Correction: Tharo pointed out that the float registers are actually 64 bits in width! Though it seems like compilers at the time would always end up using them as 2 seperate 32 bit registers that combine them to a 64 bit register as described. This seems to be the same compiler shortcoming that I've described for the general purpose registers. Also a bunch of people pointed out that "64 bit" may refer to memory bus bandwidth. Well.... the RAMBUS on the N64 is 9bit. There is a 72 bit bus in there somewhere too which kind of looks like a 64 bit bus, so maybe that's what the "64" in "Nintendo 64" could have stood for,...

Fun fact Nintendo wouldn't make another 64bit console until the Switch, 20 years after the release of the N64. GameCube, Wii, and Wii U all used similar 32bit CPUs.

64 was pure marketing. We used the 64 bit R4300 because SGI owned MIPS and the recently developed R4300 CPU was available and had the power/performance/cost tradeoffs we needed. If there had been an equally performant 32 bit processor we could have use it, and as Kraze points out it would have worked just as well. A bigger consideration than the register size was the size of the bus, which dictates how much memory can be read or written to DRAM in one cycle. Memory bandwidth was the real bottleneck in the N64 (and is usually the bottleneck in a graphics system, even with modern GPUs). The R4200 has a 64 bit bus, but the R4300 in the N64 actually has a 32 bit bus. In contrast the RDP (N64's pixel processor) used a 1024 bit bus and 1024 bit vector registers. I always thought Nintendo should have called it the N1024. But in fact all the busses (the 32 bit CPU bus, the 1024 bit RDP pixel bus, the 16 bit audio) all funneled (via the memory controller in the MCP) through the Rambus high speed 8 (or 9*) bit bus to the RDRAM memory. * Fun fact: the N64 actually used the parity bit as a data bit. So the Rambus was actually a 9bit bus. The 9th bit was not used by the cpu, but the framebuffer was 18 bits (9+9) in R5 G5 B5 C3 format where the 3 C=Coverage bits helped with antialiasing. The z buffer was also 18 bits.

So what I understand is that Kaze is creating the first Nintendo 32 game because it saves him frames.

Because higher bit means more better

Another thing to consider: Nintendo worked closely with sgi, who were a Big Deal in 3D modeling and animation. sgi machines were powerful workstations utilizing the 64 bit version of the MIPS architechture, and were the workstations of choice for Nintendo of that era. Familiarity with the architecture would have been a *huge* reason for choosing MIPS 64 over other, more purpose-efficient designs. It's also easier to run dev builds on machines that share the same architecture. In addition, it is usually cheaper to tweak an existing design than create a new one with new features (like 16-bit arithmetic acceleration).

Kaze: The N64 was the first 64 bit console. Atari Jaguar: Am I a joke to you? Literally everyone: Yes.

Funny to think that after N64, all Nintendo consoles until the Switch were 32 bit.

When I was a kid, I thought the GameCube had a 128-bit system and the Wii a 256 one because they should double every gen

It wasnt done purely for marketing. SGi were world leaders in graphics and their big expensive workstations were 64bit. It made sense to cut that down to fit than to from scratch build a new cpu with custom instructions. That basically never happens. Nes and Snes had a cpu based on the popular 6502. There weren’t many choices in 1996. The 68k family of chip were aging and expensive. PowerPC really was just getting off the ground.

For what it’s worth, most modern sound is still 16-bit 44.1kHz or 16-bit 48kHz. I say this having developed an audio player for a final project in uni.

Think 64 was simply a marketing term because at this time, I remember it well despite being so young, there was such a huge rapid growth in computers and tech, calling it a “64 bit console” despite anyone knowing what that meant, helped it ride a wave of tech obsession that pretty much captivated everyone. My dad was into building pcs at the time. So much that all his coworkers asked him to set them up with one, and I remember every year ram, disk space, all forms of memory were doubling. what you bought high end one year, was low end the next, cpus were getting faster and faster and the gpu race was just beginning. I remember the first nvidia gpus being released. I believe previously, the only thing that revolutionary was the 3dfx voodoo card. It was an amazing time for tech and video games and I think people who otherwise wouldn’t have cared at all about tech were learning terms like “64bit” it was really fascinating. He still has a cupboard full of dos floppy disks and old ms software. It was a really nostalgic wave of tech excitement that I don’t think will ever happen again. It was magical. I don’t feel that same magic when I look at today’s tech.

Wait till you look at the Dreamcast and PlayStation 2 where both were advertised as being 128 bits.

So "64 Bits" was more or less Nintendo's own variant of "Blast Processing".

The hype was real - and went hand in hand with the first iteration of VR that wasn't consumer ready. Flat shaded real time polygons on a $250 home console was a BFD. Pilotwings 64 and Aerofighters Assault were developed by pioneers in VR simulation

1:33 Note here that when we're talking about videos, 8 bits means 8 bits per color channel, so 24 bits in total. The alternative is 10 bits per channel, totalling 30 bits. For most use cases, 24 bits is perfectly fine.

At least the commodore 64 wouldnever scam me

Kaze, I can tell you, the marketing was insane. I reacted just like the N64 kid when we got it in Xmas 96.

14:21 Not only did the Gamecube use a 32-bit processor. But the Wii, Wii U, and 3DS also did. The Switch was actually Nintendo's second 64-bit console. You could argue that Wii U should've been 64 bits. But that still means they were 16 years too soon to jump to 64 bits. The PS2 and Xbox were 32 bits as well.

It was fun to learn about the history of tech arms races and 1990s propaganda at the same time The wanted poster for "DMCA Violation" is amazing

nah the fact he casually had a convo with DAN SALVATO kills me I swear ddlc is in EVERY CORNER OF THE INTERNET

0:05 screams in atari jaguar

RE: 3:47 on the FPU registers - I worked a while on a decomp of Mischief Makers, and it actually was one of the few titles to compile into MIPS 1 instructions, meaning doubles were split in 2 32-bit registers. This was only for the game's code, libultra was still largely MIPS 2/3.

1. Coming from Saturn, having a 64-bit (really, 48 bit) register is extremely useful by itself. 2. What would have mattered more is the pulse width of the RAM bus, which other comments indicate the N64's bus was 9 bit. Hilarious; the Saturn had 32 and 16 bit busses. 3. Another thing which would have made a difference is the width of the instructions; the N64's instructions are 32-bits long. Imagine how much faster it could've been if the instructions were 16-bits long. (There are compromises to be made in doing so, but it definitely worked out for SuperH) 3. The reason Nintendo ended up with a 64-bit processor was almost certainly SGI who just kind of had it on-hand.

Hey, 2 things: 1) 64-Bit colour is actually 16 bits per channel (Red, Green, Blue and Alpha) and it's only used for like, "green screened" stuff in editing if you know what I mean. 2) 16-Bit 44.1KHz audio is basically "CD quality" - that's probably why they specifically used it.

