Questions about NES programming and architecture

[Secamline]

Hi! I'm new to this forum although I've been visiting for quite a while. I've been messing with 6502 programming on the NES several times in the past but didn't accomplish much. The only game I've ever managed to complete was an Atari 2600 game I made in 2016, so let's face it, I won't be making a fully fledged NES game any time soon.
Still I'm glad programming for the NES did help me get a good understanding of the system. Yet I think it is rather incomplete and/or partially wrong. So I made this oversimplefied diagram of the most basic NES setup out there.



As far as I know, most NES games have at least two separate ROM chips. PRG ROM for code, palettes, nametables, etc... and CHR ROM (or RAM) for pattern tables. I know some games store compressed versions of their pattern tables into PRG ROM but I have no idea how the PPU has access to the graphics in this configuration>.
So far, I've noticed that most asm codes store the actual code and the pattern tables into two different banks. At first it made sense to me, I thought this was a virtual representation of the two physical chips. But then I noticed the interrupt vectors ($FFFA-$FFFF) were also stored in a different bank, even though I assume those are part of the actual PRG ROM chip in a real NES cartridge.

Also I'm not sure wether the audio and video signals generated by the APU and PPU respectively are directly sent to the TV or sent to an intermidate component. If I'm nost mistaken, some NES's have an RF output, soI guess they have a built-in RF modulator that outputs both audio and video as a single signal.

If you could help me understand the NES architecture better and tell me if there are any mistakes on the above diagram, I'd be very pleased.
Thanks in advance!

[tokumaru]

This looks about right to me. Maybe the arrow between the CPU and the PPU should point to the CPU as well, since there are read-only PPU registers that the CPU can use to get information from the PPU.

Also, you could probably improve the way in which VRAM and CHR-ROM are represented... You see, even though they're separate chips, this fact is irrelevant to the PPU, which sees the whole thing as a contiguous block of memory. There's also the fact that the NES gives the cartridge full access to its memory bus, and the cartridge can map anything it wants in the whole PPU memory space, not just the pattern table part. VRAM/VROM is split between the console and the cartridge.

I know some games store compressed versions of their pattern tables into PRG ROM but I have no idea how the PPU has access to the graphics in this configuration>.

The CPU has to decompress/copy the data from PRG memory to CHR-RAM so the PPU can read it from there. From the point of view of the PPU it doesn't matter if the CHR memory is ROM or RAM, it will simply read tiles from whatever memory is mapped at $0000-$1FFF in its addressing space. If that memory happens to be RAM, it will be "empty" on power up and it's the responsibility of the program running on the CPU to fill that memory with meaningful data.

So far, I've noticed that most asm codes store the actual code and the pattern tables into two different banks. At first it made sense to me, I thought this was a virtual representation of the two physical chips. But then I noticed the interrupt vectors ($FFFA-$FFFF) were also stored in a different bank, even though I assume those are part of the actual PRG ROM chip in a real NES cartridge.

The concept of a "bank" isn't very well defined on the NES. As far as the console itself is concerned, there are no banks at all, all it sees is a contiguous block of 32KB of memory. Banks are only a thing when mappers step in and subdivide that 32KB memory space into windows that can have different parts of a larger memory chip mapped to them.

There's nothing mandating that certain kinds of data go in certain banks, programmers are free to organize their data as they see fit. The interrupt vectors don't necessarily go in a different memory bank either, but they must be visible to the CPU at addresses $FFFA-$FFFF (i.e. the very ends of its addressing space) at all times, and how that's accomplished might differ from mapper to mapper and how they map the physical memory to those addresses.

You may have reached this conclusion from how NEASM uses the .bank directive, but that assembler was originally created for the PC Engine/TG-16, a system that apparently does use 8KB banks intrinsically, so you are forced to break your programs into 8KB blocks whether you're using bankswitching or not.

Also I'm not sure wether the audio and video signals generated by the APU and PPU respectively are directly sent to the TV or sent to an intermidate component. If I'm nost mistaken, some NES's have an RF output, soI guess they have a built-in RF modulator that outputs both audio and video as a single signal.

