RC2017/4 Final! (Replica Results and Post-Mortem)

"The Treachery Of Pop Pixel Art" - Scott Lawrence, 4/30/17
Inspired by Andy Warhol and René Magritte's works

As you might know, I spent time this past month working on what I nicknamed "The Andy Project". The idea was to re-create some of Andy Warhol's art pieces on an Amiga, well, an emulated Amiga, using appropriate tools, as pixel-accurately as possible.

This blog post will be a summary of results, mentions of pitfalls, and that kind of thing.  The previous three blog posts cover most of the other information for the project.  Links for these are on the bottom of this post.

Philosophical musings...

Andy's work is interesting because you don't see any other of the "classic" artists doing their work in such a media, where you can get pixel-for-pixel copies of the originals.  Nowadays, sure, you get photographs of the original, but with these digital art works, you can get essentially the EXACT same content that was originally produced. This is likely why the "originals" have never been made public directly... Understandably so.... That floppy gets out, and we see posters of pop-pixel-art available in every mall. That said, I want to make poster blow-ups of some of these. ;)

This actually got me thinking a lot about the resulting media files that I will be produced.  These will be virtually indistinguishable from the originals.  Are they the same as the originals?  In some of these, I am the person who drew all of the individual pixels in Deluxe Paint.  It is distinctly not the original files, which are still under lock-and-key.  But those may surface, and you may find that mine are nearly identical with respect to which color pixels are where on the digital canvas.

In the music industry, if you were to make a copy of a waveform, by looking at numerical representations of the wave, and typing them in to a computer, making a replica of the original waveform.  When played back, it's still Debbie Harry's "Rush Rush"... but you actually created it from scratch by copying the numbers from the original.  It's a replica... that is functionally and actually identical to the original.  In fact, if you were to write a computer program that did this for you; go through the audio file, and look at the numbers, then write those numbers into another file... then the computer has generated a replica of the original... That's exactly the same as I'm doing here, right?

That software already exists.. it's "cp", "copy" or "drag-and-drop the icon to another folder."

Does that mean that I cannot take credit for my reproductions?  This is kind of why I had wanted to add specific mistakes/changes to mine, so even if you were to compare them at the pixel level, mine would be at the least, a derivative work. ... but is that enough?  Couldn't Andy's estate come after me and say "that imagery is exactly the same as the original, and you're putting it up online for free! Stop that now!"

I know that mine are replicas...  perhaps that's enough.

But then, if you think about the pop-art movement of the '50s and onward, it delves DIRECTLY into this, head on.  Andy, for example, took iconic things (soup cans, Marilyn Monroe) and used them as the basis for his iconic works.  If the Campbell's Soup can looked different, so would have his artwork.

So in that vein... My reproductions are essentially my brand new art pieces, just using his pieces as the inspiration...

Wait.. are mine replicas of his works?  Are mine new works, like the originals under the pop-art umbrella?

I don't know how to resolve this.

The Andy Project

I started out with a list of 11 images to pick from.  I thought I might get a few done, but I never set specific goals for myself... so I only got three of them done.  I still feel like this is a major success. Mainly because I can now do many of the other ones at my leisure using all of the tools and frameworks I've already set in place, with full knowledge of the pitfalls for the various steps.

I also created two pieces that I was inspired to make from the project, so I included those in the ZIP and slideshow ADF as well.  Links to the slideshow ADF downloads are at the bottom of this blog post, along with an in-browser emulator that can play it in-browser.

Everything provided here is to be considered to be Creative-Commons BY-NC-SA. (Attribution, Non-Commercial, Share-Alike).

What went wrong

I think the big thing that went wrong was wrangling with tools. There are two instances that come to mind.

Nothing really went wrong here, I just thought it would almost
be appropriate for this to be my end-state of this image. :)
I feel like Andy might have accepted this.

ObeseBits

First of all, my tool "ObeseBits" was giving me trouble.  It's the first Javascript-Processing app I've ever really made.  Most of the time for Processing, I just use Java mode.  That seemed a bit excessive, and I wanted to make something I could easily share, so I went Javascript instead. 

If you watch the time lapse, you may see bits like this roll through.
The frustration was real.

