One Last Bit on JSMESS for a While — August 19, 2013

I know, three postings in a row is a bit much.

When I get into a topic, I keep going, just never stop. It’s the kind of mindset that can end up with something like the BBS Documentary – just one guy slamming away at getting things done, day in and day out.

In this case, I’m in much better shape, because I’ve got some great people helping me – Vitorio and Justin are, between the three of us, this unstoppable force of figuring out what to do to get things running.

After I started to understand the nature of the makefiles, I wrote some scripts that would generate better formatted ones, including commented-out options that might be used. It saves a lot of time. I also wrote a script that, given a string, returns all the potential modules with that string. So, everything became easier.

So we added nearly 50% more platforms within 48 hours. Yeah, we’re starting to get the hang of this.

Now things start getting to the next level.

MESS emulates roughly 1600 machines. Of those 1600 machines, roughly 600 are unique. Of THOSE 600, the MESS term internally rates their state as to how functional they are. Apply that and it’s (again, roughly), 250 platforms that are currently emulated properly in MESS.

(What of the other ones? Some are skeleton drivers, layouts that are awaiting work, or they’re lacking some aspect that hasn’t been reverse engineered, or just suffering from people excited to do that deep down assessment needed.)

Of the 250 platforms, we should make some subset of them work in MESS. Some, in my mind, will be relatively simple, like emulating the Atari 400 (we’ve already got the 800 working and they’re similar hardware). Others, like the Macintosh family, are notably more difficult. But some are just not the best to go for in a JSMESS 1.0 sitation.

Ah, JSMESS 1.0. How I’ve dreamed of you.

So, from those 250 platforms, we’re probably looking at, oh, 30-40 of them for a 1.0. Might be more, probably won’t be less. A gaggle of computers emulated and in javascript versions for the very first time!

One of the issues is speed, and the excellent Emscripten team is looking at the JSMESS routines and determining where speed can be boosted. in the transfer to Javascript. We know the ability to hit 100% of the emulated platform is in there, and now with so many platforms to use as examples, they can start finding common boosts and improvement. I have great faith in them and I’m happy to have JSMESS be a stress test for the next generation of Javascript programming.

Assuming the speed gets shored up, the next problems resolve around the keyboard interaction being subpar, because it turns out the keyboard interrupts for browsers are significant. It’s an entirely fixable problem – someone just has to go in and reset the keys and make a configuration file better suited for being in a browser. I’m sure that’ll happen soon. Obviously consoles are easier than computers – less controls to map.

Next comes the packaging. I’ve given thought to this. Here’s my rough sketch.

I’d like it to be similar to JW PLayer. Not JW Player as it is now, as a business with the demand for your e-mail before you can get a free copy of it, and with commercial licenses. It’s obviously a little Adobe wannabe and I’m not talking about that.

When JW Player first came out, it was a pretty perfect little audio/video player for a website. You got the package, and you could put JW Player right into your website with little effort, with all sorts of little settings for your needs. Need it to just have a single song in there, ready for someone to click? Template for that. Needed it to play an album? Got a template for that. Video player? Got it.

Like I said, JW Player got all business-y and it’s got licenses and a whole bunch of things now, and that’s fine – but the core original approach of giving people tools to add audio and video to their sites, that’s what JSMESS is for computers.

I see a set of templates where you can say “Put up this computer running this software”, or “Put up this computer with a drop-down menu for these software packages”, or “Put up this computer, twice the size, with a set of options selectable along the right side.” People are good at templates. I have faith we can make a set that will work nice on a page.

The nice thing about emulators is they sell themselves, once you see them. When I put up a link to the JSMESS ZX Spectrum emulator, even though I’d been putting up links to the other platforms, a range of people got really excited about it. For them, that was the selling point – a ZX Spectrum in a window. Same to the Sam Coupe crowd when that appeared. For these groups, once they see “Our favorite home computer in an embedded window”, the debate is over and shifts to “when can I put this everywhere?”

As of this writing, the loader for the JSMESS homepage is very simplistic, and meant to be flexible across all the platforms. I think with some effort, elegant and more helpful code sets can be added. I think we’ll revise things and make them easier to use, and we’ll start seeing these things popping up in weblogs and websites in no time, after the distribution of JSMESS 1.0 comes out. It’ll be great.

And the aftermarket! People taking it and adding features, customizing the templates, and finding bugs – they’ll be welcome addition to making it better.

So, one last thought about this, before I turn to the rest of the things I’m working on.

All JSMESS is, is an attempt to take MESS and port it to another language, in a way that translates as much of the MESS quality and experience to the new language. As it turns out, this language (Javascript) is an open-source implementation that works across most known browsers and therefore most hardware platforms, including mobile, desktop, and dedicated systems.

In doing this, it brings emulation of this sort to a much, much wider audience, makes it accessible to education and communities, and turns computer history into an embeddable object.

It’s powerful, but also limited and simple. It is difficult work to port MESS to Javascript, but it’s a miniscule sliver of the effort put into maintaining MESS itself, to seek out hardware, do the legwork of finding how to emulate a system, and determine the thousand, maybe million little weird aspects of these systems for the use of generations to come. That’s the effort to respect, that’s the people to applaud, before JSMESS gets any of that.

I hope this effort will bring attention to the MAME/MESS projects, the kind of attention where someone, seeing an end-to-end advantage (if they help MESS, then the embedded computer object on their website gets more accurate), gets right in there and gives MESS the deep research and information they need to capture accuracy more.

More than once in this, someone has snickered and gone “yeah, but do they support the [whack-ass peripheral] on [platform]?” And more often than not, of course they have. These people care about this. It has burned some of them out, it has made some of them rage, but they believe in it.

It’s something worth believing in too.

To 1.0!

Share this:

One Comment

A few thoughts that might help (your build/link problem is the sort I like hacking on, but unfortunately I have negative free time at present):
– the “academic” way to solve this problem (“what do I need to compile to build a working binary for this) would be to use a static analysis tool to, eg, trace possible call paths (“from this function give me the transitive closure of everything that could be called directly or indirectly”). Unfortunately I’m not aware of an good open source ones to recommend which would give you this transitive closure anywhere directly.

– one hacky approach would be to use the C linker to figure out approximations of call dependencies, by compiling _everything_ into individual .o files, adding _all_ of them into something like libmess.a, and then using the C compiler to link a $MACHINE_NAME executable with the main.c file _with_debug_symbols_ still included. Then strings/grep for the functions linked in, and where they came from (the debug symbols should have function/source file/line number information). That should be complete, if a bit slow. But automatable. (You may need some preprocessor hacks to prevent, eg, all the main() functions conflicting in the library. But that’s pretty easy to automate.)

– another hacky approach would be to do dynamic analysis, eg, using something like gcov (test coverage program): build normal MESS executable with gcov support. Run executable. Go directly to machine you wish to discovery, and run things to exercise its features. Exit. Run gcov and get a list of functions/source files covered. Try to build with those source files. This will dependant on the feature you exercise, so you’ll only get 80-90% there on the first pass, but hopefully “the rest will be obvious”, especially if you try to get the C compiler to link it first with the files you found and go find the things it complains it doesn’t have. This one is possibly faster for a handful of machines, but tricky to automate unless MESS happens to have a really good per-emulated-machine test suite…

I’m impressed at how much you’ve managed to get going. Especially considering the multiple layers of emulation. As I said years ago, it’s amazing what you can do by throwing a mutli-gigahertz machine at a problem and only expecting megahertz performance…