[koko82]

Hi All

New n00b to the forum, trying to convert a NES file into something more readable to view source code (want to manipulate the game timers). However, I have got the HEX information up, but little confused on how you correlate the letters to a table. Do you simply run through HEX & ASCII columns and pick out letters to make the table. I've seen a few articles, but don't go into depth on howto decode it all. I

koko82

[henke37]

Hex display is already mapping the data to a table. What you want is to interpret the data and code correctly. The first step to interpreting anything correctly is to figure out which language it is in. A lot of the rom contents is executable code. At best you will be able to show that as assembly code. But some will be "data", whatever the game program needs to use. Said data can be anything, text, graphics, numerical tables, tilemaps, palettes, music, a custom programming language, anything.

[koko82]

How is it mapping the data to a table, as your reading the file in a HEX formatt. To de-encode I though you will need to create a .tbl and use it to load the mapped hex values to it.

So viewing the hexcode its almost impossible to decipher what it means. So need to know a focal point to work from or pattern.

[henke37]

You do know what hex is, right? It's just base 16. Two base 16 digits is just enough to show the value of one octet of the data.

Allow me to speak very clearly: Not all data in the rom file is in the same format. It is fundamentally wrong to interpret it all as the same format.

[koko82]

I understand in hex you have to map it to a character set. Not exactly mapped to an ascii standard. So I could pass lots of different hex table types to uncover different parts of code if I understand correctly.

[chillyfeez]

It's a common misconception among people with programming backgrounds that having prior knowledge and/or experience with modern programming languages and methods will be a great deal of help in learning ("retro") video game console assembly languages.
The logic is essentially the same, but the similarities pretty much end there. Theoretically, a person with zero programming experience but a couple of college level logic classes under his/her belt would have just as easy a time (consider me exhibit A).
Consider - when a typical modern executable runs, it's constantly referencing .DAT files, image files, whateverthehell else. There's one binary running, but it is constantly drawing data from a storehouse pof neatly organized files, the missing of any of which would render the program unrunnable. In a ROM, all of those extra files are packed right in, and usually just wedged into the ROM wherever they happen to fit, not in neatly separated compartments of the file. So you could have 1255 bytes of assembly language immediately followed by 2001 bytes of image data, followed by some more assembly that breaks in the middle for a table of character stat data... Whatever. It would be nearly impossible to simply look at a NES ROM in a hex editor and understand everything you're seeing.
To make matters worse, Nintendo purposely made the methods by which ROMs manipulate NES hardware extremely cryptic in order to make unlicensed game development difficult.
I personally never studied NES assembly (my medium is SNES), but I can tell ypou that what you'll want to use to get a started would be:
1) a file that lists all NES assembly commands
2) some type of resource that explains how these commands work together to make a game happen
3) a debugging emulator, so you can see all this stuff happen live in a game as it's running (this is probably THE most important thing, actually - with enough time and motivation, one could learn everything just by fiddling around with one of these)
4) ideally, experienced people who can help you figure it all out. Unfortunately, breaking in to the hobby can be tough sometimes, because gamer nerds tend to be a bit elitist, and a lot of people won't see the point in helping but will be all too quick to discourage and insult you. Sad but true. From what I hear, the folks at nintendoage.com are an exception to this - I've heard only good about how helpful they can be - but I think they tend to focus primarily on homebrew games, not hacks.

So, that's all I've got for ya. Learning all this isn't easy, but it's certainly not impossible. Just... Abandon your assumptions about how it all works first.
 

EDIT
also, the only thing using a tbl in your hex editor will ever help you do, really, is manipulate the text in the game

[Rotwang]

It would be nearly impossible to simply look at a NES ROM in a hex editor and understand everything you're seeing.

To be fair, there have been times where I have accurately guessed the contents of a block of data without being led there through any other means than just scrolling through in a hex editor, but then again that kind of shit comes with prolonged exposure. I doubt I'm the only one here who's done that before.

Koko82, if you want to get acquainted with how the NES interprets ROM data and also demystify the whole "what the fuck am I looking at?" aspect of first gazing into the abyss of a hex editor, first you have to forget about this whole "correlate letters to a table" idea because I can tell that it's leading you off-target. The ASCII view in a hex editor is just peripheral to the hex view, as the hex view can convey much more information once you know what you're looking for. You should get FCEUX (if you don't already have it) and load up your ROM. Open the debug window (F1) and click on "Step Into." On the left panel you will see that every time you click on "Step into" there's a bunch of lines of code that skip forward. What you are seeing is the same hex data you found in your hex editor, but being interpreted as instructions. For example:

$C0A1:A5 2C    LDA $002C = #$00

Green is the address of the current instruction. This does not necessarily mean that you will find this code in the same address in the ROM file, because the NES's processor maps the data out differently, but that's a whole other subject.
Blue is the hex values of the current instruction. This means that somewhere in your ROM, you will be able to find this same A5 2C and overwrite it with something else.
Orange is the same data we saw in blue, but represented in mnemonics. This particular instruction, A5, is LDA, or LoaD A, which fetches a value from somewhere in memory or in the code itself. In this case, it's getting a value from one of the first 256 addresses in RAM, specifically $2C.
Brown is the current value of $2C, which happens to be zero.

However, maybe there is a graphic somewhere in the ROM that just happens to have the same sequence A5 2C. It's the same 2 bytes, so it can be (accidentally or deliberately for the sake of experimentation) read by the processor as a potential instruction. Just like when you open a ROM in a tile editor and you see a bunch of scrambled static-looking tiles, that's just data in the ROM that happens to not be image related, but represented as an image. You can fuck up the code of a ROM and break it beyond repair by messing with those areas in a tile editor. It's all just different ways of viewing the same data.

The best way to learn is to fuck around with it and see the results, and actually want to learn it.

[Dr. Floppy]

Indeed, whenever you see chunks of data making use of 0's, 5's, A's and F's, you're almost certainly looking at Attribute Data (since that's just what that sort of thing usually looks like).