gsu (superfx) support [work in progress]

[Eyedunno]

I hear you struggled putting fx in there.  Work and perfect the fx before you move on. herd you had to take out the usb part to put the fx in i don't mind.

Ikari made the regular firmware, redguy made the current GSU beta, and I think saturnu did the USB fork. So I'm pretty sure you "herd" wrong. The GSU beta is based on the regular firmware, which never supported USB, though redguy did have a comment about maybe adding USB later.

I hope for SA-1 firmware in the future. If it doesn't fit I don't mind having separate sd cards with different firmware's for the different chips.

Why do you think that would make a difference? It's not like the SD2SNES has to load all the chips at once; you're the second person in a few days with this mistaken idea. If the FPGA doesn't have enough logic gates to implement SA-1, then having a separate SD card wouldn't fix it. If your plane doesn't have a large enough tank to cross the Atlantic, it doesn't matter how many gas cans you use to try to fill that tank.

I'm not saying SA-1 is impossible, but I am saying this is currently unknown (as far as I am aware, anyway). Some of us (like me!) have waited 6+ years for GSU though, so have patience.

[justindarc]

If your plane doesn't have a large enough tank to cross the Atlantic, it doesn't matter how many gas cans you use to try to fill that tank.

That's a much better explanation than I gave. But yeah, given than the SA-1 has greater complexity than the Super FX chip and that the Super FX implementation has already nearly-filled the FPGA, it seems unlikely that an SA-1 implementation could fit on the current hardware.

[TomKeller]

with the current version krikzz is selling that I think people have said is somewhat better for playing MSU-1 enhanced games.

The main difference between the current SD2SNES revision and previous ones (as far as i know and understand) is an operation amplifier (opamp) build onto the SD2SNES pcb. It's basically for boosting the volume level of the streamed PCM sounds in MSU1 mode, eliminating the problem of too quiet PCM audio on former revisions... as described here:

http://blog.qwertymodo.com/2017/07/the-msu-1-volume-fiasco-explained.html

That's a much better explanation than I gave. But yeah, given than the SA-1 has greater complexity than the Super FX chip and that the Super FX implementation has already nearly-filled the FPGA, it seems unlikely that an SA-1 implementation could fit on the current hardware.

A couple of weeks ago ikari himself wrote in the German circuit-board forum, that (according to kevtris and jwdonal... which both have well known experience with FPGAs themselves ) the SA-1 probably won't fit (or at least: barely fits) into the Spartan FPGA of the SD2SNES.

So SA-1 support for the SD2SNES and its current FPGA seems unlikely. And a new SD2SNES revision with an upgraded FPGA may be kind of unlikely too, since in the FAQs of his SD2SNES page ikari stated:

The hardware is final. (...)  The capabilites of the hardware will remain the same. That also means if SuperFX or SA1 should turn out to be impossible on the current hardware then that’s set in stone.

[Eyedunno]

But yeah, given than the SA-1 has greater complexity than the Super FX chip and that the Super FX implementation has already nearly-filled the FPGA, it seems unlikely that an SA-1 implementation could fit on the current hardware.

Well bleh. At least we can hope for S-DD1 for SFA2 and uncompressed Star Ocean? But even if it won't fit, work on SA-1 is still important, because it's another step on the road to perfect SNES implementation in the future where they have flying cars, FPGAs that are cheaper than water, and where everyone is enslaved to a malevolent AI named Chuck.

The main difference between the current SD2SNES revision and previous ones (as far as i know and understand) is an operation amplifier (opamp) build onto the SD2SNES pcb. It's basically for boosting the volume level of the streamed PCM sounds in MSU1 mode, eliminating the problem of too quiet PCM audio on former revisions... as described here:

http://blog.qwertymodo.com/2017/07/the-msu-1-volume-fiasco-explained.html

Hrm, presumably I have this problem then, as I was on the very first Stone Age Gamer preorder way back in 2012 or whenever. Not that I care THAT much, as I have a Super NT now, and I can adjust that, plus MSU-1 games are more of a novelty to me than something I actually play with any regularity.

[infidelity]

Interesting tidbit on the fpga usage. :-)

Hi!

For possibly getting more memory for the SuperFX chip, have you thought about sharing the memory between the various cartridge-only chips that the SD2SNES implements?

It's not necessary: The firmware consists of several FPGA bitfiles - depending on the requested game it will reconfigure the FPGA with the corresponding bitfile. There are dedicated bitfiles for DSPx+BS-X+S-RTC, Cx4, OBC1, and now GSU thanks to RedGuy. So each of these cores already has the entire FPGA's resources available to itself.

[justindarc]

So SA-1 support for the SD2SNES and its current FPGA seems unlikely. And a new SD2SNES revision with an upgraded FPGA may be kind of unlikely too, since in the FAQs of his SD2SNES page ikari stated:

The hardware is final. (...)  The capabilites of the hardware will remain the same. That also means if SuperFX or SA1 should turn out to be impossible on the current hardware then that’s set in stone.

You cut off the last part after that where he says:

Popular demand will determine whether or not I’d go and design upgraded hardware.

