HDD (or flash) instead of a CD, questions...

[HardWareMan]

Oh, so... OK, I can try this at home.

[KanedaFr]

I'd like to make a custom checker/passthrought item.

My goal would be to take the request command, issue a serial via usb message if I doesn't understand it, and do the same thing with the status command.
In fact, it would help me to find unknown (or uncomplete) command while playing game AND to check if the status I would send is similar to the status sent on real hardware.

I know the passthrought part is not really easy to do with an µC but is it doable ?
I would add a step on the project without waiting I make some progress on FPGA part

If it's P.I.T.A, I'll wait a little more

[KanedaFr]

and, after we made all these research, a doc popups with everything already done...since 1994

viewtopic.php?f=5&t=2707
the technical doc, pages 23+ explains /confirms everything

[Miquel]

I'm lost on this, is someone doing it for real?

[KanedaFr]

you ?

on hold on my side
don't know about HardwareMan

[Miquel]

Me? No, I don't know enough electronics to do that. Perhaps if everything fits on a FPGA I could manage.

In your case, how long have you gone, there is something you can show?

Just in case, industrial patents last for 20 years effectively worldwide so I don't see any problem for toying as much as desired with this hardware (Software last further).

edit:
My mistake, it's not worldwide but human-worldwide, giant squirts copy as desire since we don't have any trade agreement with them.

[KanedaFr]

I updated the project page with most of the informations I had for now on the CDC.
its based on this thread, on CDD_inf.txt, on GensisPlusGX source code and several technical manuals available.

