dreamcast dumper discussion from ug

This forum is for the discussion of dumping games. Get help with your dumping here.

Moderator: Moderators

Post Reply
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

dreamcast dumper discussion from ug

Post by ackmed » Wed May 02, 2007 7:04 pm

darcagn/Quzar

I want to continue our discussion from ug over here.
Quzar wrote: That'll usually solve it, but that's only because DMA writes require aligned memory (as most everything on the dreamcast does =P). Even with that though, if you want to be safe, I'd reccomend doing a dcache flush on the last 32bytes after every DMA read.
ackmed wrote: I havent run into any issues with corruption since the alignment change/fix, but I will look into your dcache suggestion. thx
I looked into it and the dcache stuff make sense. I would assume it would be best to dcache flush after memset 'Q' poison, dma read the sectors, then dcache invalidate, since at that point ram would contain the correct data and not the cpu's cache.

subchannel stuff, talked about this a little with darcagn in email.

I was able to get some subchannel data from the gd-roms via a kos syscall. I last looked at this a few weeks ago so going off what I remember and some notes I made..

The syscall is CMD_GETSCD as defined in cdrom.h. I assume SCD stands for SubChannelData, but its not documented anywhere. The params I found for the syscall are

Code: Select all

struct {
  int format; // valid values are 0 to 3
  int buflen;
  char *buffer
} params;
Alot of the structs/defines for the syscall are similar to ones in http://source.winehq.org/source/include/ntddcdrm.h, which is assume is pretty standard sub channel stuff.

The values for the format seemed to match these

Code: Select all

#define IOCTL_CDROM_SUB_Q_CHANNEL    0x00
#define IOCTL_CDROM_CURRENT_POSITION 0x01
#define IOCTL_CDROM_MEDIA_CATALOG    0x02
#define IOCTL_CDROM_TRACK_ISRC       0x03
I was able to confirm the data by comparing the media catalog and track isrc data from an audio cd in cdrwin and what the syscall returned.

I only played with it for a little bit. It did have a nack for crashing on me after a few calls, but the data was there. maybe there is another param I am not seeing that is causing memory corruption.

I dont think it will help in the long run, since there is no real way to determine exactly which sector the data is coming from. One could assume its from the last read sector, but who know.

do either of you have any docs you could share and/or information on trying to directly talk to the cdrom?

thx
-ack
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Thu May 03, 2007 12:14 am

some additional interesting information I found tonight.

initializing the cdrom with p being 16 will result in it providing the only subchannel data for what appears to be the previously read sector.

With the exception of the subchannel data in the first sector, I was able to get a match when comparing a dump of track01 with cdrdao --read-subchan rw.

It was ultra slow dumping tho, about 10K/s because of having to flipflop between p being 4096 and 16 for each sector.

-ack
Nologic
Posts: 207
Joined: Sat Apr 14, 2007 12:14 pm

Post by Nologic » Thu May 03, 2007 12:29 am

Wish I had some thing to offer, but I am excited by your recent findings as it brings hope that future disc dumps will be more correct than what we have currently.

So props to you for your hard work thus far.
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Thu May 03, 2007 11:31 pm

ackmed wrote:some additional interesting information I found tonight.

initializing the cdrom with p being 16 will result in it providing the only subchannel data for what appears to be the previously read sector.

With the exception of the subchannel data in the first sector, I was able to get a match when comparing a dump of track01 with cdrdao --read-subchan rw.

It was ultra slow dumping tho, about 10K/s because of having to flipflop between p being 4096 and 16 for each sector.

-ack
got the transfer speed up to 35-40K/s with sub channel. The first sector of the track01 still gets the wrong sub channel data compared to what cdrdao dumps with, but the rest of the sub channel data matches up. It does seem to be pickie if the gd-rom isnt totally clean/unscratched.

I havent had time to compare track02 audio file as of yet. The data is offset about 2712 bytes between cdrdao and what the dc dumps.

if folks want to screw with it you can grab it from

http://www.gotwalls.com/files/httpd-ack ... 03-sub.zip

I totally butchered in the sub channel code so the source is a bit messy.

-ack
drkIIRaziel
Posts: 2
Joined: Wed May 09, 2007 7:27 am

Post by drkIIRaziel » Wed May 09, 2007 7:31 am

