Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nintendo 64 Architecture – A Practical Analysis

copetti.org

Post reply on HN
Print view View original

31–40 of 77 posts

Re: Nintendo 64 Architecture – A Practical Analysis

#31

Post by to11mtm »

rhlsthrm wrote: post #15
msla wrote: post #13

Earlier quoted context omitted.

> Hardware used to be so exotic! It might circle back around to being exotic again, if FPGAs take off and more work is done on highly-specialized task-specific hardware, as opposed to building the fastest general-purpose chips you can and beating problems to death with sheer speed.

Is this a thing that's happening? I remember how cool I thought FPGAs were from my college CE classes. Seems intuitive to me that you would want to specialize the hardware once you have a process figured out. The fact that FPGAs are upgradable makes it even more of a no brainer to me.

Well there's a cost benefit; Cheaper FPGAs may not necessarily be as performant as others for some tasks, there's still a gate budget to deal with, and I personally am not sure whether the FPGA world is one where you have full control over what you do with the chip when you sell it in a commercial product.

I know Gigabyte back in the mid 2000s made a PCIE Card that let you use DDR as a disk drive once upon a time; for the original they actually used a Xilinx Spartan FPGA since it was a smaller run.

Re: Nintendo 64 Architecture – A Practical Analysis

#32

Post by to11mtm »

joneholland wrote: post #28
nwallin wrote: post #16

Earlier quoted context omitted.

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 ho…

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.

Re: Nintendo 64 Architecture – A Practical Analysis

#33

Post by Grazester »

webwielder2 wrote: post #17
Causality1 wrote: post #12

I don't think I would have gotten as interested in gaming if it weren't for Nintendo's decisions with the N64. The native bilinear texture filtering, Z-buffer, and subpixel model rendering make such an enormous difference to me I'd have found the Playstation unplayable.

To me, N64 continued the video game "tradition" I knew from the 16-bit era. Colorful, fast-paced, responsive. PSX games by contrast were dour, slow-paced, and controlled poorly because of Sony's initial failure to consider how digital control wouldn't work in a 3D environment.

The N64 blurry textures and washed out color had me thinking initially that my friends TV was broken. It was only Rare and Factor 5 games on the N64 that really impressed me. Of course they could do nothing for the blurry picture quality. That was a hardware thing that has been fixed with a hardware HDMI mode that offer de-blurring

Re: Nintendo 64 Architecture – A Practical Analysis

#34

Post by mhh__ »

msla wrote: post #13
als0 wrote: post #5

Earlier quoted context omitted.

Hardware used to be so exotic!

> Hardware used to be so exotic! It might circle back around to being exotic again, if FPGAs take off and more work is done on highly-specialized task-specific hardware, as opposed to building the fastest general-purpose chips you can and beating problems to death with sheer speed.

It might not be visible from a regular programmers' perspective (i.e. You don't need to read https://people.freebsd.org/~lstewart/articles/cpumemory.pdf to write a website) but FPGAs are absoutely everywhere already, e.g. Xilinx (the Intel of the FPGA market... as opposed to Intel who are the AMD of the FPGA market) have Market Cap of $21Bn which is quite a lot for a company that is both fairly obscure to investors and doesn't sell directly to consumers.

The issue with this is that FPGAs are expensive to buy as a hobbyist, expensive to buy at small quantities unless you can negotiate with Avnet or similar, and involve using software from the past if you want to program them.

Beyond FPGAs, ASICs are fairly common in very high margin/high volume electronics.

Re: Nintendo 64 Architecture – A Practical Analysis

#35

Post by nwallin »

joneholland wrote: post #28
nwallin wrote: post #16

Earlier quoted context omitted.

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 ho…

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

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)

Re: Nintendo 64 Architecture – A Practical Analysis

#36

Post by to11mtm »

nwallin wrote: post #16
bambataa wrote: post #3

