gsu (superfx) support [work in progress]

[Reed_Solomon]

I really don't expect Ikari to revise the FPGA. 

Agreed.  There's what, 9 SuperFX games and 26 SA-1 games?  Assuming Sufami Turbo works (without patched roms), which should be doable, what would be the point? Unless SA-1 is considered impossible with the current FPGA, I don't see it happening.  Even if SA-1 is too difficult to do I feel another hardware revision would probably not be made to tackle it based on what I've seen.

[krom]

Hi redguy,

Amazing stuff =D
I am happy my GSU tests helped you find some bugs.
If you need any more tests made I am happy to help.
Good luck with your work.

[mrpopsicleman]

Well I'll be damned, I never thought I'd see the day. Awesome work man.

[animeloverxX93]

'Should be doable' applies to all enhancement chips; it's simply a matter of dedication, time and endurance to pull through. That, and probably money in this case.

The Sufami Turbo hardware is laid out to link two games with each other; I doubt that there's an easy way to implement Sufami Turbo games working (with their link features intact) without programming the Sufami Turbo itself.
And, if SuperFX implementation is already questionable to suceed with the current FPGA, is it really too far-fetched to consider a new board revision to have enough free-space covered for future (possible) enhancement chip implementations?
I mean, the SD2SNES already supports almost the entire Super Famicom/Super Nintendo library, plus Satellaview and MSU1.
Might as well go full-tilt and do everything, right?

Hopefully, I don't sound too demanding. I don'  t mind waiting a decade for this to happen, but if the SD2SNES can really support the entire SNES library, it will render any other flash card obsolete.
Wouldn't that be a good thing, having an all-purpose flashcard that can do pretty much everything at that point?

At any rate, that's just me.
I'm fine with my current SD2SNES, but still, it makes me wonder what will happen to the SD2SNES in the future, if the FPGA is completely filled with code and such.

[Cyber Akuma]

I really don't expect Ikari to revise the FPGA. 

Agreed.  There's what, 9 SuperFX games and 26 SA-1 games?  Assuming Sufami Turbo works (without patched roms), which should be doable, what would be the point? Unless SA-1 is considered impossible with the current FPGA, I don't see it happening.  Even if SA-1 is too difficult to do I feel another hardware revision would probably not be made to tackle it based on what I've seen.

The important point however is WHAT those games are. A large amount of those FX games are some of the most notable or best games in the SNES library such as Star Fox or Yoshi's Island, not to mention unreleased games like Star Fox 2. And the SA-1 has games like Mario RPG and Kirby Super Star as well. This isn't just some chip that was used in a handful of EA sports titles, there is a reason many people have been longing for SA-1 and FX support.

[mario64]

Hi redguy. Thanks for your work on this. Is there a way we can donate to help the cause?

[Greg2600]

SuperFX was the most well known "special chip" ever installed on a classic console cartridge, so it's been a "holy grail" for quite some time.  SA-1 would be fantastic as well, but that's not what the OP is working on right now.

[redguy]

mario64, thanks, but no donations necessary.  This is just a hobby for me.

PityOnU, you should continue your project.  My goals were to get it working as quickly as possible and have it fit on the fpga.  This resulted in overlooking lots of pipeline details.  It would be great to have a more cycle accurate implementation.

krom, most of the bugs have been caused by gsu memory addressing (PLOT, LD/ST, GET*) and snes/gsu synchronization issues.  I also haven't tested the cache injection stuff where the snes is allowed to write code into the instruction cache and tell the gsu to run it.  If you have the time, any tests in these areas would be a big help.

If someone is familiar with the sd2snes menu code it would help me to have support added for gsu configuration options.  A gsu "Normal"/"Fast" option to match ikari's cx4 option is useful.  A temporary (only available during development) gsu debug "Off"/"On" option would also be great.

Lots of progress has been made after several days of fixing bugs.  The instruction cache is implemented which significantly improved the speed of games.  star fox still lags when it's drawing a lot, though.  I think that's due to the data prefetcher missing.  Not having the prefetcher is also causing major graphics bugs and crashes in other games due to how it works.  It's next on the list to implement.

[mario64]

mario64, thanks, but no donations necessary.  This is just a hobby for me.

PityOnU, you should continue your project.  My goals were to get it working as quickly as possible and have it fit on the fpga.  This resulted in overlooking lots of pipeline details.  It would be great to have a more cycle accurate implementation.

