We sometimes discuss the merit or technicalities of putting two CPUs into a system, with shared memory or otherwise.

Today I learned that Nintendo made such a system, whereby some 33 game cartridges have their own '816-based chip, but clocked 4x the speed of the main one in the console. Both CPUs can send IRQs to the other. The fast one powers up into an idle state.

The faster chip has 2k of full-speed private RAM and a large half-speed (two cycle) RAM and ROM too.

I'm not sure how memory is shared, or how the two CPUs communicate.

The faster chip has extra computation competence too, including multiply, divide, multiply-accumulate as well as other acceleration hardware.

For more, perhaps see
https://sneslab.net/wiki/SA-1


There's a note in there about a 16 bit data bus too, somehow affording faster ROM access.

Yes, 16-bit buses generally transfer data faster than 8-bit buses at the same speed, for some reason. :-P

The exact wording is, "Large capacity memory, with a total capability of 8 MB ROM and 256 kB BW-RAM, both clocked at 5.37 MHz, with ROM having an effective 10.74 MHz speed because of the 16-bit data bus." So pretty clearly they're just saying that with their 16-bit wide data path to ROM, you can pull data out of it twice as fast as if it were only an 8-bit path.

The standard 65816 can't do this, of course, because it has only an 8-bit external data bus IIRC, but presumably since this is a custom ASIC they were able to extend the external data bus to 16 bits.

As far as the rest, I was curious about how the two CPUs interfaced with each other, but there doesn't seem to be much on that page beyond a list of hardware registers. I guess it's going to wait for someone who has one of these carts, a logic analyser, and a bit of spare time.

_________________
Curt J. Sampson - github.com/0cjs

Right, but a 16 bit bus only speeds up consecutive aligned pairs of bytes - that's not a uniform speedup. Who knows, their memory controller might be quite smart, might even keep data that might be needed - even a 2 byte cache could be a win.

Agreed, we don't quite see enough. Although, I think if I knew more about the SNES, there might be information that helps, already in the page. The basic point of a cartridge is to provide ROM that the main (slow) CPU can read, mapped into its memory space one way or another. It would be natural to do the same, and to include the (large, slower, non-private) RAM in the mix. That would then be a chunk of shared RAM accessible to both CPUs.

well if the ROM mostly contains code, something the CPU does access in a linear sequence (most of the time), then it should be an almost 2x speedup in instruction fetching. of course just speeding up fetching doesn't make the rest of the execution process faster, but it should still make a noticeable difference since cycle times on the 65xx CPUs are already so low.

there is a tiny bit more information on this github page, specifically about the memory map: https://github.com/VitorVilela7/SNES-SA-1-doc/

Thanks for the link, that's very helpful!

So the SA-1 chip which holds the CPU and the private RAM has full independent busses connecting to the console bus (aka cartridge port), the large RAM, and the wide ROM. And, I think, it sees the console clock, so it can PLL the faster clocks to make everything synchronous.

If we count in units of the fast CPU clock, we get
- one in four clocks could be a console access, to cartridge-side RAM, ROM or peripherals onboard the SA-1
- it could be that such accesses would only block the fast CPU if it was also accessing the same device in that cycle
- when the fast CPU reads the ROM, it takes two ticks to get the first byte, and presumably a sequential access to the next byte, which would need to be on an odd address, would then take only one tick because it hits the on-chip read buffer.

So, I think, for simple hardware, the best speedup for ROM access is two accesses in three ticks, the worst is one access in two ticks. It's faster than a half-speed 8-bit ROM but not as fast as a full speed 8-bit ROM.

The worst slowdown for contention between the CPUs, I think, is the fast CPU losing one access in four. I'd assume the console side, the slow CPU, always gets priority. (Even if the console side has other units doing DMA, which it probably does, the contended accesses are still only one in four as the console runs at 1/4 the clock.)

If anyone has general interest in the SNES, I can recommend the Retro Game Mechanics Explained channel on youtube https://www.youtube.com/@RGMechEx

On retro games, it covers things like how Atari's vector graphics works, how Pac Man ghost AI works.
On SNES, it covers how its graphics and sound systems work. How memory is mapped.

It also has a whole series on Super Mario Bros 3, which is just fascinating.

The videos are all very well animated and the author walks though highly technical and detailed topics extremely well.

The hardware focused videos to right down to the registers and the pipelines. The software focused videos go into superb levels of detail. All done with technical animations and diagrams.

Not covered in the video series is the CPU itself, and if I recall correctly, that's because the CPU isn't a mystery to be unraveled, unlike these other topics.

(Interesting - I hadn't realised the sound system is based on something rather like a 6502. Or if I had, then I'd forgotten.)

Sure would be fun to play with one.

SNES emulators fully support the SA-1, so you should be able to find documentation out there.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

I know this is months old but if anyone is curious details are in book 2.

https://archive.org/details/SNESDevManual/book1/

Welcome - and thanks for the link! Diagrams too:
https://archive.org/details/SNESDevManu ... 9/mode/2up