Gameboy Emulator in Javascript

[insomaniacal]

I'm sure 90% of HTS users are also Slashdotters, and have probably seen this, but here is a link to a Gameboy Emulator written in Javascript. There's articles explaining each portion of the code in a fairly straightforward way, so you can understand the theory even if you don't necessarily understand the code (For those of us like me, who aren't particularly apt with Javascript).

Anyway, I thought this was pretty cool. You can learn a good deal about how the Gameboy works at a low level, and this is a pretty cool project as it is.

Link to Part 1 of the Articles.

[msbachman]

That's pretty bad-ass. Going in my bookmarks; thanks for the link.

-

[tgoe]

Finally got a chance to look at this.. Seems like a decent starting point to see how computers work in general. I hope this series gets finished though

[thetan]

The only thing is it's incredibly slow.

It's not really javascript to blame but the way the emulator is designed. The z80 emulator in that tutorial is callback and function call heavy and function calls in JS are a heavy operation.

HTS's very own user Apples wrote his own gameboy emulator (and z80 parser thats inherent to the process) in C you can find the z80 emulator here: https://github.com/forestbelton/orchard ... urce/z80.c and the entire project here: https://github.com/forestbelton/orchard . Should be decently straight forward if you know C.

[tgoe]

Well I know calling out to the DOM and long scope chain lookups in general is slower. I didn't think regular function/method calls are all that expensive. Regardless, thinking about speed defeats the purpose of the articles; especially because it isn't finished yet. FWIW, the last demo runs fine in Opera.

[thetan]

Well I know calling out to the DOM and long scope chain lookups in general is slower.

Implementation dependent. long lexical scope lookup is near O(1) in V8.

I didn't think regular function/method calls are all that expensive.

Thats probably a bit naive. In an interpreted language a function call is never _just_ a junction call.

Regardless, thinking about speed defeats the purpose of the articles;

As a compiler theory addict i'll have to disagree out of it feeling wrong to say that efficiency isn't important in such applications.

[tgoe]

long lexical scope lookup is near O(1) in V8

So it is, indeed, slower than a short lookup?

In an interpreted language a function call is never _just_ a junction call

Of course. Its never been more true than in JavaScript when hitting the DOM API with all the side effects. By regular function call I meant calling a function defined in the script itself.

I do think efficiency is important but if the author set out to write the most efficient emulator from the start, JavaScript wouldn't be the language of choice.

[thetan]

So it is, indeed, slower than a short lookup?

No, in V8 theres no significant difference between the two in. This only effects browsers with js interpreters that have a naive implementations of lexical scope.

Of course. Its never been more true than in JavaScript when hitting the DOM API with all the side effects. By regular function call I meant calling a function defined in the script itself.

By a regular function i too was talking about one defined in the script. Especially the way the prototyping is done in this emulator, every step requires 1-2 calls to prototyped function which can account for at least two symbol table lookups per call just to locate the functions AST before it can even step though the functions AST. It's not like in ASM where a call operation is a synonym for push EIP to the stack and JMP to X location in memory. Instead you have to execute a chunk of code to traverse the lexical symbol tables until the root element is found (the prototype in this case) and then execute another block of code to traverse the symbol table of the prototype you found and if a function prototype exists then execute another block of code that steps through the functions AST. Making a function call an order of magnitude more complex then _just a function call_

You ranting about "hitting the dom" is entirely outside of the scope of what i'm talking about. Constantly writing to the DOM is bad for performance because every time you manipulate the DOM the entire page must be rendered again. Like i said though, this is not what i mentioned at all tough.

[tgoe]

Ahh, not a rant and I'm aware that js is not asm... I was just trying to be sure we were talking about the same thing because it seemed to run fine for me and I'd never heard of function calls being a real problem in js before reading your posts. After playing with it a bit more (and a more complete implementation: http://www.codebase.es/jsgb/) I'm surprised to see that it's so much slower in Firefox than Chrome or Opera on the same machine. If other browsers handle it fine and the code is valid then slowness is just a limitation of the browser. Maybe Firefox's JIT is choking. Without JIT compilation I don't think these would run well at all.. function call overhead or not.

-- Wed Dec 01, 2010 12:44 am --

Ok, maybe I'm beating a dead horse... I think function call overhead is meaningless if you're getting JIT'ed anyway. I re-wrote the OP chapter 8 dispatch and eliminated at least a call per iteration. Not much, I know, but zero change in performance. Now I'm very curious: what would it take to get something like this running acceptably in Firefox. Any ideas?