Warning: A little about project management, then a whole lot about compiling.

Three entries in a row about JSMESS! Well, I happen to think it’s one of the most important things I’ve been involved in. I mean, just think of it – vintage computers in a window, like they were a movie or a track of audio. The same way we show people something we’re working on or a piece of music we like, we can already do with a computer or computer experience. That’s magical to me. If it’s not magical to you, I don’t have anything more to discuss with you this round.

The fundamental magic of an emulator is that it creates a computer inside your computer, one that functions in many ways like the original. It’s never perfect, and the people who seek only the perfection and forget that a wrinkled photograph is better than none at all… well, they’ll never be happy. But an emulator can bring back your childhood, prove a point, answer a question, frustrate and delight. It may not inspire your own children to understand what compelled their parent so much into that world, but it might make them realize how far we’ve come or how the reason scores are at the top of the screen or why people like 8-bit references so much. And as a research tool, well…. being able to summon any artifact with the cross-platform and wide reach of browsers is a bit amazing all it itself.

Last night, while playing around, I realized I had three different computers running in windows of my laptop during testing, all of them pieces of my own past, all running along just fine.

Foe the observant, that’s an Atari 800 running Boulderdash, next to an Apple IIc running Bank Street Writer, and finally the 1980 Atari Dealer Demo. Each has their own story I won’t go into here.

In its current state, the JSMESS emulator can bring up, on your machine, in multiple browsers, hundreds of thousands of software programs that have been painstakingly transferred over the past few decades. It is already a victory were work to stop right here and now.

Obviously, we have a ways to go and the energy is still there to do it.

Now, let’s be very clear here – the lion’s share of work on JSMESS is MESS itself, which is a wonder of teamwork and dedication to accuracy and quality. Those folks, of which there are dozens, are doing a bushel of effort to bring in obscure systems, unusual setups, and strange mystical workings of long-forgotten platforms to the world. I talk a lot, but without MESS itself, there would absolutely be no JSMESS.

When I started working on this project, elements inside the MESS developers were not pleased at the idea of a not-as-fast, somewhat strange porting of MESS, especially when some aspects were being lost in the transfer to browsers. Their concerns are valid, so I rush to say that if you see something wrong with how JSMESS does something, chances are very good it’s JSMESS, not MESS. (You should download MESS at their site and check it out – it’s pretty amazing tech.) My hope is that JSMESS will honor MESS by bringing it to many more thousands of people.

A little bit about project management.

I’m not a talented programmer – I use BASH and sit down and get a pencil out when I do a tiny bit of PERL programming to make something “faster”. My attitude is other people do better work, with more thought, and it’s not for me to add One More Shitty Thing into the world that’s been done better elsewhere. So I write stuff that takes the excellent tools people have made and push them into a specific direction that I need for getting the job done.

This turns out to be how I manage projects as well.

There are a number of javascript emulators of machines out there as we speak – JSMESS is not the only one. Some are very mature, and quite amazing, inspirations for the work JSMESS is doing. For example, this is one amazing Apple II emulator, with a spectacular presentation. For the experience of being able to decide exactly what sort of machine you can emulate, check out this Amiga emulator that lets you configure the hardware and features (click on “config”) before you run anything. I mean, isn’t that amazing work?

What JSMESS has over these others is what MESS has over most single-machine emulators – a sacrifice of exacting recreation and bespoke experience with the ability to emulate many, many machines – hundreds at this point. For example, MESS has started the process of emulating the Ensoniq Mirage, a synthesizer! Why not? It’s a computer, after all. And as JSMESS grows, it will encapsulate more and more technology, maybe even everything that has a set of chips in it. So work done to port MESS to Javascipt (and whatever open cross-platform technology comes after Javascript) is a hell of a lot of bang for your buck.

(By the way, running Disk Drive Utilities in an emulator makes me feel like the program is Neo and I’m the Architect. “Your first question, while the most pertinent, is the least relevant.” “ARE THERE ANY BAD SECTORS ON THIS DISK.”)

