Monday, April 17, 2017

RC2017/4 Update: The Andy Project - Tools

Just an update to show some progress on the project.

This project is to reproduce a near-pixel-perfect reproduction of a few of Andy Warhol's pieces that he created on the Amiga 1000 back in the 1985 timeframe, on native tools.

We're 12 days in, and I do not have any completed images to show y'all.  But don't be fooled into thinking I haven't done anything!  I've been running a timelapse of the entire process, and here's the segment for the tool setup work:

Here's a summary of the tasks done so far, and the direction I'm going.

Graphic editor tools

First of all I did a kind of survey of a few tools to figure out what would work best.  I had originally thought that I would use the pre-release GraphiCraft to generate the files, however I ran into a few snags.  This software crashes.  A lot.  More importantly, it does not  have the "save" function implemented.  It DOES however have something very important... Andy's works used some of the pattern flood fills that GraphiCraft (nee ProPaint) used.  These were removed before GraphiCraft was actually released.  But I'm getting ahead of myself here.  My feeling is that with this project, GraphiCraft will only be used to generate more sample and reference materials.  Mainly the fill patterns and how they are aligned, as well as the color palette, which seems to be untouched for many of Andy's pieces.

I have three versions of GraphiCraft here.  I have a pre-release version on a "v29 DOS" disk.  This is the one with patterns, correct palette, is unstable, and cannot save.  I also have two disks labelled "GraphiCraft 1.1" and "GraphiCraft 1.2".  As far as I can tell, the applications are the same, but one is on a Workbench 1.1 bootable disk, while the other is on a Workbench 1.2 bootable disk.  For some starting points of GraphiCraft images, I'll use this to generate the file, and perhaps I'll use them as the final save step, so that we get GraphiCraft /ProPaint ILBM files instead of DPaint ILBM files.

I have also settled on Deluxe Paint III for the main amount of the work.  1 and 2 are fine, but 3 just feels more stable and complete, at least with my 30+ years of experience with the Deluxe Paints... Deluxes Paint?  hmm.  DPaint 4 would work as well, but I've never really gotten completely used to/comfortable with it.

Slideshow tool

I also looked around a bit for a slideshow application.  I want the end product to be a bootable ADF that can be dropped onto a 1.3 system, or perhaps on an AROS-replacement-kick system. I wanted to use a program where I could just script it easily, without having to fire up a gui to add in or replace files.  So tools that were out included AmigaVision (2.x+), Deluxe Video (needs gui to make slides, palette limited anyway), and so on.
Early on, I was considering the "Slideshow" application that came with the "Deluxe Paint Art and Utilities" disk from Electronic Arts. I've used it quite a bit in the past, and it has exactly the type of "script it in a text file" interface that I want. However that one seems to not function on anything newer than AmigaDOS 1.1.  There is an updated version of this on the "Impressionists" art disk also from Electronic Arts, but that one did not work with 1.3 either.

Anyway, this is the exact feature list I want, in bullet form:

  • Must run in AmigaDOS 1.3
  • Fade in/out to black
  • supports10-15 slides
  • supports 320x200 32 color IFF-ILBM image files
  • delay time while a slide is up
  • (optional) user input to advance to next slide
  • (optional) user input to exit from the slideshow
  • should not require loading a GUI to add files, tweak sequence

Here's a quick summary of some of the tools I've experimented with, and my thoughts.  Some of them are from commercial products, some from Fred Fish disks, etc.
First: these were not suitable:

  • EA Slideshow (DPaint Arts & Utilites Disk) - requires AmigaDOS 1.1
  • EA Slideshow (The Impresisonists) - requires AmigaDOS 1.1
  • EA Deluxe Video - requires gui editing to edit/tweak slideshow, 16 color images
  • AmigaVision - requires gui editing, AmigaDOS 2.x+
  • PPShow - Don't remember why. ;) I think it was doing weird palette things.
  • Mostra - requires AmigaDOS 2.x (Aminet)
And these are potentials:
  • dpslide - okay, can't seem to exit (Fish disk 11)
  • slidemaster - okay as well (Fish disk 274)
  • ALook - TBD
  • Show (Fish Disk 323) (early version of Mostra)
  • Mostra (early version on Fish Disk 330)

