[vonMuir]

I'm slogging away on my first Genesis mod and have hit a big brick wall. I have tons of juicy RAM offsets ripe for debugging, but I can't seem to successfully write any breakpoints to them.

I've been using RegenD, but it just doesn't seem to break no matter how I configure the debugger menu. I've also tried Gens Tracer, but I can't seem to understand how to set breakpoints at all. When I try using Exodus, it has issues with the ROM file and doesn't write to the RAM correctly.

What I'm trying to do (specifically): I'm working on Shadowrun. I've located the RAM offset for an enemy's health (2BC4). I set the breakpoint to that location on "write". I shoot the enemy once (which reduces the hex value at RAM offset 2BC4 from 0A to 06). Nothing happens. No break. I've tried different combinations of "read"/"write", along with "FF2BC4" instead of "2BC4", etc. to no avail.

What am I doing wrong? I'll gladly download a different debugger if necessary. There's no support for a lot of these Genesis debuggers, and most tutorials on debugging deal exclusively with the Nintendo family.

[tryphon]

IIRC, RegenD has a bug for breakpoints on RAM writes.

I never had problem with Gens_r57shell_mod_r665 available on this site (but it lacks a feature Exodus has : break on registers values).

RAM in MD always starts by FF...., so your breakpoint must be on FF2BC4 (2BC4 without FF is an offset in ROM).

Which ROM of ShadowRun do you use ? Could you provide a Gens savestate just before the shoot on the ennemy ?

[vonMuir]

Thanks for the help, Tryphon.

I downloaded Gens_r57shell_mod_r665 and have been playing around with the interface. Everything is "working" for me, but I'm still running into the same problem. I thought it was the debugger, but maybe it's a bad offset? More below...

Which ROM of ShadowRun do you use ?

Country: USA
Size: 2 MB (2,097,152 bytes)
Checksum-8: 12
Checksum-16: CD12
Checksum-32: 093CCD12
Checksum-64: 00000000093CCD12
CRC-16: 893F
CRC-16 CCITT: D611
CRC-32: FBB92909
Custom CRC (32-bit): 00000000
SHA-1: A06A281D39E845BFF446A541B2FF48E1D93143C2
SHA-256: 92A614491FC3EA12A6DF32459CCE08B48574B7B814E244C07EB860DC5C6EDB7E
SHA-384: 79E621AA4AA47225A39BD655A58CF52719F2E164268FB460E160AE7521384FFFAB2B59CDB1FD165F5A965C02860F4693
SHA-512: F0B6B15A9A5F2AD42E0E425FE2006421C2507C6B092839017E85DA79CEB67D4B6EA17BB60A9349C3B05D40F57BDA55212B70D0F5B1B1E4BF275B0386D187215F
MD-2: 27BDBC8554E4B561474F03FBB8DEB5C4
MD-4: 8644CC08510B044341D93DE078380DF9
MD-5: 53090BCD67A0B6262F71EF7C5838C02B
Shadowrun (USA)

Could you provide a Gens savestate just before the shoot on the ennemy ?

Hopefully this upload works

The health (possibly the health graphic, although I doubt it) for all active enemies on the map are stored at FF28C4, FF29C4, FF2AC4, etc. The hex values correspond with a percentage out of 100% (00-0A). This has been confirmed with some simple save state hacking.

In the save state comparison below, I've shot a "pedestrian" and reduced his health from 100% (0A) to 10% (01):



If I alter the value in a hex editor, it does in fact alter the NPC's health. It affects both the amount of health and the corresponding sprites (although I expect the sprites are controlled at a different offset by at least one longword).

However, if I set a breakpoint to write at FF29C4 (as in the "pedestrian" example above), the debugger never breaks! It will break when I load a new map (presumably because the game writes the enemy data as it loads a new map).

One new thing I did notice: ONE enemy's health is set to address register A1 (FF28C4). Maybe it's not breaking because all of the enemy data is being manipulated via registers? I'll trouble shoot this last bit a little more...
July 13, 2016, 03:15:36 pm - (Auto Merged - Double Posts are not allowed before 7 days.)

I'll trouble shoot this last bit a little more...

Enemy data offsets do get written into at least one Address Register when a map loads. I didn't poke around to see why, but I think it's just a red herring. I'm interested in damage calculations right now, not enemy stats.

[STARWIN]

My first guess would be that the save state doesn't map to RAM 1:1. So the breakpoint you set is for some other address. Do any of these emulators have a RAM viewer inside the emulator? It would be very simple to confirm with that. Otherwise you need to know which part of the save state contains the RAM (hopefully the save state isn't compressed). edit: quick google gives http://segaretro.org/Genesis_Savestate_Viewer

