Sonic and Sega Retro Message Board: 3D Sonic the Hedgehog (1 & 2) for the 3DS Hacking and Discussion - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Page 1 of 1
    Locked
    Locked Forum

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

#1 User is offline Ralakimus 

Posted 04 June 2017 - 04:12 AM

  • Posts: 273
  • Joined: 16-April 13
  • Gender:Male
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.
This post has been edited by Ralakimus: 04 June 2017 - 03:52 PM

#2 User is offline Ralakimus 

Posted 04 June 2017 - 05:05 PM

  • Posts: 273
  • Joined: 16-April 13
  • Gender:Male
Post from TheStoneBanana on SSRG (I have his permission to post what he posts there here)

TheStoneBanana said:

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.
This post has been edited by Ralakimus: 18 June 2017 - 12:16 AM

#3 User is offline Ralakimus 

Posted 04 June 2017 - 10:34 PM

  • Posts: 273
  • Joined: 16-April 13
  • Gender:Male

TheStoneBanana said:

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.

This post has been edited by Ralakimus: 18 June 2017 - 12:16 AM

#4 User is offline Ralakimus 

Posted 17 June 2017 - 05:51 PM

  • Posts: 273
  • Joined: 16-April 13
  • Gender:Male

TheStoneBanana said:

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:
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:
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! :D

This post has been edited by Ralakimus: 18 June 2017 - 12:17 AM

#5 User is offline biggestsonicfan 

Posted 17 June 2017 - 10:57 PM

  • Model2wannaB
  • Posts: 688
  • Joined: 09-May 07
  • Gender:Male
  • Project:Formerly Sonic the Fighters

View PostRalakimus, on 17 June 2017 - 05:51 PM, said:

Quote

...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! :D



Well, similar to the corrupted save state hex editor for Super Mario World for SNES, could a Sonic 1 hack be made to poke and prod the memory addresses associated with Sonic 1's 3D rendered elements? That hack could then be run within the emulator I suppose...

#6 User is offline Ralakimus 

Posted 18 June 2017 - 12:12 AM

  • Posts: 273
  • Joined: 16-April 13
  • Gender:Male
We'll see what TheStoneBanana and I can do about that...

On an unrelated note...

TheStoneBanana said:

MarkeyJester said:

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. :)/>/>

This post has been edited by Ralakimus: 18 June 2017 - 02:11 AM

#7 User is offline Ralakimus 

Posted 05 September 2017 - 06:24 PM

  • Posts: 273
  • Joined: 16-April 13
  • Gender:Male
I just realized I completely forgot to post this here. A while back near the end of June, TheStoneBanana gathered a pretty complete memory map for the Gigadrive's extended VDP:

Quote

So... are you guys ready to enter the third dimension? :D
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

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. :)/>/>

This post has been edited by Ralakimus: 05 September 2017 - 06:24 PM

Page 1 of 1
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users