The MIPS processor was probably off the shelf and only came in 64-bit.

"I was in my mother's womb at the time." Thanks for making me feel old. :D

As of the floats issue. A quick tip, you can set some compiler directives to prevent the higher depth floats from ever being used. This will simply override the standards regarding the default float format. This is also the method to work around various .Net and Mono versions using different default integer and pointer formats in various 64 bit platforms breaking code. However, be careful, less depth in rendering does mean less precision. The larger the world and the further your view distance, the more likely you will hit this range. Still, with the low-poly N64 games, it just isn't the most likely thing to need to worry about. Notably on the Multimedia Co-processor, you can do 8 bit and 16bit SIMD operations. If you are looking to handle 8 bit and 16 bit math in bulk, this is a good option.

Ah, so making it an N32 would've been more effective.

Nintendo: 64 bits! Consumers: Uh... Sony: CD playback- Consumers: Shut up and take my money!

I'm old enough and I can confirm marketing was strong. every kid wanted a nintendo or a ps1 and every new console was a real revolution. Great and interesting video

Reminds me of that story where a chain of burger restaurants was marketing a third-of-a-pound burger (1/3) to combat McDonald's quarter-pound burger (1/4). It didn't catch on, because people thought the quarter pound burger was larger than the third-of-a-pound burger. As everyone knows 1/3 < 1/4. Never underestimate the stupidity of people.

