Javascript Hero: Change Computer History Forever —
Besides adding thousands of items to archive.org and uploading terabytes of data (I’m at 28 terabytes of data uploaded since May of this year), I’ve also been working among a bunch of fronts to bring a whole raft of knowledge and history into the browseable, usable world. Trust me, a lot is getting in there. Allow me to both reveal the next step in this grand arch plan, and put a call out for people to help.
To review, the Grand Arch Plan that has been going on for 30 years.
Step One: Begin collecting computer history. I started this step when I was 9, pulling together printouts, cassettes, later floppy disks, and hardware.
Step Two: Put it all up on the Web. I started this step when I was 28, creating textfiles.com and consistently adding to both that collection and related collections.
Step Three: Absorb the human stories. This is what BBS Documentary, GET LAMP and the next three documentaries are for. This has resulted in hundreds of hours of footage of people talking about computer history, almost all of which I am putting online into the collections begun in step two.
And now the next step:
Step Four: Ubiquity. Make it possible to get to all of computer history from everywhere, as wherever feasible. Do what it takes to make it feasible.
I’m well into this step, having affiliated myself with one of the largest public data collections in the world and giving them massive piles of materials from the first three steps. Everything is open, everything is on fast pipes, everything is easy to pull down and do what you want with it. It’s going very, very well.
But on the whole I am primarily dealing with artifacts and not experience. A number of people have done some good work to bring in experience of computer history, most notably the Emulator People. In fact, if you don’t go too crazy on the rococo specifics of the accuracy of emulators, they do really really well to take you from “I wonder what it was like to play Choplifter” to “Wow, I am playing Choplifter“. And as someone sitting in the channels of several emulation projects, I will tell you they are all getting better, every single day – improvements in speed, accuracy, flexibility and expandability.
So here is what I’d like to do.
I want to help port the MESS and MAME emulators to Javascript.
Without sounding too superlative, I think this will change computer history forever. The ability to bring software up and running into any browser window will enable instant, clear recall and reference of the computing experience to millions. Setting up images that provide walkthroughs of specific computer history/reference, that will allow playing and and recall of all manner of things online for the last 50 years (the MESS emulator has support for the 1960 PDP-1). I am more than willing to engage in debate over this – but my hope is that you’re past this and going “but how is that even possible?”
It’s possible. Javascript has become unbelievably powerful. Here’s some stuff you may not know Javascript has been able to do so far:
- Linux. Specifically, a javascript emulation of PC hardware, with an entire Linux OS running on top of it.
- H.264 – They’ve now implemented a H.264 codec in Javascript.
- PDF Reading. The pdf.js reader will allow you to read PDFs in anything with Javascript support.
- Apple II – Gil Megidish has implemented an Apple II emulator in Javascript, which you can play games in.
My strong belief is the emulator people should focus on emulation, and the javascript people on javascript – that javascript should just be one of the ports of MESS and MAME to accompany all the other ports. I feel like there are emulation people who are really focused on the proper accuracy and reliability issues, and Javascript people who are really good at taking accurate, reliable code and making it work in Javascript. In fact, I suspect it’s very easy – we just need someone focused on it.
I’m focused on it. It’s what I do. It’s what I’ve been doing for 30 years.
I am right here. I can be reached at jscott@archive.org or jason@textfiles.com and we can get started making an ad-hoc group to work on it. I can answer questions and talk to anyone. This is priority one for me.
Hope to hear from you.
Categorised as: computer history | jason his own self
Comments are disabled on this post
Porting the code base to JS is silly (maintenance is an uphill battle for the projects as is), but it may be possible to compile the C++ to JS using Emscripten or something like it.
Justin: I suspect Emscripten will play a part in the process – join the working group and we’ll discuss it.
My own Javascript skills are not up to such a task, but I’m very excited at the prospect of Wayback-mulators someday being available to anyone with a web browser (especially connected to the ever-growing software collections of the Internet Archive).
If, or I should say when, there comes a time where a developer or development team needs a hand testing and debugging these projects – definitely count me in!
I am up for it! I have very little time to devote unfortunately but I’d love to participate. I was initially thinking of compiling the C++ to JS as mentioned above.
Didn’t Google do something like this.. I guess it was Native Client. http://code.google.com/chrome/nativeclient/docs/portingMAME.html
Hi, I am one of the Emscripten devs and one of the people working on the H.264 port to JS that you mentioned. This sounds like a great project, I would love to help out if you take the path of compiling those projects to JS!
Is there a mailing list already that I should follow?
Have you tried Emscripten https://github.com/kripken/emscripten?
Agree with yauch. Native Client is definitely worth a hard look. Upsides:
1] a bunch of work has already been done porting MAME
2] the performance penalty is significantly smaller (even emulating very old games is surprisingly expensive, it is currently still a hard problem to get good performance out of a rewrite of many old games in js let alone incurring the overhead of emulation)
3] by compiling the actual MAME code into the NaCl environment it will be much less work to pull in all of the advances of the MAME project as it continues to improve
The cons as I see them:
1] NaCl hasn’t taken off yet, and still feels like a research project in many ways. It does run in Chrome Dev fine, and is intended to also exist as a plugin for other browsers I believe, but I can’t find documentation on this
2] javascript is a very stable platform. anything that you get running in it is likely to be better supported (including speeding up the APIs you call) than any other platform I can name
Is it me or is the LLVM server down?
Have you heard of Emulation Collective? They’re doing something quite similar, allowing you to play NES, SNES, Game Boy/Color, and CHIP-8 games online, through your browser, through Java.
These aren’t random ROMs grabbed from the internet either. Due to a legal dispute, they have to actually own and dump the games they host themselves. So the selection of games isn’t exactly complete, but it is pretty sizable (at least the NES selection is, which is the emulator that’s been around the longest).
They even support games that use battery saves by having the site spit out a code you can copy and paste every time you visit. It’s pretty nice.
http://www.emulationcollective.com/
It would be cool if users could interact with content like you can on canv.as. Imagine being able to drag a rom or zip file onto the page, upload it, play it, share it, embed it like a youtube video.
Forget js, just sit back and wait, nacl will make all this happen. Maybe not tomorrow but give it another year.
In fact I assure you, given the ability to easily run emulators in nacl then there is no way that it will not happen.
eg : http://www.naclbox.com/
From the available options I still prefer the JS route. I ran emscripten and passed its tests 🙂 I’ll play with it a bit more and then I’ll start reading the MAME source code (http://mamedev.org/source/). Any word on a mailing list?
I’ll have a mailing list tonight, and a wiki page is being worked on.
Hay! i’m really interested in learning about game development with JavaScript and in a web environment, I’ve been developing for the web for 10+ years, so porting game emulators sounds like a good hobby, let me know how i can help with this!
I was thinking about this the other day, but I was coming at it from the VM route.
There’s already a web based front end to VMWare that allows you to run a vm and connect to it’s console in a browser, and I was imagining if you could create a (eg) NES instance as easily as you can create an x86 virtual machine now.
It’s more a client-server type of setup than using JS.
Short form answer: VM solution is very effective but doesn’t scale.
As you know, emulators accessed via browser are not new: http://web.utanet.at/nkehrer/
I would think you’d run into two possible problems – 1, since MAME and MESS are both constant works in progress, you’d have to constantly be rejiggering your javascript version, and 2, what about the legal issues of the ROMs? If you get a lot of buzz you’re going to attract the attention of those who take exception to this stuff…. just a thought.
I can answer the ROMs thing: Having the ROMs that most people would want and using them the way most people would want to is a copyright violation. The law is clear on who is allowed to redistribute works, and it isn’t the emulation community. Not profiting off of redistribution does not make it legal; at most, it reduces the damages the owners can extract from you in civil court.
(Yes, it’s illegal even if its owners don’t care. The law doesn’t have a concept of “Abandonware” even if everyone else seems to.)
On the other hand, emulators themselves are entirely legal and nobody can really stop a MAME- or MESS-in-Javascript project on legal grounds.
Yay! I finally made it to textfiles.com! 🙂
About time, I say!
Aside from the Apple2 emulator, I also wrote a Dragon’s Lair animation player in javascript, implemented the entire Another World game engine, and nowadays finishing up an Apple2 cassette player for mobile web.
W00t
@Jason Scott: You do realise, that this will kill Emulation-Accuracy?
See ” byuu.org/bsnes/accuracy “.
It won’t kill it. It’ll set it back slightly, and then provide a generalized framework where improvements to MESS accuracy over time will be immediately reflected in the javascript deployments.
Hey there, I am Mr. Animator Pro man, so you already know me as someone who is interested in javascript, and saving historical software from digital death. As other people have mentioned, Emscripten will probably be the way to go– not just for keeping the code base up to date, but for performance. It turns out that emscripten produces javascript optimised for modern VMs — see this article http://blog.mrale.ph/post/12396216081/the-trap-of-the-performance-sweet-spot
So C and C++ translated to Javascript by Emscripten actually runs significantly faster than Native Javascript- at the cost of the generated code being rather obfuscated and unreadabable/unmodifiable.
Performance will naturally get better. I’ll let you know how I go with eventually getting Animator Pro onto emscripten.