Doom 32x ROM Hacks

[Mezmorize]

Once again, thanks for all the help you've given me!

The way you explain it, makes it seem so much easier.
I'll get back to some Game Genie makin' soon.

Thanks for the comments, I bet you'll find at least a couple for some Genesis games!

[Tony H]

How come the GG codes don't have compare values like other systems?
Are the addresses static or don't use bank switching or whatever the hell that is? (I don't know much about that stuff.)

Correct... as far as I know, it's because there's no bank switching (like the NES). Although I remember reading somewhere that the Genesis uses banks. Maybe someone else here knows more.

Here's some interesting info on 68000 53xx subtract instructions... we'll use our popular 5379 as an example. We know that 5379 subtracts #1 from the address after it. If you want to change that instruction so that it subtracts #2 instead, just add 2 to the second digit: 5579 = subtract #2. 5779 = subtract #3, and so on. Also, we can modify that instruction to make it ADD instead of subtract. Just make the second digit an even number: 5279 = add #1, 5479 = add #2, etc. You can make it add or subtract up to #8.

BTW Mez, good job on the button cheat finds. I only know one method for finding them, and it doesn't work on lots of games. I'll have to thoroughly read through that post.

[Mezmorize]

Here's some more detailed info on the Cliffhanger inf time to select code. The original programing was 5379 0007 F176. This means that 5379 is subtracting #1 from RAM address 0007F176. When you changed the 0007 to 6002, this is what happened... 5379 6002 F176 = 5379 is subtracting #1 from RAM address 6002F176. In this situation, I'm not even sure if 6002F176 is a legitimate RAM address in SCD, but as you can guess, changing that RAM address could cause problems because you're going to be subtracting #1 from it. The correct way to do it would be to change the 5379 to 6004 so that we get this... 6004 0007 F176. The 6004 just jumps right over the operands (0007 F176) and on to the next instruction. The subtraction never takes place, and the programing "flow" is correct.

Oh, I see. I just took for granted that the first result that the txt document found was the correct instruction.
I fully understand what your saying, also I didn't know until now that the full 4 bytes could be for one address (0007F176).

So you may be wondering how do you tell by looking at a bunch of random hex numbers in CE's Memory Viewer, or in a hex editor, which ones are instructions, and which ones are operands? Without an assembly trace log file, it's hard to know for sure, but here's a few tips...

68000 instructions (and operands for that matter) ALWAYS start on an even ROM address number when viewing with a hex editor. For example, with 5379, the "53" will always be on an even ROM address number, and the "79" will always be on an odd ROM address number. This is important when looking at programing in a hex editor because... this will be an instruction: 5379 xxxx xxxx, but this will NOT be an instruction: xx53 79xx xxxx. Hope that makes sense.

Thanks for telling me that, but I luckily had figured it out pretty quick when I made that first Genesis GG code.
I became aware of the data alignment thing 'cause of the PSX too (thanks to Lee4).
How come the GG codes don't have compare values like other systems?
Are the addresses static or don't use bank switching or whatever the hell that is? (I don't know much about that stuff.)

There should be certain common instructions that you should have listed somewhere for easy reference. When you see these common instructions in your hex editor, you can be 90% sure they are instructions, and not operands. There is a chance that an operand will use the same numbers as an instruction, but usually not. Here's an example: 5379 00FF 5379. That means that 5379 is subtracting #1 from RAM address 00FF5379. That can be a little confusing, but you'll rarely see situations like that. 90% of the time, if you see a common instruction number like 5379, and it starts on a even ROM address, it'll be an instruction, and not an operand.

Some of the common 68000 instructions: 4E75 = RTS, 11FC = MOVE, 33FC = MOVE, 60xx = Branch, 66xx = BNE, 67xx = BEQ, 5338 = sub #1, 5379 = sub #1, 53xx = sub #1, etc... So when you see any of those, there's a good chance they're an instruction. This will help you figure out other programing near by.

Thanks a whole lot!
I'm gonna have to write these and the ones before all down somewhere.

[Tony H]

Here's some more detailed info on the Cliffhanger inf time to select code. The original programing was 5379 0007 F176. This means that 5379 is subtracting #1 from RAM address 0007F176. When you changed the 0007 to 6002, this is what happened... 5379 6002 F176 = 5379 is subtracting #1 from RAM address 6002F176. In this situation, I'm not even sure if 6002F176 is a legitimate RAM address in SCD, but as you can guess, changing that RAM address could cause problems because you're going to be subtracting #1 from it. The correct way to do it would be to change the 5379 to 6004 so that we get this... 6004 0007 F176. The 6004 just jumps right over the operands (0007 F176) and on to the next instruction. The subtraction never takes place, and the programing "flow" is correct.

