Ben Firshman is the genius behind JSNES, a playable and fully-functioning Nintendo Entertainment System emulator written in pure JavaScript. Craig interviews Ben exclusively for SitePoint.
Craig Buckler: Hi Ben. Tell us a little about yourself and what you do.
Ben Firshman: At the moment, I’m studying Computer Science at the University of Warwick, but as far as work goes, I’m principally a Django/Python Web developer. Last year, I worked on Django for Google’s Summer of Code, and this summer I’ve been doing Django development for Global Radio in London.
CB: Warwick’s a great university for IT! (Any guesses where Craig went?!) How long have you been developing web pages and JavaScript in particular?
BF: I first dipped my toes in Web development at quite an early age, perhaps 8 or 9, experimenting with MS Frontpage on hosting provided by my ISP. I was an inquisitive kid and needed to understand how things worked, so it was a natural progression to delve beneath the safety of a WYSIWYG editor and play around with the source. After a brief grounding in BASIC and C, I recall starting backend development in PHP during my early teens.
As far as JavaScript development goes, it’s a skill I’ve developed alongside my other work. The exception was a small chat application I wrote when Ajax was in its infancy. At the time it was quite exciting that it didn’t have to refresh an iframe to update; I wish I could find the code and put a date to it! Apart from this, I’ve only added spoonfuls of JavaScript sugar to my front-ends. JSNES was a huge learning experience for me.
CB: Where did your inspiration to develop JSNES come from?
BF: I stumbled across Matt Westcott’s JSSpeccy and it sparked my imagination. I have a tendency to get trapped by overly ambitious projects, and a JavaScript emulator was exactly one of those.
I played a NES for a brief period in my childhood, and based on some rigorous analysis of its speed in relation to the Spectrum (they are more or less the same age), I thought it would be the best choice of platform. That, and the fact there are vast numbers of emulators to gain inspiration from.
CB: Did you use any particular development tools or environment?
BF: Nothing particularly fancy: my trusty copy of TextMate and Firefox 3. Firebug proved an invaluable tool for debugging and profiling; nothing came close to its power at the time. The new version of Safari has some shiny new development tools, but they don’t quite hit the bar Firebug has set in terms of functionality.
CB: How long did it take to develop?
BF: I spent a few months last year contemplating the idea and browsing the source of various NES emulators. Once I found a suitable one to port (vNES) I had laid down the basics of a working emulator in a day or two. After all, the early stages were just a huge selective copy and paste exercise. From then on, it took 9 months of bug fixing and tweaking, culminating in the tiny fix enabling it to run at full speed on Chrome.
CB: It’s an ambitious project — were there any tough technical hurdles or browser incompatibilities to overcome?
BF: I didn’t hit any major hurdles. The original only worked in Firefox 3.5, but Safari 4 and the newer versions of Chrome solved the compatibility problems. Although the earlier versions of those browsers supported the canvas element they didn’t allow direct manipulation of pixels with the imageData object.
There were only a few subtle differences between Java and JavaScript that caused problems, such as division between two integers returning a float in JavaScript.
CB: JSNES runs almost 10x faster in Google Chrome and both the Mozilla and WebKit teams have been investigating the issues. Why do you think Chrome is so much faster?
BF: Interestingly enough, three independent problems originally caused bad performance on Chrome, Safari and Firefox.
- Firefox has a complex issue to solve. Firefox’s TraceMonkey engine, as the name implies, uses a technique called tracing to compile blocks of code by attempting to work out what the possible paths of execution are. Emulators branch heavily in traceable blocks such as loops and create a huge number of possible paths that could be followed. As such, it’s impractical to trace, so it runs without any of the optimization benefits. There are a couple of bugs worth following if you are interested in the issue (Bugzilla 509986 and 516264).
- The problem for Chrome was less critical. For some reason, accessing the imageData object to directly manipulate pixels is very inefficient. Simply minimizing the number of accesses caused the leap in performance.
- Safari’s performance issue has now been fixed, but the original cause was a completely different problem. Some of the classes within the emulator had a huge number of properties (the CPU and PPU for example), which caused the dictionary structure representing it not to be cached. Accessing properties on those commonly used classes was inefficient, but this was recently fixed in WebKit (changeset 48573).
To answer the question, Chrome’s JavaScript engine (and Safari’s to an extent) is just far more efficient at running this sort of code. But it originally ran at the same speed as Firefox and Safari because it had a slower canvas element.
CB: JSNES has attracted a lot of attention. Has that been a positive or negative experience for you? Has Google thanked you for raising Chrome’s profile?!
BF: It has been quite an experience to have hundreds of thousands of eyes over my work and the response has been overwhelmingly positive. In particular, numerous people have submitted patches for improving performance. I owe great thanks to all of them!
Thankfully I haven’t received any takedown notices yet. It’s reassuring that emulators of obsolete systems are becoming widely accepted by major corporations.
Interestingly, I haven’t heard from Google. But both Mozilla and the WebKit team have been in touch to try and fix the performance problems. I suppose a cutting edge Web application running poorly in their browsers but not another is bad publicity for them.
CB: Do you have further plans for JSNES?
BF: My next huge ambition is to get sound working. That’s quite a challenge because JavaScript has no direct sound support, but I’m making headway. If it’s successful I hope it will open the doors to more interesting web audio applications.
I also attempted mouse support for Duck Hunt quite early on in development, but I could never get it working. I would love to fix it although it makes the game tragically unchallenging!
There are also a number of performance improvements in the pipeline as well as more working games as the bugs get fixed.
CB: Are you working on any other exciting projects? JSPS2 perhaps?!
BF: I have nothing specific in mind yet, but let’s just say WebGL and Web workers will take JavaScript applications to a whole new level.
CB: Many thanks for your time and informative answers, Ben. We’ll all be watching JSNES and your next projects with interest.
If you’d like to track Ben’s progress, his personal home page is http://benfirshman.com/ or you can follow him at http://twitter.com/bfirsh.
See also:
Craig BucklerCraig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.