This is a fine choice, but I had a problem where... I'm not exactly sure what was going wrong, but I was re-drawing the entire screen every frame.  It seemed to be chewing on more RAM that it should, especially after it sits for 5 minutes... especially running in Chrome on a 8 year old mac with 2 gig of RAM.  Yes, I see the irony here that I'm creating these images on a machine that could do this with 1/2 megabyte of memory... hehe  Anyway, it would get so unresponsive that it would essentially lock up the machine, but it always seemed like it was JUST ABOUT TO wake up.  But no... spinny rainbow pizza instead...  Force reboots were my friends.

FS-UAE emulator

The other main issue was that I couldn't get the ADF file exported from the emulator I was working in!  Seems like a pretty straightforward thing to do:

1. Mount an ADF disk image
2. Diskcopy Amiga Workbench 1.3 to it
3. Make space by removing printer drivers, fonts, utilities, etc that aren't needed
4. Copy my "Files" folder from the virtual hard disk to the virtual floppy
5. Set the startup-sequence to just add disk buffers and then run the slideshow (DPShow)
6. Quit out of the emulator
7. The ADF disk image file you have there has all of the above done to it, right?

            RIGHT?

WRONG.  I was using FS-UAE that, because of reasons that kinda make sense, treats all mounted ADF disk images as read-only, and creates an "overlay" in a separate directory with all of your changes.  So... here's the list of things I tried to get the modified ADF out of the thing:

1. "apply" the changes to the ADF.
• Can't do this.  The change overlay is in a custom format.
• No tools exist to do this. (!!s)
2. Turn on the UAE emulator flag "writable_floppy_iamges=1", which tells the emulator that it's okay to write directly to disk images for new disks.
• Then you must mount a new disk, once this is set, diskcopy the content over, and you'll end up with an ADF with all of these changes. Right?
• WRONG. FS-UAE ignores this flag.  There is literally NO WAY to write to an ADF that I have found directly from FS-UAE.  (let it be noted: otherwise, FS-UAE is freaking awesome.  this just really frustrated me.)
3. At some point in here, I needed to edit the startup-sequence on the ADF, and I couldn't do it via the emulator's mounted-folder-as-disk-image, so i grabbed "Vim" from Fred Fish disk 591.
• This required ARP for some reason, so I grabbed ARP and ran the installer.  
• It replaced a bunch of AmigaDOS commands, added a library, etc.
• Vi now worked.  Yay!
4. Make a disk image to a file within the emulated Amiga.
• Sounds ridiculous, but in fact, yes... it is ridiculous.
• The only one I found that "should" work in AmigaDOS 1.3 was "TransADF"
• Grabbed TransADF off Aminet, put it on my "Work13" disk (which is a mounted folder from my Mac). 
• Ran TransADF, and... GURU MEDITATION
• Fumbled for a while and realized I could boot an emulated AmigaDOS 3.1 system.
• Booted up AmigaDOS 3.1, ran TransDisk, created the ADF, looked good.
• Booted back into 1.3, and suddenly, on "loadwb", the system just locked up with a blank blue screen.
• Eventually traced it back to ARP being an issue.
• Luckily, my Work13: disk was being maintained by Git, so i just reverted the changes that the ARP installer did... and now it all worked again.  blerg.

So yeah.  Cumbersome as all get out, but I managed to get the ADF made, and I now know I can just boot into 3.1 and run TransDisk to do this again.

What went right...

I got three image replicas done! YAY!

I feel super proud of the fact that I was able to do it to the best of my abilities, to the best effort I could provide and do.  I tried my best to be pixel-perfect, to be color-accurate, and I think the results paid off really well!

You can see me work on these in a time-lapse on YouTube too!

What you see here are EXACTLY what I was doing this project to avoid.  Incorrect aspect ratio, wrong file format, etc. ;)  But they show the effort. I  left the Deluxe Paint panels up just for fun, and to show that these are in fact the ones that I made, and not the source Warhol material.  If you want the proper files, they're downloadable at the bottom of this file.

"campbells.pic" (As seen in Deluxe Paint III)
Original by Andy Warhol, Replica by Scott Lawrence

"Campbells" took full advantage of the foray into GraphiCraft, as I used the palette generated from the saved out Graphicraft 1.2 image, but then tweaked by hand to accurately match the pre-release palette that Andy would have had available to him.  I feel like this is a great representative pice of his work on the Amiga, as well as for this project itself.

"venus" (As seen in Deluxe Paint III)
Original by Andy Warhol, Replica by Scott Lawrence

