Show HN: GBA.js, a Game Boy Advance emulator written in JavaScript
jpfau.github.com
jpfau.github.com
On the emulation side, you're doing pretty well! A lot of games that fouled up bsnes' GBA emulation in the early days seem to work just fine, with the minor exception of Legend of Spyro: The Eternal Night, whose intro cinematic and main-menu are both kind of glitchy (something to do with DMA timing, if I recall correctly). Also, how are you handling non-volatile storage? You seem to be at least scanning the ROM for save-type codes, because you're triggering the copy-protection in Top Gun, but are you also trying to dynamically detect EEPROM and Flash variants?
I have here the beginnings of a save-type database that I worked on for bsnes, but bsnes' GBA emulation is kind of on hiatus for the forseeable future. If you'd like a copy (currently it's a SQLite file for ease-of-editing, but it wouldn't be hard to convert to some other format), let me know!
You're correct that I'm scanning for the save type. Auto-detection is something I want to get in at some point, but I haven't quite gotten around to it yet. I was considering using a database for the save types as well, but I didn't know if such a database existed. I was just planning on pre-computing it by the same way I'm currently detecting it, which as you say has problems.
So, there's a couple of ways you can go:
- you can go the full auto-detection path. EEPROM access and size is easy to detect, I think it's fairly reliable to detect SRAM access, but unfortunately you can't dynamically detect Flash configuration - the first question the game asks the hardware is 'which Flash storage protocol do you want' and there's no way for the emulator to figure out how to answer that question ahead of time. - You can go the full static-detection path, based on scanning for save-codes. This is pointless, because you can't determine whether the game wants 6 or 14-bit EEPROM data, and you still can't determine the Flash storage protocol. Also, there are games that contain two different save-codes but only work with one save-type, and of course there's Top Gun which contains all the different save-codes, but will ignore the A button at the main-menu if it finds any any non-volatile storage present.
- You can go full database-mode. This is what bsnes intends to do eventually, but it's kind of hampered by the fact there is no (known) complete database of save types.
- You can go a hybrid system. VBA does something like this: if the game is listed in vba-over.ini, use that save-type. Otherwise, guess based on the save-code: SRAM is easy, EEPROM starts in an 'unknown size' mode and automatically configures itself as soon as the game pokes at the emulated hardware, Flash picks some reasonable defaults and lets the user change them if they don't work. This obviously gives you really good compatibility but is horribly complicated to build.
The database I have at the moment only contains known-good configuration for the ROM images known to have two-or-more save-codes, plus one or two other games mentioned by users on the bsnes forums. It occurs to me that if you had some kind of UI where users could change the emulated storage configuration until it worked, you could have some kind of 'submit configuration' button, and the database might be built up that way.
source code on github. full disclosure: I work with paul, he's very clever.
What I did observe is that the games that DON'T invalidate the recompiled code tended to run ~20% slower, so I'm not really sure what I was doing wrong there. It mostly seems to be that the code my recompiler is outputting is less well optimized by the JIT, and not that the recompilation is too slow. It's also possible that my recompilation is screwing over the garbage collector, as I have a somewhat verbose intermediate representation that I created in the hopes that I could optimize the recompiled code. I don't have much experience with compilers though, and again, I never got around to this.
I've been pondering pushing the branch that I did this work on, but I was hoping to wait until I got it to perform better before pushing it.
What kind of file should I be selecting? .SAV? .GBA? Not sure; neither worked.
The .GBA seemed to select and do nothing, and the .SAV got stuck at "Loading..."
I'm trying Pokémon Fire Red from http://www.freewebs.com/emusaves/savs.htm (.SAV) and the .GBA from freeroms.com
EDIT: Actually, I figured that out. Is there a way I can upload savegames?
There's no upload-progress indicator, it may just be that the .gba file is taking a while to process - I think Fire Red is like 16MB or something.
edit: Tried one more, "2563 - Tony Hawk's Downhill Jam (U).gba". Crashed slightly later, about a second after upload.
Not sure what else to say. It's great to say JS projects like this but I can't make it work.
It's running at ~80% speed, I suppose we can't expect much more from today's js engines. But given how much faster the engines have gotten in the last few years, I think this is just a matter of time.
Thanks to all developers who are making this happen!