You can avoid the flush by reading the data from the non cached region of the memory map.Subcode is stored on an internal buffer on the cdrom , and it is the subcode of the last readed sector.Also note that some parts of the subcode are not 'protected' with ecc so they can have different values betwen reads.
Quzar
Posts: 52
Joined: Mon Apr 23, 2007 1:22 pm
Location: Miami, FL
Contact:

Post by Quzar » Wed May 09, 2007 9:08 am

Sorry I hadn't seen this until now =\.

I'll take a look at all that stuff some time this week (I still have final exams to worry about) and I'll see what I can do to help. Is there any chance you could do source as a seperate release? I don't have a webbrowser or anything availible to me at the moment to change the ip info on my DC (i use arp to connect to it =P). Also, that way the main program can be a bit smaller (even though, I admit it makes it seem really cool to have an option to download the source from within the program hehe).
I only upload the information, not images.
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Wed May 09, 2007 10:18 am

drkIIRaziel wrote:You can avoid the flush by reading the data from the non cached region of the memory map.Subcode is stored on an internal buffer on the cdrom , and it is the subcode of the last readed sector.Also note that some parts of the subcode are not 'protected' with ecc so they can have different values betwen reads.
Thanks for the info, will look into the non-cache mmap stuff.

I was hoping to find a way to read multiple sector+sub in one call. Its painfully slow reading one at a time :/
Quzar wrote: Sorry I hadn't seen this until now =\.

I'll take a look at all that stuff some time this week (I still have final exams to worry about) and I'll see what I can do to help. Is there any chance you could do source as a seperate release? I don't have a webbrowser or anything availible to me at the moment to change the ip info on my DC (i use arp to connect to it =P). Also, that way the main program can be a bit smaller (even though, I admit it makes it seem really cool to have an option to download the source from within the program hehe).
I use it for a cheap backup too. Everyone that grabs the binary acts as a source backup for me if my hard drive fails ;)

anyways I packed up the sub version source if you want to poke it.

http://www.gotwalls.com/files/httpd-ack-sub.tgz

The sub related code may seen a bit out of order because I was trying to get a dump that matched up with how cdrdao was dumping sector+sub.

-ack
drkIIRaziel
Posts: 2
Joined: Wed May 09, 2007 7:27 am

Post by drkIIRaziel » Wed May 09, 2007 4:27 pm

As far as i know there is no way to read multyply sectors + subchannel on the hardware.
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Sat May 12, 2007 3:47 pm

I made an updated version that can do either the syscall or cdrom_read_sectors methods of reading sub channel data. The 96 byte sub channel data will be appended onto the end of each sector in the track. Transfer speeds for both is still only about 40K/s :?

The url for dumping a track now includes a sub%d option, with the following valid values

0 = don't dump sub data
1 = dump sub data with syscall method (default)
2 = dump sub data with cdrom_read_sectors

http://www.gotwalls.com/files/httpd-ack ... 12-sub.zip (elf only)
http://www.gotwalls.com/files/httpd-ack ... 12-sub.tgz (source only)

-ack
User avatar
Shoometsu
Posts: 75
Joined: Wed May 02, 2007 8:04 pm
Location: Sao Paulo - Brazil
Contact:

Post by Shoometsu » Tue May 29, 2007 5:48 pm

1 = dump sub data with syscall method (default)
2 = dump sub data with cdrom_read_sectors

what's the (real) difference between both modes, but the method?
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Tue May 29, 2007 6:05 pm

Shoometsu wrote:1 = dump sub data with syscall method (default)
2 = dump sub data with cdrom_read_sectors

what's the (real) difference between both modes, but the method?
They are different methods I have found to get the sub channel data. The resulting data should be the same for both.

-ack
Quzar
Posts: 52
Joined: Mon Apr 23, 2007 1:22 pm
Location: Miami, FL
Contact:

Post by Quzar » Wed May 30, 2007 12:35 am

the first is just a kos wapper around the second.
I only upload the information, not images.
ackmed
Posts: 28
Joined: Wed May 02, 2007 3:29 pm

Post by ackmed » Wed May 30, 2007 9:39 am

Quzar wrote:the first is just a kos wapper around the second.
how do you figure that? I added the code for the first method into kos and it does not act as wrapper for the second.

-ack
Post Reply