Messages

1

FXPAK (SD2SNES) / Re: SD2SNES mysteriously deleting save files

« on: November 06, 2019, 12:44 AM »

The problem is a MVN executed on the SA1 at instruction address $C0AAE1.  The destinations starts at $408000 which wraps the 32KB SA1 work RAM and overwrites the save slots that happen to be at the beginning.  It has something to do with the different state stored at $4F0-$4FF in SA1 work RAM as compared to the vanilla ROM.  That's probably a result of the ROM changes in the randomizer.  Maybe check that the boss or boss sprites change the randomizer makes on that screen are compatible.  I know next to nothing about SMRPG so that's all I can help with.

Both bsnes-plus and mesen-s also have the same failure.  Put a breakpoint on a write to $408000 "SA-1 Bus" in bsnes-plus to find it on the screen transition.

The match of the ROM CRC in firmware does not affect the running game's use of work RAM.

EDIT: Looks like newer versions of bsnes-plus implement the cart work RAM write protection feature which hides the bug.  That's probably why most emulators don't overwrite the save RAM region at the beginning of work RAM.  It's possible some of them may also NOP memory overflows rather than masking the address and having it wrap.

2

FXPAK (SD2SNES) / Re: sa1 support [work in progress]

« on: August 13, 2018, 07:24 PM »

sa1 v05
----------
See first post for the link to the latest version: http://krikzz.com/forum/index.php?topic=8045.msg61986#msg61986

This fixes a reset bug when using the console reset button to restart the game.  I also tried rewriting a part of the code that had known timing bugs.  Hopefully this reduces the chance it will crash, but I may have also introduced new bugs.

The visual glitches in Kirby Super Star is a known bug and, unfortunately, looks like a bug in some consoles and not the sd2snes sa1 implementation.  Somehow a real cart works around it.  I'll have to see if I can find a way to do that on the sd2snes, too.

I'm getting a pal console soon.  Hopefully that helps with reproducing some of these bugs.

3

FXPAK (SD2SNES) / Re: sa1 support [work in progress]

« on: August 08, 2018, 05:30 PM »

sa1 v04
----------
See first post for the link to the latest version: http://krikzz.com/forum/index.php?topic=8045.msg61986#msg61986

This fixes some reset bugs and the beetle game scoring in smrpg.  It also adds some limited in-game hook support.

4

FXPAK (SD2SNES) / Re: sa1 support [work in progress]

« on: August 05, 2018, 07:56 PM »

sa1 v03
----------
See first post for the link to the latest version: http://krikzz.com/forum/index.php?topic=8045.msg61986#msg61986

This update targets problems in certain Marvelous romhacks, golf games, and Pachi-Slot Monogatari. It may fix crashes or performance issues in other games but that is not confirmed.

5

FXPAK (SD2SNES) / sa1 support [work in progress]

« on: August 01, 2018, 11:36 PM »

https://github.com/RedGuyyyy/sd2snes/releases/download/sa1_v05/sd2snes_sa1_v05.zip

See the readme.txt file for details on how to install it.  To summarize, make sure you have a clean, working copy of 1.8.0 and then copy the files from the zip's "sd2snes" directory into your SD card's "sd2snes" directory.  Then restart your snes/sd2snes and check you are running the correct version.

It's still very much a work in progress.  Expect bugs including graphic glitches, crashes, slowdowns, etc.  I don't own a lot of snes or sd2snes variants so my testing is limited.

You're welcome to post bugs to here or the github page, but I need a break from working on it and won't be fixing anything for the next few days.

6

FXPAK (SD2SNES) / It IS physically possible to emulate the SA-1 on the SD2NES!

« on: July 17, 2018, 04:34 AM »

Here's a small status update.

Is sa1 being worked on?
- Yes.

Is it going to fit?
- Maybe.  We won't know until it's further along.

Is msu going to fit?
- Assume no, but we won't know until it's done.  It doesn't fit right now.

What about supporting multiple files with different features?
- I'm not interested in supporting this, but the code will have #defines for those who want to compile a version for themselves.

What currently works?
- smrpg has been played through to the end.
- kirby super star has several hours on it.
- super mario legacy and the other sa1 smw hacks are playable.
- Most other games boot, but have limited testing.
- A small set of hacks and games don't work at all.
- All games have bugs.

