Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
TheLoneSurvivor

Groundbreaking Doom SNES hacking knowledge. (+Original tools used to make doom SNES?)

Recommended Posts

Hello. You may be wondering who I am.

I am a relatively new ROM hacker, I started ROM hacking in late 2014. I had only started Doom ROM Hacking around 1 and a half months ago, I had not started with doom. However. In this time I have achieved things on the legendary status of ROM hacking. I had hacked the Doom SNES sounds, text, and most importantly graphics. I also found the music data. I am only a teenager and I have done this all.

But let us begin with my documentation and IPS patches for the ROM.

How did I do this?

The sounds and text were the easiest. I used a tool called SNESSor and I was able to successfully replace the BRR samples (Bit Rate Reduction, which is an ADPCM format which compresses every 32 bytes of sound data to 9 bytes, while still sounding clear.) The text was a matter of replacing text with a hex editor (HxD is my personal choice of hex editor)

The graphics took me about 2 weeks to find. I used a tool called Tile Molester, and the reason it took so long is I had no access to a computer for a while so I was using DOS tools on my android tablet. And when I did get my computer problems fixed, I had then used Tile Molester, and after screwing around with the bitplanes I had successfully found the textures. I only edited the Knee Deep in the Dead skybox texture, because the other textures had dots all over them and appeared to be using RLE (Run Length Encoding) like the Wolf3D SNES sprites, but the Skybox was perfectly clear, and just had to be rotated. Due to the different way the skybox works in the SNES version than the PC version the Doom 2 skybox texture I used did not connect well, due to the sky in the PC version of doom being a cylinder, and the SNES version using a cube shaped skybox, so it does not connect well like in the PC version, but it is what it is. The textures start at hex offset 8000 in the ROM and they use 8bpp linear, and the font graphics are 8bpp also, but use 8bpp planar (I think, I have not looked at the font in a while.) The weapon sprites appear to be using RLE (run length encoding) and they use the 4bpp planar composite codec.

The music data was fairly advanced, yet easy if you know how pointers and general hex works. It was as simple as this. I searched the E1M1 SPC for some 20 CD FF bytes, due to those being the starting bytes of the SPC engine in EVERY standard SPC file. I found them, and from there searched for the first 00 byte after the 20 CD FF, due to 00 being the end byte of a pointer. I found it, then did reverse order on the 2 bytes before the 00, and I opened up the search tab, clicked goto and entered the reversed 2 bytes before the 00 for the end of the pointer in the SPC file but did not enter the 00. I was brought to the hex address 8F10 in my SPC file, and I then selected a big chunk of hex from that address and opened up my Doom SNES ROM, opened up the search tab, pressed find, pasted the block of hex code and I found an exact match. The thing about this is that HxD, if you use find, and there is not an EXACT match of what you search for in the file, it just says "whatever you searched for here not found." So I knew I had found the music data. I even checked the bytes after the chunk of hex I pasted in the SPC file, they were the same as in the ROM.

This concludes this post for now, I will update but here is the IPS file for the skybox texture hack.

https://www.dropbox.com/s/68gizwoau9ut42h/DoomHack.ips?dl=0

How to patch your ROM with the hack.
1. Get Lunar IPS
2. Make sure your Doom ROM is an unmodified USA version ROM (USA version used in all of north america.)
3. Select the unmodified ROM
4. Select the IPS patch
5. Hit apply
6. Open the new ROM you have in an emulator.
7. Look at the sky.

On August 13, 2015, I found something amazing. I was looking for the official SNES SDK and I found and downloaded one. It was a DOS tool and I pressed the help button. Guess what it said? Sculpted Software's SSBUG. Sculpted Software was involved in porting Doom to the SNES. They published Doom SNES (I think they programmed some parts of Doom SNES too, but they are in the credits, hidden in the ROM and are credited elsewhere) Guess what other files there were? Super FX documentation among other documentation on SNES chips and hardware, and also there was an assembler. DOOM SNES development jackpot or what?

Share this post


