With CD audio, intro doesn't play, and E1M1 plays instead of intermission

[rfmerrill]

This is with 3.1

I have the intermission as track 28 and the intro as track 29, per the guide in the wiki. As the title says, I get a silent intro, and when I complete a level, e1m1 plays instead of the intermission music.

I've also verified I can play both of these tracks through the MegaCD's CD player menu, so it's able to read and play them.

[rfmerrill]

I just booted it up again and e1m1 played for the intro as well

[viciious]

The guide on the wiki is outdated

[rfmerrill]

Ah. Is there an up to date tracklist to follow somewhere?

[viciious]

Each map should have its own dedicated audio track, followed by:

• the end track
• victory track
• intermission screen track
• the title screen/introduction track

[rfmerrill]

That sounds like what I have. How many tracks total should that be? I have 29

[viciious]

v3.1 lists 27 maps in its "New game" setup menu screen

[rfmerrill]

Gotcha. So I should do e1m1-e1m9, e2m1-e2m9, e3m1-e3m9 and then bunny, victory, inter, intro?

[rfmerrill]

Ah ok, I think it's in the order they're listed in the menu. So

• 1-8 for each episode
• then e1m9, e2m9
• hell gate (this is a console-only level?)
• Then the last four

[viciious]

Audio tracks sequencing should follow the 'mapNumber' field ordering here: https://github.com/viciious/d32xr/blob/master/content/files/dmapinfo

[rfmerrill]

Thank you very much for your helpful responses, that helps a lot!

Unfortunately I burned a new disc with 31 tracks (27 + 4), and while every map I start on has the music that I expect it to, I still get e1m1 for both the title screen and intermission :(

I should get a build environment going so I can see if I can't debug this myself.

[rfmerrill]

Since I don't have much else to go on I decided to try other hardware to make sure it wasn't revision or unit dependent.

Original setup: JP 32X, JP Model 1 VA6 mega drive, JP Model 1 Mega CD Second setup: JP 32X, US Model 2 VA1 mega drive, US Model 2 Sega CD (Funai)

Same behavior in both cases.

[rfmerrill]

Okay I managed to get it building and I think I found the problem (or at least part of it):

I modified the debug menu to show the value of mars_cd_num_tracks and it is somehow getting erroneously set to 95, which is the real # of tracks plus 64. The fact that the correct # of tracks is 31 (0x1F) and we are getting 95 (0x3F) seems possibly significant?

When I hard code the intermission and opening to the correct track numbers, everything plays right.

[rfmerrill]

I tried with another random CD that has 22 tracks and I got 86, so it does seem to just be adding 64.

[ChillyWillyGuru]

Found the bug. Thank you for the work you did on finding that 64 - that made it easy to find the issue. It's been in the code for some time now... since the time we added support for MegaSD fake CD track playing. That 64 is a flag that says we have a real SCD and it initialized just fine.

[rfmerrill]

@ChillyWillyGuru It's a rare edge case, but what happens if a CD actually does have >=64 tracks? I know of at least one commercially pressed CD that has 99 (Fat Wreck Chords' "Short Music For Short People").

Of course there's not necessarily a reason for D32XR to actually support that, but the error handling should ideally be graceful :)

[rfmerrill]

Earlier I tested this patch and confirmed it fixed the bug:

diff --git a/marshw.c b/marshw.c
index 6f6de23..9048ebe 100644
--- a/marshw.c
+++ b/marshw.c
@@ -305,7 +305,9 @@ void Mars_UpdateCD(void)
        MARS_SYS_COMM0 = 0x0600;
        while (MARS_SYS_COMM0);
        mars_cd_ok = MARS_SYS_COMM2;
-       mars_num_cd_tracks = mars_cd_ok >> 2;
+       // XXX FIXME: unsure how this ends up with bit 6
+       //            erroneously set somehow.
+       mars_num_cd_tracks = (mars_cd_ok >> 2) & 0x3F;
        mars_cd_ok = mars_cd_ok & 0x3;
 }

[rfmerrill]

@ChillyWillyGuru OK I think I see the issue. For my own education, can you tell me if I'm right?

• InitCD returns 1 if it succeds, which sets cd_ok to 0x0001
• If read_cdstate sees a disk present, it does move.b #1, cd_ok which (since we're on a big-endian CPU) sets cd_ok to 0x0101
• The result delivered to the SH-1 is (num_tracks << 2) | cd_ok and the SH-1 expects to see cd_ok in bits 0 and 1, not 0 and 8. This is the part where there's a mixup.

[viciious]

When we return the cdstate, we do this:

        move.w  number_tracks,d0
        lsl.l   #2,d0
        or.w    cd_ok,d0
        move.w  d0,0xA15122
        move.w  #0,0xA15120         /* done */
        bra     main_loop

The lsl.l #2,d0 makes space for the cd ok bits. b1-0 = 01 = real CD ok. b1-0 = 11 = fake CD ok. That's fine. However, we're oring the WORD of cd_ok to d0, and the upper byte of that word is set to 1 if there is a cd attached that initialized fine. Hence the 64 - that's the cd working flag that wasn't cleared from the returned cdstate when setting the number tracks on the sh2 side. Also hence a max of 63 tracks with this current code.

[rfmerrill]

Thanks for the clarification!

So if I'm reading this right, the 1 in the upper byte tells us if a disc is physically present and ready in the CD player. This might be redundant information to the SH-1, since it should be able to tell that state from the number of tracks (which will be zero if there's no disc). Did I get that?

[viciious]

Fixed in 84f12290f43c4aa6dc4794c8c1c7fbd788747afd and 388c335d64de47fcad221f3f84b16db8e6ee7857