Sandy Keyboard Interface, appeal

[Chr$]

I wonder if the Sandy keyboard interface simply wasn't widely compatible with different types of XT k/b.

Well, that probably has to do with the fact that, at that time, different types of XT keyboards weren't even compatible with each other - "the standard" was just stabilizing. Original PC keyboards use 2 start bits - "compatible" ones tend to use only one. Timing (that is, bit rate) varied widely. Whether they start to operate with or w/o a dedicated reset signal after power-on is also, apparently, pure coincidence. Most vendors simply seemed to assume you'd never replace the keyboard they supplied with your computer. So, it might very well be worth trying some more makes of XT keyboards with your interface.

This is the only XT keyboard I have. But that's ok, I can at least put this card with my pile of QL related novelty stuff that does work. I also have the ABC k/b interface, which is also for XT keyboards.

XT keyboards though, they're expensive to find if you have to have one right way.

[tofro]

To be honest, I'm still a bit at a loss how even very weird input from the keyboard could possibly lock up the QL. The only thing I can imagine is that some of your "special" keypresses could produce <CTRL><ALT>7 or other reserved combinations that put the 8049 in debug mode or even trigger otherwise yet undetected coding errors in the keyboard processor code. But that would lead to a comms breakdown between 68008 and 8049 - that is, an apparent lockup (freeze) of the QL because its keyboard has just died, but not the "reset colour pattern".

[Martin_Head]

The electrolytic capacitor in the top left corner of the picture might be involved in lengthening the power on reset (unless it's just across the supply rail). Might be worth a change.

Also I noticed on the IC in the top right corner. On it's left hand side, between pins 4 and 5 from the top of the picture. I don't like the look of the print going under the IC. Or is that something you have done.

And the 74HCT157, one in from the right at the bottom, does not look like it's aligned very well in the socket.

[Chr$]

The electrolytic capacitor in the top left corner of the picture might be involved in lengthening the power on reset (unless it's just across the supply rail). Might be worth a change.

Also I noticed on the IC in the top right corner. On it's left hand side, between pins 4 and 5 from the top of the picture. I don't like the look of the print going under the IC. Or is that something you have done.

And the 74HCT157, one in from the right at the bottom, does not look like it's aligned very well in the socket.

The cap is just across the supply rail.

Top right IC, left side of it, that's a thin wire trace bodge by me, after I lifted a pad when removing to check that IC.

I will re-align the lower chip. That original 74HCT157 on the bottom row was actually totally dead. My tester didn't recognise it as any kind of 74x chip. The replacement tests fine.

Also of note and clearly deliberate - there is a break in a trace to the right of the EPROM. Some kind of jumper I suppose, perhaps for EPROM size?

[RalfR]

I think, we need a few hints from Dave.

[Dave]

I wasn’t involved in the design or build of the keyboard interface. I would love to reverse engineer it and see if it could be adapted for more modern keyboards - which should be a trivial matter.

[Ruptor]

I will re-align the lower chip. That original 74HCT157 on the bottom row was actually totally dead. My tester didn't recognise it as any kind of 74x chip. The replacement tests fine.

The burnt left hand joint of the three on the ribbon PCB looks cracked but it could just be a ring of flux. For comparison here is a picture of my work in progress single PIC keypad interface that should do the same thing. t will be serial first but could do PS/2 with a software change if it works as designed. Amazing how technology has changed.

[Chr$]

I've removed all the chips now and the 2nd 74HC157 was also faulty. Both were RCA branded. Perhaps that was causing the lockups. Or maybe they didn't like the heat from de-soldering.

Currently 3 chips are removed, I need to fit sockets and replace the 157 before checking it again.

I was able to read the PAL16L8ACN using my Retro Chip Tester pro (fantastic bit of kit). It saved a bin file and a csv file. Apparently there is a utility called PAL2GAL to convert the PAL into to GAL format to write to a GAL. But I don't have a clue and haven't tried it yet (looks like it requires DOS/Win9x). Attached is a zip with the info the RCT churned out for me, in case anyone wants to make that into a format I can write to a GAL and try out.

Edit 11/3/23: I'd extracted the data incorrectly! Ignore the attachment (now deleted).

[Dave]

It’s good to have the fuse map, but it sure would be nice to reverse engineer the equations.

[Chr$]

I've just been looking into it further, examining the Retro Chip Tester instructions (which includes a handy example for a PAL16L) and I've made a little progress. What I haven't yet been able to ascertain 100%, is which pins are outputs and which are inputs. The example in the RCT manual talks about a chip with the following configuration:

Pin Type
1 Input
2 Input
3 Input
4 Input
5 Input
6 Input
7 Input
8 Input
9 Input
10 GND
11 Input
12 Output
13 Output
14 Output
15 Input
16 Input
17 Input
18 Input
19 Output
20 +5v

But what I haven't yet worked out... is that the same for every PAL16L chip, or could I have different pins for inputs/outputs? If it's likely to be different, then I assume I have to follow traces, buzz each pin etc, find out where it goes and from that info, work out which is an Input and which is an Output?

Anyway, if the above I/O list is correct, then this attached file is what I have so far.

Edit: Ah, so by the looks of it, only pins 13 to 18 can be either I or O, right? So I would just need to investigate those?

Oh and with the 2nd dodgy 74HCT157 changed out, it's still locks up on all the same key presses (most annoyingly the back arrow) as before!