Author Topic: gsu (superfx) support [work in progress]  (Read 201517 times)

0 Members and 7 Guests are viewing this topic.

Offline iwasaperson

  • Full Member
  • ***
  • Posts: 141
  • Karma: +13/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #420 on: April 17, 2018, 01:33 AM »
I'm not too familiar with how the SD2SNES works, but is it possible to reclock the FPGA core to the appropriate 10 or 20MHz instead of using waitstates? Waitstates are more useful as an approximation of the original clock speed, but not for exact clocks, especially if it is not an integer scale.
@Syboxez on Discord and some other places as well.

Offline ikari_01

  • Sr. Member
  • ****
  • Posts: 309
  • Karma: +80/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #421 on: April 17, 2018, 02:22 AM »
As far as I can see the core is already running at 21.429MHz which is as close an approximation as you will get with the FPGA's PLL. The FPGA gets a 24MHz clock from the MCU which is multiplied by 25/7 in fpga_gsu.bit, resulting in an FPGA clock of 85.714MHz which is in turn divided by 4 using a clock enable signal for the GSU core.

Alternatively you could choose to run from the SNES master clock which could get you intro trouble on PAL consoles because they only run at 21.28MHz instead of 21.477. And the clock signal is super jittery on PAL consoles. After all, even Nintendo soon chose to go with a dedicated on-board oscillator instead of relying on the SNES clock.

Offline Eyedunno

  • Full Member
  • ***
  • Posts: 122
  • Karma: +10/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #422 on: April 17, 2018, 02:40 AM »
As far as I can see the core is already running at 21.429MHz which is as close an approximation as you will get with the FPGA's PLL. The FPGA gets a 24MHz clock from the MCU which is multiplied by 25/7 in fpga_gsu.bit, resulting in an FPGA clock of 85.714MHz which is in turn divided by 4 using a clock enable signal for the GSU core.

Alternatively you could choose to run from the SNES master clock which could get you intro trouble on PAL consoles because they only run at 21.28MHz instead of 21.477. And the clock signal is super jittery on PAL consoles. After all, even Nintendo soon chose to go with a dedicated on-board oscillator instead of relying on the SNES clock.
So why is Star Fox running slower than it should on Normal mode (seems about 5-6% slower than it should be running based on my videos)?

Offline redguy

  • Jr. Member
  • **
  • Posts: 55
  • Karma: +149/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #423 on: April 17, 2018, 03:50 AM »
The other component of runtime is cycle count.  So:

runTime [seconds] = cycleCount / frequency (in appropriate units)

The frequency is pretty close, but my current approximation of the pipeline is not accurate so that the cycle count is higher in some cases and lower in others.  Cycles can be broken down into:

cycleCount = instructionCount * average CPI  (where CPI = cycles per instruction)

The instructionCount is likely the same unless the game changes behavior based on small differences in runTime.  So the problem is the number of cycles it takes to process instructions is different.  Let's call the sd2snes implementation of the gsu the gsu-r.  The gsu-r is used to approximate a gsu-1 and gsu-2 by programming some number of cycles to fetch and execute an instruction.  Most of the instructions are very simple when it comes to performance and take either 1 clock (gsu-2 cache hit), 2 clocks (gsu-1 cache hit), or memory clocks of latency (cache miss) @ 21.4 MHz.  Multiplies take several clocks, but look to be a fixed amount for each type.  Then there is the memory system with multiple caches, a prefetcher, and store/write buffering all of which operate, to some degree, in parallel with the execution.  This is where the number of cycles gets tricky to match.

Making it faster is easy.  But getting it to match is hard.  A better approximation is still on the todo list.

---

I briefly looked at the menu and can see that some stuff the editor probably relies on got shifted to higher addresses.  One fix would be to revert back to the old menu and use the cx4 speed option to control both the cx4 and gsu.  Another option is updating the menu editor or shifting around where stuff gets compiled into the binary.  I'm not looking to spend a lot of time on this so I may just hijack the cx4 speed option temporarily.

---

For those who are worried about their memory chips - don't be.  The latency I added to read the ram should be hidden and not affect performance.  Also, it could still be a bug in my code that is causing the timing problem.  I don't have much visibility in that part of the sd2snes and just guessed at what the problem was.  The resellers and board designers don't have control over this kind of stuff as long as they use the correct part number.  It's differences in the manufacturing of the Micron chip itself and not the sd2snes.
« Last Edit: April 17, 2018, 04:17 AM by redguy »

