64 Bits: Nintendo's BIGGEST Mistake

Patreon: / kazestuff
Streams: / @kazeclips
🐦 / kazeemanuar
MERCH: kazemerch.myspreadshop.com/all
Credit to @prismcreates for the mario render used in the thumbnail!

[@KazeN64]

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,...

[@sleblanc]

Are you saying that Nintendo could have called it the Nintendo 72? We would have had Super Mario 72 and Donkey Kong 72 instead?

[@kreuner11]

Wow, can we use modern Gcc with a specific profile to fully use the N64 ISA?

[@kreuner11]

9bit? Wth

[@Clownacy]

A CPU's 'bitness' is not determined by the size of its registers, otherwise the Mega Drive would be considered a 32-bit console. What is 16-bit in the Mega Drive's 68000 CPU is its data bus. Data bus size is important when designing a circuit which uses a CPU, hence why defining how many 'bits' a CPU is is necessary in the first place.

[@alexc4924]

​@Clownacy wrong , the 68000 is a 32 bit processor hands down.

[@coolbrotherf127]

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.

[@NappaAbridged]

And the GameCube wasn't even a "128bit" console when it was just two 64 bit processors

[@batofdestiny7801]

64 bits. 32 bits.

[@Medachod]

​@@alfombracitario Yeah, they're spitballing. GameCube is 32-bit.

[@chikato7106]

​@@alfombracitariobro didn't watch the video

[@LandonEmma]

Wait really why?

[@ncorn-lm8vd]

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.

[@KazeN64]

very good comment! thank you for the input.

[@kargaroc386]

I'd actually bet that most of the N64's shenanigans were a consequence of the culture at SGI and where they were headed. They were not in the business of making game GPUs, but rather GPUs for business. Most of that knowledge would carry over yeah, but you'll get lots of weird stuff like high latency in the GPU, which for what businesses in the early 90s were using 3D graphics for wasn't as big of a deal. Likewise, the 64-bit CPU was probably because ALL their upcoming systems were 64-bit, so it was natural. Then N saw it and went OMG and hyped it to the moon.

[@enoyna1001]

Can you explain it to me like I'm 5?

[@arciks11]

Can I ask who are you? I assume someone who worked at SGI at the time based on your comment.

[@jc_dogen]

​@@kargaroc386 look up the video called oral history phil gossett. he explains a lot of the development of the chip. most of the problems were due to rambus, which was chosen by nintendo for cost. they were able to implement pretty high quality rendering for the time, under tight constraints.

[@Visuwyg]

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

[@pleasedontwatchthese9593]

I know some new game developers on modern hardware use 64 bits for large game worlds. Think of minecraft when you travel really far and the world gets funky. Anyway everything I said has nothing to do with the n64

[@thomasturtletet]

vroom vroom

[@1MyNickname1]

​@@pleasedontwatchthese9593 it also helps wuth drawing programs for planning where you can often run oom with 32 bit especially using multithreading.

[@GGigabiteM]

@@pleasedontwatchthese9593 CPU bits have nothing to do with how large a game world can be. You can represent numbers far in excess of the largest register on a given CPU. Pac Man used a Zilog Z80, which was an 8 bit processor with some 16 bit features. The largest number it can represent is 65,536, but the highest score you can get in the game is 3,333,360. Game worlds are in the same boat. You could of course use a coordinate based system that would be tied to the maximum number the processor can fit in one of its registers, but you aren't solely limited to that. There are a few older games that could dynamically load the world on the fly and the player never saw a loading screen. The world size significantly exceeded the maximum CPU bit width of any register. Minecraft's infamous "far lands" are from a bug in the world generation code, it originally was never intended to generate worlds that large, and did tie the world coordinates to a fixed bit width. But while it did it that way, it didn't have to and could have been a truly infinite world if Notch had designed it that way from the start.

[@KirikkSiSq]

​@@pleasedontwatchthese9593 yeah, Minecraft is the right example. On Bedrock, they still use 32 bit, so the world becomes unplayable at 2 million, not 30 like Java

[@faith9113]

Because higher bit means more better

[@minecrafter3448]

In 1996 it literally did mean that

[@minecrafter3448]

More powerful LITERALLY meant better games until the 128 bit generation

[@zaxlor]

It's got ALL the graphics you could ever need!

[@mechadeka]

*more betterer

[@mechadeka]

@@minecrafter3448 Watch the video.

[@SendFoodz]

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.

[@Ashanmaril]

Sounds like that's what Nintendo should have done. Do the bare minimum to not get sued for false advertising when you market it as 64-bit, then actually just use a 32-bit CPU for everything for the performance safety advantages.

[@pleasedontwatchthese9593]

You could also use that same logic for 8bit and 16 systems because it often used an address register double it's standard register size.

[@Wuerfel21]

Actually, the main CPU is the same Motorola 68000 used in the Megadrive and Neo-Geo, which most people call 16 bit. Instead the Jaguar has two 32-bit RISC coprocessors, which maybe they thought should add up to 64. Bizzaro hardware design.

