Saturday, April 19, 2014

The Otto Project


I've been trying to figure out the angle I should take on this post, and I've decided to focus on my effort here, rather than a history lesson more than a brief overview about who "Crazy Otto" was... but here's the quick recap...

In 1980, General Computer Corp (GenComp/GCC) was making mod kits for games, including one for Missile Command, and one for Pac-Man. Their Pac-Man add-on was quite innovative.  It brought four new mazes to the game, a new lead character with legs and feet, a new intro sequence, and monsters with antennae instead of ghosts.  If this sounds somewhat familiar, it should.  This mod kit became "Ms. Pac-Man", but before it was Ms, it was "Crazy Otto".  It went through a few steps in the progression, all of which I will cover below.

If you want a more comprehensive history of Ms. Pac-Man, you should watch the video of Steve Golson's presentation "From Crazy Otto to Ms. Pac-Man".  It covers many of the details that I used to create these.  Links to the PAX-2012 and MIT-2014 presentations of this are available at the bottom of this post, and are well worth your time to watch.  All of the sets I present here are directly based on sets that he described, demoed, or showed screenshots of, in an attempt to recapture the history of this iconic video game.

The tools I used to create this are:
  • ASZ80 - assembler (ASM to IHX)
  • genroms - converts IHX to binary rom files, capable of patching over source images
  • Turaco - arcade game graphics editor for MS-DOS
  • Boxer/Dos Box - MS-DOS emulator so that I could run Turaco on my Mac. ;)
  • mspacman.asm - Our well documented Ms Pac disassembly
All of these are available either through online repositories.  Links for all are at the bottom of this post.

None of this is to be used or repackaged for profit.  This is all for educational and historical reasons.  It's okay to drop it into a free-play machine as a museum piece... It is NOT okay to include it with a multigame that you're selling, etc.  Don't be a jerk.

Okay... All of that is out of the way. Let's get into the differences between the romsets, and the patches necessary to make them happen.  I'm going to use the names I came up with for the sets to differentiate them here.  Details of differences and dates were gleaned from Steve Golson's presentations.

Information gleaned from his pre-PAX-2012 talk: (Time magazine photo and rumors)
  • Approximate image of Otto, one frame of 16, no animations
  • Approximate image of monster sprites, one frame of two
  • The fact that this existed at all
Information gleaned from the PAX-2012 talk:
  • Dates of ROM releases
  • Attract sequence differences (Pac-Man, Ms. Pac Marquee, Pac-Woman additional movement)
  • Ghost name differences
  • Crazy Otto exact graphics romset (shown as two screenshots, recreated using Turaco)
  • Monster exact graphics
  • Pac-Woman exact character graphics (recreated using Turaco)
  • Character coloring (for the "alternate" character in intermissions)
  • Intermission structure (short bits of original asm code were displayed, providing a rosetta stone)
  • Lack of monster "eyes" after monster death
  • Death animations for all 
The following ROMsets were released by me (version 05) on April 19th, 2014.  They were playable on a 13" JAMMA test rig (on a Yenox bootleg mspac board) in the lobby of BarCamp Rochester on this day as well.  I switched the ROMs back and forth between the "PZ" set, and the "Pac-Woman" set.

And now I'll list off details about what makes each particular release distinct, as well as some info about recreating it, backwards, from a standard "mspacmab" bootleg ROMset.

OttoP1 - 1981-Oct-12




Character and sprite roms for OttoP1.  These are pixel-for-pixel copies of the original.
The character graphics (top) are based on Pac-Man (Notice the score graphics)

  • Pixel perfect Crazy Otto graphics rom (characters moved around)
  • Pac-Man intro sequence (stationary ghosts) showing their names
  • GENCOMP logo, rather than Midway logo/copyright
  • Remap movement animation frames (characters, stork, baby, etc)
  • Remap of characters and colors for intermissions

This one was one of the more interesting hacks to work on.  A lot of what makes this one unique was to be eventually obliterated by Ms Pac patches.  At first I tried reversing the one patch in Pac-Man that jumps to Ms Pac romspace, where the new "marquee" intro happens, and just let it fall back on original code.  This kind-of worked.  The problem is that it used quite a few of the text slots, which were re-used for the new marquee introduction.  To fix this, I reverted many of the text strings to their modified Pac-Man versions, eg Mad Dog, Killer, etc instead of Inky, Blinky, etc.

