sd2snes usb support

A few years back one of the other forum members here enabled use of the USB connector on the SD2SNES. Those changes were used as a base for a small project to view and modify SNES state over USB. The version linked below has:
- A basic protocol over USB that supports reset, booting of games, SD card file access, reading and writing the 16MB RAM, and a few other things.
- FPGA changes to snoop PPU, WRAM, OAM, CGRAM, and other cart bus operations in order to store mirrored copies in a region of the 16MB RAM.
- A windows tool tray app which provides a way to multiplex the USB connection across multiple clients using websockets.
- Websocket enabled windows apps including a FileViewer/ControlPanel, MemoryViewer to see various components of the 16MB RAM, and a NintendoSpy-based InputViewer which has limited game support for displaying input controls.
- A way to patch code into the NMI hook at run time to support things like the included save_state.ips patch. The save state patch has only been tested on a few games and sometimes requires a game-specific change to support more games so don't expect even GameSaver quality.
... And other things I'm forgetting.

The USB 2.0 port supports full speed rates (12 Mb/s data rate) of which I've seen ~750 KB/s. 1 MB/s may be possible by rewriting parts of the firmware.

The code is far from perfect and I'm still working through some races in the websocket protocol, but it's usable in current form.

BSX, DSP, CX4, MSU, and some of the other chips don't support the FPGA changes in order to free up some space. They still work, but it's best to not use the USB changes with them. The FPGA code hijacks the MSU and other buffers on the SD2SNES to support capturing certain state from the cart bus that is still a work in progress.

https://github.com/RedGuyyyy/sd2snes/releases/latest

source:
https://github.com/RedGuyyyy/sd2snes/
https://github.com/RedGuyyyy/usb2snesw/

Looks very promising.
I'm making a note to look at what you've presented here further when I have some time.

As far as the FPGA change goes, I'm not super-clear on the limitations you're expressing. Are you saying that the with the special chips, the FPGA is simply too small to have the register snoop (shadow copy) also active, or is it a RAM bus bandwidth/arbitration thing, or something else?

The 16 MB RAM that's hooked up to the FPGA has enough bandwidth to write 2B between SNES bus operations which works out nicely for the 2B PPU registers and all other state. By itself, the context engine fits in the FPGA without removing the special chips, but I also added a RAM DMA engine to speed up the state saving operation (coupled with putting the SNES in a spin loop using a BRA FE operation from register state), a cart bus trace engine which is not fully debugged, and some other changes. That's when I started running out of space. I'm sure the additional code has major room for improvement, but it was easier to just remove BSX, DSP, and MSU from the base firmware to make development faster. I don't want to maintain multiple versions, yet. The CX4 and OBC1 support already cut out a lot of features to fit their changes. When the FPGA starts filling up the compile times get very long (and typically fail) due to failed timing closure.

The trace mode actually requires a lot more bandwidth (6B trace record per snes operation) and the block RAM used for the MSU and DSP were convenient to re-use for that. The MSU buffer was originally 16KB and is now expanded to 30KB. It's dual port and can perform both a read and write on a FPGA cycle (~96 MHz). The 16 MB RAM supports a synchronous mode which has higher bandwidth, but the pins aren't hooked up to do those operations - perhaps because the FPGA I/O is filled. The MSU buffer also has other higher bandwidth uses which are still a work in progress.

So I guess it's a bit of both, in the end. Despite the space constraints, it's nice to have access to emulator-like state for the various SNES RAMs and a way to access the menu operations and SD card. I have a locally modified version of bsnes-plus that polls on the VRAM contents and PPU registers to display the state in the PPU viewers. It's a bit of a hack right now and isn't included in the zip file. The 16MB RAM also provides a lot of extra room to add code and data at runtime that interact with games.