[@DonutTPOTer]

​@@Wuerfel21Genesis*

[@fnjesusfreak]

@@Wuerfel21 Most people, perhaps, but not Amiga people, who will point out that the 68000 is actually 32-bit under the hood.

[@KingBowserLP]

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).

[@Wiimeiser]

This happens in software, too. Skyrim mannequins, for one.

[@Great-Documentaries]

"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." Sorry, no. Nintendo wasn't filled with SGI workstations as there was zero reason for them to be. A few people might have used them to model (and then drastically downscale) models, but they were programmers and thus had no familiarity with the MIPS architecture or how to program it. Please stop pretending you know about 1990s game development. You clearly do not.

[@laelcellier1673]

@@Great-Documentaries But the peoples behind PilotWings64 were working on software that had to run on ꜱɢɪ workstation (commercial pilot training). Openɢl came from ꜱɢɪ.

[@LockedPotato]

@@Great-Documentaries Not saying either one of you is correct or not but... Nintendo did actually create and test at least SM64 on SGI workstations. There's literally a test build that runs on IRIX.

[@xenozelda0102]

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

[@digndie]

Switch 64 would have been a nice name XD

[@SuperM789]

Except the later gameboy models of color/light Kappa

[@1mariomaniac]

​@@SuperM789I think he meant home consoles, not handhelds.

[@asiermr]

​@@SuperM789The What

[@se7ense7ense7ense7ense7en]

@@SuperM789 not sure where you got that from the gb and gbc were both 8bit, gba and gba sp were 32 bit

[@staxmurphy64]

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

[@WildVoltorb]

🙄

[@ShadowXeldron]

It gets worse - the Jag doesn't even have a 64-bit CPU. It's just two 32-bit CPUs and the ad was born from Atari "doing the math." This isn't the first time that Atari tried to use bits to sell hardware though because the ST in Atari ST means Sixteen/Thirty Two and is in reference to the Motorola 68000 chip that the ST uses.

[@waterheart95]

​@ShadowXeldron The bitter and object processor are 64 bit on the atari jaguar.

[@primesuspect8567]

haha that am i a joke thing is such a funny joke you could keep saying it it gets funnier every time haha

[@nicolaskeroack7860]

but we are talking about the first one that actually sold lol

[@keyboard_g]

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.

[@keyboard_g]

@@IncognitoActivado What cope, I don’t care what they called it. Look at the chips available in 1995. MIPS 64 bit, Sparc 64 bit (very expensive), Alpha 64 bit (super expensive), PPC 32bit (not available), Motorola 68030 32 bit (expensive and not fast replaced by PPC). Intel Pentium32 bit, hot and costs more than the entire console.

[@IncognitoActivado]

@@keyboard_g Not my problem.

[@Great-Documentaries]

"PowerPC really was just getting off the ground." PowerPC was hardly just getting off the ground. It was based on the 1980s IBM RS/6000 workstation. The 68K family of chips were ANYTHING but expensive. And of course there was Intel. Nintendo had plenty to choose from and chose poorly.

[@brunoldo]

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

[@sirbill_greebi3811]

Same here, buddy. I thought it was talking about the number of bits on screen: 64 x 64 bits. The switch has a 1028-bit architecture. Each register can store 5.0706024e+30 different values.

[@half-qilin]

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.

[@GoodOlKuro]

because it's enough for playback :)

[@IncognitoActivado]

That doesn't count as an excuse.

[@_SereneMango]

​@IncognitoActivado ...I took their comment specifically as extra trivia for people who have zero knowledge in digital audio.

[@CrAzYpotpie]

​@@_SereneMangoLet's hope they are too young to use KZbin with such a dumb attitude.

[@xenotiic8356]

I'm curious, what was your uni major? It sounds interesting

[@crazedlunatic43]

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

[@kurikuraconkuritas]

I wonder if there was ant benefit to that

[@Kurriochi]

Technically, modern CPUs are 512-bit due to AVX512 SIMD instructions. The Dreamcast's superscalar architecture uses 128 bit SIMD and I think PS2 does a similar thing.

[@SianaGearz]

@@Kurriochi 128-bit vector co-processor integrated... which runs on 32-bit registers. Sitting effectively beside a classic 32-bit superscalar processor on the same die. There really is very little integration between them. The other 128-bit unit in the Dreamcast is the VRAM bus. Of course both are helpful to get Dremacast to the performance that it needed, but also... it could have conceivably been done differently with the same outcome. Bit wars are plain stupid.

[@laelcellier1673]

@@Kurriochi No : the maximum size of an Integer inside a vector is still 64‒bits. Such instructions basically allows to use of several ᴀʟᴜ in the ᴄᴘᴜ but the ᴀʟᴜ are still 64‒bits. Even when you design cryptographic ᴀꜱɪᴄs, adders/multipliers are 64‒bits wide as adding 128 or 256‒bits integers directly requires more steps than doing it manually.

[@mirabilis]

Please direct me to an ad that says that.

