Hardware limits on simultaneous special chip use?

[93143]

It occurs to me that certain types of games that would use a Super FX (or SA-1, but I'm mostly thinking Super FX) might also benefit from having a DSP-1 available.

The mature version of the Super FX memory map allows CPU-exclusive ROM in the top half of the map, and the MMIO/reserved area up there has a Game Pak RAM mirror that seems a little superfluous (accessing it during GSU operation is possible but not usual IIUC) and encompasses the DSP-1 area from Mode 21. I have no very solid understanding of mapper design, but it doesn't seem like it would be all that hard to map a DSP-1 to $6000-$7FFF in banks $80-$8F (or $80-$BF if you must) while leaving $00-$3F and maybe $90-$BF as GPRAM. The map for the SA-1 is much busier, but there still seems to be a gap that could be exploited (and there are definitely similar gaps in the Super FX map if you really don't want to lose the GPRAM mirror)...

I've having trouble finding any hard data on current consumption for these chips. All I know is that you can't use stuff like the multitap with the Super FX because the combination exceeds the PSU's rated maximum. (And there was talk of higan supporting devcarts with both Super FX and SA-1 on board, but I'm not sure that means both running at the same time...).

Does anyone know if it would be possible to combine chips like this without hardware instability (or at all, for some other reason)?

(I probably don't need this for my game; I'm just curious.)

[Drew Sebastino]

Don't the expansion chips just send information to the CPU by one of the busses? How does the CPU communicate to any of the chips? I imagine you could have a chip that the CPU actually communicates to that then communicates to one of the chips, and it then sends the signal back to the middle chip that then sends it back to the CPU. I have no clue how this would work though.

[93143]

There are various address decoders (LS139, MAD-1, MAD-1A, MAD-R...) used in SNES games; if I understand correctly this is basically how the cartridge interprets the standard cartridge slot pinout so the system can address the appropriate components on the board. An address decoder is pretty simple, and doesn't involve any real computation or any significant access delays; it seems to be just a signal router and can be described with a modest-sized truth table. Anything in the cartridge that needs to access memory on its own will no doubt have its own memory controller.

The Super FX chip can issue interrupts to the SNES, but mostly it's confined to the cartridge; it works within GPROM/GPRAM and its own instruction cache and registers, and can't access the main system buses or even the rest of the cartridge (CPUROM and BRAM). To get data from the GSU, the S-CPU has to pause it (or wait for it to pause itself, triggering an interrupt) so as to be able to access the Game Pak RAM. The S-CPU can manipulate the GSU via control registers and can rewrite the instruction cache while the GSU is off.

The DSP-1 presents itself to the Super NES as a range of I/O registers; the S-CPU writes data to the inputs, waits a while (or does a useful task or something), and then reads the outputs. It's just like the built-in multiplier/divider unit, only more sophisticated. And there's a special bit that indicates that a result is ready, so you don't end up with weird bugs due to trying to read a result early or change a parameter in the middle of a calculation.

[lidnariq]

You should be able to put an ammeter in series with the SNES's power switch without disrupting anything too much. Because the SNES uses a 7805, an amp in on the high side is an amp out on the low side.

[qwertymodo]

Another issue is with chips like the SuperFX or SA-1 that actually sit completely inbetween the cart edge and the ROM/SRAM. You would probably not be able to use those together due to the chips needing exclusive access to the ROM/SRAM for their own operations. Other than that, they all just exist on the same primary data bus (the A bus), and I can't think of any register address conflicts. The DSP, however, gets its data from the CPU, right? If so then it probably could co-exist with the SuperFX, yes.

[Drew Sebastino]

Another issue is with chips like the SuperFX or SA-1 that actually sit completely inbetween the cart edge and the ROM/SRAM. You would probably not be able to use those together due to the chips needing exclusive access to the ROM/SRAM for their own operations.

I know this is going to sound silly, but could you have 2 sets of rom and sram? I have no clue how this would work. I actually don't think the 2 srams would be too hard though. I have zero knowledge about this stuff, but I just figured.

