Hacker News new | ask | show | jobs
by monocasa 2222 days ago
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.

2 comments

> The crazy hacks that Rare did to subdivide their geometry on texture boundaries wouldn't be necessary for instance.

I would love to know more about this. Is their texture format tomfoolery written up somewhere?

I don't think anything is written up, but you can see it if you put Project64 into wireframe mode. The most clear I've seen it is in the intro cut scene of Conker's Bad Fur Day where the camera's slowly backing up from Conker's throne.

So TMEM is only 4k. If you want mippmapping, that eats half of it, down to 2k practically. That leaves you with enough room for 1 32x32x16BPP texture at most. So I think what they did in some cases was to take a mesh with a larger texture, and run it through a processor to tesselate the mesh on smaller texture block boundaries in UV space, so they can render each tile of geometry with the same texture block at once, then swap to the next subtexture and render all it's geometry. That'd give you an apparent larger texture than you could fit into TMEM, and is one reason (of many) why their games look so good. They also might not have had tooling for that and just brute forced it by hand, I can't tell just from looking at the wireframe.

this is relevant but not same system https://www.youtube.com/watch?v=izxXGuVL21o
Amazing. Is there somewhere I can watch this talk?
It wasn't recorded unfortunately.

The source behind the text of the most recent slides starts here if you'd like to read it: https://github.com/monocasa/n64-slides-apr/blob/caae25f397c5...

I should probably save off pictures and put it into a pdf or something where it could be more easily accessible.

I’d certainly watch it if you made a video by giving the talk again, if you still have your notes :)
If you made a video of the slides with a recording of your voice over it and posted it on Youtube, I’m sure you’d get a great response
Would it be possible to provide a rom Image that would run in an emulator?
I uploaded the build into a github release on the repo just now.

https://github.com/monocasa/n64-slides-apr/releases/tag/v0.1...

I've only tested it with cen64 and real hardware with a 64drive.

A is forward through the slides, B is back.

That's certainly an interesting way to organize your slides!