?
  1. Yes

    96.0%
  2. No

    4.0%
  3. *snooooore*

    0 vote(s)
    0.0%
  1. TheStoneBanana

    OP TheStoneBanana GBAtemp Fan
    Member

    Joined:
    Aug 19, 2015
    Messages:
    496
    Country:
    United States
    Hello! :D

    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_7AE0DC
    
    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).

    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
    ...
    
    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.
    ¦ 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??

    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.
    Now then, that said, there's probably a few confusing things mentioned which should be expanded upon...
    • 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.
    And that's about all there is to it!

    If anybody else finds something out about this emulator which is not documented here, I will be glad to include it. :)
     
    Last edited by TheStoneBanana, Jun 30, 2017
  2. CeeDee

    CeeDee Oh, fishsticks. I'm nauseous...
    Member

    Joined:
    May 4, 2014
    Messages:
    4,501
    Country:
    United States
    Nice work! I'd love to see some more 3D games, or perhaps a multiROM gigadrive emulator.

    Edit: Maybe the 3D Classics Kirby's Adventure is a similar 3D emulator too? Unlike the others it seems like it's just a straight port of the original NES ROM.
     
    Last edited by CeeDee, Jun 28, 2017
    Yepi69 likes this.
  3. Yepi69

    Yepi69 Jill-sandwiched
    Member

    Joined:
    Nov 29, 2010
    Messages:
    2,854
    Country:
    Portugal
    Same here, I don't know why but the 3D effect made me appreciate the games more on my 3DS rather than on my PS3.
     
    CeeDee likes this.
  4. TheStoneBanana

    OP TheStoneBanana GBAtemp Fan
    Member

    Joined:
    Aug 19, 2015
    Messages:
    496
    Country:
    United States
    The multiROM emulator would be difficult due to the patches using hardcoded addresses, but it's not impossible. I'm sure some homebrew could be made to do it or something.
    In terms of more 3D games, that's the end-goal. Since I and @Ralakimus are both primarily Sonic hackers, getting 3D Sonic hacks working is the first goal. Then, hopefully, beyond. :D

    That sounds plausible, and honestly, it wouldn't surprise me. Maybe I can check that out next after this is all done.
     
    matt! and CeeDee like this.
  5. CeeDee

    CeeDee Oh, fishsticks. I'm nauseous...
    Member

    Joined:
    May 4, 2014
    Messages:
    4,501
    Country:
    United States
    I wouldn't mind the 3D part being omitted - I just want a good Mega Drive emulator on 3DS. Retroarch is okay, but I'd like something cleaner and built for 3DS.


    That'd be great!
    Kirby seems to be the classic with the least changes, whereas the others seem quite revamped (Urban Champion, for instance) so I bet it's the same emulator with 3D deal.
     
  6. TheStoneBanana

    OP TheStoneBanana GBAtemp Fan
    Member

    Joined:
    Aug 19, 2015
    Messages:
    496
    Country:
    United States
    Information pertaining on how to use 3D has finally been added to the OP. The research needed for this was just wrapped up yesterday! :D
    If ya don't feel like scrolling up, everything you need to know is here:
    For now, unless there's something that was missed, I'm going to consider research on this emulator completed.
    If you have any questions about usage, I'll be glad to try to answer them the best I can.
     
  7. Billy Acuña

    Billy Acuña GBAtemp Psycho!
    Member

    Joined:
    Oct 10, 2015
    Messages:
    3,000
    Country:
    Mexico
    @bubble2k16
    You probably want to take a look on this one :)
     
  8. Category

    Category Trainee Romhacker
    Member

    Joined:
    Jan 29, 2008
    Messages:
    249
    Country:
    Nice work! Could your injector be made to work with other ROMs?

    I imagine this would perform better than the RetroArch "injector" I've seen around

    — Posts automatically merged - Please don't double post! —
     
  9. matt!

    matt! GBAtemp Fan
    Member

    Joined:
    Nov 20, 2009
    Messages:
    467
    Country:
    I'd love to add 3D support to my favourite Mega Drive golf games (New 3D Golf Simulation: series).

    This would mean different depths for the player, all scenery sprites, and the HUD/menu. Then depth for each scan line of the ground bitmap. Hopefully the scenery sprites are not drawn as part of the ground.

    Will keep watching for progress! Good luck.
     
    Last edited by matt!, Dec 27, 2018
Loading...

Hide similar threads Similar threads with keywords - [Research], Gigadrive, Emulator