There is still some missing bits and, unfortunately, all captured data by HardwareMan are lost (I get the CSV back but they're not really usable as is)
I now have a Saleae so I'll recapture them later.

I plan to update CDD stuff next week, it would then give me a list of data to capture to fix what is missing.

(yes, 7 years later but I NEVER forgot it)

[KanedaFr]

I'm stuck trying to understand the sub part....well, the S0S1 bytes in fact
I know I could only focus on Q sub but...well....I want to know and understand.


PQRSTUVW are encore on 96+2 frames, 1 bit per frame
Only the 96 last frames are really used for subcode because the 2 first frames are used to encode the S0 and S1 sync bytes

P is easy (96 0's since CD dump get ride of gaps and it's mostly unused)
Q is more complex but not that hard (apart the 2 first bits of course)
RW is nothing since used for CD+G only so nothing to create

BUT the 2 first bits for each of them (so 2x8bits) should produce to S0 and S1 bytes, which tell the CDC a sector started.
Like data, these bytes go through 8-to-14 modulation.

We know the 14bits version of the S0 S1 bytes are
SYNC0 ( 00100000000001 ) and SYNC1 ( 00000000010010 )
BUT, and this is my problem,
I'm absolutely unable to find the 8 bits version I need.

why ? because they are reserved patterns (data can't use them, only sync) and so you can't find them on the 256-patterns table.

anyone knows them or know where / how to find them ?

[Mask of Destiny]

We know the 14bits version of the S0 S1 bytes are
SYNC0 ( 00100000000001 ) and SYNC1 ( 00000000010010 )
BUT, and this is my problem,
I'm absolutely unable to find the 8 bits version I need.

why ? because they are reserved patterns (data can't use them, only sync) and so you can't find them on the 256-patterns table.

anyone knows them or know where / how to find them ?

They don't exist. As you say, the whole point is that they don't decode to a normal byte so they can be used for sync detection. The CD DSP outputs a dedicated signal, SCOR, when it detects sync. This signal, along with SBSO (full subcode serial output) and EXCK (externally driven clock for said serial output) are directly connected to the MCE (Mega CD Engine) for subcode transfer. Well, there's technically a buffer on the lines that are inputs to MCE, but it's direct other than that.

BUT the 2 first bits for each of them (so 2x8bits) should produce to S0 and S1 bytes, which tell the CDC a sector started.
Like data, these bytes go through 8-to-14 modulation.

The S0 and S1 sync "bytes" aren't used by the CDC at all. Instead it looks for a separate CD-ROM specific sync pattern in the decoded data and the CD-ROM spec specifies a transform of the data that makes it very unlikely for this pattern to occur during a normal sector. Feels like a gross hack when CD-DA already had a proper sync marker, but I guess it made it easier to tack on CD-ROM support to existing CD player hardware. The sync pattern and transform are specified in the yellow book spec.

It's also worth noting that the CDD MCU receives the Q subcode through a separate interface from the full subcode output received by the MCE. SUBQ is the output and SQCK is the externally driven clock for that output (at least on the CXD2500AQ, the CXD1167Q seems like it has a selectable clocck direction, but presumably since both parts are used in different models the rest of the CD hardware expects the externally driven clock setup). It also seems to use SCOR for sync detection though.

[KanedaFr]

so if I raise SCOR, put anything I want on the 2 first S0S1 bits of the Q subchannel, here we go ?

The more I dig on this SYNC stuff, the less I understand...because if we're logic, S0S1 is 2x8 bits so it disables 2bits on P-W
But any (even official) docs I read talk about 98 bytes for everyone, apart Q!
It doesn't make sense to set P for exemple on a start of a audio sector since it would falsy says the sector is a gap, not audio data.

I can't wait to trace what happen on these lines on start (when drive reads the TOC) , on seek and on read (mainly when it jumps from one track to the next one).

[Mask of Destiny]

so if I raise SCOR, put anything I want on the 2 first S0S1 bits of the Q subchannel, here we go ?

So S0/S1 never get output on SUBQ. Looking at the CXD2500BQ datasheet, it looks like the DSP does Q channel error detection and only outputs the 80 data bits of the Q subchannel (the other 16-bits of channel Q are for error detection) and optionally an extra 16-bits of audio data peak info. I think the CRC OK signal (CRCF) is output on SUBQ while SQCK is high.

For SBSO, the datasheet is less clear. It seems like a byte is availabe on the falling edge of WFCK (seems to be the channel frame clock output) and you have until the next falling edge to clock out 8 bits of data using EXCK/SBSO. The datasheet does seem to show that it will output something if you attempt to clock out data while SCOR is high, but it doesn't seem to make sense to do so. My assumption is that the MCE starts the subcode transfer on the falling edge of SCOR.

But any (even official) docs I read talk about 98 bytes for everyone, apart Q!

There are 98 channel data frames per timecode frame, but there are definitely only 96 bytes of actual subcode data.

I do recommend taking a look at the CXD2500BQ (or the AQ, but the copy of that I saw online seemed like a low quality scan and there don't seem to be obvious differences between the BQ and AQ) datasheet. It's not well written and some if it is a bit confusing, but it does have a fair bit of detail about the interface between the DSP and the rest of the system.

Some Mega CDs use the CXD1167Q. It seems to have a separate CRCF output pin, but we don't have a full datasheet for it so it's hard to know if there are other interface differences.

To take a step back here, I'm assuming you want to emulate the drive at the level of the interface between the DSP and the rest of the system (MCE + CDD MCU + LC8915) because this is conveniently where the Model 1 sticks the cable that runs to the drive and it's a reasonably sensible place to emulate the drive logically. But there are other choices you could make and I may be confusing things if you're planning on interfacing somewhere else

[KanedaFr]

On the CXD2500AQ datasheet, it's written

Code: Select all

The contents of the subcode interface can be externally read in two ways.

The Game Processor get subcodes using the first way : P-W through SBSO, EXCK based.
It make sense since MCD support CD+G and so needs more than only subcode Q.

Code: Select all

These subcodes can be read by entering EXCK immediately after the fall of WFCK.

Code: Select all

SCOR Turns "H" when subcode Sync SO or 51 is detected.

since it's S0 or S1, GameProcessor can totally not know if it's receiving first or second bits.
so, like you, I assume it doesn't care about P-W bits when SCOR is high and starts reading the 96 bits when it goes low.


If we even go deeper on this subject, in fact, I don't even know if it's required or not
If the Game Processor uses the status' nibbles to read position, Q isn't needed
if we don't care about CD+G, R-W isn't need (note for myself : get technical informations on the Karaoke module)
P is rarely used (D/M already desactivate/activate audio)

On emulators, subcodes aren't emulated and games plays w/o problem, no ?

To take a step back here, I'm assuming you want to emulate the drive at the level of the interface between the DSP and the rest of the system (MCE + CDD MCU + LC8915) because this is conveniently where the Model 1 sticks the cable that runs to the drive and it's a reasonably sensible place to emulate the drive logically. But there are other choices you could make and I may be confusing things if you're planning on interfacing somewhere else

I want to emulate this :

so yes, on the MCD1 it means hooking the cable.

[Mask of Destiny]

On the CXD2500AQ datasheet, it's written

Code: Select all

The contents of the subcode interface can be externally read in two ways.

The Game Processor get subcodes using the first way : P-W through SBSO, EXCK based.
It make sense since MCD support CD+G and so needs more than only subcode Q.

The MCE/Game Processor uses SBSO and EXCK, but the CDD MCU uses SUBQ and SBCK.

If we even go deeper on this subject, in fact, I don't even know if it's required or not
If the Game Processor uses the status' nibbles to read position, Q isn't needed
if we don't care about CD+G, R-W isn't need (note for myself : get technical informations on the Karaoke module)
P is rarely used (D/M already desactivate/activate audio)

On emulators, subcodes aren't emulated and games plays w/o problem, no ?

You're correct, the full subcode interface is not needed for playing games. The full subcode interface drives level 6 interrupts and receipt of subcode data via gate array registers 68-1FE. Approximately nothing other than the builtin CD player actually uses this.

Games don't interact with subcodes directly, but instead rely on status reports from the CDD MCU which in turn is driven off the SUBQ/SBCK interface. I guess to put this another way, you can probably ignore any signals that only go to the MCE/Game Processor and focus only on the ones that go to the CDD MCU (Mechanism Control UP in the diagram you posted) and LC8915 (or equivalent depending on model) and CDD fader (though I think these signals also generally go to the LC8915 too). I think this just gets you out of SBSO, EXCK and WFCK though.

[KanedaFr]

main page updated with all I know/understand, be free to fix and confirm data

next step : capture data with my Saleae -> see you in some months

[Mask of Destiny]

main page updated with all I know/understand, be free to fix and confirm data

By main page, you mean this one, right? One thing that I found a little confusing is that you talk a lot about the CDC, but from the description it sounds like you're talking about the MCU that's part of the CDD in Sega's parlance (or the Mechanism Controller in some of the schematics). When Sega's docs talk about the CDC, they're referring to the LC8915 (or a chip in this family).

On an unrelated note, for some reason I thought this CDD MCU was on one of the main boards of the MCD1, but it seems I was mistaken. Since you'll be emulating the MCU you actually don't need to care about subcodes at all unless you want to implement CD+G. The SUBQ/SQCK stuff is how the CDD MCU gets timestamp info, but the game processor only gets the digested status reports. Sorry for any confusion I added above because of this mistake.

As an aside, did you see this archive Nemesis posted a while back. It has the full source of the CDD MCU implementation from the SNASM CD-ROM emulator. While it's not literally the same code as what's in the production units (dev system uses a 6809 family or something like that whereas the production ones are cheapo 4-bit MCUs), but the behavior seems to be basically identical. I used this source as a guide for implementing the CDD MCU implementation in BlastEm. It doesn't get you everything since some details depend on the behavior of things lower down in the stack, but I found it very helpful.

One little detail that's worth mentioning, is that seeking has two consequences for CDD status. The first is that it's not consistently happening every 1/75th of a second anymore. The other is that periodically the drive seems to lose sync and the CDD gives a not-ready status. This not-ready status is actually important because the BIOS is a buggy piece of crap and only updates it's knowledge of the current track number after receiving such a status even though it's periodically getting track number updates from the CDD.