[@howilearned2stopworrying508]

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

[@mr.m2675]

vr, the actual vr with a head mounted display? (ofcource im not talking about vr we have now)

[@howilearned2stopworrying508]

@@mr.m2675 yes it existed in the 90s - but only as demos that you saw on TV or at trade shows- not a mass consumer product. The graphics were mostly colored polygons with few textures. Virtual Boy was riding that hype.

[@mr.m2675]

@@howilearned2stopworrying508 i saw some arcade vr maschines on the internet but i didn't know consumers were able to have vr tech at home

[@petemiller2598]

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.

[@rightwingsafetysquad9872]

But more cylinders usually literally sounds better.

[@ThePlayerOfGames]

​@@rightwingsafetysquad9872 most modern fossil cars are using only the number of cylinders required and piping in sound to the cabin in order to meet both emissions requirements and customer satisfaction, especially the higher power rated engines

[@ThePlayerOfGames]

Indeed *fewer* cylinders is better as it means the engine is better optimised (outside of the cheap moped and cheap car market), with 0 being the true target

[@Drekel]

​@ThePlayerOfGames Your comment is invalidated due to your PFP. Pls change or refrain from sharing what could be considered information

[@rightwingsafetysquad9872]

@ThePlayerOfGames Manufacturers doing something dumb with synthetic sound does not invalidate my point. 8 or 12 cylinders almost always sound better than 4 or 6. 5 and 10 are odd, 5 cylinders always sound better than 6, and 10 is peak engine music. Fewer cylinders do not necessarily mean an engine is smaller. The GM and Toyota 2.7L 4 cylinders are larger than many Ferrari V8s. But that doesn't matter either, a smaller engine does not at all mean it is more optimized. It just means it's smaller. First, what are you even optimizing for? Weight, manufacturing cost, fuel efficiency, noise, speed, tow capability, driver preference? Let's say you mean fuel efficiency. The most efficient engines are the Ford 2.5L, Toyota 2.4 and 2.0L. They regularly beat engines less than half their size. The most efficient truck engine is a GM 6.2L followed by a Foed 6.7L, both regularly do better than their own 2.7L engines. In motorcycles, BMW's 2-cylinder engines are very fuel hungry, even compared to something like Honda's 6-cylinder Goldwing engine.

[@DaVince21]

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.

[@tyjuarez]

In film, 24-bits is mostly only fine for final delivery formats. Many cameras capture 10 or 12 bit (per channel) footage in a Log color space for extra headroom in the color grading process. An alpha channel is also sometimes needed for transparency. Some cameras now actually have a 16-bit option, as do film scanners for those shooting analog. Modern HDR TVs and monitors output a 10-bit signal, with the lower 512 levels of brightness per channel representing the same dynamic range as the 256 of 8-bit, and the upper 512 being compressed depending on the max brightness limit of the display panel.

[@DaVince21]

@@tyjuarez Oh, I definitely agree that when processing and editing video, the higher quality you have, the better. It's the same for photos or audio when it comes to that. "Most use cases" to me is when viewing non-HDR material on the average TV or monitor.

[@Liam3072]

@@DaVince21 Yep, same in audio, 24 or even 32 bits can be useful for audio edition. But for playback? 16 bits is plenty.

[@musaran2]

Old enough to remember when 16 bits images meant per pixel, not per component.

[@seacliff217]

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

[@Dark_Mario_Bros.]

Yes, except it's real unlike the Genesis propaganda 😂

[@Slamy4096]

@@Dark_Mario_Bros. I would say it was. The M68000 of the Genesis was superior to the W65816 of the SNES.

[@arthur78]

​@@Dark_Mario_Bros.I think Blast Processing was real too. I'm pretty sure I saw videos/forum threads proving it.

[@FunnyParadox]

​​​​@@Dark_Mario_Bros.Except that it was "true" as the Megadrive's CPU was MUCH faster (but still less capable nonetheless) than the Super Nintendo's CPU

[@miguelhervaspalomares5978]

@@FunnyParadox one was better for some type of games and the same applies to the other.

[@jvogler_art4708]

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.

[@smokeydops]

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.

[@Optidorf]

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.

[@observingnerd]

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

[@harveysattic3918]

I mean, the guy's on twitter and twitch. Heck, I've seen him in streamers streams I watch. Chill guy.

[@achunkofbutter]

Dan was one of the top Melee Link players and was a Project M developer/pro player. He's a Nintendo nerd.

[@transfem_goodbye]

​@achunkofbutter i also remember hearing about him in a video about super mario sunshine speedrunning.

[@pronounjow]

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

[@Moshugaani]

It worked on me as a kid. :D "64 is at least double the more of 32 so N64 better than Playstation hurdur"

[@Fuzzycuffsqt]

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

[@Kurriochi]

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.

[@keiyakins]

And even the audiophiles usually only go to like, 24 bit 48khz because that's already overkill for the human ear, or any speaker on the market.

[@mirabilis]

​@@keiyakinsThere are 24bit/192kHz files. :) I have no idea why. Audiophiles must be bats.

