What's new

Anyone want to learn rom-hacking?

Interested in a rom-hacking series?

  • Total voters
    49
ekorz said:
...well someone isn't interested!
Click to expand...
That was me.

I am genuinely not interested in learning, nor going to click "yes" for the sake of being a sheep.

Doesn't mean I don't respect people who hack teh romz or want to. Salute to the majority and look forward to playing the fruits of your labour whatever it is.
 
Just watching these now. In the first video around the 8:50 mark you're talking about hex ROM size. I have a handy cross-reference chart I made for myself. Literally I have this printed out and taped up next to my monitor makes it easy to determine file size vs size in mame vs what EPROM it likely uses.

ts-eprom-xref_v1.1.png


I think I posted the original v1.0 of this chart before this is a v1.1 that made a few few adjustments and made the colors a little more printer friendly.
 
Last edited:
twistedsymphony said:
8:50 mark you're talking about hex ROM size
Click to expand...
yeah and I think I made a mistake there too. but thankfully the important part for hacking is just that you can tell via MAME docs what the address and address-space are for, regardless of the size on disk/rom :D
 
I just finished watching through. definitely learned a few things. As someone who tends to patch by hand I really like your patch array python script. usually I'll have a text file with the bytes and location to modify then go through and tweak my joined.bin from notes before de-interleaving for test. your method is also great for essentially self-documenting the patch as well. I'll definitely be stealing that. Also learned a few shortcuts you use that I wasn't aware of.

I'd love to find a good op-code database, some are pretty straight forward to modify (like the ones you used in this video) some are not (like if you need to do something with D2 vs D0). when I was doing the Metro VG420 and VG460 input patches I ran into a lot of opcodes that I needed that I couldn't find examples of in the disassembly and need to disassemble a few other games to find good examples.

When I did my GunFrontier conversion I ran into the same issue and ended up finding a 68K compiler to generate the opcodes for me. if I recall it was a real pain to get setup though so I haven't revisited that method.
 
twistedsymphony said:
I just finished watching through. definitely learned a few things. As someone who tends to patch by hand I really like your patch array python script. usually I'll have a text file with the bytes and location to modify then go through and tweak my joined.bin from notes before de-interleaving for test. your method is also great for essentially self-documenting the patch as well. I'll definitely be stealing that. Also learned a few shortcuts you use that I wasn't aware of.

I'd love to find a good op-code database, some are pretty straight forward to modify (like the ones you used in this video) some are not (like if you need to do something with D2 vs D0). when I was doing the Metro VG420 and VG460 input patches I ran into a lot of opcodes that I needed that I couldn't find examples of in the disassembly and need to disassemble a few other games to find good examples.

When I did my GunFrontier conversion I ran into the same issue and ended up finding a 68K compiler to generate the opcodes for me. if I recall it was a real pain to get setup though so I haven't revisited that method.
Click to expand...
It would be cool to have a FULL library.

The files in my thread the txt from opcode.zip does have a lot of opcodes, and they're pretty easily searchable once you get used to it. One thing I've gotten used to is that the codes themselves are usually guess-able once you get to know them, because they're ordered. Take "move byte to a data register". you can see the only thing that changes is the second digit, and they increment by skipping every other digit.

move.b #<DATA> to D0 (W+W) - 103C + #Data
move.b #<DATA> to D1 (W+W) - 123C + #Data
move.b #<DATA> to D2 (W+W) - 143C + #Data
move.b #<DATA> to D3 (W+W) - 163C + #Data
move.b #<DATA> to D4 (W+W) - 183C + #Data
move.b #<DATA> to D5 (W+W) - 1A3C + #Data
move.b #<DATA> to D6 (W+W) - 1C3C + #Data
move.b #<DATA> to D7 (W+W) - 1E3C + #Data