I think there's some minor processing of the signals going on (amplification, filtering, etc.), but I don't see that as a separate unit that should be included in this diagram. Also, analog signal processing is largely irrelevant from a programming standpoint, which seem to be the focus of your diagram.

[Bregalad]

The WRAM label in the console is probably incorrect, it should simply read RAM. As far as I know WRAM is a term used for optional extra RAM on the cartridge typically at $6000-$7fff. At least when refering to terminology printed on Nintendo-made PCBs.

Since NES-related terminology is almost always controversial and vague, because of termonology used by Nintendo and various reverse-engineer and emulators are different, partially overlapping and partially disagreeing, I could be wrong.

And the CHR-ROM label should really be CHR-ROM or CHR-RAM. About half the game library has one, and the other half the other. It's really interesting how each one of those has its benefits and drawbacks compared to the other. As far as I know, the NES/FC platform is totally unique in this regard, I know of no other retro console/computer has only ROM, RAM or if there's a combination of two the ROM is only in the computer, such as the C64 where the character set is in ROM.

[tepples]

Neo Geo MVS/AES is the other platform with CHR ROM that gets trotted out.

On Super NES, "work RAM" (WRAM) refers to the RAM inside the Control Deck connected to the CPU. The package is marked "S-WRAM". On Game Boy, the community appears to have adopted "WRAM" for memory inside the main unit and "SRAM" for memory inside the Game Pak, but then no licensed Game Boy games have RAM on the cart without a battery.

[Secamline]

Thanks for your answers!
I tried to at least partially fix the issues you pointed out, however I can't seem to find where the OAM fits in the PPU's address space.

[tokumaru]

I can't seem to find where the OAM fits in the PPU's address space.

It's exactly as you've drawn - the memory is physically inside the PPU. It's the same for the palettes: even though we access them using normal VRAM addresses, they are internal to the PPU, which hardwired them to specific VRAM addresses.

I'm not sure I'm a fan of how VRAM/VROM is pictured though... Even though it's true that the cartridge USUALLY contains the PPU memory from $0000-$1FFF and the internal VRAM is usually visible at $2000-$3FFF, this isn't hardwired, and can be controlled from the cartridge side.

The cartridge connector has a pin called "CIRAM /CE" which tells the NES when to enable its internal VRAM chip. The cartridge can keep this chip permanently disabled and provide the entirety of the video memory. It can also do the opposite, keeping the internal RAM permanently enabled and provide no video memory at all, meaning that the internal 2KB will be mirrored across the entire $0000-$3FFF space and be used for everything (pattern, name and attribute tables).

I don't know if your plan is to draw an accurate diagram, or just the common case, but this is something to consider.

Another thing to consider are mapper chips, which can get newbies a little confused.

[dougeff]

Right. I would add a chip in the cartridge, possibly 2.

-memory management controller, MMC (the mapper chip)
-SRAM (battery backed RAM, usually $2000 bytes... usually mapped to $6000-7fff)

Or just say "optional expansion hardware".

In japan, sometimes, the cartridge could have additional audio hardware.

Edit, I like how you have a little bubble to the side of the cartridge for CHR-RAM. Maybe add another bubble on the other side for the things I mentioned.

[lidnariq]

The WRAM label in the console is probably incorrect, it should simply read RAM. As far as I know WRAM is a term used for optional extra RAM on the cartridge typically at $6000-$7fff. At least when refering to terminology printed on Nintendo-made PCBs.

Nintendo used the same "WRAM" label on the NES mainboard.

[Bregalad]

Nintendo used the same "WRAM" label on the NES mainboard.

OK so as I had myself guessed, I was wrong ^^
I suppose CPU RAM at both $0000-$07FF and $6000-$7FFF can be considered "WRAM" regardless whether it's on the cartridge or on the main board.

Or just say "optional expansion hardware".

I'd go for that. Many games doesn't have any mapper, and of those who do have one, most don't have cartridge WRAM.
This makes it very clear the cartridge is responsible of expanding things further.

[Dwedit]

Some things you wouldn't get from that diagram:

* Cartridge can control nametable mirroring. In addition to the usual address lines to the cartridge, there are a few address lines that are output from the cartridge back to the system. These tell the system which nametable to use.

