12

The TMS9918 video controller which came out in the 1970s is designed around the use of DRAM for video memory--typically a bank of 16Kx8. Not only was DRAM vastly cheaper than SRAM, but it also included a "free" upper address latch.

The PPU used in the NES/Famicom is designed with a 16K address space, which was expected to be filled with an 8K ROM chip on a cartridge and a SRAM (2K on the Famicom/NES, though I don't know if Nintendo contemplated the possibility of using only 1K). While some cartridges eventually supported bank switching of video ROM, I think that was an afterthought. Because the PPU doesn't have enough pins available to output a full 14-bit address directly, the NES needs to include an on-board latch for the upper address bits.

Was the cost of a 2Kx8 RAM, plus an adddress latch, plus all the cartridge pins needed to expose the video bus, less than the cost of eight 16Kx1 or two 16Kx4 DRAM chips? The TMS design was well established, and improvements in memory speed would have allowed commodity DRAMs to achieve the same memory bandwith as the PPU bus. For games that would need less than 32K of code and tile graphics combined, a cart with a 32K ROM would almost certainly be cheaper than one with both a 32K ROM and an 8K ROM, and I would expect that even a cart with 64K of ROM plus a glue logic chip to toggle the ROM's A15 on any CPU write cycle would be as cheap or cheaper than one with two ROM chips because of the reduced board width allowed by slashing the number of cart connector pins).

As noted, the TMS 9918 and similar devices were well established, and are conceptually similar to the Famicom except that the latter would need to achieve a slightly higher memory throughput. The timing to achieve maximum DRAM bandwidth would be a little different from the timing required by the multiplexed PPU bus, but not in a way that would seem difficult to implement given the 6x chroma input clock. Further, having more than 2K of RAM available would allow half of the bits in the Object Attribute Memory--those related to object tile number and X position to be eliminated (they could be fetched just before the object shape data).

What prompted Nintendo to design a system which is closer to the TMS 9918 design (which was used in the Colecovision and MSX machines) than other 6502-based machines of the era, but not use the DRAM which was common to such systems?

7
  • The answer is contained in your question. Everything but tile map already was in ROM and thus needed no splitting addresses and ras/cas, the extra should be 2 kilobytes of tile maps. How more expensive would be using dram chips of the era (like 8 pieces of 16k ones) instead of obvious single piece of 2kx8 SRAM?
    – lvd
    Jan 7 at 12:00
  • @lvd: The PPU already uses a multiplexed address bus, and it already receives a clock which is vastly faster than the bus clock. DRAM was much cheaper per byte than SRAM, and a fair price comparison would add to the cost of SRAM the cost of an address latch chip (not needed if using DRAM), an extra couple dozen cartridge slot pins, the board area on every cartridge needed to accommodate such pins, and an extra 8Kx8 ROM on every cartridge.
    – supercat
    Jan 8 at 17:13
  • You have forgotten to also include more complicated power supply for +12/-5v for cheaper DRAM chips (and anyway much more power for 8x DRAMs), then much bigger PCB which could also cause the plastic case to be bigger. Finally an important thing would be different efforts for designing PPU either for SRAM/ROM or for DRAM and no ROM. An important factor might be the need to have CPU memory paging from the very beginning (as all gfx should be copied to DRAM by the CPU anyway now). How well cartridges could be expanded with this approach, vs. the existing lots-of-mappers situation?
    – lvd
    Jan 8 at 18:43
  • @lvd: The amount of extra board space required for each cartridge as a result of the separate memory bus would probably be enough to hold about 3-4 DRAM chips. I don't know how the price of 4516 chips compared to the cost of 4116; if the cost advantage of using DRAM wasn't expected to be shared with 4516, that would be an argument against it. My impression is that once manufacturers figured out how to produce NMOS DRAM, it was cheaper to produce than PMOS,and enough devices existed that could use multi-voltage chips that the main...
    – supercat
    Jan 8 at 19:01
  • ...drop off in demand for 16K chips would have been due to the emergence of 64K DRAM chips, but I could be mistaken in that.
    – supercat
    Jan 8 at 19:02

4 Answers 4

7

The PPU used in the NES/Famicom is designed with a 16K address space, which was expected to be filled with an 8K ROM chip on a cartridge and a SRAM

That's not what the NES wiki states:

  • $0000-1FFF is normally mapped by the cartridge to a CHR-ROM or CHR-RAM, often with a bank switching mechanism.
  • $2000-2FFF is normally mapped to the 2kB NES internal VRAM, providing 2 nametables with a mirroring configuration controlled by the cartridge, but it can be partly or fully remapped to RAM on the cartridge, allowing up to 4 simultaneous nametables.

So unless you need more nametables, there is no additional cost for VRAM on the cartridge.

Why SRAM and not DRAM for VRAM? My guess is that the necessary refresh could possibly interfere with the PPU timings, and would need extra circuitry, making the PPU more complex, so they went for the simpler solution, in particular as the SRAM cost is not necessarily per cartridge.

Why add the complete PPU address and data bus to the cartridge? Flexibility for future expansions, and the cost for a slightly bigger connector is only marginal, and the cartridge has to be a certain size anyway to handle it comfortably, so one might as well make use of the size.

4
  • The PPU doesn't use allow programmers to use the upper 4K of space its bus could accommodate, but my point was that everything that the PPU design could access was accessed using 14 address bits and would fit in a single 16K DRAM bank, eliminating the need to retrieve data from elsehwere.
    – supercat
    Jan 1 at 19:09
  • DRAMs of the era also required funky power supplies (+12V, -5V in addition to 5V) which may have the potential to increase system cost.
    – d3jones
    Jan 2 at 0:13
  • @d3jones: Early DRAM required extra power supply voltages, but I would think the 5-volt-only 4516 would have replaced the 4116 by the time the Famicom came out. Still a worthwhile consideration, though.
    – supercat
    Jan 2 at 17:50
  • @d3jones: I just realized another issue that may have been relevant: a bank of eight 4516 chips would draw about 200mA. This isn't a huge amount of power, but might have increased the heat sinking requirement for the system's 7805 regulator.
    – supercat
    Jan 4 at 18:27
6

Was the cost of a 2Kx8 RAM, plus an address latch, plus all the cartridge pins needed to expose the video bus, less than the cost of eight 16Kx1 or two 16Kx4 DRAM chips?

The DRAM would have been cheaper, yes, but DRAM needs refreshing. So either the PPU would need DRAM refresh circuitry (which eats up silicon space, so the price goes up), or it would have to be put somewhere else (the price still goes up).

The SRAM would have been cheaper as there was less circuitry to implement, something that DRAM's cost advantage doesn't overcome with the cost of its extra circuitry.

There is PSRAM (Pseudo Static RAM) but I'm not familiar with its cost per bit, and I very much suspect that wasn't an option back when the Famicom was still in development.

6
  • 2
    PSRAM is just a DRAM and an independent refresh circuit on a module with the same electrical interface as SRAM. Even if it was a thing in 1983, it's still DRAM. PSRAM is an ease-of-integration win over DRAM, but not a total cost or complexity win.
    – hobbs
    Jan 1 at 22:00
  • @hobbs: The scenarios where PSRAM makes sense are those where all address pins are discrete. A 64Kx8 PSRAM would contain circuitry so that each memory access would feed the internal DRAM logic the 8 row address bits, and then feed it the 8 column address bits. Since the PPU already splits the address in half and outputs both halves separately, and a PSRAM can't even begin to process the row address until it has receive the entire address, it would be a very bad fit in the Famicom video system.
    – supercat
    Jan 1 at 22:08
  • @supercat agreed. I was debating whether to write more in my comment or to leave it there. But yes, it's a win for someone, somewhere, but not in this case :) All the downsides of DRAM plus a few extra.
    – hobbs
    Jan 1 at 22:11
  • Note - I'm not sure if it's true for the NES PPU, but a PPU's memory layout can be arranged to naturally refresh every row as part of drawing the screen.
    – user253751
    Jan 1 at 22:21
  • @user253751: While the CPU is outputting content, the bottom 7 bits of the tile-select-RAM address would cycle through the range 0-127 every 32 scan lines, which is just a smidgin slower than what the DRAM data sheet requires, but would probably work. The two difficulties with this approach would be that display accesses stop during vblank, and the CPU could change the address mid-frame or blank the display when it wants to load lots of data. On the other hand, DRAM data sheet timings are loose enough to accommdoate a CPU-or-refresh cycle during each character time,...
    – supercat
    Jan 1 at 22:30
3

The TMS9918 derivative which was used in the NES/Famicom (the Ricoh 2C02) simply didn't have the RAS/CAS pins to use DRAM.

Note that the TMS9918 and the Ricoh 2C02 are not pin-compatible!

The 2C02 had an extra feature: the pins EXT0, EXT1, EXT2 and EXT3 allowed to be two PPUs to be connected together. The additional PPU could overlay the video of the other PPU. In the NES, these four pins were tied to ground. I could be that Ricoh ditched DRAM support for this feature. Or it could be that they ditched DRAM support to avoid patent infringement (like they disabled the patented fast BCD arithmetic in the 6502 core of their 2A03).


Pure speculation: patent US4243984A (the "TMS9918 patent") mentions:

"In the memory subsystem, a balanced mix of dynamic RAM, P-channel MOS ROM and N-channel MOS ROM are included to minimize cost without sacrificing performance."

"In the RAM portion of the memory subsystem 14, a block of dynamic RAM "

"In addition, the VDP provides for the periodic refreshing of the contents of the various devices comprising the RAM."

I'm no patent lawyer, but to me it sounds that, if you stay with SRAM (and, possibly more important, insert enough money into a capable patent lawyer), you're home free.

5
  • 2
    DRAM would require three control signals: /RAS, /CAS, and R/W. The 2C02 memory interface uses a multiplex-latch pin, /RD, and /WR. Same number of pins. I think the TMS9918 was intended to support overlaying, since the TI 99/4A documented color zero as "transparent", though I don't know what devices if any made use of that. Patent issues would be an interesting angle if there were any evidence to support that.
    – supercat
    Jan 1 at 20:42
  • 3
    do you have any proofs that 2c02 is allegedly a "derivative" of tms9918?
    – lvd
    Jan 2 at 23:23
  • 1
    @lvd: I wouldn't expect that it would be "derivative" beyond the fact that the TMS9918 demonstrates the practicality of having a "single-chip" video solution which uses an isolated bus for a bank of DRAM that it "owns", and that talks to the CPU via an entirely independent bus.
    – supercat
    Jan 3 at 18:04
  • @lvd No proof, Ricoh and Nintendo seem to keep this secret for some reason. Let's just say that Nintendo wanted a video game console fast, and cheap, and it must to be able to play a home version of their #1 arcade game, Donkey Kong. Donkey Kong had been licensed to quite a few licensees, including Coleco, and the ColecoVision port was one of the better ones. And the ColecoVision used the TMS9928A/9929A PPU. So Nintendo approached Texas Instruments...oh, wait, nope - "cheap" was the order of the day. Not enough room to elaborate here, search YouTube for "Nintendo's Cheating Console".
    – Klaws
    Jan 4 at 19:25
  • That is complete bullshit, 'resemblance in terms of functionality' (as that trash video states) is by no means 2c02 is a derivative of tms8819. Even wiki article over tms9918 shows they are not 'derivatives' of one another.
    – lvd
    Jan 7 at 11:56
1

DRAM would have needed refresh circuitry and address multiplexing. And as Nintendo needed an 8-bit bus and DRAMs of the time were 1-bit parts they would have needed 8 parts instead of 1 with costs in part count and board layout. DRAMs were much cheaper in terms of raw cost per bit but that might have not been as true for a mere 2Kx8 when accounting for the extra chip packaging, especially as they would have needed at least 4K of DRAM and I don't even know if 4Kx1 DRAMs were as price optimal at a time when 16Kx1 was standard and 64Kx1 was emergent. At any rate, the cost savings would have been at best pretty marginal, probably under $1/unit.

There seems to be this long-standing idea that the 2C02 was based on the TMS9918 but I've never seen much evidence of this. TMS9918 wouldn't have been that well established in Japan - the original TI-99/4 (non/A) was very niche and barely sold while the TMS9918A revision wasn't out until 1981 and didn't really catch on until later when TI got into a price war with Commodore.

Not even being familiar with the 6502 until Ricoh introduced it Nintendo was never that keyed into American tech. Of course they were familiar with the Colecovision given how important the Donkey Kong license was for it but that was introduced to them in 1982 which would have been getting pretty close to when the NES was already being designed.

What was well established in Japan was arcade hardware, especially Galaxian (1979) which many subsequent machines were based on to varying degrees, including ones from Nintendo, who was at this time was first and foremost an arcade developer.

Just about every facet of the 2C02's design could be traced to contemporary tile/sprite based arcade hardware. Even sprite multiplexing (the oft-cited similarity to TMS9918) could be found on Nintendo's own Radar Scope (1980) (which was repurposed into Donkey Kong, though I have no idea if that even took advantage of sprite multiplexing)

There were many design decisions and features that the 2C02 had that TMS9918 didn't but various Galaxian-like arcade platforms did such as fine scrolling, tile attributes (separate from the tile data itself), sprite flip/mirror, sprite priority, 2bpp tiles/sprites and dedicated object attribute memory (TMS9918 had to fetch every sprite's Y position from DRAM every scanline which limited total sprites to just 32). These features used space on the chip, especially the OAM which took up a sizable block, and that meant they didn't have as much room for DRAM interface circuitry.