As a digital logic developer, I would guess the register file being narrower wouldn't mean much in terms of chip cost. However it could possibly make timing closure easier which may have meant higher CPU clocks. However, since this system is memory bound due to the GPU sharing the bus, I think generally a 64 bit architecture makes sense because it means the internal data bus is 64 bit. Even though the external RAMBUS is 32 bit this still matters when moving data around the chip and getting it to the RAMBUS controller faster. In my opinion, 32 vs 64 bits is a tiny drop in the bucket as far as the overall chip design, there is so much more they could have done or not done, boiling it down to 32 vs 64 bits is like trying to compress 1000 design decision into a bool.

First Pannen's documentary, now Kaze blesses us as well

rather than going for 64-bit to market it as a Silicon Graphics super computer, they should've thought about what a new era of game graphics would actually mean. They wouldnt have gone for CD but increasing the texture buffer sizes would've been nice. THAT and a rambus that goes vroom vroom!

Thanks for the video Kaze, I'm still patiently waiting to play your elite optimized original N64 so I can experience my childhood in the best way possible! I've held off playing the game for so many years just to play yours, i can't wait to experience it!

The 64 bit refers to the 64 bits of doritos you have to push in through the vents as good luck charms.

imagine being the original m64 developers and thinking "ah this code is a little rushed, but who's really gonna be looking at it......"

There's a bit of confusion around the floating point register modes. FR=0 selects the mode in which there are 16 64-bit floating-point registers, the even-numbered registers access the lower 32 bits of a double while the odd-numbered registers access the upper 32 bits of a double. FR=1 gives you 32 distinct *64-bit* floating-point registers, not 32 32-bit registers; this mode relies on having 64-bit GPRs and using dmtc1 to load double-precision values into the FPRs, the FR=0 mode was for older MIPS versions that did not have dmtc1 so required two mtc1 instead. The FR=1 mode crashes for you when using doubles as GCC cannot generate correct code for this mode on old ABIs for the VR4300, but this could conceivably be patched (not that there would be much benefit to using doubles)

For people who don't know, note that *nowadays* having larger registers can improve performance by a lot, even though it was worthless in 1996. Modern computers have SIMD instructions that allow us to do math on multiple values at once in a single (ish) instruction as long as you can stuff them all into a register. So for example, you could fit four 16 bit numbers into a 64 bit register and multiply 8 numbers in one instruction. Or even more! The newest x86 CPUs have registers as big as 512 bits, with AVX512 instructions. Also note though that most programs don't take advantage of the instructions at all, simd is a little situational and inconvenient to program in most languages. You usually see it used by the same breed of wackadoodle programmer as Kaze who sacrifice Yoshis to the vroom gods in exchange for incomprehensible powers of compilation.

I work in 16 bit (and lower) floating point standards. There was no such thing as 16 bit (standard) floats until IEEE754-2008, which also brought us FMA instructions. As for 16 bit ints and uints, that’s a mips ISA thing

the jaguar was "64" for its 32 bit video chip + 32 bit sound chip

We made this even more confusing for me is that generally when people talk about 64 bit architectures versus 32 bit architectures they generally are talking about the difference in the virtual address space size increasing beyond 4GB. Obviously the N64 has nowhere near 4GB of memory, but it DOES have virtual memory addressing! 😲

Makes me think of this as a somewhat reversed situation with the Sega Genesis/Mega Drive. The Motorola 68000 CPU had 32-bit internal registers, but a 16-bit external bus, and was practically exclusively used as a 16-bit system. By marketing logic, Sega was underselling the console's performance on that basis. Then you got the IBM PC's 8088 CPU, which was 16-bit internally (and programmed as such), but the external data bus was 8 bits, yet I'd say the IBM PC is often seen more as a 16-bit system than 8-bit.

At the time the N64 came out, no one had a clue what the bits really meant, so it was pure marketing - and it worked. When the rumors about the gamecube started a few years later, one would read about people expecting the gamecube being 128-bit for sure and "Super Mario 128" was the fabled new mario game back then. Yet today after the rise of 64 bit home computers everyone knows that there is virtually no more benefit for going from 64 to 128 bits. 64 bit architecture is here to stay.

