nesdev.com
http://forums.nesdev.com/

N64 maskrom logic
http://forums.nesdev.com/viewtopic.php?f=23&t=15942
Page 1 of 1

Author:  pipes [ Sun May 14, 2017 5:18 pm ]
Post subject:  N64 maskrom logic

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.

Author:  tepples [ Sun May 14, 2017 5:28 pm ]
Post subject:  Re: N64 maskrom logic

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

Author:  lidnariq [ Sun May 14, 2017 5:36 pm ]
Post subject:  Re: N64 maskrom logic

tepples wrote:
and "read 16-bit word and advance to next"
and "write 16-bit word and advance to next"

Author:  pipes [ Sun May 14, 2017 7:43 pm ]
Post subject:  Re: N64 maskrom logic

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?

Author:  lidnariq [ Sun May 14, 2017 7:54 pm ]
Post subject:  Re: N64 maskrom logic

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

Author:  tepples [ Mon May 15, 2017 6:08 am ]
Post subject:  Re: N64 maskrom logic

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.

Author:  lidnariq [ Mon May 15, 2017 9:53 am ]
Post subject:  Re: N64 maskrom logic

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

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/