The GENCOMP logo was already in the character set, so i just needed to remove the jump to the Midway logo and copyrights, and replaced one of the copyright strings with the characters necessary to draw out "GENCOMP" ("pqrstuv").  I also used a feature of the text render routine that I'm fairly certain no one else uses anywhere else, and that lets you draw the text out in multiple colors, rather than just one color for the entire text string.

Remapping the movement frames was fairly straightforward once I replaced the original math-based routine with my table-based routine.  This is discussed in the section below "Player Sprite Picker".

Remapping the colors, characters, and sprite frames was fairly easy once I was able to use the rosetta from Golson's talk to figure out some of the animation format.  Past that, It was a bunch of experimenting to determine what parameters did what (color, speed, location, etc)  The 'female' character from the intermissions required more attention, since it now uses a different palette color (red), so all occurrences of the color (12 of them) are replaced from 0x09 (yellow) to 0x01 (red).


In Golson's talk, as you can see in the above image, he had a couple of pages of code snippets.  The one above is showing the animation format.  Thanks to him publishing his presentation materials, we can see that up close:

With a little bit of sleuthing, I was able to use this as a kind of rosetta stone, to figure out the animation format.  These animation scripts are used for the intermissions, as well as the introduction attract "marquee" screen.  This becomes more important with the P5 (Pac-Woman) hack below.

For the record, here's the above code chunk, but in the mspac.asm disassembly project, showing that we have a better grasp on how these scripts work.

OttoP2 - 1981-Oct-20




The graphics roms for P2 are similar to P1.  The sprite rom (second) is identical.  The character rom (first) is upgraded to the MsPac version. Notice the marquee graphic instead of the scores in the character rom.

  • Everything from P1 except for:
  • Marquee intro sequence, with "Bonnie" instead of "Sue"
  • "MIDWAY MFG. CO" with Midway Logo
Replacing "Sue" with "Bonnie" was a simple text replacement.  Same with the Midway logo.  The year line was removed from the final product, and the other line was just moved down, and changed to the text seen above.  Nothing really major.  All of the guts of this was accomplished in the P1 variant.

OttoP3 - 1981-Oct-29


  • Everything from P2 exept for:
  • "(c) MIDWAY MFG CO"
  • "1980"
Again, this was just further text changes and tweaks. Nothing major here.

SuperP4M, SuperP4G - 1981-Oct-29

   

This one signifies two different graphics rom sets with the same code underneath it. "P4M" specifies the version with Crazy Otto Monsters, while "P4G" specifies the standard ghosts.




For this version, the character ROM is basically the same as P2 above.
I switched the layout for Super Pac0Man to be closer to the Pac-Man layout.

  • Graphics Rom is closer to Pac-Man than Ms. Pac, to retain the Pac-Man death animation
  • Many similarities with P1-P3
  • Copyright string from P3
  • Game and character names on marquee introduction changed to "Super Pac-Man"
  • Character sprite table for movement and animations changed to Pac-Man
  • Stork and baby sprites in the table were also remapped
All of the changes here were explained in previous sections.  The character movement table was used to tweak the frames of animation to the Pac-Man standard.  The death animation frames were remapped to what Pac originally had.  Also the color of the "female" for the intermissions was retained as red as in the above, but is now a red Pac-Man puck, rather than an Otto with legs (AKA "Anna").

WomanP5 - 1981-Nov-12






The Pac-Woman set is based on Ms. Pac-Man.  The orientations for the death animation are the same as in the final MsPac.  I've included this in yellow so you can see the woman graphics appropriately.  The red/blue/white version is included for comparison with the above examples.

