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.

Messages - redguy

Pages: 1 2 [3] 4
FXPAK (SD2SNES) / Re: programmable address map
« on: February 02, 2018, 04:53 AM »
Not sure if anyone has a use for this, but I updated it to v2 (see first post).  More effort was spent meeting timing than making the actual changes so it's done for now.

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) / Re: My SD2SNES cannot run ExLoRom game
« on: January 21, 2018, 10:06 PM »

That link is to a new fpga_base.bit file with a very simple but not 100% complete change (for all possible types of ROMs) which fixes the problem.  Make sure you are running 0.1.7e and copy it over the existing file in the sd2snes/ subdirectory on your SD card.

It's incomplete because several games have conflicting address maps for a LOROM style map that is >4MB.  I took a look at snes9x source code and the generic behavior when it detects the header is >4MB is to stack 4-8MB and then 0-4MB.  The patched FPGA file does that with the following change in the address map for LOROM:
                            : ({2'b00, SNES_ADDR[22:16], SNES_ADDR[14:0]}
                               & ROM_MASK))
                            : ({1'b0, ~SNES_ADDR[23], SNES_ADDR[22:16], SNES_ADDR[14:0]}
                               & ROM_MASK))

But there are exceptions to this like SA-1, S-DD1, and SPC7110 games.  And if the header score is lower for the 4MB region of the ROM it doesn't invert bit 23.  I don't have anything that breaks with the change, but it's possible a ROM hack or really any game that is >4MB and expects LOROM addressing will stop working.  It would have to expect the 0-4MB to be mirrored to 4-8MB for it to work with an unmodified 0.1.7e.  I also didn't touch the SaveRAM address map because the latest version of snes9x doesn't do that.  What's weird is that address map you posted does.  So you may want to test if the saving/loading works in the game.

A more complete solution would require changing the firmware to perform these checks and enable different maps.  It would be cool to have support for a programmable address map via a xml file.  :)

The current save state patch in USB2SNES mostly(*) ignores the APU state except for a few fixes to games that store to one of the APU ports and then compare that port against a value in WRAM.  If the load state operation didn't force the value into WRAM the game will sometimes lock up due to a race condition.  Most of the Capcom games need this.  It wasn't possible to fix Super Metroid this way so instead there is special handling for that.  It only allows a save/load operation when it thinks the game is not in the middle of modifying or checking the APU state.  The games that have patches are either ones I like or ones that other people have asked me to fix.

For those who are interested, the following code shows the patch table where it just reads a value from an address and stores it somewhere else when it detects the CRC in the header matches.

It's possible to go through every single game and make a custom patch to start or change the music if necessary.  Or even try to reload the APU state by resetting the game and restoring everything, including the initial APU image, and then call some game code to start the music.  But it's an enormous amount of work, error prone, and not something I am interested in doing when ignoring the APU state mostly works.

* = Actually, the FPGA code makes an attempt at saving the initial sound engine code sent to the APU.  But there's little hope in coming up with a universal way to see what the current state of the APU from something attached to the cartridge bus without implementing part or all of the APU.

FXPAK (SD2SNES) / Re: usb support
« on: December 03, 2017, 07:58 PM »

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.

FXPAK (SD2SNES) / Re: usb support
« on: November 18, 2017, 10:35 PM »

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.

FXPAK (SD2SNES) / Re: usb support
« on: November 05, 2017, 12:55 AM »
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.

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.

FXPAK (SD2SNES) / Re: usb support
« on: October 22, 2017, 01:39 AM »
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) {
->  // wait for prior operations to clear out

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)

FXPAK (SD2SNES) / Re: usb support
« on: September 30, 2017, 09:14 PM »

usb2snes 0.66

Fixed several bugs with NORESP and vector operations.
Reverted CX4 and MSU enabled FPGA file to 0.1.7e.

I reverted the mmx2 and mmx3 special FPGA programming to use the 0.1.7e files.  That and when you load a MSU enabled file it will load the original 0.1.7e.  The USB stuff and MSU does not coexist nicely, though, as they both want to use interrupts and do FPGA accesses.  And the MSU has real time requirements which I don't want to work around right now.  So if you really want to use MSU stuff then please stick to the normal menu and don't use any of the USB stuff at the same time or you strange things will happen.

<Technical stuff below>

Now the NORESP and vector operations should work in all cases.  The data you need to send/get has to be a multiple of the data size (64 or 512 bytes).  Vector operations will have packed data with no gaps between each lane.

FXPAK (SD2SNES) / Re: usb support
« on: September 24, 2017, 06:28 AM »

usb2snes 0.65

Fixed save state to not enable PPU until after PPU alignment.  Fixes some momentary graphics glitches on load.
Fixed many timing and questionable SNES bus loading statements in the FPGA.
Added support for 64B data block sizes and no responses based on flag.
Added support for 64B vector VGET/VPUT commands.
Removed MSU support from base firmware.
Removed ZeldaHUD.
Changed save to SD code to compute CRC across multiple iterations to leave time for USB on large SaveRAM images.

This is mostly bug fixes so you should definitely get it if you have an earlier version.  I temporarily removed MSU support to make room for other things, but I will fit it back in for the next release without all of the USB support.  I had to change how saving to SD works so remember to back up your SD card before trying this.  It's a little slower now for large SaveRAM files (mostly rom hacks) for it to back the save state up to the SD card.

I decided to remove the ZeldaHUD because I wasn't updating it anymore.  The previous version should still work with the 0.65 firmware.  Once there's a better USB interface to sd2snes I'm hoping someone will come along and make one or modify one of the existing ones that are popular.

