Showing posts with label roms. Show all posts
Showing posts with label roms. Show all posts

Friday, June 24, 2016

The RC2014 Computer: 1. Emulation


As you may know, I'm bigtime into Z80 computerey stuff.  For the past 20 years or so, I've been hacking Pac-Man ROMs, been maintaining the Ms Pac Disassembly, and have made my own Z80-Pac based programes over the years.

Fairly recently, I got a Kaypro II from a friend at interlock, and it worked perfectly, and looked brand new.  I felt like I couldn't hold on to it... "it belongs in a museum!" ...so I donated it to ICHEG/Strong Museum of Play.  But it helped whet my appetite for a CP/M computer.

Another project I've been wanting to do was to start with a Commodore 64 (I know it's not Z80, it's 6502ish), a floppy drive, some blank disks and a hardware manual and code up, from scratch, an OS.  Start out by making a text editor, assembler, GEOS-like GUI, etc.

These projects recently had an opportunity to overlap, and they all seem to converge on the RC2014 modular Z80 computer.

The RC2014 computer is a backplane-based modular computer created by Spencer Owen, based on the Z80SBC by Grant Searle.  There are modules for the CPU, RAM, ROM, Serial Terminal interface, and so on.  It is available as a kit from tindie.com.  Once assembled, you hook up a serial terminal to it, power it on, and you get a 1980s-esque BASIC prompt onto which you can write your 32kbytes of program.  This is based on Grant's simplified Z80 computer, so there is no off-line storage.

My general plan for the RC2014 is:
  1. Emulation:
    1. Create an emulator for the system to aid with rapid development
      1. also bring my "bleu-romtools" from Google Code to github
    2. Add a serial-based storage solution to the RC2014 emulation to confirm proof-of-concept
    3. Add ROM swap out to the emulation
    4. Add 32k of ram to give a full flat 64k of ram to the emulation
  2. Hardware:
    1. Get a RC2014 kit
    2. Build the RC2014 kit
    3. Make a test ROM to run on real hardware to verify my toolchain is working
    4. Create a new serial card that sits at port 0xC0 (second serial)
    5. Create the SD Drive firmware for the serial arduino
    6. Hack the ROM and Digital IO boards to allow for disabling the ROM
    7. Add 32k hacked RAM to the system
  3. Name: RC2014/LL
    1. At this point, the architecture is different enough and well defined enough that I think a new name for this configuration is in order. I call this configuration "RC2014/LL".
  4. Port CP/M
    1. Create the BIOS
    2. Create the sector-based emulation layer in the SD drive
    3. Boot CP/M
    4. Play Zork