This one got a bit interesting. Golson didn't have any demonstration of this other than a screenshot of "Pac-Woman" in the graphics ROM, and the intro screen animation.  I interpolated this up from what I had for P3, as well as putting her in place of Ms. Pac-Man in her romset.  He even said that there wasn't a playable version of the ROMs that existed... which makes my P5 set even more interesting, since we can now actually try it out.
  • Ms Pac graphics rom with "woman" in place of Ms. pac
  • other character in animations was Pac-Man, like in the final version
  • Animation frame indexing changed from Ms. Pac to use the tables, as explained above
  • Additional animation added to the intro sequence
Since I now knew most of the animation format, as explained earlier, I was able to tweak the animation segment table to point to a new section for Pac-Woman's introduction.  It does the same thing as before, where she walks in from the right side, and stops in the middle of the screen.  But from there, she turns and moves down a little bit.  I did a bunch of tweaking to the speed, distance, and ending frame to try to make this look as much like the demonstration video as possible.

He stated that this version was abandoned due to the fact that when she's moving away from you, it's easy to confuse her with the red ghost.  And he's absolutely right.

From this stage, they generated a slightly different character, again with a bow on her, and she became the Ms. Pac-Man that we all know and love.

OttoPZ




The PZ variant brought forward a bunch of problems.  The main screen needed to have the monster graphics, as well as both logos and the marquee for the Pac-Man and Ms. Pac-Man introduction screen.  The sprite rom is basically the same as the above P2 version

This one is a multigame version of P1-P3, plus an additional fictitious mode not based on any single romset.  It also has additional patches for playability.  You select at startup time which variant (P1, P2, P3, PZ) you want to play as well as whether you want the fast or regular variant of it.  Once you pick that, it behaves like any game above.

While it's running, holding P1 and P2 start and pressing the joystick up "drops a quarter".  Holding those and pressing the joystick down resets the machine, so you can pick a different variant.

This one is perfect for your home arcade, MAME machine or other emulator.
  • Switchable Pac-Man intro and Ms Pac-Man marquee intro
  • General playability of P1-P3 above
  • Fast mode selectable at bootup time too
  • PZ mode also selectable - Ms Pac marquee intro, with GENCOMP logo.
This one got a little complicated.  In P1 above, I was able to just swap out the Ms Pac text table and restore the Pac-Man one.  I didn't have that luxury this time, since we needed the Ms Pac text table to be intact for the P2, P3 and PZ versions of the game.  I implemented this by hooking in to the actual text rendering routine.   It skips out and goes to my own routine which checks to see if the current game is P1.  If it is, it uses a reproduction of the Pac-Man table, but out in my memory space, and with a few strings restored to the OttoP1 versions.  This one has the original P1 strings, rather than the re-used/remapped strings that are used for the Marquee introduction.

One other modification done in this patch is the check for if the game is trying to render string 0x13 (copyright) or 0x35 (copyright year).  Since each variant has different versions of these, the routine uses the variant number as an index into its own string table, and draws the appropriate-looking text to the screen.

This does get into something though.  How do we know which game and variant we're playing. We need to store it in RAM somewhere nonvolatile.  We can pick someplace unused, but it might get used and we haven't figured out the documentation yet.  Or we can use a trick that I figured out while working on a multigame Ms. Pac a few years ago.  The stack pointer always starts at 0x4fc0, and works down from there.  Nothing ever  goes above it other than sprite registers.  So, if we just patch the game code to start the stack pointer down a little bit, we have a few bytes that we can use for our own storage.  

The test for the coin drop and reset hack was hooked in to the routine that checks the coin slot switches.  This gets called often while the game is running, so it seemed like the most comprehensive place to insert our routine.  Before it checks the coin slot switch, it will check to see if P1 and P2 are being pressed.  If the joystick is also being pressed up also, we "drop a coin", and if it's pressed down, we reset the machine, so that the player can pick a different variant to play.

This set also drops the "jumble of characters" standard MsPac startup tests. 

All of the patched romsets mentioned in this post are available through links at the bottom of this post.

Common patches applied

There are a few patches that got applied to just about all of the sets in one way or another.  I didn't want to change any of the gameplay behaviors, so I didn't fix the killscreen at level 240ish.  I also didn't apply the "Fast" hack to any of these sets, since I wanted to reproduce the original gameplay, not a "comfortable playable set". If you want that, use the "OttoPZ" multigame, which is tweaked for general "daily" use.