[Khaz]

I know this is going to sound silly, but could you have 2 sets of rom and sram? I have no clue how this would work. I actually don't think the 2 srams would be too hard though. I have zero knowledge about this stuff, but I just figured.

Having a second set of ROM chips actually sounds like it's probably not a hard or terribly expensive solution. I wonder if there's any theoretical possibility of your two SRAMs desyncing though? I guess that's also a silly question - probably infinitesimal.

Would you also need twice as much battery power to sustain the SRAM, or do we have good non-battery options for SRAM these days?

[lidnariq]

Would you also need twice as much battery power to sustain the SRAM, or do we have good non-battery options for SRAM these days?

Both?

Our SRAMs' standby power hasn't really gotten much lower—the low-power ones (as opposed to fast) still draw about 10µW when deselected. Drawing twice as much will halve the shelf life, but whether that's a problem is another question. [1]

On the other hand, a number of people on the forum have been playing with using FRAMs instead these days. They technically have limited read cycle counts, but recent ones have durability that's so huge that the NES would take a year or two of executing straight from them to use it up.


[1] Using the data in http://www.varta-microbattery.com/appli ... lls_en.pdf implies that a 2032 coin cell, like those used in most NES and SNES game paks, sourcing the ≈3µA maximum needed to keep the values inside a 6264 should last for about 7 years. But ... some people have NES paks with the original battery, still holding onto their saves. Evidently some RAMs are using a lot less than 3µA.

[93143]

You should be able to put an ammeter in series with the SNES's power switch without disrupting anything too much. Because the SNES uses a 7805, an amp in on the high side is an amp out on the low side.

Is that a no?

(Apparently the accessory restrictions associated with the Super FX depend on ROM size, so this is evidently not a trivial question...)

I know this is going to sound silly, but could you have 2 sets of rom and sram? I have no clue how this would work.

The GSU memory map already allows for this. No games actually used the secondary ROM capability and I don't think any used the extra RAM capability either, but my shooter port is going to need both.

Code: Select all

  00-3F:3000-34FF  GSU I/O Ports
  00-3F:6000-7FFF  Mirror of 70:0000-1FFF (ie. FIRST 8K of Game Pak RAM)
  00-3F:8000-FFFF  Game Pak ROM in LoRom mapping (2Mbyte max)
  40-5F:0000-FFFF  Game Pak ROM in HiRom mapping (mirror of above 2Mbyte)
  70-71:0000-FFFF  Game Pak RAM       (128Kbyte max, usually 32K or 64K)
  78-79:0000-FFFF  Additional "Backup" RAM  (128Kbyte max, usually none)
  80-BF:3000-32FF  Mirror of GSU I/O Ports
  80-BF:6000-7FFF  Mirror of 70:0000-1FFF (ie. FIRST 8K of Game Pak RAM)
  80-BF:8000-FFFF  Additional "CPU" ROM LoROM (2Mbyte max, usually none)
  C0-FF:0000-FFFF  Additional "CPU" ROM HiROM (4Mbyte max, usually none)
  Other Addresses  Open Bus

The additional ROM is really nice because while the GSU is still limited to 16 Mb of Game Pak ROM, you can add up to 48 Mb of CPU ROM that the SNES has all to itself, meaning you don't need to leave the S-CPU in a WRAM loop while the GSU is using the Game Pak ROM. Of course you can also use it to store a ton of extra data, as long as it's stuff the GSU doesn't need to have direct access to - full-screen 8bpp graphics, music with low sample commonality between tracks, streaming sound effects, precomputed HDMA tables, maybe even snippets of FMV (note that in some of these cases it's really helpful to be able to access the data while the GSU is running...). And it just so happens that all this extra ROM is in the top half of the map, so you can run in high-speed mode while accessing it.

...