I started out by making an emulator using the Z80 Pack emulation system.  Once I got this running, I realized the limitations of this emulator and looked around and found another emulator that suited my needs better. (I wanted a way to "swap" memory around, which Z80 Pack would not do in a way that wasn't a major hack.)

I created a layer that adds disableable memory regions, and added emulation of the 6850 ACIA serial chip, and threw the 32k RAM BASIC ROM at it, and it started right up, running BASIC!

I added a second 32k of RAM (easy to do when you're emulating it!), and started creating the SD interface, also using the 6850 ACIA for communications.  I then added a port, emulating the IO card, on which bit 0 (0x01), when set, will disable the ROM... So any reads to the low area of memory will read from the ROM.  Whether this is set or not, all writes to that area of memory will actually happen to the RAM... they will just be hidden from reads until that bit is set.

I now have the basics of the RC2014/LL system emulated in software!  I created a boot/diagnostic ROM which can be used for all RC2014 systems which can probe memory to determine type (ROM, RAM, unpopulated), peek and poke memory, In and out IO, and other utility functions for the SD card interface.

Currently, I'm writing the SD card API which I will port to the Arduino Leonardo and SD breakout board which I have ordered, once those come this weekend, I'll shove them into my own serial board and burn a test ROM and see how it goes....

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. 

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

Thursday, January 24, 2013

Tron Arcade Monitor Repair


I won't lie to you.  Having an arcade machine is a lot of fun.  I used to have about 6 of them, but I'm down to two, due to space restrictions and general sanity.  The two that I still have are a TRON Mini/Cabaret, and a generic full-size cabinet into which I can put one of a few game motherboards that I have. (Dig Dug, Mortal Kombat, Klax, Rampart, and a few others.)  But one of the less glamorous sides of collecting machines is troubleshooting and repairing these 30 year old beasts.

I bought the Tron Mini in the late 90s as an empty cabinet.  I was having a difficult time back then finding an affordable Tron board/control set to install, so I instead put Satan's Hollow into it.

Tron Cabaret cabinet with Satan's Hollow - Note the red joystick and white "shield" button instead of the standard blue stick and spinner from Tron.

Over time, I found all of the parts needed including a few tricks to restore this.  When I put the Satan's Hollow boardset in, I rewired/hacked/brutalized the wiring in the cabinet to accommodate SH.  Although SH used the same boardset, the controls were wired differently.  Once I got the Tron board, and realized how rare this machine really is, I re-wired it using a wire harness from a junked Tron machine.  I also found the correct power supply to install, repaired by a fellow collector.  The controls were also out of another junked machine.  Over time, I got the machine as restored as I could get it. 

Tron uses a boardset, three boards connected together, from Bally/Midway called "MCR-2".  It consists of a CPU/Program board, a Video/Graphics board, and a Sound/IO board.  Midway used this boardset for a few games, including Tron, Satan's Hollow, Two Tigers, and a couple other ones.  If you have a ROM programmer (which I do), you can buy one of the cheaper boardsets to use as a replacement for one of the more desirable machines.  Tron boardsets, when I was last looking, sold for about $75-$150.  Two Tigers sold for about $40.  The boardset I have Tron running on right now is a Two Tigers boardset.

When restoring a game, there's a line to walk with respect to what parts to put into it.  This machine has some vinyl veneer on the sides, which are somewhat damaged.  It also has a fair bit of wear on the front edge of the control panel.  I could have tracked down a replacement/reproduction for these parts, but I'd rather keep it factory original.  It's not like the damage is too severe for either issue.  I'm actually very happy with the overall condition....  except for the monitor.

The cabaret/mini cabinet uses a 13" monitor, compared with the full-size's 19" monitor.  The monitor on this one showed a wavy haze, distorting the image a little, and mucking with the brightness across the screen, which you can kinda see here:



I was given a solution about 11 years ago, involving modifying one of the boards in the monitor (the "neck board", which connects directly to the back of the picture tube) but never did it, and lost the parts a few years ago.  I instead bought a "cap kit" from Amusements Plus around 3 years ago, and decided to install it.  The last time I did one of these was in 2001, so it's been some time.  

Love that desoldering iron!  The pump just clears out all of the solder super fast!

All of the caps in the cap kit have been replaced.  Shiny new caps on the board.  Old, dusty, puffy caps in the plastic bag.  I'm not entirely sure why I kept them...

Thanks to the awesome desoldering tool at Interlock, I was able to do this in about 45 minutes, rather than the 3 hours it took me years ago.

The board is mounted into the monitor framework, and reconnected to the picture tube.


Just about all of these knobs needed to be tweaked to get the picture looking its best!

After some calibration of adjusting all of the controls (focus and drive on the flyback transformer, and R/G/B Drive and Cutoffs on the neck board), the picture looked better than it has ever looked before! Which you can't really tell from these pictures, but trust me, the picture is sharp, colors bright, and the imagery is stable. It's like it's a new monitor!

The boardset I had in it at first was the Satan's Hollow with my ROM hack so that it will work as a drop-in for TRON arcade cabinets with no rewiring at all.


Yeah, a horrible high score, but just let me practice and remember my old strategies!

The above pictures were taken before I realized how much dust had accumulated on the picture tube and shroud.  I've since removed the artwork glass as well as the tinted plexi below that, and cleaned off those items as well as the picture tube itself.  That eliminated all of the haze, and improved the picture as well!

Hopefully, I'll get 30 more years of life out of if!

Soon, I need to mount a bunch of UV LEDs in the cabinet to illuminate all of the art work.  That's one of the features of the full-size cabinet that I really miss.

Thursday, November 15, 2012

EPROMs part 2: Success!

NOTE: This article was originally posted over at the Interlock blog.

This is a continuation of a previous article.  Quick summary: I tried to build a device for dumping an EPROM via Arduino, and I constructed a device that had no chance of working.  Oops.

This post will continue where that one left off.  I'll walk through some of the process to hopefully get to a solution that works...


To summarize the overall project;  I want to build a device that will illuminate an UV light-erasable ROM (EPROM) device, and also dump out its contents. I will then take the contents, display them as a graphic, and animate them over time as the bits fade away into an erased oblivion.


When we last left this, the above circuit was what I was going to work with.  The Arduino would shift out a 16 bit address, which will be stored in the 74HC595 serial-in, parallel-out shift registers.  Those would output to the address lines of the EPROM device. The 8 data line outputs of the EPROM then are read in directly by the Arduino.  I started to look around for the parts, and I was planning to buy them from Sparkfun.com, for a very reasonable price.  I was all set to place the order, but then I started thinking about other ways to sample the data, and then it hit me...

In the late 1980s, I had an Amiga 1000 computer (see previous post about restoring it).  We used Macintosh SE computers in High School, and as a result, we bought the "AMAX" Macintosh emulation system for the Amiga.  It was a lot easier to carry a floppy or two, rather than a SE or SE/30 in a plastic milk crate, not to mention that MacWrite was a substantially better word processor than TextCraft. ;)

AMAX consisted of software you run that emulated the Mac's hardware, as well as a "cartridge" that plugged into the floppy drive port of the Amiga.  I remember hearing that they went with the floppy drive port because it was the only appropriate port identical on all Amigas that were available at the time. (Amiga 1000, 500, 2000).

The cartridge served two functions. First, it let you plug in a Mac floppy drive right into the Amiga so that you could read and write 800k Mac floppies directly.  There was something about Amiga drives and Mac drives supporting a different number of drive speeds, so full Mac compatibility on the Amiga's drives was directly impossible.  Future versions of AMAX that used an internal card on the Amiga 2000 worked around this issue.  It was possible to make a floppy that supported just the sectors/speeds that were the same on both, but they only stored 272k of content.  But I digress...

The other function of the cartridge was that you needed to plug in Mac roms into it, which the software would read in as it starts.  Rather than storing the ROM on the Amiga, this protected the copyrights or whatever.  But the important thing here is the function.  I had picked up a few AMAX cartridges for $2 apiece at the awesome Active Surplus on Queen Street in Toronto a bunch of years back, so I dug one out.

Left-to-Right, you see: Amiga D23 floppy connector, for connecting it to your Amiga, two 28 pin rom sockets, two 74LS393s, one 74LS165, a resistor, some diodes, a 74LS139, the Mac D19 floppy connector on the bottom, then the Amiga D23 floppy connector for adding additional Amiga floppy drives.

I've started to trace out the circuit, but it became obvious quickly that it was optimized for board layout rather than what I would consider to be a sane arrangements of data lines.  For example the 8 data output lines of the ROMs go into the 74LS165 PISO shift register out of order, so they need to be reshuffled once captured in the host computer.

Instead I decided to desolder the chips!  My guess at the original function is something like: the Amiga issues a clear to the 74LS393 binary counter chips, ganged together to yeield a 16 bit output, rather than two dual-4 bit outputs.  This will reset their 16 bit output value to 0.  The 74LS165 parallel-in, serial-out register then latches the 8 bit output from the ROM, and provides it through shifting to the Amiga via the floppy port.  From there, you need to simply pulse the clock on the '393, and it will increment through every address. Then you just latch and shift in the data. There's also a 74LS139 demultiplexer, which might be responsible for sequencing through those events, or perhaps something to do with the Mac floppy drive. I had a slight mishap and lost the 74LS165, which is okay since I didn't need it for this project anyway.  Regardless, $2 plus some time -- I'm already ahead and I haven't even removed the D23s yet (which are the same size as Amiga RGB Video connectors! Perfect for another project...)

For fun, here's the board with no components on it.


With a slight change in gears I can adapt my design to use the parts I now have in my toolbox thanks to my desoldering tools.  Instead of the Arduino shifting out an address, it will instead do the process described above.  It will first clear the 393s, then alternately cycle between clocking out a pulse to increment their values, and reading in the value directly. Since I'm accessing the ROM data from start to finish, sequentially anyway, this solution works out perfectly.  I also show four LEDs in the above diagram. Three for various status, one for UV illumination.

Here is a close up of a 27C128 part. This one has Pac-Man programmed onto it... of course.  You can see through the quartz window, and down onto the EPROM silicon itself.

Here we see the pins on the Arduino, and how they connect to the shield's bus connections, along with the LEDs.  I could draw this up in a computerey drawing program, but sketching it out in Sharpie on graph paper is just quicker... ;)

Here are the  two 74LS393's.   You can see their connection to the address lines on the ROM, as well as the cascading of the counter, e.g. from 1QD to 2A, and from 2QD to 1A on the second chip.

And the wiring for the 28 pin socket, including the 3 pin (two-way) jumper so that i can use smaller 24 pin parts as well.

About the UV illumination...  The data sheets for the EPROMs show that they should be erased with 253.7 nanometer light, at 15-20 minutes, 2.5cm distance at 15 Watt/seconds per cm^2.  I dont know how to measure this with respect to LEDs, but I'm going to just wing it and see what happens.  The sheet also says that 253.7nm is the optimal wavelength for erasing them, but anything below 400nm should work.  I believe the UV LEDs I have are somewhere between 350nm and 400nm, so it should work.  The other issue is that the LEDs are substantially less powerful, probably a tenth to a hundredth the power. We'll see once we get this going, but I expect it will take on the order of weeks to erase a rom, rather than minutes.

The good thing about this project, in comparison to using EPROMs functionally, is that you want speed of erasure for functional use.  I personally found that my eraser worked on most of the devices I own in about 10 minutes.  I would often have a chip or two in the eraser, while programming and debugging others.  It worked out fairly well.  For this project, it's completely okay if it takes on the order of hours to erase a device.  I'll find out how well it works once I get it going.  I may use more than one LED just to speed it up a little, in case it takes on the order of days instead of minutes or hours.
I started laying out the board at home, wiring in just the LEDs, and figuring out the best layout for the chips.  I used the DIY shield for Arduino from AdaFruit.com as the foundation to build this upon.  I wanted to leave space for possibly using larger chips in the future, so what is the bottom of the board here has space for a few extra data lines if i re-route that red power line.  The '393's are layed out so that the one on the right, which addresses bits A0-A7 has four of its lines directly lined up.  This was to try to make it a little easier to wire up.


I bought some wire wrap wire for address, data, and control lines, and did most of the work of wiring those up one evening at Interlock.  I used red for control (counter clear, clock data cascade lines) as well as eprom address lines.  I used blue for data lines.  In the above pictures you can see how the wires were routed around (there was some more writing on the bottom, obviously.) You can also see how the UV LEDs are mounted with some stiff solid core wire.  I reduced the number of LEDs to two plus the UV LEDs for no real reason at all.  (There is an Arduino underneath there somewhere...)

On the two images above, you can see a jumper on the left of the first image, bottom of the second image... this changes what one pin is used for.  For smaller EPROMs, pin 26 of the 28 pin footprint is used for VCC, powering the chip.  In the larger packages, VCC is moved to pin 28, and pin 26 is used for Address line 13.  It's confusing.  A table that shows all of the pinouts doesn't really help too much, but it was necessary so that I could figure things out for wiring it up.


Next is firmware. I wrote a pretty simple program for the Arduino that simply enables the EPROM, resets the counters, then clocks through the addresses, reads them in and sends that data down through the serial link.  After getting the enable lines wrong (active low, rather than active high), I managed to get it spitting out actual accurate ROM contents.  As you can see in the above, it read out of the ROM (right half) 0xf3, 0x3e, 0x00, and so on.  In a disassembly of Ms PacMan on the left, you can see these bytes in cyan, just to the right of the red numbers 0000, 0001, and so on.

The other half is a simple program that runs on a host computer that simply reads in serial data and logs it out to a file.  That content looks like this:
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812 
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812 
f33e00ed47c30b23772310fcc9c30e07060708090a0b0c0d0e0f101114f532c038002a804c702c712c20022ec022804c3aaf4e324a503aec4ea73aef4e20033ae187d75f2356ebe9e146234e23e51812
I've now had this running for 12 hours with no change in the bits at all.  I'm thinking that it will require running for upwards of a week or two to have any affect on bits.  I may need to just drop the Arduino and ROM shield into my eraser to get the results I'm looking for... or at least a "control" to prove that the idea has a chance of working from here.

If nothing else, I now have a way to read EPROMS from an Arduino.  Awesome!