[TomKeller]

Hrm, presumably I have this problem then, as I was on the very first Stone Age Gamer preorder way back in 2012 or whenever. Not that I care THAT much, as I have a Super NT now, and I can adjust that, plus MSU-1 games are more of a novelty to me than something I actually play with any regularity.

If you have some decent soldering skills a SD2SNES hardware upgrade is fairly simple (and cheap too), using bortis addon pcb:

http://krikzz.com/forum/index.php?topic=5273.msg47106#msg47106

I did this upgrade myself a couple of times without any problems at all. But it's obviously not necessary, if you don't care about the MSU1 functionality that much.

You cut off the last part after that where he says:

Popular demand will determine whether or not I’d go and design upgraded hardware.

That's why i provided the link to the FAQs . But we don't have to forget: designing a whole new future-proof hardware revision takes some time... and while ikari did an outstanding job in designing a unique flash cart it is still his hobby and not his obligation supporting it. Not to mention: since writing those FAQs his priorities may have "slightly" shifted in favor of his family and private life.

So while we may see a similar FPGA based SD2SNES successor somewhere in the future, its creation is not guaranteed... and it's totally possible it won't come from ikari and it won't have a "SD2SNES" in its name .

[iwasaperson]

@iwasaperson
I had the same problem with a freshly pulled source tree. It now works after commenting out "`define DEBUG" in gsu.v:78.

That worked. Thanks! I'm guessing debugging being enabled causes the GSU core to halt unless an external program enables it or something? I'd like to know why that happens.

[Nobody09]

I've tested Yoshi's Island (both revisions) on a 2-1-3 SNES with a rev F SD2SNES and I didn't notice any issues other than some slowdown in some areas.

EDIT: I've also just tried all revisions of Yossy Island (the Japanese Yoshi's Island) and same.

[redguy]

If anyone has a rom that doesn't work at all and works in an emulator then send me a message with the name, file size, checksum.  I doubt I've run anything with the 0x200 byte copier header and there may be a problem with the scoring code.

With DEBUG defined the debug config registers are added in and default to stepping instructions.  So the first gsu instruction causes it to halt in the wait/registerwrite/retire stage until you increment the stepCnt register.  Originally, I planned to have it default to running and never reset, but there were some problems with that I never debugged.  So now it resets that register state on a snes reset assertion which makes it more convenient to default to stepping.  Now that it runs more often than it crashes I suppose I should change the default. 

[James-F]

  Now that it runs more often than it crashes I suppose I should change the default. 

Yes please. 

Redguy do you plan to further investigate the speed issues, and iron out bugs?
I am interested to know how a programmer decides what is "final", and stops debugging his work.

With the CX4 implementation, a "final" build was when SD2SNES ran Megaman X1-3 side-by-side with the real cart and was time accurate, including slowdowns of the real chip.
I suppose GSU will not hit that level of cycle accuracy as CX4 but will be very close?
Also, does the code differentiate between GSU-1 and GSU-2 speeds, or does it run everything at a certain speed (21MHz)?
Moreover, what about the remaining FPGA space you were worried about, are we in-the-clear?

Do you think compiling each commit automatically with AppVeyor for people to try will be a good idea?

[Rahzadan]

If anyone has a rom that doesn't work at all and works in an emulator then send me a message with the name, file size, checksum.

I'm happy to report that I've tested all of the Officially released (non-hacks) Super FX roms, and not a single one of them "doesn't work at all". In other words, they all work - albiet with their own individual sets of slowdowns, graphic glitches here and there, etc... I've heard that SFX rom hacks are a little bit worse off in this department, with some not working much at all - but I haven't tested these.

[toadhall]

Booted up Starfox 2 just to test this out and ended up finishing the whole bloody game. I've never even got past the second battle before in any of my previous playthroughs and I own a SNES mini! Didn't detect any problems. Some stages seemed slow but honestly I couldn't tell. Worked fine for me!

I love my SD2SNES! Good work Redguy!

[redguy]

Give this version a try.  I fixed the doom graphics glitch bug which may have also fixed stunt race fx and the startup crash.  You can turn the in-game hooks back on, but they are now temporarily disabled in gsu games.  I still need to fix that bug.

Fixed doom graphical glitch.
Fixed in-game hooks by temporarily disabling with gsu games.
Fixed save problem with non-gsu games.

See the first post for the latest version: http://krikzz.com/forum/index.php?topic=7451.msg57572#msg57572

[ArrisonChan]

Give this version a try.  I fixed the doom graphics glitch bug which may have also fixed stunt race fx and the startup crash.  You can turn the in-game hooks back on, but they are now temporarily disabled in gsu games.  I still need to fix that bug.

Fixed doom graphical glitch.
Fixed in-game hooks by temporarily disabling with gsu games.
Fixed save problem with non-gsu games.

https://github.com/RedGuyyyy/sd2snes/releases/download/gsu_v02/sd2snes_gsu_v02.zip
https://github.com/RedGuyyyy/sd2snes/releases/tag/gsu_v02

Nice! I'll give this a shot here in a few. Thanks for the hard work!