Questions on writing a new Mega CD emulator

[Eke]

Genesis Plus GX seems to start in the "reading TOC" (0x9) mode when the system is reset and a disc is inserted.

The BIOS then sends a "stop" (0x1) command, which GX lets the BIOS read back once, and then it switches to "reading TOC" mode again.

This was based on the status infos described in Stef's cdd_inf.txt document regarding the Stop command, which stated that status was 0x0 after that command then 0x9 so I assumed the drive was automatically restarted in leadin area once stopped (and assumed it was also the case on reset when it initializes in stopped state).

This behavior seems to work fine with BIOS but, after analyzing CD emulator controller sourcecode posted by Nemesis, it seems like the CDD status is initialized then stays to 0x0 (stopped) until a TOCT request command is sent (0x2:0x4), which only then causes a CDD status transition to 0x9 (read TOC) if there is a disc in the tray (0xb otherwise).

I don't see any code in GX that transitions away from "reading TOC" into "playing" (0x1) mode after reading 150 sectors.

That transition is not automatic and occurs only after a read command (0×3) is sent. This is confirmed in CDTrac microcontroller sourcecode (actually it seems you can also get this status transition by sending a resume/play command): CDD status remains to 0x9 while TOC is being read in leadin area but also when the drive reaches the end of leadin area. Drive is automatically paused at the start of program area (which corresponds to absolute time 00:00:00) but CDD status remains unchanged until specific commands are sent.

Note that there are no such thing as 'reading 150 sectors' while in 'read TOC' status, the leadin area has variable size apparently and the drive is paused when end of leadin area is detected. The 150 sectors thing is the 2s pause at the start of the program area so it's not read in 'read TOC' status.

Anyone have advice?

Are you correctly emulating CDC decoder interrupt (int5) every 1/75s once it get enabled by the BIOS (IFCTRL=0x3A and DECEN bit in CTRL0 enable decoder interrupt and data transfer to the host) ? It has higher priority than CDD interrupt (int4) used to read CDD status and update CDD command and should not cancel it.

Normally, once 00:01:74 is reached in CDD status, the BIOS will send a new set of CDC registers write commands (in int5 handler I think) to enable write of sector data to CDC internal buffer RAM and initiate data transfer to the host, then BIOS successively reads data words from CDC host data register.

Also don't forget to update CDC HEAD0-3 registers with the info of current decoded block/ sector as they are read (I think) in int5 handler.

[Near]

it seems like the CDD status is initialized then stays to 0x0 (stopped) until a TOCT request command is sent (0x2:0x4), which only then causes a CDD status transition to 0x9 (read TOC) if there is a disc in the tray (0xb otherwise).

Ah, so then ... how does the BIOS get correct TOC information if the lead-in area hasn't already been read in?

I would think you'd have to wait N milliseconds for the drive head to seek to the beginning of the disc, plus two more seconds after starting the disc reading before you could query TOC information via 0x2:0xN commands.

Note that there are no such thing as 'reading 150 sectors' while in 'read TOC' status, the leadin area has variable size apparently and the drive is paused when end of leadin area is detected. The 150 sectors thing is the 2s pause at the start of the program area so it's not read in 'read TOC' status.

Oh boy, that's confusing. So all of the +150 stuff in GX is just for the first track pre-gap being artificially added on, and there's even more "unknown-size" lead-in area with the TOC?

None of this makes any sense ... :c

I know the TOC isn't just a single sector, it has to encode 100 tracks worth of information in the Q-subchannel, and I've also heard there's redundancy (it repeats itself) in case it were read wrong, as subchannel data isn't protected by Reed-Solomon codes.

Are you correctly emulating CDC decoder interrupt (int5) every 1/75s once it get enabled by the BIOS (IFCTRL=0x3A and DECEN bit in CTRL0 enable decoder interrupt and data transfer to the host) ?

Ah, I see ... that's probably it, thank you. Hopefully that will finally lead to a CDC DMA so I can start trying to send back disc data to the BIOS.

