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.

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.