3D Sonic the Hedgehog (1 & 2) for the 3DS Hacking and Discussion

3D Sonic the Hedgehog for the 3DS doesn't use ROM patches to apply changes...

Instead, what it does, is that it checks for certain conditions, and when appropriate, it will override the emulator, run its own code, then give back control to the emulator. No ROM modifications are made.

For example, it will check if Sonic is spindashing, and when the 68000 gets to LoadSonicDynPLC, it will stop the 68000, transfer the appropriate spindash art (depending on which frame it is), then set the 68000's PC to the end of LoadSonicDynPLC, and then let the 68000 run again. (You can see that here)

There are many more routines in the ARM code like this. All the extra VDP stuff used to do the 3D effects are done with this method as well.

But hey, this is one step closer to figuring out the extra VDP features. You would just need to look in the ARM code in ExeFS (base address is 0x100000). Luckily, finding references to 68000 memory is rather easy, as it's all basically how it would look on the MD (i.e. you will be able to see things like 0xFFFE10 and 0xFFC800 referenced in the ARM code and it would be referencing to MD's RAM). The extra VDP stuff is mapped after the standard VDP addresses, so in the $C00000-$DFFFFF area.

 

In a search for what authenticates the ROM and allows for 3D privileges (if you didn't know already, the 3D itself isnt "patched" in until the ROM is authenticated and assured to be correct), Ralakimus and I made an interesting discovery.

Essentially, similarly to how patches work, the emulator takes over during the initialization routine of the ROM... and does it all itself!
Pretty much the entire stock Mega Drive initialization routine is recreated and handled by the emulator itself. Why they did this, we aren't exactly sure. The main theory right now is that it was for speed purposes, seeing as how it does nothing out of the ordinary as far as we can tell.

More to come soon when we finally crack authentication.

 

It should be noted that this was tested with Sonic 2, but not Sonic 1.

 

So how possible would it be for 3D Knuckles' Emerald Hunt, assuming authentication is solved (also 3D Knuckles in Sonic 2)?

 

Once authentication is solved, the 3D stuff is next (at least for me) to figure out. It SHOULD be possible to do from the ROM, since all the ARM does is read and write data in the $C00000 to $DFFFFF range, so I assume that you can do the same from the 68000.

 

Considering how wrong we were before, I feel an update is needed here. The ROM authentication hasn't been cracked yet, but we learned more about the recreated boot routine.

It is not alone.
The emulator actually recreates many parts of the game (there's around 4,000 entries in it's equivalency table) to it's liking, some modified, presumably for the purposes of 3D or otherwise. I can't help but feel this is slightly ridiculous, as some of the ports such as the security routine are unchanged, but whatever. There isn't much we can do about it right now, and it's the mess we have to work with. Essentially, this is part 3DS port, part emulation.
That's why it requires the authentication, and that's why the authentication itself is so picky with what it runs the """patches""", or as we learned now, the ported routines, on.

For REAL this time, more updates will come when the authentication has been cracked.

 

Note: I replaced a Sonic 1 ROM with a customized Sonic 1 ROM that already had SpinDash included, and the 3D effect was still present and fully operational.

 

Do you still have this ROM? If so, we would be interested in having it for analysis of ROM authentication.
No exact routine has been located, but it's been narrowed down to at least the checksum, checksum routine, and size of the file.

 

I wonder if it's checking something vague like a checksum or a file size.
That said, check PM in a minute and I'll have it.

Just keep in mind:

..and so the process to verify the ROM is likely to be much less sophisticated than the later emulator.

 

It should be noted that with the MDF compression, you MUST compress it as Sonic1.SGD or whatever the name was in XXXXX.m, or it WON'T decompress, as the filename helps determine how it's compressed.

 

Let's talk ROM authentication, shall we?

Firstly, somewhat of a checksum is calculated. The routine for doing so, extracted from Sonic 2 3D, is here:

Code:

loc_7AE0DC                              ; CODE XREF: ROM:007AE0F8j
      ADD     R1, R0, R3,LSL#2
      SUBS    R2, R2, #1
      LDR     R8, [R1]
      LDR     R1, [R1,#4]
      ADD     R3, R3, #2
      ADD     R6, R6, R8,ROR#16
      ADD     R12, R12, R1,ROR#16
      BNE     loc_7AE0DC

It slightly differs in terms of register usage in Sonic 1 3D, but it's purpose is the same.
Basically, there are actually two checksums calculated, one for every other longword. To simplify it a bit more, the first longword is read and added to Checksum #1, then the longword afterwards is read and added to Checksum #2. This continues until the entire ROM has been covered.
Then, once this is complete, Checksum #2 is added to Checksum #1 to create a final, complete checksum.

From here, all that's left to do is make sure that the checksum is valid. The routine for doing so, once again extracted from Sonic 2 3D, is here:

Code:

loc_794C68                              ; CODE XREF: sub_794C54+34j
      LDR     R0, [R2]
      LDR     R12, [R0,#0x10]
      CMP     R12, R1
      LDREQ   R12, [R0,#0xC]
      CMPEQ   R12, R3
...

Once again, this slightly differs from Sonic 1 3D, but it's purpose is exactly the same.
It fetches the stored checksum from inside of the code, and compares it to the calculated checksum from earlier. If it matches, it will simply return to whatever routine called the comparison beforehand. Otherwise, it does some stuff to presumably indicate that the ROM is not the wanted game, and returns.

Thankfully for us, this security measure is extremely easy and straightforward to bypass. There are many ways of approaching getting around it, but I personally just created a patch which forces the correct checksum to be calculated no matter what. It works perfectly fine as expected, and will boot any ROM you throw at it with the custom """patches"""!

...However, this does not mean you can actually play the ROMs in 3D just yet. How the extended VDP functions still needs to be researched, and we need to actually write new patches for whatever games should be played in 3D.
This is still one giant leap, though!

 

I think you guys have been mislead.

These are not security measure systems, they are data error detection systems. The purpose of a checksum is to ensure the data that was transmitted (either through networks or onto cartridges) was done successfully. During manufacturing of cartridges for example, each cartridge will be plugged in and tested for errors to ensure the data was transfered properly, and that there isn't a mistake that would not be noticed until "level 10" or whatever for example.

Other than that though, well done guys! You are providing some shining examples of hacking~

Might I recommend though, finding a way of applying new checksums with the new ROMs rather than trying to bypass it?

 

This was taken into consideration, and I wrote a small tool in C to do the job which has been attatched to this post.
It supports both Sonic 1 3D and Sonic 2 3D.

At this point, we have enough now to play very VERY basic Sonic 1 or 2 hacks in 3D. Due to the reliance on hardcoded addresses within the games """patches""", there can't be too much change from the original game besides art, palettes, and maybe layouts. The first custom hack I got working was a red recolor of Sonic in Sonic 2, so I guess @redhotsonic gets the (technical) honors of starring in the first fully 3D hack.

 

So... are you guys ready to enter the third dimension?
In these past few days, the final work needed to document this stuff was completed by @Novedicus and I, with the bulk of work being done last night and this morning.

Without further ado, just take a look at this extended VDP register map!

Spoiler: Complete Map of Extended VDP Registers

$C00130 = Layers from the Stock MD to not display
- 0000 0BC0
- B = Disable the Display of Plane B (regular MD), C = Disable the Display of Plane A (regular MD)

$C00132 = Layers from the Gigadrive to display
- 0000 ABCD
- A = Plane B (duplicated) , B = Plane 3, C = Plane 2, D = Plane 1

$C00134 = Base VRAM Address of Sprite Depth Array

$C00138 - $C0013E = Unused (?)

$C00140 = Not sure how it works, but it's what sets horizontal and vertical scrolling for the plane. Standard value is $08.
$C00142 = Depth of Plane 1
$C00146 = Base VRAM Address of Plane 1 (Trees in front of Sonic are on this layer in 3D S1)
- What goes here is the base VRAM address divided by $1000.

$C00148 = Same explanation as $C00140
$C0014A = Depth of Plane 2
$C0014E = Base VRAM Address of Plane 2 (Most Level elements are on this layer in 3D S1)
- Same explanation as Plane 1's register.

$C00150 = Same explanation as $C00140
$C00152 = Depth of Plane 3
$C00156 = Base VRAM Address of Plane 3 (GHZ Totems, Flowers, and Trees behind Sonic are on this layer in 3D S1)
- Same explanation as Plane 1's register.

$C00158-$C0015C = Base VRAM Address of Plane B Depth Array
- What goes in these registers is just the base VRAM address divided by $10.

$C0015E = Base VRAM Address of Plane B Duplication
- Same explanation as Plane 1's register.

Now then, there's a couple of terms to expand upon, and things to explain.

• Each register listed above is a word long, with the value being contained in the lower-byte.
• The VRAM addresses referred to in the registers are the raw addresses, not the addresses mapped to RAM as detailed in M2's extended VDP read out. For example, you would use $XXXXX, not $DXXXXX. When referencing these addresses from ROM, you DO use the $DXXXXX addresses.
  
• The "Sprite Depth Array", quite simply, is just an array of the depths of all sprites on screen, in the order of the Sprite Attribute Table. Pretty simple, eh?
• Each new plane's depth is a signed byte value. The higher the value, the deeper into the screen the plane will appear.
• The "Plane B Depth Array" is an array of depths for each scanline of the background layer. Each scanline depth is a word long, unsigned. The higher the value, the deeper into the screen the plane will appear.
• All six planes (the two stock MD planes, as well as the added Gigadrive ones) can be displayed at once! However, the stock MD planes will have no depth, and performance is a little slow without the aid of ""patches"".
• All of the listed above can be interfaced from stock ROMs with no need for authentication as previously thought. However, once again, performance may be a little slow depending on usage of the effects.

...aaaaaaaand that's about it!
Hopefully y'all make good use out of the beast that is the Gigadrive.