[@JoeStuffzAlt]

@@mirabilis Many audiophiles actually can't tell the difference. There's actually 32-bit float, and 32-bit float has a bunch of advantages when it comes to mixing

[@mirabilis]

@@JoeStuffzAlt I would say there's not a single person who can tell the difference between 96 and 192kHz. XD

[@JoeStuffzAlt]

@@mirabilis One issue is that people aren't probably going to buy both the 96 KHz and the 192 KHz version.

[@dkosmari]

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.)

[@Great-Documentaries]

EVERYTHING ELSE from Silicon Graphics (GPU) was certainly NOT off the shelf, and cost Nintendo dearly. Nor were 4300s particularly cheap.

[@dkosmari]

@@Great-Documentaries How much did the 4300s cost Nintendo?

[@SimonBuchanNz]

​@@dkosmaripress release said $50 for samples, $35 for 100k, and other site implied a per-unit manufacturing cost of $15, so probably a bit less than that given their expected sales: I'm guessing $20-$25.

[@WannabeMarysue]

At least the commodore 64 wouldnever scam me

[@ShuckleShellAnemia]

Ultimate Wizard was a fantastic game

[@MegaManNeo]

At least with the bread bin and its successor we know they referred to the internal memory.

[@dacueba-games]

A good portion of the RAM was dedicated to loading basic, so yeah, it did scam you. XD

[@XENON2028]

@@dacueba-games ye but it is banked so you can replace it if you don't need it!

[@thezipcreator]

@@dacueba-games assembly games could bank that out tho and use all 64kB of memory

[@JoshuaVonNoctis]

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

[@tlst94]

Imagine Dil's birth theme song playing irl during Kaze's birth. Which is an orchestral/cosmic remix of the Rugrats opening song. While also showing everything from the universe's beginning, to science, and history.

[@MinuteManGameReviews]

Shut up. Lol

[@Ragesauce]

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!

[@Darkknight512]

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.

[@chucks9999]

Agreed. I don't think it was so much that they said "we need a 64-bit system" but rather the vast majority of modern MIPS processors (at the time) were 64-bit and since the deal was with SGI, who uses MIPS for their workstations, there were very few options for 32-bit without using an outdated processor. Doesn't change the fact the marketing team "overhyped" the 64-bit aspect of the console but that's their job. The argument with 32-bit vs. 64-bit seems to be an allusion to the N64's faulty memory design. Choosing an UMA design was forward thinking but there may have been a miscalculation in the bandwidth demands of the CPU, RCP, and PI, alongside RDRAM's unusual (poor?) performance characteristics.

[@Darkknight512]

@@chucks9999 Yeah, there is definately some decisions around using a core that someone already has. Marketing will always just do almost whatever they want regardless.

[@ruediix]

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.

[@KazeN64]

which directive are you suggesting? i've read through a lot of GCC stuff and never saw anything like that. rendering does not work via floats on the n64. the floats are purely a CPU thing. the GPU all works on fixed point integers. and you hit a lot of depth issues on the n64 due to the depth being brought down to an s16

[@jeffreymalone2079]

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! 😲

[@ViremasterOfUSA]

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.

[@mrmimeisfunny]

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.

[@Eb-ky9xy]

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.

[@Great-Documentaries]

EVERYTHING ELSE from Silicon Graphics (GPU) was certainly NOT off the shelf, and cost Nintendo dearly. Nor were 4300s particularly cheap. Frankly it was a huge mistake to use THAT processor and a pseudo 64-bit architecture and then both starve it of RAM and not give it a CDROM for storage. Nintendo screwed up very badly.

[@Liam3072]

@@Great-Documentaries Hindsight is always 20/20. At the time, nothing was set in stone, doing 3D right was hard, nobody really even knew what "doing 3D right" really meant (see e.g. the Saturn, 3DO, and nvidia's first PC GPU nv1 all using quad polygons rather than triangles). Using the expertise of a company that had lots of experience in making 3D hardware kind of made sense.

[@crazedlunatic43]

@@Great-DocumentariesEven if Nintendo went with CDs, they would’ve attempted to use a proprietary format since the company refuses to pay royalties. So CD playback may not be possible and would’ve been labeled as a pure gaming machine.

[@eddievhfan1984]

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.

[@SianaGearz]

Yes. 68000 is slow in 32-bit operations, since it was designed to compete head on with 16-bit processors and couldn't dedicate much extra logic to it. I think this r4300 is similar in 64-bit being a second class citizen and being cut down in implementation cost as far as possible, since by all reason none of the systems using that era's r4000 series processors would really need 64-bit capability for the time being, but maybe in the distant future but also when the transistor budget and speed would be higher by then. The mixed 16/32-bit design gave the 68000 a massive advantage, in that the memory is flat 24-bit address space where you don't need to make special concessions for where in memory something is. True 16-bit processors used the more cumbersome page-offset memory access. Another advantage is forward compatibility with future true 32-bit systems, including software compatibility.

[@palaceswitcher]

The SNES has pretty much the same situation too, its CPU is more or less just a souped up 6502 with a 16 bit register flag and 24-bit addressing. The data bus was still 8-bit which makes some 16 bit operations take almost twice as long.

[@windowsxpnt2347]

the main reason why people say the ibm pc was more 16 bit than 8 bit is because a lot of pc clones liked to use the 16 bit 8086

[@alexc4924]

68000 is a 32 bit processor through and through. But when people talk about 16 bit consoles they mean consoles with 16 bit like capabilities and that's all they mean.

[@windowsxpnt2347]

@@alexc4924 the 68000 had a 24 bit address bus and the internal data bus was only 16 bit

[@tharo3813]

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)