Link to post

Somebody realized it and tested the rom against existing and proven rom hacking tools ! Praise he who bumped a seven year old thread !

its kind of funny how long it took before somebody did it.

Share this post


Link to post
FireFish said:

Somebody realized it and tested the rom against existing and proven rom hacking tools ! Praise he who bumped a seven year old thread !

its kind of funny how long it took before somebody did it.


Well, it is more then that. It is difficult. You have to make sure you comply with the extreme limitations of the SNES, you have to go through the ROM with every single bitplane, and there is over 20 bitplane codecs in tile molester, and find which bitplanes have what. Then you have to keep note of all of the bitplanes and any graphics they have, if any at all. You then have to import the pallette every time you load the program up, and manually go to the directory with the zsnes save state for the pallette, which is tedious. Then you have maximum graphics size and palettes and loss of colour depth and run length encoding to deal with.

Share this post


Link to post
TheLoneSurvivor said:

Well, it is more then that. It is difficult. You have to make sure you comply with the extreme limitations of the SNES, you have to go through the ROM with every single bitplane, and there is over 20 bitplane codecs in tile molester, and find which bitplanes have what. Then you have to keep note of all of the bitplanes and any graphics they have, if any at all. You then have to import the pallette every time you load the program up, and manually go to the directory with the zsnes save state for the pallette, which is tedious. Then you have maximum graphics size and palettes and loss of colour depth and run length encoding to deal with.


I know how irritating or time consuming it can be. even with all those great tools. Using them often comes down to having the patience to test everything when the locations or formats are not obvious... and taking notes of offsets and whatnot. i would not have the patience anymore, and i cant blame anyone else when they have none either.

Share this post


Link to post

Kickass. I suppose there's never been quite enough interest, but you've taken the initiative and I appreciate it.

I think it'd be fun if there was a modified version of Chocolate Doom with gameplay behavior and outward appearance identical to SNES Doom, yet can run PC data without whatever limits actual SNES Doom may have.

That way, whatever merit the off-brand knockoff gameplay may have can be better utilized. Not that it undermines your reverse engineering efforts, of course!

Share this post


Link to post
Sodaholic said:

Kickass. I suppose there's never been quite enough interest, but you've taken the initiative and I appreciate it.

I think it'd be fun if there was a modified version of Chocolate Doom with gameplay behavior and outward appearance identical to SNES Doom, yet can run PC data without whatever limits actual SNES Doom may have.

That way, whatever merit the off-brand knockoff gameplay may have can be better utilized. Not that it undermines your reverse engineering efforts, of course!


Most polite post I have read on any fourm in a long time. Thank you for being polite

Share this post


Link to post
TheLoneSurvivor said:

Most polite post I have read on any fourm in a long time. Thank you for being polite

Thanks. The SNES version is the first version I played, so I've always had an interest in it and wanted to see something more done with it but never pursued any reverse-engineering efforts.

About the PC-SNES idea: maybe there could be a 30hz mode (actual SNES game runs @ 15hz), hi-res mode (instead of double-width columns) and the ability to actually circle-strafe.

Share this post


Link to post
Sodaholic said:

Thanks. The SNES version is the first version I played, so I've always had an interest in it and wanted to see something more done with it but never pursued any reverse-engineering efforts.

About the PC-SNES idea: maybe there could be a 30hz mode (actual SNES game runs @ 15hz), hi-res mode (instead of double-width columns) and the ability to actually circle-strafe.


No, the Super FX 2 (GSU-2) chip used in Doom runs at a clock speed of 21.7 mhz.
You can get higher FPS in the SNES version of doom on a real console by overclocking the Super FX chip (40mhz runs smoothly) and the benefit is that the Super FX should not overheat anymore than 21.7 mhz according to a starfox overclocking video, which also uses the Super FX. Only problem with overclocking is that when the enemies are standing, you know how they look like they walk in place I am assuming, well when it is overclocked their walking in place looks faster than sonic on meth, and the imp fireballs go faster. You can also use zsnes, which is a good emulator, which I find runs Doom like it was overclocked.
Some other emulators have Super FX overclocking emulation. Just google (snes super fx overclocked emulator)

