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

Wednesday, November 13, 2013

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!

Thursday, October 17, 2013

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!

Friday, August 16, 2013

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.