Memory Mirror Fix

First of all, due to nothing being mapped in memory space above 0xAFFF, writes to those locations map down to lower memory.  That is to say that writes to 0xB000 will acutally occur at 0x4000.  The emulators do something weird with this, and the writes disappear into unreferenced 'ram' space.  This is a problem because the text rendering routine (at 0x2c5e) does something weird with it.  You call this routine with a number, an index into a list of pointers to text structures.  The first item in the text structure is the offset into video memory that the text should start.  The upper two and lower two lines use a different arrangement of bytes, so they need to behave differently.  This behavior is signified by setting the high bit (0x8000) on the offset.  Well, if we now have text that was supposed to be at offset 0x00FF, but it is in that region so the high bit is set (0x80ff).  This offset added to memory space at 0x4000 produces 0xC0FF as the starting location.  In real hardware, this is fine, since the high bit is not connected, so the write actually happens to (0x4000 + 0x00ff), but in emulators, it actually happens at 0xC0FF.  There's a patch that fixes this -- it masks off that high bit when adding in the offset to the video base pointer.

Player Sprite Picker

Another patch standard on all of these is replacing the original function that determines what sprite to display for Pac/Ms.Pac/Otto.  The original did some sort of weird math to determine the sprite number.  I replaced all of that with four hooks into my code that loads the appropriate four-entry table (four hooks; one for North, South, East, and West.)  This code actually fits over the original code, without needing any extra space... in fact, it's smaller and more efficient than the original at 58 bytes instead of 81 bytes... plus, and more importantly, it's MUCH easier to hack in different sprite characters for different graphics sets, which I needed to do.  I'm actually kinda surprised that Otto/Msp didn't use a table for this.

Splash Intro Page

One obvious modification is that all romsets have a splash screen on startup. I didn't want my reproduction sets to be mistaken for the real thing, should it ever be released.  At the end of the startup tests, just after the test grid is drawn, it is cleared, and then my own routine occurs.  This one has its own text string table for the standard text routine at 0x2c5e, so as to not need entries in the standard string table.  It will draw out info about the romset, my email address, and after a moment, it prompts the user to press a button (or move the joystick.) (The "clear screen" routine was also re-added as a patch, since the original wasn't easily callable.

Links


NOTE:  I pursued this project on my own, using only publicly available information.  No direct contact was made during development by anyone involved with GENCOMP nor Midway nor Namco.  This is meant to be a historical/educational project, not for profit.  The use of copyrighted materials is covered by fair use, as this is for educational use.  It is fine to use this for museum-type displays, but not included in a multigame that you're selling.  Don't be a jerk.

NONE OF THESE WORKS ARE TO EVER BE DISTRIBUTED FOR PROFIT, EITHER ALONE, OR REPACKAGED. 

JAMMA test rig box (Part 2)


I decided to package up my JAMMA test rig so that I could demo Crazy Otto at Rochester BarCamp for today.  My design was basically a box that would house the entire thing, with a nice control panel for player 1.  As you can see in the above image, I have the A/V cable going to an external monitor.  Broken out on the box are player 1 and 2 start, coin 1, and player 1 controls - joystick and 3 buttons.  On the right side of the box are the three "coin box" controls -- Test, Tilt, and Service, for testing those functions of the board.  Also on that side is a nice handle to help it be portable.

This is a continuation of part 1, where I updated the AV connections of the rig.

This is about the extent of blueprints I have for this.  I knew I needed 14" depth for the monitor, and that it needed about a 2" rise from the back to the front to put it at a good angle.  I wanted it to be 18" wide, and 24" deep.  That would give enough room for a game board inside of it, as well as for a decent sized control panel.


I started by cutting a sheet of plywood I've had in our garage for a while.  I also built the control panel using spare parts I had.


Some standard microswitch buttons, and a nice ball-top leaf-switch joystick.
The basic construction is that I glued some cleats on the inside of each side. Then the back, bottom, front and control panel will be screwed to it.  After that, it looked like this:

