Javascript Mess

From Archiveteam
Jump to navigation Jump to search

This is the organizing page for the Javascript Mess Project, an effort to port the MAME and MESS emulators to Javascript. Manifesto and References will be at the bottom of the page, and actions at the top of the page. This entry is currently a work in progress, and more information is still being added.After writing the initial weblog entry and announcement for the project, a number of people have responded with interest. Feel free to use the discussion page of this wiki entry to add your thoughts and questions.

Javascript MESS currently runs Colecovision cartridges well

Functioning Demonstrations

A mock-up of how a JSMESS window might be an informative part of a historical page is on this K.C. Munchkin History Page. The window with K.C. Munchkin running is at the bottom.

Currently, JSMESS works with Chrome and Firefox, recent versions. It has spotty performance elsewhere.

Actions (To Be Done)

  • Create Pre-loader javascript routine for the emulator. Right now, the window just fires off and goes and emulates. It should really have a window where you press a button and THEN it loads the run-time and shows a bar graph, and THEN executes.
  • Create cohesive Makefile for compiling for individual platforms. Currently there are hand-made Makefiles for creating the individual compiled javascript runtimes. They won't scale, and as we add more features, it'll be more difficult to get things done.
  • Add and test more platforms. Game consoles are rather easy but we should really be adding Atari 800, Commodore PET, ZX Spectrum, and other computer systems, for greatly increased supported software.
  • Get back up to date with upstream. Currently we are using a version of the MESS code from circa June 2011, prior to the addition of cooperative multithreading (cothreads) which JavaScript does not support. However cothreads were later removed from MESS so this is no longer an obstacle. Newer versions of the code do rely on later SDL APIs but a lot of work has been done already within Emscripten and on the jsmess_trunk branch of jsmess to deal with those issues. MESS is a very fast-moving codebase so there is a risk of the work required to catch up becoming prohibitive as time passes.
  • Speed, speed, speed

Actions (Completed)

  • Compile MESS with Emscripten Status: Done and it only took about a year! Thanks to all the folks who have worked on it up to this point. The Status on Emscripten issue tracker is currently completed, awaiting further needs from Emscripten to add features or fix issues.
  • Compile Multiple Platforms with MESS Status: Done - we have provably been able to make Javascript MESS emulate a Colecovision and Odyssey 2 game platform, and run cartridges in them. An attempt to do a Commodore PET 2001 has gotten it to somewhat boot but it freezes - more platforms should be added.

Manifesto

  • The goal is to provide a ubiquitous, flexible, comprehensive-as-possible emulator that will appear in as many browsers as possible without installing a plugin or runtime. While a number of emulation solutions exist that allow much of what is wanted, they nearly all require plugins and most are directed towards a single machine or small sets of machines.
  • Currently, the most flexible runtime is current versions of Javascript, a horribly named runtime that utilizes a Turing-complete programming language to provide all manner of applications, effects and trickery to the browsing public. All major browsers support Javascript, and the language also allows support for cleanly informing end-users what is going on if something goes wrong.
  • MESS and MAME were started over a decade ago to provide ubiquitous, universal emulation of arcade/gaming machines (MAME) and general computer hardware (MESS). While specific emulation implementations exist that do specific machines better than MAME/MESS, no other project has the comprehensiveness and modularity. Modifications are consistently coming in, and emulation breadth and quality increases over time. In the case of MAME, pages exist listing machines it does not emulate. [1]
  • The dream/goal is to provide access to computer software and artwork that would otherwise require the user to have the original hardware and software at hand to bring into existence. While nothing beats having vintage, well-maintained computer hardware to show what software "was", it requires advocacy and often physical presence to do so. Games like Pac-Man' or Super Mario have been re-done many times and provided in all manner of online and offline presentations... not so much examples of Wordperfect, Peachtree Accounting, or the Atari TOS. By providing this method of calling in software, historians and academics and the merely curious can get near-instantaneous access to the gist of these early programming works. As a side benefit, people with collections of old software will be more inclined to share or donate their piles of materials knowing that universal access will come shortly after.

Communication Channels

Currently, most communication is done in the #jsmess channel on the EFNet IRC network. If you don't use IRC or just have questions, please mail jsmess@textfiles.com to inquire.

Getting started with the source

Building JSMESS is currently a bit lame because the MESS build process has intermediate steps where it builds tools that process precursor files into .c/.h files which are then compiled. Emscripten does not (easily) support this because it wants to compile all the tools to JavaScript which are then unusable from the command line. So as a workaround for now we are doing a native build of MESS first, then copying over the needed files to a second copy of the source which will be compiled with Emscripten. There is almost certainly a nicer way of doing this!

  • Install Emscripten. You'll probably want to test your setup on something small before going whole hog into JSMESS.
  • Obtain the no_cothreads branch of the source from https://github.com/ziz/jsmess/ into two different folders (say, native-jsmess and jsmess)
  • In the makefile for native-jsmess, uncomment the lines under "compiler, linker and utilities" specifying AR, CC, and LD
  • In the native-jsmess folder, issue make TARGET=mess SUBTARGET=tiny. You may need to add NOWERROR=1 and/or PTR64=1 depending on your system.
  • In the jsmess folder, edit the makemess script to point to your installed Emscripten location.
  • In the jsmess folder, issue ./makemess.
  • The makemess process will eventually die due to missing files. Copy these files from your native-jsmess build tree like so:
 cp ~/native-jsmess/obj/osdmini/messtiny64/emu/*.fh obj/sdl/messtiny/emu
 cp ~/native-jsmess/obj/osdmini/messtiny64/emu/layout/*.lh obj/sdl/messtiny/emu/layout
 cp ~/native-jsmess/obj/osdmini/messtiny64/drivlist.c obj/sdl/messtiny
  • Run ./makemess again.
  • With any luck you should now have a file called messtiny containing LLVM bytecode. Do the following, replacing the --embed-file parameters with appropriate paths to a coleco.zip file containing the BIOS and another file containing a cartridge ROM (or whatever is suitable for the emulated system you are targeting)
 mv messtiny messtiny.bc
 ~/path/to/emscripten/emcc -s DISABLE_EXCEPTION_CATCHING=0 messtiny.bc -o messtiny.js --post-js post.js --embed-file coleco.zip --embed-file cosmofighter2.zip
  • After a (long) wait, you should have a file messtiny.js with the JavaScript code. This code exceeds Chrome's limit of 32,767 variables, so we need to run it through closure before using it:
 java -Xmx1536m -jar ~/path/to/closure-compiler/compiler.jar --js messtiny.js --js_output_file mess_closure.js
  • After another (long) wait, you should have a smaller mess_closure.js file which can be slotted into one of the existing Colecovision demo pages (potentially with the game filename changed).

References

  • A team of Google engineers launched a project to port MAME to their own plugin runtime, NaCL (Native Client, or pronounced "Salt"). The report is here. High level summary: They did it in 4 days of work, pulled out parts that were too intense or time-involved, but still could emulate 75% of the games. The diff was 1200 lines of code. The report is useful for understanding MAME's unique structure.

Posts by Jason Scott about the Project