Sonic CD Quirks/Deconstruction

I took a look, and there's a hidden "spin tunnel" tag object there (they typically are used to propel Sonic into a ball a the ends of a tunnel)! It is used to force Sonic into a ball when hitting the spring. This tag object is also quite sensitive, which is why you can get propelled even if you are just *near* the spring. Interestingly, the 2011 remake lacks this object, so the described effects do not occur there.

 

It seems there is some misinformation regarding how to access this screen on only the Sega CD version of Sonic CD. Probably a mix-up with how to access it on the 1996 PC version.



You can only access it from Visual Mode. Lemme explain.

So, first off, the only piece of code that even loads this screen is located after playing the good ending in Visual Mode:



There is no such call in the regular game ending code:



I also checked the ending's program code, and there is absolutely no code that checks any parameters or set up for this screen.

So... how are you supposed to access this screen in the PC version? Get a good ending while your time attack records hits a certain threshold. The ending program doesn't even have any references to save data.

The only time the screen itself references save data is for determining which player in time attack mode has the overall best placings, using a points system, where 3rd place gets you 1 point, 2nd place gets you 2, and 1st place gets you 3:




The best player initials are what get displayed in the center of the screen.

While researching this, I found a weird quirk. In the Japanese and European versions of Sonic CD, the Sega logo after the credits and the quoted screen did not have any timers to automatically exit after a certain amount of time. That was added in the US version.

Sega logo after credits:





"Thank You" screen:

 

I just want to say that if you feel like there's a correction that should be made, then don't be afraid to reach out! The purpose isn't to purposely spread misinformation, but mistakes can happen. Corrections can always be made.

 

Here's a silly thing I just realized, and I think I figured out why the STM files for the FMVs were placed towards the top of the file name table.

So, there's this function that is designed to grab a file name based on an index ID:

Code (ASM):

1.         mulu.w  #FILE_NAME_SIZE+1,d0                            ; Get file name pointer
2.         lea     SpxFileNameTable,a0
3.         adda.w  d0,a0
4.         rts

But, there's one problem: not every file name in the table is "FILE_NAME_SIZE+1" bytes long:



It begins to deviate starting with "GOODEND.STM". Speaking of STMs, note how all the STM files are grouped here towards the top, ending with that "GOODEND.STM". It makes me wonder if they encountered this issue and simply moved the STM files up towards the top in order for the FMV Sub CPU programs to be able to use that function.

 

If anyone cares, there's a Bluesky account for this stuff, alongside code and data breakdowns from other classic Sonic titles, including the remakes.

 

Visual demonstration:

 

A brief breakdown of how the peelout and spindash are charged up in the original Sega CD version of Sonic CD. This is basically why the peelout feels faster than the spindash. Despite the same max charge speed, the peelout has a faster charge rate and charge time.

 

A breakdown of the differences in the peelout and spindash between the original and 2011 remake.

 

There is a function specifically made for Palmtree Panic where it checks if Sonic is in a tunnel and passes through a waterfall chunk, and if he is, then it spawns the splash objects. The code that checks which chunk Sonic is passing through (via it's ID) is pretty standard, except that they seem to have accidentally leftover a line that's usually used for calculating the direct address of a chunk's data, but here, it doesn't have any real purpose and effectively does nothing with how this function is used:

Code (ASM):

1. GetMapChunkId:
2.         move.w  d2,d0                   ; Get map layout Y offset
3.         lsr.w   #1,d0
4.         andi.w  #$380,d0
5.         move.w  d3,d1                   ; Get map layout X offset
6.         lsr.w   #8,d1
7.         andi.w  #$7F,d1
8.         add.w   d1,d0                   ; Combine map offsets
9.         move.l  #MapChunks,d1           ; Useless leftover line (0x210000)
10.         lea     map_layout,a1           ; Get chunk at map offset
11.         move.b  (a1,d0.w),d1
12.         andi.b  #$7F,d1                 ; Mask out loop flag
13.         rts

Code (ASM):

1.         bsr.w   GetMapChunkId           ; Get chunk Sonic is passing through
2.         cmpi.b  #$2F,d1                 ; Is it a waterfall?
3.         bne.s   .NotWaterfall           ; If not, branch

Interestingly, the 90's C port actually retains the useless "MapChunks" line, even using the same exact address value that was assigned in the original Sega CD version:

Code (C):

1. unsigned int mapno_chk(short d2, short d3)
2. {
3.     unsigned int d1;
4.     d1 = 0x210000;                      /* The same useless leftover line! */
5.     d1 += mapwka[d2 >> 8][d3 >> 8];
6.     return d1;
7. }

 

Yeah, so, the way the address to direct chunk data is calculated in the original 68000 code is that it takes the base address of the chunk data (0x210000 in Sonic CD, 0xFF0000 in the regular Genesis games), and because the lower word of the base chunk data address is DELIBERATELY ALWAYS 0, it uses that space to calculate the offset within the chunk data, which is done by storing the chunk ID, multiplying it by 0x200 (the size of a 256x256 chunk in bytes, it's 0x80 for 128x128 chunks), and then any offsets in the case of selecting a block at a specific position.

In this case, I have a feeling that they might have copied and pasted some code related to picking out a block for drawing/collision purposes, but just cut out the code after the chunk ID is retrieved, and also forgot to remove that line. Oops!

 

Yeah, the MCD's graphical operations output data to be uploaded to VRAM, and that also includes the 1M/1M mode, where a Word RAM bank mirror can be used as a canvas for easier software rendering. Regardless, it's still the MCD side that is generating the graphics data, so you can still say that the MCD renders graphics, it just doesn't have a dedicated video output like the 32X does, so it has to be transferred over to the MD's VDP for it to actually be displayed.