I also cut and drilled a small metal bracket to hold the power supply in place, which you can see in the above.  The coin 1 button on the front has a 12v light in it.  The old P2 controller is still attached to the JAMMA rig, in case I want to test/play 2 player games.  You can also see the 1 1/4" fine thread drywall screws holding it together here.  From here, the only change is that I painted it, stinking up our garage in the process. heh.  The top lid hooks under the control panel, and has a cleat in the back to keep it from sliding off the back.  There's a single screw to hold it in place, and to let it be carried withot the contents falling out.
The great thing about this thing is that it's easy to tote this thing around to play/demo games and such.  It takes two trips since the monitor is cumbersome, and the box itself is pretty heavy, but it's SIGNIFICANTLY easier than toting around a full arcade cabinet.

For reference, here's the JAMMA pinout standard:  (Most games since the late 1980s use this or a variant of it -- for example, Neo Geo adds additional buttons on unused pins, Rampart uses a trackball on the joystick pins, and Mortal Kombat has additional buttons on another interface harness.)
The power and ground at the top portion are wired directly to the old PC power supply.  Coin counters and lockout coils are not wired to anything.  The speaker wires are broken out to a RCA plug, and the Video (RGB,Sync) are out to a DIN connector, as seen in the previous post.  Service, Tilt, and Test are wired to the three switches on the side of the box.  Coin switch 1, and the two start buttons are on the control panel, as are all of the 1P controls (on the right).

Friday, April 4, 2014

Sparkfun Arduino Day / SD-Arduino device

Sparkfun had their "Arduino Day 2014 Sale" this past weekend.  Thanks to their sale, as well as an additional $20 off thanks to Reddit Gold ($4 for one month), I was able to get a whole lot of stuff at a really good price.


So here's what I got:

  • Arduino Uno R3 - I wanted a modern board with the 32u4 on it, for doing USB device enumeration type of stuff. My first thought is to put it on my C=64 keyboard, replacing the old Arduino Serial i've got on there, and turning it into a real HID keyboard.  That could be really neat.
  • Two Arduino Pro Mini 3.3v - For future projects, including a super small SD interface (below) And for $3, it's a no-brainer.
  • Two Arduino Pro Mini 5v - For future projects. Again. $3? No questions there...
  • Two soft-power switches - I need one for my Lego RCX/Arduino project, and I figured it'd be nice to have a spare for another project.
  • 5v-3.3v level converter - I've modified my old Sparkfun SD shield, which did not have level conversion, using resistor networks, and that was always a variable.  For the next time I need 3v-5v conversion, I have this thing to use, in my toolbox.
  • Pack of LEDs - because why not. I needed to pad my order to $50 to be able to use the $20 off reddit coupon.
  • Bunch of male and female headers, since I always seem to depleat my supply of these.  Useful thingies.

One of the things I wanted to do with the 3.3v Pro Mini was to try to make a serial-sd device as small and as inexpensive as possible, for a serial-based storage device and SD management shell project.  I did the trick of wiring up an SD-MicroSD adapter to the Arduino.  Since they're both 3.3v, i didn't need to do any conversion, so it's directly hooked up.


It was pretty straightforward wiring here. +3.3v to one pin, ground to two pins, then four data lines. Easy stuff.  The only nonconventional thing I needed to do was to wire up the FTDI connector to the RAW power input, rather than directly to VCC on the board.  My FTDI interface boards are all 5v, so that would kinda fry things.  The short red wire jumper over to the RAW input on the board means that it all gets regulated down to 3.3v, and everybody is happy.

Here's the wiring diagram:


The fun thing is, that it all fits inside of a SD Card storage case pretty neatly. (Well, not including the FTDI interface.) 


I figure that I can eventually work this in with a 2032 Lithium cell holder, RS232 adapter, and shove it into a DB-25 shell, for it to be a tiny "plug into serial port" storage device for my Tandy 102, Amiga 1000 or some other classic machine.

Friday, February 7, 2014

Updating my JAMMA test rig