for anyone wondering, Atari Jaguar which came out 3 years prior to N64, marketed as 64-bit, had only a 64-bit object processor and blitter logic block, but the main CPU was 32-bit. a hard stretch to call 64-bit outside of marketing.

The "64bit" designation really did come from the memory bus though. With the N64, the main processor is really the Reality Signal Processor - which did your animations, T&L, sound, and drove the rasterizer. It ran at 62.5MHz, and with 64bit registers interfacing with the unified memory bus that amounted to 500MB/s of bandwidth. Now the memory itself wasn't truly 64bit because it was serial RAMBUS technology. Instead, it was 9bit and clocked at 500 million transfers per second. However, the 9th bit was only accessible by the rasterizer - not by the RSP. It's thus not counted because it's reserved for a supporting processor, not the main one. So, the RSP has 500 million 8bit bytes of available bandwidth every second and which matches 64bits clocked at 62.5MHz. So you essentially had a 62.5MHz 'computer' with a 64bit main processor connected to 64 memory and that is where the designation comes from.

Humans can’t hear any improvements from 24 or 32 bit audio over 16 bit, or from higher sample rates than 44.1 khz. The CD really perfected digital audio, at least from the listener’s point of view. It’s still useful to use 24 bit audio for recording, and audio is processed in 32-bit float in DAWs, which is also very important. But once you have a final product, 16-bit 44.1 khz is literally as good as it gets to our ears. Anything past that is just placebo.

It is kind of like car companies advertising the number of cylinders in an engine. It really doesn't tell you how the performance of the car is, but more cylinders sounds better.

It wasn't just consumers that assumed 64-bit would automagically be better. From what I recall, one of the N64 developers/executives later went on to state that, they had made a misstep with the N64, by building it with the assumption that making the processor as big and as fast as possible would be the best choice, that the peak 1% high of performance was key; when in fact it was increasing the "cruising speed" they should have been targeting, that is, making the average operations per second faster. It wasn't really a corporate decision to knowingly make the console perform worse for marketing purposes. You have to keep in mind that, developers and engineers back then didn't have the firm grasp of what 3d gaming was supposed to look like, or how it was supposed to actually work. For as good as the N64 and Playstation did; it was still very much in the experimental stage of 3d graphics. God, what a time to be alive. We really thought that the technology from Ghost in the Shell and Blade Runner was just right around the corner.

Here's the thing: In the early 90's we were going from having significant limitations due to actual bitness - 8bit cpu's could access 64k ram for example to it being more important what the system as a whole could do. Having 64bit instructions was pointless in a system that was sprite based for example, or just didn't need 64bit etc. (most N64 code is 32bit) BUT having 64bit wide ram, and bus was critical when moving massive amounts of sprites and other graphics around. In the "32bit" era for instance, Intel CPU's were 32bit only all the way up to the Core 2 Duo (discounting other not so great cpus that didn't do so well) But those were totally fine, when paired with a super fast 3d accelerator card that had in some cases a 256 bit bus to ram. One of the Atari guys had a great quote back in the day "It is a 64bit 'system', meaning where it should be 64 bit it was, and where it didn't need to be, it wasn't" or something like that. And that is true now too. Your nice i9 whatever is 64bit, but your GPU, which needs to throw around massive amounts of data and huge computations, is likely far wider than 64bit.

hard to imagine that the entire videogame hardware industry throughout the 1990s was dictated by one dumb marketing decision by Sega when they released the Genesis in 1999, they could've picked any of a dozen metrics to compare it to the NES to. they could've picked the clock speed (7.67MHz on the Genesis vs 1.79MHz on the NES) they could've picked the amount of memory (64KB CPU RAM plus 64KB VRAM on the Genesis vs 2KB CPU RAM plus 2KB tile map on the NES) if they wanted to pick a metric that was actually _useful_ to compare video game console performance, they could've picked the number of simultaneous sprites (80 vs 16), parallax background layers (4 versus 1), or colors (the NES could only display 64 colors total, and only 4 per background tile) None of those metrics are particularly good measurements of how powerful a game console is, even back then, but any of them would've been a better indicator than the one they went with, which was the fucking CPU bus width. as shown in that video, that impacts absolutely nothing with regards to development, but for marketing reasons, every other console manufacturer at the time had to jump on the hype train, leading to dumb decisions like the 64-bit CPU in the N64 and the even dumber 64-bit graphics chip in the Atari Jaguar (which, by the way, came out 3 years before the N64)