[@KazeN64]

ohh i had no idea, i definitely missunderstood this then. I thought the reason all the games don't use odd floats was because they were intended as the lower part of doubles. that's good to know.

[@jlewwis1995]

So in theory using the fr=1 mode could theoretically still give better performance (because you have more registers to work with in that mode) as long as you can get it to play nicely with the compiler?

[@KazeN64]

@@jlewwis1995 yeah, it was a 20us speedup in my case though it ran pretty unstable. i was thinking it ran unstable because of the doubles, but it seems like a compiler can circumvent that somehow. i'm no longer entirely confident what the underlying cause for the instability was there.

[@Nodsaibot]

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

[@AyyDraws]

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

[@blueyoshi8517]

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

[@unyu-cyberstorm64]

Or call it the Nintendo Ultra 3D

[@magicalcapi9148]

I think the Sony breakup must have added fuel to the decision. Making a 32-bits CD based console would probably be the most effective solution, but since PlayStation was now on the table, they needed something to differentiate themselves. A 64-bit console was imminent (in the market perspective), so Nintendo took a shot.

[@RAHelllord]

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

[@Kiyuja]

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!

[@ArneChristianRosenfeldt]

TMEM lives on the other chip.

[@xenotiic8356]

Hindsight is 20/20, though I agree

[@davidmcgill1000]

Could've always had double the RAM, and double the price. RAM was the bottleneck in a lot of ways in those years.

[@sethfriedman1479]

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

[@halofreak1990]

Kind of like how the Xbox 360 had a 64-bit CPU, but all code running on it was 32-bit, and they used the upper 32 bits of the integer registers for security purposes. Not sure if it applied to the C++ compilers as well, but the XNA compilers were famously horrible with floating point code, adding casting instructions everywhere if you used 32-bit floats in your code. For performance, you wanted to do all your float math in doubles, and then cast the final result to float, so as to only have a single cast instruction at the end.

[@user-dv9ey4wo1h]

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

[@camofelix]

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

[@KazeN64]

i was thinking of 16 bit instructions for the general purpose registers.

[@gudenau]

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.

[@ArneChristianRosenfeldt]

Isn’t the RDP 2:54 RCP connection 32 Bit? And all the pointers ( Java: Reference) would be 64 Bit and stress RamBus.

[@gudenau]

@@ArneChristianRosenfeldt Vroom vroom.

[@SianaGearz]

Speaking of better suited processors, an SH-3 would be an interesting choice. A 32-bit CPU through and through, but it has condensed 16-bit instructions, reducing required memory bandwidth. When N64 was developed, it would reach 100 MHz with one instruction per cycle in Dhrrystone, ending up a little slower than the r4300 that they went with. But Hitachi wouldn't just give you the core and let you add coprocessors and periphery, you had to buy the processors from them as-is, while Nintendo used customised chips, licensing the core from MTI and letting NEC do the customisations. The way SEGA got their ideal (one could say dream) processor for the Dreamcast is by convincing automotive headunit designers in Japan that they needed the same exact chip with the same enhancements.

[@SianaGearz]

This sort of forward-compatible mixed design has popped up a number of times. The original 68000 is a 32-bit processor of the same complexity and intended to compete with typical 16-bit processors of the era... which would also nominally make Megadrive a 32-bit console if they chose to push that sort of angle? Which is stupid, i'm glad they hadn't done that. The 32-bit instructions are largely slow and not really intended to be used throughout, and the one day to day advantage the mixed design brings is flat addressing as opposed to segmented memory typical of 16-bit processors. I think you're right to suspect that 64-bit forward design is not being very wasteful in the MIPS core, that they kept the overhead to a minimum knowing it's going to compete in the 32-bit world, but it's also not very useful.

[@ArneChristianRosenfeldt]

@@SianaGearz I would have been cool to have seen an upgraded Archimedes. Archimedes has no co-processors, so it does the pixels. With MMX instructions acting on 64 bit, this would be quite fast. Actually, ADD already works on vectors stored in 64 bit if you leave some 000s between the component (4x16 bit). Barrel-shift lets us mix and match components. I only miss a MUL instruction with built in shift and mask to manipulate brightness on RGB. 32x32->64 bit MUL could always be signed. The program would either sign extend one factor into 64 bit or not. Then we would use the same iMUL instruction for all products.

[@Lock2002ful]