Hi-res mode would be irrational. Single-width columns may make it look smoother, but it may cause performance issues and glitches, due to the fact they wrote the ASM code to use double width column rendering so this may require a whole render engine rewrite, which is HIGHLY illogical due to our lack of knowledge on how the ROM works, and the sheer amount of time it would take.

Also, about circle strafing. This would, again take time due to our lack of knowledge on the ROM, and would require a considerable reprogram of player controlling. It would also potentially lead to glitches, because for example the hit detection might be screwy, due to the rendering engine potentially not being able to handle rendering while turning and moving, and shooting. The player may also encounter issues such as bad hit detection, due to the fact we would have to make the hitboxes move with the player who is moving in circles at a fast rate. This would lead to game imbalance and potentially going through walls.

Overall, I think that what you are saying is illogical from the viewpoint of a ROM hacker. Please take the time to actually learn how the SNES and the ROM work internally before making suggestions. Not trying to be rude, but seriously though.

Share this post


Link to post

No, I know it'd be quite a piece of work to do that in the actual SNES version. I was talking about a reimplementation of its look and feel in something like Chocolate Doom.

Also, I had no idea about the framerate not being capped at 15hz. I came to that conclusion when counting the number of refreshes frames lasted in an emulator. This was mostly at the start of E2 Refinery that I checked it.

If the gameplay speed is non-deterministic, that really intrigues me. If the game behavior were disassembled, we could learn a lot. Based on your description, I take it they ran it on the SuperFX2 and not the SNES's own CPU?

TheLoneSurvivor said:

You can also use zsnes, which is a good emulator, which I find runs Doom like it was overclocked.

ZSNES actually has a reputation of being quite inaccurate to the real hardware. Fine to just play on, but not suited for development.

Share this post


Link to post
Sodaholic said:

No, I know it'd be quite a piece of work to do that in the actual SNES version. I was talking about a reimplementation of its look and feel in something like Chocolate Doom.

Also, I had no idea about the framerate not being capped at 15hz. I came to that conclusion when counting the number of refreshes frames lasted in an emulator. This was mostly at the start of E2 Refinery that I checked it.

If the gameplay speed is non-deterministic, that really intrigues me. If the game behavior were disassembled, we could learn a lot. Based on your description, I take it they ran it on the SuperFX2 and not the SNES's own CPU?

ZSNES actually has a reputation of being quite inaccurate to the real hardware. Fine to just play on, but not suited for development.


Yes, the Super FX was the only reason Doom could work on the SNES at all. All the rendering is handled on the Super FX, and the Minimap uses Super FX according to the doom wiki, but the minimap appears to actually be using mode 7 graphics

Share this post


Link to post
TheLoneSurvivor said:

Yes, the Super FX was the only reason Doom could work on the SNES at all. All the rendering is handled on the Super FX

I was talking about the gameplay behavior, like player movement, monster line of sight, attacks, etc. I'd think it more sensible to have that on the SNES CPU to save as much time for the SuperFX to do its thing with the 3D rendering.

And of course I know that the SuperFX handled rendering and was what enabled its feasibility at all. Frankly, I feel as though you're not addressing my discussion points and are treating me as clueless. I realize that's probably not your intent, but it's slightly irritating to me to have simple questions answered that I never asked.

TheLoneSurvivor said:

the Minimap uses Super FX according to the doom wiki, but the minimap appears to actually be using mode 7 graphics

It looks like it's tracing lines, to me. I thought Mode 7 only dealt with raster bitmaps, am I wrong about that?

Share this post


Link to post