krom, most of the bugs have been caused by gsu memory addressing (PLOT, LD/ST, GET*) and snes/gsu synchronization issues.  I also haven't tested the cache injection stuff where the snes is allowed to write code into the instruction cache and tell the gsu to run it.  If you have the time, any tests in these areas would be a big help.

If someone is familiar with the sd2snes menu code it would help me to have support added for gsu configuration options.  A gsu "Normal"/"Fast" option to match ikari's cx4 option is useful.  A temporary (only available during development) gsu debug "Off"/"On" option would also be great.

Lots of progress has been made after several days of fixing bugs.  The instruction cache is implemented which significantly improved the speed of games.  star fox still lags when it's drawing a lot, though.  I think that's due to the data prefetcher missing.  Not having the prefetcher is also causing major graphics bugs and crashes in other games due to how it works.  It's next on the list to implement.

Sounds great. Thanks for the update!

[the_randomizer]

SuperFX was the most well known "special chip" ever installed on a classic console cartridge, so it's been a "holy grail" for quite some time.  SA-1 would be fantastic as well, but that's not what the OP is working on right now.

Right, we're just saying we hope it doesn't get totally ignored by others, that's all.

[jonnnlad]

mario64, thanks, but no donations necessary.  This is just a hobby for me.

PityOnU, you should continue your project.  My goals were to get it working as quickly as possible and have it fit on the fpga.  This resulted in overlooking lots of pipeline details.  It would be great to have a more cycle accurate implementation.

krom, most of the bugs have been caused by gsu memory addressing (PLOT, LD/ST, GET*) and snes/gsu synchronization issues.  I also haven't tested the cache injection stuff where the snes is allowed to write code into the instruction cache and tell the gsu to run it.  If you have the time, any tests in these areas would be a big help.

If someone is familiar with the sd2snes menu code it would help me to have support added for gsu configuration options.  A gsu "Normal"/"Fast" option to match ikari's cx4 option is useful.  A temporary (only available during development) gsu debug "Off"/"On" option would also be great.

Lots of progress has been made after several days of fixing bugs.  The instruction cache is implemented which significantly improved the speed of games.  star fox still lags when it's drawing a lot, though.  I think that's due to the data prefetcher missing.  Not having the prefetcher is also causing major graphics bugs and crashes in other games due to how it works.  It's next on the list to implement.

Sounds great. Thanks for the update!

This is amazing, you dont know how much this is appreciated

Have you tested any other FX games? Does Yoshis Island run well?

Thank you so much

[redguy]

I just fixed a bug that was randomly crashing Yoshi's Island and several other games.  The games run faster now than in the star fox video, but they still lag too much in parts to be fun to test.

Played through most of one route before Andross blew me up (I blame the lag):
Star Fox

Plays fine, but haven't tested a lot:
Star Fox 2
Yoshi's Island
Stunt Race FX
Dirt Trax FX
Dirt Racer
Vortex

Random pixels go bad, but playable:
Doom

Bad background graphics.  Not playable:
Winter Gold

First I'm going to fix Winter Gold and hope it fixes Doom.  Then the performance will be fixed.

[SmokeMonster]

That is phenomenal!

[James-F]

I don't get it.
For years nobody dared to touch this but here comes redguy and nails it in a couple short weeks... this is astonishing.

[krom]

krom, most of the bugs have been caused by gsu memory addressing (PLOT, LD/ST, GET*) and snes/gsu synchronization issues.  I also haven't tested the cache injection stuff where the snes is allowed to write code into the instruction cache and tell the gsu to run it.  If you have the time, any tests in these areas would be a big help.

Hi redguy,
I thought I'd start with a cache injection demo which you can find here:
https://github.com/PeterLemon/SNES/tree/master/CHIP/GSU/GSUTest/CACHEINJECT

It's basically the 1st 2 tests from my ADC demo, but converted to cache injected code...
Here is how I setup this demo:
1. GSU Cart Has No SRAM Or Extended Header
2. GSU Cache Code Uploaded From SNES Side (Writes Minimum Cache Line Data)
3. GSU RON & RAN Not Set
4. GSU Resumes Using PC After STOP

Your output should match this screenshot to pass:

I hope this helps, good luck =D