Stag ZL30 repair

Please note that for safety reasons repairs to electronic equipment should only be undertaken by a qualified electronics technician

This ZL30 was obtained from Ebay and described as not working. When switched on the LED above the rightmost socket was lit but no beeps and the fluorescent display was blank. The exterior and interior of the case were in amazingly good condition and looked almost as new. There are currently no circuit diagrams available for this programmer so I spent some time staring at the PCB looking for anything it had in common with the PP3X and PP4X programmers that I had already. The ZL30 seems to have been developed after the PP3X but before the PP4X. The 10937 display controller is driven by a 6821 PIA like the PP39 but uses a 1MHz 6809 when the PP39 uses a Z80 and the PP42 uses a 2MHz 6809. Unlike both the PP3X and PP4X programmers the ZL30 has no static RAM only 16KB of dynamic RAM.

I decided to create a test firmware for the ZL30 using the one I had created for the PP4X as a starting point. The first test that the firmware performs is normally on the static RAM, because it uses that for it's stack memory which is required to call subroutines in the code. The PP4X static memory test would only give a pass or fail using the buzzer as that is all that is required as the entire static RAM IC would be replaced if it failed the test. The ZL30 only has dynamic RAM organised as 8 x 2KB ICs and if one if the ICs failed it would be necessary to know which needed replacing. The test writes FFH to each memory location and if the value read back is not the same it transmits the read back value in ASCII using the serial port which allows the faulty device to be identified and replaced. When I ran the new firmware in the socket for IC68 with a PC running a terminal emulation program connected to the serial port it indicated a memory fault and showed that bit 0 was always read back as 0. This corresponds to the 4816 memory IC labelled IC18 and after replacing it the firmware indicated the memory was working correctly. I removed the test firmware, refitted the original EPROM for IC68, switched the ZL30 on and it displayed "Selftest Fail 4". At that point I put it away until I could decide how to proceed.

Update: December 2022

There is no information available for the ZL30 circuit or even the meaning of the selftest failure codes and I needed to decide whether to give up or try to document the ZL30 PCB even if it was only partially. I took the decision to continue and get the test firmware working in a similar way to the others I had written. I found that the error message displayed changed if switched off and on again and could be any of "Selftest Fail 1", "Selftest Fail 2" or "Selftest Fail 4". This may indicate a failure when testing the presence of the four EPROMS on the add-on board (the firmware revision is 30A48) so I would implement a test for that once the keypad and display were supported.

After more than two weeks the display was still not working but when I replaced the original Stag firmware it worked fine. Eventually I managed to get the display functioning after optimising as much as I could of the code which drives the 10957 display IC. The ZL30 only has a 1MHz 6809 and the display IC has specific timing requirements that can be difficult to meet. Now I could move on, except that sometimes if I powered the ZL30 off with the test firmware the display would not work when I powered it on. So I changed back to the original firmware and it still did not show a display but it would work if I left it off overnight and powered it on in the morning. Very odd, another hardware fault ?

I proceeded with the modifications to the keypad code to allow the use of a menu to select tests but, while testing this, sometimes the display would disappear while moving the PCB. A dodgy wire from the PSU ? A short in the fluorescent display ?

I tested the wires and measured the filament resistance while the board was upside-down and all was well. I managed to get the keypad working but the delays in the code needed tweaking slightly. I left it on for a few minutes while I felt good that it was working but when I touched the keypad it didn't work. I powered it off and on again and heard the long beep followed by two extremely short beeps (the code does not generate beeps that short) and the display was blank. Aaargh !

Update: January 2023

I changed the code to send a message to the serial port shortly after starting up but nothing was sent. At this point I thought of giving up but I decided to connect up a logic analyser and find out what was going on.

I changed the code to only configure the UART and send a character in a tight loop. When triggering on the chip enable pin of the 2661 UART and displaying the signals on D0-D7, A0-A1 and -R/W I could see that the code was trying to do it but the A0 and A1 inputs were always high. A0 and A1 are used to select the register in the UART to be accessed and this doesn't make sense because this code uses all four registers. Using a multimeter I found that address line A0 was being pulled up to +5V and A1 and A2 were shorted together.

First I desoldered IC39 74LS244 which buffers the address bus from the CPU and drives IC10 6821 PIA, IC91 6821 PIA, IC11 2661 PIA, IC1 68488 GPIA, IC33 74LS138, and IC21-28 74LS279 addressable latches. After removal A0-A2 were still found to be faulty. Of the devices driven by the 74LS244 only IC1, IC33 and IC21-28 use address line A2 so one of these must be the cause of the problem. I chose to desolder IC1 first as it was easier to access, after removal the fault remained. For the other ICs the daughter board that is connected using a flexible strip needed to be loosened or removed first, but after removing IC33 I hadn't found the fault. I had an idea to desolder just the pins of IC21-28 that used A1 & A2 as inputs but this strategy did not work as the shoulder of each pin still touches the pad. Then I chose one of them to remove but found that it was too easy to lift a pad when trying to remove it so gave up on that. Instead, I would sacrifice all eight ICs by snipping off their legs and desoldering the legs individually but as these devices are still available and not too expensive I could accept that. After removal I would install IC sockets that would make future fault finding easier.

to be continued

home contact