Very neat, but it's a shame that interpretation is used. With the speed of current Javascript implementations, dynamic recompilation (block-based recompilation to JS functions, specifically) is insanely fast.
A while back, http://6502asm.com/ popped up with a web-based 6502 (chip used in the NES, Apple ][, and many others) emulator. I stumbled upon it and in a matter of hours, I patched it to become the first (to my knowledge) dynarec emulator in JS. You can see a live version here: http://ironbabel.googlepages.com/6502.html
This same technology could easily be applied to JSNES for considerable speedups.
No, sorry. I haven't done much in the way of optimizations with JS, but I'll explain how this is optimized. This is actually a simplified version of the structure used in IronBabel (emulator platform of mine, http://sourceforge.net/projects/ironbabel/ )
You have a hash table mapping an address to a block length, block function, and a hash/checksum. Your execution loop looks for the program counter in the hash table. If it exists, you take <block length> bytes from the program counter, hash/checksum it, and compare it against the hash table entry.
If the cache entry misses, you need to recompile the block. Starting from the program counter, read instructions and rather than executing the operation (as in an interpreter), you append the operation's code to a string. When you hit a branch and output the code, you break the loop. You now have the code of the block.
Wrap it in a function, eval it, and put the function in the cache.
There are a number of optimizations that can be done (see IronBabel for specifics), but the easiest is to group blocks into a state machine. Simply push all of the code into a big while(true) { switch(PC) { case 0xDEADBEEF: ... }} and break out if you hit a block that isn't in the state machine.
Yes, but it's also correct to say that he wrote a compiler.
He is taking the assembly code you type in and translating it to machine code, then he's translating the machine code to JavaScript source, then executing that source directly.
Translating a program from one language to another is compilation, by definition. While the first translation step could also be considered assembling, the second cannot.
Agreed. Google Web Toolkit was a step in this direction. Once you can develop in a language of your choice (Java, Python, Ruby, etc.) and have the user interface code auto-magically compiled into equivalent functional HTML5 and JavaScript so that it can run on any browser, I think Flash will begin its fall and decline. However, I think Adobe probably has some skunkworks project to target ActionScript/Flash as pure HTML5+Javascript output (they'll sell the graphical development tool and give up on browser domination).
Adobe is working towads the holy grail of UI design tools. To build the tool that lets wireframes become functional. They are working on FXG. I imagine, internally, that there are major turf wars on continuing with Flash native vs HTML5.
JavaScript is one of the few languages where you keep being surprised with what can be done with it. For the longest time I saw it as pretty limited, then one day somone shows me an apple II emulator in javascript.
Very impressive, but performance sucks, even in google chrome. Keep in mind that the 486 is capable of fully emulating the NES. The truth is that javascript will simply never be appropriate for tasks such as this. It is too slow and no amount of magic fairy dust optimizations will make it come close to high performance languages.
Java on the other hand (as much as I hate java) can do high performance stuff. Here is a java applet NES emulator, with sound: http://www.nescafeweb.com
I heard an interview with Brendan Eich from last year where he says there are still many javascript optimizations that haven't been attacked yet, that there is still a lot of low-hanging fruit.
He also predicted speeds bordering on C within a few years.
Even if JavaScript is slow as a turtle, Html5+JavaScript (H5J) is still a lot better for making simple animations than applets. With WebKits 3D effects, animation will look just as slick and smooth as flash.
In terms of performance, I couldn't tell the difference between a real NES for Zelda II (like 40 fps). The performance for Chrome for me was stellar, almost perfect. (v3.0.196.2)
WOW - I just installed Chrome for Intel OSX, and this is amazing. The performance in Firefox 3.5 was unplayable, while Safari 4 was much better, but Chrome is insane.
I can't believe what I just witnessed: a playable javascript NES emulator. I think this is a pretty significant step for the "web," actually.
I've heard (can't find a source) that Shigeru Miyamoto (creator of most Nintendo's hit titles) personally has a lighthearted stance to the whole emulator/ROM scene and basically thinks it is nice that people still play the games.
Sounds very plausible. It just seems odd that Nintendo would allow this to go on while still making all of these games available for purchase via the Wii store.
I wonder how far behind a n64 emulator is. Does anyone else remember when UltraHLE showed up in early 1999? Nobody expected the Nintendo64 would be emulated that soon (GameCube was still 2 years away at that point).
I wonder if sound could be added via the HTML5 <audio> support?
You can actually use the data uri scheme for <audio> src. So if you generate WAV data on the fly via JavaScript, and encode it as Base64, you can play it immediately.
Here's an example of on-the-fly WAV generation w/ <embed>, but I just tried it in Firefox with <audio> and that works as well:
I sure hope flashblock comes up with an optional canvas block because it all starts with fun and games until advertisers realize "ooh hey we can skip flash and write the content anywhere without filtering" and then you've got "hit the monkey" all over again.
I wouldn't be too concerned... The number of people using Flashblock is vanishingly small, and their eyeballs are worth less for many products. Also, Flash cookies are more advertiser-friendly than browser cookies.
A while back, http://6502asm.com/ popped up with a web-based 6502 (chip used in the NES, Apple ][, and many others) emulator. I stumbled upon it and in a matter of hours, I patched it to become the first (to my knowledge) dynarec emulator in JS. You can see a live version here: http://ironbabel.googlepages.com/6502.html
This same technology could easily be applied to JSNES for considerable speedups.