I want to continue our discussion from ug over here.
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.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
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;
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 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