Hello! 
In May 2013, the development studio M2 unveiled and released 3D "remasterizations" of classic SEGA games under the 'SEGA 3D Classics' line. As explained in an interview given for 3D Sonic the Hedgehog, an entirely new (albiet virtual) system was created to run these games in 3D, dubbed the SEGA Gigadrive. I have a love for working with both the Megadrive and 3DS, so this specialized emulator was like a match made in heaven for me.
Out of personal interest, I, as well as my good friend @Ralakimus, have been slowly researching the inner workings of this thing and making sense of it for eventual hacking usage. I figure you guys here might have somewhat of an interest in our efforts.
ROM Verification
To begin with, before anything is done, the Gigadrive verifies the ROM. You see, for each 3D game, there are "patches" to enhance them to be in 3D. No modification is done to the ROM binary itself. Because of this, the ROM has to be checked to be the correct one before allowing any "patches" to be used. This is why, in user-made injections, games will work but will have no 3D capabilities.
The routine above is taken from 3D Sonic the Hedgehog 2, but is identical in the other 3D Classic releases.
Basically, there are 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. The two checksums are then combined, forming one large (and final) checksum.
A tool to generate a checksum like this for a custom ROM has been provided here. However, at the moment, it only supports injection for 3D Sonic 1 and 2 (as Sonic hacking is my main area of expertise).
The routine above, once again, is extracted from 3D Sonic the Hedgehog 2. It's still identical to other 3D Classic releases though.
All it does is compare the calculated checksum from the code to a stored checksum. If the generated checksum matches the stored checksum, the ROM is just regularly passed through and is given the OK to use "patches". However, if it does not match, some stuff is done presumably to tell the emulator not to use the custom "patches".
"Patches"
You may have noticed that I keep referring to the "patches" with quotation marks. This is because they are actually not patches to the ROM itself, and a better name for them hasn't really been thought of. :Y
Inside of the code there is a giant table of "equivalencies", as I like to call them. There is a hardcoded address of 68k code in the ROM, and then an address of code in the emulator to jump to. During run time, if the ROM is permitted to use custom patches, it will use the 68k program counter to grab the correct equivalency and jump to the right ARM code (I'm not sure exactly how this works, but I know for a fact it does occur thanks to debugging with GDB). The emulator in essence overrides 68k execution with its own code, and when that is done, it hands off control back to the 68k as if nothing happened. It's pretty straightforward, and there are tons of equivalencies like this for the entire game.
To quote Naoki Horii, president of M2:
3D Implementation
The Gigadrive, interestingly enough, maps some parts of the VDP to the system's RAM.
This is important to work with the 3D features, as the game must use the included Extended VDP registers mapped here. Below is a complete map of these registers, which can be set from the stock ROM or from the previously mentioned ARM "patches".
Now then, that said, there's probably a few confusing things mentioned which should be expanded upon...
If anybody else finds something out about this emulator which is not documented here, I will be glad to include it.
In May 2013, the development studio M2 unveiled and released 3D "remasterizations" of classic SEGA games under the 'SEGA 3D Classics' line. As explained in an interview given for 3D Sonic the Hedgehog, an entirely new (albiet virtual) system was created to run these games in 3D, dubbed the SEGA Gigadrive. I have a love for working with both the Megadrive and 3DS, so this specialized emulator was like a match made in heaven for me.
Out of personal interest, I, as well as my good friend @Ralakimus, have been slowly researching the inner workings of this thing and making sense of it for eventual hacking usage. I figure you guys here might have somewhat of an interest in our efforts.
ROM Verification
To begin with, before anything is done, the Gigadrive verifies the ROM. You see, for each 3D game, there are "patches" to enhance them to be in 3D. No modification is done to the ROM binary itself. Because of this, the ROM has to be checked to be the correct one before allowing any "patches" to be used. This is why, in user-made injections, games will work but will have no 3D capabilities.
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_7AE0DCBasically, there are 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. The two checksums are then combined, forming one large (and final) checksum.
A tool to generate a checksum like this for a custom ROM has been provided here. However, at the moment, it only supports injection for 3D Sonic 1 and 2 (as Sonic hacking is my main area of expertise).
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
...All it does is compare the calculated checksum from the code to a stored checksum. If the generated checksum matches the stored checksum, the ROM is just regularly passed through and is given the OK to use "patches". However, if it does not match, some stuff is done presumably to tell the emulator not to use the custom "patches".
"Patches"
You may have noticed that I keep referring to the "patches" with quotation marks. This is because they are actually not patches to the ROM itself, and a better name for them hasn't really been thought of. :Y
Inside of the code there is a giant table of "equivalencies", as I like to call them. There is a hardcoded address of 68k code in the ROM, and then an address of code in the emulator to jump to. During run time, if the ROM is permitted to use custom patches, it will use the 68k program counter to grab the correct equivalency and jump to the right ARM code (I'm not sure exactly how this works, but I know for a fact it does occur thanks to debugging with GDB). The emulator in essence overrides 68k execution with its own code, and when that is done, it hands off control back to the 68k as if nothing happened. It's pretty straightforward, and there are tons of equivalencies like this for the entire game.
To quote Naoki Horii, president of M2:
Naoki Horii said:
3D Implementation
The Gigadrive, interestingly enough, maps some parts of the VDP to the system's RAM.
¦ The GigaDrive supports backward compatibility with MegaDrive games (Unmodified MDROMs will run normally without modification)
·Expanded VDP register for controlling expanded functionality included
·Expanded VRAM included
·Four extra background layers included
·Z-values can be set for each extra background or raster line
·Every sprite has a Z-value setting.
·VDP and Expanded VDP registers are memory-mapped and accessible
·VRAM and Expanded VRAM are memory-mapped and accessible
Memory Map:
* $c00000 r/w VDP DATA
* $c00002 r/w VDP DATA
* $c00004 r/w VDP STATUS(read)/CTRL(write)
* $c00006 r/w VDP STATUS(read)/CTRL(write)
* $c00100-$c0012f -/w VDP REGS(write only)
* $c00130-$c0015f -/w EXT VDP REGS(write only)
* $c00200-$c0024f r/w VSRAM
* $c00300-$c0030f r/w DIPSW
* $d00000-$d0ffff r/w 64KB VRAM
* $d10000-$d1ffff r/w 64KB EXT VRAM
??Detailed I/O Map spec omitted??
·Expanded VDP register for controlling expanded functionality included
·Expanded VRAM included
·Four extra background layers included
·Z-values can be set for each extra background or raster line
·Every sprite has a Z-value setting.
·VDP and Expanded VDP registers are memory-mapped and accessible
·VRAM and Expanded VRAM are memory-mapped and accessible
Memory Map:
* $c00000 r/w VDP DATA
* $c00002 r/w VDP DATA
* $c00004 r/w VDP STATUS(read)/CTRL(write)
* $c00006 r/w VDP STATUS(read)/CTRL(write)
* $c00100-$c0012f -/w VDP REGS(write only)
* $c00130-$c0015f -/w EXT VDP REGS(write only)
* $c00200-$c0024f r/w VSRAM
* $c00300-$c0030f r/w DIPSW
* $d00000-$d0ffff r/w 64KB VRAM
* $d10000-$d1ffff r/w 64KB EXT VRAM
??Detailed I/O Map spec omitted??
This is important to work with the 3D features, as the game must use the included Extended VDP registers mapped here. Below is a complete map of these registers, which can be set from the stock ROM or from the previously mentioned ARM "patches".
$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.
- 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.
- 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.
If anybody else finds something out about this emulator which is not documented here, I will be glad to include it.
Last edited by Deleted member 370283,