Almost no audio is 64bits. CDs are 16bit, as are MP3s and the audio from this KZfaq video. Your device's soundcard is very likely configured for either 16 or 24 bit. There's no reason to go any further for consumer gear, it's simply not needed. All it really does is lower the noise floor, which means that quieter sounds can be reproduced without being drowned out in noise. For 16bit that's already nearly imperceptible at normal listening volume. At 24bit, it is completely imperceptible. Higher bitdepths are only needed in studio recording and mixing scenarios, where a raw signal coming from an instrument or microphone might be at extremely low volume. You might need to amplify a source a considerable amount afterwards, which would also amplify the noise floor. That's where working with 32 or even 64bit files can make sense. In fact, most modern audio software internally mixes in 64bit float to avoid this exact problem.

64 bit audio sample rate might as well be infinite

Nintendo's biggest mistake was the naming of the Wii U

14:02 Yep. That was me as a kid. I was a quiet kid too, but when I opened up that Christmas present... And the N64 played some role in leading me into doing embedded software as an adult.

Bro, you missed out by being a fetus in the run up to N64 launch. I still remember seeing an import N64 in New York a couple of months before it released here. That first glance at the Mario head attract screen will never stop being the most impressive thing I've ever seen with my eyes.

I’m excited to see how making 3d games was a greater offense than the the virtual boy

I feel like it was probably an executive screaming “MAKE IT 64 BITS OUR WE NEED BIGGER NUMBER”

14:50 Mario just casually brutally got run over by train. D:

PS2 had 128 bit registers that let you do bulk operations on 4 32bit floating point values which is the very basis of vector / matrix math which is why it was such a beast for things like physics simulation

Well, the Nintendo 32 just doesn't roll off the tongue as well, right?

Nintendo already had a 32-bit console: the Virtual Boy.

Considering the 64 bit instructions take about twice the time I'd guess that the CPU is basically doing 32 bit math like the software algorithms showed. A 16 bit mode would probably save a little bit of die space in some areas (registers mostly) and used more in others (cutting the 32 but registers in half) if it is implemented with two halves, otherwise if it is a real 32 bit ALU (arithmetic logic unit) then it would have saved a lot more of die space and been cheaper. I might be a little off here, but the gist should be about right.

... Bruh just made me realise. When I was a kid and going on forums to defend the Gamecube, we refered it as the 128 bit gen. Holy moly 💀 I just looked up and people think ps3 and 360s are 256 bits 💀💀💀

0:31 That looks familiar! Nice video, I added it to the page 👾

I think 90% of the consumers thought N64 was just a random name.

I was around for the N64 release and the jump to 3D was insane at the time. I don't think anyone cared that it was 64 bits or even knew what it meant, we just knew number was bigger and games were 3d now. It's kind of like how people thought the 1/3lb burger was smaller than the quarter pounder (1/4lb burger), obviously bigger number means more, right? It doesn't matter if it's actually true, as long as dumb people (the average person) thinks it is a certain way.

Fair note on the Gamecube and Wii, those *do* have 64-bit Float Registers, so it's still 64-bit in that way. They also use an extension of the instruction set which lets you hold two 32-bit Floats in a single register, which lets you do some fancy SIMD type stuff

Sony is STILL advertising the PS2 as a 128-bit machine in Astro's Playroom -_-

13:52 "unfortunately I was still in my mother's womb when all this marketing happened" - Are you Turok? bc you made me feel like a dinosaur with that attack 😅😅🙈🙈☠☠🤣🤣

Nintendo 64™ just sounds better than Nintendo Optimized 32™

As somebody already pointed out, the r4300 was just a readily available product on the shelf, that SGI was selling for very cheap; their product sheet says it's intended for printers, routers, and other low-power devices. Buying an off-the-shelf product means Nintendo could reuse existing tools, like a compiler chain, already made for that product. The 64-bit integers could allow for 64-bit fixed-point calculations, if the developers ever wanted to use it; but the CPU lacked fixed-point instructions, so fixed-point would have to be made in software (and that kills all the speed advantage over floating-point.)