<Technical stuff below>

EDIT: Looks like there are some bugs with NORESP and the GET operations.  I'm working on a fix.

I was ignoring a lot of timing problems in the verilog which I think were causing weird hardware glitches for people.  The address decode logic in several units is in desperate need of some flops, but I need to understand it better to make sure I don't introduce logic bugs.  This release fixes that and the context state is still working as far as I can tell.

The save state fix is pretty simple and cleans up the first few frames after save/load so it doesn't show garbage.

The 512B minimum packet size was artificial because full speed USB 2.0 bulk has a maximum packet size of 64B.  I'm not ready to redesign the whole USB interface protocol so instead I added flags to: (a) enable a 64B data payload and (b) disable the need for responses on certain transactions.  This is coupled with 2 new 64B commands VGET/VPUT that support 8 vector lanes of 0-255 byte each.  The vector data is packed over USB.  All of the old commands (including responses) are still 512B.  So you can now use VGET/VPUT with responses disabled and 64B payload to do small fetches of somewhat sparse data with lower latency and lower overhead.  The vector operations are reasonably well tested, but may have some bugs.

I haven't started on the app that allow sharing of the USB, but it is very high on the list of things to do.

FXPAK (SD2SNES) / Re: usb support
« on: September 16, 2017, 03:49 AM »
Glad to hear you are finding it useful.

It is possible to write data into WRAM, VRAM, and the other on-snes data stores, but it currently requires patching the NMI hook.  There are two patches:
- usb_test : This is a work in progress that is meant to be a shared "USB"-specific memory address space that will be kept mostly coherent through broadcast operations.  It has an inbound and outbound queue where you can send and receive operations (compare and swap, xor, increment, etc) that operate on a small region of memory.  The operation and data is currently defined to be 4B.
- usb_write : This is a more general purpose patch that re-uses the inbound queue code to support full address space byte writes packed into the same 4B queue element.

I haven't mentioned them before since they are just hacks and aren't well tested.  You'll want the usb_write patch.  Hopefully it still works.  I just checked in an assembled version of it:

Eventually I should merge these patches with the existing sd2snes hook code.  For things like USB address space support, save states, and anything that the hardware can detect it would be nice to have a conditional NMI hook that only runs when the trigger is hit.  But that's going to take some time to figure out and implement.

FXPAK (SD2SNES) / Re: usb support
« on: September 13, 2017, 06:39 AM »
(rgb+ossc output on the left, snes9x/usb output on the right)

I'm trying to implement a digital out from the sd2snes to an emulator (uses the software PPU) over USB.  It still needs a lot of bug fixes, a HDMA model, and some USB protocol optimizations.  The missing HDMA code is the cause of most of the background, item display, and special effect bugs.  It's pretty cool to have all the snes9x scaling and filter options available.

It probably won't work in all games and may not even work at all in the end, but it's a fun project.

FXPAK (SD2SNES) / Re: usb support
« on: August 29, 2017, 06:50 AM »
Thanks for working on it.  Now I have to be careful not to change/break the protocol.  I have to figure out a way to add support for a smaller packet size in case someone wants to poll on a small set of data.  Or maybe a scatter-gather style operation since there are probably a lot of random bytes all over memory that certain tools would want.

USB full-speed bandwidth is a little low for some of things I'd like to try.  For example, it would be nice to have a data stream operation where the app can open up a connection and the firmware keeps streaming data from some hardware queue.  The RAM bandwidth may also be a limiting factor.  I have to check if it supports a burst mode.

FXPAK (SD2SNES) / Re: usb support
« on: August 27, 2017, 10:46 PM »

usb2snes v0.6

- Fixed several timeouts.
- Fixed some graphics corruption/lockups in save state.
- Added hardware RAM DMA engine with spin loop support.
- Minor cleanup in the CTX engine.
- Updated ZeldaHUD so it hopefully doesn't crash on startup for some people.

The save states should be fast again.  The DMA engine is used to copy the current state to a location that stores the save state.

<Technical Stuff>

The DMA engine currently supports a 24b source address, destination address and length.  It has 3 opcodes: copy, reset, and set.  It works similar to MVN (memmove) and will handle overlap assuming it is bug free.  You can put the snes into a BRA $FE spin loop as part of its configuration.  It feeds the instructions directly in order to leave RAM bus cycles for the DMA operation.

FXPAK (SD2SNES) / Re: usb support
« on: August 22, 2017, 07:49 AM »

Here's a new version, but it's mostly for people who want to check out the (simple, non-bsnes-plus) RAM viewer and associated contents.  Save states are going to be slower for the time being because I'm also copying APURAM which is inefficient.  I need to add the hardware DMA engine.  I also worked around some races that I found when compiling everything under windows10.

By driver I was really just thinking of a system tray app in user space and not an actual driver.  I shouldn't have called it that.  The USB stuff has too many races and stalls that I need to work through to make all the apps deal with that code.  It would be better to have one app that deals with those problems and interleaves commands onto the sd2snes from other apps.

I'm not sure why the ZeldaHUD isn't working for you.  I didn't update it to use the latest USB code, but it still works for me.  Eventually I'm going to remove it as it was just for testing.  Yes, it's possible to add a soft reset button.  For now you can just double click/boot the file again to reload it.

EDIT: Actually, I think I forgot to include the fixed HUD in the last release.  I'll do that next time around.  I fixed it a while ago and just didn't include it.

Pages: 1 2 [3] 4