Patreon: / kazestuff Streams: / @kazeclips 🐦 / kazeemanuar MERCH: kazemerch.mysp... Credit to @prismcreates for the mario render used in the thumbnail!
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,...
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.
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.
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.
@@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.
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
@@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.
@@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
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).
"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.
@@Great-Documentaries But the peoples behind PilotWings64 were working on software that had to run on ꜱɢɪ workstation (commercial pilot training). Openɢl came from ꜱɢɪ.
@@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.
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.
@@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.
"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.
They would have literally done what Sony did with the Playstation and just use a R3000A + custom GPU from Toshiba/Nvidia/ATI/etc (there were a lot of options in the 90s for GPU), the N64 was poorly balanced budget-wise all around, and many of the novelty ideas that SGi pushed (unified memory, etc.) were extremely poorly done. It wasn't even sold cheap, and the N64 ended up as a bad financial decision for Nintendo, hardware wise. They simply took bad decisions and bleeded out market share until the Wii+DS for it. However, bad hardware does actually make up the place for good games, ironically, as it forces creative solutions.
@@MsNyara The Wii wasn't even really successful. It was cheap compared to the other consoles. That's literally the only thing it had going for it. Look at the number of units sold vs the number of games sold. People bought one for their kids and one for grandma and grandpa to get them to move but it just sat there gathering dust. Pretty much the only titles that sold were first party titles... Meaning again, it was nothing more than a Mario/Zelda machine. It was an underpowered non-HD Mario machine and no serious gamer played it.
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.
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.
@@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
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 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.
@@howilearned2stopworrying508 Virtual boy, while marketed wrong in the sense that it wasn't VR as we wanted. Was such a nice little machine. The fact that you had to be in a quiet area, the 32 Bit sound, (i think) and the whole experience on most the games are unlike anything that ever existed or will ever exist. Its underrated and a cool little device that is a bit of a cult classic now. Wario Land belongs in the top 50 best games ever made all things considered.
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.
@@mrmimeisfunny Yes and no. Actually the PowerPC 750 it's based on is from 1997, so it's even older. But that doesn't really matter as the Wii U's 3-core iteration went a long way from that basic design with far more cache, cores, clock speed and additional features. Another example: Intel went back after the Pentium 4 Netburst debacle and based their new core - architecture CPU's on their Notebook offerings, which themselves were based on the Pentium 3. So going back to an older design as a base can totally make sense, based on the given scenario. Changing the architecture at this point wouldn't have changed much, as Nintendo had no ambitions to build a technical competitive console anyways so they would just have swapped it for another low power alternative with additional costs in development both hardware and software tools.
@@mrmimeisfunny so? modern windows and linux PC's use x86_64 which is just the 64-bit version of x86 which was originally 16-bit and dates back to 1978. as long as the speed keeps being upgraded to keep up with the times it doesn't matter how old the architecture is
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.
@@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
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.
@@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.
@@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.
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.
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.
What's weird is that he develops for a retro console that was presumably in its prime when he was still a baby (if I understand correctly)? I mean, most of us have nostalgia for the stuff that was around in our _teens_ or something like that (give or take). But Kaze devotes his time to a game and system from the time when he was either _in the womb or an infant_ 😂
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.
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.
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.
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.
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!
@@davidmcgill1000 The PSX did fine with a similar amount of RAM, the problem was Nintendo/SGi going with an unified memory approach, which made coding memory use a real nightmare, as every operation bottlenecked the other, so you needed to over-optimize your code (aka see Kaze's work) to actually get to use your memory decently. Or also why N64's expansion pack (doubling total RAM) really just helped meaningfully toward the end. The other mistake was the 9-bit bus, which would bottleneck every other single part of the whole hardware, specially with unified memory making use of the tiny bus even more frequent.
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
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)
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.
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 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
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
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.
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.
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.
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.
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.
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.
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.
@@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.
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.
Almost no audio is 64bits. CDs are 16bit, as are MP3s and the audio from this UA-cam 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.
@@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).
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
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.
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.
@@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.
@@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.
@@Great-Documentaries Going CD would've increased to BOM-costs, likely meaning they'd have to cut in other departments (like the PS1 did). In short, design is a matter of trade-offs.
@@sundhaug92 but the 16bit era already showed the potential of CDs, from the MegaCD to the PC Engine CD. Developers had so much more space to work on, and they were cheaper to produce.
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.
The Xbox had the main advantage of possessing Direct3D. The only thing the xbox didn't have was HLSL (yet). Back then the shaders were written in assembly. The N64 didn't even have access to any type of shader!
@@lordkrythic6246 The Xbox was dramatically better in basically every way, it only came out 5 years later, but tech moved fast back in those days. It had many times the clock rate, RAM and bus speed. The GPU in the Xbox was a 233Mhz Nvidia GPU with parallel shader units while the N64's 'GPU' was a modified CPU running at only 63Mhz. IMO it wasn't really Direct3D, but the parallelism in the GPU that makes the biggest different, aside from the huge increase in clock rate.
As a kid, I thought it "64-bit" was addressable space because of their amazing RAMBUS invention and they wanted to try and get more FLOPS out of that architecture. Turns out, I wasn't too far off but I was still in the "factoid" territory. Anyone else "learn" the CPU-Address space + RAMBUS argument? I feel like that was a thing back then for the nerds.
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.
"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.
When talking about 64 bit CPUs, most people refer to the adress width (which requires 64 bit registers) and results in 64 bit address bus width. According to the internet, the n64 has a 32 bit address bus, which makes sense, because the n64 does not have even close the amount of ram to hit any limit with 32 bit addresses.
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.)
@@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.
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.
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.
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.
Just to let you know, 8bit, 16bit and 64bit had nothing to do with the color regarding consoles and had been something that people kept confusing since regarding computers it was regarding the colors. The bit for consoles was actually regarding the CPU, for example SNES and Turbo Graphix 16 had a 16 bit CPU. N64 had a 64bit CPU, NES and Sega had an 8bit CPU.
@@KazeN64 it was a common mistake that was made especially growing up as a kid in the 80s . I was playing Arcade games, consoles and computer games back then and even though the bit wasn't specified in consoles so much. With computers at the time it was specific with color. Even now if you were to do a fresh install of windows and not have the driver for the video card installed on a computer today. It would appear with 8bit or 16 bit color unless they changed it with windows 11. 256 color was a huge deal back in the 80s/90s and made a huge difference that stayed in place for so many years. Personally I feel the Turbo Graphix 16 was the most underrated console of it's time. Not only was it the first to utilize CDs when you attached the accessory to it but it's the only one in which the basic cartridge for it was also compatible with it's mobile console the Turbo Express.
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.
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 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)
@@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.
@@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.
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.
Nintendo is not a microchip manufacturer, and there are a finite number of CPU architectures, all with different prices. It stands to reason that you won't always be able to get the exact CPU your game console needs to function optimally.
I was astounded studying for my CompTIA A+ and learning just how little a difference 32 and 64 bits make with a processor. Hell, there are PCs running today that are still on 32 bit CPUs [though Microsoft is dead-set on killing that off with Windows 11 requiring a 64 bit CPU, and not even releasing a 32 bit version of the OS] It's the same basic principle of how video game graphics peaked in the mid 2010s and have plateaued since then- diminishing returns. 8 bits is a world more powerful than 4 bits, 16 bits is way better than 8, 32 bits is a sizable improvement over 16, and 64 bits is a step up from 32 bits. Because processor bits increase exponentially, 64 is likely the highest we'll need to go for a damn good while, 128 bit CPUs MIGHT start to come around for home computers some time in the 2040s or so. But a strong processor is only a way to PROCESS the instructions sent by other components- a 2048 bit GPU would mean jack shit with 4GB of RAM, a GTX 1030 graphics card, and a spinning hard drive.
It's a shame they didn't call it the original name of "Nintendo Ultra 64" due to some copyright or trademark issue or another. Heck I found an etsy page that makes a decent "Nintendo Ultra 64" jewel modelled after the original Nintendo Power advertising for the console (minus the curved surface, unfortunately). At least then the marketing would have been all about the "Ultra" part and not the "64" part. "Super Mario Ultra", "Kirby Ultra", and so on and so forth, just like all the "Super" names on the Super Nintendo/Famicom. Heck the massively loud "Ultra Combo!" from Killer Instinct was a not so subtle bit of marketing for that original name. So it seems what I'm hearing is yes it's a 64 bit console, no that isn't a good thing, but they'd run a few things in that mode purely to prevent bugs from accidental use of 64 bit floats. Now, I can't say whether or not Atari and Nintendo added that mode PURELY for marketing (I'm not sure if Nintendo of Japan marketed their consoles purely on bits at all), but in terms of manufacturing, it may actually have been cheaper to design the chips that way rather than custom design a purely 32 bit SGI chip with it's own instructions. Manufacturing costs MAY have been the likely culprit of this design decision. It's still funny to me that 64 bit processing didn't actually become something close to useful until PCs and later consoles actually started including more than 4GB of RAM.
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.
i love how the 64 bit marketing didn't hinder Sony's sales at all, and actually managing to sell THREE times more units than the N64 did (PS1 sold around 100 millions as opposed to the N64's 32 millions)
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
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
It refers to address space. Pointers have a range of +/-512GB (half a TB The TLB only looks at the low 40 bits of the address for page table lookups. This is still worthwhile even with a 32 bit physical data bus because you have a gigantic virtual address space, where you only have part of the data in memory at once, and use it to do things like mapping in entire DVD or something, with demand paging (if N64 had DVD that is, LOL).
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.
one small mistake: the usual thing for determining the bitrate of a CPU is the native integer size, not the register size. This is an absurdly pedantic difference to even bring up and is nearly never relevant, only being relevant when a CPU uses some weird design that uses a full native integer for instruction data and just adds more bits to the instruction word, and even then if you go back in the 90s your definition is exactly what would've been used. Basically it's pointless that I've commented this. I'm just padding your comment section. hiiiiiiiiii whoever reads this =]
Funnily enough we now try and utilise 16-bit floating point values and packed math as much as we can in modern shader code where there isn't a noticeable precision tradeoff, as packing those instructions into fewer cycles can be a huge win, especially on power constrained mobile devices. So yeah more bits is not always better.
I know this is probably beyond the scope of this video, but it makes me wonder if there's anything that justified calling the Dreamcast 128-bit? The funny thing is that the Dreamcast/PS2/GameCube era actually dropped the bit war. Maybe the 128-bit stuff was just used by journalists that didn't understand tech and just called it 128-bit because it was more powerful than the N64.
I don't use this phrase lightly but... "mind blown"! I loved my N64, but I had no idea that it was just marketing hype. Imagine if they'd spent that money instead on improving the memory or video cache.
Interesting, in the documented MIPS III instruction set there are actually no direct memory operations except copying from or to a register. And a good reminder how short those instruction sets where back in the day. Because transistors where so much bigger.
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.
*some children had no clue what the bits really meant There’s a lot of comments like this but I knew about colour depth at like 11, and CPU register sizes at 15. The biggest mystery to me for a few years is “wtf is the 64 if not colour?”. Also it’s not a flex, back in the day you had to set your colour depth of your output. If you set it low it looked bad, but if your system could handle it, turning it up made things look better. Learning why that was, was just a stone’s throw away at that point. I only point this out because you obviously purely see things through the lens of when you were a child from that era. You seem to forget there were people in the world building CPUs, setting up computers, and generally working with technology who are curious. You just didn’t have the good fortune of being around those people. All to say it wasn’t “just” marketing, but a factor for sure.
With custom asics the difference in cost only reflects the die size and process used. the changes you mentioned would have only very little on the production cost of the cpu , but it may have had a significant effect on R&D costs. We have come a long way and you can now design your own RISC-V cpu in an Asic with tinytapeout if your are crazy enough to do it.
Nintendo was kinda lucky the N64 worked out as a product. This could also have turned into the PS3 situation where developers are presented with hardware too powerful and complex for its own good. Sony's saving grace here was the tremendous success of the previous console generation. The CELL processor itself was ahead of its time and as such a disaster to develop for.
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,...
Are you saying that Nintendo could have called it the Nintendo 72? We would have had Super Mario 72 and Donkey Kong 72 instead?
Wow, can we use modern Gcc with a specific profile to fully use the N64 ISA?
9bit? Wth
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.
@Clownacy wrong , the 68000 is a 32 bit processor hands down.
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.
And the GameCube wasn't even a "128bit" console when it was just two 64 bit processors
64 bits. 32 bits.
@@alfombracitario Yeah, they're spitballing. GameCube is 32-bit.
@@alfombracitariobro didn't watch the video
Wait really why?
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.
very good comment! thank you for the input.
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.
Can you explain it to me like I'm 5?
Can I ask who are you? I assume someone who worked at SGI at the time based on your comment.
@@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.
So what I understand is that Kaze is creating the first Nintendo 32 game because it saves him frames.
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
vroom vroom
@@pleasedontwatchthese9593 it also helps wuth drawing programs for planning where you can often run oom with 32 bit especially using multithreading.
@@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.
@@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
Because higher bit means more better
In 1996 it literally did mean that
More powerful LITERALLY meant better games until the 128 bit generation
It's got ALL the graphics you could ever need!
*more betterer
@@minecrafter3448 Watch the video.
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).
This happens in software, too. Skyrim mannequins, for one.
"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.
@@Great-Documentaries But the peoples behind PilotWings64 were working on software that had to run on ꜱɢɪ workstation (commercial pilot training). Openɢl came from ꜱɢɪ.
@@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.
@@Great-Documentarieswho are you and where did you work? Your comment is just wrong.
Funny to think that after N64, all Nintendo consoles until the Switch were 32 bit.
Switch 64 would have been a nice name XD
Except the later gameboy models of color/light Kappa
@@SuperM789I think he meant home consoles, not handhelds.
@@SuperM789The What
@@SuperM789 not sure where you got that from the gb and gbc were both 8bit, gba and gba sp were 32 bit
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.
@@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.
@@keyboard_g Not my problem.
"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.
They would have literally done what Sony did with the Playstation and just use a R3000A + custom GPU from Toshiba/Nvidia/ATI/etc (there were a lot of options in the 90s for GPU), the N64 was poorly balanced budget-wise all around, and many of the novelty ideas that SGi pushed (unified memory, etc.) were extremely poorly done. It wasn't even sold cheap, and the N64 ended up as a bad financial decision for Nintendo, hardware wise. They simply took bad decisions and bleeded out market share until the Wii+DS for it.
However, bad hardware does actually make up the place for good games, ironically, as it forces creative solutions.
@@MsNyara The Wii wasn't even really successful. It was cheap compared to the other consoles. That's literally the only thing it had going for it.
Look at the number of units sold vs the number of games sold.
People bought one for their kids and one for grandma and grandpa to get them to move but it just sat there gathering dust.
Pretty much the only titles that sold were first party titles... Meaning again, it was nothing more than a Mario/Zelda machine.
It was an underpowered non-HD Mario machine and no serious gamer played it.
Kaze: The N64 was the first 64 bit console.
Atari Jaguar: Am I a joke to you?
Literally everyone: Yes.
🙄
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.
@ShadowXeldron The bitter and object processor are 64 bit on the atari jaguar.
haha that am i a joke thing is such a funny joke you could keep saying it it gets funnier every time haha
but we are talking about the first one that actually sold lol
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
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.
Yeah me too. When I was a kid. NOT until I was 36. Ha ha.
@@sirbill_greebi3811 1028 is not a power of 10
Did you take it apart and count the bits to verify?
Nintendo doesn't want you to know this but the NES secretly has 5,000 extra bits that go unu-
So "64 Bits" was more or less Nintendo's own variant of "Blast Processing".
Yes, except it's real unlike the Genesis propaganda 😂
@@Dark_Mario_Bros. I would say it was. The M68000 of the Genesis was superior to the W65816 of the SNES.
@@Dark_Mario_Bros.I think Blast Processing was real too. I'm pretty sure I saw videos/forum threads proving it.
@@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
@@FunnyParadox one was better for some type of games and the same applies to the other.
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
vr, the actual vr with a head mounted display? (ofcource im not talking about vr we have now)
@@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.
@@howilearned2stopworrying508 i saw some arcade vr maschines on the internet but i didn't know consumers were able to have vr tech at home
@@howilearned2stopworrying508 Virtual boy, while marketed wrong in the sense that it wasn't VR as we wanted. Was such a nice little machine. The fact that you had to be in a quiet area, the 32 Bit sound, (i think) and the whole experience on most the games are unlike anything that ever existed or will ever exist. Its underrated and a cool little device that is a bit of a cult classic now. Wario Land belongs in the top 50 best games ever made all things considered.
@@howilearned2stopworrying508 VR was gonna be the next big thing like 92-93.
It was even in movies like Lawnmower Man and whatnot.
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.
Why? WiiU having 64 bit would only have mattered if it had more than 4GB RAM to go along with it.
@@Ashitaka0815 It's not really about the bits. More about how it still used an architecture from 2001.
@@mrmimeisfunny Yes and no. Actually the PowerPC 750 it's based on is from 1997, so it's even older. But that doesn't really matter as the Wii U's 3-core iteration went a long way from that basic design with far more cache, cores, clock speed and additional features.
Another example: Intel went back after the Pentium 4 Netburst debacle and based their new core - architecture CPU's on their Notebook offerings, which themselves were based on the Pentium 3. So going back to an older design as a base can totally make sense, based on the given scenario.
Changing the architecture at this point wouldn't have changed much, as Nintendo had no ambitions to build a technical competitive console anyways so they would just have swapped it for another low power alternative with additional costs in development both hardware and software tools.
@@mrmimeisfunny so? modern windows and linux PC's use x86_64 which is just the 64-bit version of x86 which was originally 16-bit and dates back to 1978. as long as the speed keeps being upgraded to keep up with the times it doesn't matter how old the architecture is
0:05 screams in atari jaguar
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.
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.
@@keiyakinsThere are 24bit/192kHz files. :) I have no idea why. Audiophiles must be bats.
@@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
@@JoeStuffzAlt I would say there's not a single person who can tell the difference between 96 and 192kHz. XD
@@mirabilis One issue is that people aren't probably going to buy both the 96 KHz and the 192 KHz version.
nah the fact he casually had a convo with DAN SALVATO kills me
I swear ddlc is in EVERY CORNER OF THE INTERNET
I mean, the guy's on twitter and twitch. Heck, I've seen him in streamers streams I watch. Chill guy.
Dan was one of the top Melee Link players and was a Project M developer/pro player. He's a Nintendo nerd.
@achunkofbutter i also remember hearing about him in a video about super mario sunshine speedrunning.
i knew who he was before DDLC, thanks to his old wii hacking tutorials!
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
Wait till you look at the Dreamcast and PlayStation 2 where both were advertised as being 128 bits.
I wonder if there was ant benefit to that
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.
@@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.
@@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.
Please direct me to an ad that says that.
At least the commodore 64 wouldnever scam me
Ultimate Wizard was a fantastic game
At least with the bread bin and its successor we know they referred to the internal memory.
A good portion of the RAM was dedicated to loading basic, so yeah, it did scam you. XD
@@dacueba-games ye but it is banked so you can replace it if you don't need it!
@@dacueba-games assembly games could bank that out tho and use all 64kB of memory
Ah, so making it an N32 would've been more effective.
Or call it the Nintendo Ultra 3D
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.
50% less effective
Bingo
"I was in my mother's womb at the time." Thanks for making me feel old. :D
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.
Shut up. Lol
What's weird is that he develops for a retro console that was presumably in its prime when he was still a baby (if I understand correctly)? I mean, most of us have nostalgia for the stuff that was around in our _teens_ or something like that (give or take). But Kaze devotes his time to a game and system from the time when he was either _in the womb or an infant_ 😂
The MIPS processor was probably off the shelf and only came in 64-bit.
PlayStation 2 also used a MIPS processor
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.
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.
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.
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.
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.
@@Wuerfel21Genesis*
@@Wuerfel21 Most people, perhaps, but not Amiga people, who will point out that the 68000 is actually 32-bit under the hood.
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!
TMEM lives on the other chip.
Hindsight is 20/20, though I agree
Could've always had double the RAM, and double the price. RAM was the bottleneck in a lot of ways in those years.
@@davidmcgill1000 The PSX did fine with a similar amount of RAM, the problem was Nintendo/SGi going with an unified memory approach, which made coding memory use a real nightmare, as every operation bottlenecked the other, so you needed to over-optimize your code (aka see Kaze's work) to actually get to use your memory decently. Or also why N64's expansion pack (doubling total RAM) really just helped meaningfully toward the end.
The other mistake was the 9-bit bus, which would bottleneck every other single part of the whole hardware, specially with unified memory making use of the tiny bus even more frequent.
The 64 bit refers to the 64 bits of doritos you have to push in through the vents as good luck charms.
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
the jaguar was "64" for its 32 bit video chip + 32 bit sound chip
had a sixth sense.
The teenage boy was accused of breaking his arm simply to get out of the test.
What???????
Nintendo: 64 bits!
Consumers: Uh...
Sony: CD playback-
Consumers: Shut up and take my money!
It worked on me as a kid. :D
"64 is at least double the more of 32 so N64 better than Playstation hurdur"
Well guess whats more useful...
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)
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.
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.
so many languages in the world and this man chose to speak facts
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
i was thinking of 16 bit instructions for the general purpose registers.
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
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.
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.
Psyduck needs HUGS
@@Margen67 psyduck has a headache and is full of angst
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.
64 bit audio sample rate might as well be infinite
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.
IMG! Imagine the size of a 64 bit mp3!
Nintendo's biggest mistake was the naming of the Wii U
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.
Isn’t the RDP 2:54 RCP connection 32 Bit? And all the pointers ( Java: Reference) would be 64 Bit and stress RamBus.
@@ArneChristianRosenfeldt Vroom vroom.
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.
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.
@@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.
I think 90% of the consumers thought N64 was just a random name.
Everyone knows the 64 stood for the amount of milliseconds of frametime
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.
The light in his life was actually a fire burning all around him.
Almost no audio is 64bits. CDs are 16bit, as are MP3s and the audio from this UA-cam 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.
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.
mp3s aren't 16bit because they're lossy just like this video
@@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).
this reminds me of how sony used the cell for the ps3
"The PS3/cell can find the cure for cancer".
LMAO
The PS2’s Emotion Engine shares something in common with Cell: Both were difficult to program for.
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
That, “man, I wish there was an easier way to do this,” comment was gold.
Keep going buddy! You have a great career in front of you!
Gary didn't understand why Doug went upstairs to get one dollar bills when he invited him to go cow tipping.
I’m excited to see how making 3d games was a greater offense than the the virtual boy
I just clicked on this video and it wasn't till over halfway through I realized this was the king of SM64 hacks.
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.
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.
@@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.
@@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.
@@Great-Documentaries Going CD would've increased to BOM-costs, likely meaning they'd have to cut in other departments (like the PS1 did). In short, design is a matter of trade-offs.
@@sundhaug92 but the 16bit era already showed the potential of CDs, from the MegaCD to the PC Engine CD. Developers had so much more space to work on, and they were cheaper to produce.
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.
The first Xbox, a way waaay more powerful console, was 32 bit.
Depending on how you count, for example it can do vector-processing etc
The Xbox had the main advantage of possessing Direct3D. The only thing the xbox didn't have was HLSL (yet). Back then the shaders were written in assembly. The N64 didn't even have access to any type of shader!
@@lordkrythic6246 The Xbox was dramatically better in basically every way, it only came out 5 years later, but tech moved fast back in those days.
It had many times the clock rate, RAM and bus speed. The GPU in the Xbox was a 233Mhz Nvidia GPU with parallel shader units while the N64's 'GPU' was a modified CPU running at only 63Mhz. IMO it wasn't really Direct3D, but the parallelism in the GPU that makes the biggest different, aside from the huge increase in clock rate.
As a kid, I thought it "64-bit" was addressable space because of their amazing RAMBUS invention and they wanted to try and get more FLOPS out of that architecture.
Turns out, I wasn't too far off but I was still in the "factoid" territory. Anyone else "learn" the CPU-Address space + RAMBUS argument? I feel like that was a thing back then for the nerds.
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.
Just like the graphic wars are on its last legs nowadays.
"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.
@@Mrcake0103 FLOPS are also a dumb way to measure stuff as efficiency in how well they are used is way more important.
When talking about 64 bit CPUs, most people refer to the adress width (which requires 64 bit registers) and results in 64 bit address bus width. According to the internet, the n64 has a 32 bit address bus, which makes sense, because the n64 does not have even close the amount of ram to hit any limit with 32 bit addresses.
What about the theory, that the GPU of the N64 maybe used a 64-bit memory bus?
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.)
@@Sauraen Nice try, dude. XD
@@IncognitoActivado What?
@@Sauraen antialiasing data??
@@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.
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.
16 bit sound not only can sound great but it does sound great.
thank goodness I can get that extra 4 GB of RAM in my N64
4 MB :---)
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).
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.
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.
Just to let you know, 8bit, 16bit and 64bit had nothing to do with the color regarding consoles and had been something that people kept confusing since regarding computers it was regarding the colors. The bit for consoles was actually regarding the CPU, for example SNES and Turbo Graphix 16 had a 16 bit CPU. N64 had a 64bit CPU, NES and Sega had an 8bit CPU.
Yeah, that section is there because people kept talking about "X bit graphics". even now you can still see people make jokes about that
@@KazeN64 it was a common mistake that was made especially growing up as a kid in the 80s . I was playing Arcade games, consoles and computer games back then and even though the bit wasn't specified in consoles so much. With computers at the time it was specific with color. Even now if you were to do a fresh install of windows and not have the driver for the video card installed on a computer today. It would appear with 8bit or 16 bit color unless they changed it with windows 11. 256 color was a huge deal back in the 80s/90s and made a huge difference that stayed in place for so many years. Personally I feel the Turbo Graphix 16 was the most underrated console of it's time. Not only was it the first to utilize CDs when you attached the accessory to it but it's the only one in which the basic cartridge for it was also compatible with it's mobile console the Turbo Express.
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.
Nobody has encountered an explosive daisy and lived to tell the tale.
Sony is STILL advertising the PS2 as a 128-bit machine in Astro's Playroom -_-
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)
@@SimonBuchanNz I thought we never actually went past 64 bits. Modern PCs are 64 bits after all, or am I wrong?
@@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)
@@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.
@@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.
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.
Nintendo is not a microchip manufacturer, and there are a finite number of CPU architectures, all with different prices. It stands to reason that you won't always be able to get the exact CPU your game console needs to function optimally.
I was astounded studying for my CompTIA A+ and learning just how little a difference 32 and 64 bits make with a processor. Hell, there are PCs running today that are still on 32 bit CPUs [though Microsoft is dead-set on killing that off with Windows 11 requiring a 64 bit CPU, and not even releasing a 32 bit version of the OS]
It's the same basic principle of how video game graphics peaked in the mid 2010s and have plateaued since then- diminishing returns. 8 bits is a world more powerful than 4 bits, 16 bits is way better than 8, 32 bits is a sizable improvement over 16, and 64 bits is a step up from 32 bits.
Because processor bits increase exponentially, 64 is likely the highest we'll need to go for a damn good while, 128 bit CPUs MIGHT start to come around for home computers some time in the 2040s or so. But a strong processor is only a way to PROCESS the instructions sent by other components- a 2048 bit GPU would mean jack shit with 4GB of RAM, a GTX 1030 graphics card, and a spinning hard drive.
It's fun to notice that modern GPUs such as Nvidia RTX series only have 16 and 32 bit cores.
Nice video! We actually did a tournament of Nintendo’s biggest mistakes to determine the biggest one on our podcast
The yandev shade went hard
It's a shame they didn't call it the original name of "Nintendo Ultra 64" due to some copyright or trademark issue or another. Heck I found an etsy page that makes a decent "Nintendo Ultra 64" jewel modelled after the original Nintendo Power advertising for the console (minus the curved surface, unfortunately).
At least then the marketing would have been all about the "Ultra" part and not the "64" part. "Super Mario Ultra", "Kirby Ultra", and so on and so forth, just like all the "Super" names on the Super Nintendo/Famicom. Heck the massively loud "Ultra Combo!" from Killer Instinct was a not so subtle bit of marketing for that original name.
So it seems what I'm hearing is yes it's a 64 bit console, no that isn't a good thing, but they'd run a few things in that mode purely to prevent bugs from accidental use of 64 bit floats. Now, I can't say whether or not Atari and Nintendo added that mode PURELY for marketing (I'm not sure if Nintendo of Japan marketed their consoles purely on bits at all), but in terms of manufacturing, it may actually have been cheaper to design the chips that way rather than custom design a purely 32 bit SGI chip with it's own instructions. Manufacturing costs MAY have been the likely culprit of this design decision.
It's still funny to me that 64 bit processing didn't actually become something close to useful until PCs and later consoles actually started including more than 4GB of RAM.
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.
i love how the 64 bit marketing didn't hinder Sony's sales at all, and actually managing to sell THREE times more units than the N64 did (PS1 sold around 100 millions as opposed to the N64's 32 millions)
If marketing was the purpose then it should've been called Nintendo69.
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
Anything over a 19 inch tv was basically baller status for the 90s
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
He waited for the stop sign to turn to a go sign.
Because of this kind of marketing, I assumed the Gamecube has 128 Bits as a kid lol
"Super Mario 128"... LoL...
I'm sure somewhere out there someone is calling the Switch a 1024 bit console
@@TonyStarkCLC i mean that is what people often call that gamecube tech demo with all the marios
@@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
I don’t think this was a mistake, a lot of gamers like this console
It refers to address space. Pointers have a range of +/-512GB (half a TB The TLB only looks at the low 40 bits of the address for page table lookups.
This is still worthwhile even with a 32 bit physical data bus because you have a gigantic virtual address space, where you only have part of the data in memory at once, and use it to do things like mapping in entire DVD or something, with demand paging (if N64 had DVD that is, LOL).
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.
Finally a new Kaze video dropped
"16 bit audio can sound great, as you can tell from this example." No, I can't tell because you played it at 2% volume lmao
one small mistake: the usual thing for determining the bitrate of a CPU is the native integer size, not the register size. This is an absurdly pedantic difference to even bring up and is nearly never relevant, only being relevant when a CPU uses some weird design that uses a full native integer for instruction data and just adds more bits to the instruction word, and even then if you go back in the 90s your definition is exactly what would've been used. Basically it's pointless that I've commented this. I'm just padding your comment section. hiiiiiiiiii whoever reads this =]
lol
Funnily enough we now try and utilise 16-bit floating point values and packed math as much as we can in modern shader code where there isn't a noticeable precision tradeoff, as packing those instructions into fewer cycles can be a huge win, especially on power constrained mobile devices. So yeah more bits is not always better.
I know this is probably beyond the scope of this video, but it makes me wonder if there's anything that justified calling the Dreamcast 128-bit? The funny thing is that the Dreamcast/PS2/GameCube era actually dropped the bit war. Maybe the 128-bit stuff was just used by journalists that didn't understand tech and just called it 128-bit because it was more powerful than the N64.
I don't use this phrase lightly but... "mind blown"!
I loved my N64, but I had no idea that it was just marketing hype. Imagine if they'd spent that money instead on improving the memory or video cache.
Take a drink everytime he says "64 bits" 😂
Interesting, in the documented MIPS III instruction set there are actually no direct memory operations except copying from or to a register.
And a good reminder how short those instruction sets where back in the day. Because transistors where so much bigger.
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.
*some children had no clue what the bits really meant
There’s a lot of comments like this but I knew about colour depth at like 11, and CPU register sizes at 15. The biggest mystery to me for a few years is “wtf is the 64 if not colour?”.
Also it’s not a flex, back in the day you had to set your colour depth of your output. If you set it low it looked bad, but if your system could handle it, turning it up made things look better. Learning why that was, was just a stone’s throw away at that point.
I only point this out because you obviously purely see things through the lens of when you were a child from that era. You seem to forget there were people in the world building CPUs, setting up computers, and generally working with technology who are curious. You just didn’t have the good fortune of being around those people.
All to say it wasn’t “just” marketing, but a factor for sure.
I'm not in this world to live up to your expectations and you're not in this world to live up to mine.
I'm always amazed by your big brain
11:50 so they should have made the Nintendo 48 instead
With custom asics the difference in cost only reflects the die size and process used. the changes you mentioned would have only very little on the production cost of the cpu , but it may have had a significant effect on R&D costs. We have come a long way and you can now design your own RISC-V cpu in an Asic with tinytapeout if your are crazy enough to do it.
64 was a commercial marketing term to say it was 3D and next gen by labeling it 64 (because of 32 architecture in that time making it look next gen)
3d physics is way complex. So to store all the numbers and calculations they wanted 64bit. 32bit would have been fine.
Nintendo was kinda lucky the N64 worked out as a product. This could also have turned into the PS3 situation where developers are presented with hardware too powerful and complex for its own good. Sony's saving grace here was the tremendous success of the previous console generation. The CELL processor itself was ahead of its time and as such a disaster to develop for.
Your voice is very soothing.