Comment by nwallin | Hacker News Reader

Comment by nwallin | Hacker News Reader

Parent Full thread

Regarding simply having 8/16/32kB, the cache was integrated with the chip itself, it wasn't RAM that lived on the motherboard. So adding more would have required a larger chip.

It was a multifaceted problem, and was ultimately a design flaw/oversight rather than someone saying "I think 4kB is enough memory to store all the textures". The problem is less that the cache was small, it's more that Nintendo's plans for how awesome RDRAM and a unified memory architecture didn't pan out.

Problem #1: There was no dedicated video memory. All RAM on the N64 was shared RAM. So framerates tanked if you didn't have most of your stuff in cache. Keep in mind the framebuffer also lived in this unified memory area, so the video chip was already very noisy on the memory bus.

Problem #2: The unified shared system RAM was RDRAM, not SDRAM. And the latency on RDRAM is absolutely terrible. So the already expensive cost of using RAM was compounded.

If the N64 did what the playstation and saturn did and just have dedicated video/system RAM, and made this RAM relatively low latency SDRAM instead of the relatively high latency RDRAM, this 4kB limitation wouldn't have mattered.

Yeah, but RDRAM gave them one big benefit: Even with the price premium of RDRAM back then, it was the cheapest route to getting 500mb/sec of memory bandwidth.

The Playstation by comparison used EDO (Based on eyeballing the pictures on wikipedia, baseline was 70ns/60ns for CPU and Video memory.) But, It's main bus was under 133mb/sec, and the fastest it could read from CD was 300kb/sec.

EDO Memory would have kneecapped the N64 from a memory bandwidth standpoint. The cartridge bus alone is over 200mb/sec. SDRAM -might- have done the job but may have wound up being more expensive; PC-66 (we are at the infancy of SDR in 1996) would have meant a PCB with 8 chips laid out for the parallel bus. To be frank I'm not sure Nintendo could have even gotten such a configuration (i.e. 8 512KB PC-66 chips.)

RDRAM was definitely a design compromise, but in retrospect I understand it's use in keeping overall costs down.

Dedicated video ram would have been a better option however, but I think it was another cost issue.

It's interesting to consider the N64 in contrast to the first Voodoo card. One is a console and the other is an add-in card, but both launched in 1996, with underlying 3D technology from SGI. The Voodoo used EDO RAM, 8 chips of 256k x 16b, 2 MB for the z+framebuffer and 2 MB for the texture memory. With 50 MHz EDO RAM, wired in a 64-bit bus, the peak texture bandwidth would be 400 MB/s, dedicated to that purpose alone; in contrast the N64 RDRAM was main memory and had to service other functions.

The N64 launched at $200, the Voodoo at $300. Of course you would additionally need a computer to run the Voodoo, but I remember thinking the N64 was already way too expensive back in the day. It would've been even more expensive to support a 64-bit memory bus.

If I recall correctly, later games actually packed higher throughout ram into the cartridges to work around the latency of the onboard ram.

Not quite.

Larger cartridges (i.e. 32/64MByte) gave them space in ROM to play with tiled textures. Usually this -did- also involve use of the 4MB RDRAM upgrade.

They used uncompressed textures on the cart, in ROM. (not on-cart RAM) Normally a game would store compressed textures in ROM, and decompress them into RAM. It was a solution with significant tradeoffs though.

#1 It was still slower than the cache.

#2 You were still using the single shared bus. You would still be using cycles which contribute to data stalls elsewhere in the system.

#3 ROM was expensive. N64 games were typically in the ballpark of $10 more expensive than Playstation or Saturn games because of the manufacturing expense.

#4 I don't fully understand why, but it was all or nothing. You couldn't have uncompressed textures in ROM but also gain the benefit of the cache. Maybe the cache invalidation was poor or something. I wish I knew more.

Later games were more likely to go this route because ROM was cheaper. (Moore's Law and all that)

So the TMEM wasn't cache, but manually managed memory split into 8 512 byte banks that had to be loaded from the RDP's command list stream. That's half the problem.

Additionally, the TMEM could only be loaded from RDRAM, not directly from the cartridge. I think the RDP's DMA master is only connected to the RDRAM slave port and not the main system's bus matrix.

So going back to it, games would a lot of the time store compressed data with a simple algorithm that could run out of the CPU's cache. Then the scheme looks like

* Cart->RDRAM DMA of compressed texture

* CPU decompresses texture into another RDRAM bank, and can be considered a RDRAM->RDRAM transfer. Sometimes the RSP handles this instead. I'm not sure if you could load straight out of RSP DMEM to avoid another bounce to RDRAM. I don't think XBUS works that way, but I could be wrong.

* RDRAM->TMEM DMA of uncompressed texture

Interestingly, games with more advanced texturing schemes like Indiana Jones tended to use uncompressed textures. They did this to avoid the decompression step and it's bandwidth. At that point it's just staging the texture with that cart's DMA, and slurping that into TMEM without any other processors eating bandwidth in between.

Reply on news.ycombinator.com