Also, I'm curious about how hex works in general. This might have to do with the physical hardware, but how does the NES know what each value means? Like how woud it know "A3" is the brown/black color palette for a sprite? How is that defined?
The people who made the game had a certain amount of ROM where they could put the game, the system had a certain amount of RAM for temporary variables for the program running and the system could emit graphics and sound. They worked systematically so that a number in a given location had a given meaning. As long as they sticked to that, the number was only used for that thing and consequently, if you edit that number, it changes that specific thing.
The whole system is a big bunch of numbers and the CPU mostly just moves them from one place to another and sometimes does simple math on them. The CPU does it by having a list of numbers defined as actions (by hardware, moving numbers and simple math, that is). When the system starts the CPU reads the first number in a known place and does the action the number represents. After each action is done it reads the next number, and this continues.
The real magic is that the system has certain places, where when you put a number (or enough numbers) in a certain way, audio or graphics come out. So it is a combination of code being systematic and these input/output locations in memory. Input for reading the controller, of course.
Sometimes you can figure out what numbers in the ROM mean because they are stored in a nice order. Like, if you had a list of prices in some shop, and they happened to be stored in a way you can guess (a list=table in the same order as they appear in the game and each price taking 2 bytes, for example), then you could search for a hex string with a hex editor with a bunch of the prices glued together, and it would then find that exact spot (and it is unlikely any other number sequence would be exactly the same, so this usually works easily if it works).
With computers and hex values longer than 1 byte, you have to always pay a bit of attention to whether the values are stored little-endian (least valuable byte first) or big-endian. The numbers people use in everyday life are neither, because they don't consist of bytes, but big-endian looks very similar otherwise, just with the byte gaps. I have no idea how a given NES game would store 2 byte prices, so I'd try searching for both orders. NES only supports 1 byte math, and anything more complex is written in code in a multiple command sequence, which could eat the numbers any way the coder thought of.
However for many things a debugger emulator like FCEUX is more reliable than guessing, although there you must pay some of your time to get the more reliable answers. It basically lets you read the code, but you need to be able to understand what the code means and you need an "attack plan" on how to find the code (or data, but they are closely related as data is given a meaning only by the code). Breakpoints are the most common tool in most attack plans. You can check the debugger in FCEUX even if you don't expect to be able to use it, because if you get the basic concepts, you pretty much start to understand everything.
One of the very basic problems is that there are a lot of numbers (several magnitudes more than most people would find comfortable) and it is slow to read even small amounts of them, be it reading code or looking at data. But hey, it takes a lot of time to complete the game itself too..
I don't know the perfect attack plans for your problem examples (and I don't know if Maeson or Kea would already know enough to solve them quickly), but I'll try to list something that comes to mind:
1. Changing the "Life" spell from being level 5 White Magic to being level 4 White Magic
- when you equip LV5 and LV4 magic they end up to their respective lines. this is a difference that touches something much related to the problem (code)
- when you have them equipped vs not equipped, that difference shows in RAM too (location for a breakpoint)
2. Editing maps
- encounter background is different on different terrain
- ships cannot travel over land
- airship cannot land on mountains
- no encounters in safe areas
3. Setting what jobs are obtained from what Crystals
- somewhere during when you gain the jobs, code touches this
- job selection menu touches jobs
4. Editing text boxes
- text or boxes? well it is a bit boring for me to think about
@Bregalad
I found, like, 43 sequential unused bytes when I did my little hack. There's plenty of space!! (I hope it is unused)
It isn't so much of a problem for modders though, they usually just change existing bytes. Only adding more text, if that text boxes means that, would apply in the first post here.
Topic: Is there anything that cannot be edited via Hexadecimal? (Read 9678 times)