I found the holy grail of SNES development and debugging. I found the official, yes. OFFICIAL SNES SDK from Nintendo. I am not sure whether or not they actually released it or if it was leaked, but as far as I can tell it is legit. It has documentation on the Super FX also, among other things such as a SNES debugger and assembler. Think about it. The debugger is official and can do disassembly and tracing. It was from nintendo, so it must be the most accurate out there, due to them knowing the most about the SNES (because they made it) I heard that an official SNES SDK was floating around the internet for a while, (before 2007 from what I can tell by my research) so I think I have a legit copy. I will reveal any discoveries I make as soon as I find something useful. If possible, I will release a ROM hack on Christmas as my Doomworld present.

Share this post


Link to post

I remember playing Doom on the SNES, dont even know why i played it on that platform, since i got a PC just to play Doom before. Was the first SNES game i ever saw that didnt have the standard grey cartridge, but red instead. That fact alone was so kickass for me.

But damn it made my eyes hurt (the graphics and fps, not the red cartridge). :D

Anyway, really cool achievement @TheLoneSurvivor.

Share this post


Link to post
TheLoneSurvivor said:

You can also use zsnes, which is a good emulator, which I find runs Doom like it was overclocked.


Zsnes is horrible and you need to kill yourself if you use it in 2015, use Bsnes or higan

Hi-res mode would be irrational. Single-width columns may make it look smoother, but it may cause performance issues and glitches, due to the fact they wrote the ASM code to use double width column rendering so this may require a whole render engine rewrite, which is HIGHLY illogical due to our lack of knowledge on how the ROM works, and the sheer amount of time it would take.

Not irrational. The SuperFX doesn't care what internal resolution you're trying to render at because the screen is always addressed by the Super Nintendo as a tilemap. The SuperFX provides hardware functionality to translate a bitmapped playfield into a tilemapped one; with relatively little modification to the renderer, it's probably completely possible with an overclocked SFX2

Also, about circle strafing. This would, again take time due to our lack of knowledge on the ROM, and would require a considerable reprogram of player controlling. It would also potentially lead to glitches, because for example the hit detection might be screwy, due to the rendering engine potentially not being able to handle rendering while turning and moving, and shooting. The player may also encounter issues such as bad hit detection, due to the fact we would have to make the hitboxes move with the player who is moving in circles at a fast rate. This would lead to game imbalance and potentially going through walls.

You can probably trace backwards through error strings to find the routines that poll controller input. It's not that difficult to do and I can assure you the renderer doesn't care what the controller is doing.

Overall, I think that what you are saying is illogical from the viewpoint of a ROM hacker. Please take the time to actually learn how the SNES and the ROM work internally before making suggestions. Not trying to be rude, but seriously though.

Don't get penisy, kid

It looks like it's tracing lines, to me. I thought Mode 7 only dealt with raster bitmaps, am I wrong about that?

There is no "bitmapped" mode on SNES at all, even if the SuperFX is rendering it. Mode 7 is a tilemapped mode just like any other, but you have a few additional registers to play with regarding transforming the viewport to simulate a 3D plane, independent of the other background and sprite layers. I am willing to bet the SuperFX is indeed rendering the automap because Mode 7 cannot be active while the nametable mode the SuperFX chip uses for bitmapped mode simulation is in effect unless the SuperFX is rendering to a sprite layer or something, which I suspect is "unlikely" in a word.

Ultimately what is happening with SuperFX rendering is that the SFX chip is simply an ordinary low-power RISC CPU soldered onto the cartridge, addressable through a few extra pins. You can tell it to do whatever the hell you want; Yoshi's Island (or whatever the fuck that game is) uses the SFX for sprite scaling/rotation and enemy AI, while Doom and Star Fox use it to render the scene. The SFX provides a means for you to render to an internal "bitmapped" framebuffer which is a little more limited in resolution compared to the native SNES output (this is why you get those big black bars around everything in Doom and Star Fox). After the scene is ready to be output to the TV, the SFX will eventually be triggered to generate a tilemap of the internal framebuffer and then DMA (?) it to SNES nametable memory, typically in Mode 3 or 4. Mode 7's rotation registers on the PPU do not have any effect in any PPU nametable mode except 7.

Share this post


Link to post

