usb support

[redguy]

Haven't posted in a while, but I've been working on a few things including the tool tray app, a bus trace capture engine, and various bug fixes.  Still working out bugs before I'm ready to post it up.

<Technical stuff below>

I have observed a random data corruption bug when reading the RAM for a while now.  It started happening a little more frequently when vector reads (VGET) were added.  I noticed that the second and later vector lane would vary rarely (4+ hours of doing random writes + reads with data checks) return shifted/rotated data or a corrupted first byte.  I believe the problem is how the MCU performs an address increment, sends the next read operation, and waits for the response from the RAM scheduler.  After a block of MCU operations are done it will still advance the address pointer and try to perform a read of the address directly after the block.  If that read is delayed and another MCU operation (address set + read) arrives it's possible the stalled read will show up and look like the first read, but with the wrong data.  As a workaround I added a FPGA_WAIT_RDY() call to the fpga_spi.c:set_mcu_addr function and it seems to have solved the problem.  I need to run longer tests to verify.

void set_mcu_addr(uint32_t address) {
  FPGA_SELECT();
->  // wait for prior operations to clear out
->  FPGA_WAIT_RDY();
  FPGA_TX_BYTE(FPGA_CMD_SETADDR | FPGA_TGT_MEM);

The USB firmware and FPGA changes make this more likely due to the context saving engine which has higher priority than the MCU, but it may still be possible to hit in unmodified 0.1.7e.

It's also interesting to note that the following print in memory.c:sram_reliable() hasn't printed since I made the change, either.  It used to show up at random times exhibiting the same first byte corruption/shifting I saw on USB reads.
printf("i=%d val=%08lX\n", i, val)

[redguy]

EDIT: I fixed a bug with a hardcoded COM port in the InputViewer and also made minor changes to the apps/ directory structure and parsing code.

https://github.com/RedGuyyyy/sd2snes/releases/download/v3/usb2snes_v3.1.zip

usb2snes v3.1

Added websocket/tray app.
Added input viewer based on NintendoSpy.
Fixed lots of bugs and added lots more.

The main update is the tray app.  You can launch the file, input, and memory viewer from there.  They can all work at the same time including multiple instances, but things start to get slow if you are reading a lot of data with something like the memory viewer.  The input viewer will work with only a few games.  If it doesn't work and you know the memory address where it stores the controller buttons you can type that (in hex) into the address field and try that.  The memory viewer can help to find the location in memory for the buttons if you know what to look for and the game writes them out.

<Technical stuff below>
The tray app listens on localhost:8080 (likely IPv6 depending on OS) and supports the websocket protocol with JSON commands and binary data.  It's a pretty simple protocol and everything available across USB has a simplified command over the websocket interface.  The websocket API I used has some issues including not exposing partial messages.

There's also more general configuration register accesses (on the FPGA) with masking support and a trace buffer which uses that config.  The trace buffer needs some testing and a tool to interface with it.  It lets you set a start and stop trigger event on the bus and captures the events in that window.  It re-uses the MSU buffer which is now expanded to 30 KB.

To free up space, the BSX, DSP, and MSU code was commented out from the default FPGA file.  The firmware loads up the appropriate default 0.1.7e when it detects these files.  So those games will lose several of the features of the USB changes.

[redguy]

https://github.com/RedGuyyyy/sd2snes/releases/download/v4/usb2snes_v4.1.zip

usb2snes v4.1

Added persistant patch support that can be applied anywhere including the menu.
Fixed save_state patch code so it doesn't conflict with the menu.
Added memory trigger for save and load into save_state patch.
Added (experimental) firmware update feature + power cycle.

The save state patch now lasts as long as you keep it powered.  You can change games and go back to the menu and it won't be disabled.  The patch still requires NMI hooks to be enabled to work.

Future updates will support updating at start of the usb2snes application and support uploading the various firmware files.  Unfortunately, that doesn't work until after you update to this version because of a bug in v3.x.

[redguy]

https://github.com/RedGuyyyy/sd2snes/releases/download/v5/usb2snes_v5.1.zip

usb2snes v5.1

Added hookless NMI patching support.  The MemoryViewer uses this to now allow updates to regions like WRAM and VRAM.
Added auto tracking Zelda HUD.
Adding websocket message logging support.
Fixed (workaround) another USB timeout I can't figure out.

[Rockslam]

https://github.com/RedGuyyyy/sd2snes/releases/download/v5/usb2snes_v5.1.zip

usb2snes v5.1

Added hookless NMI patching support.  The MemoryViewer uses this to now allow updates to regions like WRAM and VRAM.
Added auto tracking Zelda HUD.
Adding websocket message logging support.
Fixed (workaround) another USB timeout I can't figure out.

Congratulations for your work. i am testing now in my sd2snes.

[V0lrat]

First of all thank you for this!

I have been using the Save State functionality and it is quite impressive. I have been facing compatibility issues with some games and was wondering if there's anything that can be done to make them work or if it's something that's currently being looked at.

The main game I am looking to make it work with is Claymates (USA).

[redguy]

Unfortunately, Claymates doesn't appear to use NMIs (Non Maskable Interrupt) to generate a frame and the save state relies on that.

The good news is I was able to make a really simple change to the US version (attached) that enables an empty NMI.  It seems to work, but I only tested it for a few minutes.  Make sure to create a backup of the original.  Use something like lunar IPS to patch it.

You also need the attached save_state patch.  The patch will only work if you apply it while the game is started.  A bit of a hack, but that's to avoid it running more code.

[V0lrat]

Unfortunately, Claymates doesn't appear to use NMIs (Non Maskable Interrupt) to generate a frame and the save state relies on that.

The good news is I was able to make a really simple change to the US version (attached) that enables an empty NMI.  It seems to work, but I only tested it for a few minutes.  Make sure to create a backup of the original.  Use something like lunar IPS to patch it.

You also need the attached save_state patch.  The patch will only work if you apply it while the game is started.  A bit of a hack, but that's to avoid it running more code.

Your sir are a  L E G E N D! Thank you so much for that.

[redguy]

I should mention that the latest version (currently v7) can be found here: https://github.com/RedGuyyyy/sd2snes/releases/latest

I haven't had time to work on it lately so it will stay at v7 for a while.

[ErivandoXP]

Awesome features!

I used savestate on the SD2SNES for the First time!

Easy to use. Thanks a lot and good Lucky.

[FartPuff]

besides save-states, super nerdy developer stuff like memory view, and HUDs, what else could this kind of gear-chain provide?  Netplay perhaps?

edit:  I just did notice Redguy mention he was tinkering with netplay.  wow.  if USB/netplay becomes a thing it's definitely interesting to me.

[Monkey]

This is really intresting stuff.  Does this mean that theoretically with 2 SNESes and 2 SD2SNES carts something like this could be hacked to work on real hardware?

https://www.romhacking.net/forum/index.php?topic=7912.0

A 4 player SMK would be really cool.  Or just 2 player battle mode without seeing the others screen.

Or a really bad way to play doom deathmatch!

[ErivandoXP]

The usb2snes savestate function is possible to integrate with the official firmware without a computer?

[Enmet]

This is really intresting stuff.  Does this mean that theoretically with 2 SNESes and 2 SD2SNES carts something like this could be hacked to work on real hardware?

Maybe, the closest thing we have so far is Multitroid, a co-op client for Super Metroid that syncs game events and items between players.

In the case of Multitroid, you will have two different instances of Super Metroid running on two different consoles (SD2SNES and Snes9x supported) but ammo, health, items, map, events (bosses down, special doors opened, game triggers) are all shared between players. Here's a video of 100% from the release event.

Perhaps there would be too much latency for a vanilla 2-player mode.

[Monkey]

So in theory you could have a raspberry pi connected to the usb port running software to make a modern day BSX feature?  There could be a ROM hacked version of games like F-Zero, Super Mario Kart or SMW etc. that coud run on the SD2SNES that you could select and download custom levels from online.  Upload scores and lap times/ host data. The pi could handle you account/ username and ghost is patches for the latest games to be hacked and features.