[vonMuir]

I'm still working on my first mod here.

I'm trying to locate offsets for things like weapon damage and enemy hit points. I've done some comparative editing (as one might do for an RPG), but because this is an action RPG, a LOT of code is changing between save states. Plus, all of the in-game data is using bars to represent most statistics like health, so I don't have any place to start looking for specific hex patterns.

Any tips on how to handle this?
June 29, 2016, 12:21:41 am - (Auto Merged - Double Posts are not allowed before 7 days.)I realize I'm being a bit vague about the save states:

State 1: I have my enemy targeted.

State 2: I have shot my enemy, and he has run away from me just a bit. The graphic that represents his health has turned from green to red.

[STARWIN]

Theoretically the more data points you have the less RAM locations you are left with (0 shots sustained, 1, 2, 3..). I've done it manually with vbindiff over a bunch of RAM dumps (~uncompressed save states) but in case there is no tool in the debugger emulator to do this for you, it would be an unambitious coding task to automate (most likely code like this exists somewhere, I just haven't noticed a multi binary comparison tool anywhere really).

If there is a realtime RAM viewer and the system is old enough for the RAM to fit on a few screens, it tends to be practical to just look at it and see where it is.

One more path is to locate player character hit points and use breakpoints to trace back to opponent's damage calculation/value. (other stats of opponent's may be sequentially close to this value)

If someone has the values in a FAQ/a cheat code exists that could be an alternative approach.

[vonMuir]

Thank you for the response!

I'm going to fool around today to see if I can't get any of those techniques to work. I'm especially curious about this one:

One more path is to locate player character hit points and use breakpoints to trace back to opponent's damage calculation/value. (other stats of opponent's may be sequentially close to this value)

I will likely have to do this later in my project if not now (I want to modify algorithms the game uses to calculate certain variables). I've gotten to the point where I understand how to read basic 68k assembly code (I'm working on the Genesis game Shadowrun). But I'm still not 100% sure how to accomplish what I'm trying to do...

I have a debugger (Regen), but it seems to only display a snapshot of the code (image below). So, how do I use that to determine the programming that preceded my screen shot? In other words: I know how to view the assembly code prior to my attack and the assembly code immediately following my attack, but I don't know how to identify the code that was read during my attack (which would be the pertinent information).

I'm clearly missing something simple, but I'm having a hard time finding resources that go beyond hex editting.
June 29, 2016, 01:37:41 pm - (Auto Merged - Double Posts are not allowed before 7 days.)(forgot the image:)

[STARWIN]

I assume that code is just some unknown code to you. You start by figuring out which RAM address holds the player health, set a write or read (address) breakpoint there depending on whether you want it to halt at code that writes to player health or code that reads it. PC register contains the address where it is halted right now (it is either the next instruction or the current one ~technicalities). 1 Step I assume executes one instruction. By stepping to (beyond) a return (RTS I assume) you will see where the function was called from. Which can be useful for setting a breakpoint just before it gets called or to see among which instructions it gets called, where it gets the values input to the function (if any) etc..

You can probably use that "Show disassembly" part there, if what you are asking is how to read other code than shown assuming you already know where you are in the code.

[vonMuir]

The code pictured is from the "State 2" mentioned in my first post.

I'm still not quite getting some of this, so thank you very much for taking the time and helping a beginner like me out:

I read through the code posted in the picture. The second half of the code (below the first "RTS") peaked my interest. Both routines involve three elements: D1, offset ffe173, and the conditional "Z" flag (one of 5 on/off flags that the 68k employs).

cmpi.b #-$2, $ffe173 - This command subtracts hex value 02 from the longword at offset ffe173

The next line of code checks the Z flag condition, and results in altering the value at D1.

This is repeated below, with significant variation.

I figured that this code might have something to do with deciding whether or not my attack was successful and then alters the enemies hit points. First, I decided to check the value of the longword at ffe173. I loaded up my hex editor, and checked the offset...

...

It doesn't have that many offsets...

Not even close...

Grr... So that's the first issue. Why is the PC running a program on an offset that doesn't exist?

ISSUE NUMBER TWO:

I wanted to know whether or not I was even looking in the right place, so I figured I would experiment a bit and debug a couple more save states. I loaded the game in the same spot as before and ran the debugger several times. I figured that irrelevant portions of the code would change, affecting graphics and sound, but the relevant game data would replicate itself.

