Questions around FDS Pointer Hacking (Hikari Shinwa - Palthena no Kagami)

[BlackPaladin]

I have a couple of questions regarding the FDS ROM, "Hikari Shinwa: Palthena no Kagami".  (Kid Icarus in NES Form)  First, I'm trying to figure out this game's pointer system, but I don't know if FDS pointers are any different than NES pointers.  I want to switch some text around, but without any info regarding FDS pointers, I'm having a hard time using the available space in the ROM itself.


This text appears on a black screen...

0x9E4 = Flip to Side A (1 space extra)
0x9F3 = Flip to Side B (1 space extra)
0xA02 = I'm Dead (1 more spc needed)
0xA09 = Continue (2 spaces extra)
0xA13 = Save (2/3 spaces extra)

What I want to do is to use one extra space in 0x9F3 so that whatever pointer is pointing at 0xA02 (I'mDead) can be subtracted by one so that it points to 0xA01 so that I can have it display as (I'm Dead).

Now for question number two...

In the game's status screen, I want to move the free space in the first like so that it can be moved two spaces back so that it shows two characters, one space, and five characters.  Right now, it shows as four characters, one space, and three characters.

Allow me to further elaborate by showing the offsets...

0x2B92 = HiSc ore
0x2B96 = ore

Notice where the space is in the offsets.  In the HEX Data, it's all just seven straight lines of text, no spaces therein.  If you open up the ROM in WindHex, the text therein is shown as "HiScore".  I can only assume there's a pointer that is pointing at 0x2B96 (ore) that I would like it to point at 0x2B94 so that it would show (Score) in the second line.  Maybe if that's successfully changed, the "space" which is wedged in (HiSc ore) to be displayed as (Hi Score).

I hope my questions are made clear here.  I'm still unsure if FDS ROM Hacking is any different, compared to NES ROM Hacking.

https://www.sendspace.com/file/u0929g

This is what I've done so far.  If you want to use this patch, you'll need the FDS ROM with a header (131,016 bytes) with a CRC Checksum of BC88AA13.

[FCandChill]

The FDS is a Famicom add-on so reverse engineering FDS games mostly requires the same debugging process as NES games. The biggest game changer is the fact everything must be loaded to RAM to be read or executed. Hacking can be as simple as expanding a file or as complicated as requiring to make a full disassembly to get more space. For pointer format, this is specified at the software level.

[BlackPaladin]

The FDS is a Famicom add-on so reverse engineering FDS games mostly requires the same debugging process as NES games. The biggest game changer is the fact everything must be loaded to RAM to be read or executed. Hacking can be as simple as expanding a file or as complicated as requiring to make a full disassembly to get more space. For pointer format, this is specified at the software level.

So does this mean that if I wanted to hack pointers in FDS ROMs, I would require learning ASM to do that?

[FAST6191]

Can't say you won't have to learn it but there is probably still much you can do for most games with just file level* or simple memory** level approaches.


*I have not hacked many FDS games to give a general overview like I might for other systems I know more of but across systems in general you have three main approaches plus sectors. Those are i) basic pointers (give or take any endianness concerns then start counting at the start of the file), ii) offset pointers (like the previous but you start some way into the file, usually at the start of the data you are concerned with), and iii) relative pointers (you take the location of the current pointer as you are reading it and add the value at this location, will see this more in the code side of things but is quite possible at file level too). I don't know how often files will use accessory files to contain all their pointers -- easier to load a small list of locations rather than keep going back to a massive file to figure out things and then load the data from said same.

**see FDS/NES with FDS memory map. It might make sense for some files that know the location they will land in memory to operate accordingly rather than stick to file level things, though the NES/6502 does do a bit more in the way of relative jumps and pointer maths/generated pointers compared to later systems by virtue of being 8 bits (get to 32 bits and you can address some 4 gigabytes, 2^8 however is rather less than that so workarounds get employed). Sectors is where you call a given size of data on disc or something a sector, you can then say "sector 4000, bytes 15h through 40h" at the cost of wasting space if the whole thing is not filled -- see also why your windows computer might say size of file and size of file on disk.

[FCandChill]

So does this mean that if I wanted to hack pointers in FDS ROMs, I would require learning ASM to do that?

If you want to easily get an idea of how a game works, then yes. Without assembly knowledge, you're limited to blind guesses. And that will only take you so far. If a game does something really weird such as pointers embedded into assembly code or has its own scripting language, general knowledge about pointers aren't going to help...

One thing to keep in mind is that pointers for the FDS point to RAM locations, not disk image locations.

