News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: Question about how game code works  (Read 1031 times)

devonm0

  • Newbie
  • *
  • Posts: 3
    • View Profile
Question about how game code works
« on: September 23, 2019, 04:06:57 am »
How does the referencing of data work in ROM files?  How do you change what position in the code is referenced by an existing pointer?  Is it possible to make such a change in a plain hex editor?  Are there any general use programs that can help with this?  The game I'm modifying hardly gets any attention, but it's the one I'm most familiar with modifying in small ways and I've run into a snag because I need to change the referenced location to make it work right but I don't know how.

FAST6191

  • Hero Member
  • *****
  • Posts: 2589
    • View Profile
Re: Question about how game code works
« Reply #1 on: September 23, 2019, 01:00:13 pm »
That will depend somewhat upon the mapper the game uses (or that you hacked it to support).

To work it tends to pay to have your game accessible. Various devices have various ways of effecting a read from storage (DMA aka direct memory access, direct reads from CPU instructions, and BIOS/firmware functions being the big three, with some CD consoles and later device firmwares having something more like a chip moderating access to things) but the NES is a bit simpler so you don't have some of those things just mentioned.
https://wiki.nesdev.com/w/index.php/CPU_memory_map
https://wiki.nesdev.com/w/index.php/Mapper
https://wiki.nesdev.com/w/index.php/CHR_ROM_vs._CHR_RAM
You would then be looking for things looking at the relevant parts of the ROM and accounting for what the mapper does here. Sometimes a given bank might be full which means you either get to optimise or see about claiming space on another one and sorting the setup that falls from that


As the hex editor can alter any part of the ROM then yes you can. You can do any hack you like with a hex editor. Generally though it is a bad plan for anything but the smallest of hacks, and even then that will likely be after you have figured out what to do thanks to some combo of disassembly, emulator and your notes.

Pointer calculators exist for some things but for the most part that is more of a format conversion thing, cheat making helper (though probably not for the NES) and such rather than something that will recalculate things for random NES games.

devonm0

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Question about how game code works
« Reply #2 on: September 23, 2019, 05:57:28 pm »
Somehow it completely slipped my mind that I should have been specific with the game I'm modding.  Honestly it never occurred to me that it could depend so much on which game it is, though in hindsight I should have known.  The ROM in question is Lufia and the Fortress of Doom/Estpolis Denki for the Super Nintendo.  It's the NTSC version in case there are version differences to the code itself, unedited except for what I've done which is very localized.  If anyone has any experience with modding this game in particular, I'd appreciate the help.

I appreciate the info, FAST, but as I'm not modding an NES game I don't think it'll be much help.  Still, the fault is mine for not being clearer to start, so I thank you for your time.

Psyklax

  • Hero Member
  • *****
  • Posts: 1055
    • View Profile
    • Psyklax Translations
Re: Question about how game code works
« Reply #3 on: September 24, 2019, 06:01:42 pm »
How does the referencing of data work in ROM files?

Do you know assembly at all? If we're talking about the SNES, the 65816 CPU gets instructions to load data from certain places, and these locations are referenced in the instructions themselves.

How do you change what position in the code is referenced by an existing pointer?

Change the instruction, or the pointer table if the routine uses one.

Is it possible to make such a change in a plain hex editor?

Yes.

Are there any general use programs that can help with this?

Er... hex editors? :) Not sure what you mean by this.

Basically, you mentioned the game you were tinkering with, but didn't explain why you needed to get involved with pointers and such. Maybe if you explain your exact problem, it will make more sense. ;)

FAST6191

  • Hero Member
  • *****
  • Posts: 2589
    • View Profile
Re: Question about how game code works
« Reply #4 on: September 25, 2019, 06:04:28 am »
Hmm. Don't know why I had NES on the brain there. It is all pretty similar though whether you are working on a Vic20 or a current device.

So yeah find out how the read protocol for the disc/cart/storage of the system (and style of game if there are multiple) and means by which it can be accessed. Again there is often a function within the system to avoid having to have the CPU bogged down accessing the cart which tends to be called DMA, the CPU itself might have options and there are often extras that are not technically either of those from a code perspective (if you watched the signals at hardware level that might change but if you are playing with code then eh) but will yield data from the ROM.
Sometimes the disc/cart/storage is in memory, sometimes only a sliver of it is (see mapping/mappers/memory bank controllers and more besides) and you change that sliver, and sometimes there is something you first have to ask and it will show the relevant bit (tends to be on later systems or systems with large amounts of storage, though older ones will often have something like it for save games where you first have to speak nicely to the save controller and then read in a certain way).

https://en.wikibooks.org/wiki/Super_NES_Programming/SNES_memory_map
http://problemkaputt.de/fullsnes.htm#snescartridges