Also don't forget to update CDC HEAD0-3 registers with the info of current decoded block/ sector as they are read (I think) in int5 handler.

Good catch, I wasn't doing that, either. Thank you!

I'll give it another go tonight and see where I can get to.

[Eke]

how does the BIOS get correct TOC information if the lead-in area hasn't already been read in? I would think you'd have to wait N milliseconds for the drive head to seek to the beginning of the disc, plus two more seconds after starting the disc reading before you could query TOC information via 0x2:0xN commands.

According to the microcontroller sourcecode, the status is returned with 'not ready (0xf) report code until the TOC is fully read in lead-in area and the drive is paused outside lead-in area.
By returning a normal report code immediately after the first request, we are just simulating zero-time leadin area read and the BIOS knows it can query the rest of TOC infos.
The real time to read lead-in area obviously depends on the number of sectors in lead-in area but it's unlikely 150 sectors i.e 2s. The 2s pause corresponds to the first track (TNO=01) pause area (INDEX=00) and is technically outside lead-in area.

Oh boy, that's confusing. So all of the +150 stuff in GX is just for the first track pre-gap being artificially added on, and there's even more "unknown-size" lead-in area with the TOC?

None of this makes any sense ... :c

It makes sense to ignore the "unknown size" of lead-in area considering none of the disc images we have store this area and the BIOS does not care about this or has any way to track where precisely we are in leadin area, hence why the read time of this area is not emulated
And similarly, the 150 sector offset corresponds to the delta between the absolute time used in CDD status/commands, which starts at 00:00:00 at the start of program area and the LBA (logical block address) which corresponds to the sector offset in the CD images (which never contain that 2s pause).
We could have use a different sector counter which starts at the sector corresponding to 00:00:00 and remove an offset everytime we seek or read from CD image file but it does not change anything in the end, it's just an implementation choice (although cdd.lba should probably be initialized to -150 instead of 0 to be more accurate to initial reported state as seen in available microcontroller sourcecode , but I originally assumed CDD would pause the drive on reset at the first track starting block as reported by lead-in area)

I know the TOC isn't just a single sector, it has to encode 100 tracks worth of information in the Q-subchannel, and I've also heard there's redundancy (it repeats itself) in case it were read wrong, as subchannel data isn't protected by Reed-Solomon codes.

Indeed, hence why I didn't understand why you would think the 150 sector offset is related to lead-in. Pause area is precisely defined in the standards as being sectors in User Data / Program or Lead Out areas with INDEX field (in Q-subchannel data) set to 00 but this does not exist for Lead-In area.

[Near]

According to the microcontroller sourcecode, the status is returned with 'not ready (0xf) report code until the TOC is fully read in lead-in area and the drive is paused outside lead-in area.

Okay, cool. Can do then. I found some websites that mentioned the lead-in area is 7500 sectors, and I guess once it's read a full, good copy of the TOC, it can seek ahead to the first track's pregap so it won't actually take 100 seconds.

The 2s pause corresponds to the first track (TNO=01) pause area (INDEX=00) and is technically outside lead-in area.

Is there any such thing as track# 0, or a disc with track# 1, no track# 2, and then track# 3? Or is it literally, always, "the first track is 1, the second track is 2, ..."? I don't mean "what it should be per Redbook", I mean, if you could write your own bits to the raw disc spiral, could you make such a CD that is missing tracks or has a track 0? Some people online talk about a "data track 0" with mixed-mode CDs ...

We could have use a different sector counter which starts at the sector corresponding to 00:00:00 and remove an offset everytime we seek or read from CD image file but it does not change anything in the end, it's just an implementation choice

The thing is, the standard says the pregap must be 2s, but you can make CDs where that's not the case, with the risk that CD players may skip part of the audio/data as a result.

So it sounds like an implementation detail of the LC8951 to force the 2s pregap no matter what in its own reporting of MM:SS:FF times.