Offline jse

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #424 on: April 17, 2018, 05:52 AM »
I've discovered a weird issue.

https://i.imgur.com/2TKjnFT.jpg Super Famicom With SuperCIC has graphical glitching in SMW2: Yoshi's Island
https://i.imgur.com/OGoHuQE.jpg Super Famicom With no mod plays SMW2: Yoshi's island perfectly.

Not sure whats causing it, both systems are using same cables and SD2SNES, im gonna open up the unmodded Super Famicom
maybe it is a different board revison. other than that I'm out of ideas. Any one else have issues with SuperCIC modded systems?

Edit:

Ok so after opening both systems I can confirm they are diffrent board revisions
https://i.imgur.com/7nm0yxI.jpg ©1992 Nintendo SNS-CPU-GPM-01
https://i.imgur.com/FPOtdZG.jpg ©1994 Nintendo SNS-CPU-RGB-01

I am going to install a SuperCIC and uIGR in the 1994 model to make sure it's the board
revision and not the SuperCIC that causes issues, will let you all know how it goes in a bit.
« Last Edit: April 17, 2018, 06:26 AM by jse »

Offline GreenXarrow

  • Newbie
  • *
  • Posts: 21
  • Karma: +0/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #425 on: April 17, 2018, 07:07 AM »
Wow, just keeps getting better! went from v03 - v07 on SNES mini with Fast Mode - AMAZING!

Offline ikari_01

  • Sr. Member
  • ****
  • Posts: 309
  • Karma: +80/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #426 on: April 17, 2018, 11:35 AM »
I briefly looked at the menu and can see that some stuff the editor probably relies on got shifted to higher addresses.  One fix would be to revert back to the old menu and use the cx4 speed option to control both the cx4 and gsu.  Another option is updating the menu editor or shifting around where stuff gets compiled into the binary.  I'm not looking to spend a lot of time on this so I may just hijack the cx4 speed option temporarily.

In case dotsarecool wants to adapt his editor, here are the locations of the relevant assets for v0.1.7e-gsu-v07: https://docs.google.com/spreadsheets/d/1ljoD-suzTlEfXzhR3gnzEeHQfPVFrVdpMRm6E_cvZNA/edit?usp=sharing

I also sent him a tweet about it.

Offline omonim2007

  • Jr. Member
  • **
  • Posts: 87
  • Karma: +2/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #427 on: April 17, 2018, 04:48 PM »
I have unmodified PAL SNES.
In v5 firmware there are no errors at all. Everything works fine (no glitches or other problem).

I've tested all ROMs of all Super FX games (PAL, NTSC-J, NTS-U).
My projects:
- ROM sets for Retro Consoles (Russian)
- Krikzz Flash carts reviews (Russian)

Offline yavimaya

  • Newbie
  • *
  • Posts: 2
  • Karma: +0/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #428 on: April 17, 2018, 06:06 PM »
Nice update that v07 ! :D
I had lot of problems with previous releases on JAP SNES on SD2SNES rev E2.
Now every game runs ok on that JAP console, good job!.
Still having issues with pal snes.

Offline tyser

  • Newbie
  • *
  • Posts: 3
  • Karma: +1/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #429 on: April 17, 2018, 06:10 PM »
I briefly looked at the menu and can see that some stuff the editor probably relies on got shifted to higher addresses.  One fix would be to revert back to the old menu and use the cx4 speed option to control both the cx4 and gsu.  Another option is updating the menu editor or shifting around where stuff gets compiled into the binary.  I'm not looking to spend a lot of time on this so I may just hijack the cx4 speed option temporarily.

In case dotsarecool wants to adapt his editor, here are the locations of the relevant assets for v0.1.7e-gsu-v07: https://docs.google.com/spreadsheets/d/1ljoD-suzTlEfXzhR3gnzEeHQfPVFrVdpMRm6E_cvZNA/edit?usp=sharing

I also sent him a tweet about it.
looks like the message was received
Quote
Dots @Dotsarecool
1h1 hour ago

sd2snes menu customizer has been updated to support the most recent gsu build! http://www.dotsarecool.com/sd2snesimg/
it should auto detect the version of your menu.bin, it still supports the non-gsu version as well.

just tested it myself and custom menus are now working with gsu-v07

