Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - redguy

Pages: [1]
FXPAK (SD2SNES) / sa1 support [work in progress]
« on: August 01, 2018, 11:36 PM »

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.

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.

FXPAK (SD2SNES) / gsu (superfx) support [work in progress]
« on: March 26, 2018, 08:04 AM »
Latest version is here:

A few weeks back I decided to learn about the superfx chip and this is the result.  It's still quite buggy, but I figured it's far enough along to show a video (ignore the bad gameplay).  The various caches haven't been fully implemented which causes moderate slowdown.  There are also several graphical glitches that need to be worked out as well as getting the other gsu games working.  The fpga is quite full and hopefully it all fits.

It's not ready for people to test, yet.  Once it gets to that point I will post a set of files.  Thanks to those who have offered to help.

The development platform uses usb2snes to read out gsu state, step instructions, set breakpoints, collect an instruction trace, and other useful stuff.  It's been extremely useful in finding many bugs.

Source is here, but I haven't checked in the firmware changes necessary to run the fpga file correctly.

One area that would help a lot is some self-checking assembly tests.  krom has a suite here that all pass, but it would be great to have more tests.  After the caches are implemented I plan on writing some myself.

Huge thanks to all the bsnes and bsnes-plus developers, the nocash fullsnes docs, krom and his gsu tests which found several bugs early on in development, and ikari for making the sd2snes.

FXPAK (SD2SNES) / programmable address map
« on: January 29, 2018, 12:10 AM »
EDIT: There's a new version.  The major changes are the Disable field was moved to the Type field, a NOP type was added to force a match but not use the table (useful for WRAM, etc, to avoid false SaveRAM matches), and timing was improved a little.

I thought it would be interesting to support a programmable address map.  This is more a proof of concept than something that is useful long term.  Many of the lorom and hirom formats work.  I gave up on trying to support bs-x and star ocean (why does this interleave using the bank address bits?) so they are still hardcoded.  In addition to the basic maps, there is support for a yml format that can be located along with the rom of the same name in order to program a custom address map.  I included an example for Super Ghouls and Ghosts (lorom, no saveram) at the end of this post.  Programming it is not very straightforward and errors usually result in a black screen on start.

The zip file contains new firmware and fpga_base.bit files along with the sample custom address map.

The timing was already pretty tight for the address map generation logic and I only made that worse.  I tried a few fixes, but it's not always obvious what the problem is.  What seems like a good fix to improve things sometimes makes it worse.  One time changing the name of a variable allowed it to successfully finish synthesis...

# Address Map Definition
# Up to 8 Address map entries which are 8B each.
# Mode
#  7:4 0=ROM, 2=RAM (RAM ignore ROMSEL), E=NOP, F=Disable
#  3:0 0=64KB page interleaving (15:0), 1=32KB page interleaving (14:0), ..., 5=2KB page interleaving
# Base = 23:8
# Mask = 23:8
# OBase = 23:16
# OMask = 23:8
# Match = Mode[7:4] != Disable && (Base == SNES_ADDR[23:8] & Mask)
# Addr = {OBase, 0000} + ({SNES_ADDR[23:16], SNES_ADDR[15-Mode[2:0]:0]} & {OMask,FF})
#   [ Mode, Base,     Mask,     OBase,    OMask    ]
- AddrMap:
    [ 0x01, 0x008000, 0x008000, 0x000000, 0x0FFFFF,
      0xFF, 0x000000, 0x000000, 0x000000, 0x000000,
      0xFF, 0x000000, 0x000000, 0x000000, 0x000000,
      0xFF, 0x000000, 0x000000, 0x000000, 0x000000,
      0xFF, 0x000000, 0x000000, 0x000000, 0x000000,
      0xFF, 0x000000, 0x000000, 0x000000, 0x000000,
      0xFF, 0x000000, 0x000000, 0x000000, 0x000000,
      0xFF, 0x000000, 0x000000, 0x000000, 0x000000 ]

FXPAK (SD2SNES) / usb support
« on: June 17, 2017, 11:10 PM »
I took saturnu's usb firmware mods and made the following changes:
- Ported it to 0.1.7e.
- Rewrote most of the packet handling code to provide an interface to the file system and some common FW commands.

It's all a bit of hack right now while I figure out what I ultimately want to do with it.  The USB version supported by the sd2snes HW is 2.0 @ full speed (12 Mb/s theoretical data rate).  Reasonably fast for transferring single digit number of files, but not anywhere close to accessing the SD card directly from your computer.

Please back up your SD card if you decide to try it out.  The error/reset logic isn't the greatest so it's possible to get the usb state machine in the firmware and/or the app accessing it out of sync.  Getting the USB to work again usually involves reopening the app and/or rebooting the snes.

One odd thing I've seen is something related to sd2snes SRAM reads seem to indirectly mask or disable the interrupt that gets called when EP2/BulkIn is available.  I saw some comments from saturnu regarding this, too.  The current code has to poll (hack) in order to push the data out when SRAM is accessed.  When it's a transfer of a file from the SD card the interrupt seems to work fine.  Maybe it's caused by the FPGA accesses?

This includes:
- The firmware with instructions on how to update the firmware and install a suitable windows driver.
- A c# app to access the file system of the SD card over USB with a variety of commands to modify, boot, etc.
- A hacked version of an alttp item randomizer display that reads SRAM over USB to update.

Source here:

Pages: [1]