Commodore 64 PLA replacements

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

A common cause of  a black screen*, garbage on the screen, intermittent startup or general instability in Commodore 64's is the 906114-01 PLA chip. A custom gate array chip which handles all the address decoding in the C64. As usual, original stocks dried up many years ago, but there are various options to replace these. It is sometimes a bit of a lottery, as the timing in the C64 was never quite right. You can get a C64 that will only work with some PLAs, or PLAs that will only work in certain C64s.

I've tried various things in the past, a popular option is to use an EPROM to replace the PLA. This just need a bit or rewiring, I've tried that a few times (see previous article on C64 EPROM PLA replacements). It sort of works, but with mixed results, better on some boards than others.

There are a few designs around using CPLDs, but most of the 5V ones have been discontinued, so they would need 3.3V to 5V level shifters  on the outputs. I did try building one with two GAL chips a couple of years ago. I'm going to revisit that at some point, as it should be viable, but I haven't quite got the equations right yet.

Timing seems to be an issue, only certain EPROMs seem to work at the right speed, the Atmel AT27C512R-45PU (45nS) being a good choice. It appears the reason for the timing issues is that one signal (/CASRAM) needs to be delayed a little longer than the rest. When designing the two GAL version above, I passed that signal from the first chip through to the second to get the additional delay. That led me to adding an additional gate delay onto the EPROM board. I built this one with TTL logic gates buffering the /CASRAM signal between the EPROM and the board, shown without the headers for clarity.

The jumpers select 1, 2, 3 or 4 gate propagation delays, adding around 30 to 120nS to that signal. That works well in a lot of cases, 1 or 2 delays (30nS or 60nS) seems to be good for a lot of boards. Another simple option demonstrated in this video shows you can get a similar effect by adding some additional capacitance to the pin.

I've built up some boards with space for a suitable capacitor, 68 or 82pF being around the right value. It should probably be an RC filter, but just the C seems to work.

I've tested this on several boards, and it seems to work quite well. Testing over several hours with the diagnostics cartridge and test harness and with an assortment of games it seems to run well,

I dug out a a couple of boards which has been a bit picky about PLAs in the past, one liked it, one didn't. I've used turned pin headers which fit into most sockets. I've had a few boards with intermittent sockets, so it is worth replacing them with turned pin sockets. Also in a fit of optimism, some boards actually have the PLA factory soldered in.

After all the above photos, this one may look like a mistake, I've put the PLA in the socket at the back of the case, not the middle. Bit it isn't a mistake, at least not a mistake by me. The PLA is indeed in a different place. For some reason Commodore had a board that had been around for several years and several revisions with the only two 28pin socketed chips close by each other in the middle of the board. When they came to revise that board, not much else changed (apart from the VIC II and surroundings). But some clever chap decided to swap around the SID and the PLA between the two most common versions of the C64, the 250407 and the 250425.

What's great is the SID has 12V on pin 28, and the PLA has 5V. Get them the wrong way around and you fry the PLA. If it doubt, power on with both sockets empty and measure the voltage at pin 28, or look for the two capacitors around pins 1-4 of the SID. I've had at least one C64 arrive with those chips the wrong way around, and a baking hot PLA running at 12V. Since the PLA outputs are pulled up to it's supply voltage, that also sends up to 12V to some of the pins that are outputs on the PLA. On the SID these pins are some of the data and address bus, so can send 12V to most of the chips on the board. Oh dear, not a good move.

I have some of both the logic gate delay and the capacitor delay board. I can supply these with a programmed 27C512, tested on some of my Commdore 64's.Whether they work on your particular C64 is difficult to say. It would be nice to have a guaranteed replacement, but no sign so far.

* N.B. when I say black screen, this is video sync but only a black screen displayed. This is different from no video sync, which usually indicates the VIC II chip is at fault.

Commodore 8032 Mainboard Repair

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Another 8032 board in for repair. I seem to be doing quite a few of those at the moment. They never fail to disappoint in the range of weird ailments. It's the traditional black screen, no beep, a generally dead computer. The owner has previously attempted to get this running, replacing four of the ROMs with 2532 EPROMs, and replacing the four 2114 video RAM chips.

There were a few suspicious looking solder joints, but these boards can be difficult to work on, so that is understandable. Usual first tests, power, reset, clock all came out OK, although the reset pulse was a bit slow, three or four seconds, it's normally a second or so. So time for the ROM/RAM replacement board.

