

N64js: an N64 emulator in JavaScript - micheljansen
http://hulkholden.github.com/n64js/

======
k-mcgrady
Tried it with two different ROM formats .z64 and .v64 and it wouldn't run.

Edit: I took a look at the technical information on his blog[1] and found:

"It's still far from being playable. I mean, you can run around in Super Mario
64, but it's not particularly enjoyable. Various other games boot, but there
are lots of bugs, graphics glitches and slowness. Realistically, I think it's
going to be a long time before enough of these issues are fixed that n64js
could be considered 'usable'."

Still, cool that he got it working at all.

[1]<http://n64js.blogspot.co.uk/>

~~~
Sarkie
Tried it with a Super Mario 64.z64 and it worked, but died with a Wave
Race.v64.

Atwood's Law again.

~~~
k-mcgrady
Yeh, I was using Diddy Kong Racing and it failed with both formats. It's
tempted me to get my N64 down from the attic though :)

~~~
Sarkie
I think most N64 emulator devs start with Mario 64 as it was one of the first
games and probably most documented.

Coincidentally, I've been looking at this
<https://github.com/paulscode/mupen64plus-ae/> for my phone, it works fine on
my Android tablet.

~~~
pholden
Hi - I wrote n64js.

Yes, it's true that Super Mario 64 is one of the easiest roms to get running
as it uses relatively few features.

The format (z64 vs v64) shouldn't matter - I byteswap the file on load. I
don't handle compressed roms though.

A few other roms that should boot: mario kart, wetrix, aeroguage, extreme-g,
pilot wings, star fox. I haven't tested many others yet - let me know if you
have success with anything else!

One thing to bear in mind: reload the page when you switch roms. There's some
state I'm not resetting properly which breaks everything quite horribly. Sorry
for the lameness - I'll try to get this fixed ASAP.

If you open the debug pane, you should get some debug output which gives you
some clue as to why the rom failed to boot (usually unhandled memory accesses,
unimplemented save format, unimplemented instruction, something like that).
For the games that do boot, there are still some cpu bugs which prevent them
from passing the CIC-chip's CRC check. E.g. GoldenEye and Zelda OoT both seem
to fail in this way.

~~~
BruuD
You're awesome dude. Hope you get to finish this project!

------
kevinconroy
Reminded of this incredible Ars Technica article on why it's so hard to build
a good emulator. In short, you need to emulate all of the hardware features
_and_ all of the bugs, which have now become features that some games depend
on.

"It is possible for a well-optimized, speed-oriented SNES emulator to run at
full speed using only 300MHz of processing power. You will also end up with
hundreds of obscure bugs.

What typically happens is that the problems are specifically hacked around.
Both ZSNES and Snes9X contain internal lists of the most popular fifty or so
games. When you load those games, the emulators tweak their timing values and
patch out certain areas of code to get these games running. It's an
improvement over the Nesticle days of the games themselves being hacked
externally, but it is still cheating, regardless of the visual end results.

The casual gamer who only plays the most popular twenty or so titles will see
no visible differences between an emulator requiring 300MHz and another
requiring 3GHz, so they will of course go with the former. Although I do
respect and appreciate speed-oriented emulators, one concerned with accuracy
can't help but lament the way this approach stalls progress. Without more
players using the more accurate emulators, we won't find the bugs in all the
games the emulator supports. The more people we have playing the games in the
way they were intended, the better the emulator can become as issues are found
and stomped out—not by fixing specific code for each game, but by fixing the
accuracy of the emulator."

[http://arstechnica.com/gaming/2011/08/accuracy-takes-
power-o...](http://arstechnica.com/gaming/2011/08/accuracy-takes-power-one-
mans-3ghz-quest-to-build-a-perfect-snes-emulator/)

------
thebigshane
Be sure to repost this when GoldenEye 007 is working. Especially if
multiplayer is working (I assume it would be entirely harder to get actual
online multiplayer working, right? Did N64 have any real multiplayer
functionality? Either online or N64 to N64 direct connection?)

~~~
pwny
I personally didn't even have an internet connection when I got my N64 :P

There was no online mode and AFAIK no way to multiplayer across multiple
consoles. Multiplayer was 2-4 players slit-screen on one console.

------
dbbolton
Considering how hot my laptop gets just running mupen64plus, and how slow
anything with webgl is, I can't imagine this being playable for quite some
time. I imagine it was just a proof of concept.

------
jdc
See also: 1964js - <http://code.google.com/p/1964js/>

------
guilloche
I am wondering how the emulator performs. JS seems not a right language for
this kind of tasks.

~~~
nandemo
Think about it. Nintendo 64 was released around 15 years ago. Its CPU was
_somewhat_ slower than the CPUs that typically run modern browsers.

~~~
shinratdr
Processor speed is near irrelevant. The processors that ended up in gaming
consoles are both extremely complex and unique. More important than that, they
were pushed to the absolute limit using specific programming tricks that work
only on that processor by devs that had the official Nintendo dev kit. Not to
mention full documentation, upwards of 5+ years of dev experience with that
specific console, while also surrounded by people who know the ins and outs of
the console better than Nintendo.

Emulating an N64 will continue to be difficult long after x64 processors have
outstripped it in terms of speed by hundreds and hundreds of times. It will
continue to require an HLE design to be playable until even after that. Then,
maybe after we have an LLE N64 emulator, HLE JS N64 emulation will be within
the realm of playable.

