
Show HN: GBA.js, a Game Boy Advance emulator written in JavaScript - jpfau
http://jpfau.github.com/gbajs/
======
thristian
Although it's not quite in the same style as the original GBA, you might want
to consider putting the keybinding information above or below the screen,
instead of to either side - I keep my browser at a 'comfortable reading' width
(~1000px), and the keybinding information was pushed off the side without a
scrollbar. CSS media queries would probably be helpful here!

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!

~~~
jpfau
I can definitely see about moving some of the controls around. When I was
testing it, I just had a lot of "wasted space" around the edges, so I figured
I could use that for the controls and instructions. I guess I should rethink
that.

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.

~~~
thristian
(I will use 'save-code' to mean the SRAM_V123 strings embedded in ROM images,
and 'save-type' to mean the actual non-volatile storage configuration the game
expects)

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.

------
mm_alex
Imma just gonna leave this here: <http://hulkholden.github.com/n64js/> fully
functioning n64 emulator in javascript, which dynamically recompiles mips asm
to js so that your browser can JIT it into native code. the dev blog is full
of amazing js perf knowledge too: <http://n64js.blogspot.co.uk/> (videos here
also if you dont have any roms to hand)

source code on github. full disclosure: I work with paul, he's very clever.

~~~
jpfau
I tried writing an ARM -> JS recompiler, but my initial tests showed that the
slow games tended to re-copy the portions of code that were slow back into
their working RAM, causing me to invalidate the recompiled code. Maybe I could
get clever and detect when I don't need to invalidate the recompiled code, but
I have a feeling that that would actually slow it down overall. Haven't tried
this yet, though, so who can say?

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.

------
tekknolagi
Hi,

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?

~~~
thristian
You definitely want the .gba file.

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.

~~~
tekknolagi
Is there a way to upload saves, so I can do things like automatically have the
Legendaries? Yeah, cheating, but whatever :)

~~~
jpfau
There is an upload savegame button before you load the game. Once you've
loaded the game you have to reset before you can load another savegame.

~~~
tekknolagi
Hmmm. I loaded "FireRed.GBA" then click "RESET" then clicked "Upload Savegame"
— and got "FAILED".

------
SquareWheel
I did a quick search for a game, found "Mario Golf - Advance Tour (USA).gba",
and the emulator crashed immediately after upload.

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.

~~~
jarel
F Zero GP Legend (rs-fzgl.gba) worked for me (FF 15.0.1).

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!

------
Bakkot
You should let Jason Scott know about this. He's been pushing a similar
project for MAME. <http://ascii.textfiles.com/archives/3685>

------
strags
Awww. In an attempt to recreate Inception, I tried to run Foon (a ZX-Spectrum
Emulator for the GBA that I wrote about a decade ago) on it. Unfortunately it
crashed almost immediately :(

------
kevingadd
Games seem to run pretty well. I'm disappointed that there's no sound though
:(

~~~
geoffschmidt
I totally got sound out of Pokemon Red! It was pretty choppy but I think
that's because my Macbook Air can't quite manage to run the game at full
realtime.

------
weslly
I'm impressed. It works like a charm with Pokemon Fire Red.

------
NegativeLatency
Advance Wars 2 (US) crashed when I played it.

------
saebekassebil
Atwood's law strikes again.

------
camus
not sure you can post a proprietary bios like that on github, while the
emulator itself may be the author's code , i'm pretty sure the bios is not
open source.

~~~
thristian
The "bios.bin" in the resources directory is 216 bytes; the proprietary GBA
bios is 16KB. I'm pretty sure this the author's own code.

~~~
rjh29
It is: <https://github.com/jpfau/gbajs/commits/master/bios.S>

------
ank_net
nice...