I had originally thought that "venus" was going to be pretty simple. It was mostly the "venus.iff" file that is included with every copy of Deluxe Paint.  (Here's a link to the original as seen in Deluxe Paint IV.) Well, there's those two orange dots on the left, the scribble on one eye, and the third eye... so it should be easy.  Right?  Nope.  

1. The source material that I had was a JPEG, with its entire color palette completely wonky.  Browns looked violet... whites looked yellow... that kind of thing
2. This means that I had to spend time not just picking the right color, but also cross-referencing the pixel in the jpeg with another of the same wrong color, but unchanged by andy... then find THAT color in my DPaint version, and use that color.  
3. The forehead.  I don't know how... I don't know why, but Andy replaced MOST of the forehead with the version that's there... He probably just grabbed a brush and pasted it down a lot. There's some evidence of this being the case along the left side. Perhaps I'll analyze it more for another blog post in the future.  I ended up having to wipe out the entire forehead and re-do it entirely.

I do feel it necessary to note that many of the pixels in this are "close".. not specifically the exact correct shade of the colors.  There are a lot of orange/browns that are VERY similar and with the process of cross-referencing mentioned above, I know that I made a few mistakes here and there on this one.

I had felt a bit uneasy looking at this one for a while, but couldn't place exactly why... but it turned out that the forehead's replacement was a huge subconscious "something's not right here" flag in my head that I couldn't quite place. 

"flower" (As seen in Deluxe Paint III)
Original by Andy Warhol, Replica by Scott Lawrence

This one looked like it was going to be fairly straightforward to make... and it in fact was!  There were a lot of stepped lines, and the source material was scaled up and fuzzy, but I was able to work around this.  I remembered that DPaint has a tool "Coords" (press | to enable) which shows where your cursor is in X and Y, and also length of lines you're drawing.  This took was invaluable for doing this replica.

Notes...

Yes, I did notice that "Flower" and "Campbells" are missing the red rectangles in the upper right of the imagery on the provided ZIP and ADF files below..  Those are the screen raise/lower tools from AmigaDOS shining through.  Much like the "GraphiCraft" drag bar being visible, those should also have been visible. That's my mistake. The next version I cut of the slideshow will have that fixed.

Oops!

Links!

Here's a list of links of products and stuff that may be interesting:

• See the slideshow via SAE emulation in your web browser (Select "AndyProjectSlideshow" config,  click "Start")
• Download the slideshow folder, zipped with IFF file (80k Zip file)
• Downlaod the slideshow ADF (350k Zip, ADF Disk Image, autoboot, needs Kickstart 1.3)
• Watch the Timelapse video (with annotations) Over on the YewToobz
• Try out ObeseBits - Made with Processing 3.3, using the JavaScript (p5.js) mode.
• And finally, here's my umlautllama page collecting all of the materials

Everything provided here is to be considered to be Creative-Commons BY-NC-SA. (Attribution, Non-Commercial, Share-Alike). 

And previous blog posts about the topic:

• Post 1: Announcement of my intentions
• Post 2: Configuring the tools
• Post 3: ObeseBits information

Retro Challenge 2015/7: Post-Mortem and project notes...

Current Project State

For this Summer's Retro Challenge (2015/7), I worked on a small widget that lets you use an Amiga mouse, Atari ST mouse or Atari-style Joystick.  I was successful in building it and having it be manually configurable.  There's a shell based interface that you can use to select which input device and output style is used.

All of the code for this project as well as further and future documentation is available at the project's github repository.

There are a bunch of things that I did complete during the "challenge"...

• Arduino Leonardo based firmware with simple direct connection to a single D9 male connector
• Two versions of the hardware, one quick and dirty, the other optimized for the parts I had.
• Designed to use minimal external parts - just the Arduino board and a D9.
• Serial interface shell to configure which device it is
• Amiga Mouse (fully tested)
• Atari ST Mouse (fully tested)
• Atari Digital Joystick (fully tested)
• Serial interface to select which output the joystick provides
• Mouse movements
• WASD keypress input
• Arrow Key keypress input
• HJKL keypress input
• etc.  (support for MAME, Stella, Vice, etc)
• "Explorer" to experiment with input device auto detection algorithm (which does work)
• Amiga 500 keyboard input header (incomplete)
• Amiga 500 to Amiga 1000 keyboard adapter (to RJ-22 4P4C telephone handset jack)
• Documented Amiga keyboard adaption 
• Documented Amiga - Atari ST mouse differences
• Documented other D9 joystick pinouts (and how they relate, etc)

There are two features that I did not complete before the end of the month...

First of all, I was unable to get the keyboard support working before the end of the month. I was having a hard time with it only to realize it was a power issue.  The keyboard was consuming more power than my widget could provide.  It will require a secondary power supply to give enough oomph to get it working.  I also was unable to read from it once I hacked in some power.

Secondly, I had designed an algorithm to autodetect between the three different supported input devices, but I was not able to integrate the code in before the end of the month.  At some point I'll mix it in, and it will switch the kind of device it will be based on analysis of the signals (and signal pairs) of data coming in when it detects "motion".

Next Steps

At this point, I'd like to take the codebase as it exists now, and change the program flow to do the auto-detection of the device type, and then do the "appropriate" thing with it.  "out of the box" it will just "do the right thing" when devices are plugged in. Namely:

• Amiga mouse becomes USB HID Mouse
• Atari ST mouse becomes USB HID Mouse
• Atari Digital Joystick gets configured to send STELLA keypresses (arrow keys, etc)

I will implement this at some point, perhaps during the next Retro Challenge.

Retro Challenge 2015/7 Update 2: Keyboard And Joysticks

Space Invaders running in Stella on my Mac.  Jasper loved it!

(He also liked the green light-up USB cable.  That's my kid!)

As of last night, I have finished code for the joystick-to-keypress controller, as well as the ability to save the configuration in the EEPROM in the ATmega chip. As usual, the code is all available here on github.  What this basically means is that moving the joystick will send down keypress codes to the host computer... so the computer thinks that a keyboard is being used.  This means that applications like Stella, an Atari 2600 VCS emulator, which expect you to use the arrow keys and space bar in place of a real joystick, can see those key presses when you move your actual Atari joystick!

You can now pick from a list of keyboard mappings, including:

• Stella (Atari 2600 emulator) (shown above)
• Vice (Commodore 64 emulator)
• Mame (Arcade game emulator)
• WASD (general PC game usage)
• HJKL (vi cursor movements (because why not!))

I have also implemented a basic settings system that saves settings to the EEPROM within the ATmega32u4 chip.  It currently has "slots" for a few things, but could be expanded with the above joystick-to-keyboard mapping, to send other keypresses from joystick movements or what have you.

The settings system works with 4 bytes in the EEPROM to determine what's going on with respect to saved settings. The first 3 bytes are a sentinel.  If the code does not read the sentinel, it will assume it's on a new device, and will install default values to the EEPROM.  The current sentinel are the three hex bytes: { 0x53, 0x44, 0x4c } which are the ASCII string "SDL", my initials. ;)  Next at setting slot [3] is the settings version number.  Currently this is just '1'.  Settings slot [4] contains the usage mode for the interface port. (Mouse/keyboard mapping, etc).

I attempted last week to get an Amiga Keyboard working with this.  I wired up an 8 position pin header to the interface board, using the Amiga 500 pinout:

1. Data
2. Clock
3. Reset (toggled when Ctrl-A-A is pressed)
4. +5v
5. key (missing pin)
6. Ground
7. Status LED (power)
8. In-Use LED (disk access)

I was going to just wire out the Data, Clock, +5 and ground but decided that it made more sense to use the actual A500 pinout. I ran into a problem on this though.  The interface can't provide enough power to drive the chips on the interface board.  I measured 4.5v at the pin header, then 3.2v down on the interface board itself.  This isn't good.  I will have to wire up a new interface connector with an external power connector, probably a USB-B jack, to provide dedicated power to the keyboard.

I did however find a phone being discarded, and retrieved the two 4P4C (RJ-22) connectors from it so that I can make a better A1000 keyboard jack.  The first one I made used an RJ-45 wall mount jack, which worked somewhat for RJ-22, but it was pretty hacked. ;)