With the ROM/RAM board in place and set to replace the onboard ROM and RAM the system booted. Checking individually, there was a fault in the RAM, and with the RAM replaced, the onboard ROM would beep, but not show anything on the screen. This usually means the kernal is getting somewhere, but not far enough along to start BASIC. The other issue was the screen.

Quite a nice pattern, but that's not much use. Looking closer, it appeared the text was being displayed, but the right hand half of each character was a solid block. You can just make out the 31743 bytes free and ready prompts.

The 80 column video circuit on the Pet is quite complex, and there is a lot of odd / even split, and it uses pairs of 2114 SRAM which are 4 bits wide each to give the 8 bit character. It's very tempting to start looking at all the odd and even bytes parts, and the buffers that only affect half of the byte. The section outlined in red is the video circuitry, and most parts of it operate on only odd or only even, or on half bytes.

But you have to stop and think about the Pet. It has no pixel graphics capability. All of the above things are working at the character level, so when they go wrong, you don't get half a 'b' in 'bytes', you get half of the bits that make up the character code for 'b' (0x42), so it won't be a 'b' at all, but 0xF2 or 0x4F if the bits are stuck on, 0x02 and 0x40 if they are off. That isn't what is happening, it's actually in the pixel that make up the 'b', and that narrows it down to only two candidates, the two chips on the left of that red box, the character ROM and the 74166 shift register.

Testing that was easy. I removed the character ROM, and I still saw half blocks on the screen, so the culprit was the shift register. This takes a line of the bitmap of the character from the character ROM and sends it out to the screen a pixel at a time. Replacing that and the display was restored.

Well, I say restored, there were a few random characters, usually @ symbols on the screen. This seemed to get worse when the screen was scrolled. This is a simple test program that is meant to alternate \ and / characters to make up a random maze, but the more it scrolls, the more @ symbols appear.

I went to a simpler test program:

10 PRINT ".";
20 GOTO 10

This produced a screen half full of dots as expected by also a random collection of letter n's.

Here '.' is 0x2E in PETSCII and n is 0x4E, and on the boot screen, @ is 0x00  and it should be space (0x20). It looked like one particular bit was wrong in the value being fed to the character ROM, so it could have been the input buffers or output latches or the 138 that does the timing not pulsing the write for long enough. But, it did look like it was the video RAM. It could have just been one bad bit on one RAM chip, but there were some n's that were on the alternate characters (i.e. .n.n.n.n would mean just the odd or the even, ..nn.. would mean both). I replaced all the video SRAM with good chips, and it was fine. The 2114 that had been replaced passed memory tests, but I think were just a bit slow to cope with rapid screen fills. With the video RAM replaced, and the screen was back to how it should be.

Now I could get on with the rest of the testing. Memory tests showed one faulty 4116, so I replaced that with a similar spare. This time I soldered it in place, as these MOSTEK ones all seem to have short legs and it didn't sit well in a socket. You'd hardly know it was there.

The ROMs were still not able to boot. I tried a full set of known working 2532 EPROMs, and got the same result, so I tested for continuity and found a few bad connections. I decided the best approach was to removed and replace all the ROM sockets.

The tracks underneath were in good condition, and all continuity tests passed with no sockets, so I installed a new set of sockets and tested with a set of known working ROMs. That worked, so I want back to the set of 2532's that came with the board, and they all worked as well. With those labelled up, it was back in business, running on it's own ROM and RAM.

Further testing showed no response from the IEEE-488 port with one of my pet microSD disk drives plugged in, and no response from either tape. Oh, and it is still slow to reset. Tape 1 came back after cleaning the connector, I've found the best way with those is to re-tin them with fresh solder, and then wick most of it back off with solder braid.

I cleaned all of the connectors and but still no tape 2 or IEEE-488. The IEEE-488 connector is gold plated, so I didn't want to tin that, I checked for continuity, and all the connections were going through.

I used the debug output from the pet microSD to check what was coming through, and it was getting a request, but the handshaking wasn't working. I could see the name of the file I had tried to load, so the data lines looked OK. That rules out one 6520 and two of the MC3446's. The one chip that does handshaking and tape 2 is the 6522. I removed and socked that and installed a new 6522 and that brought back the IEEE-488 port and tape two.

