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...

Cheap contiuity tester

I am working on restoring/repairing a Macintosh SE/30 machine, and I'm at the point now where I'm debugging why SCSI isn't working on it anymore. I found some schematics for it online, as well as some troubleshooting guides.  The project ahead of me was to 'buzz out' all 44 pins of the SCSI interface chip to points elsewhere on the board, to figure out why it's failing.  I knew I'd need a good continuity tester for this.  I have this feature in my multimeter, but I didn't want to hear that annoying beeper... I wanted a visual response instead.

I had toyed with the idea of using an LED Glow Stick flashlight, like I used for my "Sonic Screwdriver", just add in two wires going to test points.  I swung by the auto parts store, and instead saw this there for $10:

I decided this was a good starting point.  The light up portion was originally made for an incandescent screw-in type light bulb, but has been replaced by an LED, which doesn't work awesomely at glowing that end, and the alligator clip should be something a lot more precise, so those are the two things I decided to address.

First thing that had to go was the alligator clip end.  This is going to be touching into very fine-pitched electronics, so I needed something more precise.

I snipped off the clip, and soldered the wire to a plain old straight pin, and then snipped off the pinhead. To make a handle of sorts, and to shield the exposed wire, I just used some heatshrink tubing.  I intentionally used too much heat shrink to stiffen the end of the wire and give me a place to grip it.

The LED in it was a bit... lacking... So I added in a bit of reflection using some metal foil tape, to try to let it glow better when it's on too.

The end result is pretty simple, but very useful.  That pin can really get onto any of the densely packed pins I need to test, and pierce through any oxide or muck on the joint.

Knowing now how easy it was to make the "probe" here, and how well it works, I think I might go back to my original idea of using an LED Glow Stick flashlight, and just tapping into the circuit to add in two probe wires, terminating in these pin probes.  In retrospect, I already had everything I needed before I bought this thing. Heh!

Visualizing ROMs 1: Diode Matrix ROM

As a part of my BarCamp Fall 2013 presentation about visualizing ROMs, I decided to build a Diode Matrix ROM at Interlock this week. I should note that this is not practical, but it was a fun exercise in making physical data.

To start with, ROMs come in a few different varieties.

The most well known are EPROMs.  These are ICs with a quartz window on the top, through which you can see the storage array on the silicon.  This window is used to erase the ROM with ultraviolet(UV) light, then you can use a programmer to re-burn the ROM with other data.  It remains mostly non-volatile, unless it's erased with UV light again, via an eraser or by leaving it in the sun for a couple weeks.  These kinds of ROMs are useful for when you need to reprogram the content, or if the production runs are relatively small. These are often used in video arcade machines, as the program or graphical data might need revisions, and production runs are not in the "millions".

Another kind of ROM is the PROM, which is progammable once. It does not have a window on the top, and cannot be re-erased, as the bits are stored by actually burning out links on the IC.

Yet another kind of ROM is the Masked Rom. (Not related to Zorro or Mask Man.) This is not programmable at all, as its data is formed in the IC fabrication process.  Many mass-produced devices use this, like BIOS ROMs for PCs, Kernel ROMs for the Commodore 64, Kickstart ROMs on Amigas and so on.

Another way to produce a ROM is to actually physically build one using diodes at each of the bit positions. This makes for physically large ROMs, but is useful for very small production runs of very small amounts of data. In the past, Diode ROMs were used for boot programs for early mainframes like the DEC PDP-11, and are currently used for model railroading electrical logic.  I decided to make one of these.

Documentation on how to build one is a bit sparse, as not many people have bothered to make one, for obvious reasons. I went forward anyway and "winged it".  I built what you see in this in one evening at Interlock. I will attempt to describe the basic theory of operation in this post.


The data in a ROM is generated when an address is fed into the chip, and an enable line is activated.  This goes into the ROM chip, and activates the data bits at that address.  Those bits are then reflected out to the data output of the ROM itself.

For my example, we will make a 24 pin "part" that simulates use of a 2716 ROM, using its pinout.  We will plug this into my EPROM reader/programmer to dump out the contents.  More on this later...  Due to the nature of this circuit, I will be ignoring all of the address bits above A1, the activate/latch functionality (OE) as well as the programmability of a standard EPROM.

We will only look at address bits A0 and A1.  This means that there are four possible addresses we can use. A0 and A1 from the chip socket are wired into a "demultiplexer" chip, 74LS139. When A0 and A1 are (0,0) the '139 will enable only Output 0.  When they are (0,1) it will enable only Output 1, and so on.  Since the upper bits are ignored, once this reaches past (1,1), and becomes (1,0,0), we will read it as (0,0) and we will produce the same outputs. This means that our content will repeat over and over again, since I ignore bits A2-A10 of the address lines.