One person on Facebook had recommended a trick that some demo disks did, which was to set the system colors to all black, then images could be loaded one by one from a startup-sequence or the like.  That's something I'll consider as well.  (also, ref Fish Disk 323, "Color Tools")

One AmigaDOS reminder; to make a CLI script executable, you use the "protect" command line tool like so:

    protect slidehowScript +s

AmigaDOS 1.3

All of this will be worked on in a virtual NTSC Amiga 1000 (or Amiga 500) provied by the FS-UAE emulator running on my Mac OSX laptop.  I've set up a Workbench 1.3 filesystem disk, onto which I have installed the basic 1.3 system, Deluxe Paint III and GraphiCraft 1.2.  This is honestly nothing too extravagant.
I set up a new FS-UAE config file with the specs:

  • NTSC chipset
  • 512k chip (Amiga 500)
  • 2 meg fast (not really necessary)
  • DH0: "WORK13:" is a filesystem-based hard drive, with a "Files" folder containing all the works-in-progress, and completed imagery
And I also set up a second config for obtaining and analyzing reference materials from GraphiCraft


I discovered early on that it was going to be necessary to have some way to apply a grid to the reference images from the internet (PNG and JPEG images), so that I can recreate their content pixel-for-pixel.  Since they had differetn scaling, different compression and in some cases, different pixel aspect ratios (non-square or stretched-to-square) pixels.

The Amiga in the modes that Andy used had non-square pixels.  Well, the representation on disk was a 4:3 display of a 320x200 pixel image. This means that each pixel is slightly rectangular at 1.1:1 or something like that.  However, when they are displayed on an Amiga monitor or TV set, they are displayed-as-square.  This sounds confusing, but rest assured, it really is.

