(WIP) Sonic CD disassembly

Status
Not open for further replies.
After bashing my head and having several drinks, I have a decent-ish split of the level code, and got R11B (Palmtree Panic Act 1 Past) disassembled and buildable, with SonLVL support. It has been pushed into the repository.

Honestly, don't be expecting this to be the most "hack friendly" thing, due to the nature of how the original source code was assembled (tl;dr they copy and pasted a bunch of files per level, and there are weird minute differences between each copy). I am trying my best to make it manageable, and even incorporating things like SonLVL support, but I have my limitations.
 
Last edited:
It calls a function in the main level V-INT routine that's located towards where the chunks and PLC list is at. You should recognize it from the DMA commands being sent. MMZ2 Present in the USA version has it located at 0x20F8B2.
 
thanks i found it in IDA pro i think mine is the jap one because i found it in like 15 lines from where you said it is anyways figured that out ...
 

Attachments

  • IDA - R82A__.MMD.idb (R82A__.MMD) C__Users_lavag_OneDrive_Desktop_CdTidalTempist_LavaCdWork-TT...png
    IDA - R82A__.MMD.idb (R82A__.MMD) C__Users_lavag_OneDrive_Desktop_CdTidalTempist_LavaCdWork-TT...png
    126.2 KB · Views: 3
Last edited:
So, how about some specifications for the special stage maps (possibly to use for making a tool)?
  • The map itself is just a standard 4096x4096px Sega CD stamp map, with 32x32 stamps. Stamp data and stamp map data are compressed in Kosinski.
    • Stamps are basically just Genesis tiles, arranged vertically, exactly like how tiles are arranged for sprites.
    • Boo0Fqp.png

    • Stamp IDs are the address relative to Word RAM divided by 0x80, making 32x32 stamp IDs multiples of 4 only (remember, 16x16 stamps are also a thing on the Sega CD).
    • Stamp maps then are 128x128 stamps in size. Each stamp ID is a word.
      • HRR0 0SSS SSSS SSSS
        • S = Stamp ID (last 2 bits are actually ignored with 32x32 stamps, again, multiples of 4 only)
        • R = Rotation (00 = 0deg, 01 = 90deg, 10 = 180deg, 11 = 270deg)
        • H = Horizontal flip (done after rotation)
        • [IMG]
  • Stamps are loaded 0x200 bytes into Word RAM, making the first stamp always blank (the stamp bank address is always fixed at the start of Word RAM, by the way).
    • Stage 3 has a secondary set of stamps loaded 0x10000 bytes into Word RAM.
  • Each stamp is assigned a type via a separate array of byte sized IDs (like how each 16x16 in regular stages gets a collision block ID via its own separate array).
    • 0 = Path
    • 1 = Bumper
    • 2 = Fan
    • 3 = Water
    • 4 = Rough surface
    • 5 = Spring
    • 6 = Hazard
    • 7 = Big boost pad
    • 8 = Small boost pad
    • 9 = Oil (Yes, the unused oil stamps have this. No, it doesn't do anything)
  • Stamp animations are handled in its own routine with its own stage specific data
    • 2 animations types: hazard and fan
    • Animation data is an array of stamp IDs to place in various locations in the stage
      • Each entry starts off with a word value indicating the raw offset in the stamp map to write the stamp ID. It's then followed with the stamp IDs used in the animation.
      • Hazard animations have 4 frames, and fan animations have 3.
  • Object positions on the map are 16.16 fixed point.
  • Each UFO has their own path data to follow. No, they do not actively dodge the player, they stay strictly on the path.
    • First byte is the UFO item type
      • 0 = Rings
      • 1 = Speed shoes
      • 2 = Time (Only valid for the time UFO, which is actually a separate object. Regular UFOs will just give you rings)
      • 3 = Hand (Unused, just gives you rings)
    • Second byte is some unknown, unused flag.
    • Each path node contains 5 words:
      • First word is how many frames it takes to move to the next node. Basically, its speed.
      • Second and third words are the node's starting X and Y positions respectively. When a UFO starts on a node, it automatically snaps to this position.
      • Fourth and fifth words are the node's target X and Y positions respectively. It'll move towards this position at within the time specified.
    • Data is terminated with a single 0xFFFF.
  • Time UFO has its own path data that's shared between every stage.
  • A quick fun fact: regular UFOs are always purple and the vertical stripes on them change color depending on the item they have (yellow for rings, white for speed shoes). The time UFO is always blue.
Data in the disassembly can be referenced, of course.
 
Last edited:
Update:
  • Every PCM driver is now disassembled with their data extracted. Music and SFX in ASM format.
  • Began some cleanup and further documentation that I left untouched forever.
 
Status
Not open for further replies.
Back
Top