Many years back, I hooked up a spare JAMMA harness to an old PC power supply, a monitor and some repurposed joystick pads.  (JAMMA is a standard connector size and pinout to hook up arcade game boards into arcade cabinets.  Most of my arcade game boards are either natively Jamma (Mortal Kombat, Klax, Block-out) or I have adapters to hook them up using JAMMA.  (Dig-Dug, Pac-Man, etc)).  One board that I've been using with it recently is a knockoff Ms. Pac-Man board, seen in these photos.


The harness/rig I have was always kind of a hack.  The video and audio wires terminated in a small box with some knobs which were meant to attenuate the signal but never really worked right.  The power switch was on this cord that came out and was weirdly fastened to the side of the power supply.  I decided to clean this up while at Interlock for open night.


It turns out that I happened to have the right 6 pin DIN connector for this old RGB monitor (basically a Commodore Amiga 1084 clone).   So I wired up Red, Green, Blue, and Ground directly to the correct pins on it.  JAMMA spits out composite video, but this monitor takes in Horizontal and Vertical sync.  I knew that some monitors would take in composite sync on their Vertical Sync line, so I tried that... and it worked! Huzzah.

The only video issue now is that the game boards put out video that's slightly too hot/too high a voltage, so I should put attenuation resistors inside the din connector or something...

Even though the JAMMA interface spits out amplified audio, I decided to hook up an RCA plug on the audio lines anyway, to plug it into the line-level in on the monitor.  As long as I'm careful it will be fine.


And here it is being driven by my Yenox Ms Pac-Man board with the "Horizontal Ms Pac" rom hack.You can see the power switch sticking out of the side of the power supply there.  It's not the most optimal thing ever, but it's substantially cleaner than before.  Perhaps I'll replace that switch with a nice carling switch in the future.  I'll need this test rig for the next task, which is fixing the audio on this board.  It sounds horrid...

This was originally posted on the Interlock blog on January 30th, 2014.

Tuesday, February 4, 2014

Repairing the audio on a Pac-Man arcade board.

I got this knockoff JAMMA Ms Pac-Man arcade board many years back.  It's got two ROMs instead of the authentic board's 6 (9 for Ms Pac), and is substantially smaller than the "real thing".  The only issue is that the audio is poor... REALLY poor.  It makes sounds but they're... wrong and noisy.


