The Commodore 128D Journey Ends

This is the final installment in my four-part walk through of repairing and upgrading my old Commodore 128DCR.

When we left off, I was trouble-shooting a problem with the section of the C128's address bus that touches the back cartridge port.  Several months ago, a lightning storm had sent a surge through the network wiring in my house, zapping a network cartridge in that port.

The four chips pictured above are the only four on that leg of the address bus, from left->right: Character ROM, 2k video ram, flip flop, and bus tranceiver.  The Char-ROM had already been replaced when I first started working on the computer, since it was strange character shapes that told me something was wrong.  It was a failed attempt to use a diagnostic cartridge in the cartridge port that told me that there was still something amiss in that area.

After narrowing down the problem, I ended up replacing the flip flop and tranceiver, socketing them as you can see above.  I then tried the diagnostic cartridge again.

The cartridge did boot this time, so those chip swaps were not in vain.  However, the cartridge would now lock up when it got to the Color RAM test.  This told me that the final unreplaced chip, the 3517B-15 2k ram chip, also needed socketing and replacing.

After doing that, the computer was finally able to run through an entire diagnostic check, finding no other issues.

I was finally able to get back to my upgrades!

The only upgrade I had not yet completed was a second sound chip for stereo sound.  I was going to use a SID2SID board (a pre-built PCB that saves a ton of time and dinky wires for second sound chip installation), but the board did not fit under the C128DCR's power supply.

I also gave piggybacking the sound chips a go, but the legs on those 8580 SIDs just weren't holding solder at the low temperatures, and those sound chips are just too expensive to risk higher temperatures.  For piggybacking, I had even constructed a small signal sub-board, and figured out how to get the filter capacitors on the second chip without soldering them.  However, like I said, piggybacking wasn't happening.

So I went back to the SID2SID board and basically attached an extension cable, so that the SID2SID board could be mounted elsewhere in the case.

To make the board easy to remove, yet firmly mounted, I chose to hot glue the board to a corner of the top of the metal RF adapter case, careful not to allow any short-circuits.  I also chose to use test-lead clips for some of the other necessary signals instead of soldering more wires directly to the board, including ground.  In the end, you can see that it's quite a mess there, but quick and easy to assemble and disassemble when necessary.

A quick test using a type-in program from the Commodore Programmers Reference Guide allowed me to confirm that all 3 voices on both chips were functional.  Since I had clipped the chip select to pin 7 of the cartridge port, the second SID would be found at I/O port address $DE00, which is typical.  However, a switch would allow me to release that port for other uses by shorting the chip select pin on the second SID to 5V (pin 3 on the cartridge port).

All of my upgrades were done!

In the last entry about this journey, you saw that I had actually removed the entire motherboard for the chip replacements.  So now it was time to put everything back together.

Once everything was reassembled, I ran it through one more pass of the diagnostic cartridge (even to the point of attaching the port-testing leads, not shown here) before putting the case top back on.

And that's all there is to it.  All shiny and clean and upgraded! She has:

• All the stock features of the Commodore 128DCR, of course, including 128K of user ram, 64k of 80 column video ram, and 2k of C64 color video ram.
• 2 new built in software packages in a switchable option rom, 
• JiffyDOS kernal rom, also switchable
• Second SID sound chip for stereo music
• SuperMMU 128 for interaction with the SuperCPU accellerator card I'll plug back in
• 4GB UIEC/SD internal compact flash card disk drive, complete with enable switch, as well as forward/backward button for quick disk-image mounting.
• A thoroughly repaired address bus, including 4 new socketed chips.

I hope you found this useful!

The Commodore 128D Journey: Crossroads

Sometimes it is when things seem to be going very well that you discover you've been whistling past the graveyard without even knowing it.

If you followed the first two posts on this journey, you know that we last left off with a final project to add dual stereo SID (sound) chips.  This project has been set aside to solve a more dire problem.

At one point, I paused to run a full diagnostic on the Commodore 128DCR, to make sure everything was OK after all the insertions and removals of the MMU that came from messing with the sound socket (shown above).  That's when I discovered that the diagnostic cartridge, which works fine on a flat C128, didn't boot at all.  Testing other cartridges revealed the same behavior -- cartridges simply would not boot correctly.

However, everything else about the computer SEEMed fine.  C64, C128, and Z80/CPM modes all booted normally and ran software normally.  Everything seemed OK.  But cartridges were definitely not working.

