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.)
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.
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.
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.
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.
qwertymodo wrote:
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.
Espozo wrote:
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?
Khaz wrote:
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.
lidnariq wrote:
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...)
Espozo wrote:
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.
nocash wrote:
Code:
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...
93143 wrote:
lidnariq wrote:
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.
Put a DC power barrel connector on the side of your cart. Voila, no more power limitations :D
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?
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?
lidnariq wrote:
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.
lidnariq wrote:
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...
byuu wrote:
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...
I think it's more the fact that at this point you may as well go for a newer system with so much cheating. On a more practical remark: how much would it cost to make the actual cartridge? Especially if one decides to avoid donor boards.
You can already use MSU1 with any other special chip, including the Super FX. I didn't think using a DSP-1 instead was all that big of a deal. I seem to recall hearing that the DSP-1 was originally supposed to be part of the console; if true that would mean the Super FX by itself almost became what I'm proposing...
None of this is anywhere near what Sega pulled with the 32X, not even the dubious Super FX/SA-1 combo. To be fair, the 32X was a system add-on rather than a game add-on...
...
Well, whatever; it's not like I have any plans that require this stunt. Just thought experiments, and not very well developed ones at that...
93143 wrote:
I seem to recall hearing that the DSP-1 was originally supposed to be part of the console; if true that would mean the Super FX by itself almost became what I'm proposing...
Yep, from the Mirage emulator if I recall correctly. The idea was that the DSP-1 would have been part of the console and was removed at last moment, the reason Pilotwings needs the DSP-1 isn't because the SNES isn't powerful enough but because they didn't have enough time to reprogram the game to not use it.
In any case the cost reason stands. I recall somebody mentioning an ARM-centric DSP not long ago which in hindsight doesn't really seem that much crazier than what Sega did with the SVP (it was ARM + some memory + some random stuff I think? and 5V compatible), honestly I'd say that's a more reasonable option if it can be made to work given it's off-the-shelf (except because emulators wouldn't be able to run it, so you're stuck wih real hardware).
Sik wrote:
I recall somebody mentioning an ARM-centric DSP
That was used to accelerate AI in
Hayazashi Nidan Morita Shogi. I don't know whether NO$SNS emulates it, but the accompanying doc (
Fullsnes) describes it.
Quote:
which in hindsight doesn't really seem that much crazier than what Sega did with the SVP (it was ARM + some memory + some random stuff I think? and 5V compatible)
Samsung SSP1600, not ARM. Twice as smooth as the GSU-powered
Stunt Race FX but a lot more expensive.
Sik wrote:
Especially if one decides to avoid donor boards.
Then where are you going to get the chip from? FPGA clone? At that point you might as well just write a new HDL config for the SD2SNES.
tepples wrote:
That was used to accelerate AI in
Hayazashi Nidan Morita Shogi. I don't know whether NO$SNS emulates it, but the accompanying doc (
Fullsnes) describes it.
No, I was talking about this:
viewtopic.php?f=12&t=12820The chip in question:
https://www.verical.com/pd/stmicroelect ... aQod8kYANQtepples wrote:
Samsung SSP1600, not ARM. Twice as smooth as the GSU-powered Stunt Race FX but a lot more expensive.
I was doing comparisons in how it's designed, of course they aren't even remotely related architecture-wise =P
qwertymodo wrote:
Then where are you going to get the chip from? FPGA clone? At that point you might as well just write a new HDL config for the SD2SNES.
Thing is, SD2SNES is probably the most feasible option in the long term (especially if you consider how people don't like having to destroy a game just to make another, and here you'd need to do it with
two games to make one).
93143 wrote:
I can't help but wonder if you guys are making fun of me...
Oh, no no. Absolutely not.
My sincere apologies for giving you that impression.
I put a lot of work into allowing multiple special chips at the same time in higan, and allowing you to even run your own programs on said coprocessors. And indeed you can even use a special chip with the MSU1 on the sd2snes.
I was half-joking about putting a power port on the cart, but also half-serious.
With tepples' response, I was just having fun escalating his facetiousness. But that was directed at him (and still friendly), not at you.
This is why I hate talking online. You try and say something, and it comes off completely differently to someone else. Had you not said anything, you may have stayed upset with me over a misunderstanding >_<
byuu wrote:
With tepples' response, I was just having fun escalating his facetiousness. But that was directed at him (and still friendly), not at you.
I kinda figured that, but I wasn't sure. I tried to keep my query lighthearted rather than accusatory, but it's not easy in pure text...
Quote:
Had you not said anything, you may have stayed upset with me over a misunderstanding >_<
Don't worry; I wasn't really upset. I was just wondering if I had crossed some sort of invisible line with my proposal, given the responses I'd gotten up to that point (and then Sik's comment about "cheating" seemed to confirm it). My reason for involvement in this hobby is somewhat atypical*, and I'm still fairly new here, so I can't always be quite sure I'm not the odd man out in an unspoken consensus or something like that.
Thanks for clarifying.
tepples wrote:
That was used to accelerate AI in
Hayazashi Nidan Morita Shogi. I don't know whether NO$SNS emulates it, but the accompanying doc (
Fullsnes) describes it.
It's emulated in higan. I believe it was the last special chip to be LLEed.
Quote:
Samsung SSP1600, not ARM. Twice as smooth as the GSU-powered Stunt Race FX but a lot more expensive.
Wasn't Stunt Race FX developed for the 21 MHz version/mode and downgraded at the last second? Or was that just speculation?
Sik wrote:
In any case the cost reason stands.
What do you figure it would do to the cost? One-time R&D to put both chips on a board, maybe? I don't remember the Super FX adding much more than $10 or so to game prices, and the DSP-1 should have been a lot cheaper in the mid-'90s since it was an older and simpler chip. It feels like adding 6 MB of extra ROM would have been more expensive.
Sik wrote:
SD2SNES is probably the most feasible option in the long term
I really hope ikari implements Super FX support in the reasonably near future. If he doesn't, I might end up with a game that can
only be played using higan's accuracy core v095 and up (the port I'm working on currently relies on both the Super FX and some
obscure PPU behaviour that even v094 doesn't get right)...
Quote:
especially if you consider how people don't like having to destroy a game just to make another
I don't really like the idea of cannibalizing games for chips either. If I wanted a production run of Super FX cartridges, for instance, I'd be asking Synopsys ARC for quotes. (I wonder if Nintendo has a warehouse full of unused chips somewhere... nah, probably not.) A really cool and fairly substantial work might warrant the destruction of a copy or two of Winter Gold or Doom, but going much beyond that seems like a waste of a non-renewable resource...
*
I've loved the SNES since I first encountered an imported Super Famicom in the spring of 1991, but actually programming it was never on my radar. (Even though my research requires a lot of coding, I've never really considered myself a programmer as such; it was black magic to me until I entered university, and "assembly language" stayed that way until last year.) A little over a year ago, though, I saw a post on some website that claimed a particular game would never work on the Super NES. Being naturally contrary in matters like this, I started thinking about ways to pull it off. One thing led to another, and now I'm trying to actually port the game - and having a lot of fun doing it, when I can spare the time...
93143 wrote:
Quote:
Samsung SSP1600, not ARM. Twice as smooth as the GSU-powered Stunt Race FX but a lot more expensive.
Wasn't Stunt Race FX developed for the 21 MHz version/mode and downgraded at the last second? Or was that just speculation?
I
recently proved that the GSU-1 on a Stunt Race FX board supports the high-speed mode just fine (whether or not the code actually used it, I don't know, but I would assume so). I also had a Stunt Race FX board that used the GSU-1A revision chip
and it does too.
Due to the fact that Stunt Race FX runs like crap, I wouldn't doubt it. I'd love to see a mod of it working on the Super FX 2 chip, because the game is nearly unplayable, and I have played Star Fox, it's just that Star Fox isn't a racing game and I'm pretty sure it runs smoother anyway.
93143 wrote:
What do you figure it would do to the cost? One-time R&D to put both chips on a board, maybe? I don't remember the Super FX adding much more than $10 or so to game prices, and the DSP-1 should have been a lot cheaper in the mid-'90s since it was an older and simpler chip. It feels like adding 6 MB of extra ROM would have been more expensive.
I was talking about making a new cartridge today... =P
Espozo wrote:
Due to the fact that Stunt Race FX runs like crap, I wouldn't doubt it. I'd love to see a mod of it working on the Super FX 2 chip, because the game is nearly unplayable, and I have played Star Fox, it's just that Star Fox isn't a racing game and I'm pretty sure it runs smoother anyway.
Did that one too.
SuperFX 2 doesn't run any faster.Edit: Just checked, and at $0386AD (file offset 0x0186AD), the game does set $3039 (SFX clock select register) to $01 (21MHz mode). So yeah, it's already running full speed, you're not going to get any better performance out of a SuperFX 2 or any other tricks short of an overclock.
That video isn't from Stunt Race FX by any means =P
It is, however, a valid test of the GSU-1 clocking. And it's running on a Stunt Race FX donor board, so it's the same GSU-1 revision that Stunt Race FX uses. That, coupled with the register setting at $0386AD of the Stunt Race FX code is still a valid conclusion, regardless of the fact that I used a different game for my tests. Sure, you could go ahead and put Stunt Race FX on a GSU-2 board and run them side-by-side, but you're not going to see any difference.
It matters though, since the game itself can artificially limit its maximum framerate (in fact this is what nearly every game on the SNES does, or they'd be running way too fast to be playable). On top of that the program run by the GSU is provided by the game itself, so the GSU is running entirely different (and potentially unoptimal) code as well.
The only way to check for sure is to test against the game one is talking about.
EDIT: OK I just noticed the Stunt Racer FX hack thing. But yeah that only says Stunt Racer FX is bad, doesn't say much about the Super FX itself without testing more things for sure. (also I think the issue with Stunt Racer FX is that it loves doing textured polygons everywhere)
EDIT: checking again, it seems that rendering more cars is a bigger issue than more complex scenery o.O Are those cars really that complex?
My point was that Stunt Race FX is already running in 21MHz mode, that the GSU-1 supports 21MHz mode, and that there is no speed difference between 21MHz mode on the GSU-1 vs the GSU-2. Yes, the GSU code runs independently of the main CPU, but that aspect of the hardware is identical between revisions, so it should run the same speed on a GSU-1 as a GSU-2. The only difference that I know of that has been proven to exist between the GSU-1 and GSU-2 is that the GSU-2 can address up to 16Mbit ROM, as opposed to only 8Mbit for the GSU-1.
Just checked in Snes9XW, and it does seem to set $3039 to 1 three separate times before the actual race starts. So much for that idea...
I doubt the SVP was all that much faster at pixel plotting than the GSU, what with the use of DRAM and the lack of a smart pixel buffer (the 16-bit bus does help), but it was a multiplication monster - 1-cycle 16x16 if I understand correctly, compared to 2-cycle 8x8 or 8-cycle 16x16 for a GSU in high-speed mode (half that in low-speed mode with fast multiply). Also, I believe the chip was set up so the Mega Drive CPU could run in parallel rather than being forced into a RAM loop as with the usual GSU setup, and byuu has complained that the Super FX is a terrible general-purpose CPU. Maybe there's a lot of complicated physics going on in Stunt Race FX, if the cars are what seem to be causing the problem...
Sik wrote:
I was talking about making a new cartridge today... =P
This may be that difference in perspective I was talking about when I mentioned the port I'm working on. I'm less an artist with a creative vision and more a fanboy with something to prove, which means that compared to a typical homebrewer, I tend to think more about theoretical possibilities and less about the current practicality of production and distribution. And since the multi-chip idea is just a what-if unconnected to my actual project, this tendency is intensified...
93143 wrote:
I doubt the SVP was all that much faster at pixel plotting than the GSU, what with the use of DRAM and the lack of a smart pixel buffer (the 16-bit bus does help),
The SVP outright didn't have any graphics-specific functionality at all, it was just the DSP as-is (and Virtua Racing only uses a small subset of the instructions, so for all we know it may even be a dumbed down version - it doesn't even touch the stack). It's kind of countered by the use of packed graphics instead of planar, but still.
I suppose that the lack of FROM and TO instructions helps though (more operations in the same amount of cycles, although I wonder if the register count can live up to it).
93143 wrote:
Also, I believe the chip was set up so the Mega Drive CPU could run in parallel rather than being forced into a RAM loop as with the usual GSU setup
Oh yeah, forgot that detail... SVP just runs off its own RAM (without access to the rest of the cartridge at all), with the 68000 having the ability to do a bus request whenever it feels like (just like with the Z80). The 68000 is also responsible for loading the program into this RAM before the SVP boots (this also means the 3D rendering code isn't hardwired into the DSP, which is neat).
93143 wrote:
Maybe there's a lot of complicated physics going on in Stunt Race FX, if the cars are what seem to be causing the problem...
Honestly I wouldn't be surprised if this is the case. The truck seems to bring down the game to its knees despite not being really that more complex either. I'd argue that the textured sides cause slow down, but in practice it's zoomed out and also they're at the sides (which get squashed) so they shouldn't contribute that much to rendering time.
93143 wrote:
I doubt the SVP was all that much faster at pixel plotting than the GSU, what with the use of DRAM and the lack of a smart pixel buffer (the 16-bit bus does help)
As does the packed pixel format of the Genesis VDP, as Sik mentioned.
Quote:
Also, I believe the chip was set up so the Mega Drive CPU could run in parallel rather than being forced into a RAM loop as with the usual GSU setup
I've written entire
games for Game Boy Advance that can fit in a RAM loop. Is there a good reason that a game can't just load its most often used subroutines into $7F0000-$7FFFFF? True, RAM is as slow as slow ROM (2.7 MHz for most cycles), but I imagine it'd still be faster than sitting around and waiting for the GSU to get off the bus.
tepples wrote:
93143 wrote:
I doubt the SVP was all that much faster at pixel plotting than the GSU, what with the use of DRAM and the lack of a smart pixel buffer (the 16-bit bus does help)
As does the packed pixel format of the Genesis VDP, as Sik mentioned.
Well, yes, I was taking that into account. Or trying to - how exactly does the SVP access RAM? Is there a buffer, or does it use wait states? Or is the RAM fast enough to take a one-cycle write? I thought I'd seen a reference to a 4-cycle RAM buffer, but maybe I made that up...
The pixel buffers and associated opcodes allow the Super FX to saturate its RAM buffer without redundancy (each bit is read and written at most once per pass), at least in theory. To do better than that, you'd need faster RAM, a wider bus, a graphics format with fewer pixels per word (resulting in somewhat lower transparency overhead), or some combination thereof, and there's still the question of whether the chip can saturate its I/O without an equivalent to the PLOT functionality, which becomes less likely the faster the RAM is.
Quote:
Is there a good reason that a game can't just load its most often used subroutines into $7F0000-$7FFFFF?
Depends on the game, but I can't imagine what reason might apply to the general case. I thought I'd heard somewhere that Star Fox didn't, though... Stunt Race FX has some interesting-looking blocks of data in WRAM that might be nontrivial code, but I don't have time to try to figure out whether they are or not...
Dirt Racer for the SNES loaded to at least $7E8000-$7EFFFF (or something along those lines). This game gets props because the code appears to be loaded in fragments... and certain parts of it are definitely not as easy to find as you think they would be.
I also discovered $7F0000-$7Fxxxx being used as code in Dirt Trax FX.
The way to settle that is to place an execute breakpoint on $7E0000-$7FFFFF and see what pops up.
I actually investigated the RAM directly in Dirt Racer and Dirt Trax FX via SNES9X's RAM lookup function (I didn't have the debugger due to a platform incompatibility)... it was much harder for me to do Dirt Racer, because I had to outright look up the RAM for the music routines. Needless to say, for Dirt Racer, the game had an internal breakpoint routine (as in, all I needed to do was to call the BRK opcode). For me, at least that means I could attempt to determine what was going on.