It didn't.

I tried over and over again, but each save state is displaying drastically different code. This is sort of the same problem I had in the beginning, I guess. I don't understand how to find view the code I'm looking for -only how to view the most immediate lines of code. I'm having trouble coming up with the question, since I don't have the answer... Maybe someone with more experience will know what I mean?

[STARWIN]

1. Usually the ROM offsets are different from the memory space the CPU sees. This is called memory mapping and you basically have to read how it works in your particular target system.

2. How you halt the emulator is very important. If you quickly do something and quickly do a save state or something, it won't work because the amount of lines executed every second is massive. The only way to find the code is to use a breakpoint, which does the halting for you when a condition matches.

The code tends to be unchanging and what changes is RAM content, based on the code executed. Save states contain RAM and a few other changing things like registers.

[vonMuir]

1. Usually the ROM offsets are different from the memory space the CPU sees. This is called memory mapping and you basically have to read how it works in your particular target system.

So my emulator takes the data from the save state and recompiles the data into the original ROM file? Previous mods I made to this ROM involved editing the .bin file directly, not just editing the save state data, so the process involved is a little bit different now.

Let's say that I locate and identify the variable I'm looking for (let's say it's enemy health). Is my only purpose in doing this to establish a breakpoint? It seems that knowing the offset only helps me in altering the current state of the game otherwise, not changing any mechanics involved.

The only way to find the code is to use a breakpoint, which does the halting for you when a condition matches.

I was playing around with the title screen trying to get the "PRESS START" text to stop blinking. If I've successfully found the breakpoint that starts the routine instructing the text to blink, how do I proceed?

I presume that blinking text would be caused by a routine that either adds/removes the text or else by a routine that adds/removes a layer of tiles to cover up the text. How would I identify and alter this code in the current state of the game? How would I identify and alter the code in the original ROM file? I'm not asking for the specific code, of course -just the general process.

There are a plethora of a resources available for folks trying to do basic translation hacks or cheats, but I just don't see a lot of resources available for people trying to do more full scale mods, which is unfortunate.

[STARWIN]

The 68K CPU sees a certain address space. The PC travels somewhere in it. The CPU alone doesn't know anything besides this. When they built the Genesis they wired it so that certain regions of the address space refer to certain memory locations or input/output or something else (or nothing). Here is a 68K memory map for Genesis: https://en.wikibooks.org/wiki/Genesis_Programming

So that previous FFE173 for example refers to a RAM location. Looks like the ROM is mapped to the beginning (although it says Cartridge RAM can be somewhere there too - that is not part of the ROM). But it is possible that the ROM (file) contains more information than just the game image (which is loaded to the emulator), like a header or such as the above article hints. You should be able to figure out how the ROM offsets map to the address space by reading/tinkering a bit.

I doubt the save state (=copy of RAM and registers and possibly save RAM) and the ROM touch each other much, but I don't really know this console. To mod the game you do indeed change the ROM and not the save state. The save state just acts as one possible way of looking at RAM, if the save state format is easy to read.

Yeah you want the RAM location to set the breakpoint, and when the breakpoint triggers you see one piece of code (there can be many of course) that accesses the datum there. The location of the code gives its location in the ROM (or you can search the rom for a nearby unique opcode sequence if you want to skip some thinking).

I was playing around with the title screen trying to get the "PRESS START" text to stop blinking. If I've successfully found the breakpoint that starts the routine instructing the text to blink, how do I proceed?

I presume that blinking text would be caused by a routine that either adds/removes the text or else by a routine that adds/removes a layer of tiles to cover up the text. How would I identify and alter this code in the current state of the game? How would I identify and alter the code in the original ROM file? I'm not asking for the specific code, of course -just the general process.

I don't have an educated opinion of how graphics work in this system (or any system) so I just don't know. For graphics there is a graphics subsystem with its own rules, basically a piece of hardware.. for game mechanics it is always CPU only, and I really like the simple CPUland better. Someone who knows graphics might have better ideas than me.

[vonMuir]

Thanks again, STARWIN, for the precise and well-written response.

I think that I'm getting a much better grasp on what I need to do to accomplish this project. I'm going to experiment around and see whether or not I can successfully identify and alter some of the game's mechanics.