"How do you change what position in the code is referenced by an existing pointer?"
Is that not the whole point of the pointer? Most would define pointers as a piece of data within a program that shows the way, points if you will, to another aspect of the code that is theoretically* relevant to the task at hand. It might be more code (think the classic "GOTO" operation), might be a piece of non executable data (text, graphics, music...), might be another pointer (if you learn one of the C family languages you will likely get an exam question which is basically a nest of pointers to pointers to pointers with a few other bits thrown in and you get to decode it to show you really get pointers within the language). The pointers themselves might not be direct memory locations or ROM addresses, and later systems and file formats often do maths on the pointers to get where you need to be, but that is the part of the fun of playing hacker.

*being a filthy hacker you might wish to break a pointer, and you also have things like ROP (return oriented programming) that abuse the concept of pointers to achieve interesting results in locked down systems (not much use on the SNES unless you just want to show off or have some fun).

You asked about programs for it. There might be some and while many games will have pointer after pointer and work either at system memory or file level there will be others that stick something in the middle of each pointer, some that do a bit of maths to it, some that will use the higher bits that are never otherwise used to indicate something (indicating compression is popular here, what directory another though probably not for the SNES).
So yeah someone makes a program to allow people to simply generate the classic list of ?? bit values that are pointers, and maybe add 10h (or whatever you like) to each after a point to account for a shift of so much to fit something longer in earlier on, though nobody changes just one line so you now need a list of changes to calculate or things to reference from. So far so good but then you add the skip bytes for those games that wedge something between pointers, then you ask masking/Boolean options for the higher bits being used, some operations in case you have shifts, the option to regenerate based upon location (some pointers are current location plus pointer value)... and now you basically have a new programming language or something not far off it. As a "general case" is not really a thing then you can't even kick most of that to optional functionality that few ever use (or possibly one of those everybody only uses 10%, but each a different 10%).

To that end my usual approach runs hex editor if it is just one thing I need to change (usually making a size value larger for a file I know the format for or telling one file to look in another location, the classic repoint to use this instead hack, or I can set it up such that I do the change, press down, do the next simple change and so on for probably only still a handful of pointers), spreadsheet (modern spreadsheet programs should support hex out of the box, older ones might need a plugin), briefly consider a ROM hacking pointer management program (again they are often scripting languages unto themselves, and usually geared for systems other than those I play with, which does mean the SNES is an option here. https://www.romhacking.net/utilities/224/ being the classic example, and usually flanked with Cartographer) before saying meh and writing my own program instead.
As far as programming goes then any language you know and care to use will likely do fine here -- even a slow as sin Java program (Java is surprisingly unpopular in ROM hacking circles which I am delighted by but you do you) will likely still only take a few seconds to repoint an entire ROM, never mind just a handful of lines at a time, and it is not like you tend to have to repoint things in a ROM a thousand times a second.
That said spreadsheets are usually enough for a lot of what I do, particularly if I couple it with a program like filecutter ( https://web.archive.org/web/20170218180937/http://min.midco.net/cracker/filecutter.zip ) as combined that gives me a nice extraction tool, and most formats I want to play with have a nice end of file/segment marker I can search for to generate where the pointer should be (if end of file is here then end of file +1 is where the next starts sort of thing).

devonm0

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: Question about how game code works
« Reply #5 on: September 27, 2019, 02:32:55 pm »
My apologies to you both.  I have a bad habit of getting so focused on trying to do something in the way I have in mind that I lose sight of alternative options.  After giving myself time to step back and reevaluate, it finally occurred to me that I just need a text editor that's compatible with the game in question.  Shouldn't be too hard to find.  The issue I was having is that I was trying to add and edit flavor text, and I guess because I was doing it in a hex editor it caused some minor hiccups because with the start point of various bits of flavor text altered in a hex editor, when the game would call the flavor text the reference wasn't right anymore.  It made a mess.

So yeah, the problem was that in my laser focus on that one avenue, I was pursuing a solution that was far from the most efficient.  Still, that's some good information for when I inevitably take my hacking of the game further, and I appreciate your effort and attempts to help.  Especially you FAST, though I might not need them for this little excursion after all, those references sound like they'd be worth looking at.  For the record, I have no experience with programming languages.  Might have to look into changing that.  Anyway, thanks again.

...5 hours later...

I don't know why I thought it'd be straightforward.  I should have known that because game text is written into the game's code in a way that converts directly to hex, that there would be more to it than to expect some kind of plug 'n' play editor like I'm used to.  Well, that's that.  In that regard I'm stuck for now.  Won't be able to progress until such a time as I'm able to understand the particulars of it instead of the touch and go process I've been able to rely on for the less invasive modding.
« Last Edit: September 27, 2019, 07:24:27 pm by devonm0 »

Chicken Knife

  • Sr. Member
  • ****
  • Posts: 296
    • View Profile
Re: Question about how game code works
« Reply #6 on: September 28, 2019, 12:59:41 pm »
Sounds like you need to start looking at software like Cartographer that spools out a game's text and Atlas that inserts it back into the rom, automatically adjusting all the pointers to the new locations for the text strings. abw recently developed a more refined piece of software that incorporates and improves both of those, abcde. I've been using it for new 8 bit Dragon Quest translations and there is a lot of information you could read in the Dragon Warrior 1, 2 and 3 hacking questions thread related to my process of learning the software.