You will, without fail, find only two and only two different things in your ROM - data and code. That's it.
The data, which makes sense within the context of the code, often seems like stuff that makes sense and has other names in other languages. You may find data that looks like text, you may find data that looks like a font, or some pictures, or data that tells the game where to find other data, but when it comes down to it, it's all just data. What the game does with the data is important, but if you approach assembly-level programming thinking of a font or of pictures instead of raw data manipulation, you're going to get incredibly confused and you're not going to be able to do a whole hell of a lot. This is, in fact, largely the point of this whole chapter of The New Romhacker's Bible -- if you take anything away from this document, be it this! When I was first doing font work, I was quite lost because I thought I was dealing with font tiles instead of a series of bytes that look like font tiles.
The other thing you'll find in the rom is code. Code, unfortunately, masquerades as data more often then not. Unless you've been dealing with assembly for a long time and know to look for certain patterns of bytes, you're probably not going to be able to tell the difference between data and code. As such, when you're first starting out, unless you're specifically breaking ("corrupting") large chunks of ROM in an effort to locate, say, map data, the rule of thumb should be that you should not change anything if you're unsure of what it is. That, and always keep a backup!
That's WinHex32 up there, a great (albeit work-in-progress) hex editor by romhacker extraordinaire Bongo`. Aside from your standard conventions such as the menu bar, scroll bar, and title bar, every decent hex editor has three major features, and WinHex here is no exception. As you can see in the main body of the window, the main editor has three columns. The left-most is the file address, the middle one is the raw hex data (DATA!), and the right-hand pane is the ASCII equivalent.
The first and probably most complicated column is the left-hand one, the file address column. Notice that there are sixteen rows, and it counts by 0x10. Each row in the middle and right-hand pane displays 16 bytes of the open file (in this case, "madoue.smc") and the file address column attests to this. You'll probably want to fire up WinHex yourself, open up any old file, and move the cursor around with the arrow keys. Watch how the "offset" field down at the bottom changes as you move the cursor left and right, up and down. That'll help you get a feel for how it works. It really isn't something I can explain in writing, it's something you're going to have to get the hang of yourself.
The middle column shows the raw hex for each byte of the file. If you open up a 543 byte file, there will be a total of 543 different bytes in the middle column. Each pair of digits (FC 00 2D 24 1E and so on) represents a single byte, which can have any of 256 (0xFF) different values. Please see Chapter 1 for an explanation of how hex works. If you change one of the bytes in a file and save it, the change will be reflected in some way when you open the file in the program that was meant to run it. If you change a byte in the middle column, the right-hand column should immediately reflect the change. More on that next.
The right-hand column is important. As a beginning text hacker, you will probably be using it more than the middle for editing a file. It contains the text equivalent of the data (DATA!) in the middle column. If you open a standard .txt file up in a hex editor, the right hand pane will show the text, as it is stored as American Standard Code for Information Interchange, or ASCII, which is the "standard" hex-to-text data (DATA!) across personal computer platforms. Most ROM files will not store their text data (DATA!) as ASCII. In this case, I have a standard .tbl file - an equivalency table, or just a "table file" or "table" for short - loaded into WinHex to get Madou Monogatari's text displayed properly in the right-hand column. In the next chapter, where I cover basic text editing, I will do my damnedest to find a ROM that uses standard ASCII for its text before progressing to slightly more difficult things - tables.
One more small thing before ending the chapter, and that's the status fields down at the bottom of WinHex's window. The first thing it displays is the decimal value of the byte you've selected. Right next to that is the hexadecimal value of the same, followed by the actual offset of the cursor in the file (try moving it around and watching it change!) and a percentage to tell you approximately how far into the file you are. In this case, we're 17% of the way through the file. It also shows you what the ASCII for the capital letter A is, but it doesn't seem to update that with the table so I have really no idea what use it is, heh. Any good hex editor should have most or all (minus the Asc A='41' thing) of these features, if not more, in its own status bar.