Will there be a beta?
- Yes.

When will the beta be released?
- ...

When will it be done?
- ...

Most of the sa1 features are implemented, but it's difficult to fit both the debugging code and all the features at the same time.  The debugging code is a huge help for fixing bugs.  I'm currently rewriting major parts to both free up some space and also fix slowdowns.

7

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: May 05, 2018, 08:06 AM »

Check the first post for v10:

http://krikzz.com/forum/index.php?topic=7451.msg57572#msg57572

Fixed bug in starfox related to use of dithered color for plot instruction.
Fixed power slide demo by forcing init of memory to $00.
Fixed very small cycle hole with go and irq bits. May fix a rare crash.

There's a small chance that a random crash in yoshi's island was caused by the irq or go bit bug that's now fixed.  It's a really small window where multiple things have to come together.  I'm not sure what actually happens when that occurs - it's game dependent.

8

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 22, 2018, 08:37 PM »

Check the first post for v08:

http://krikzz.com/forum/index.php?topic=7451.msg57572#msg57572

Fixed timing to improve match with real carts. Thanks to all the people that contributed.
Fixed 8b multiplies to support 0 cycles of additional latency.
Fixed ram word accesses to do serialized byte transfers.
Changed ram accesses to use second ram chip.

If there are stability problems it may be due to using the new ram chip.  I can add more delay, if necessary, but it's been working so far.

9

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 19, 2018, 06:26 AM »

I just fixed a bug with the v07 github page.  v07 is still the latest and it's unchanged.

10

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« 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.

11

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 16, 2018, 03:13 AM »

Check the first post for v07:

http://krikzz.com/forum/index.php?topic=7451.msg57572#msg57572

Fixed ram timing for more ram chips with worse timing by adding additional fpga clock.
Fixed menu config save bug with gsu speed option.

If you've had problems with it not running at all give this version a try.  I will take a look at the menu editor thing.  It probably moved something in memory that the editor was modifying.

12

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 15, 2018, 11:59 PM »

Yes a custom menu should work, but it needs to be based off the new menu.bin code if you want access to the normal/fast option for the gsu.  I have never created a customized menu file before.  If it's just hex editing/pasting in new stuff to an existing file then it should work.

Someone pointed out the menu option isn't saving and I noticed a firmware bug when reading the config file.  I'll fix that in the next version.

13

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 09, 2018, 04:47 AM »

See the top of the first post for a link to v04:

http://krikzz.com/forum/index.php?topic=7451.msg57572#msg57572

I think I introduced a bug in v03 when trying to fix another bug in v02.  This is the attempt to fix that, although, I can't test it because it works for me with both versions.  If someone had a working v02, but it stopped working in v03 give this one a try.  If it still doesn't work then try the fpga_gsu.bit from v02 and see if that works.

Also, you may have to delete your save files for yoshi's island from v02 and older.  They may have gotten corrupted by v01 and v02.

14

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 08, 2018, 06:35 PM »

The stunt race fx expert track looks the same to me in the emulators as the sd2snes.  Am I missing something?  Looks like a "feature" of the expert tracks is the color changes.

15

FXPAK (SD2SNES) / Re: gsu (superfx) support [work in progress]

« on: April 08, 2018, 02:54 AM »

See the top of the first post for a link to v03:

http://krikzz.com/forum/index.php?topic=7451.msg57572#msg57572

Fixed bug with how save ram size is detected. Should fix most (all?) startup problems for games and some graphical glitches.
Fixed icache invalidation bug.
Added periodic saving back in. Saves are now backed up every few seconds.

I'm hoping this fixes all startup problems and some of the graphic glitch problems.  I was basically reading out of the psram before the game was loaded to figure out how big the cartridge ram should be.  So that either took the last game's value (which is why loading it twice seemed to fix it) or some random value if the psram loses power.

The cache bug fix seems to improve the speed of doom a little, but it may just be my imagination.

Saves should now work thanks to fixing the first bug.  They get backed up every few seconds and not when you actually save.  So don't turn off the console the instance you think the data is saved.  This is the standard way the sd2snes works, but it's in a special mode where it saves every few seconds rather than immediately when it detects something is changed in the game.

There was also a bug fixed in the voxel demo.