Looking for a simple spreadheet-like program for developing ROM patches

[BeyondTheStatic]

Hi,

I'm trying to find a program that allows you to fill one column with data, and another with comments, like so:

.........................
| A9 | LDA #$01 ....... |
| 01 | ................ |
| 85 | STA $00CF = #$01 |
| CF | ................ |


It would need to have support for selecting/copying/pasting/deleting the entire or partial contents of a column, as well as the ability to add/delete rows anywhere.

Does such a program exist?

[Hacc]

Romhacking.net might have a program available for download to do this.

[BeyondTheStatic]

Yeah, I've been there, but I'll check again. I just spent 30+ minutes downloading and trying to get Columnizer to do what I want, but it's for formatting text files, not explicitly working with rows/columns like I want. Maybe RH has something. Thanks.

[Hacc]

You're welcome. I'll continue to look around and see if I find anything.

[rimsky82]

I might be interested in adding something like this to my NES Tool. You basically want a nice gui to alter the asm, and then be able to patch it into the rom, right? That sounds cool to try to implement. We could put in some really nice analysis. Obviously it's not an emulator, so it wouldn't have register or ram info like a debugger, but it should still get some decent info from the asm.

Let me know if this interests you.

[xibalba]

.

[BeyondTheStatic]

You basically want a nice gui to alter the asm, and then be able to patch it into the rom, right? That sounds cool to try to implement. We could put in some really nice analysis.

Yeah! In addition to patching, the ability to select and copy data from columns would be nice, since I often like working with FCEUX's Hex Editor to edit ROM data in real-time.

Obviously it's not an emulator, so it wouldn't have register or ram info like a debugger, but it should still get some decent info from the asm.

That's OK, I'm used to having dozens of things open at once; one more running program can't hurt

Let me know if this interests you.

Indeed, it does. It would make a perfect enhancement to your NES Tool, since it would allow you to design your ASM and add comments as you go along. As it is now, I either have to decipher the ASM each time I want to edit it, or remove comments one-by-one. It's more of a tedious process than it should be. Also, such a tool would make cataloging discovered HEX text values much easier

P.S. Line numbering in hex would help make calculating branch statements easier. I don't know if it would be possible to have a start address or not, but it would be a great feature for visualizing exactly where your code will be placed in memory.

[Lazy Bastard]

Did xibalba's post have any relevance? He's usually quite helpful.

[BeyondTheStatic]

@Lazy Bastard: Not really, AFAICT. What he linked to seems to be set of scripts for use in various spreadsheet apps. I'm trying to avoid buying a commercial program, or downloading an entire office suite when all I need is a single lightweight program to edit text in tiny boxes. Seems simple enough :/

[Lazy Bastard]

Ah, I see.

[rimsky82]

Well, I integrated a simple asm analyzer that interprets the code, and tells you what it can. I haven't gotten into the actual editing of it yet, that will take more time. (As of writing this, I haven't released it yet. I want to make it a little more interactive with the rest of the tool first.)

You have to consider that if you start adding code instead of replacing it, then you risk crashing when the pages are too big, and you start messing up branch distances. So, I think I'll let you replace code, but not add or delete to keep the page sizes consistent. What do you think?

[BeyondTheStatic]

Well, I integrated a simple asm analyzer that interprets the code, and tells you what it can. I haven't gotten into the actual editing of it yet, that will take more time. (As of writing this, I haven't released it yet. I want to make it a little more interactive with the rest of the tool first.)

Sounds cool.

You have to consider that if you start adding code instead of replacing it, then you risk crashing when the pages are too big, and you start messing up branch distances. So, I think I'll let you replace code, but not add or delete to keep the page sizes consistent. What do you think?

Are you talking about cases where you write code that needs to be bank-swapped? If so, I have no idea how to do that yet. It would be very useful, if I could only figure out how it's done.

[rimsky82]

A prg bank is 16k. No bigger, no smaller. Changing the size would offset the other banks, and emulators wouldn't read them correctly.

Branches work by telling the machine how far to jump (BCC $#08 would tell the processor to skip the next 8 bytes if the carry flag is clear). Adding code in the middle of routines would throw off these numbers.

I haven't looked into bank-swapping yet. I do wonder if the cart's mapper would make a difference in that case though.

[nolberto82]

  :7F30:48        PHA                         
  :7F31:A9 86     LDA #$86
  :7F33:8D 00 80  STA $8000 = #$00 - usually it writes 0x86 or 0x87 to 0x8000
  :7F36:A9 0E     LDA #$0E
  :7F38:8D 01 80  STA $8001 = #$00 - when this write happens bank E is switched to 0x8000. That will be 0x1C010 in ROM.
  :7F3B:20 00 90  JSR $9000        - This will jump to the empty space where you will put your custom routine.
  :7F3E:68        PLA
  :7F3F:20 1D FF  JSR $FF1D        - jump to the game's bank switch routine.
  :7F42:60        RTS

This was for a trainer I did some 2 years ago for Double Dragon 2. It is for mapper 4. The best way to bank switch is to locate any calls to the bank switch routine and jump to a different location execute your own routines and then execute the original one.

[BeyondTheStatic]

Branches work by telling the machine how far to jump (BCC $#08 would tell the processor to skip the next 8 bytes if the carry flag is clear).

Yeah, I figured that out the hard way :/

Adding code in the middle of routines would throw off these numbers.

How so? If you're using compare values (which aren't completely foolproof), and you're replacing a bunch of FFs or something, I don't see how that's going to adversely affect any routine which jumps over said region. But I'm still relatively new to hacking, so I'm probably missing the point