On the cost-saving point, I always understood that the limited 4kb texture memory led to lots of games having really muddy, blurry textures. How much more would have 8kb or 16kb cost? It seems a small cost saving that had a pretty large, negative impact.

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 ho…

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.

Re: Nintendo 64 Architecture – A Practical Analysis

#38

Post by monocasa »

I gave a talk not too long ago about running Rust on a Nintendo 64, with the slide deck written in Rust and running on an N64.

https://twitter.com/DebugSteven/status/1054903603985559553

So I guess what I'm saying is that I have pretty hands on knowledge with the system and would be happy to answer any questions I can.

One thing I'll throw out there, is that one of the biggest limitations of the N64 (its 4KB texture memory) gets called a texture cache a lot, but that's a misnomer. It's a manually managed piece of memory, and (IMO) the system would have been much better off if it were actually a cache rather than having to load an entire texture in regardless of what was being sampled. Nowhere I've seen in Nintendo's literature do they call it a cache either. The crazy hacks that Rare did to subdivide their geometry on texture boundaries wouldn't be necessary for instance. I'd maybe even be into a 2KB cache over a 4KB chunk of manually managed memory.

One other aside is that I think the system still has tons of unlocked potential. So much of unlocking it's power seems to be centered around memory bank utilization. Switching which page of DRAM within a bank is expensive in terms of latency, but it seems like if you allocate your memory in 1MB bank chunks you can get around a lot of the limitations of the systems having the slow memory that developers complained about at the time. I don't blame developers at the time, they were coming from SNES where it was single cycle access to RAM, to the N64 that had a very deep, very modern memory hierarchy and what all that means for your code. The industry as a whole didn't really catch on until about halfway through the PS2's development cycle. But applying some of those PS2 techniques back, the system really purrs when you have dedicate a 1MB bank to each streaming source or destination. I can't wait to see what crazy stuff happens when the demoscene folk really start to get their hands dirty with it.

Re: Nintendo 64 Architecture – A Practical Analysis

#39

Post by monocasa »

Jasper_ wrote: post #10
bambataa wrote: post #3

On the cost-saving point, I always understood that the limited 4kb texture memory led to lots of games having really muddy, blurry textures. How much more would have 8kb or 16kb cost? It seems a small cost saving that had a pretty large, negative impact.

Texture memory (TMEM) is very special and fast, so it tends to be expensive stuff, at least back then, and it's balanced together with the rest of the architecture, like the bandwidth the RDP has, DMA copies from main mem -> TMEM, and so on. It would have changed quite a lot of the underlying architecture to increase it to 8KB, and might not have been worth it. You couldn't have increased texture resolution by simply…

It was a pretty bog standard 6T SRAM block. You can see a die shot here, and I don't think going to 8K would have been a huge deal. http://www.hotchips.org/wp-content/uploads/hc_archives/hc09/...

That being said, going to a real cache rather than a block of manually managed memory I thin would have been the better design choice. Most textures didn't fill up the memory because of the practicalities of managing that memory. A double buffer scheme to load a block wile rendering from another one, the fact that you have to eat the whole cost of the full texture's load before you can render from it, etc.

Re: Nintendo 64 Architecture – A Practical Analysis

#40

Post by opencl »

jerrysievert wrote: post #27
DarknessFalls wrote: post #7

Earlier quoted context omitted.

They should have released a Nintendo 64 Plus sometime before the release of the Gamecube that would have doubled its RAM to provide hi-res textures.

they technically did. the https://en.wikipedia.org/wiki/Nintendo_64_accessories#Expans... raised main memory from 4mb to 8mb. it was required for one of the Zelda games, but also helped with graphics for some games if it was inserted. seemed to be a decent success.

DK64 required the expansion pak due to a bug (it was intended to work in either 4MB or 8MB modes and they couldn't fix a crashing bug in the 4MB version) and then Rare spent an obscene amount of money shipping an expansion pak with every copy of the game. That was probably responsible for a large fraction of the units shipped, with most of the rest accounted for by Zelda (which did not include the pak even though it was required).
Post reply on HN