My intended abstraction layer for CDs will be to include the null bytes for pregaps, including for the first track, so I'm going to try to avoid the 150-sector offset detail.

Indeed, hence why I didn't understand why you would think the 150 sector offset is related to lead-in.

It's extremely hard to find good information on the low-level details of CDs. It's like nine circles of hell.

...

Moving on ... I see in the GX CDC code:

Code: Select all

    /* pending decoder interrupt */
    cdc.ifstat &= ~BIT_DECI;

    /* decoder interrupt enabled ? */
    if (cdc.ifctrl & BIT_DECIEN)
    {
      /* pending level 5 interrupt */
      scd.pending |= (1 << 5);
      ...
    }

So the pending interrupt flag is set for STAT3 read-out even if interrupts are disabled.

Code: Select all

    case 0x0f:  /* STAT3 */
    {
      uint8 data = cdc.stat[3];

      /* clear !VALST (note: this is not 100% correct but BIOS do not seem to care) */
      cdc.stat[3] = BIT_VALST;

      /* clear pending decoder interrupt */
      cdc.ifstat |= BIT_DECI;

And reading STAT3 will clear the pending status bit, but won't actually suppress an interrupt that was queued to trigger later?
And an interrupt actually firing won't clear STAT3, but will thus only fire that one time.
So in other words, we can't emulate these IRQs via { bool pending (DECI); bool enable (DECIEN); }.
I think I'm going to need a third "bool trigger;" flag that once set, cannot be suppressed by reading STAT3.

Also unclear whether *all* interrupts work like this (eg graphics, CDD, timer, etc), or just CDC sub-interrupts (decoder, transfer, command.)

...

Anyway, now I'm up to CDC DMA commands. It looks like after seeking to 00:01:70, it expects to *not* pause at 00:02:00, but instead keep reading. So I guess the pregap part of a track is part of the track as well.

...

EDIT: okay, it's reading the first sector of the CD via $ff8008. But it does two transfers of lengths 0x803 and 0xfff. And since we step by two, and GX casts the length to int16 to detect an underflow, that means 0x804 + 0x1000 bytes == 0x1804 bytes are read, which is 6148 bytes. Which is ... way more than a single sector. I would have expected 0x930 (for BIN 2352 style sectors) or 0x800 (for ISO 2048 style sectors.)

[Near]

Almost there ... the BIOS is reading the first sector of the valid Sega CD test BIN image, and going to "press start button".
Once doing so, it reads the same first sector again, and then hangs forever.

From the top ...
The CDD seeks to sector 145 (-5 if you will), skips writing sector 145 due to DECEN being disabled, skips writing sector 146 due to WRRQ being disabled, writes out sectors 148, 149, 150. Then it performs a DTTRG=3 and reads back track 1 sector 0 (absolute sector 150) via $ff8008 reads, 0x804 bytes (one sector of 4-byte header + 2048-bytes data.)

Then we get to "press start button". Upon doing so, it mostly repeats itself again: it seeks to 145, ends up writing sectors 147-150, and then reading back sector 150. It turns off writing (WRRQ=0) so sectors 151+ do not get transferred.

It starts reading most of the CDC registers three times, during which sectors 151-153 do not get transferred.
Then it pauses the CDD, then it starts playing the CDD again.
But it doesn't set WRRQ, so it just starts skipping writes.
Meanwhile, it reads all the CDC registers, while skipping sectors 154-160.
Then it writes to the CDC control registers, sends a superfluous CDD play again, and skips sectors 161-163.
This pattern keeps going until it skips sector 189.
Then after one last read of all CDC registers, it pauses the CDD, writes IFCTRL, and then deadloops querying the TOC.

Logs below ... any ideas this time? This is likely the last piece before I can boot some stuff :/

Code: Select all

CDC write f=0
CDC write f=0
CDC write 1=3a
CDC write 8=0
CDC write 9=0
CDC write c=0
CDC write d=0
CDD 1:0
CDD 2:4
CDD 2:3
CDD 2:5
CDD 1:0
CDD 2:4
CDD 2:3
CDD 2:5
CDD 4:0
seeking to 145
CDD 2:0
CDD 3:0
blocked decoding of 145
CDC write 1=38
CDC write 1=3a
CDC write f=0
CDC write 1=3a
CDC write 8=0
CDC write 9=0
CDC write c=0
CDC write d=0
CDC write a=a0
CDC write b=f8
not writing 146
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=71
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a4
CDC write b=d8
writing to 147:930
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=72
CDC read 8=1
CDC read 9=30
CDC read a=9
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a7
CDC write b=f0
writing to 148:1260
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=73
CDC read 8=1
CDC read 9=60
CDC read a=12
CDC read d=80
CDC read e=0
CDC read f=0
CDC read 0=0
writing to 149:1b90
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=74
CDC read 8=1
CDC read 9=90
CDC read a=1b
CDC read d=80
CDC read e=0
CDC read f=0
CDC read 0=0
writing to 150:24c0
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=0
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=0
CDC read 0=0
CDC write a=a0
CDC write b=f8
CDC write 2=3
CDC write 3=8
CDC write 4=c0
CDC write 5=24
CDC write 6=0
DTRG: 3
reading from 24c0 remaining 803
reading from 24c1 remaining 802
0002
reading from 24c2 remaining 801
reading from 24c3 remaining 800
0001
reading from 24c4 remaining 7ff
reading from 24c5 remaining 7fe
5345
reading from 24c6 remaining 7fd
reading from 24c7 remaining 7fc
4741

<continues>

Code: Select all

reading from 2cc2 remaining 1
reading from 2cc3 remaining 0
completed
0000
CDC write 7=0
not writing 151
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=1
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 152
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=2
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDD 2:0
not writing 153
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=3
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDD 6:0
CDC write 1=38
CDC write 1=3a
CDD 2:1
CDD 2:5
CDD 4:0
seeking to 145

<Press Start Button>

Code: Select all

CDD 2:5
CDD 4:0
seeking to 145
CDD 2:0
CDD 3:0
not writing 145
CDC write 1=38
CDC write 1=3a
CDC write f=0
CDC write 1=3a
CDC write 8=0
CDC write 9=0
CDC write c=0
CDC write d=0
CDC write a=a0
CDC write b=f8
not writing 146
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=71
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a4
CDC write b=d8
writing to 147:930
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=72
CDC read 8=1
CDC read 9=30
CDC read a=9
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a7
CDC write b=f0
writing to 148:1260
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=73
CDC read 8=1
CDC read 9=60
CDC read a=12
CDC read d=80
CDC read e=0
CDC read f=0
CDC read 0=0
writing to 149:1b90
CDC read 2=df
CDC read 5=0
CDC read 6=1
CDC read 7=74
CDC read 8=1
CDC read 9=90
CDC read a=1b
CDC read d=80
CDC read e=0
CDC read f=0
CDC read 0=0
writing to 150:24c0
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=0
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=0
CDC read 0=0
CDC write a=a0
CDC write b=f8
CDC write 2=3
CDC write 3=8
CDC write 4=c0
CDC write 5=24
CDC write 6=0
DTRG: 3
reading from 24c0 remaining 803
reading from 24c1 remaining 802
0002
reading from 24c2 remaining 801
reading from 24c3 remaining 800
0001
reading from 24c4 remaining 7ff
reading from 24c5 remaining 7fe
5345
reading from 24c6 remaining 7fd
reading from 24c7 remaining 7fc
4741

<continues>

Code: Select all

reading from 2cc2 remaining 1
reading from 2cc3 remaining 0
completed
0000
CDC write 7=0
not writing 151
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=1
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 152
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=2
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDD 2:0
not writing 153
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=3
CDC read 8=1
CDC read 9=c0
CDC read a=24
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDD 6:0
CDC write 1=38
CDC write 1=3a
CDD 2:0
CDD 3:0
not writing 154
CDC write 1=38
CDC write 1=3a
CDC write f=0
CDC write 1=3a
CDC write 8=0
CDC write 9=0
CDC write c=0
CDC write d=0
CDC write a=a0
CDC write b=f8
not writing 155
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=5
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 156
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=6
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 157
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=7
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 158
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=8
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 159
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=9
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 160
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=10
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a0
CDC write b=f8
CDC write 1=38
CDC write 1=3a
not writing 161
CDD 2:0
not writing 162
CDD 3:0
not writing 163
CDC write 1=38
CDC write 1=3a
CDC write f=0
CDC write 1=3a
CDC write 8=0
CDC write 9=0
CDC write c=0
CDC write d=0
CDC write a=a0
CDC write b=f8
not writing 164
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=14
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 165
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=15
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 166
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=16
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 167
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=17
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 168
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=18
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 169
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=19
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a0
CDC write b=f8
CDC write 1=38
CDC write 1=3a
not writing 170
CDD 2:0
not writing 171
CDD 3:0
not writing 172
CDC write 1=38
CDC write 1=3a
CDC write f=0
CDC write 1=3a
CDC write 8=0
CDC write 9=0
CDC write c=0
CDC write d=0
CDC write a=a0
CDC write b=f8
not writing 173
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=23
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 174
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=24
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 175
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=25
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 176
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=26
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 177
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=27
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 178
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=28
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a0
CDC write b=f8
CDC write 1=38
CDC write 1=3a
not writing 179
CDD 2:0
not writing 180
CDD 3:0
not writing 181
CDC write 1=38
CDC write 1=3a
CDC write f=0
CDC write 1=3a
CDC write 8=0
CDC write 9=0
CDC write c=0
CDC write d=0
CDC write a=a0
CDC write b=f8
not writing 182
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=32
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 183
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=33
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 184
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=34
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 185
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=35
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 186
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=36
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
not writing 187
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=37
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDC write a=a0
CDC write b=f8
not writing 188
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=38
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDD 2:0
not writing 189
CDC read 2=df
CDC read 5=0
CDC read 6=2
CDC read 7=39
CDC read 8=1
CDC read 9=0
CDC read a=0
CDC read d=80
CDC read e=0
CDC read f=8
CDC read 0=0
CDD 6:0
CDC write 1=38
CDC write 1=3a
CDD 2:2
CDD 2:0
CDD 2:1
CDD 2:2
CDD 2:0
CDD 2:1
CDD 2:2
CDD 2:0
CDD 2:1
<repeats forever>

<hangs>

[Eke]

And reading STAT3 will clear the pending status bit, but won't actually suppress an interrupt that was queued to trigger later?

Well, that is likely incorrect in my code actually (you can see there is commented code which clear the pending int5 flag when !DECI is set and CDC irq line is disactivated after reading STAT3... and similar code for data transfer interrupt when DTACK register is written) but I think I left it like that because it did not changed anything (int5 is never masked on ASiC side when CDC interrupts are triggered and is always cleared in int5 handler so it never really remains "pending").

And an interrupt actually firing won't clear STAT3, but will thus only fire that one time.

int5 will likely continue to be triggered until !DECI bit is reset by reading STAT3 register or DECIEN bit is cleared in IFCTRL register. It's just that int5 handler in BIOS always read STAT3 register, so it did not make any difference to handle it like other internal pending interrupts (i.e clearing pending flag when int is serviced) but that's again not hardware accurate as only specific CDC register read/write can acknowledge and inactivate CDC interrupt.

Also unclear whether *all* interrupts work like this (eg graphics, CDD, timer, etc), or just CDC sub-interrupts (decoder, transfer, command.)

CDC interrupt request is actually the only one which is controlled externally to the ASIC so it's easier to guess its real behavior. Other interrupts requests are triggered and cleared internally so their "pending" and "ack" conditions are harder to figure.

[TascoDLX]

Logs below ... any ideas this time? This is likely the last piece before I can boot some stuff :/

It looks like you're not performing the seek for the read command. The CDD treats the READ command as a seek leading into reading data. Contrast this with the SEEK command, which is treated as a seek leading to a pause.

[Near]

!! oh wow, I never would have thought of that. I figured you'd just issue a seek and then a play.
I'll give this a try, hopefully that's what was missing, thank you!

[Near]

Still a crazy amount of things to implement (CD-DA most especially), but ... it works now ^-^;

Videos here: https://twitter.com/byuu_san/status/1131642295067897856

Thank you very much to everyone in this thread who graciously helped me make a 21-year long dream come true.

This one's to you, Atani.

[Sik]

Later we should probably write a new doc documenting the CDD well. By this I mean what each command does (including the format) and common sequences of commands (e.g. how to ask to read CD sectors or how to ask to play a given audio track). Not having to deal with the BIOS sounds like it should be a good thing long term (the other thing to replace would be the back-up RAM stuff, but that's for a different thread :​v).

[Near]

I'm happy to try and help with some documentation in return for all the help, perhaps spare MaskOfDestiny some pain, hahah.

I can capture CDC+CDD logs of booting a game. Luke Usher made a tiny 128KB "hello world" style demo for me which is pretty good for that.

It feels really intimidating to see a 600MB game and think "how in the world is this ever going to run?", but of course pretty much as soon as the "hello world" demo runs, most of the other games run.

I also purchased a Mega CD2, and I'd like to try and fill in the list of like a billion unknown open questions I have for the system, even if it's not super important to games. But to do that, I'm going to need some hardware stuff. A flash cart alone would be the most blunt object possible, but I iterate dozens of times faster when I have a PC<>serial cable link and can just push new binaries from my PC right onto a running system, get results back to my PC, and repeat.

I tried digging through that CDD emulator but it's intimidating being in (nicely commented at least) assembler. Looks to be actual code that might run on a real CDD.

Speaking of ... it would certainly be amazing to be able to get one of those CDD ROMs dumped.

BIOS replacement could be cool. What I'd like to see most is a free (MIT/ISC/etc) BIOS, ala C-BIOS for the MSX, that can be dropped into any emulator out of the box, which can be swapped out for the real deal if desired. I'd definitely be willing to help with such a project.

[Sik]

BIOS replacement could be cool. What I'd like to see most is a free (MIT/ISC/etc) BIOS, ala C-BIOS for the MSX, that can be dropped into any emulator out of the box, which can be swapped out for the real deal if desired. I'd definitely be willing to help with such a project.

Yeah, that's why I want those CDD sequences to be documented (even if just at a highish level, i.e. enough for the programming side of things). Once you have that you don't even need a BIOS to use the CD drive (talk to the CDD), and the only other thing the BIOS does is back-up RAM (everything else has to be touched by the game directly).

I suppose a free BIOS could matter for emulators mainly as you said (but that wouldn't be just the BIOS, but the whole firmware including the CD player, etc.). If you're booting your own homebrew from cartridge go the CDD route instead.

[Chilly Willy]

I think the primary benefit of an open BIOS for the CD would be to help facilitate CD replacements. The CD drives on these systems are now so old that they're not very good, even when "new". The replacement I got for my CDX is barely any better than the old drive. An open BIOS would allow replacing the drive with something entirely different that still worked at the BIOS level, since I don't know of anything commercial for the CD that bypasses the BIOS. That would allow for competing CD replacements since very few people are up to replacing the CD at the hardware level.

[cero]

Or maybe even an ODE that replaces the drive with a SD card? Which could also lead to MegaSG implementing it.

[King Of Chaos]

There's widespread rumors Terraonion is about to announce/release a Sega CD ODE.

If so, day one purchase for me.