Luckily for me, while the C128 diagnostic cartridge would not boot at all, it would crash into the C128's Machine Language Monitor program, allowing me to take a quick glance at the code in Bank 10, addresses $8000 - .   That address is where the software of the ROM chip inside the diagnostic cartridge would be mapped to in the C128's memory.  $8034 also happened to be where the cartridge software would crash. Using the ML Monitor to disassemble that area of memory revealed, unsurprisingly, that many of the ML commands were corrupted, but only maybe 10% of them.  For some reason, this suggested a problem with the Address bus, which is one of the most complicated systems inside an already complicated computer like the C128.

You see, if one of the many chips that translates and routes a particular memory address to a particular chip in the system has gone bad, this would explain why some entire ROM bytes are being presented incorrectly to the ML monitor (and the CPU!).  Since I know the data inside the cartridge is good, and the data is not generally scrambled, I dismissed the Data bus as a possible culprit.  No, my focus would be the complex Address bus.

To solve this problem, I removed the motherboard from the computer and Got Serious.

I began running other tests, and taking care of some low-hanging fruit:

• I carefully cleaned the pins on both cartridges, and the cartridge port.  No help.
• I tested continuity between all cartridge port pins and an external cartridge.  All checked out.
• I wrote and ran a BASIC program that tested as much of the RAM chips as it could.  No errors.
• I swapped out the 8722 MMU (shown above) since it was socketed, and I have several spares.  No changes.

Since I had decided to focus on the Address bus, and had already tried the MMU, I decided to go after the MOS 8721 PLA (Programmable Logic Array). While the PLA is not socketed, I did have several spares, so it seemed a relatively harmless thing to try.  So I snipped out the old PLA, did one of the best de-soldering jobs of my life to remove the pins and clean out the holes, and soldered back in a precision 48 pin socket.  I went slowly and carefully -- It took all of an evening.  

But when I put the new PLA into the socket and powered on the computer with the diagnostic cartridge in place, nothing had changed.  It was all for naught and I felt like an idiot for risking that part of the motherboard.

I was now at a bit of a loss, so I decided to go back to the beginning and focus on the information at hand: the cartridge crashes into the ML monitor, and I had access to the Machine Language commands and bytes, corrupted versions of those in the diagnostic cartridge, that were causing the crash.  I went online and actually found a binary copy of the firmware for one of the diagnostic cartridges (the one on the left in the picture above, marked simply "C128").  The firmware is for Commodore 128 Diagnostic Revision 588121.  You can download it yourself here.

Having access to the bytes that SHOULD be shown in the ML Monitor but were not, I printed out those correct bytes on a piece of paper, and compared them to the bytes shown in the ML monitor.  Whenever a byte did not match, I crossed it out in blue and wrote in the Corrupted byte shown in the ML monitor.

As you can see, there were several bad bytes discovered.  Upon reflection, I realized two patterns in the bad bytes:

1. Every bad byte was at an even numbered address: $8024, $802e, $803a, etc..
2. Every bad byte was strangely *close*, in value, to the byte after it, often matching exactly: $9f/$9a, $cd/$ca, $20/$20, $00/$00, $00/$06, $00/$00, $9d/$9d, $bd/$bd, $9b/$9b, $80/$80...

Both of those facts made me seriously think that something might be wrong with the Address line that handles the first/lowest/0 bit on the address bus, often called 'A0' on schematics.  If this bit were being incorrectly held high, then attempts to read even numbered addresses would instead grab values from the odd numbered one right after it.  

So back to the schematics I went.  I learned that the low address byte on the cartridge port is part of the "SA0 - SA7" address bus.  The high byte is called the "TA0 - TA7" bus.  The SA lines are my focus.  They touch several chips in the upper-middle area of the motherboard, including, strangely enough, the MOS 390059 Character ROM chip.  If you recall, replacing a bad Character ROM was what actually started this entire journey, so, in a way, I had my first confirmation that I was on the right track.

Further study of the schematic shows that this SA0-SA7 address bus touches four different chips: the Character ROM, a color memory ram chip (?!), and two other chips (a tranceiver and a flip/flop) which appear to translate other address busses: the main 'A' CPU address bus, and an address bus called the 'VMA0 - VMA7' address bus (I did warn you this computer had a complicated address bus system!).  Those chips, at locations U55, U17, U18, and U19, are pictured at the bottom left of the photo below:

And this is where I will end our journey today.  My next step will be to tackle socketing and replacing those two address bus translation chips, starting with the transceiver (a 74F245N), since it handles translation for the main address bus.  Hopefully, my next entry on this journey will regard its end.

Good night!