• A Forgotten Amiga 500

    I came across a pretty nice condition, but broken, Commodore Amiga 500. The Amiga 500 was a cost reduced, mass market successor to the Amiga 1000, wrapped in a wonderful case with a built-in keyboard, side expansion, and a floppy drive. It didn’t have the most amazing specifications, but it had tons of room to grow, particularly compared to some of the competitors at the time. By default, it had an 8 MHz 68000, 512k of RAM, side and trapdoor expansion slots, and a plethora of ports in the back. It, and the successors, were wildly successful in the UK and Europe, and had decent traction in the United States and Canada.

    Initially, this one would boot to a black screen. The red power LED would light up, but the floppy wouldn’t spin, no colours would appear on the screen, but at least the video would initialize. The power is probably good!

    Commodore Amiga 500 with the top case and keyboard off, showing a motherboard with two black resistors on top

    Opening up the case showed a fairly normal looking rev 5 motherboard. Two resistors by the serial port were black, likely due to someone blindly plugging something in at some point in the Amiga’s lifetime. Worst case, that would affect serial, but shouldn’t affect boot. It had a Commodore OEM Kickstart 2.04 ROM, with pins 1 and 31 joined together. There was quite a bit of dust, but no other obvious damage. Sitting in the trapdoor slot was a SupraRAM 512k chipmem expansion with a clock chip, which was a nice bonus.

    Maybe because I’ve had some difficult Amigas before this, but I started out with DiagROM this time. Burned a 16-bit EPROM and popped it in with an adapter. Hooked up video and a serial cable, powered up, and… nothing. Black screen, no serial output. Crud. My guess was Agnus or CPU, as the Amiga will usually boot something with a dead chip elsewhere.

    The Amiga 500 is notorious for ICs popping out, at least from the factory. Commodore would recommend that dealers drop them from a short height just to reseat ICs in case something went awry. I’m not sure if it was cheap sockets or poor assembly, but they had a history. That’s where I started, and that seemed to be the culprit. Each socketed IC was incredibly stuck, so much that my chip puller was just not cutting it. I had to use a flathead screwdriver as a lever to gently rock the ICs out of their socket. Once finally out, there were no signs of corrosion, but the fact they were in so tightly led me to apply some De-oxit to the sockets before re-inserting.

    Photo of a monitor displaying DiagROM output from the Commodore Amiga 500, doing a memory test with 255k of memory tested so far

    Heyyyyyy, there’s the DiagROM we all know and love. From there, it was pretty smooth. RAM tested well with the original 512k, as well as the 512k expansion. CIAs tested OK, serial was functional, Paula pushed out sound just fine, only issue was the Enter key did nothing. I pulled the DiagROM out, replaced it with the original Workbench ROM, and it fired right up. I was incredibly pleased.

    Amiga 500 keyboard with the keys and plastic base removed, showing the flexible membrane with some stains

    The next step was the keyboard. Many Amiga keyboards are Mitsumi manufactured, with a soft membrane handling the keyboard matrix contacts and an on-board keyboard controller to talk back to the motherboard. I disassembled the keyboard to find a thankfully intact membrane with decades-old buildup of coffee or soda. I gently cleaned the membrane with water and just a hint of soap, and it cleared up nicely. Checking the continuity of the contacts under the enter key was successful, so it was likely to need either a new layer of graphite. Thinking the damage wasn’t bad, I did the paper trick instead — rub a piece of clean copier paper across the carbon contacts on the plunger to rough it up a bit. While apart, I also removed all the keys, washed the plastic keyboard base, as well as did a full scrub of each individual key. Reassembled the keyboard, booted it up, fired up the Amiga Shell, and tested each key. Success! Functional enter key, and all of the other keys worked as well.

    In the home stretch, I replaced those resistors next to the serial port. No drama there, they pulled out great, easy to replace, serial still worked. Hot dang, this is a fully functional Amiga 500.

    Top down view of the Commodore Amiga 500, in fairly clean condition
  • A Surprisingly Annoying Amiga 3000

    The Amiga 3000 was a high-end Amiga released in 1990, with a redesigned case, a 68030 processor, up to 16mb of RAM on board, and built-in SCSI support. They didn’t sell incredibly well, and at least for me, were remarkably hard to find. Naturally, I found myself a broken one.

    This one would boot immediately to nothing — a dim power LED, and a black but active display on both the VGA and RGB ports. The battery had already been cut out, and the situation looked really good at a glance, though I saw some damage next to where the battery was.

    I started out with the usual suspects. Most of the ICs moved significantly when pushing on them, so every socketed DIP and PLCC was pulled and put back into place. I then checked voltages coming in from the power supply, and each rail looked close enough, then a select few voltages taken at important ICs, all looking close enough to normal. Still no boot. I then went through jumpers and found that one of them was out of place, leading me to believe this used to have an accelerator installed.

    At that point, the system booted… once, but it was glorious to see that purple screen come up. Something was still flaky, and was causing no boot or partial boots, but generally couldn’t make it to Workbench. Oddly, the more the machine was on, the less likely it was to boot. I initially thought it was a bad floppy drive as the problem got worse after I connected a floppy, but the system quickly stopped making it to the purple screen with or without the drive. I burned a couple of DiagROM EPROMs and started digging in. DiagROM would report errors while testing the upper bounds of Chip RAM, and sometimes fail while testing Fast RAM. After removing the upper bank of chip and all of the fast, we could occasionally start booting again, but the system would still occasionally hang. Sure, some of the fast RAM was MT, but even putting in some combination of fast to get only 4mb, the flakiness would continue to get worse.

    Trying to be methodical, I went for Fat Agnus first as it does memory control. Doing a continuity check on lines coming out of the chip found issues with a data line. I pulled the board out from the case and flipped it over and found that the previous battery had leaked before it was cut, with obvious signs spreading out the bottom of the board. I treated the area with vinegar to neutralize, and then alcohol to clean it. Deciding that the corrosion got to it, I elected to replace the PLCC socket for Fat Agnus. Unfortunately, I managed to destroy a via in the process (or it had already become a problem due to corrosion, but either way, womp-womp), so I not only had to replace a socket, but had to add bodge wires anyway. Given that it was in the area, I decided to replace the Denise socket as well, but that went far better.

    Once that was finished, still had some extreme flakiness ranging from no boot, to only outputting the DiagROM header over serial, to making it all the way but getting address errors while doing memory tests. I used the schematics to make a spreadsheet of each of Agnus, Denise, Paula, and Gary, their pins, signals, and next hop. I then used that sheet to trace each line from each of those chips and check for continuity.

    Animated loop showing the Amiga 3000 running DiagROM with display corruption, including garbled characters, overwriting of the screen buffer, and colour changes

    At this point, this flaky Amiga was driving me nuts. Again, every address line and data line had continuity. The Amiga would even boot into workbench on occasion, provided I didn’t have the second bank of chip ram in, or any fast ram in. Generally, the first boot of the day would work fine, but over time, the flakiness would get worse. DiagROM would start testing RAM and then start throwing address error exceptions, and sometimes just not even get to the point where it would finish the initial diagnostics before failing.

    The address errors led me to believe that I still had an issue on the address lines causing an echo or something on the address bus was getting weird. I tried pulling out chips that were connected thinking they were artificially bringing down lines — ramsey, buster, and the super dmac would all cause things to fail, but the address errors would persist. I put in an older 8372A agnus, but the symptoms were still the same, and I knew the 8372A was good. Running out of ideas, I pulled out the schematics for the ReAmiga 3000 board, converted the board layout to a png, and used a paint app to trace address lines all around the board. I noticed a few address lines went the other direction from agnus over to a 74LS147 TTL IC right next to the battery. I took out my magnifying glass and saw that there was a ton of green corrosion still remaining in the area. Treated it again, and desoldered it — which was a huge pain due to the corrosion and the large ground plane. Replaced with a socket and a new 74LS147, and finished a chipmem test successfully. Got weird display artifacts, and then an address error while testing fastram. Due to the display artifacts, I reseated Denise again, and while boots would happen, there was still definitely some flakiness.

    I was out of ideas that I could point at with evidence, and that’s a lack of experience at work. Running out of options, but desperate that I was so close, I decided that since some of the capacitors were in the battery blast zone, and the machine itself is thirty years old, might as well replace all the electrolytics. I picked up a cap kit full of Rubycon capacitors from Retro Rewind, and recapped the main board and the daughterboard. After that, well.

    At this point, it was just adding back fast RAM and retesting with the Amiga Test Kit until I ended up with a really solid 2mb of chip, and a really solid 12mb of fast, and I’ll finish that out another time. This Amiga 3000 really works, does not crash, passes all tests, I’m super pleased. Next step will be getting a SCSI drive that will partition properly, and potentially a little retrobrighting of this very yellow case.

  • What if I replaced Google Photos? (1/x)

    Years and years ago, as I started using operating systems besides Mac OS X full time, I decided to let go of iPhoto and start doing my photo management elsewhere. I ended up on Google Photos for a few big reasons. One, the launch photo editing was pretty amazing. Two, since the primary interface was web-based, it was easy to use pretty much anywhere. Three, since most of my photos were coming from my phone by that time, having it auto-upload from my phone was pretty amazing.

    Some time has passed, and I’m starting to get that itch again. I still use Android as my primary mobile OS, but I’m less trusting of Google both from a privacy standpoint and a feature standpoint. They absolutely have the ability to mine through my data, even if I am paying for the storage. They also have a terrible track record of removing features and functionality that they feel doesn’t get a lot of traction.

    So, I have a home file server, I have outside cloud backup, maybe the landscape is better now for multi-device photo management than it once was. I’m going to explore.

    What do I want?

    There are some hard points that I like about Google Photos that I’d like out of any solution, and then there’s other functionality that I’d really like to have but wouldn’t stop me from migrating. I’m open to both open source and proprietary solutions, provided the proprietary solution doesn’t limit me to the consuming platform.

    Must have

    • Photos should sync to the destination without me performing the action manually
    • Photos could be viewed, added, or removed from a web interface
    • Albums could be created, viewed, or removed — and photos could be moved in and out from a web interface
    • I should be able to download images locally from that interface
    • Basic categorization should exist automatically…
    • … and in particular, automatic facial recognition should exist and be navigable

    Nice to have

    • Open source
    • Does not require a separate cloud service
    • A server side agent that works on FreeBSD
    • A native application for Android and/or iOS for faster, fluent navigation
    • Google Photos is pretty good at determining other objects, words, and locations from photos, and I’d like to see something similar. For instance, searching for “green”, or searching for “car”
    • Location categorization for determining where photos were taken
    • Video organization along with photo organization
    • Automatic file organization, similar to iPhoto, to make it easier to export, back up, and avoid collision
    • Duplicate detection, in case two photo sources get mixed up
    • Public sharing of photos or albums, to allow those with a certain link to view certain photos without giving away everything

    Where to from here

    At the time of this post, without veering off to other solutions, these are the ones I’m going to be looking at, in alphabetical order:

    • Adobe Lightroom (proprietary, requires subscription)
    • LibrePhotos (open source)
    • Mylio (proprietary, requires subscription, potentially allows for self hosting images)
    • Photonix (open source)
    • PhotoPrism (open source)
    • Piwigo (open source)

    Auto syncing from my phone

    While some of the solutions I’ll be looking at have some capacity for auto sync from my phone, I wanted to at least have a solution to get photos from my phone to my file server without having to mess around with it.

    Enter Syncthing

    Syncthing provides bidirectional or unidirectional sync between folders on two different devices. In some cases, this could be a documents folder on your laptop and your desktop, or maybe important files between work and home. They have agents for Windows, Linux, macOS, the various BSDs, and even Solaris. Even better, they have a first party client for Android. A third party is currently working on an iOS client that will likely cost some money to use.

    I was able to set up my file server and my Pixel 4 very easily, and was able to point the Pixel at the QR code from the file server’s web interface to link up the two devices. By default, the Android client is set up to send pictures one way from the camera folder to another device, so it was a matter of flipping the switch to enable it, and authorizing the connection from the file server and setting the destination folder. All of the NAT traversal was automatic, and within a few minutes, all of the photos from my phone were safely on my file server.

    That seems like a good starting point to me, I’ll worry about a Google Photos export once I find a decent solution.

    More to come.

  • The Ongoing Saga of this Commodore B128 (3/x)

    In the last post, I ended up desoldering some components that I thought could be a problem, only to find that they appear to be just fine. I moved on to second guess my assumptions due to my experience level, specifically wondering about whether these address and data lines are correct. I then sent off all of my socketed chips to another member of the Commodore CBM-II community to see what he thinks.

    Oh, ho, ho.

    My new Commodore friend popped my 6509 CPU, 6526A CIA, PLA, and 3 ROMs into one of his test boards to verify functionality. My ROMs and PLA successfully ran for an hour of diagnostics. My CIA checked out okay (but looked quite different than the CIAs he had). My 6509… was toast. In two different machines, it hung up before it could even hit diagnostics. I don’t know for sure if what he saw was similar to what I see on my board, but it certainly was not computing, and that looked a lot like what I was running into.

    Camera image of the Commodore B128 displaying diagnostic results

    Now, nothing else using the 6509 was released by Commodore, so finding these chips in the wild is rare to impossible. Luckily, back in December, I ordered a Nu6509 from RETRO Innovations, and with any luck, that will arrive soon. The Nu6509 allows one to use a 6502, 65C02, or 65C816S CPU, and adds the memory banking logic of the 6509 to provide a fully compatible CPU for these machines. I ordered it as a “just in case”, and now it looks like we have a winner.

    That said, I’m fully aware that this could be one element of potentially multiple failures in this board, so I am not getting my hopes up.

    In the meantime, I am awestruck by the work of Michal Pleban creating a replacement 8088 card for the CBM-II. Commodore originally created an 8088 board to allow CBM-II owners to use MS-DOS 1.25, however, since none of the I/O ports matched up with the IBM PC, it was DOS-compatible, but not PC-compatible, so of limited usefulness. Michal took the original card design, and created a quasi-virtualization layer to proxy those requests to Commodore hardware. Furthermore, he managed to get FreeDOS running on it from an SD card, making it a fairly usable XT-style machine that can work in high profile and low profile CBM-IIs. Now he has a schematic available, and is building boards to sell this fall. If I get this machine working, that may end up being my next step — unless I can convince him to send me a card. 🙂

    Next update when I receive my parts and my Nu6509.

  • The Ongoing Saga of this Commodore B128 (2/x)

    In the last post, I introduced my US-market Commodore B128 that wasn’t feeling like being a computer. A lot of the diagnostics looked okay, and I was just about to start desoldering components out of a combination of hope and despair.

    Some Soldering Required

    Each desoldered component was replaced with a same-size socket, and continuity tested from the pin receiver to the bottom of the board.

    Step one was desoldering the 74LS275 at U12. I wasn’t sure if there was an internal short that was bringing down D1 at pin 12, and I couldn’t test it in circuit effectively. Once out, I put it in my TL866-II to test, and it tested good. For fun, I replaced it with another 74LS275, with the same results. Drat.

    Second was the RAM connected to D1, at U65 and U73. That is, theoretically, the only other thing on D1. I don’t have a DRAM tester, but I do have some 3764s which should be 1:1 compatible. Popped those in, no appreciable change. Drat.

    Third was the 74S138 at U40, to figure out if there’s an issue with chip select, since what I was seeing in the oscilloscope didn’t really match what I thought the truth table said. It also tested good in the TL866-II. I tried a replacement SN74AS138N1 but that didn’t change any of the chip selects, so maybe I’m reading that truth table wrong.

    Hands in the Air

    It was this point that I started to wonder if I was going to desolder every TTL chip on this board. Due to my lack of experience, I don’t know what these address and data lines are supposed to look like on an oscilloscope, but something about them bother me. It shouldn’t be power ripple, but I just have this nagging feeling that something is affecting the data bus on this board, and that’s why things are getting weird. Furthermore, there’s a huge difference in how the bus looks when the BASIC ROMs are installed versus when they are empty. While I’ve already successfully read them in my EPROM programmer, something is bugging me.

    With that, I’m taking up the offer of another member of the B128 community. He’s going to burn me a new 82S100 PLA, and while doing that, he’s taking all of my socketed chips and testing them in a working B128 board. I still have a feeling everything’s going to check okay, but at least it’ll eliminate those chips, particularly the 6509. Next entry will be after those chips are tested and back in the board.

    1. It’s incredibly difficult finding a 74S138 nearby, though fairly available as used stock on eBay. I went the instant gratification route after reading up on legacy vs modern versions of these TTL chips. The S is a faster max propagation delay (8ns), high power component. The LS was a low power, but somewhat slower (21ns) variant. The AS has a typical delay of 9ns, whereas the ALS is 12ns. Figured the AS was the closest match to the component.