Some thoughts for future additional expansion:

I'm currently going for the "cheap as chips" version of this, which is why there's no interface on it, and you have to connect via serial port to configure it.  This was all intentional to keep the build parts list down... to the point where the only necessary part is a D9 connector!  However, in using it, a few future revisions may offer more usability at the cost of parts expense:

1. Multiple D9 jacks for multiple devices
1. Ports dedicated for Mouse, Trackball, Multiple Joysticks, etc
2. Could be just 2 that simulate Commodore/Amiga
3. Could be 4 to simulate Atari 800 joystick ports
4. Could be 1 for mouse, 5 for joysticks, so you never have to disconnect them.
5. Would require a parallel-in, serial out shift register, or a port expander
6. Expansion at the cost of a few cents, additional wiring, and time to read in the content
2. (related) configuration for multiple ports
3. User interface - Was thinking that this could be a variety of different methods:
1. single pushbutton, Red/Green LED for indication codes (flashing colors)
2. single or dual pushbutton, RGB color addressable LED for indication codes
1. each could be wired directly to IO pins
3. dual pushbutton, 7 segment LED display
1. Could indicate use mode(s), etc
2. 'C' for commodore mouse, 'A' for atari mouse
3. '0'..'7' for joystick mode display
4. Could flash multiple digits sequentially for info etc
5. Would require LED driver chip

