There's some fundamental misunderstandings going on here. You need to understand how systems work in the first place, as this will help you understand why things work as they do. Let me try to break it down real quick.
A CPU is just a calculator. It's fast and can take various instructions, but basically it's just a calculator. Look at this number, add to it, multiply it, put it here, go here if it equals whatever. So those hex values in a ROM are just numbers to give this calculator. Some of them are interpreted as instructions, but often it's just numbers (that can be used for anything - graphics, levels, music, logic etc). This is why you can't look at some hex and say exactly what it means, because it means what the programmer wanted it to mean.
Case in point: I'm translating an NES game, and the background graphics are done in two ways: either listing every tile that's used in an area of the screen (for details like text), or saying where on the screen to put it, which tile to use, and how many (for repetitive things like borders and the logo). Why? Because the NES is hardcoded to do that? No, because this particular programmer wanted to do it this way. The end result of these two methods is the same: changing bytes in the PPU that dictate what is on screen at any moment. They just get there by different means, because the programmer wanted to save ROM space for the instructions. It's quicker to say "fill 20 spaces of the screen with tile 6B" rather than "here's the tiles: 6B6B6B6B6B6B...".
Of course, some things are generally the same: the way systems determine graphics, or palettes, for example. But in the end it's just programmers typing numbers into a calculator.
But if you can learn a thing or two about assembly, and how your chosen system works, and then use good debugging emulators, you can figure things out pretty quickly.