[KingMike]

Yes, you need to know where in RAM the file (and in turn the pointed data) is. Fortunately the RAM address is right in the file header data, so any program that can display the contents of a FDS disk should be able to tell you that.

If you are using a program that can unpack and repack FDS image files, then you would need to know the offset of the data within whatever file it is in, plus the file's target RAM offset, and then you just put the two together.
If you hacking the .fds file directly, well then you have a lot of work with no easy answer. Know that files in a FDS disk are stored sequentially of the listed order (again, see a file listing program) and a whole lot of math to figure that out.

[BlackPaladin]

Sounds like I have a lot to learn when it comes to FDS ROM Hacking.  I didn't realize how difficult it could be.

In any case, I did download the utility, FDS Explorer, to see files WITHIN the FDS ROM.  This is what was inside, so far...

Disk: 1
Side: A
No of files: 14
* KYODAKU- (NT, $2800, 224 bytes)
* END OTO (PRG, $CE00, 784 bytes)
* SI OTO (PRG, $D000, 475 bytes)
* TITL PRO (PRG, $6100, 21230 bytes)
* AGL HEX (PRG, $CEB0, 4432 bytes)
* END PRO (PRG, $A5F8, 620 bytes)
* SI PRO (PRG, $A5F8, 8554 bytes)
* TITL BG (CHR, $1000, 3280 bytes)
* END BG (CHR, $1000, 4080 bytes)
* END OB (CHR, $0, 3072 bytes)
* SI BG (CHR, $1C00, 1024 bytes)
* SI OB (CHR, $C00, 896 bytes)
* REG BACK (PRG, $6000, 256 bytes)
* REG SAVE (PRG, $6000, 256 bytes)

Disk: 1
Side: B
No of files: 17
* CH OTO (PRG, $D000, 417 bytes)
* TO OTO (PRG, $D080, 346 bytes)
* RI OTO (PRG, $D000, 468 bytes)
* SO OTO (PRG, $D000, 409 bytes)
* CH PRO (PRG, $A5F8, 10249 bytes)
* RI PRO (PRG, $A5F8, 9615 bytes)
* SO PRO (PRG, $A5F8, 9645 bytes)
* TO PRO (PRG, $A5F8, 9198 bytes)
* TO DATA1 (PRG, $C9E4, 1650 bytes)
* TO DATA2 (PRG, $C9E4, 1486 bytes)
* TO DATA3 (PRG, $C9E4, 1499 bytes)
* CH OBJ (CHR, $C00, 832 bytes)
* CH BG (CHR, $1C00, 560 bytes)
* RI OBJ (CHR, $C00, 944 bytes)
* RI BG (CHR, $1C00, 832 bytes)
* SO OBJ (CHR, $C00, 896 bytes)
* SO BG (CHR, $1C00, 720 bytes)

Does this mean I have inside the files marked as CHR for the data?  (PRG must be sprite data files, I assume.)  I guess this means I can copy (from the FDS file) and paste (outside of it as an individual file) to find the text therein and try calculating pointers that way?

Please excuse me if I sound like a total moron when it comes to FDS ROM Hacking.  This is something VERY unfamiliar to me, and I'm trying to learn as much as I can from "the experts".

I'm going to have to read a bit more when it comes to hacking FDS ROMs...   

Edit:  For what it's worth, I used FDS Explorer to extra the file within the FDS ROM called "TITL PRO" (which I saved as "TITL PRO.bin") and found the text I had mentioned earlier therein.  These are the offsets of the text located inside the file...

0x39B = Flip to Side A (1 Space extra)
0x3AA = Flip to Side B (1 Space extra)
0x3B9 = I'mDead (1 more space needed here)
0x3C0 = Continue (2 Spaces extra)
0x3CA = Save (2-3 Spaces extra)

Edit II:  According to FDS Explorer, the file "TITL PRO" is at the address $6100.  With the offsets I have discovered for the text entries, does this mean what I'm looking for is this?

"Flip to Side A"  $6100 + 39B = $649B
"Flip to Side B"  $6100 + 3AA = $64AA
"I'mDead"  $6100 + 3B9 = $64B9
"Continue"  $6100 + 3C0 = $64C0
"Save"  $6100 + 3CA = $64CA

Is this how it's done?  Or am I WAAAY off in my calculations here?

[KingMike]

Those pointers sound correct.

PRG/CHR indicates which of the NES' RAM it should be loaded to. (PRG-RAM or CHR-RAM)
Thus PRG is program code/data, CHR is graphics.