Sorry to keep you waiting! Turns out I have some sort of GUI-code-a-phobia so the cheat interface isn’t done yet.
I’m currently updating the secondary FPGA configurations (cx4, obc1, bootstrap) with the updated in-game command interface and simplified memory sharing. So with a bit of luck I might be able to release a preview version (with everything but cheat support) this weekend. :)

Here’s what I’ve been working on in the meantime:

  • More refactorings of the menu ROM. This will facilitate further UI development (sub-menus etc.)
  • NMI+IRQ hook routine – these are required for WRAM cheats and in-game reset. The latter is in working state as of now. I’d like some input on which key combinations would be desirable ;-) (some conflicts can arise with existing SNES mods, see below). There is now a dedicated memory area in FPGA block RAM mapped to $2a00-$2aff which is used for the hook routine and command exchange between a running game and the sd2snes main CPU.
  • Game loading handshake between SNES menu and sd2snes CPU – this is a technical prerequisite for error handling (such as missing supplementary files, write-protected SD Card, etc.)
  • LED blink codes for file system errors – e.g. in case the SRM file cannot be saved this will tell you that something’s gone wrong. Also the sd2snes will retry saving until it works so you have the chance to swap out the SD Card etc.
  • “Screen saver” – the screen is darkened after some idle time to reduce wear on CRT and plasma screens.
  • Memory sharing between SNES and the sd2snes CPU is greatly simplified (The FSM is reduced to only 5 states instead of 18) and timing is more relaxed. This should help with stability on a wider range of consoles.
  • Fixed some compatibility issues with a number of games. (Super Play Action Football (S-RTC interference), GP1 Part II (WRAM initialization), Human Grand Prix (mapper detection bug))

To do for the upcoming release:

  • Cheat management – technical prerequisites for cheats (ROM+WRAM) are met, now to code the GUI for it…
  • Finish on-the-fly file browsing
  • Decide on key combinations for in-game functions. (en/disable cheats, kill cheat engine, reset game, reset to menu)

About key combinations:
I wanted to use combinations that don’t interfere with my SNES IGR mod. This mod uses L+R+Select in combination with Start, A, B, X, or Y to perform different operations. In that scenario I still had the four directional buttons left to put other functions on. However :D With borti4938′s release of the feature-enriched uIGR these are now taken.

So far this is my new proposal for key combinations (UPDATED 2014-06-24):

L+R+Select+StartReset game
L+R+Select+XReset to sd2snes menu
L+R+Start+BDisable cheats
L+R+Start+AEnable cheats
L+R+Start+YKill in-game routines (in case they interfere with game operation).

Updated to reflect some of your suggestions. Already looks better to me. I steered clear of L+R+Start+X because it’s similar to L+R+Select+X. ;)

Just a little fun post inbetween. Ingo Korb of sd2iec fame (that’s the project that got me started on sd2snes in the first place!) had the chance to take thermal images of a running SNES+sd2snes. Some people, including myself, found that the sd2snes gets quite hot in the SNES. However the heat actually comes from outside the sd2snes, that is from inside the cart slot! The SNES’s linear voltage regulator produces a lot of heat that gets radiated into the cartridge slot (among other places).

thermal image of an SNES+sd2snes - top view

Top view – SNES cauldron!

thermal image of an SNES+sd2snes - rear view

Rear view

These images illustrate it quite nicely. There are little hotspots where the chip dice are but most of the heat comes from below / behind.

This is a little call for feedback. In order to simplify the general usage of file lists – such as ROM lists, cheat lists, skin lists… – in terms of programming I would like to generalize directory access.

The sd2snes currently scans the entire card on startup and rebuilds an internal database if any change to relevant card contents is detected. This takes place so the file browser can always show the current state on card. Said database contains the entire directory structure and takes up quite some “ROM” space. I would like to replace this “deep scanning” by a simple “list a single directory” function which can also be used to list other kinds of files under different circumstances. This would mean that a folder will be loaded on the fly when you open it, instead of all folders being preloaded at startup.

The current state of implementation has one advantage: browsing the card is fast. There are no delays when changing directories.
The downside is that you have quite a lengthy “Loading …” screen at bootup because of the full card scan. And if something is added/removed/renamed the database rebuild can take a long time.