The SA-1 does have a fairly full memory map associated with it, so if you tried to cram it into the same map as a Super FX you'd have to make some sacrifices. Nothing too horrible - mostly you'd see increased restrictions on how much of the 8 MB ROM you could see at one time, and of course both chips would lose mirrors. Oh, and only one of them would be accessible via direct page. Not a drop-in solution, but to me it seems potentially doable with some R&D.

Mind you, nobody said they had to fit in one map - the example of the NES may be instructive here...

If you wanted the chips to actually share memory, you'd have to get fancy, and the SA-1 is pretty fancy already... I suppose you could put the Super FX behind the SA-1 or something like that...

And of course there's the issue I brought up in the OP. It seems the SA-1 also excludes certain peripherals due to increased current draw, so it's entirely plausible that the combination of the two heavies would be unstable or unfeasible with a stock PSU. Mostly I was interested in the possibility of combining one of them with a lesser chip; it seems simpler to implement and more likely to work...

[lidnariq]

You should be able to put an ammeter in series with the SNES's power switch without disrupting anything too much. Because the SNES uses a 7805, an amp in on the high side is an amp out on the low side.

Is that a no?

(Apparently the accessory restrictions associated with the Super FX depend on ROM size, so this is evidently not a trivial question...)

It's a "I haven't heard anyone else measure power consumption, but it should be easy to do without damaging anything"—the power switch (at least in my initial-US-release SNES) is attached to the mainboard via a 1×2 pin header, so (at least for me) putting an ammeter in series with, or in lieu of, the power switch is almost trivial.

If I wanted time precision, because it's the pre-regulator side, I could put a comparatively large current measurement resistor there and use an oscilloscope... but the only coprocessor-having game I own is Yoshi's Island.

[Near]

Put a DC power barrel connector on the side of your cart. Voila, no more power limitations :D

[tepples]

Once you're adding a separate power supply, you might as well factor out the special chip into a separate enclosure and call it the 32Y or something. Then you'll need some different sort of game media because special chips need 16-bit memory while Super NES Game Paks are 8-bit. Perhaps you could add some PSRAM for the game program and make it take games on SD cards. Oh wait, did I just reinvent the sd2snes?

[Near]

Well, it goes without saying that you also want an HDMI and a USB port on there, too. An M.2 drive and wifi will eliminate the need for an SD card slot. You don't want this thing looking gaudy with ports everywhere, do you?

[Sik]

On the other hand, a number of people on the forum have been playing with using FRAMs instead these days. They technically have limited read cycle counts, but recent ones have durability that's so huge that the NES would take a year or two of executing straight from them to use it up.

Sonic 3 used this kind of memory, it's still kicking around =P

Then again there's the catch that Sonic 3 only reads once when it boots (caching the data in RAM) and then any accesses after that are writes. Incidentally this is why bootleg cartridges will keep the "saved" data until the system is shut down, the game just pays attention to its copy in RAM while the FRAM writes go nowhere.

[93143]

It's a "I haven't heard anyone else measure power consumption, but it should be easy to do without damaging anything"—the power switch (at least in my initial-US-release SNES) is attached to the mainboard via a 1×2 pin header, so (at least for me) putting an ammeter in series with, or in lieu of, the power switch is almost trivial.

If I wanted time precision, because it's the pre-regulator side, I could put a comparatively large current measurement resistor there and use an oscilloscope... but the only coprocessor-having game I own is Yoshi's Island.

I have Yoshi's Island, Star Fox, Super Mario Kart, Vortex, and Super Mario RPG. But I don't have the equipment to open my SNES, never mind measure anything in it, and I haven't touched a breadboard in 15 years.

On the other hand, I have an older malfunctioning SNES too, and there's an electronics repair guy in town, so it's possible things might develop in that direction...

Well, it goes without saying that you also want an HDMI and a USB port on there, too. An M.2 drive and wifi will eliminate the need for an SD card slot. You don't want this thing looking gaudy with ports everywhere, do you?

I can't help but wonder if you guys are making fun of me...