One of these arcade-like design ideas was having separate memories for program code, tile map and tile pattern data. Like the Famicom the arcade machines would have tile pattern data in ROM. While there's drawbacks to this approach it does simplify the design and critically it allows for graphics to be drawn without having to load the data into VRAM first, allowing for fast animation. While this design didn't see much use in consoles beyond the Famicom (probably because there was a cost premium for high speed ROM and it wasn't space efficient) it did show up in another arcade-centric platform, the Neo Geo.

8
  • DRAM refresh circuitry is not complicated, and the PPU's design required address multiplexing even when using static RAM. A difference between DRAM and SRAM multiplexing here is that the DRAM memory timings are measured from when the FIRST part of the address becomes available, while SRAM and ROM timings are measured from when the LAST part becomes available. Refresh seems for some reason to be perceived as something really complicated, but I'm not sure why. Your point about arcade hardware is interesting, though. I wouldn't expect many arcade machines of the era to use the same bus...
    – supercat
    Jan 3 at 17:54
  • 1
    ...for background tile selection, background tile shapes, and sprite tile shapes, but the fact that arcade tiles are kept in ROM might have influenced Nintendo engineers to assume tiles "naturally" belong in ROM, when the primary advantage to using DRAM would that its increased capacity would allow it to "absorb" functionality that would otherwise be handled via separate ROM or additional bits in the sprite attribute memory (having separate ROM could offer a bandwidth advantage if tile ROM used a separate bus from tile RAM, but on the PPU it doesn't).
    – supercat
    Jan 3 at 18:02
  • 1
    Any time the CPU issues a read or write request, the PPU can process it at any convenient time within the next ~1.6 microseconds; if the PPU performs memory cycles whenever it's idle, and a CPU request arrives in the middle of a cycle (as would usually be the case), the PPU would simply use process the request during its next convenient memory cycle.
    – supercat
    Jan 3 at 18:20
  • 1
    @Klaws I know VRAM isn't in the address space directly but there really isn't a ton of bandwidth available. On NTSC the NES only has about 20 lines of usable vblank after the NMI hits, or 2273 CPU cycles. 513/514 needed for OAM DMA. LDA ABS,X/STA ABS pairs take 9 cycles then there's setup overhead. So realistically you have well under 200 bytes, which is enough to update one edge for four way scrolling under 8-pixel/frame (~100 bytes) but not much else, including if you need faster scrolling.
    – Exophase
    Jan 6 at 5:51
  • 2
    @Klaws Don't know why you'd think it was based on the TMS9928A instead... That is the same as TMS9918A just with YPbPr output instead of composite and NES has composite output. The two chips are really little alike.
    – Exophase
    Jan 6 at 5:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .