The Apatco 6502 breadboard computer kit I’ve been building is complete. The next stage was to make it more so.
A word of warning, though. This story does not have a happy ending. Nonetheless, someone may find the attempt at debugging entertaining or instructional, so here it is.
The kit is sold (or perhaps ‘was’ would be better, as it seems to be near-permanently out of stock) in two versions. The basic one gets you as far as flashing LEDs, which is where I’m at. The extended kit adds a PS/2 socket for a keyboard and a 128×64 pixel LCD – the AGM1264F for those playing along at home. Both of these devices are controlled by the 6522 VIA. A pre-programmed EEPROM is also supplied, which manages keyboard input and the display and has a small memory monitor program.
That is, when it works. Right now, that’s not the case.
Wiring is pretty straightforward – with one exception, as we’ll see.
The PS/2 socket needs +5V and GND for power, plus a data line and a clock line. I managed to get the connections mirror-imaged on the first attempt to solder wires to the socket, but some perusing of PS/2 pinouts online got me back on to the right track. The data and clock signals connect to two pins on Port B of the 6522 (PB4 and PB5 to be precise).
The LCD takes rather more wiring. There are eight data lines that connect to all the pins of Port A on the 6522. Then there’s VCC and GND, of course. Pin 4 on the LCD determines whether the panel is receiving data to display or instructions, so this goes to a pin on Port B. The read/not-write pin is pulled permanently high by connecting it to the +5V rail – the LCD only ever needs to be in input mode. A reset pin (17), which is active low, gets connected to the reset line of the 6502. Two chip select pins (there are two driver ICs in the panel) are connected to pins on Port B. There are two pins (VCC and GND) for the backlight. The GND goes to the ground rail while the positive goes to another pin on Port B, so that backlighting is under programmatic control.
Finally, there’s the knotty issue of the ‘driver’ voltage for the display. The Apatco manual shows a rare instance of being a bit vague about this. It mentions that two pins on the LCD – pin 3, known as Vo, and pin 18, known as Vee – connect to each other via a potentiometer. But which pins of the potentiometer is left unclear.
A diagram seems to suggest +5V connected to one side of the pot, pin 3 (Vo) to the other and pin 18 (Vee) to the wiper. This, it turns out, is wrong.
I tracked down the data sheet for the AGM1264F and things started to become a little clearer.
The driver voltage for this display is in the 10-12V range. To achieve this, there’s an onboard DC-DC converter that supplies -10V on pin 18 (when measured, this came out closer to -9V, but let’s not quibble). If you attach this to one side of a potentiometer and +5V to the other, there’s a potential across the pot of 15V. You then tap into this by attaching pin 3 of the display, which is for the driver voltage input, to the wiper of the pot. At least, that’s how I understand it.
The diagram on the right is from the AGM1264F data sheet. It specifies a 10-20kΩ potentiometer. The Apatco kit supplies a 20kΩ pot, but it refuses to sit patiently in the breadboard and keeps popping out. I replaced it with a 10kΩ one of my own.
I also kept the eight-segment bar LED connected to the Port A lines of the 6522 (ie, the data lines feeding the display).
We have a problem
So the wiring’s sorted and double-checked. Why doesn’t it work?
The first issue was finding a PS/2 keyboard. Digging around I found I had two Dell keyboards, both in fairly crusty condition but functional.
After firing up the computer … well, not much happened. The keyboard lights flashed briefly, but nothing appeared on screen. No amount of pot adjustment produced any display. The keyboard LEDs work as expected when hitting things like NumLock, so the device is being powered.
I tried adjusting the pot before resetting (by this time I’d added a reset button to make life easier). When resetting, I found that one of several things would happen:
- The display would spring into life and show the menu I was expecting. The bar LEDs would stop with just the bit 6 bar illuminated. But don’t get too excited just yet.
- The display would show rapidly changing patterns of pixels, like a badly tuned old-style TV. This looked like the display was trying to work but there was, perhaps, some sort of timing issue.
- There would be no display, but the scroll lock lights on the keyboard would start flashing rapidly and the LEDs on the computer would go similarly haywire.
If situation 1 occurred and I tried pressing a key, the display would change to report a keyboard error. At the same time the display would pulse, like it was constantly re-displaying the message and the keyboard would go into flashy mode. Alternatively, the display would remain showing the main menu, but again would pulse slightly in intensity while the keyboard flashed.
So there’s a lot to work with there.
Maybe the keyboard is the problem. I tried connecting a USB keyboard via a USB-PS/2 adapter.
Hmm. Different. None of the flashing LEDs problem. Each time I reset, the computer LEDs would flash briefly and then stop with the same bar illuminated that normally shows when the menu is displayed. But I can’t see any menu. A few times, I briefly glimpsed text on the display, but faintly, and the screen quickly went blank again. Nothing I could do would coax a menu display out of the LCD.
Maybe the constant flashing is caused by the computer repeatedly resetting? There was a moment when the computer LEDs were flashing, but not at the usual rapid pace, and more in bursts. Checking with the scope revealed that the reset line was, indeed, being pulled low a lot.
This situation happened a few times. But more common was the rapid pulsing of the keyboard LED accompanied by similar pulsing of the computer LEDs. During this state, the reset line remained high.
There were signals galore on the clock and data lines to the keyboard, via pins PB4 and PB5 of the 6522 VIA. Removing the keyboard connections killed the signals on these pins and stopped the keyboard flashing, although the computer LEDs continued to flash. Does this suggest that the keyboard itself was somehow causing these signals? I’m baffled.
While pondering many of these imponderables, I found myself gazing at the LCD display. I didn’t much like the look of the soldering on the row of 20 header pins (not my doing). A closer examination revealed that pin 3 was bridged to pin 2 (VCC). And while there were no other shorts, some of the other joints looked decidedly iffy. I cleaned up the solder joints and tried again.
Did it make things better? No, worse. Now, no matter how many times I reset the damn machine, I could never get a menu up on screen. Gah!
The thing is, it should just work.
And by the way, just to ensure I hadn’t accidentally disturbed some wires – easy to do on a breadboard setup – I removed the keyboard and LCD, and swapped back in the previous EEPROM. The computer ran the binary counting program without a hitch. And I’ve checked and re-checked every connection, voltages etc.
I’m left with a few suspicions:
- That the EEPROM code is somehow borked.
- That the LCD is faulty.
- Keyboard incompatibility causing problems. I can see how this might happen as the code is constantly reading keyboard input.
- That I’ve missed something important about how everything is wired up. But like I said, I’ve checked the connections many times, both against the Apatco menu and the LCD datasheet.
If you have any ideas, let me know.
[UPDATE: later the same day] On a whim, I plugged in the USB keyboard via the adapter. There’s no screen display, as I mentioned, but the flashing thing doesn’t happen. I used the scope to look for signals coming from the keyboard on the data and clock lines when I pressed keys. Nothing. Nada. Zilch. The keyboard is getting power, as evidenced by its LEDs. But no signs of any activity.
That can’t be good.
[UPDATE 11/10/2019] Just a couple more notes (because I’m treating this post, like so many others, as a lab notebook):
- When the computer is booted with no keyboard attached, it does the flashy-flashy thing. So that seems to be some failed state that the code goes into whenever there’s a keyboard problem (see shot of display above).
- Using a Dell keyboard, I found that, on boot, whether the computer goes into that flashy-flashy mode or appears to boot properly (with the value 64, just the bit 6 bar illuminated) depends on the setting of the potentiometer. And it’s very sensitive.
- On one occasion when the computer booted into that stable state, I measured various voltages on the LCD’s pins:
- Pin 20 – 3.7V – huh. This is the anode for the backlight. It’s connected to a pin on the 6522 VIA. I tried tying this directly to +5V at which point I realised that, although the backlight had been switching on before, it was at nothing like its proper intensity. The pin on the 6522 is giving out 4.9V, but this is being pulled down to 3.7V when connected to the LCD.
- Pin 17 – Reset. This is active low. Trying to measure this with the DMM the first time caused the computer to trip into the flashy-flashy mode. Yup, that sensitive. Second time around, this read 4.9V, which is what I would expect.
- Pin 16 – CS2 – 4.8V, which is expected.
- Pin 15 – CS1 – 4.8V, also expected.
- Pin 5 – Read/Write – 4.8V. This is tied high, so this is expected. The LCD only ever needs to be in Read mode.
- Pin 4 – Data/Instruction – 0V. Being low means that the LCD is in instruction mode. This seems about right.
- Potential between pin 3 (Vo) and pin 18 (Vee) – 10.88V, which is about right.
I guess one thing I could try is putting the logic analyser on some of these pins to see what’s happening.
But I’m starting to think there’s a power issue here. The backlight doesn’t come on fully. Some of the flashing of the display may be to do with power issues. Even though the driver voltage on pin 3 is in the right area, somehow it seems very sensitive.
I’m powering this board via a bench power supply, which is limited to 2A – and the draw comes nothing close to that – maybe 140mA. I thought that maybe the regulator that came with the kit isn’t up to the job and so tried a different one – an LM7805A capable of supplying 1A. No change.