Very interesting, thank you for this! Also looking forward to your game a lot!

[@skylo706]

Yay another technical video. Probably said this a lot already but you made me interested in low level programming and modding. I'm still a web dev jobwise but my hobby is assembly and C for modding old games and it's thanks to you I didn't gave up and got where I am right now

[@SpeedfreakUK]

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

[@polycube868]

PlayStation 2 also used a MIPS processor

[@phil5583]

Finally a new Kaze video dropped

[@drsupergood8978]

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.

[@jhgvvetyjj6589]

I like the way x86 handles it (before SSE/SSE2/x64) where all floating point values are loaded into a uniform format of eight 80-bit x87 registers (with 64 significant bits), which ensures that floating point remains precise, and MMX reuses the register space of x87 to store eight 64-bit vectorized registers that allow for 64-bit loads and stores as well as 64-bit bitwise and addition operations and there are operations on arrays of 32-bit, 16-bit, and 8-bit registers that can be used to perform same operation on multiple integers of the 64-bit MMX register.

[@EndOfForever]

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

[@TheLongestConfidence]

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.

[@Rex_iudaeorum]

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

[@Micha-Hil]

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

[@GENIUSGT]

64 bit audio sample rate might as well be infinite

[@Roxor128]

Depth, not rate. Audio is sampled a certain number of times per second. Actually storing it requires quantizing those samples to some size. Usually 8-24 bits per sample, though you can certainly go lower or higher, and there have been many uses of lower depths historically. The difference between 8 and 16 bits per sample at a given sample rate is noticeable, and between 16 and 24 is hard to hear. Beyond that, you're not going to be able to tell, so it's only good for processing. 32-bit floating-point is basically the same accuracy as 24-bit, but easier to program.

[@willwill2548]

IMG! Imagine the size of a 64 bit mp3!

[@seedmole]

I've done a bunch of audio design lately, and one huge shortcoming for 32bit numbers turned out to be indexing an audio clip by sample, which is needed for some playback purposes. 32bit floating point numbers come out to about 350 seconds of audio (give or take a factor of two), so all sorts of factors are limited by that, including oversampled audio.

[@Anytyme06]

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

[@tl1882]

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

[@TonyStarkCLC]

"The PS3/cell can find the cure for cancer". LMAO

[@crazedlunatic43]

The PS2’s Emotion Engine shares something in common with Cell: Both were difficult to program for.

[@fastmovingvolcanomatter]

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

[@toastbrot97]

Quick addition to the color bit depth in the beginning. Usually the bits are being labeld per color channel. Most monitors these days display 8bit per color channel (which is what's shown at 1:26 ), or if you multiply this by 3, since there are 3 color channels, we get a total of 24bits. With HDR and stuff there is a good reason to increase the bitdepth to 10bit or 12bit per color channel. 16bit per CC is completely overkill for pretty much everything.

[@thatfellow7556]

Boy, I was actually thinking this very same thing. I would love to see a breakdown of how many 64-bit instructions were actually used for each major N64 game. Honestly, they should've traded the 64-bit ALU for quadruple the texture cache.

[@chrish2o270]

Danke Kaze wieder was neues Gelernt

[@obinator9065]

gelernt wird hier kleingeschrieben! Jetzt hast du noch mehr gelernt!

[@chrish2o270]

@@obinator9065 niemand mag Klugscheißer Obi, aber danke!!

[@darkfoxfurre]

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.

[@CrAzYpotpie]

Who is this "we" you're talking about? I never thought for a second back then that a Tachikoma was right around the corner for our reality.

[@SilentShadow-ss5xp]

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.

[@superresistant8041]

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).

[@johnsimon8457]

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

[@davidmcgill1000]

In other words it had SIMD instructions, which were the new hotness of the late 90's in PCs. Gamecube had something similar where it could treat one 64 bit floating point register as two 32 bit floating point registers.

[@jhgvvetyjj6589]

x86 also had 128-bit registers with four 32-bit floating point in SSE in 1999. And before that, in 1997 it had MMX which were 64-bit registers that can do bitwise 64-bit integers or operations on multiple 32-bit or 16-bit or 8-bit integers.

[@Margen67]

Psyduck needs HUGS

[@johnsimon8457]

@@Margen67 psyduck has a headache and is full of angst

[@jagenigma]

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.

[@1MyNickname1]

Just like the graphic wars are on its last legs nowadays.

[@Mrcake0103]

"bits" are an exceedingly dumb way to measure a computer's "power". Floating Point Operations Per Second is better, time to sort a list of 10,000 random integers by heap sort is better still, etc.

[@1MyNickname1]

@@Mrcake0103 FLOPS are also a dumb way to measure stuff as efficiency in how well they are used is way more important.

[@snigwithasword1284]

Love these technical breakdowns

[@kenh6096]

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.

[@convincingmountain]

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

[@Rose_r3v]

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

[@TonyStarkCLC]

"Super Mario 128"... LoL...

[@keiyakins]

I'm sure somewhere out there someone is calling the Switch a 1024 bit console

