Super Mario 64 for the PS1

The whole thing about the texture cache being the worst design decision in the N64 just gets parroted so much, but nobody can cogently explain which corner should have been cut instead to fit the budget.

See https://news.ycombinator.com/item?id=46227453

The N64's CPU, with pretty much every single game released on the platform, is just sitting there idling along at maybe 30% load tops, and usually less than that. It's a 64 bit CPU, but Nintendo's official SDK doesn't even support doubles or uint64!

Of course, Nintendo clearly cared about the CPU a lot for marketing purposes (it's in the console's name), but from a purely technological perspective, it is wasteful. Most of the actual compute is done on the RSP anyway. So, getting a much smaller CPU would have been a big corner to cut, that could have saved enough resources to increase the texture cache to a useful resolution like 128x128 or so.

It should be noted, though, that the N64 was designed with multitexturing capabilities, which would have helped with the mushy colors had games actually taken advantage of it (but they didn't, which here again, the Nintendo SDK is to blame for).

You could have saved a lot of money by using CDs instead of cartridges.

If you sell games for roughly the same amount as before (or even a bit cheaper), you have extra surplus you can use to subsidise the cost of the console a bit.

Effectively, you'd be cutting a corner on worse load times, I guess?

Keep in mind that the above ignores questions of piracy. I don't know what the actual impact of a CD based solution would have been, but I can tell for sure that the officials at Nintendo thought it would have made a difference when they made their decision.

> It's a 64 bit CPU, [...]

Only really in the marketing material. It's a bit like calling a 386 with an arithmetic co-processor an 80 bit machine, when it was still clearly a 32 bit machine by all metrics that matter.

However, I agree in general that the N64 CPU sits idle a lot of the time. It's overspecced compared to the rest of the system.

imho, Nintendo had a hard enough time with preventing piracy and unlicensed games with the NES and SNES and saw the PS1 got modded within a year, even with the special black coated discs to hide the tracks. There wasn’t a lot of optical/compact disc copy protection magic at the time and, cd-rs and writers started getting popular quickly as well. ps1 in 1994, n64 in 1996, backwards Dreamcast GD-ROMs and beginnings of larger discs and DVDS in 98.

The discs being black was a marketing gimmick, the actual magic was in the 'wobble'.

> Nintendo had a hard enough time with preventing piracy and unlicensed games with the NES and SNES [...]

Yes, so I'm not sure that the cartridge drawbacks bought them that much in terms of piracy protection?

I agree that the PS1 had more piracy, but I'm not sure that actually diminished its success?

no, it really is a true 64 bit CPU. it's just that that fact is useless and it usually runs in 32 bit mode because games don't need that.

> So, getting a much smaller CPU would have been a big corner to cut, that could have saved enough resources to increase the texture cache to a useful resolution like 128x128 or so.

How? The texture RAM (TMEM) is in the RSP, not in the CPU.

> I agree that the PS1 had more piracy, but I'm not sure that actually diminished its success?

At least in my corner of the world (Spain), piracy improved its success. Everybody wanted the PSX due to how cheap it was, I think it outsold the N64 10:1.

it works if the console isn't sold at a loss, which isn't always the business model

How is that relevant? "Resources" really just means money, which can be allocated between different items on the BoM at-will. The N64's chips are all (more or less) bespoke, so the functionality of each individual part is completely under Nintendo's control. Spend less on the CPU, and you suddenly have money left to spend on the RSP. (And on the RDP, which contains the TMEM -- it lives on the same chip as the RSP, but is a distinct thing. I assume you know this, but just to add to the discussion for readers - the RSP is the N64's SIMD coprocessing unit, which most games use to perform vertex shading, whereas the RDP is the actual rasterization and texturing hardware.)

Yes. Although people like to point out that on the N64's CPU the external data bus is restricted to 32 bits, that's irrelevant in practice. The real limitation is the RDRAM's data bus, which is only 9 bits wide (of which the CPU uses 8 bits). The problem is that the rest of the system simply cannot match the overspecced CPU.

Realistically it wasn't even "We only have X dollars to spend". They needed the console to have a final budget and they really could have "just" added more transistors dedicated to that texture unit without significantly altering prices or profit.

But hardware was actively transitioning and what we "knew" one year was gone the next and Nintendo was lucky to have made enough right choices to support enough good games to survive the transition. They just got some bets wrong and calculated some tradeoffs poorly.

For example, almost everything Kaze is showing off, all the optimizations were technically doable on original hardware, but devs were crunching to meet deadlines and nobody even thought to wonder whether "lets put a texture on this cube" needed another ten hours of engineering time to optimize. Cartridges needed to be constructed by Christmas. A lot of games made optimization tradeoffs that were just wrong, and didn't test them to find out. Like the HellDivers 2 game size issue.

Sega meanwhile flubbed the transition like four different ways and died. Now they have the blue hedgehog hooked up to a milking machine. Their various transition consoles are hilariously bad. "Our cpu and rasterizer can't actually do real polygon rendering and can't fake it fast enough to do 3D graphics anyway. Oh, well what about two of them?"

I wonder what the maximum addressable memory of the N64 is?

Of course, even 32 bit are massively more than they actually need for the paltry amount of memory they actually get, even if you map ROM and various devices into the same virtual address space.

You are right about the RSP/RDP distinction. My point is that removing transistors from one chip doesn't magically let you add more transistors to another chip, that's not how IC fabrication works. And the CPU was not a custom design, it was a VR4300 licensed by NEC from the original R4300.

Anyway, the real problem is that TMEM was not a hardware-managed cache, but a scratchpad RAM fully under the control of the programmer, which meant that the whole texture had to fit under a meagre 4 kB of RAM! It is the same mistake that Sony and IBM later made with the Cell.