Do you have any idea why there are (rumored at least) Game Genie codes that work with Doom and leave the game playable, whereas for most SuperFX games this is totally impossible? I know why it's usually impossible. What I don't know is why Doom would be any different.

Share this post


Link to post

I'm looking forward to any developments that arise as a result of this. I probably should go and set up my SNES again.

Share this post


Link to post
Quasar said:

Do you have any idea why there are (rumored at least) Game Genie codes that work with Doom and leave the game playable, whereas for most SuperFX games this is totally impossible? I know why it's usually impossible. What I don't know is why Doom would be any different.


No idea. The real cartridge definitely has the SuperFX pins, so I couldn't tell you.

It should be physically impossible for any GG codes to work with any SFX game, though. For anyone who is not aware as to why this is physically impossible, SNES Game Genies do not have the additional expansion cartridge pins that SuperFX games do have. These pins are typically used for uploading/downloading from SuperFX memory space IIRC and the SuperFX will either fail to power up or won't behave properly if the pins don't connect to the SNES in some way.

My best guess as to why Doom may be different is that perhaps the DMA trigger that sends in/out data to/from the SuperFX to/from the SNES PPU is done using the non-expanded cart pins, but how that would be done -- if possible at all -- is a mystery to me.

Share this post


Link to post

The only extra cartridge pin I believe the SuperFX uses is the 21.4 MHz clock; most of the other pins are for the peripheral address bus, which the SuperFX doesn't use. Its entire address space consists of the on-cart ROM and RAM, which the SNES accesses through the standard address/data pins.

I'm not convinced there are Game Genie codes that do work with Doom on an actual console; it seems more likely that any Game Genie codes floating around the internet were meant to be used with emulators (for that matter, I know there are at least some Game Genie / Action Replay codes for Doom that work in ZSNES but not in emulators that actually support the Super FX correctly...)

Share this post


Link to post
Fisk said:

Zsnes is horrible and you need to kill yourself if you use it in 2015, use Bsnes or higan

I prefer BizHawk.

Same exact emulation core, but least it doesn't make me configure a stupid ROM library just to test a Mario romhack. It also doesn't incessantly refer to everything as "famicom" despite being an English emulator.

Share this post


Link to post
Revenant said:

The only extra cartridge pin I believe the SuperFX uses is the 21.4 MHz clock; most of the other pins are for the peripheral address bus, which the SuperFX doesn't use. Its entire address space consists of the on-cart ROM and RAM, which the SNES accesses through the standard address/data pins.

I'm not convinced there are Game Genie codes that do work with Doom on an actual console; it seems more likely that any Game Genie codes floating around the internet were meant to be used with emulators (for that matter, I know there are at least some Game Genie / Action Replay codes for Doom that work in ZSNES but not in emulators that actually support the Super FX correctly...)

Wouldn't surprise me if that's the case.

Share this post


Link to post

I'd try soldering a temporary bypass with some insulated wires if I didn't already sell my copy of SNES Doom and my Game Genie like a fool. :(

Anyone willing to do that to their own hardware could try that to test it out on real hardware.

Jaxxoon R said:

configure a stupid ROM library just to test a Mario romhack. It also doesn't incessantly refer to everything as "famicom" despite being an English emulator.

Tell me about it. I've always hated that about BSNES, and any other program that is very functional but has ass-backwards UI or other caveats.

Share this post


Link to post
Mattfrie1 said:

Have you checked out the Japanese version of SNES Doom yet? It features quite a few changes from the US and PAL versions of the game.


I realized that, due to one line of assembly mopoz showed me on romhacking.net (he was working on a doom snes editor, it was very legit, but he said he could not continue working on it due to the fact there is such little free space in the rom, and anything past 2mb is inaccessable to the super fx, and couldn't do nodes.

The line of assembly was $5F/FAF2 22 2E 31 5F JSL $5F312E[$5F:312E]

If I can figure out the equivalant in the Japanese ROM, I can figure out how levels are loaded and bring the any episode on any difficulty feature back to the USA version.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×