[rullion]

I'm very confused about how offsets work in assembly. Let me give you an example:

I thought the NES was supposed to be 8 bit, but the offset like "0x000000" only shows six bits. And sometimes I've seen the offset as four bits. What's going on? Can someone clue me in what I don't get?

[nesrocks]

Those are not bits, those are digits in the hexadecimal addresses. The nes CPU can access addresses ranging from 0x0000 to 0xFFFF, but the ROM can be much larger. This is what mappers are for, they are configured to take one specific section of the ROM and set it to an address range the CPU can access.
Though the RAM address range only goes from 0x0000 to 0xFFFF (thus requiring only 4 digits), the ROM section usually requires more, so I imagine they just show 6 digits in both for simplicity's sake.
Mind that "RAM" in fceux hex editor is a loose term. It's really actually the full length of what the nes cpu is currently seeing, which includes RAM and the mapped ROM section.
Refer to this: http://wiki.nesdev.com/w/index.php/CPU_memory_map

You may want to do some research on what bits and bytes are, in case there's confusion there.

[rullion]

Those are not bits, those are addresses in hexadecimal.

What then determines the length of the hexadecimal address then? I can get that $ refers to a memory location, but I see different "0x" hexadecimal values like 0xFF or 0x10FA or 0x000001. Why is there a difference because it's really confusing me.

Also, why does some hex editors like HxD go up to eight digits such as 0x00000000. You said the NES only goes up to 0xFFFF, but why would another hex editor stop at eight? I'm just trying to understand the lack of consistency when it comes to hexadecimal digits in the offset. Sometimes I see 4 digits and some programs I have seen go 8+. Are there just zeros beyond the number such as 0x1234?

[KingMike]

0x is usually used to refer to values (numbers stored at addresses) whereas $ is used to refer to addresses themselves.

There is also a difference between CPU address and ROM address.
8-bit CPUs (such as used in the NES) will only have a 16-bit addressing capability (thus 16 bits = 4 hex digits). That means typically CPUs in cartridge-based 8-bit consoles would have a 32KB ROM limit (16 bits equals 64KB, but consoles usually needed to reserve some space for RAM, and if they were using memory-mapped IO, reserving some space for that, too. It was usually logically simplest to just divide that memory map down the middle. Even if it was something like the Genesis memory map, where as I understand, battery-backed games usually split the 4MB address space down the middle, even though a 2MB save would've been **** huge for a 16-bit era game. ).
To have ROM bigger than 32KB usually required a mapper. Mapper breaks the ROM (which itself can be any size as long as mapper can support it) down into banks, so that while only 32KB worth of "banks" can be accessible at any one point, the game can immediately swap them out as needed.

[nesrocks]

Also, why does some hex editors like HxD go up to eight digits such as 0x00000000. You said the NES only goes up to 0xFFFF, but why would another hex editor stop at eight? I'm just trying to understand the lack of consistency when it comes to hexadecimal digits in the offset. Sometimes I see 4 digits and some programs I have seen go 8+. Are there just zeros beyond the number such as 0x1234?

Hexadecimal digits are no different than decimal ones (other than the base). Meaning you can have as many zeroes to the left as you want. 00000098 apples is the same as 98 apples. The hex editor can have as many zeroes as it wants and the only difference it makes is visual. So it will logically have as few zeroes as it needs.

If you're still very confused (I know I was when I was hacking Super Pitfall) it may help to hack a mapper 0 game first, to get used to things. It took me a while to understand what a mapper does, and it didn't help at all that I had so many more basic things to understand first.