So what I’ve done over the past couple of years is work with volunteers to come up with a framework for porting MESS to Javascript. This has resulted in the work with Emscripten, a method for turning compiled code into running Javascript programs. That took a while, but it does work.

Now, let’s get technical. And where I need your help.

We figured out long ago we simply couldn’t compile all of MESS into a single .js file – it makes every browser explode. Chrome currently has a hardcoded limit of 32,767 variables, and Firefox has a point at which it hits the CTRL-FUCKIT button and drops the mic.

So, instead, we went a different route. Within the MESS system there’s something called a “Tiny Make”, which allows you to build a minimal version of MESS for the purposes of testing. In their case, it generates a version of MESS that only plays the Colecovision. It turns out this “tiny make” is small enough to be converted by Emscripten into a .js file that does everything we want, and which still contains basically all the features of MESS within it. (It even has the internal menu system and configuration!)

Once it was proven that this worked with Colecovision (you can try it out here), it’s “just” been a case of making the rest of the platforms that are properly emulated work. (Here’s a list of all the platforms currently in MESS: 1766 variations of 683 different computers!) Of the 683 platforms, “only” about a hundred are in a ‘good’ emulated status, and of those ‘good’ ones, some are minor variations of a platform, like emulating the Dragon 64 and the Dragon 64+.

So, the high level plan is to make Makefiles for all the “good” emulated platforms (about 100 as of this writing) and put up JSMESS pages for them.

After we have that going, we’ll go back and make keyboard mappings better, presentation better, and so on. We also, in parallel, have the Emscripten gang working to make better and better Javascript speed improvements for the materials (right now speed ranges from 11%-100% of the original platform’s performance). But it all depends on having Makefiles and compiling the systems. That’s our bottleneck right now.

So, what exactly am I talking about here with the Makefiles?

Well, the way that we put together a platform is to compile just the modules needed to make that system run. So, for example, the Colecovision needs the following files compiled to run:

emudummy.c, drivers/coleco.c, machine/coleco.c, plus Z80 Support, plus MCS48 Support.

Once these are all compiled, we have a working Colecovision.

For the Atari 800, here’s what we threw in to make it work.

emudummy.c, machine/6821pia.c, video/atari.c, video/antic.c, video/gtia.c, machine/atari.c, devices/appldriv.c, formats/flopimg.c, formats/fdi_dsk.c, formats/td0.dsk.c, formats/imd_dsk.c, formats/dsk_dsk.c, formats/d88.dsk.c, formats/atari_dsk.c, machine/atarifdc.c, machine/ataricrt.c, machine/atari400.c, plus POKEY support, plus DAC support.

Now, some of these might not be needed, but many are, and when we compile it, we make a .js file that can emulate an Atari 800.

Obviously cleanup is in order down the line, but we’re just in the “get it going” phase, and it’s OK.

Now, our problem is forming the makefiles for the rest of the platforms.

It’s a weird art. I describe it like walking into a rock concert and determining who in the crowd has less than five fingers on a hand. It’s not what MESS was designed for, they do not have a facility to say “just compile this single machine”, (There’s been debates about it for a number of years, but they currently do not do it.)

It’d be great if this was automated somehow, if it was possible to say “show me everything that this emulation of this system needs”. Maybe there is! But we haven’t found it yet.

So instead people are working very hard in the #jsmess channel on EFNet to swim through the code and figure out, as best we can, what’s needed for a given machine. It’s voodoo and strange but the result is emulated computers, so it’s rewarding when it works.

So? Want in?

You’d be doing a lot of good, and if this is the kind of challenge you like, the rewards are immediate and great. Maybe you’ll even figure out a way for us to do it with a lot of scripting help, to make it that much easier. We can dream.

Or maybe MESS, down the line, will add this feature. Who knows.

But I’ve laid it out to you.

Hurrah for emulation!

Categorised as: computer history

Comments are disabled on this post