So that's it pretty much sorted, other than the slow reset. I had noticed some of the capacitors were in a poor state, including the one on the 555 that generates the reset signal. I don't normally replace the capacitors on Pet boards unless they appear damaged, or are not preforming properly. In this case it was both, the covering was shrunk and split on several of them, that usually means they have got rather hot at some point. I went though and replaced all the electrolytics, bar the large one, as that seemed OK and is difficult to get one with the right lead spacing.

Testing the caps, some were still OK, but several were out of tolerance and had quite a high ESR.

With those replaced, the reset was back to how it should be, and all was working. Well.

A long soak test and lots of testing and it's ready to go back.

The final list of faults was as follows:

• RAM - 1x4116 DRAM replaced
• ROM - all ROM sockets replaced, all ROM and EPROMs tested OK
• Video half character blocks - 74LS166 replaced
• Video random characters - 4x2114 and sockets replaced, 
• Tape - edge connectors cleaned
• IEEE-488 - 6522 socketed and replaced
• Slow boot - recapped

Commodore PET 4032 Repair - only 16K reported

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

I have repaired and restored several 4032 and 8032 boards in the past, and here we have another Commodore Pet 4032 main board for repair.

This is one of the later Universal Dynamic Pet boards (8032089). It looks to have always been a 4032 as the extra screen RAM and associated buffers and links that would be required for 80 column mode are untouched. It also has 16 matching 4116 DRAMs (Commodore's own MOSTEK brandered MK4217N-3 / 4116N-S), so should be a 32K machine.

The problem is, it is showing 15359 bytes free, so is only detecting 16K RAM. I quick first check would be jumpers Y and Z. Z should be set for 32K and Y for 16K, But the board was correctly set for 32K mode with link Z fitted.

As usual, it's good to check the voltages first of all. I found the 7905 voltage regulator was outputting -6.5v, rather than -5v. Replacing that the rail now measured -5v as it should, but it didn't resolve the memory problem. As the -5v rail is only used by the DRAM chips, and they are sensitive to voltage problems, it may explain if any of the DRAM chips are damaged.

A good diagnostic tool at this point is a ROM/RAM replacement board, I've had a few requests for the 6502 ROM/RAM boards I built previously, and have now run out. I've designed a new version with a few changes, these will be available soon (UPDATE: available now). Installing one of those in the processor socket and enabling it's RAM, The pet boots and detects 32K, so there appears to be a fault in the upper bank of RAM.

A fault in the upper bank still leaves the system usable, using just the lower 16K. If the fault had been in the lower 16K, it wouldn't have booted up. With a non booting system, it is sometimes worth swapping the ends of resistors R10 and R11 (as I did in the DRAM repair on my 4032). This is all that is required to swap the upper and lower banks. In this case, with the banks swapped, the machine did not boot. This pretty much confirms there is a fault in the upper bank. If there is only a fault in the lower bank, this is an easy way to get the machine to boot.

If you have the lower 16K bank working, and the machine is running, you can still access the top 16K of RAM, it just won't be used by BASIC. A quick way to check which of the 8 DRAM chips in the upper bank are at fault, is to poke a number to an address in the upper bank and read it back. So for example, the first address in the upper bank is 16384, so poke 0 there and read it back, it should be 0.

POKE 16384,0
PRINT PEEK(16384)

Then try poking 255 there and read that back, and you should get 255.

POKE 16384,255
PRINT PEEK(16384)

If either or these responses are wrong, you can work out which chip is stuck high or low by converting to binary, so for example if the response is 8 and 255, one bit is stuck high. That is 0x08 in hex, 0000 1000 in binary. So it looks like bit 3 is stuck high. You would get 252 rather than 255 if it were stuck low. From the schematics at zimmers.net archive (pages 5 and 6), you will see that bit each bit is provided by a single chip, the 4116 being 16K x 1 bit. In this case, bit 3 is UA12.

Value	Bit	Lower bank	Upper bank
1	0	UA19	UA18
2	1	UA17	UA16
4	2	UA15	UA14
8	3	UA13	UA12
16	4	UA11	UA10
32	5	UA9	UA8
64	6	UA7	UA6
128	7	UA5	UA4

Once the chip is identified, remove it and replace it and see try again. I've talked a few people through this process, including in the comments on one of my previous RAM repairs, Dave Stevenson wrote up the repair of his 8096. In the case of this 4032 board, it's going to be more complicated as this initially showed no errors. Checking other addresses, I got an error at address 16420 (0x4024 hex).

Further testing with my memtest program showed a pattern, with multiple bits failing at addresses in hex always ending in 2 or A then 4 or C.

• 0x4024
• 0x402C
• 0x40A4
• 0x40AC
• 0x4124
• 0x412C
• 0x41A4
• 0x41AC
• etc.

This repeated all the way up to 0x7FAC. It seemed unlikely that the entire bank of upper RAM was faulty, so I spent a while looking at various addressing issues that could case this, but given the bank swap had shown there was a fault, and that only the DRAM chips are involved after those resistors, it had to be the RAM chips. The error pattern had only bits 3 and 7 changing, so I took a punt on bit 3, since I'd already seen it appeared to be stuck high at some location. That reduced the number of errors, so I replaced bit 7 as well. Replacing those two DRAM chips and the Pet booted up and reported 31743 bytes free, as it should be. It appears the addressing was being messed up by UA4, and there were some faults in UA12.

I managed to find some spare 4116 chips which were a good match for the originals, the same make and model and the date code 6 weeks later. If I was keeping this board, I would have been tempted to remove the sockets and solder the two replacement chips to the board, but I've left the sockets in place in case the board's owner has any problems in future.

With the new RAM in place, the system was up and running and detected 31743 bytes free as normal. Running memtest again, it passed with no problems.

It's a hard life for me, I had to test this again thoroughly with things like space invaders and down.

Also, at the request of the owner, I tested Colossal Caves adventure. We had spoken about this a while ago, he had remembered playing this on a Pet, but couldn't find a version of it. I finally located a D64 disk image of Colossal Cave, this was actually a port to the pet by Jim Butterfield.

To load the D64 disk image, I used my prototype PET microSD drive - this will soon be available, register your interest now if you want one of the first batch.

USB to IEEE-488 for Commodore Disk Drives

This is an old post, preserved for reference.

The products and services mentioned within are no longer available.

Here are the details of the USB to IEEE-488 / GPIB adapter I have been using to test the Commodore PET IEEE-488 disk drives.

Like the USB to IEC adapter I build last year for testing Commodore 1541 disk drives, this one is based on xum1541 firmware. That needs to run on an ATmega32U2, and as before I adapted one of my USB keyboard PCBs for the purpose. The latest PCB for the ZX81 adds a sounder to click on each keypress (which makes typing easier), and a mode switch. That leaves a pile of the old style PCBs for tasks like this.

I've added a piece of padboard to add the additional circuitry, held in place with a couple of cable ties and by the resistors which bridge the boards.

There are 8 grounds, 8 data lines and 8 handshaking lines on the 24 pin connectors, I've wired all those to short lengths of wire.

The two LEDs for power and activity fit in the lid.

The rest of the circuit (a 7406 hex invertor) also goes on the padboard, and it is all wired together.

That just fits in the box.

The circuit is actually the same as the IEC version, so I could have added a 6 pin DIN socket, but there wasn't space. Once complete, the unit plugs into the back of the disk drive.

I had forgotten the 8250 drives have the connector mounted upside down, so the LEDs are pointing downwards. I should be able to turn the connector round later on, although it is the right way around if testing with the board loose though.

However it's connected, the drive can be accessed using the xum1541 versions of the opencbm command line apps.

The CMBXfer GUI also works with this

It also works with the 1541 disk drive converted to a 2031.

I don't think anyone expected these two things to be connected together, so it is not recognized by the detect command.

I'm having a few problems with the 2031 clone responding intermittently. I'm seeing the same problems talking to the drive from real Commodore PET computers, so I don't think it's this adapter at fault. As a test, I went back to the 8250 disk drive, I tried copying a .d82 disk image to a real floppy disk.

Don't be fooled by the progress bar, that's only the first track of many.

It took almost half an hour to copy the whole image, certainly a good test of the adapter and the drive.

Once complete, a directory showed just how little was actually on the disk image, but still it had been a useful test, and I now have an 8250 demo disk to test the drive out.

Checking the disk on a real computer, the files have transferred correctly. Another useful bit of kit to add to the collection.

As ever, credit to those who created the xum1541, opencbm, CBMxfer and other tools I have used.