FAQ
This page tries to provide a detailed answer to frequently asked questions on Nintendo 64. Some of these have spawned myths over the years in online communities, so this page hopefully answers properly and debunks some of them.
What is the maximum cartridge size (ROM) supported by a Nintendo 64?
Short answer: 4 GiB, without bank switchers. Unlimited otherwise.
Most people seem to believe that Nintendo 64 is somehow limited to cartridge of 64 MiB. The origin of this belief is likely the fact that 64 MiB is the maximum size used by retail games (such as Conker: Bad Fur Day). In fact, there is no such a hardware limit. The cartridge is accessed via the PI bus, a serial bus that allows for full 32-bit addresses, accessible via DMA: so a hardware cartridge can reply with data to any address in the 32-bit range, that is a total of 4 GiB. ROMs must have a valid header at address 1000'0000
, but besides that, there is absolutely no constraint: a cartridge could also reply with data in the range 0000'0000
- 0FFF'FFFF
, as long as the application itself knows about it and retrieves it when necessary.
Others seem to believe the maximum size is 252 MiB. That belief comes from the fact that some of the address space of the PI bus is also memory-mapped to the VR4300 (and that includes normally the whole ROM too), and in fact 252 MiB of it is memory mapped in the physical range 0x10000000-0x1FBFFFFF
but that is not a limit or a constraint in any way. There is no technical constraints preventing a cartridge to expose a larger area to the PI bus (up to 4 GiB). It is true that this full 32-bit address space is accessible only via DMA, but that is actually the main (and almost only) way a ROM is normally accessed: direct I/O accesses via CPUs in memory mapped areas are rather slow, cannot be cached, and only work correctly with 32-bit access size. So in practice they are rarely used.
At the hardware level, the presence of a serial bus means that it is possible to split ROM contents across a different array of chips if required; as long as the PI bus decoding logic knows how to map each address to the correct chip, it will be fine.
Homebrew developers should anyway carefully consider going past 64 MiB with their ROMs. In fact, most emulators do not support ROMs beyond that limit (even though the modification is expected to be quick once they are made aware that it is not a hardware limit), and flashcarts commonly used to play home-brew productions on hardware (such as EverDrive 64 or SummerCart 64) only have about 64 MiB of SDRAM to keep ROM contents, so they do not support larger ROMs as well.
Would it be possible to create a larger RAM expansion for N64, to go beyond the total 8 MiB we can get today with the Expansion Pak?
Short answer: Currently, it is thought to be impossible because of a physical hardware limit of the RDRAM controller (RI) within the RCP chip.
The RDRAM chips are connected to the RCP via a bus called RAMBUS. This bus allows to connect multiple chips to a controller; the controller can then talk to each chip and configure it to reply to a certain range of addresses (that is, "map it" into a memory map).
The RDRAM initialization is performed by IPL3, a piece of the Nintendo 64 secure boot code (there are a few variants to its contents but the differences are not related to RAM management). IPL3 does the RDRAM chip initialization using a process called "current calibration", and then map them into the (phyisical) address space, by giving to each chip its own address. Nintendo's IPL3 can correctly handle up to 4 2-MiB chips (it also has buggy support for 1 MiB chips, which probably were never released by Rambus, so the code was never tested).
For a long time, it was then believed that changing IPL3 would be enough to allow more chips to be mapped, assuming somebody built an expansion pak card with more chips in it. Instead, late work on Libdragon's open source IPL3 led to more reverse engineering of the RI chip, which eventually proven that RI internally runs a state machine that tracks RDRAM bank status, and only has enough room for 8 1-MiB banks (each 2-MiB chip is logically made of 2 1-MiB bank). More details can be found in the RDRAM Interface#Bank Status Tracking wiki section.
On top of this, Rasky (who authored Libdragon's IPL3) also got the chance to test a custom made expansion pak with 8 MiB of RAM in it, designed by LambBrainz. This pak uses donor chips from official expansion paks, and is correctly recognized by Nintendo IPL3, though just as a 4 MiB pak. Anyway, by hacking Libdragon's open source IPL3, it can be seen that the extra banks were indeed present on the bus, but it turned out to be inaccessible after bus mapping. This is a further proof that RI is not actually able to handle more than 8 MiB of RAM.
Is it true that the RSP has hardware MPEG-1 acceleration? Is it used by full motion videos in Resident Evil 2?
Short answer: RSP has two couples of opcodes (VMULQ
/VMACQ
and VRNDN
/VRNDP
) that are meant to simplify implementation of a very small part of the MPEG-1 decoder (inverse quantization and oddification of IDCT coefficients). They are not used by Resident Evil 2 or any other commercial game though.
RSP is the vector coprocessor in Nintendo 64. It is well designed to also accelerate video codecs such as those of the MPEG family. To do so, though, careful assembly code must be written using the specific RSP vector opcodes to perform the various operations required for a video decoder. When RSP was designed by SGI (in the early 90s), only MPEG1 existed as a finished standard (MPEG2 was finalized in 1994, after the RSP design was frozen), so SGI designers decided to add a couple of opcodes to the instruction set to help implementing a part of the MPEG1 decoder: specifically, the algorithm that performs inverse quantization and oddificaton of IDCT coefficients. This is actually a quite specific part of the whole pipeline, and it is not even the most resource intensive one. It is hard to guess why the SGI designers thought it was important to specifically add these instructions or speed up this specific part of the pipeline.
Resident Evil 2, which is a marvelous example of careful code crafting, did manage to cram full motion videos together with the whole game in the limited 64 MiB cartridge. To do so, they encoded them with MPEG1 at a low resolution, bitrate and frame rate (around 15 fps), and then performed a nice interpolation (cross-fade) between frames using RDP. The MPEG decoder was not specifically accelerated though (if not for the final YUV to RGB conversion, which is technically not even part of MPEG): they simply recompiled a C player that worked good enough at that bitrate, so they did not get to use the special RSP instructions for it.
In modern times, libdragon provides a fully accelerated MPEG decoder that uses RSP and also uses the special RSP instructions. This can also be used as further proof that the instructions SGI designed were indeed useful for their goal, albeit for a very small part of the whole algorithm.