Offline DJBabyBuster

  • Newbie
  • *
  • Posts: 8
  • Karma: +0/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #430 on: April 17, 2018, 07:22 PM »
Running latest v7 on revision F cart, on Super NT and all super fx are functioning 100%.  In prior versions, especially <v5 I had much more frequent instances of roms not loading the first time, and I'd have to reset a couple times to get a successful load.  Have yet to have any error with v7, roms load every time. Aside from improving normal clock accuracy, seems close to a final version.

The GSU fast speed option is quite remarkable.  Star fox zooms like a new expert mode, and Doom is now actually playable without the awful input lag that the actual cart exhibits.     

Thank you Redguy, the functionality you've added to the sd2snes in such a short time is quite an accomplishment!
« Last Edit: April 17, 2018, 07:26 PM by DJBabyBuster »

Offline Eyedunno

  • Full Member
  • ***
  • Posts: 122
  • Karma: +10/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #431 on: April 17, 2018, 08:33 PM »
Amazing that dotsarecool did that so quickly.

Also, I agree with a lot of you about Doom. It's an improvement over the real cart on fast mode. Unfortunately, I've played Star Fox so much, and for so long (25 years!) that anything too far above or below the actual timing feels inferior to me (even though I admit that it's a cool novelty to see things move faster).

I have never played Yoshi's Island to completion, and am curious what's different between the two speeds and the real cart. Is there a certain level that might be best suited to testing the differences? I'd maybe be willing to play through to that point just to see, and I have a flash programmer with which I SHOULD be able to copy a save to/from my real cart. (I hear a lot about "Touch Fuzzy, Get Dizzy", but dunno if that's the best GSU-2 showcase or not.)
« Last Edit: April 17, 2018, 08:37 PM by Eyedunno »

Offline brianvgplayer

  • Sr. Member
  • ****
  • Posts: 285
  • Karma: +5/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #432 on: April 17, 2018, 08:41 PM »
I've discovered a weird issue.

https://i.imgur.com/2TKjnFT.jpg Super Famicom With SuperCIC has graphical glitching in SMW2: Yoshi's Island
https://i.imgur.com/OGoHuQE.jpg Super Famicom With no mod plays SMW2: Yoshi's island perfectly.

Not sure whats causing it, both systems are using same cables and SD2SNES, im gonna open up the unmodded Super Famicom
maybe it is a different board revison. other than that I'm out of ideas. Any one else have issues with SuperCIC modded systems?

Edit:

Ok so after opening both systems I can confirm they are diffrent board revisions
https://i.imgur.com/7nm0yxI.jpg ©1992 Nintendo SNS-CPU-GPM-01
https://i.imgur.com/FPOtdZG.jpg ©1994 Nintendo SNS-CPU-RGB-01

I am going to install a SuperCIC and uIGR in the 1994 model to make sure it's the board
revision and not the SuperCIC that causes issues, will let you all know how it goes in a bit.

Did you make sure SuperCIC is off on the SD2SNES itself? Maybe it would be better to try the SuperCIC on the SD2SNES before installing it onto another system?
« Last Edit: April 17, 2018, 08:44 PM by brianvgplayer »

Offline Greg2600

  • Sr. Member
  • ****
  • Posts: 300
  • Karma: +7/-0
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #433 on: April 17, 2018, 09:13 PM »
Fast mode SFX is amazing!  It might be a tad too fast IMO, but holy crud Doom, Stunt Race, even that miserable Power Slide are actually playable now!

Offline Arnold101

  • Sr. Member
  • ****
  • Posts: 356
  • Karma: +4/-1
    • View Profile
Re: gsu (superfx) support [work in progress]
« Reply #434 on: April 17, 2018, 11:10 PM »
I briefly looked at the menu and can see that some stuff the editor probably relies on got shifted to higher addresses.  One fix would be to revert back to the old menu and use the cx4 speed option to control both the cx4 and gsu.  Another option is updating the menu editor or shifting around where stuff gets compiled into the binary.  I'm not looking to spend a lot of time on this so I may just hijack the cx4 speed option temporarily.

In case dotsarecool wants to adapt his editor, here are the locations of the relevant assets for v0.1.7e-gsu-v07: https://docs.google.com/spreadsheets/d/1ljoD-suzTlEfXzhR3gnzEeHQfPVFrVdpMRm6E_cvZNA/edit?usp=sharing

I also sent him a tweet about it.
i sent him a tweet yesterday too :) ikari please check my pm here?