Obviously, all of these would require additional effort beyond the "let's get this working" and can be seen as stretch-stretch goals.  ;)

Retro Challenge 2015/7 - Amiga Mouse, Joystick, Keyboard USB interface

Once again, it is time for the Retro Challenge! This time around... well, I wasn't sure what I was going to work on,... In my "I want to partake" email, I listed projects such as working on an SD-card based storage drive for the KIM-Uno, my "Bare Metal C64" long term project.. which will likely wait until I retire, as well as working on the Interlock Homebrew Computer System.

Then I started to get parts from an aliexpress order that I placed.  I received my Arduino Pro Micro which is the teeny tiny version of the Arduino Leonardo.  What makes this special is that the main chip on it is the ATmega 32u4. This is the USB interface chip used in the Arduino Uno.  It has all of the standard IO of the 168/328, but with USB HID support.  This means that it can pretend to be a USB keyboard, mouse, etc.  This is a HUGE feature if you want to make standard computer peripherals.

For some reason, it clicked that I wanted to make a USB HID interface for my Amiga mice.  Long story short, within an hour, I had a functional prototype. I was moving my Amiga mouse, and the cursor on my MacBook's screen was moving.

I figure that this will be great for using the Amiga emulators. It'll be nice to use an authentic mouse, joystick and maybe keyboard with UAE, Vice or just for fun for regular usage.  I know that there are other projects out there or products that do this kind of thing, but they're a bit pricey to have a widget that I can't expand or repurpose... and besides at its core, this is not really a difficult or expensive product.  The most expensive single part so far is the microcontroller, and that was $3.

A little background on the Amiga's mouse...

The way old optical ball mice work is that they have two rollers that sit on a weighted ball, one for the horizontal, and one for the vertical.  As the mouse moves horizontally, the horizontal roller moves, and the ball slips on the vertical one.  The rollers have an encoding wheel with little windows that make and break optical connections with a pair of sensors.  These two sensors generate two bits of data for each direction. (four total.)  These two rotary encoders generate a gray code quadrature output.

Movement in one direction outputs:  00  01  11 10  00
Movement in the other direction outputs: 00 10 11 01 00

So, if you read these in a tight loop, and detect changes you can detect movements in the horizontal and vertical directions. In the same loop, if you look at the button inputs, you can determine if the buttons are pressed.

This is the basis for this project.  By reading these values from a dumb (no internal processing) Amiga mouse, I can generate vertical and horizontal motion values.  I can then send these down the USB HID stack through the Arduino libraries, and voilà, we have an Amiga Mouse to HID USB mouse adapter.  NOTE: PS2 and ADB mice have more smarts in them and output movement deltas rather than optical sensor pulses.  Reading either of those requires serial communications and protocol decoding instead.

My cheat sheet for pinouts and connection information.

Within an hour of this brainstorm, I had this prototype:

Arduino Pro Micro (ATmega32u4), with headers and D9 cable attached.

Commodore Amiga mouse plugged into a spare serial cable re-used as a D9 cable.

Unfortunately, the serial cable I was using had all of the wires connected except for the line used for the right mouse button.  Oh well... For the "what's available on my desk" approach, it was good enough for a proof of concept.

From there, some simple acceleration was added to convert "quick" movements of the mouse to "large deltas" sent down as mouse movements...

The way I implemented acceleration was that each time through the loop, i check for Horizontal or Vertical ticks.  I store the ticks as +1, 0, or -1 in an array of the last 128 readings.  Then, I sum the entire 128 elements of each (horizontal and vertical) array, and use that as the mouse movement.  The faster the mouse is being moved, the more +1s or -1s there will be, so it sends a larger number.  It was a quick hack that I thought might work, that turned out to work perfectly!