[tryphon]

STARWIN is right : the savestate IS NOT the RAM. It contains a copy of the RAM, but doesn't start with it. It also contains many other things, such as register values, VRAM, VDP registers values, and other.

You can consult the .gsx specifications, but you can also use gens-r57shell (or tracer) hex viewer.

If I have time, I'll have a closer look tomorrow...

[KingMike]

If that version of Gens is using the savestate format as the version I've been using, I recall RAM should start at $478 in the savestate file.

That format was uncompressed and should contain emulator/register stuff, and then $10000 bytes WRAM, $10000 VRAM and then I don't know what other kind of RAM you have in the Genesis.

[vonMuir]

STARWIN is right

I get the feeling that happens a lot!

I'm not sure I have my head wrapped around the whole concept yet, but I used the save state viewer to find the corresponding address. 28C4 in the save state worked out to a RAM address of FF054C. So, I plugged that new value into the breakpoint in my debugger, and... success! I tracked down a pedestrian, fired a shot, and immediately tripped the breakpoint!

I need to do some more tests to make sure it's all working correctly, but preliminary results show it working out perfectly.

STARWIN, you're my spirit animal.

[JLukas]

If you still have trouble getting those same breakpoints to work in other debuggers note that you may need to use 32-bit addresses e.g. for the RAM address in your last post you would need to set a breakpoint on 00FF054C instead of FF054C.

[tryphon]

GENS has no problem with FFxxxx.

Anyway, MD addresses are 24 bits.

[vonMuir]

Thanks to everyone's help, I was able to make some progress. Pictured below, I've just reduced the NPC's health from 100% (0A) to 60% (06) and triggered the breakpoint:



After getting it to break successfully a couple more times, I took a look at the code itself. Now I'm a bit puzzled again. In all the video tutorials I've seen, the location that caused the trigger shows up right in the op code. Is this a normal? If not, what's going on here?

In the meantime, I'll be backtracking through the PC trying to figure out how the damage was calculated.

[STARWIN]

Usually when reading code in a typical debugger emulator, I see a bit more.. code on the left side. Here, if I understand correctly, there are small pieces of code that jump to the next code island.. looks strange to me because if the branch isn't taken it hits that hex stuff? if it is data, it would fail.. but maybe this emulator doesn't show the code properly or uh, something..

I don't know the syntax but does $009A(A1) really resolve to FF054C like you expect? I'd assume ($00FFF0CC) resolves into FF054C instead. So the bytes FF 05 4C would be stored in FFF0CC in some order.

The 06 you see in the code is an offset for the branch, which as you can see resolves into a jump into 05:5A6E, which is the island where it broke. So not related to 06 in (what is hopefully) health.

Guess I'm missing something overall though (or the code is a bit crazy).

edit: also tst.b breaking when it is a write breakpoint doesn't seem sensible, I'd imagine tst.b only reads.

edit2: orrr maybe the simplest solution would be that that was the last PC as it says, and the current instruction executed is in 055A90, so scroll down a bit.

[vonMuir]

I've done a bunch more testing, and I think that I've answered my last question.

It appears as though the op code sometimes points towards a specific RAM address without naming it. It uses different combinations of registers. It's late and I'm burnt out, but basically the debuggers might read op code that says something like:

"Add the hex value 66 to the long word at Data Register 7. Take that value and add it to the long word at Address Register 1. Move to that new address."

This all reads as one op code. If Data Register 7 contains 00000000 and Address Register 1 contains 00FF0200, then the code will end up pointing towards offset 00FF0266. If I set my breakpoint to 00FF0266, it will break at this line of code. And even though there'll be plenty of reference to the two Registers, I'll never actually see 00FF0266 written directly into the code.

The above example was my attempt to mod another part of the game (which I'll return to tomorrow), and I tested it out quite a bit to make sure I understood what was going on.

[STARWIN]

Yes, that's what I meant by resolving. The different ways to resolve the operation target(s) are called different addressing modes, and you can consider them equally direct reads or writes as far as breakpoints are concerned. A document like http://www.freescale.com/files/archives/doc/ref_manual/M68000PRM.pdf lists all the modes in section 2.2, but it isn't as clearly written as some docs for some other systems IMO.

[vonMuir]

I've seen that document. I've been referencing Markey Jester's tutorial, mostly. I find it a lot more user friendly, albeit incomplete.

Thank you to everyone for the help, especially Tryphon and STARWIN! I understand all of this much better.