this reminds me of how sony used the cell for the ps3

I always found it funny how they went back to 32 bit with the wii and gamecube.

In 1993 the Atari Jaguar was "64 bits" (data path from the DRAM to the CPU and Tom and Jerry chips is 64 bits wide).

The R4300 in the N64 is just a commercial off the shelf part with some slight differences (pinout) to the standard NEC VR4300. NEC produced the R4300 in bulk for all sorts of low-cost applications (printers, networking, arcades), which probably made it an attractive (and inexpensive) solution over a custom developed part. The console did get a revised CPU, probably just a VR4310 CPU with better physical and electrical performance.

sir, is it really necessary to implement 64 bit technology that serves no purpose? it would be much better dedicating resources to the ram buss going vroom vroom.

I was a PC gamer in the 90s. I had a Genesis for a while, but that was it. I can’t describe to this day how strange it is to see PC gaming be so common and big. That simply wasn’t the case at the time. What it comes down to is that video gaming at the time was still a question of how much like Nintendo’s games something could be, which meant how simple the rules could be and still be entertaining. This is why you could build the technological masterpieces that were Doom, Quake, Half-Life, and Unreal, or the complex gameplay of Warcraft II, StarCraft, Daggerfall, Lands of Lore, or all the Space/Flight sims and so forth, but you still couldn’t compete at scale with something like Super Mario World, Zelda, or Mario 64. Gaming was expected to be much simpler. As a rule, this is still true today, with the Switch having have become what it did even though Nintendo was in trouble in the mid 2010s prior to the switch. The 90s was a time of technical growth, and it culminated with mp3s and the internet hitting full swing in the early 2000s. The 64 bits was just Nintendo latching on to that trend, even though their strength remained a question of pure simple gameplay. What matters more from a technical perspective is the instruction set, which is why video games of the mid 90s were so technologically advanced relative to anything on consoles. By the time of Unreal and Quake on PC, you could dedicate the CPU to the tasks of the gaming logic, and the GPU could be dedicated to graphical tasks because of cards like a Voodoo 1 or 2. So you could be playing something as complex and beautiful as Freespace on a PC machine, while the best that Nintendo could do was Starfox. Obviously, the playstation closed that gap, but it was still very wide. At the same time, Sony and Nintendo simply put out very good and entertaining games, like Final Fantasy VII, VIII, and IX, Spyro, Goldeneye, Crash bandicoot, etc. While these games weren’t as technically advanced as Unreal, Quake II, Descent Freespace, etc, their gameplay was still more inviting. To play any of those PC games required experience a mouse and keyboard. While PS and N64 games could be very inviting and enjoyed on a couch. The first game I ever saw to bridge the gap was obviously Halo. Not because the gameplay was very particular to the one or the other, but because the experience between the PC and console was very similar. To me, the last thing that the PC dominated technologically was network play. Again, all of these are questions of instruction sets, not register width. The network card on a PC has a controller with an instruction set, and the OS abstracts this for use by the game. The GPU does the same. And the CPU also has instructions that facilitates interactions of all of these from the perspective of the OS and therefore the game. That’s why games on the PC looked more realistic and were more capable for well over a decade on 32-Bit chipsets and memory. They simply had more instruction sets. And you could upgrade these easily because they came with a motherboard specifically designed to handle changing hardware and, therefore, more instruction sets.

It was more of a marketing gimmick than anything that would really benefit the system. They dropped the "bit race" with the GameCube, since it didn't really matter anymore at that point.

Because of this kind of marketing, I assumed the Gamecube has 128 Bits as a kid lol

Everyone knows the 64 stood for the amount of milliseconds of frametime

The "I was still in my mothers womb" comment hit hard. For you this is recent history. I remember this as my childhood. I was lucky enough to be a screaming NINTENDO 64 christmas kid.

Can't forget Sony trying to one-up Nintendo in 2000, by developing the 128bit Emotion Engine for the PS2, which only ran at only 295Mhz with just 32MB of memory. Of course the PS2 was legendary, but again, MOAR BITS == MOAR SALES !!!

What a great day for SM64. PannenKoek and Kaze both uploaded major videos!!

