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:
- Every bad byte was at an even numbered address: $8024, $802e, $803a, etc..
- 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.
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!
I hate it when you get to the end of the episode and you get the, "to be continued" message! Your story remind me of an airplane transponder I had once that had the least significant bit in the final octal stuck high...
ReplyDelete