So you may be wondering how do you tell by looking at a bunch of random hex numbers in CE's Memory Viewer, or in a hex editor, which ones are instructions, and which ones are operands? Without an assembly trace log file, it's hard to know for sure, but here's a few tips...

68000 instructions (and operands for that matter) ALWAYS start on an even ROM address number when viewing with a hex editor. For example, with 5379, the "53" will always be on an even ROM address number, and the "79" will always be on an odd ROM address number. This is important when looking at programing in a hex editor because... this will be an instruction: 5379 xxxx xxxx, but this will NOT be an instruction: xx53 79xx xxxx. Hope that makes sense.

There should be certain common instructions that you should have listed somewhere for easy reference. When you see these common instructions in your hex editor, you can be 90% sure they are instructions, and not operands. There is a chance that an operand will use the same numbers as an instruction, but usually not. Here's an example: 5379 00FF 5379. That means that 5379 is subtracting #1 from RAM address 00FF5379. That can be a little confusing, but you'll rarely see situations like that. 90% of the time, if you see a common instruction number like 5379, and it starts on a even ROM address, it'll be an instruction, and not an operand.

Some of the common 68000 instructions: 4E75 = RTS, 11FC = MOVE, 33FC = MOVE, 60xx = Branch, 66xx = BNE, 67xx = BEQ, 5338 = sub #1, 5379 = sub #1, 53xx = sub #1, etc... So when you see any of those, there's a good chance they're an instruction. This will help you figure out other programing near by.

[Tony H]

It looks like the F176 and 0007 are operands. The 5379 (before those) is the instruction. 5379 = subq.w #1. Pugsy's guide shows that 5379 has 2 operands (4 bytes), so if you replace the 5379 with 6004, you should get inf time. Your code worked because you changed one of the operands, which changed the address that's getting subtracted from.

EDIT: And yes, Sega CD uses 68000 assembly.

[Mezmorize]

Wow, awesome!
Thanks for putting it in plain english that I could understand ^.^
Also thanks for telling me the ones most used, I was starting to figure out for the Game Gear by looking at other peoples codes.

I take it the Sega CD uses 68000 also, 'cause I just used the info you posted above successfully.
Here's the example I tried from what you posted.

I found the RAM code for a 'Press Start To Continue' timer decreasing for Cliffhanger.
Used CE to get the ROM address (the byte that's highlighted in the below picture).
Like you've mentioned, I have to go backwards 2 bytes.
So I search the txt document for F176 and there are no results.
So I then tried going back 2 more bytes and searched for 0007.
Success! And after what it found I see 2 bytes.
I replaced the 0007 with 6002 and it successfully worked (Infinite Time To Continue >.<).



So thanks a whole lot, I've learned a lot thanks to another one of your great guides!

[Tony H]

Thanks Mez. Good to know someone read that stuff. :-)

A quick assembly guide... 0009 = NOP for 32x assembly only. 4E71 = NOP for Genesis (68000) assembly. Genesis (68000) assembly instructions are ALWAYS 2 bytes long.

When trying to kill an instruction (add, subtract, etc) in Genesis (68000) assembly, most of the time you will only need to use one of three different instructions... 4E71 (NOP), 6002 (Branch 2 bytes), and 6004 (Branch 4 bytes). If the instruction you want to kill doesn't have any operands, then you use 4E71. If the instruction has one operand (2 bytes), then you use 6002. If the instruction has 2 operands (4 bytes), then you use 6004. In short, you have to make sure that your NOP or Branch goes to the next instruction, and NOT an operand. Branching (jumping) to an operand can cause the game to freeze (because the programing will treat the operand as an instruction).

Here's an easy way to tell if an instruction has any operands, and if so, how many... Open up Pugsy's 68000 list and find your instruction. We'll use your code address for Lotus II RECS (inf time) as an example. The original instruction at the ROM address is 536C. In Pugsy's guide, it shows that it's: subq.w #1, (-$5520,A4) 536C AAE0. We know that it's subtracting 1 from the clock, and we want to kill it (jump over it) so we'll have infinite time. If you look at our instruction in Pugsy's guide, on the far right side it shows the hex number of the code (536C), with AAE0 after it. The AAE0 tells us it has one operand (2 bytes), so we would use 6002 to branch (jump) over it. Lets say the instruction was 5379... on the far right side of Pugsy's guide it shows: 5379 88B0 99C0. The 88B0 99C0 tells us there are 2 operands (4 bytes), so we would use 6004 to branch (jump) over it. If the instruction was 5340, Pugsy's guide shows on the far right side: 5340. No operands, so use 4E71 to jump over it.