* PPU can be read, so the arrow doesn't just point to the right. (I see this was already fixed) PPU status is read for checking for sprite 0 hits, PPU triggers Non-Maskable-Interrupts, PPU memory (including character ROM) can be read by the CPU, and so-on.

[Secamline]

I'm actually learning a lot from this, thanks! I will update the diagram, but first I'd like to make sure that I understand everything.

So, the CIRAM/CE pin tells the PPU wether to enable the VRAM (which I just learned was also called CIRAM to add up to the confusion) and/or CHR ROM/RAM, right? So if the VRAM is disabled, the CHR chip provides nametables and palettes ontop of pattern tables? I assume this means that CHR RAM is used instead of CHR ROM. I guess this also means that CHR RAM is larger than 8K in this case. Does it mean that addresses $2000 through $3FFF are then mapped to CHR RAM?
Also, if CHR ROM/RAM is disabled, where are the pattern tables stored in the PPU's memory map? And what are PPU addresses $0000-$1FFF mapped to?
I might have just gotten things wrong so if you could clarify this point, it would help my dumb brain.
Also could you tell me which chip in the cartridge the CIRAM/CE pin is connected to.

As for the mapper chip, I actually wanted to include it, but I simply couldn't find much information about mappers, so I don't fully understand how it works. If I were to take a wild guess, I'd say the MMC chip tells the PRG and CHR chips which banks to expose to the CPU and PPU, but again I might be completely wrong.

I didn't include the additional audio chip simply because I had the western NES in mind.

[aa-dav]

I'm actually learning a lot from this, thanks! I will update the diagram, but first I'd like to make sure that I understand everything.

So, the CIRAM/CE pin tells the PPU wether to enable the VRAM (which I just learned was also called CIRAM to add up to the confusion) and/or CHR ROM/RAM, right? So if the VRAM is disabled, the CHR chip provides nametables and palettes ontop of pattern tables? I assume this means that CHR RAM is used instead of CHR ROM. I guess this also means that CHR RAM is larger than 8K in this case. Does it mean that addresses $2000 through $3FFF are then mapped to CHR RAM?

Internal NES VRAM (2Kb) is used for nametables - it's like videopages for character mode in PC with character images in CHR area. The ability to do per-pixel scrolling is the only difference of NES PPU and regular text videomode of regular PC of the same era. CIRAM/CE (or another name - VRAM /CS) is signal for enabling this VRAM chip. Note that in schematics every ROM/RAM chip has "chip select" input pin which enables/disables this chip and this is how we connect multiple chips to single data/address buses - we just enable only one chip from them and this is how they do not interfere. "Chip Select (CS)" line is crucial thing in schematics and it is built around demultiplexers of upper address lines usually.
So, VRAM/CS is just this enable input for VRAM chip (not CHR!). This gives you ability to provide own VRAM chip on the cartridge. For example with 4Kb of full 4 videopages (internal VRAM has 2 videopages only of 4 possible).
If you want to use internal VRAM you just connect PPU /A13 line to VRAM/CS line because this is it. PPU address space is built in the way to povide A/13 is '1' during accessing VRAM only (not CHR, not palettes). So it could be made without demultiplexer in this simple way.

As for the mapper chip, I actually wanted to include it, but I simply couldn't find much information about mappers, so I don't fully understand how it works.

Mappers are used to have more than 32Kb PRG and 8Rb CHR using concept of 'current page' and a lot of ROM chips or single huge ROM chip. So they provide upper address lines or provide new 'chip select' lines inside cartridge to have more ROM.

[tokumaru]

So, the CIRAM/CE pin tells the PPU wether to enable the VRAM (which I just learned was also called CIRAM to add up to the confusion) and/or CHR ROM/RAM, right?

Well, the CIRAM /CE pin enables/disables the internal VRAM, but it doesn't affect the CHR-ROM/RAM on the cartridge. What normally happens is that the cartridge uses the PPU A13 signal to detect whether the PPU is accessing $0000-$1FFF or $2000-$3FFF, and based on that it will enable either the CHR-RAM/ROM on the cartridge or the internal VRAM (via the CIRAM /CE line), but these are separate operations.

So if the VRAM is disabled, the CHR chip provides nametables and palettes ontop of pattern tables?