The advantage of proposed on-the-fly file list creation is that there is almost no loading time at startup. I could even ax the “Loading …” screen altogether. There will be no lengthy “rebuilding database …” either every time you change something on card. Files could easily be manipulated on the fly, too – some people asked for a file deletion feature – without having to rebuild the entire database. Also the database creation code is a complex mess and I want to get rid of it… ;)
The disadvantage is that there will be slight delays while browsing (as a folder is read and sorted on demand) – if a single folder contains several thousand files this can amount to a few seconds.

So um, would you mind if I changed file handling to the latter?

It’s been a while~ Firmware v0.1.6 is out with these changes:

  • OBC1 support (yeah, did it anyway :)). Metal Combat: Falcon’s Revenge now works.
  • Menu: Start button now brings up the 10 most recently played games instead of only one
  • Menu: File browser now ignores files with the “hidden” and “system” attributes
  • Partial-size BS-X games should now load correctly
  • Fixed a PSRAM mapping bug in BS-X support that caused sprite corruption or worse on some games (notably Treasure Conflix)
  • Map SRAM to the whole bank instead of just the lower half on LoROM games <=16Mbits. Fixes saving in some games, at least Ys III - Wanderers from Ys.

Grab it here.

Next up will be cheat support and possibly advanced SuperCIC utilization.

I’ve added an FAQ to address some questions I’ve been getting over time. I’d rather not give any time estimates for implemented features since that didn’t work so well in the past… ;) All I can say is that SuperFX is too much for me to handle at the moment so I’m going to target some lower hanging fruit for now.

So I’ve been getting a lot of questions pertaining to current progress, understandably. ;)
SuperFX is still crawling along, I’ve gotten a basic CPU core control unit and partial instruction decoder to work which can run test code in simulation fine, albeit limited. But it doesn’t deal with the different memory delays, stalling and parallelism yet; also the SNES interface, plot logic and other supplementary stuff are still missing.
The SuperFX uses pipelining which is a thing I haven’t fully understood yet, so that’s going to take some brain work and likely multiple complete rewrites of the CPU core. I’d rather not give an estimated time of completion for that at the moment… ;) Implementing pipelining properly is important because game code is laid out to take advantage of it and will not run correctly otherwise.

Besides the SuperFX, kogami has discovered a BS memory mapping bug, a regression that snuck into firmware 0.1.5 where I rewrote the BS memory mapping based on my own RE efforts. Also some graphical corruption has been found when using the “Run previous game” feature (Start button). I expect to make a bug fix / minor release addressing these issues (possibly others) in a couple of weeks.

Firmware v0.1.5 is out with these changes:

  • Menu: Files are now sorted by their entire file name instead of the first 20 characters only
  • Menu: Ignore input from non-standard controllers (Super Scope, Mouse etc.)
  • SPC player: fix soft fade-in (first note cut off) on S-APU consoles (1CHIP / some Jr.)
  • More accurate BS-X memory map
  • Correctly map SRAM larger than 8192 bytes (HiROM) / 32768 bytes (LoROM), fixes Dezaemon, Ongaku Tsukuuru – Kanadeeru
  • minor memory access timing tweaks (should help with occasional glitches on some systems)

Download it here.

In the past weeks, amongst a number of smaller feature requests, I’ve been getting a lot of questions about SuperFX progress. I’ve even seen rumors spread about SuperFX support being cancelled. This is not the case.

SuperFX is the most complex core to implement to date, and it even took me several months to complete Cx4 support. That was before the public release of sd2snes, however, so less people noticed. Rest assured that SuperFX support is still in progress. It will take at least the rest of this year though.

To me, having existing features working properly takes priority. That’s why I’m addressing reported bugs and also minor feature requests which have been in the queue for quite long in parallel to working on SuperFX. I expect there to be 1-2 more releases before SuperFX support is introduced in v0.2.0, not counting critical bug fixes should need for them arise. Since people seem to get annoyed at my love for the Satellaview I’ll put off further work on that until after SuperFX. :P

There will be a v0.1.5 release shortly, which supports large SRAM properly, fixes sorting of long directory entries, fixes a glitch in SPC playback with S-APU consoles, works properly with non-standard controllers plugged in (e.g. Super Scope), and has more faithful BS-X memory mapping (<- actually finished a couple of weeks ago).

v0.1.6 will probably introduce proper SuperCIC support (allowing to select 50/60Hz from the menu) and maybe rudimentary cheat code support (ROM patching only). Both might be delayed to v0.2.0.

Keep in mind that while I’m continuing work on SuperFX support it helps doing something else now and then. ;)

I’ve added a compatibility list (actually an incompatibility list) to the page: Compatibility
It will be updated whenever new custom chips are implemented or bugs are fixed.