[Mezmorize]

I had wrote down the buttons for that animation viewer also, but apparently forgot to save the text document.
Yeah, to me, a picture is worth a thousand words.

I told you I didn't know what I was doin' though lol.
Like I didn't know (at the time) that the ASM was any different than what I was used to.
For instance I believe that I seen you say that 0009 was NOP, not just 00.

(I typically try to figure things out on my own, but ASM is hard damn it)

Just figured I would share a little history:
I got my very first PC in 2005 (same one actually, until my taxes come at least).
I had come across your site many times while trying to learn how to make codes always on.

In fact, here's a little evidence that used to be on my old GeoCities site.
http://www.freewebs.com/mezmorizingm...kNesRomsV2.pdf
I wrote that about the same time, after learning how from you (I should have credited you >.<).

So thanks for the great guides you write, I wouldn't know a lot that I do today if it weren't for you!

[Tony H]

Edit:
"Many thanks for Ugetab's 68000 instruction list."

Where is that?
I see one by Pugsy, but the txt formatting is crazy (nevermind, opening it with wordpad instead of notepad did the trick).

The one from Pugsy is the right one (don't know why I thought it was by Ugetab).

I really like your Lotus II guide. The pictures are a very nice touch (makes it much easier to follow).

[Tony H]

By "debugger instructions", I meant these...

Start - Start/end debugging
D-Pad - Move Object

A - Cycle down through the different objects
C - Cycle up through the different objects

B - Place current object down
Y - Remove current object

X - Cycle through the different speeds
Z - Move the map forward at the speed set by X

I've gotta leave for work... I'll post a link to Ugetab's 68000 list later (and I'll check out your guide).

[Mezmorize]

I wanted to tell you that the info you gave me didn't fall on deaf ears.
I followed every step, up until the part where the 32x ROM codes are off, then I got simi lost >.<
I'll eventually get it all, I'm just kinda slow I suppose.

You don't have to ask my permission, you made the code LOL.
I tried and failed to make it a Game Genie code, that's why I asked you ^.^

I'm not one to bicker about such things as code credit, I'm having fun while learning something, so no complaints here!
(By debugger instructions I take it you mean with Cheat Engine?)

Not that I know what the hell I'm doin', but I made a shitty guide the other day as I made my first Genesis Game Genie code:
https://sites.google.com/site/gamegeniefusion/genesis

Edit:
"Many thanks for Ugetab's 68000 instruction list."

Where is that?
I see one by Pugsy, but the txt formatting is crazy (nevermind, opening it with wordpad instead of notepad did the trick).

[Tony H]

Mez, I'm going to add my Motherbase 2000 Game Genie code to my 32x GG file (giving you full credit for discovering the hidden options of course), but with your permission, I'd like in include your debugger instructions.

[Tony H]

Yes, that's the right one. I wrote a guide on how to use it:

http://codehut.gshi.org/GensTracerGuide.txt

EDIT: Note that in the guide, I say to subtract 2 from the ROM address you get from the memory trace. It may not always be exactly 2 less than the address it gives you. The address it gives you is USUALLY 2 less.

[Mezmorize]

OK, is this the version of Gens I need?
http://www.romhacking.net/utils/337/

I just don't see where to input a RAM address to watch, but I don't usually use this emulator.

[Tony H]

Good job on finding the hidden menu. Good to know there are unknown treasures like that still to be found.

Here's a bit more info on the method I used...

Use Gens Tracer to do a memory trace of your RAM address. That shows you were in the ROM the values for the RAM address are coming from. Here's what it looked like:

[FF:B8A6] W16 = 0000 [FF0552]
[FF:00D8] W08 = 02 [FF0552]

The ROM address we're interested in is [FF:00D8]. The problem is that because it's a 32x game, FF:00D8 isn't the actual ROM address. We'll use the assembly trace log to find the actual ROM address.

Do an assembly trace log.

Open the log and search for FF:00D until you find what your looking for (what's loading the value of 02 into our RAM address). Then use the method I described earlier to make the code. Note that the ROM address shown from the memory trace file is FF:00D8, and the actual ROM address for our code is $00BBFC. WTF?? As you can see, they're not even close. The way I find the actual ROM address is to write down a string of numbers from the assembly trace log and then search for them in the ROM with a hex editor.

This one was a little more difficult than most. You'll find that it's much easier with regular Genesis games.