The NES can address 4 name tables, arranged in a 2x2 grid, and cartridges are able to map memory differently in this space. Having more than 1 screen worth of background graphics is mostly useful for scrolling (which Dr. Mario doesn't do, so it ended up using single screen mirroring, as indicated at the bottom of that screen), but it could serve other purposes too. The NES doesn't even have enough built-in memory for mapping unique screens to all 4 slots, so any game using more than 2 unique name tables at a time needs extra memory inside the cartridge. Few games do this, though, and from a programming point of view, it's hardly necessary.Deemar wrote:- Why does the nametable viewer show the screen 4 times?
For some good name table viewing fun, fire up games that scroll in all directions. It's always fun to see how new background data is constantly loaded, overwriting the parts of the level that you leave behind as you play.
Because the first palette defined by the game you're playing is mostly blue. This is the pattern table, where the raw tiles are stored. NES tiles are only 4 colors, and the emulator will only know which palette each tile will use when they're used in the name tables (the attribute tables are used for selecting background palettes), or when sprites use them. The obvious solution is to allow the user to cycle through all the palettes (with a right button click? I'm not sure) if you really need to see the correct colors for specific tiles.Why is everything in the PPU viewer a shade of blue?
Some emulators try to be smart and remember what palettes are used for which tiles and reflect that in the pattern viewer, but that doesn't always work because the same tile can be rendered using different palettes (I'm sure you noticed recolored enemies or blocks when playing NES games) and some tiles are never used at all by the game (would these be black?).
EDIT: As for the usefulness of each debug screen, you'll surely find yourself using some of them more frequently than others. The RAM search for example is mostly used for cheating. You can, for example, get hit and search for every byte that its value decreased since the last check. Do that a couple of times and you're likely to find the variable that specifies how much health you have, so you can freeze it or create a Game Genie code to patch the code that manipulates this address. Not useful for homebrewing, since you know where all your variables are.
The PPU debuggers are the most useful IMO, along with the 6502 debugger. By watching the pattern and name tables you can easily see if all the graphics are being put where they should be, and the 6502 debugger is insanely useful to see if your logic is doing what it's supposed to. There you can step through the code instruction by instruction and see how they affect all the CPU registers.