so if I have a similar opcode and need to change some part of it, I can sometimes guess (and let mame's debugger disassemble my guess... and tell me if I was right).
 
Pythagoras said:
The best 68k mnemonic/opcode reference is this one by Pugsy...
Click to expand...
the more the merrier, but don't sleep on the opcode list I attach here: https://www.arcade-projects.com/threads/my-rom-hacking-method-vids.35802/#post-482030

The pugsy one didn't have several that I just CTRL+F'd - like move with displacement, which is something I use quite a lot.

move.w D0 to (d8,A1,Xn) on #<Displacement> (W+W) - 3380 + Displacement (and similar kinds of moves D1 to A1 + displacement etc.)
 
Oh, you are correct! I have not noticed that, since I mostly write my code in an assembler. But sometimes I use opcodes and a hexeditor for small patches.
 
Pythagoras said:
Oh, you are correct! I have not noticed that, since I mostly write my code in an assembler. But sometimes I use opcodes and a hexeditor for small patches.
Click to expand...
If you have a nice workflow we can learn from, please share it! you can see what I'm doing for my romhacks in that other thread -- better than hand patches but still could be improved
 
twistedsymphony said:
Just watching these now. In the first video around the 8:50 mark you're talking about hex ROM size. I have a handy cross-reference chart I made for myself. Literally I have this printed out and taped up next to my monitor makes it easy to determine file size vs size in mame vs what EPROM it likely uses.
Click to expand...
Maybe you'll want to include mask ROMs too, a bit more problematic world like the DIP28 1MB ones (pinout compatible with DIP32 27C100 EPROMs, but the PCB must have the sockets or at least room for them), or those 834100s which are only pin compatible with 27C4096/27C4002 in 16bit mode, in 8 bit mode you need an adapter to 27C400, etc.
 
Really awesome stuff you are putting together for folks @ekorz.

One tip I found helpful and worth sharing is the way that @zardam put together his build process here:

https://github.com/zardam/ub_vortex_multicart/blob/main/src/build

This type of flow makes it easier to document patches and build/rebuild when putting together a more complex mod.

Also you can leverage the vasmm68k_std assembler to generate your code, then tell your build script where to inject the output.

Note you still need to verify that the code you generate "fits" into place where you want it.
 
@ekorz I got around to watching the videos, great stuff, thanks for making them!

I also run into that mame debugger issue where it will stop accepting commands when working on my stuff. I've found a couple ways to fix it.

1. Click in the disasm part of the main debugger window and press escape, this will usually fix it
2. In the Setting menu, disable 'Save Window Arrangement', then restart mame (and re-enable the option if you like it). This will 100% fix it every time for me.

twistedsymphony said:
Just watching these now. In the first video around the 8:50 mark you're talking about hex ROM size. I have a handy cross-reference chart I made for myself. Literally I have this printed out and taped up next to my monitor makes it easy to determine file size vs size in mame vs what EPROM it likely uses.

ts-eprom-xref_v1.1.png


I think I posted the original v1.0 of this chart before this is a v1.1 that made a few few adjustments and made the colors a little more printer friendly.
Click to expand...

I use your older version all the time. Didn't know you had a newer version, time to upgrade! thanks.

kuze said:
Also you can leverage the vasmm68k_std assembler to generate your code, then tell your build script where to inject the output.
Click to expand...

I was going to suggest this as well. You can also leverage it if you just want to know an opcode.

Code: 
$ vasmm68k_mot -m68000 -spaces -chklabels /dev/stdin -L /dev/stdout
vasm 1.9c (c) in 2002-2023 Volker Barthelmann
vasm M68k/CPU32/ColdFire cpu backend 2.6 (c) 2002-2023 Frank Wille
vasm motorola syntax module 3.17 (c) 2002-2023 Frank Wille
vasm test output module 1.0 (c) 2002 Volker Barthelmann
                clr.b   $100082
                btst    #$2, $e00001
                beq     .dip_not_set
                move.b  #$9, $100082
        .dip_not_set:
                rts

Once you typed in all your code, press ctrl-d and it will spit out something like this

Code: 
Sections:
00: "CODE" (0-1A)


Source: "/dev/stdin"
00:00000000 423900100082             1:                 clr.b   $100082
00:00000006 0839000200E00001         2:                 btst    #$2, $e00001
00:0000000E 6708                     3:                 beq     .dip_not_set
00:00000010 13FC000900100082         4:                 move.b  #$9, $100082
                                     5:         .dip_not_set:
00:00000018 4E75                     6:                 rts
                                     7:


Symbols by name:

Symbols by value:

CODE(acrx2):              26 bytes

Just be mindful that vasm doesn't allow instructions at the start of a line, so you need to either space or tab over before writing them
 
You must log in or register to reply here.
Back
Top