N64 maskrom logic

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
pipes
Posts: 8
Joined: Sun May 11, 2014 2:23 am

N64 maskrom logic

Post by pipes »

Supposedly Nintendo 64 maskroms have some propitiatory logic to multiplex the address and data and was wondering if there is any info online that goes over that.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: N64 maskrom logic

Post by tepples »

The cart has "seek high", "seek low", and "read 16-bit word and advance to next". Like the DS and unlike the GBA, the N64 treats ROM as an SSD, not execute-in-place.

Previous topic: N64 Cartridge Bus
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: N64 maskrom logic

Post by lidnariq »

tepples wrote:and "read 16-bit word and advance to next"
and "write 16-bit word and advance to next"
pipes
Posts: 8
Joined: Sun May 11, 2014 2:23 am

Re: N64 maskrom logic

Post by pipes »

tepples wrote:The cart has "seek high", "seek low", and "read 16-bit word and advance to next". Like the DS and unlike the GBA, the N64 treats ROM as an SSD, not execute-in-place.

Previous topic: N64 Cartridge Bus
My bad. I didn't know that thread was so young. I did see the thread though via google search and was hoping for more info honestly. I have questions like once you count up to your data how do you go back? Do you give an address to wrap around or is there like a reset?
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: N64 maskrom logic

Post by lidnariq »

The N64's RCP is entirely in control of every bus activity the CPU does. CPU wants to write to video memory? Through the RCP. Wants to read the cartridge? RCP. Wants to read the joystick or save memory? RCP and usually also the PIF. CPU wants to read from main memory? Through the RCP.

The only thing the CPU can do without the RCP helping it is execute and read code from its own cache.

So when the CPU tries to read a 32-bit value from from address 0x1000_0020 as part of the boot ROM ("IPL"), the RCP drives the multiplexed bus as:
* Sets the upper 16 bits of address
* Sets the lower 16 bits of address
* Reads 16 bits
* Reads 16 bits.

The IPL doesn't use the RCP's DMA controller, and instead just reads a series of 32-bit values, so the above 4-long pattern repeats as the N64 validates the signature of the cartridge's boot "sector". After the signature cross-checks correctly, the code in the boot sector runs, and that uses the DMA controller to perform 256 reads at a time.

Unlike older consoles, where there's a continuous mapping of [address in] to [data out], instead with the N64 it's instead [specify start address] and then [transfer N 16-bit words].
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: N64 maskrom logic

Post by tepples »

lidnariq wrote:The N64's RCP is entirely in control of every bus activity the CPU does. CPU wants to write to video memory? Through the RCP. Wants to read the cartridge? RCP. Wants to read the joystick or save memory? RCP and usually also the PIF. CPU wants to read from main memory? Through the RCP.
Isn't that exactly the same as every computer that has integrated graphics on the northbridge? If I recall correctly, the Xbox 360 is the same way.
lidnariq
Posts: 11430
Joined: Sun Apr 13, 2008 11:12 am

Re: N64 maskrom logic

Post by lidnariq »

Sure, but the N64 is the first console that looks like a modern PC with integrated graphics.

Also, I'm not entirely certain where on the spectrum of "just a bus arbiter" to "something much weirder and much less responsive" the RCP actually sits. I'd naively expect the people who experimented with changing the N64 CPU multiplier would have gotten any improvement at all by changing the multiplier up from 1.5, but they basically didn't. I suppose the obvious reply is that Nintendo/SGI already chose the fastest multiplier for which there was going to be any performance improvement...
Post Reply