The tool that I eventually made, "ObeseBits" (the name is a play on the MacPaint magnifyer tool which it called "FatBits", but it's for much larger images. see?) has been made using the "Processing" development environment.  I used the most recent "Processing v3.3" to create it, using the "p5.js" JavaScript mode.  That way I could just run it in any browser without the need to install Java.

As I worked on it this past week, I rolled in a bunch of features which I figured would be useful for this project:

  • Load in any image (scaled most images to 2xxx by 15xxx pixels for consistency)
  • Show the image zoomed in (4x zoom defined in the code, nonadjustable)
  • Grid is applied over the displayed image
  • Grid has selectable white/black/yellow color with a few levels of opacity
  • Grid has slightly bolder 5th lines, making 5x5 grid of pixels
  • left-click drag to move the target zoom area around
  • shift left-click drag to adjust the grid spacing/scale
  • Scaled down to 160x100 thumbnail showing where the zoom area is in the "big picture"
  • display of the current pixel color under the mouse
After using this tool on the same machine as the emulation for an evening, I've determined that it will be substantially more efficient to run this tool on a second computer, and dedicate the primary computer purely for the emulation environment.

Current State...

After the weekend, I've created the following content, using the above tools to be detailed in an upcoming blog post:
  • GraphiCraft reference image 
    • 320x200 IFF ILBM image
    • Created from observations, documentation from GraphiCraft v27r6
    • Recreated in Deluxe Paint III
    • 32 colors with the exact palette from v27r6
    • "purple balls" pattern reproduced with exact pattern-grid alignment
  • "Campbells" image started
    • Started with the reference image above, kept the palette and header bar
    • Some of the top of the can is converted.

A Minor Dilemma...

I am caught in a dilemma of sorts though that I need to figure out at some point...

Andy did a lot of his work in ProPaint, which was the original name for GraphiCraft.  This can be seen on the video on youtube where he is capturing and editing a picture of Debbie Harry.  The header bar says "ProPaint V27 Release 14".  All of the released images from the recent effort show "GraphiCraft v27 Release 6"... Which is correct?  My gut is telling me that the software that he used, specifically, on that day for the presentation, it put that text atop the screen.  Perhaps that was the exact text on his copies as well.  I can only assume that the restoration team was using the software they had, not necessarily the specific application disks Andy was using... although I could be wrong.  I am trying to get into contact with them to determine exactly what is going on there.

For now, I'll stick with the GraphiCraft heading. ;)

Tuesday, March 14, 2017

RC2017/04 - A new direction... Andy Warhol

So the Retro Challenge 2017/04 is starting up again next month.  I've decided to try a different direction on this, this time.

For many years, I've been interested in the artwork that Andy Warhol had done on the Amiga.  For a long time, only fuzzy versions and NTSC video were available of it.  Fairly recently art historians found his Amiga computer, including all of his floppy disks and transferred the files off to modern devices so that we can all enjoy them again.

Anyway, after that procedure was done, scaled up pixel-perfect images have been released, in modern image formats.  The originals are still locked onto their disks.  I'd like to change that. (I should note here that there was a floppy demo disk circulating with all of the images as IFFs, but they were back-converted from the JPEGs... so.. yeah.  meh.)

So here's my plan:

I'm going to, as faithfully and pixel-perfect as possible, recreate some of the Andy Warhol pieces.

I'm putting all of the reference and work in here: (dropbox link) which currently is only photo references.

As far as I've been able to find, there are 11 works, which are represented here:

These are all captured from images and videos on the internet.  All are copyright the Andy Warhol Foundation for the Visual Arts, Inc. and are being used here without direct permission.

My plan for the first items are:
  1. venus
  2. signature
  3. campbells can
  4. self portrait (next to the can above)
And we'll see how it goes from there

I will be using GraphiCraft and Deluxe Paint (II) to reproduce these works.  I had originally thought to use the original pre-release version(s) of GraphiCraft to accomplish this, but I have decided to use production, shipping software to do the work, as they will be functionally the same, and a lot more stable.

I figure that my products will be my own works, much in the same way that Andy's reproduction of existing designs, like the Campbell's soup can, became his own...

I do plan on having minor, obvious intentional differences to differentiate mine from the "originals".

Monday, December 5, 2016

RC2014/LL Showing ROM/RAM switching, 64k!

So I thought I'd just make a quick post to show how I know that the ROM swap hardware in my RC2014/LL is working. I'll walk through the procedure here...

First, I booted up the RC2014 as usual, which drops me into BASIC.  From there I wrote this short program:
10 FOR A = 0 to 8192
20 B = PEEK( A ) 
What this does is goes through the lowest 8 kbytes of memory, reads (peek) and then writes (poke) the byte it finds right back to the place it got it from.   For example:
  1. Read from memory address 0
  2. Write to memory address 0
  3. Switch to the next memory address, repeat 
Which seems stupid, that it does nothing.  But if you remember from a previous post, when the ROM is enabled, it's only enabled for reads.  Writes still happen to the RAM in the same addresses.  So the above program copies the BASIC ROM into RAM.

Next, we switch off the ROM by doing this:
 OUT 0,1
The lowest bit, '1' turns off the ROM, and switches to the RAM for read operations.  To confirm we're working out of the RAM, we can poke a 0 in somewhere down there.

POKE 0,0
So we can see here that memory address 0 has been changed from 243 to 0.

I also went one step further and yanked the ROM board out of my RC2014.  This is not recommended. ;)  But it did continue to run without any problems... until I really tried to muck things up, for fun:

I wrote a program to clear RAM, and then ran it in BASIC.  Here is the listing:

And here's what happened when i typed 'run'.  It completely locked up after it printed the '8'. Starting at memory address 0x0008 is the text output routine, so it cleared out the boot code before that (0x0000-0x0007), erased the beginning of the print handler, then went to print out something to the screen, and crashed.  Well, I assume it crashed. It got an invalid opcode and who knows what it's actually doing. The code there used to be a "jump" which is 3 bytes.  Instead it got a NOP, which does nothing, (0x00)  and then two garbage bytes which map to something incorrect. Boom!

Monday, October 17, 2016

State of the RC2016/10

RC2016/10 is a little more than halfway over... so where am I?

Pretty much in the weeds.

I'm almost at the point where I wanted to be at the beginning of the challenge. I'm still working on finishing up the SD loader routines.  Well, I've finished the SD/Micro side of things (in the SSDD1 module - Serial SD Drive) both for the real physical drive as well as for the emulator, for loading only.  The emulation also supports writes now, and both support file/directory manipuations:  Directory listings, make directory, remove directory/file. (For the FAT filesystem anyway.)

