11 March 2016 - Forum Rules

Main Menu

Three questions on finding free space on an nes rom

Started by Pikachumanson, November 18, 2012, 02:59:20 AM

Previous topic - Next topic


The game I am going to implement dte on is Akagawa Jirou no Yuurei Ressha for the Nes, or Akagawa Jirou's Ghost Train, if you will.
The first question I wanna ask is where in an Nes rom is free space usually located? Also, how would I be able to tell if I am looking at the dakuten/handakuten routine in case I want to replace that with a dte routine? Also, I noticed when I was working another nes rom (4 Nin Uchi), I saw quite a few lines of code that were like "lda undefined" or something like that. Is that free space that I can code over as well?


Most people would just go by if they saw a ton of space with a single repeating byte/pattern. No way to guarantee, though.
Also, it is typically only useful if the free space is in the same ROM bank as the code/data one wants to change.

As to dakuten code, it would typically be something like this:
(say if dakuten were $A0 to $E0)

ldy #$00
lda ($20),y       ;say the text pointer was stored at $20-21
cmp #$A0
bcc NotDakuten   ;less than
cmp #$E0
bcs NotDakuten
;do stuff here with dakuten/handakuten
;other stuff

Other games I've seen do something like this:
-store the hex value for a space tile to RAM
-read a text character, store to RAM
-if han/dakuten, store that han/dakuten mark over the space tile in RAM
And then when it goes to print the character, it will read and print both the character and the mark tile (blank or han/dakuten).
For English, you'd have to null out the dakuten-writing code. (say it stored the base character to $0600 and the dakuten to $0601, you'd null the line of the code that's like "lda $0601: sta $2007"

Other games might do a variation, where it writes up a string that gets copied to VRAM.
One such format I've seen:

1 byte length, 0 for end
2 byte VRAM address
repeat (until length=0)

So for example, it might be 01 20 82 50 01 20 62 3D 00, if 50 were the base character and 3D were the dakuten tile. If it were doing that, you'd take out the routine that was writing 01 20 62 3D to the buffer.
"My watch says 30 chickens" Google, 2018


Load the game with FCEUXD SP 1.07 and use the code/data logger. It logs the executed/read/written bytes. Play the game and try to go through many different codepaths.

In the included hex editor (F6), switch to ROM view. Colored bytes were used. If you were going to use some of the colored ones, don't. Ends of banks might be more likely to be unused.

It will only help to avoid certainly used bytes though. Some risk still remains.


Free space is almost always FF or 00. I would be suspicious of any other value; it may well be data of some kind.

One thing to look for is if the repeated value occurs until the end of the current bank. Banks will end at 8 KB, 16 KB, or 32 KB boundaries depending on your ROM's mapper. (Remember that the iNES header is 16 bytes, so a bank will end at e.g. 0x0200f instead of 0x01fff). If that's the case, it's probably free space no matter what the value is. Unless I know exactly what code/data precedes it, though, I usually insert stuff a few bytes into the padding rather than right at the start, because you don't know whether the first bytes of the block are padding or data that happens to have exactly the same value as the padding.

On the NES, in some games the last six bytes of every bank are set to the IRQ, NMI, and RESET vectors, so it's not a problem if the last six bytes of the block are different. I'd leave those bytes alone just to be safe, though.