Some upcoming additions that I might / probably will do:

- Atari ST Mouse Support.  The only difference between an Atari and Amiga mouse are that two of the lines (specifically D9 pins 1 and 4) are swapped. This is an easy change in software.  The difficult part is tracking down an Atari ST mouse to test with!

- Atari (Digital) Joystick Support.  By combining the button read code with the acceleration code hinted at above, I can convert Joystick movements to HID mouse movements

And really, from that point, it would be near trivial to add in HID keyboard support as well... I can send down WASD key presses for joystick movements... or really any other key presses based on joystick movements.

Additional features may include support for Amiga keyboards as HID keyboard, joystick as HID gamepad, etc.  In preparation for working with one of my old Amiga 1000 keyboards, I cleaned one up to get the years of finger grime of of it...

The right side has been cleaned using my proprietary cleaning technique described below.

Keyboard in the process of being cleaned. More like CLEANBOARD. HAHAHA. :(

Here's the (yellowed) keyboard with some keys removed. (The 'X' key has been missing for years, sadly.)  The proprietary cleaning solution is in that "Cascade" container.  I would use that dental pick tool and my hand noodles to pop the keys off of the keyboard.  Then I dropped them into the cleaning solution.  After about 30 minutes, I pulled each one out, wiped it off with my fingers, rinsed it off, and they were as clean as new.  The proprietary cleaning solution is one squirt of dish soap with some warm water. ;)

NOTE: Not shown is the process of removing all of the lint, hair and other bits of whatever that were stuck between the keys because that's kinda gross and you don't really want to see that anyway..

More on this project to come...

I briefly explored the idea of supporting Mac/Apple IIgs ADB mouse and keyboard support, but I quickly learned the complexity of the ADB spec, and am putting that safely outside of the scope of this project!

The code for this project and other development details are available on github in the AmigaInputToUSB repository.

Amiga 1000 Repaired!

Amiga 1000 computer (1985) with an Amiga 3000 "pregnant" mouse.

One of the fun things about owning retro computers is that you get to repair them yourself. (Perhaps this isn't a fun thing for some of you, but I really enjoy it.)

About 6 years ago, my Amiga 1000 started showing some strange behaviors but only in the green levels of the video.  If you dragged the green slider, instead of it stepping up gradually from dark to bright, it would get brighter, darker, brighter, darker, much brighter, a little darker than that, and so on. The following video shows this...

About 5 years ago, I had opened it up and replaced two '244 latches in the video output section.  I kinda did this blindly by looking at the schematic...

Video output circuit on the A1000
Left to right: Denise coprocessor, '244 latches, resistor ladders, and output transistors.

...and replacing the two latches, assuming that one of them had gone bad.  After doing the repair, the problem persisted and I just gave up on it for a while.

Green section is at the top.  The two '244 latches are now socketed and replaced.

A few days ago, a comment on the above video re-sparked interest in this project and I decided to bring the Amiga over to Interlock and really get to the bottom of the problem. I hooked it up to a scope and followed the paths according to the schematics.

Amiga 1000 apart, hooked up to a scope and a LCD monitor.
The video circuit is on the left edge of the board, just under the power cable.

I traced the lines from input on Q2 (where all of the four resistors in the D-to-A resistor ladder are joined, and back through to the latch, and then continuing back to the Denise video generation coprocessor.

I tried jumpering across various portions of the resistor ladder to try to track down exactly where the issue was.  It gave some pretty interesting results, but really only helped me track down where the issue is.  I eventually came to the realization that something on the R55 data path was drawing it down to ground, or at least close to ground. (Where the left alligator clip is attached in the above picture.)

The "Green" section of the video generation circuit in
the Amiga 1000 with notes

I tried pulling out the pins on the Denise's G1 output (pin 29) and soldering it directly to pin 15 of U6A, and it didn't change anything.  I then pretty much realized that the issue was on the other side of U6A -- the connection between pin 5 of U6A and the left side of R55 (4k resistor).  I decided to leave the above wire "flying" and pulled the resistor leg, soldering it directly to pin 5 of U6A.

This did the trick!  It worked.  I probably could have restored the flying wire back to the original traces on the board, desoldering the wire, re-seating the chips, but I had flexed those pins in and out a lot, and decided to not stress out the pins anymore, and just leave it.  -- "It works... don't touch it!"

After 5 years of it sitting on a shelf, my trusty 'ol Amiga, my favorite computer, is finally is working again!