I've got a bunch of things on my plate right now, between work, finishing up a contract or two, the animatronic bird project has reappeared a bit, plus time for the family, lack of sleep, and general lack of motivation for anything.

I haven't done any of the sector IO stuff yet, as I want to get regular files working.

In any event, here's a quick bullet summary of the current state of the project:


  • Hardware for SD interface
  • Hardware for ROM/RAM switcher
  • SSDD1 process design (see image above)
  • SD drive (SSDD1) firmware (preliminary)
  • SSDD1 emulation for file and directory support
  • SSDD1 firmware for directory support and file reading
  • CP/M research to figue out what needs to be done, prior work.


  • SSDD1 firmware for file writing
  • SSDD1 firmware and emulation for simulated sector IO
  • Z80 SSDD1 decoder (Hex string+checksum to proper formatter)
  • Z80 IHX decoder (stream from SSDD1 to RAM writer

Gameplan tasks (Roughly in order of probable completion):
  • Z80 IHX decoder
  • Load a ROM from the SD card into RAM, switch off the boot ROM, restart, run from RAM
  • Backport emulation into the firmware to get them equal
From here, I can go down one of two paths.  I can completely flesh out the rest of the SSDD1, and get the sector IO code implemented, which is probably the best course of action, just for completeness.  Or I could start working on porting/implementing the CP/M bios ROM, which might give me the "win" kick that I need to get the Sector interface implemented... although once I have the regular file IO stuff done (which it is) the sector IO stuff is the same plus a bit more wrapper implementation... after all it's just a bunch of 128 byte files in subdirectories... so...
  • Sector IO SSDD1 emulation
  • Backport Sector IO to SSDD1 firmware
  • CP/M Bios
  • CP/M Bootloader into LLoader ROM
  • Burn new LLoader ROM to 27C512 EPROM
  • Boot a RC2014 to CP/M!

Sunday, October 2, 2016

RC2014/LL and RC2016/10

The RetroChallenge is upon us again!

This time around, I plan on working on my Z80 homebuilt computer, the RC2014.  (Website for RC2014, Order a RC2014) For a few months now, I've had my RC-2014 computer built, and modified to be an RC2014/LL computer. What this means is, is that I have some modified modules using no additional external hardware.

The above picture shows my RC2014/LL system with its extra RAM module, and the C0 Serial expansion board to the left, with the SD card interface board (SSDD1) on it.

The basics of this design:

Unmodified RC2014 modules:
  • Z80 CPU module
  • Clock module (* see below)
  • Serial console interface
  • RAM module (for RAM in the range $8000 through $FFFF
Modified RC2014 modules:
  • Second RAM module
  • ROM module
  • Digital IO module
Additional hardware:
  • Second ACIA Serial port at $C0
  • SSDD1 (Serial SD Drive)
(*) While the clock module is unmodified, it technically is modified. I have added a 10 uF (50V) cap between the reset line and ground to be a quick-and-dirty power-on reset circuit. It works perfectly.  Every time I power on the computer, it "presses the reset button" for me. ;)

The plans to mod these parts are available here.  This is currently fully functional and tested. The modifications use unused gates on the boards, so that it requires no extra additional hardware or boards to implement. The basic theory to the /LL modifications are as follows:

Bit 0 (0x01) of the Digital IO module is tied to one of the extra bus lines on the backplane.  Let's call this "Extra-A".  When you do an "out" to that port of "0x01", it will trigger the Extra-A line.

The ROM module "out of the box" is configured such that if there is a memory access, which is a read from address $0000 through $7FFF, it will enable the ROM, and it will put its data on the bus.  My modification adds in one extra condition to this.  It adds in that only if the Extra-A line is LOW, that the ROM will be enabled.  This means that when Extra-A is 0, the ROM works. When Extra-A is 1, it's as though the ROM doesn't exist.

The RAM module "out of the box" sits at the high half of memory space ($8000-$FFFF), and is always enabled on memory READ or WRITE to those addresses.  The modification to this module is threefold.  First, it sits the RAM at the low half of memory space ($0000-$7FFF). Secondly, it is set up that WRITEs to this memory space will always work, regardless of Extra-A.  Thirdly, it is set up that READs to this memory space will ONLY work when Extra-A is HIGH.

The end result of this is that when Extra-A is low, reads in the low half of memory will come from the ROM.  When it is high, reads will come from RAM.  Writes ALWAYS go to RAM.

This is quirky...

I admit this.  It means that you can (and I will) write a bootloader/monitor ROM that is enabled on power-on, will read from a mass-storage device and write into anywhere in RAM... It can load a 64 k byte memory image into RAM, and then switch off the ROM and it will all work.  The quirkyness is that you cannot verify the loaded-in memory in the low range of ram, since reads will come out of the ROM.   Obviously, you also need to do this routine completely out of registers, as your stack variables will get overwritten if you're not careful.


If you want it to behave like a stock RC2014, remove the jumper from the IO board to Extra-A, and instead add a jumper from ground to Extra-A.  I have added a switch to mine to force this in the case where the IO board comes up in the wrong state.

Additionally, I have added a second serial port, which basically follows the circuit for the first port, but it sits at $C0, and does not have an interrupt line wired to it.  The RX/TX on that one comes out to a FTDI-like pinout header, which is where my SSDD1 module plugs in.  The plans for this serial port are available here, and can be seen as the brown perf-board on the left of the topmost image of this post.

The SSDD1 module...

The Serial SD Drive module is the mass storage module that I've created for my Z80 to interface with. I know that I can push the FAT filesystem support onto the Z80, but that would require substantial effort.  I instead decided to go with the model where I have a smart serial-based device that you tell it "i want this file" and it sends it out.  Like a local BBS. ;)

The use of a serial-driven drive is not unprecedented.  It's somewhat modeled after the Commodore 64/Vic 20's "IEC" serial interface for floppy drives.  It also mirrors it in that the drive has some smarts in it to deal with the drive architecture.

I also went this route for the ultimate form of this computer, which is to run CP/M.  CP/M expects drives with a Drive+128 byte Sector layout.  While other Z80-CP/M computers implement this by having direct interface to the sectors on the spinny disk/cf/sd card, I will do it by having files on the SD card, for the most amount of flexibility.  There will be a "drives" folder on the card containing folders named "A", "B", "C", and so on.  These letters are the drives.  In each of those will be directories for the tracks, named "0000", "0001", etc and in each of those, files named "0000" "0001" "0002" etc. These files are the simulated sectors on the disks.  It will be easy to build virtual drives for other use out of this.  It also means that I won't need some special interface on a modern computer to talk with this.  I won't have to do 'dd' style transfers to get at the data... It's all just sitting on a FAT filesystem.

The implementation of this module is based on an Arduino with a microSD breakout module.  The serial interface communicates directly with it, and it sends the content via serial back to the Z80 host.

The above picture shows the SSDD1 module off of the RC2014/LL expansion board, and instead wired to a breakout board where I have a second FTDI serial-USB interface so that I can debug the hardware more easily.

And that brings me to the current Retro Challenge...

My goals for this month is to do a few things here, to finish up this computer system...
  • Finish up the firmware for the SSDD1
    • Sector load/save support
    • File load/save of intel hex files
    • directory create, list, remove
  • Write the SSDD1 emulation for the emulator
  • Finish up the loader and burn it to a ROM
  • Write a CP/M bios that uses the SSDD1 interface
  • Build CP/M disk/sector files 
  • Play Zork
Stretch goals:
  • Extend the NASCOM BASIC to support the SSDD1 for loading and saving.

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

Sunday, February 21, 2016

Hacking my own Arduino Mega

At Interlock, I was handed the old controller board for a gutted 3D printer that was being rebuilt. "Do whatever you want with this." A close inspection of the board showed that it had a main microcontroller of the ATmega 1280, which is the chip used in older Arduino Megas.  The interface to USB however was an ATmega 8u2, which is the chip used in newer Arduino Megas, and you may also know it from older Arduino Unos... modern Uno R3s use a 32u4.

This board had custom firmware on it so that it didn't look like an Arduino, or any sort of serial connection to the host computer it's plugged into... so as-is, it was useless for general use as an Arduino; taking advantage of the GUI and clicky-clicky programmer interface.

So my thought was, it might be nice to have my own 'Mega for testing and such.  Could this board be set up in a way that might make this process and outcome easy?  Turns out it mostly was.

The original board got its power from a power terminls on the board, 24V.  It needed to power the stepper motors, and such so it needed to be beefy.  This was dropped down to 5 and 3.3 on the board itself.

There is a USB B jack for connecting this to a host computer, which did not have its 5V connected, so my thought was, what if i hooked up this 5V to the USB jack.  would that be enough to power the chips?

I added this jumper, which connects the +5 on the USB jack to the 5v bus on the board, and plugged it in, and sure enough, it beeped and came to life without its host power supply.

Next up would be reprogramming the micros to have the arduino bootloader and code on them.

I hooked up my fairly cheesy Arduino D-15 (hacked stepper motor controller) ISP to the 6 pin header, which thankfully was already populated and labelled on the board!  I plugged it into the port labelled "1280 ISP", selected the Arduino Mega, with 1280 micro from the Arduino 1.6.6 menus, selected Arduino ISP for the programmer, then selected "load bootlader".  In about a minute, it seemed to have completed successfully.... if something didn't jive, it would spew out sync or device errors to the screen.  Seemed good so far!

Next, was hooking it up to the jack labelled 8u2 ISP.  This was a little trickier because I wasn't installing the bootloader (which the Arduino IDE makes REALLY easy to do), but rather the secondary micro's firmware, which basically was just a USB-Serial interface driver.

Long story short, I grabbed the 8u2 code from github, "MEGA-dfu_and_usbserial_combined.hex", and used the following command line (using a mixture of the code on that page, with the parameters that my system used via the arduino IDE on my Mac:

    ./avrdude -p at90usb82 -F -cstk500v1 -P/dev/cu.usbserial-A800czia -b19200 -U flash:w:8u2.hex  -U lfuse:w:0xFF:m -U hfuse:w:0xD9:m -U efuse:w:0xF4:m -U lock:w:0x0F:m -C/Users/me/Library/Arduino15/packages/arduino/tools/avrdude/6.0.1-arduino5/etc/avrdude.conf

In short, it sets the CPU to at90usb82, uses the stk500v1 communications protocol over the /dev/cu.usbserial driver, at 19200 baud.... it programs the file 8u2.hex, sets fuses and sets other avrdude configuration stuff.

After lots of text scrolling by from running that, I was able to drop a program I was working on, onto it via the Arduino IDE directly, without any problems at all! I set the port to the serial Mega, set the board to "Arduino Mega", cpu set at "Mega 1280", clicked 'upload' and bam, fully functional serial communications from the serial montior down through to the '1280 on the board.

Whoo! Free Arduino Mega for me!

Edit: Here's the pinouts of stuff I beeped out.

 * 4 - Piezo +
 * 6 - heat
 * 7 - fan
 * 24 - A Dir
 * 25 - A Step
 * 26 - A Enable
 * 27 - A Pot
 * 28 - B Dir
 * 29 - B Step
 * 36 - debug 2
 * 37 - debug 3
 * 38 - (nc)
 * 39 - B Enable
 * 40 - debug 4
 * 41 - PG0
 * 42 - TP33 / Z-MAX
 * 43 - TP32 / Z-MIN
 * 44 - Extra +/R85
 * 45 - bp heat
 * 46 - TP31 / Y-MAX
 * 47 - TP30 / Y-MIN
 * 48 - TP29 / X-MAX
 * 49 - TP28 / X-Min
 * A0 - X Dir
 * A1 - X Step
 * A2 - X Enable
 * A3 - X Pot
 * A4 - Y Dir
 * A5 - Y Step
 * A6 - Y Enable
 * A7 - Y Pot
 * A8  - Z Dir
 * A9  - Z Step
 * A10 - Z Enable
 * A11 - Z Pot
 * A12 - PK4 / JP7
 * A13 - PK5 / JP7
 * A14 - PK6 / JP6
 * A15 - TP27 / HBP Therm

The molex switch connectors seem to have the pinout: (signal) (ground) (ground) (+5v)