In the diagram above, the upper chip pinout sketched is the '139.  the two inputs are on pins 2 and 3, and the outputs are on pins 4,5,6,7.  The lower diagram shows the 2716 part pinout.  A0 and A1 from pins 7 and 8 go to the '139. Data output from our diode matrix goes to pins 9-11,12-17, to be read by the EPROM reader.

The above is shown in this diagram as the top two chips.  The diode matrix is shown below.  The orange lines are the outputs from the '139 part, as AD0, AD1, AD2, and AD3.  It will output 0v (active low) on only the selected line, and +v for the three other outputs.  Our diode matrix has 8 data bits shown as D7..D0 above.  Those are weakly pulled up to +v.  At the junction of any of the address lines (orange), and any data line (black), a diode can be added to signify a digital "0" as the diode will pull the current from the pullup'ed data line down to 0v.  If no diode is present, it will remain pulled up, tp +v, or a digital "1".  I should note that the values for each of the data pins are 0x80 (1000 0000) for D7, 0x40 (0100 000) for D6 and so on down to to 0x01 (0000 0001) for D0.

We want to output "Hi! ", repeating in the rom, so the four bytes we need to store are the ascii values for these characters, 0x48, 0x69, 0x21, 0x20... in binary form, this is (0100 1000), (0110 1001), (1101 0001), and (0010 0000).  As you can see above, if you look at the first of these, and read across you will see the presence of a diode where a '0' is signified, and lack of a diode where a '1' is.

The above image shows the physical interpretation of this circuit, annotated.  The 2716 connector is in the top right, '139 demultiplexer just below it on the right.  Its outputs become horizontal traces on the back (see the below image) to which the diode cathodes are connected, and the data bits become vertical wires on the front, to which the diode anodes are connected.  The pullups are at the top, connected to a +5v bus at the top. (Note: after this photo was taken, the blue data lines at the top were crazy-glued down to tidy them up a bit.)

The back of the board (kinda) shows the horizontal traces.  Trust me... it's there.  Stripboard isn't always easy to understand by looking at it. ;)

Since the Needhams EMP-10 requires a parallel port, and a MS-DOS based software package, I have dedicated my old Toshiba Libretto 50 only for running it.  It has Windows 95, a 10 gig disk, and not much else.  You can see it running scandisk as it boots Windows 95. Fun.  I could buy a new programmer, but why bother when this works well, and a new programmer is expensive.

So I built this board, and put it into my Needhams EMP-10, and I can retrieve the content out of it.  The notch on the right is so that I can use the latching lever in the ZIF socket.

And here you can see the buffer read in by the programmer.  The physical rows of diodes have become non-physical data inside of the computer. It's sorta like the digitizer in TRON, but not really. ;)

Bonus picture...

The following picture shows when it was not working correctly, before it was debugged.  There are a few things wrong, starting with some accidental shorts on the back tying some data lines together (not shown), but there's also one major issue here, and a bunch of minor issues here which are visible in the following photo.  See if you notice them...

Do you see the mistakes?

To start with, the 3rd data line from the left (D5 or 0x20) is both running to the wrong side of the diode, and is also not soldered to it.  The mistake harder to see is that the top two horizontal rows of diodes are completely not soldered to the data lines at all.  If they outputted anything it was accidental.  This is what happens when you're tired and too quick to plug it in and try it out without visually inspecting it.  Oops!

Update:  This article was featured in Hack A Day on October 18th, 2013.  Hello friends!

My all-in-one Pi

I have a Raspberry Pi, but I wasn't sure how to encase it or whatever.  I picked up a bunch of these 13" LCD monitors from the scrap heap at work.  They run on 12v, and have VGA, S-Video, Component and Composite inputs.  I figured that I wanted to use one as a display for the Pi, so I started with trying to suck 5v of power off of the mainboard inside of it.  After a little probing with a multimeter, I found a 5v and Ground that seemed like a good place to tap.

I sacrificed a micro usb cable to tap directly onto the motherboard.  On the left you can see where I zip-tied it to the frame to prevent strain on the soldered connection.

The cord comes out from an unused port opening.  I added the two screw/standoffs you see on the bottom right.  I should note that I also removed the fan whose grille you can see in the top of the frame.  The fan wasn't needed, and was super noisy.  Next thing to do is to mount the pi on the back of the case.

Huzzah.  Everything fits nicely.  A short composite cable to hook it up and it's ready for use... Only problem was a way to prop it up.  I was going to build some sort of stand for it, but after looking around the parts area of Interlock, I found a broken Dell monitor I had brought in months ago.  I decided to repurpose its stand.

I removed the plastic backing from the upper portion, then removed the mounting plate from the stand.  I added four more holes to line up with the four screws coming out of the monitor (which have a ball joint as seen above) and use those to mount it to the stand.

