Because of how cartridge systems work, you can put an arbitrarily powerful computer into a Famicom cartridge, limited only by current limits. We saw this in the later days of the SFC, as the SA-1 chip, plus the lesser helper chips like the DSPs. For sound, CD-quality sound is possible in both, if you have arbitrary memory and computing power on the cartridge, except that FC would only be mono. This wouldn't work on the NES, though. Also, the cartridge port on both the FC and SFC talks to the system GPU directly. In the Famicom, the cartridge is attached to the GPU's bus. The GPU sends requests to read tile bitmaps and the tile layout to this bus, and the cartridge can respond. Because the GPU doesn't cache very much, it requests from the bus again whenever it uses a particular byte. The MMC5 took advantage of this to allow changing palettes on an 8x8 area rather than a 16x16 area - the MMC5 would answer with a different value when the GPU later read the same attribute byte a second time for the second 8x8 area, and the GPU was none the wiser. On the Super Famicom, my knowledge isn't as good. My possibly-wrong understanding is that the extra cartridge pins used by some cartridges allows cartridge hardware to access VRAM. If that's correct, then that means that Star Fox worked by having the Super FX render 3D onto VRAM tile bitmaps. Similarly, I believe that the C4 allowed Rockman X2 and X3 to have more sprites this way (and not just the few polygon bosses). I don't count things that make you pass through extra wires like the Mega Drive's 32X - only devices that could run from the cartridge port alone. If techniques like these are combined, what are the ultimate capabilities of the Famicom and Super Famicom? What graphics potential would there be?
According to unsourced Wikipedia: "[Super FX] was typically programmed to act like a graphics accelerator chip that would draw polygons to a frame buffer in the RAM that sat adjacent to it. For those games, the data in this frame buffer were periodically transferred to the main video memory inside of the console using DMA in order to show up on the television display." The question is, can this be done more often than ~30fps we usually see in SuperFX games? Question is - does this framerate max out some bandwidth, or is it only a limitation in the speed of the SuperFX? If not bandwidth: the sky is the limit, I suppose. Arbitrary hardware could render anything and pass it in just like the SuperFX does. The only limit would be how high resolution the SNES can output. The CPU could just pass on all inputs to the cart and better hardware on the cart could take care of actually rendering the game and we could have a (sub-SD) PS3/360 running on top of the machine... (<--- it looks like someone needs to start a new project! )
It's unsourced because I wrote it. I was referring to the leaked SNES development manual and some reverse engineering I was doing at the time on Starfox's rendering engine. HA! When's the last time you played a SFX game? They tend to get more like 10-15 FPS at best. Little bit of column A, little of column B. You are hinting at the two fundamental issues: bandwidth limits and overall system architecture. The SFX (for example) does not have access to any of the SNES's IO. If you wanted to do most or all of your processing on an external chip, the main CPU would have to constantly act as a mediator between the SNES hardware and that chip. It's not impossible to get decent performance this way, but the architecture was not designed with this in mind. You ARE limited to 256x256 pixels. This is both a bandwidth and arch limit (DMA and SNES frame buffer sizes are fixed). You'll never get 360-quality graphics, but you can do a damn spot better than a wimpy 20 MHz RISC core. In short: you could put a much more powerful CPU on the cart and do some very neat stuff with it. It would be an interesting exercise, but in the end I think it's more valuable as a thought experiment.
The Super Game Boy is a 60 Hz example of such a system, but it uses 4-color palette tile mode, and doesn't cover the whole screen. It may avoid DMA bandwidth limits this way. Having a legacy system to which you attach a massively more powerful coprocessor, and needing the legacy hardware to mediate I/O device access for you is a PS2. =)
For the Super Famicom, reference the MSU-1 and FMV capability. This basically could be used with a fast enough CPU to just feed the SNES video information and directly feed audio through the cartridge port. Examples: http://www.youtube.com/watch?v=THJvsIezXrQ http://www.youtube.com/watch?v=YMfeowmxsQ4 http://byuu.org/21fx/ - Details some of the SNES's capability. If someone was crazy enough you could play lower resolution 3D games on the SNES, maybe Devil May Cry from the PS2 could work in some fashion if someone had access to everything needed. The NES could possibly do more with a powerful coprocessor. You could totally offload audio, adding a more powerful sound chip. You could have a second CPU basically do everything and prepare PPU updates and register interaction and communication with the NES CPU. But then you're not really playing a NES game are you?
I think that the SNES can almost entirely offload audio if properly designed. An NES has more direct interaction with the graphics unit from the cartridge, but the graphics unit has far fewer capabilities compared to the SNES. In the best case, it can only display 25 colors from the built-in 53 on a single scanline. 13 of those are background colors, and 12 of them are for sprites. Each 8-pixel tile can only use the 4 colors out of 13; 3 are selected per-palette and the 4th is shared among all 4 palettes. For sprites, only 8 8-pixel parts of a scanline can be covered. Also, I don't know whether it's even possible to change sprites' locations between scanlines - they may be fixed for the entire screen once vblank ends. One way to improve bandwidth and interactivity is to have the coprocessor generate 6502/65816 assembly code at runtime and "stream" it to the CPU. Such a trick would probably be downright necessary on something like an Atari 2600, but maybe not for NES/SNES. The debate of whether you'd be playing an NES/SNES game at all is an interesting one. However, it's equivalent to asking the question, are Star Fox 1 and 2 really SNES games?
The subject of this thread is quite interesting. I could compare what's being discussed here to that of some one putting a big block Chevrolet engine in a Honda Civic. (I've seen it done.) In the end the real question is this: Is it REALLY worth all the effort and cost to do this? For some people maybe. I say leave well enough alone and move to a newer console for the experimentation. Maybe a N64 would be able to do just as much or more since it is a native 64 bit setup. Windows 7 on N64 anyone?
But the NES/SNES and other cart consoles were BUILT to allow extensions like this, without modifying the actual hardware (unlike that Civic->Chevvy conversion)
With 8MB of RAM I don't think you meet minimum specs ;*) The N64 wasn't really designed to be extended in this way. You could use some similiar tricks, ie. pumping pre-rendered stuff directly into memory, but that's about it.
It was meant to be a sappy joke anyhow. I was making it based off the fact the SNES can be extended with extremely powerful plugin carts for extra functionality. The joke was based on having a Mini ITX or something like that system connected through the console for the UI. Just a poor joke... However, that would b neat to see if it were possible...
