Re: Questions on writing a new Mega CD emulator
Posted: Sun May 05, 2019 4:25 pm
I'm trying to build a support function library to transform between F1 frames and channel frames.
So far, I have EFM working in both directions (hopefully with no table transcoding errors), scrambling working (although I don't have any test scrambled data to verify I implemented it right ...), EDC generation/verification, and RSPC P/Q generation/verification (only thanks to ecm.c)
I have absolutely no idea how to actually use P/Q to correct errors in data sectors if they're detected, and it's also unclear to me how to implement CIRC for the lower levels of the disc. It also seems really weird to me why the first 16 bytes are skipped when calculating the EDC in ecm.c, or why ecm.c is zeroing out the address bytes before computing P/Q RS codes in CD-XA mode.
Here's my code so far ... https://pastebin.com/raw/uY0gWjdV
Any pointers for the missing stuff would be appreciated ^-^
Games being able to lie about the sector mode is a compelling reason to leave it scrambled.
So now at this point that's 2448-bytes/sector. And from what I see, the two sync control subcode bytes are 14-bit EFM codes that do not exist in the EFM table, so I see why it's generally not stored as 2450-bytes. So I'm probably going to go with 2448-bytes/sector, with lead-in + lead-out, and with scrambled data, as my preferred format, unless something new comes up.
So far, I have EFM working in both directions (hopefully with no table transcoding errors), scrambling working (although I don't have any test scrambled data to verify I implemented it right ...), EDC generation/verification, and RSPC P/Q generation/verification (only thanks to ecm.c)
I have absolutely no idea how to actually use P/Q to correct errors in data sectors if they're detected, and it's also unclear to me how to implement CIRC for the lower levels of the disc. It also seems really weird to me why the first 16 bytes are skipped when calculating the EDC in ecm.c, or why ecm.c is zeroing out the address bytes before computing P/Q RS codes in CD-XA mode.
Here's my code so far ... https://pastebin.com/raw/uY0gWjdV
Any pointers for the missing stuff would be appreciated ^-^
You were right the first time, it was.which I thought was what byuu was asking about
Games being able to lie about the sector mode is a compelling reason to leave it scrambled.
So now at this point that's 2448-bytes/sector. And from what I see, the two sync control subcode bytes are 14-bit EFM codes that do not exist in the EFM table, so I see why it's generally not stored as 2450-bytes. So I'm probably going to go with 2448-bytes/sector, with lead-in + lead-out, and with scrambled data, as my preferred format, unless something new comes up.