After assembling it all together, it seems to work nicely.  I've since zip-tied the power brick to the back as well, although I'm not sure I like the way that works out.  The USB and ethernet ports are underneath the stand.  I'm considering moving the pi to be on the back, along the right side rather than on the back along the bottom.

You can also see in the above picture that I have added in a handle on the side of the monitor as well.  It's just the same kind of wire/metal drawer pull as I've used in the past.  It adds a nice carry handle to the project.

All of the ports of the Pi are still easily accessible.

BL-328 Computer: The keyboard

I was going to integrate this into the megapost for BL328, but there was enough here that I wanted to give it its own post.

For a while, I was thinking that I wanted to use a PS2 keyboard for my BL-328 computer.  This would have worked well; being just software serial to receive PS2 messages from the keyboard, and sending down RS232 keys, or just integrating it right into the main board of the device, using the above.  Space was getting tight on the main board, but I could have made it work.

One fateful trip up to Active Surplus up on Queen Street in Toronto, Canada changed that idea.  (NOTE: this is one of the reasons I love browsing there.  I wish they were closer!)

I found this.  It's a Commodore 16 keyboard.  I remember looking up Commodore 64 keyboards at one point, and they were a simple matrix.

Keyboard matrices work pretty simply. You have a grid of wires in the horizontal and vertical.  At each intersection, there's a switch (one key on the keyboard).  To "read" it, you send out a signal on each of the horizontal lines, then read in through each of the vertical lines. If you see the signal on the vertical line, you know that the intersection of that vertical with the horizontal that you sent out the signal on is where there's a key that's pressed down.

I made an interface for this using an old serial Arduino board, a Seeed Studio shield kit, and a bunch of wire. Above you can see the early version of this before I had everything figured out.  The above worked somewhat, but had to be directly plugged in to an Arduino.  I've since added a FTDI header for communications, as well as switching around one line to he header.  On the Arduino boards (and on this board) Digital 13 was broken out to an LED for display.  This interfered with the keyboard scanning, so I had to rewire it a bit.  The topmost red line was swapped down to be just below the bottommost line.  It made the code a little confusing, but it all worked out.

In a testing configuration, directly wired in to an Arduino Pro.  Notice that I'm using a Commodore 64 keyboard instead of the Commodore 16 keyboard purchased/shown earlier.

Detail showing that one rewired line on the controller board.  This is also after I mounted the Arduino, Shield and keyboard on a piece of lexan.  Rubber feet on the bottom, underneath the keyboard keep it nice and sturdy.  This also shows the three-wire serial at the top of the image, which connects it to the host computer.

Hooked up to a test display to get a feel for how it would work.

And as a part of the completed system.  CPU board is in the red project box, with a battery pack sticking out from it.  Keyboard and controller sit on the bottom of the image.  Between the two is the video display module, sitting on its plexiglass monitor stand. I also settled upon a color scheme for the keyboard as well.

Tiny FTDI adapter for the D15 Stepper Motor Controllers

Here's a quick one. I wanted a VERY compact FTDI interface for the D15 devices, that didn't offer any IO pin access, just so that I could try building stuff to the Atmega 168 in there, and chat with it through serial.

Rather than using the cable I made and showed in previous posts, I decided to just do point-to-point soldering of a 6 pin header directly to a D15 connector.

The results are that I have a very compact device to play with.  It's very portable too!

Microphone Mount for my Voice Recorder

I like to audio record stuff, and have since I was a kid.  I recently got a Sony ICD-PX820, which records to MP3 files, accessible through USB, which is super handy.  It has a proprietary database file that contains the time and date of the recordings, and probably some other information. I somewhat recently reverse engineered this file enough to retrieve some information out of it, and made this available through github.

One of my minor issues with it, is that although it does record decently through the builtin microphone, it's mono and of limited dynamic abilities.  I found that I could get decent recordings by using the stereo mic I bought many moons ago for use with my DV camcorder.  The Sony has a mic jack on it, which is perfect, but it only has two gain settings "High" and "Low".  It's enough to get by, until I buy a real portable recorder.

The one problem I had with this setup though is that there was no way to easily carry it.  I decided to make some sort of mounting adapter to attach the microphone to the voice recorder.  The mic came with a clip with a hotshoe/tripod mount on it, as well as a little extension arm which also has the same abilities.   I decided that the best way to take advantage of this was to mount a screw through the case of the voice recorder, and attach the mic to this.

I started by mapping out the best locations for screws. I decided to make two holes, so that I would be able to switch it around if I needed to.  The screws I have, have heads that are a little too rounded, so they force the battery cover up a little bit, but it's good enough for now.

In the future, I'd like to try flatter-headed screws for this design.  I'd also like to perhaps try a 3D-printed thing, which the voice recorder can be snapped into, and the microphone slid into the bottom, to make it more sleek.