I took over some desk space at Interlock and got to work.  (I should note that the beverages you can see here are other people's, not mine. ;)

I traced the audio circuit on a real Pac-Man schematic (seen on my laptop's monitor), and buzzed it out on the Yenox board to try to corrolate the two.

I had to trace four similar paths from a quad flip-flop, through a quad bidirecional switch, to the audio output.  It got really confusing at times, and took me probably a bit longer than it should have.  For the most part, they were pin-for-pin correct as far as how they were wired.  These chips have the same device (eg, a flip flop, or a logic gate) repeated 4 or 6 times.  In some cases here, the Yenox board had a different one of these devices hooked up, which added to the confusion.

This portion of the circuit uses 8 resistors to make a digital-to-analog converter. These generally work by having different resistance levels, usually something like multiples of eachother, eg,  10k ohm, 22k ohm, 47k ohm then 100kohm.  I traced out all of the lines on the Yenox board and I found out that not only were the resistors in the wrong order on the board, but they were also wildly wrong (47 ohm instead of 4.7k ohm), which you can see in this table I made:



You can see these resistors here on the Yenox board, right next to the JAMMA connector.  They start from the left with R1 (my notation.)  The printing on the board completely matched the resistance values that sat on them, so it's obvious that the engineer who made this board seriously screwed it up in the design stage.


I replaced resistors R3 - R7.  I put them in with the gold band closer to the JAMMA connector, rather than the other way around.

And now it sounds near-perfect.  There's a little bit of popping left, but I was getting tired and decided to head home for the night.  I'll hook it up to an oscilloscope at some point and see if i can figure out which line is causing problems.

For what it's worth, I also did the same as this on the video path DAC, seen in the above picture as the next three groups of resistors.  In the above, the group of four and then the group of five are for audio, then the next group of three is for the "red", next three for "green", next two for "blue", and the remaining two are for the sync.  Again, there were some 47 ohm resistors mixed in, and notice two of the three in the "green" section are identical (red-red-brown)... which is surely wrong.  Color is now perfect on the board too!

This post originally appeared on the Interlock project blog 2/2014.

Thursday, January 30, 2014

The Otto Project: Notes and Planning...

Introduction

Many years ago, after hearing about "Crazy Otto", I've wanted the ROMset so that I could play it.  Crazy Otto was a hack/modification that GenComp (General Computing/GCC, a group out of MIT) made.  It was a board with a couple of roms that sat on a Pac-Man board, and gave the game a few updates; four maps, multicolor maps, smarter enemies, cut-scenes between some levels... If this sounds familiar, it should.  After various events, Midway acquired it and it was rebadged as "Ms. Pac-Man". Mind you, it went through a few variations, namely Super Pac-Man, Pac-Woman, and Miss Pac-Man... more on those in another post.

I recently decided to pick this project back up, mainly because of a bunch more info about Otto hit the internet in 2012.  Some design docs, screen grabs from various incarnations of the game, the graphics set, have all been released, but in modern formats... mainly Steve Golson's presentation at PAX 2012 as well as a very recent presentation at MIT. From these, as well as his presentation materials from them (PDF, MOV, etc) I am able to get a lot of information to dive back into this project.  He has also said in the MIT talk that he will release the ROMs when Namco releases ROMs for Pac-Man... which pretty much means "never", so my recreations are probably the closest we'll come to playing it in our own arcades...

My Previous Effort

I had started to work on this a few years back, going completely on the one screenshot that existed, which was from Time magazine.  The photographer apparently found one of three Crazy Otto machines in the country, out of 50,000 machines.  Here's my attempt at reproducing the graphics ROM based on the screenshot.  You'll be able to compare this with the final version, showing how close I got it. (spoiler alert: not very.)

Pac Man scuttles about maze, eating dots.

Planning

After seeing the material that has come to light, I now have to answer a few questions to understand where I'm going to take this project.
  1. Should I put some sort of watermark in the ROMS/on the screen to indicate this is a recreation?
  2. Which version of Otto should I reproduce? The earlier or the later version.
    1. Earlier version had different names, and used the Pac-Man attract screens
    2. Later version had differenter names, and used the Ms. Pac-Man attract screens
    3. Graphics-rom only hack, using Ms.Pac program roms.
  3. How accurate do I want to get?  Should I make my graphics ROM identical to Otto, requiring more code hacks, or should I make it more convenient to implement, but less binary-accurate?
  4. Do I want to make it require bootleg hardware, or figure out shoving it into an authentic Ms.Pac board?
I'm going to answer these questions now...  (I wrote these questions about two weeks ago, before I started on the project.  I'm going to answer them now, based on the acutality of the products produced.)

  1. 1. Yes.  The program ROMs have an indication in them that this was a recreation made by me.  On top of this, the startup routine displays a message stating which recreation it is, what date it was released on (as per Steve Golson's talk), and contact information for me.  It also requires that the player press a button or move the joystick to proceed into the game itself.
  2. Due to the way the animations frame sequences were to be stored (compared to the final MsPac -- moving North vs moving South required different sprites) It was impossible to make a graphics-only romhack.  So, the versions chosen for the project are:
    1. "OttoP1" 10/12/1981 - Pac-Man attract sequence, Otto graphics pixel-perfect, GENCOMP
    2. "OttoP2" 10/20/1981 - Ms. Pac-Man attract sequence, Midway copyright.
    3. "OttoP3" 10/29/1981 - Same as P2, but with a slightly different Midway copyright.
    4. "SuperP4M" 10/29/1981 - Same as P3, but with Pac-Man instead of Otto
    5. "SuperP4G" 10/29/1981 - Same as P4M, but with Ghosts instead of monsters.
    6. "WomanP5" 11/12/1981 - Same as P3, but with "Pac Woman" graphics
  3. All romsets were started with the graphics ROMs, adjusting animation sequences, sprite indexing, other patches to accomodate the layout of the graphics ROMs.
  4. It requires bootleg hardware.  In MAME, it uses "mspacmab", the one with "boot1".."boot6" rom images. 
That all said, the next post will have screenshots, links to ROMset downloads, and further explanation of all of the patches required to make this work...