Fixing a Poorly Commodore 64 (Part 3)
So far I’ve been able to test the 6510 CPU using a NOP tester circuit on a breadboard, the 4164 DRAM chips using a £20 Arduino-based DRAM tester by Stephen Vickers, and the logic chips using my trusty TL866II+ EPROM programmer.
Which got me thinking. Is there an easy way to test whether the PLA I’d removed from my C64 was working or not. Like the MOS logic chips, these have a reputation for failing. Modern replacements are readily available, but it’d be nice to have a simple test to determine, for future repair work.
I was getting ready to breadboard a test circuit when it occurred to me that I may be able to test it using the TL866II+ EPROM programmer. Since version 10.61 of the Xgpro software I’d noticed that it is possible to create user defined tests for logic chips. And as the C64 PLA is essentially a large combinational logic chip, I should, in theory, be able to test it in the programmer.
Either way, I’d need a logic or truth table to determine what the normal operation of the PLA is. Thankfully I found one online, in a copy of an article in Volume 6, Issue 5 of The Transactor Magazine.
Testing a Commodore 64 906114-01 PLA with a TL866II+
The PLA takes 16 inputs from various parts of the motherboard and produces 8 outputs, which are used to switch in RAM, ROM and devices in the 6510 memory map. Armed with this knowledge, I had a crack at converting the truth table to work in the Xgpro software bundled with the TL866II+.
First, I transformed the table by effectively rotating it 90° and ordering it by pin number.
I then entered the spreadsheet data into the software more or less as-is, by adding a new row for each of the 26 tests, and setting the pin states for each test accordingly.
On the first attempt it failed. I’d forgotten to pull the OE pin low. This was fixed by setting pin 19 to 0 for all tests. I eventually got it to pass all 26 tests, with just one anomouly.
If you look back at my translation of the original truth table, you’ll notice on the 26th line I’ve highlighted the L for pin 18 in red. I could not get this test to pass. It didn’t matter if I marked it as H or L, so got around it by ignoring it in the test. I assume that output is floating for some reason, rather than being pulled up or down.
Anyway, I’m not sure whether this is an issue with the test, the PLA, or the original documentation. As the PLA has passed all other tests, I’m 99% certain that it is not an issue with the PLA, and will investigate that later.
Update: 23/03/2021
In the latest version of Xgpro (10.80) it is possible to export and import custom tests from the logic test screen. You can downloaded the spreadsheet and logic (lgc) file here: C64-82S100-PLA.zip. This may save you some typing. I’d be interested to hear how you get on – I’ve only tested this procedure on a couple of PLAs to date.
Update: 24/04/2021
A member of lemon64 with the handle ceebee tested the procedure on a GAL-based PLA replacement chip that was working fine in a C64 as far as they were aware, and noted the following errors during testing:
- Lines 4 & 5: Pin 11 (L)
- Line 6: Pin 12 and 18
- Lines 7 to 10: Pin 12 (L)
- Line 11: Pin 12 (L) and 18 (H)
- Line 12: Pin 13 (L)
- Lines 13 to 15: Pin 15 (L)
- Line 14: Pin 15 (L) and 18 (H)
- Line 17: Pin 15 (L)
- Line 26: Pin 15 (H)
However, other users have tested the following replacement PLAs successfully using this method:
- A GAL replacement (PLA20V8) using 25ns GALs
- A Philips PLS-100N programmed and supplied by Mutant Caterpillar
It does mean that this test is currently only valid for original 82S100 (906114-01) PLAs. It should be possible to adapt the test by making it less exact (ignoring those outputs) for GALs.
I’m not quite sure why ceebee got so many fails during testing. Maybe it is a by-product of the GAL being independently reverse engineered. It is also possible that GALs from a different manufacturer may produce different results. Anyway, as a principle I think this method is a sound, and I will be using it to test PLAs, and similar chips, in future repair projects.
Update: 09/04/2021
A good friend on Twitter @evolutionalgd and I got chatting shortly after I figured this out. We both agreed that the Xgpro editor was a bit of a faff, especially when entering large truth tables. Anyway, to cut a long story short, he went away and developed a rather natty command line utility that allows you to convert Xgpro lgc files to and from human-readable files in TOML format that can be edited quickly in a text editor like Visual Studio or Notepad++.
It’s written in Go, and there are instructions on compiling this to the OS of your choice. I’ve tested it on MacOS Big Sur with no issues.
Link to the project’s repository here: https://github.com/evolutional/xgpro-logic