[@Rose_r3v]

@@TonyStarkCLC i mean that is what people often call that gamecube tech demo with all the marios

[@Rose_r3v]

@@keiyakins it’s me. i’m going to do this. i’m going to spread misinformation online and convince people that the switch is a 1024 bit console

[@squidgysquid6237]

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

[@KazeN64]

oh that's your website!! that's pretty cool. i reference it a fair bit to explain stuff to people haha

[@KrunchyTheClown78]

Thanks a lot for clearing all that up!

[@BinaryCounter]

Almost no audio is 64bits. CDs are 16bit, as are MP3s and the audio from this KZbin 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.

[@KazeN64]

yeah agreed, same for pixel depth. i just wanted to cover a bunch of different measures and bit counts so give the system a good look.

[@gamecubeplayer]

mp3s aren't 16bit because they're lossy just like this video

[@BinaryCounter]

​@@gamecubeplayer While mp3s have an effective dynamic range of 20bits, in nearly all scenarios both the encoder and the decoder truncate that to 16bit PCM on the input/output, making mp3s 16bit (at best, not considering the possible signal degradation due to lossy compression). Same goes for AAC (in most cases).

[@LeonAlkoholik67]

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

[@Sauraen]

It's not a theory, it did. Each transfer to or from RAMBUS RDRAM is 64 bits read or write per RCP clock cycle, plus overheads for starting a new transfer. (Actually 72 bits because of the use of parity RAMs for antialiasing data, but for everything other than that part of the graphics pipeline, the extra 8 bits are invisible.)

[@IncognitoActivado]

@@Sauraen Nice try, dude. XD

[@Sauraen]

@@IncognitoActivado What?

[@forasago]

@@Sauraen antialiasing data??

[@Sauraen]

@@forasago Yes, I'll spare you the details, but each pixel of the "16-bit" framebuffer is 18 bits, with 5 each for RGB and 3 for coverage, which has to do with antialiasing. Similarly each pixel of the Z buffer is 18 bits, with 14 for depth and 4 for the derivative of depth. To do this, they are using parity RAMs, which have 9 bits per byte instead of 8. Normally the extra bit is used as a checksum to detect memory corruption, but here it's used for the antialiasing.

[@punishedkid]

Parallel universe where we got the Nintendo 32.

[@taktoa1]

In general, having a wider datapath means more amortization. For example, if you want to switch between N 64-bit values, you use a 64-bit N-to-1 multiplexer. That multiplexer consists of N*64 tristate buffers plus a decoder, which converts from log(N) bits to a one-hot signal of N bits. Overall, that means the cost of an M bit N-to-1 multiplexer is O(M*N + log(N)), which means that for small M and large N the log(N) term can dominate. Many circuit elements are built out of multiplexers or have similar log or constant factors (e.g. column decode and row decode in SRAMs), so all else being equal I would expect it to be more expensive to add a 16 bit mode to a 32 bit processor than to add a 64 bit mode. My brain is calibrated for modern process technologies so I have no idea what it's like to design a processor back in the days of the 350 nm process, but I imagine that these differences which could be considered too tiny to matter now would have been more significant back then (nowadays the area consumption of logic doesn't matter as much because SRAM scaling has lagged behind logic scaling).

[@KazeN64]

huhh but O(M*N + log(N)) with n=64 and m=32 is bigger than O(M*N + log(N)) with n=32 and m=16

[@taktoa1]

@@KazeN64 The big O notation hides a constant factor on the log that is larger than the constant factor on the MN term.

[@KazeN64]

@@taktoa1 well that makes bringing up that formula just confusing LOL, but good to have insight from someone who works with this stuff.

[@zephyr1181]

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

[@Moshugaani]

4 MB :---)

[@ShurMaster]

I feel Ninty realized halfway through the 64 Bits weren't necessary and probably but probably continued using it as they were fairly deep in dev of Mario 64, and continued not optimizing games as much out of fear of making Mario 64 look bad in comparison.

[@eructationlyrique]

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

[@jakescartoons6045]

I'm really looking forward to your new game! Can't wait to play it!

[@Yipper64]

I like how 64 bits was basically something that developers only ever used on accident and the majority of the reason the expansion pak was used was due to some games breaking without it. Like, the entire console seems to be constantly facing this type of issue.

[@waterheart95]

The Dk64 rumor was false. DK64 used it to enable more dynamic lighting. Other expansion required games used it just because they needed more ram for data.

[@ZERARCHIVE2023]

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

[@dacueba-games]

Everything was passive cooled back then...

[@CodeDashie]

console gpus didn't consume enough power back then to cause overheating.

[@alvallac2171]

*passively cooled

[@windowsxpnt2347]

@@dacueba-games i would say by 1996, computers were starting to need a fan especially with things like the pentium and pentium pro requiring a fan and the older 486 dx 4 100 could be cooled passively, it was recommended you put a fan on there

[@chr1st0pher]

Your videos are the best, always really fascinating even though this stuff is way over my head

