Some of the later NES/Famicom games contained not just ROM, but coprocessors for better sound and graphics than the original console hardware could provide, such as the MMC5: https://wiki.nesdev.com/w/index.php/MMC5

Did the console itself, the cartridge slot, do anything special to support these coprocessors, was it farsighted planning in the original design? Or is the ability to add such coprocessors later, an automatic consequence of the ability to address ROM? Looking at the pinout https://forums.nesdev.com/viewtopic.php?f=9&t=14924 the most suggestive thing I can see is IRQ; it does not seem that should be necessary just for ROM cartridges?

(I get the impression that by the time the SNES was designed, they were explicitly thinking about later coprocessor support, but I would not have expected such thinking at the time of design of the original Famicom, which is why I am curious.)

  • 7
    In my terminology, a "real" coprocessor can take over the bus and stop the main CPU - This does not seem to be possible, as the CPU RDY signal doesn't seem to be exposed on the cartridge slot - Apparently, the coprocessors can only work as intelligent I/O processors – tofro Sep 12 '18 at 20:51
  • 1
    Re: the SNES, didn't they move the DSP-1 off the main board only at a relatively late stage, after Pilotwings was already mostly finished? I don't have a concrete source for that. But it would more than support the idea that coprocessor support was being explicitly factored into the SNES design. – Tommy Sep 13 '18 at 0:34
  • 1
    You might be interested in watching youtube.com/watch?v=ar9WRwCiSr0 where a guy basically does that by observing the bus and really in the end uses the NES just as an i/o system and everything runs on the cartridge. – PlasmaHH Sep 13 '18 at 8:19
  • 1
    I think the catch is that the DSP-1 had a fixed internal program that couldn't be changed so they'd have been stuck with the functions they implemented for the lifetime of the system. I'd guess if it was originally part of the design they'd have picked a different DSP where the program and data could be freely modified based on the application. At least putting the DSP in the cart didn't seem to make the games particularly more expensive! – raisin-wrangler Sep 13 '18 at 18:31

You're correct about it being a consequence of cartridges being able to observe the PPU memory bus. The advanced video features of the MMC5 and other mappers might have been trivial to add if Nintendo provided more signals to expose the internal state of the PPU to the cartridge, but they didn't, so these chips function by carefully monitoring PPU memory accesses to infer what it is doing as there isn't a more direct line of communication.

It takes a lot of logic to do that which is why the advanced features didn't show up in earlier cartridges made with discrete TTL parts (outside of bankswitching which is trivial) until they could justify the cost of adding semi-custom parts (gate arrays) to implement the PPU bus monitoring.

Nintendo did have foresight to push the cost of graphics memory into the cartridges knowing memory gets cheaper over time, which allowed for interesting design choices like using RAM and large ROMs. But the special functions of the MMC2, MMC5, and scanline counting across various mappers were a consequence of the design rather than something intentional.

For audio it's a different matter, the Famicom had a dedicated audio input pin so they always intended for that kind of feature expansion.

The SNES has a high speed channel for moving data from external memory into video RAM which was what made things like the SuperFX and SA-1 possible. I don't think they envisioned those exact uses but understood that having a way to shuttle in data quickly would be beneficial which it turned out to be. It's rather unfortunate their CD-ROM peripheral never took off because slow access to video memory is what hampered streaming video on the Genesis and TurboGrafx CD systems.

| improve this answer | |

Yes and no. Since the cartridge slot contained a complete basic CPU bus (Address + Data + Clock + R/W), any memory mappable coprocessor can be implemented. No specific coprocessor handling lines are present - and the CPU wouldn't support such anyway.

(And the SNES was only specific in having designated lines to handle a game specific security chip - besides that it was again rather plain CPU/Memory design).

| improve this answer | |
  • 1
    What about IRQ? What is that for, if not a specific coprocessor handling line? – rwallace Sep 12 '18 at 17:46
  • 5
    IRQ is a general way to handle interrupts - and they are general purpose. Handling a coprocessor may involve interupts - much the same way as a parallel interface or a push button. Having one (or more) interrupts is a definite plus for an interface, but neither special for coprocessors nor required. – Raffzahn Sep 12 '18 at 18:07

Actually, there are features that allow cartridge coprocessor to alter completely screen of the NES.

The picture data is constantly read from the cartridge during the display: specifically, the tile data is read. So by replacing tile data seen by the PPU in NES in a clever way, one can display arbitrary pictures with less limitations.

In the Famicom, the sound is also passed through the cartridge, so here arises the possibility to alter or even completely replace it inside the cartridge.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.