41–50 of 77 posts
One of my favourite little easter eggs in Goldeneye is that during the Silo mission, two of the satellite components you have to steal are the N64's RSP and RDP: https://twitter.com/007goldeneye25/status/109829415491907174...
The rabbit you need to catch beneath the castle in Super Mario 64 is named "MIPS". :)
Earlier quoted context omitted.
If I recall correctly, later games actually packed higher throughout ram into the cartridges to work around the latency of the onboard ram.
They used uncompressed textures on the cart, in ROM. (not on-cart RAM) Normally a game would store compressed textures in ROM, and decompress them into RAM. It was a solution with significant tradeoffs though. #1 It was still slower than the cache. #2 You were still using the single shared bus. You would still be using cycles which contribute to data stalls elsewhere in the system. #3 ROM was expensive. N64 games wer…
Additionally, the TMEM could only be loaded from RDRAM, not directly from the cartridge. I think the RDP's DMA master is only connected to the RDRAM slave port and not the main system's bus matrix.
So going back to it, games would a lot of the time store compressed data with a simple algorithm that could run out of the CPU's cache. Then the scheme looks like
* Cart->RDRAM DMA of compressed texture
* CPU decompresses texture into another RDRAM bank, and can be considered a RDRAM->RDRAM transfer. Sometimes the RSP handles this instead. I'm not sure if you could load straight out of RSP DMEM to avoid another bounce to RDRAM. I don't think XBUS works that way, but I could be wrong.
* RDRAM->TMEM DMA of uncompressed texture
Interestingly, games with more advanced texturing schemes like Indiana Jones tended to use uncompressed textures. They did this to avoid the decompression step and it's bandwidth. At that point it's just staging the texture with that cart's DMA, and slurping that into TMEM without any other processors eating bandwidth in between.
Earlier quoted context omitted.
Well, I would guess twice as much and four times as much respectively. I mean RAM is cheap today but if you wanted 128GB of it today it’d still run you like, $700. I can’t pretend to know what this particular type of RAM cost back in the day, but given how relatively cutting edge the machine was I can only guess it was not particularly inexpensive...
They should have released a Nintendo 64 Plus sometime before the release of the Gamecube that would have doubled its RAM to provide hi-res textures.
Earlier quoted context omitted.
> Hardware used to be so exotic! It might circle back around to being exotic again, if FPGAs take off and more work is done on highly-specialized task-specific hardware, as opposed to building the fastest general-purpose chips you can and beating problems to death with sheer speed.
Is this a thing that's happening? I remember how cool I thought FPGAs were from my college CE classes. Seems intuitive to me that you would want to specialize the hardware once you have a process figured out. The fact that FPGAs are upgradable makes it even more of a no brainer to me.
Earlier quoted context omitted.
They should have released a Nintendo 64 Plus sometime before the release of the Gamecube that would have doubled its RAM to provide hi-res textures.
That... doesn't work. The games which were released for the N64 were all designed to run within the limits of the hardware. Adding more memory later wouldn't give existing games higher resolution textures. Plus, adding more texture memory would have meant respinning the RCP silicon. That would have been a significant expense for marginal returns. Besides, Nintendo had already sold a memory upgrade in the form of the…
Earlier quoted context omitted.
Is this a thing that's happening? I remember how cool I thought FPGAs were from my college CE classes. Seems intuitive to me that you would want to specialize the hardware once you have a process figured out. The fact that FPGAs are upgradable makes it even more of a no brainer to me.
Well there's a cost benefit; Cheaper FPGAs may not necessarily be as performant as others for some tasks, there's still a gate budget to deal with, and I personally am not sure whether the FPGA world is one where you have full control over what you do with the chip when you sell it in a commercial product. I know Gigabyte back in the mid 2000s made a PCIE Card that let you use DDR as a disk drive once upon a time; fo…
The FPGA also can have a massive unique key that allows the designer to create a whitelist algorithm that only lets certain unique IDs run that firmware. Other options involve setting a time limit for how long the firmware will run, disabling certain features, or totally bricking that FPGA forever. Spartans have this feature but it would still allow for someone to build a new design that doesn't check the device ID.
Additionally, the bitstream can be encrypted so that if a field update is necessary or the firmware is stored in a stored in a separate flash chip, someone can't reverse engineer it.
Overall, the more you pay, the more security features there are available. An example secure design would disable JTAG pins permanently and have a microprocessor inside that would handle new updates. The processor would authenticate any new encrypted firmware before programming the internal flash.
I get the nostalgia angle -- but why are we discussing a console that's >20 years old?
Earlier quoted context omitted.
> Hardware used to be so exotic! It might circle back around to being exotic again, if FPGAs take off and more work is done on highly-specialized task-specific hardware, as opposed to building the fastest general-purpose chips you can and beating problems to death with sheer speed.
Is this a thing that's happening? I remember how cool I thought FPGAs were from my college CE classes. Seems intuitive to me that you would want to specialize the hardware once you have a process figured out. The fact that FPGAs are upgradable makes it even more of a no brainer to me.
Earlier quoted context omitted.
they technically did. the https://en.wikipedia.org/wiki/Nintendo_64_accessories#Expans... raised main memory from 4mb to 8mb. it was required for one of the Zelda games, but also helped with graphics for some games if it was inserted. seemed to be a decent success.
DK64 required the expansion pak due to a bug (it was intended to work in either 4MB or 8MB modes and they couldn't fix a crashing bug in the 4MB version) and then Rare spent an obscene amount of money shipping an expansion pak with every copy of the game. That was probably responsible for a large fraction of the units shipped, with most of the rest accounted for by Zelda (which did not include the pak even though it…
https://www.reddit.com/r/n64/comments/ft63zn/dk64_memory_lea...
The lead artist claims they’d always been planning to make use of it. There’s compelling evidence of a memory leak or similar issue since the released version of the game apparently crashes if you leave it running for some amount of time over 10 hours (which wasn’t usually a problem in practice except for very long speedruns until it was released on Wii U Virtual Console and people started using save states which don’t reset the timer the same way as turning the game off and on does).
I get the nostalgia angle -- but why are we discussing a console that's >20 years old?