[@user-zo1kn8ob7h]

0:05 screams in atari jaguar

[@Teppich]

I'm always amazed by your big brain

[@theeternalsuperstar3773]

Your voice is very soothing.

[@AdolfoWWolf]

Incredible video mate, i never knew exactly what the 64 bit stood for, and after i learned about graphics cards memory bandwidth, i though it was about that so when i saw the first 128 bit video card, i though "that's it, the N64 was beaten", but at the time didn't knew what i was talking about, and now seeing this videos makes me realize i still don't know much better hahahha thanks mate, love the insight you bring us with these videos.

[@ravengaming4143]

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.

[@ChampionRevilo]

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

[@SimonBuchanNz]

It has 128bit SIMD registers, eg doing 4×32bit multiplications at once. Useful when you have a lot of colors (red, green, blue, and alpha) or vertex positions (x,y,z,w - where the w is used for perspective)

[@ChampionRevilo]

@@SimonBuchanNz I thought we never actually went past 64 bits. Modern PCs are 64 bits after all, or am I wrong?

[@SimonBuchanNz]

@@ChampionRevilo depends what you mean. There's lots of different "bits* you can be. Intel chips have AVX-512 instructions, which operate on 512 bits, memory buses are up to kilobytes, and Nvidia's GPUs have "tensor cores" that operate on even more. But in general, day to day use CPUs are still occasionally in 32bit mode (though much less nowadays)

[@Liam3072]

@@SimonBuchanNz Using the SIMD registers as the number of bits of one's CPU, rather than the general purpose registers of the ALU, is kinda cheating IMO. By that metric, the Pentium 1 MMX was a 64-bits CPU, the Pentium III was a 128-bits CPU and modern CPUs are 512bits. Which nobody really claims.

[@SimonBuchanNz]

@@Liam3072 yeah, I would agree in a vacuum, but it does get weird as soon as you get outside of desktop CPUs. Like, what bitness is Nvidia's Ada Lovelace (40xx)? Each "SM" has hundreds of cores, including 32bit and 64bit floating point, 32bit int, matrix units supporting 8 to 64bit operands, and it's generally going to be invoking the same operation on 32 of those at once. The classic definitions of bitness fall apart here.

[@dafff08]

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.

[@KazeN64]

so many languages in the world and this man chose to speak facts

[@greasebob]

Just an aside to the N64 discussion here-- Castlevania: Legacy of Darkness actually used antialiasing in its Hi-res mode which equated to a horrible frame rate. You can disable the AA in Hi-Res mode using a Gameshark code and it actually improves the frame rate significantly. Its the only game so far Ive tested with such noticeable improvement.

[@Gamers_of_Oz]

My grandmother bought me a N64 (which I still have) 3 months after it came out in Australia I can tell yuo it was GLORIOUS I took to that holiday back to my nans and played it on a 12 inch colour TV it was glorious then my mum picked me up after work and I got to play it on a 22 inch tv or 59cm which was big at the time. I was 13

[@humanbass]

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

[@Clancydaenlightened]

64bit as in CPU alu may use 64bit and gpu internal register 64bit But not the address and Data busses between the chips maybe 32 or 48 bit Open a cartridge, what's the data and address sizes on the memory chips if the use standard chips, (open an unlicensed N64 cart) but Nintendo typically gets custom maskroms now they include custom multiplexing logic for the cartridge port with a off the shelf chip.....now it's an in house chip How much more can you really shove where the ram expansion goes, shove a fpga, small bios, and 16megs or something with an esp32 Now you can make a "64bit" KZbin app or web browser 🙃

[@Clancydaenlightened]

64bit in the case means something because you get better flops for geometry and you can count higher using less memory than a 32 or 16 bit and that's also good for Floating point

[@Clancydaenlightened]

But having 64bit can be used and exploited with bank switching even if you don't have a 64 bit address/data bus, you can add the missing bits back

[@Clancydaenlightened]

Get an Atari Jaguar and see if you can fix that "64bit" 🙃

[@rgm4646]

What can I say? Back then bits mattered to us. lol The N64 was sold out EVERYWHERE in my area. I got lucky because a walmart employee had one behind the counter, and I bought it.

[@mekafinchi]

I think the real lesson is that higher-bit hardware isn't better just for doing more bits at once, it needs to do the operation in the same/similar time to actually perform better

[@RupeeRhod]

I mean it's fair to call the N64 a 64 bit console if we ignore basically what that actually would encompass fully, and just stick to that it could use a 64 bit datatype. I'm not saying you're wrong, but the way Nintendo marketed it and what the N64 is capable of isn't really different than its 32 bit competitors at the time.

[@KazeN64]

yeah i go over a few definitions, my conclusion was basically "there's at least 1 definition by which you may call the n64 a 64 bit console" which is good enough for marketing i guess

[@RupeeRhod]

@@KazeN64 indeed, I loved your in depth view at how often compiler would just end up doing doubles for no reason, or because of programmer error. I bet a fun thing to discover, and hell to actually keep an eye out for.