Yes, if the internal VRAM is disabled and the CHR-ROM/RAM chip is enabled when the PPU is accessing $2000-$3FFF, the PPU will treat the contents of CHR-RAM/ROM as name/attribute data. This is actually one way to implement a 4-screen name table layout in CHR-RAM cartridges: you just disable the CIRAM permanently and leave a 16KB (or more) CHR-RAM chip permanently enabled, causing it to be used for patterns as well as for name/attribute tables (not palettes, though - palettes are always stored inside the PPU itself).

I assume this means that CHR RAM is used instead of CHR ROM.

It works with ROM too, but the types of games you can make exclusively with ROM name tables is very limited!

I guess this also means that CHR RAM is larger than 8K in this case.

Normally yes, but it doesn't have to be. If it's 8KB or less, that simply means that the memory will be mirrored across the PPU address space, and the programmer will be responsible for deciding which tiles to sacrifice so they can be used for name/attributes instead.

Does it mean that addresses $2000 through $3FFF are then mapped to CHR RAM?

Yes.

Also, if CHR ROM/RAM is disabled, where are the pattern tables stored in the PPU's memory map? And what are PPU addresses $0000-$1FFF mapped to?

If you keep the internal VRAM enabled, then that's what will show up at $0000-$1FFF, meaning you'll only have 2KB for all your tiles and name/pattern tables. I don't recall whether there's an iNES mapper number for that configuration, but there are a couple of homebrew games that use the internal VRAM like that... they're sometimes called "single-chip NES games", because they only have the PRG chip (here's one of those games - scroll down to find the NES version, along with pictures of the "single-chip NES cartridge").

Also could you tell me which chip in the cartridge the CIRAM/CE pin is connected to.

Depends on the cartridge, but the cartridge connector offers both PPU A13 and PPU /A13, so you have both signals readily available to enable/disable any chips you see fit. The "/CE" in the pin's name means that CIRAM is enabled when that line is low, and PPU A13 is high when $2000-$3FFF is accessed, so in most cases you'll probably see PPU /A13 directly connected to CIRAM /CE.

If I were to take a wild guess, I'd say the MMC chip tells the PRG and CHR chips which banks to expose to the CPU and PPU

That is correct. Mappers kinda sit between the CPU/PPU and the memory chips in the cartridge, and the commands they receive from the CPU affect which banks they expose to the CPU/PPU.

[lidnariq]

(which I just learned was also called CIRAM to add up to the confusion)

Also also NTRAM. Because ... we can't make up our mind, or something.

So if the VRAM is disabled, the CHR chip provides nametables and palettes on top of pattern tables?

Not palettes! Despite how they're addressed, palettes, like OAM, are actually inside the PPU.

And "depends". A game wouldn't disable the mainboard's PPU RAM without putting something else there, such as more RAM.

Some games can switch what is enabled in a dynamic sense. The game After Burner uses this to store nametables in CHR ROM, but to be able to use the VRAM at other times.

Does it mean that addresses $2000 through $3FFF are then mapped to CHR RAM?

Depends. For example, in the game Napoleon Senki, $3000-$3FFF is left open bus, because nothing depends on it.

Also, if CHR ROM/RAM is disabled, where are the pattern tables stored in the PPU's memory map? And what are PPU addresses $0000-$1FFF mapped to?

Pattern tables are always at addresses $0000-$1FFF. If there's nothing logically there, then random crud ("open bus") is what's drawn. (Games don't do this)

[Bregalad]

Most technically : The PPU reads CHR data from $0000-$1FFF and NT/AT data from $2000-$2FFF but can't know what the cartridge hardware puts there.

The NES mainboard offers 2kb of VRAM but the cartridge can use it wherever it wants, or disable it entirely. The cartridge can ads whatever VROM and VRAM it wants to that amount.

Now 99.5% of the time, internal 2k NES VRAM is used for nametables, while cartridge hardware is used for CHR data (aprox. 50% CHR-ROM and 50% CHR-RAM).

$3000-$3FFF is unused, but palettes are writable and readable for the CPU through $2007 at PPU $3FE0-$3FFF despite not actually being on the PPU adress range; reads and write won't be visible on the bus.