• A Macintosh LC Out of the Spotlight

    The Macintosh LC was a mid-range computer released in 1990, as part of a trio of new Macs (including the Classic and IIsi) allowing Apple to target a more cost-sensitive user. At $2,499, it was the lowest cost colour Macintosh released at that time. It was hobbled intentionally by Apple from the getgo. While the 32 bit 16 MHz 68020 wasn’t necessarily a bad processor, Apple saddled it with a 16 bit data path, didn’t provide a way to add a FPU, and limited the maximum RAM to 10mb. To add insult to injury for a wistful retro enthusiast, the LC was the last nail in the coffin for the somewhat more interesting IIgs.

    Nevertheless, this was a machine I wanted so badly at launch. I had a Macintosh 512Ke at the time, and the idea of having a colour Macintosh for what appeared to be a reasonable price was really alluring. By 1990, a black and white Macintosh with 512k of RAM and a 68000 was already losing usefulness. Unfortunately, it was only a reasonable price compared to other Macs, and it just wasn’t in the cards for me. My school got a couple, though, and I was able to play with some great applications while there.

    I picked up this particular machine from a local computer reseller. It was obviously turned in, but far too old for this particular retailer to reasonably sell. I found it on Facebook for a price I was comfortable with and brought it home. The machine was in pretty great condition, inside and out — no major damage, no obvious leakage anywhere. Booting it up for the first time gave me a display, but a flashing question mark and a grating squealing noise. There was absolutely a hard disk in there, but maybe it had been wiped, or maybe it was the source of the noise. I inserted a System 7 floppy, and it brought me to a desktop. Drive Setup didn’t see anything on the SCSI bus and the sound was driving me nuts, off it went again.

    I opened up the LC again. I first assumed that something was going on the power supply to make the squealing noise, but the power supply was quiet. The hard disk was spinning up on boot, but I couldn’t hear it seek at all. The squeal was louder, though, but it turned out to be coming from the speaker. Oh, right, we’re in the 1990s now, and these are surface mount capacitors. I wondered a little if the capacitors had anything to do with SCSI being functional. A quick browse to Console5 to order a new cap kit, and I wrapped up the machine to work on later.

    Capacitors in hand, I opened up the machine and removed the board. The LC uses captive plastic brackets to mount the board to the case, so it’s incredibly easy to remove. There are 17 capacitors on the board, all sitting near some melty plastic, but this was pretty easy compared to the Amigas. I have been using the controversial twist and remove method to get rid of the caps, used braid to remove the remainder of legs and solder from the board, and replaced each with their appropriate cap. I then rinsed the board with flux remover and alcohol to get rid of the soldering debris as well as the left over capacitor “juice”, and reassembled. The machine turned on, and the squeal was gone. Unfortunately, still no disk.

    Doing some web searches on old Macs and their disks, turns out that old SCSI drives — Quantums in particular — had a tendency to have their heads stick to the bumpers on either side of the platters. Figuring I had literally nothing to lose by trying, I removed the cover of the hard disk and found that no obvious damage was there, but the head was not planted up against a bumper. I powered it on while open, and the head simply would not move. For grins, I put a shim around the rubber bumpers on either side, even though they didn’t feel sticky or tacky. I then powered it on again and started lightly tapping on the head until it started seeking… and the Mac started booting. I immediately powered down. I added a little bit of oil to the head and reassembled the disk. One last power up, and it boots! Before buttoning up the machine, I replaced the PRAM battery with something from this decade, and added 2 4mb SIMMs for a total of the maximum allowed 10mb of RAM.

    The disk itself had System 6.0.8 and a wide variety of personal documents and kid projects dating up to 2001, which is a heck of a run for a 4mb 68020 Macintosh. I took the opportunity to make some System 7.1 floppies, wipe the drive, and create something close to period correct. With the keyboard and mouse already in working order, that was about it, this Macintosh LC lives to be admired for another day. As a future to do, I am very likely to replace the hard disk. That head is probably going to stick again, and those platters looked absolutely terrible. It’d be fun to increase the VRAM on the machine as well, if something reasonable comes along. Even better if I could find a IIe card for the PDS connector, but I don’t think a reasonable one will come along…

  • Varta’d by the Amiga 4000

    In very early 2021, really bored by the pandemic, I was on the lookout for busted Commodore and Amiga machines. Someone reached out with an Amiga 4000 they had available. They had no way to test it, all of the cables and accessories were missing, and it’s been in a garage for decades. Sounds like my kind of thing.

    The Amiga 4000 was the last of the “big box” Amigas, and a pretty decent last hurrah for Commodore. Housed in a fairly generic PC-like desktop case, the Amiga 4000 had a 68030 or 68040 processor, 2mb of chip RAM, up to 16mb of fast RAM, the new AGA chipset providing enhanced graphics, and IDE instead of the SCSI of the 3000. There has long been a debate on whether the Amiga 3000 or 4000 is the superior machine, with a lot of gotchas. I think they’re both fantastic machines with a ton of expansion opportunities, but for me, the edge goes to the 4000 with AGA. Why Commodore didn’t include the scan doubler on this one eludes me.

    Taking Inventory

    View of the clock portion of a Commodore Amiga 4000 motherboard still mounted in its case, covered in a blue-green hue due to the damage from battery leakage

    This 4000 looked and smelled like it had been in a garage for some time, and after coming inside and warming up, you could smell the leaking capacitors. Pulling off the case revealed a motherboard awash with blue-green from a long-leaking Varta clock battery. The green was in the case, on the pins, between the slots, and even on the pins of the 2 DE-9 joystick/mouse connectors. Along with that, the 4000 suffers from the same issues as early to mid 1990s Macintosh machines, where the SMD capacitors weren’t all that great, and failed by leaking electrolyte as well. That’s two major sources of trace-eating damage, and this one was full of it. I may have bitten off more than I could chew.

    View of the clock portion of a Commodore Amiga 4000 motherboard separated from the case, covered in a blue-green hue due to the damage from battery leakage

    On the plus side, this came with everything and then some. It already had a CD-ROM drive, the original floppy drive, a working power supply, and some additional Zorro cards to be investigated later. Once I got under the drive cage, the best surprise appeared, a Warp Engine 68040 card with 32mb of RAM on board, expandable to 128mb. If anything, that would be useful in another machine if this never came back to life.

    Clean up

    Top down view of the Commodore Amiga 4000 motherboard, after a round of cleaning

    Job one was to get rid of everything that could be continuing to damage the board before actually trying to fix anything. First thing was snipping off the battery with side cutters, then lightly scrubbing the board with isopropyl alcohol to get off the initial battery fuzz. I desoldered and/or removed all of the capacitors, and pulled out all of the jumpers and socked chips. From there, the board was covered in paper towels soaked in vinegar to neutralize the chemicals eating at the board, followed by a scrub with soap and deionized water, followed by isopropyl alcohol. The end result didn’t look too awful. There’s obvious damage where the battery was, one of the capacitor’s pads completely lifted off the board due to the damage, there’s some corrosion on the backing plate for the DE-9 connectors, but most of the stuff is still there.

    Doing a continuity check around the clock area of the board showed at least nine connections that were not meeting up. In many of these cases, the connection between a pad and a trace was missing, so at the very least, there is going to be some bodge work.

    Half the effort in twice the time

    As I was early in my learning to repair adventure, I was methodical but naive. Each of the electrolytic capacitors was replaced, and for the one with the missing pads, wires were attached to the via on each side and strung to the capacitor. I dutifully added bodge wires to each of the nine connections that were missing, and verified the connections with the multimeter. Everything seemed to be in order, at least from a connection perspective in the clock area.

    The power supply was disassembled and cleaned out, as it was full of all the things one would find hidden in a machine after being stored for a few decades. All of the rails tested out okay with a multimeter, and I couldn’t see any obvious damage to the capacitors on the power supply board.

    For fun, I attempted to boot the machine. It did power on. It showed a grey screen and nothing more. On one hand, at least we have hsync and vsync, on the other hand, we don’t even know if the CPU card works or not — the power LED sure didn’t get any brighter. Still, that’s progress. After running out of reasonable ideas for a next step, this 4000 went on a shelf for a while so I could find some successes elsewhere.

    In the middle of my Amiga 3000 repair, I had the chance to test the Warp Engine on that motherboard, and it worked. I couldn’t use it permanently, for multiple reasons. The Warp Engine is the wrong size to fit around the 3000’s daughterboard, and there’s no way to fit the drive cage over it with the way the memory is positioned. At least I knew it worked. Knowing that I had a valid and working CPU, and now that I knew about DiagROM, I threw the DiagROMs in the 4000 to see what would happen. It sure didn’t give me a display, but it absolutely gave me output over serial… though e x t r e m e l y s l o w l y. Fewer than 10 characters per second. It gave me hope that this board could return to life, or at the very least, there were some good components left on here.

    More effort with more thought

    As I mentioned, I was methodical but naive. There are a bunch of small ICs near that battery, particularly two 74HCT166 at U975 and U976 and a 74HCT174 at U177. A bunch of those bad connections were on the U177 which meant a lot of damage was done to the board in that area.

    I assumed at this point that the chip was also bad much like the connections beneath it, and took it off. Out of an abundance of caution, I also yanked U976. I assumed U975 was good since DiagROM booted at all, and there’s a pin on U975 that is required for anything to happen at all. I removed them extremely carefully, but a ton of pads on U177 came with it, which meant they had completely detached from the board anyway and were only held down by the pressure of the IC on the other pads. That sure explains the number of busted connections. U976 came off cleanly. I cleaned the whole area well, and scraped the corrosion off the remaining pads. I attached a new 74HCT166 to U975, which went shockingly well. Checking continuity showed that two of the pads off U976 did not make contact with the resistor bank below, and so two wires had to be bodged from the chip to those resistors. Then, turns out the +5v on the other side of those resistors was not making contact, and so wires had to be placed between the vias and the resistors. One via was too badly damaged, so the wire had to be wrapped around the edge of the board to the capacitor feeding the 5v on the other side of the board.

    I started the machine, and DiagROM started! and died!

    It did not come back.

    Using the oscilliscope, I started poking around at signals, not really finding anything amiss. There’s a 74F245 at U891, and its job is to handle signaling of fast RAM. I didn’t have any fast RAM installed, as it’s sitting on the Warp Engine, so I hadn’t bothered checking it until last. As I’m probing, I touch it to the ground pin in the lower right of the chip, and it springs to life. More trace damage. Turns out the ground on that chip is important, even if you don’t have any RAM… I took the opportunity to drag some flux around all of the ICs in the area, and apply some fresh solder around each.

    DiagROM System Information screen on a Commodore Amiga 4000, showing all resolved custom chipset registers, fully detected 2mb of Chip RAM, a passed ROM checksum test, and the detected 68040

    We have a winner. DiagROM started up just fine, detected the CPU, chip RAM, fast RAM just fine. I ran a full memory test, as well as the CIA/IRQ tests to make sure those survived okay, and things were going splendidly. Everything seemed to pass! I swapped out the ROMS with the Kickstart ROMs it came with and started it up. My bench LCD lit up, then went back to power save mode.

    Back to the scope.

    I couldn’t find anything. Everything seemed to be okay. For grins, I hooked the 4000 up to a Commodore 1084S wondering if somehow I was using a screen mode that was not supported. Turns out, yes. I still don’t know why that’s different between the 3000 and 4000.

    Commodore Amiga 4000 boot screen of the 3.00 ROM, requesting the user to insert a floppy

    That was an excellent sign. What I still had was some extreme flakiness, occasional nothings on power up, and no boot to Workbench. While finding the issue with U891 earlier, some of the probing would cause the board to work, and I was seeing similar results here. I realized that it wasn’t necessarily the act of probing causing things to work, but the logic board slightly bending when probing certain areas. Heading back to the oscilloscope and tracing around the same area, it became obvious that the +5v connections on the bottom of the set of resistors near the edge of the board were not all completing. In fact, only one resistor was consistently getting +5v, and the only reason anything was working was the voltages generated on the other side of the resistors or the occasional connection that occurred when the board was bent slightly. Not a great situation. I started bridging the connection from the input side of the resistor to the vias on the board just below providing the +5v with short unshielded wire, but it looked incredibly messy. Instead, I used slightly longer wire with the sheath still on, and created a line of curved/looped wires instead. One via didn’t have enough viable copper to create a good connection, so a wire was looped around the edge and connected directly to the capacitor on the other side. Sure, it’s still ugly, but easy to understand what’s happening.

    Eight SMD resistors with their inputs connected to the vias below them

    That fix sealed the deal, and we had boot. I still hadn’t connected the real time clock latch at U177, as the chips I had ordered long ago were not the correct size. The 4000 will happily boot without it, though, you just can’t save the time. I was able to connect up a gotek and run Amiga Test Kit successfully, with everything except the clock passing tests. The memory on board the Warp Engine checked out just fine, so it was time to make it do something real. I connected a CF card and adapter to the IDE interface, pre-configured the card on WinUAE with Amiga OS and some games, and booted it up. Everything was checking out fine, I was able to play a couple of games and listen to some music, and sat a little surprised at how well it was working considering what a hack job it was.

    The hack job gets worse

    As mentioned, U177 came off with a bunch of pads. I made an attempt to connect some slightly thicker wire from the vias underneath where the chip was to where the pads were supposed to be, in preparation for the IC replacement. I received a batch of 74LS174 SOIC, and finally got around to putting it on the board. Carefully balancing tweezers, a pre-tinned pad 9, and the 174, I put down the first leg of the chip successfully and delicately started working on each new leg. Much of the pads on the “left” side of the chip (pins 9-16) aren’t connected to much, but those were the pads I had. That side went well, and the chip was fairly secure. I started work on the right hand side, and it all went downhill fast. The heat of the iron against the wires had a tendency to desolder them from their vias given how little was actually adhered. Instead of trying to do the same thing again, I pulled out those wires out completely, and soldered legs to the remaining pads on that side of the chip. Resigned to more bodge wiring as there were already missing pads on the left side, I went for the remainder.

    A blurry picture of a hot mess of bodge wiring around U177 on a Commodore Amiga 4000 motherboard

    In total, pins 1, 2, 3, 5, and 9 all had to be hand wired to the resistor pack above it, to a via near it, or to resistors on the other side of the board. The above blurry picture is in the middle of the process, as I was merely trying to see if it would work, but hadn’t shortened or cleaned up the mess.

    The chip itself checks out just fine, the wiring is all beeping out on the multimeter, it’s ugly as sin.

    Guess what, though? Clock found.

    Pure Amiga goodness

    I’m still left with something of a hack job. The board in this machine is so very far gone, and I have no way of knowing for sure that I’ve neutralized all of the damage. The number of visible traces around that part of the logic board is worse than I’ve seen so far, and I’m frankly surprised at how well the machine works now. Given that all of the custom chips are working great, and all of the supporting hardware is functioning normally, this could be a good candidate down the road for a A4000 replica board or an AA3000+. It’s possible that I won’t bother deciding until something else fails horribly, but as it stands, this machine is going to be staying in the permanent collection due to the amount of failure.

    That said, all of the traces were covered in enamel and double checked. The case went through one more round of vinegar treatment on the places that battery corrosion had leaked onto the metal. It also had a re-clean, as I hadn’t cleaned it since early 2021. I reassembled the board back in the case, which was incredibly challenging as it had been disassembled since January of 2021, but made it. I reinstalled the Sunrize AD516 sound card that came with the machine, along with a freshly upgraded CyberVision 64 that came with another machine. Booting up the machine looked downright perfect, and I’m still in awe that this machine was so far gone and yet boots up into a modern Amiga OS without any real difficulty.

    Next up is some minor work to make it a better machine long term. The CD-ROM has an obvious stripped plastic gear, you can hear it when it first spins up, though it doesn’t affect its ability to read. I will probably replace the whole device. I have RAM on order to bump the machine from 32mb to 128mb. I’d also like to get an IDE splitter to allow the CF card to mount in one of the slots at the rear of the case while still having the IDE CD-ROM work in the front.

    Other than that, it’s pretty great to have an Amiga 4000 around.

  • The Ongoing Saga of this Commodore B128 (4/4)

    In the last post, I found out my MOS 6509 was garbage, at the very least, and was waiting on an order of a Nu6509 from RETRO Innovations. There were some delays in receiving PCBs and getting them soldered up, but it finally arrived a couple of weeks ago. In the meantime, I ordered a WDC 65C816S CPU to pop into it.

    The great news was that it booted up to a screen I’ve literally never had a chance to see on this machine. The bad news is that any command I’d enter would result in a trap to the built-in monitor, with a program counter somewhere in the BASIC RAM space. To add insult to injury, at some point while debugging, the whole thing went dark again, going back to the symptoms before. It felt like I was starting all over again. I packed it up and put it on a shelf, too upset to keep going with it.

    Well, time to drag it out again. Given how the last three machines have worked out for me, I knew exactly where I was going to start before digging any further holes — I’m recapping this thing. No readily available recap kits, so Mouser to the rescue, once you have the list of capacitors you need. It was incredibly uneventful, no ridiculously large ground planes, no battery leakage to power through. The capacitors all were somewhat within spec, so it may not have been needed, but at least it has another 40 years of life.

    Once I powered it up, it was exactly as I left it. Power is fine, screen isn’t behaving. I decided to go a different route, and I used Ben Eater’s 6502 project to test my 65c816 and 65c02 chips to make sure they’re working the way they should. On rare occasion, the Commodore would boot to the initial prompt, but would either provide a syntax error for anything read, or freeze entirely for any command.

    I remembered reading that on the Commodore PET (at the very least) what you typed didn’t go into any sort of buffer RAM, but was just sitting there in video RAM, and the machine would read what was typed right out of video RAM. If that was the case here, maybe these syntax errors or occasional start issues had something to do with the access to video RAM. I checked the lines in and out of the video RAM, and the chip itself seemed to be responding properly. Moving backwards to the latch at U8, power looked good, and while I was holding the oscilloscope probe to OE to watch the signals on power on, it booted. Not only did it boot, but it started executing commands. Not only that, but my AV2HDMI started working due to proper sync.

    Screen shot from a functional Commodore B128, with the opening 'commodore basic 128, v4.0' boot message, and a BASIC program that repeatedly outputs 'omg, it works!'

    Hot dang. I reflowed the joints on U8 thinking this was a cold solder joint situation. Thinking back to the original issues, moving and pulling chips nearby could have easily caused movement of that joint, causing intermittent issues on the data bus, power fluctuations, and so on. That, combined with a loose socket for the CPU, easily explains the last part of the symptoms I saw. I’ll take that win.

    Further testing is showing that this thing is now fully working, and while some of those chips didn’t need to be desoldered and socketed, it’ll help for any future work that’s required. The worst part was reassembling the machine. It’s been disassembled for over a year and a half, I had a hard time remembering how the jigsaw puzzle went together. Next steps? See if I can get my SD2PET Future to cooperate with the B128, order Space Chase, and maybe see how those 8088 boards are coming along.

  • 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. The CIAs tested OK, serial was functional, Paula pushed out sound just fine. The only real issue was the Enter key did nothing, no matter how firmly it was pressed. 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.