it's probably a lot to do with that was simply what SGI had. The MIPS cores had already migrated to 64bit some time before and the only powerful enough off the shelf budget core they had were that of the VR43-- range. To have made a 32bit only core would have taken even more development and to implement multiple 16bit more still. Given these available chips were already considerably more powerful than all used by the competitors and the system already massively undercutting the manufacturing costs of the available alternatives there was probably little need seen to change what they had.

Take a drink everytime he says "64 bits" 😂

One thing to keep in mind relating to the price of the silicon in the console is that by the time you are spinning your own chips with a bunch of customizations and other stuff like that the bits and registers are not what costs money. Maybe in the r&d stage it might change things a bit but no CPU manufacturer is charging its customers per register. Likely it was 64-bit because that's what was available even tho they had no real use for the functionality. Likely Nintendo went with 64 bits just because its more bits than the competition and had no real use case for it that made much sense or gave any real advantage. I can't imagine a few less instructions here and there was really making a big difference. If anything they needed to invest in a far better memory subsystem. That alone would have unlocked much more potential for the hardware.

Danke Kaze wieder was neues Gelernt

At the time, leaning on bit count as a marketing schematic was important. The bit wars were certainly at their end pint around this time, but it proved to be nintendos folly here. Kaze proving how much better it would have been if nintendo just hadn't leaned into it, the N64 wouldn't have had as many limitations and complications as it did.

Therapist: 128 bit mario isn't real, he can hurt you. 4:07

Oh my god, that train level your building shown at the end is beautiful!

What about the theory, that the GPU of the N64 maybe used a 64-bit memory bus?

The first Xbox, a way waaay more powerful console, was 32 bit.

Since 8 bit was very limiting for NES era, bits became "the factor" for early consoles after it. 16 and the 32 bit looked way better. Gamers had no idea after 32 bits there would be no benefit. But who could argue with.. "DO THE MATH!!"

The reason the N64 uses a "64 bit" processor is likely because it was fastest on paper rather than being optimised for that specific application. As the video even pointed out, when you want to do double or long long maths the speed gain from having instruction support for 64 bit types is massive over needing to emulate the calculations with multiple 32 bit instructions. This is what the CPU designers would have been looking at, since a lot of *industry* applications require the use of 64 bit types, and is one of the main driving reasons that current high performance CPUs offer instruction support for 64 bit types. The issue comes that outside basic operations, instructions on wider bit types are usually slower or use more hardware than their narrower bit type equivalents. As such when the additional precision is not required, such as for most of the logic in a *game*, you are usually better off going with the smaller types so do not see any of the benefit from the instructions for 64 bit types. The best modern example of this would be when using SIMD instructions such as AVX. With some implementations of AVX512 you could choose to perform an operation on 8x 64 bit values, or 16x 32 bit values, or even 32x 16 bit values, allowing significantly higher throughput at the cost of precision. Modern games would likely choose the 16x 32 bit values because render preparation still mostly deals with single precision floats. This does not really hold true for regular instructions on modern CPUs though, since they are pipelined to such an extent that the wider types usually at worst have longer *latency* but the throughput remains the same, being capable of executing multiple such instructions per cycle every cycle. The main reason to still use narrower types for such logic is for memory/cache density rather than execution performance, where they can still result in significant gains. Processor bit depths has little to do with allocteable memory. That is entirely determined by the processor data bus and accompanying support features. It was entirely possible for a x86 "32 bit" linux OS to address more than 4 GB or RAM due to the one of the x86 instruction extensions. 32 bit builds of Windows could have as well, but Microsoft choose not to support the feature widely, and instead push it as part of their x86-64 "64 bit" version of Windows. The x86-64 instructions would help process such bigger memory addresses more efficiently, but are not required to do so. This approach is how old 8 bit consoles such as the NES could access more than 256 bytes of RAM/ROM.

thank goodness I can get that extra 4 GB of RAM in my N64

16 bit sound not only can sound great but it does sound great.

ive often wondered how much better the n64 could perform if the slow RDRAM was could be swapped out with the fastest compatible RDRAM. ive seen a guy put 8mb on to a n64 motherboard so the expansion wouldnt be needed. so i know its possible.

The fact the N64 was passive cool'd just mindblows me still