SOL-20 keyboard malfunction

[dfnr2]

I've been working on restoring my Sol-20, and get to the point of having a boot prompt, but when I attempt to type commands, I'm observing incorrect behavior.

On booting, the UPPER CASE light is on, but the alphabet keys give non-ASCII characters. UPPER CASE cannot be turned off.

SHIFT LOCK toggles the local LED as well as the SHIFT LOCK LED. With SHIFT LOCK engaged, alpha keys give (mostly) the correct values, but numeric keys don't.

With SHIFT LOCK off, the lower case keys give wrong chars, but consistently mapped.

RETURN doesn't work, and neither does CTRL-M. LF and CTRL-J do the same thing, which is generate an "?" error message and go to the next line, except every once in a while it also home the cursor, which never makes it to the bottom of the screen. "0", "@", and spacebar all act like a Return.

I might have suspected my ROM images, but the original SOLOS module behaves the same as the replacement module. The screen clears just fine on startup, and the prompt displays properly.

I plan to look into it when I have a little time. If there's a stuck bit, the issue could be anywhere from the analog multiplexers through the RAM or the PROM. Both the 2101 and 74S287 might be candidates for statistically most likely to fail, but I'll have to poke around to get a clearer picture of what's going on.

Has anyone had a similar experience? Has anybody dumped a working PROM?

Dave

 

[Hugo Holden]

I think the first move rather than trying to solve incorrect character issue initially is to determine why some of the keys are not working, such as return. Check with the scope on the output of the transistor sub-circuit that detects the key capacitance increase there, that a pulse appears when you depress the key (it sets a flip flop as I recall, I don't have the schematic in front of me).

What sort of condition are the foam discs in ? Have you inspected or replaced them yet ?

When the discs disintegrate they can do all sorts of things, the metalization in the mylar fails and they cannot raise the capacitance high enough to generate a key detect pulse, so that key gets ignored. Also, the foam layer splits in two and the mylar can fall across the pcb area and act like a permanently depressed key, or be intermittent.

It is easy to see if all the keys themselves are working normally looking at the output of the transistorized differentiator and threshold detector circuit they have there on the scope. If that is ok, initially, then its a matter of looking at the circuitry after that. A faulty TTL IC here and there is not uncommon, I had a few on my SOL motherboard and one on the keyboard.

 

[Hugo Holden]

...... This was the experience with my keyboard, probably different issues than yours, I documented it in an article:

"The keyboard required the usual replacements of the foam pads with the dielectric
coated discs.
The original arrangement uses a 0.07mm thick dielectric (possibly mylar or polyester)
on a foam disc with the conductive layer sandwiched in the middle of the dielectric, so
about 0.035mm from the surface.
Experiments showed that the capacitance has to rise to about 10 to 15pF to produce a
reliable negative going output pulse from the transistorized differentiator and threshold
circuit, of about 800nS width. This sets the S-R flip flop U14 on a key-press.
Prior to getting the Sun 4 keyboard replacements pads, I had experimented with
conductive rubber discs, which also work and running in a “DC coupled” mode the
output pulses are 5uS long.
I bought some other capacitance pads to try which had a similar thickness dielectric, but
the conductive coat was on one surface and therefore the capacitance didn’t rise high
enough for reliable key detection as the dielectric layer was too thick.
After replacing all of the pads, the Sol keyboard appeared to work well on all keys.
However, every now and then it would stop and not respond to any keys. In seconds or
minutes it would work again, Sometimes the problem disappeared for days. So I had my
scope at the ready.
When the condition appeared, a quick test with the scope showed that there where no
pulses coming via the keys from the key-scan circuit and that the key-scan pulses had
vanished. The master clock U17 was still working. It turned out that U6 a Fairchild brand
7493 was faulty, with the A output intermittently disappearing, disabling the key-scan
circuit. The IC was replaced. Intermittent IC’s are not very common and Fairchild 74 IC’s
seldom do this sort of thing. Also, the intermittent failure of this IC, surprisingly, was not
temperature sensitive. Heating or cooling the IC did not change the nature of the fault
within it to any measurable degree".

 

[dfnr2]

I think the first move rather than trying to solve incorrect character issue initially is to determine why some of the keys are not working, such as return. Check with the scope on the output of the transistor sub-circuit that detects the key capacitance increase there, that a pulse appears when you depress the key (it sets a flip flop as I recall, I don't have the schematic in front of me).

That's good advice. I did not have a lot of time to investigate, but I did disassemble the keyboard to inspect the discs. The previous owner told me he had been able to order discs from the manufacturer and replaced them in the early 2000's. Opening up the keyboard, the discs were not quite disintegrated, but were mushier and less resilient than fresh discs, so I replaced them all. However, the behavior didn't change.

I scoped the pads and saw good pulse trains to each disc, but not all keypresses are detected. However, I don't think it's enough to account for the mapping issues.

When I have a little more time, I will investigate further. Bummer.

Dave

 

[Hugo Holden]

I scoped the pads and saw good pulse trains to each disc, but not all keypresses are detected. However, I don't think it's enough to account for the mapping issues.

Dave

Most likely though, there will be one fault not two (but its always possible there is more than one) and it is easier to fault find a problem with a signal missing, rather than incorrect in some way. If you find the cause why some keys are not detected, it could turn out that the fault causing that is also causing the other issue. At least I would guess that, unless I fixed this issue and the other issue still persisted.

 

[Corey986]

To determine if it’s the pads, remove the top of the keyboard. Clean the all the contacts with an art eraser (white kind) and then try the keyboard out without the pads or the top installed. Your bare finger can activate the keys by simply pressing on the contacts on the keyboard. Your skin/body is enough for the capacitive discharge to work. If you need to start troubshooting the TTL on the keyboard this is also how I’d do it to simplify the effort. When it all works, then reassemble the keyboard with pads. Be careful, sometime the pads fall out of the clips. This will also cause a problem as the matrix might read wrong. In those cases a small drop of contact cement on the plastic disk. Just enough to hold it in but not enough to clog up the mechanism. I have also used permanent double sided tape cut to the shape of the plastic disk.

 

[dfnr2]

My first hope was that it might be bad pads. I did open up the keyboard. Although all of the original pads worked, I replaced them because they were a bit mushy and slow to rebound. However, using a good pad on a spare plunger, certain keys activate and others don't.

I'll have to determine if the pattern of keys follows columns or if it's random. A random pattern of keys would lead me to suspect the 2101. A column pattern could be the TTL circuitry or the 2101.

Has anyone ever made a dump of the PROM, or would someone with a good keyboard be willing to do so? I couldn't find it in the manual. I suppose, if necessary, it would be possible to reverse engineer it, to some extent, from the schematic and by comparing outputs with a working keyboard.

Dave

 

[Hugo Holden]

My first hope was that it might be bad pads. I did open up the keyboard. Although all of the original pads worked, I replaced them because they were a bit mushy and slow to rebound. However, using a good pad on a spare plunger, certain keys activate and others don't.

Dave

This is classic for unsuitable pads. There are some where the thickness of the mylar is too thick and the capacitance increase they generate is borderline enough, so they trigger some keys and not others.I had this with the first set of Texelec discs I tried. But to know if that is true you need to check the non responding circuit pads on the keyboard, that they respond to another stimulus, such as your finger, or a resistance anything less than 47k, or >15pF capacitor trips a key detect and you can register a pulse on the collector of Q2. Have you checked the keyscan and detect circuitry, as you can see its done with pairs of IC's to get the whole array working. It is possible that with an issue there, some keys could work and others not.

Proms like the 74187 would be pretty reliable along with the 2101 IC (these IC's are still available, I got a spare on ebay) I have not got around to dumping the 74187 yet, it is on my to do list along with the similar Proms on the Northstar controller card I have for my disk drives. I wasn't quite sure how I would do it yet, because my Rom reader doesn't support those IC's so I would have to make some sort of custom adapter. Maybe someone has already done it though.

 

[Hugo Holden]

...oddly the PROM on my SOL keyboard, U18, is a 74S287. My manual copy is not very good and it looks like 74187, similar proms, but not pin compatible. What is the number on the prom on your keyboard ?

 

[dfnr2]

...oddly the PROM on my SOL keyboard, U18, is a 74S287. My manual copy is not very good and it looks like 74187, similar proms, but not pin compatible. What is the number on the prom on your keyboard ?

It's a 74S287. My manual lists it as a "8574 or 74S187A", but the Mike's arcade cross reference indicates the 8584 is compatible with 74S287. So the '187 must be a typo.

 

[dfnr2]

(a qualified) Success!!

I took a look at DI1 and DO1 pins on the 2101 last night, and found spurious pulses on the DO1 pin with no key presses and no input on DI1. I replaced the 2101 and all the keys are now working perfectly.

Now that I can toggle the UPPER_CASE key, the keys all work perfectly with UPPER_CASE off, but I get odd characters and control codes when UPPER_CASE is active. Since the pin drives an address line on the PROM, I favor a bad PROM.

Hugo, any chance I might be able to talk you into dumping yours?

Dave

 

[Hugo Holden]

Hugo, any chance I might be able to talk you into dumping yours?

Dave

It is a project I plan to do in the future, i'm in the middle of another project with a light pen right now, however I think it will involve a custom setup to be able to read and program these vintage proms. I would have to have that up and working and be convinced I could safely read and write these proms with known test files, before I would be game to attempt to install my keyboard's 74S287 in the device, in case I damaged it in the process. So it would take some R&D time.

There may be somebody who has done it with these and has a safe setup already for that IC.

 

[Hugo Holden]

..........of course that Prom might be ok. One way to find out would be to send it someone with a working sol-20 keyboard in your area and plug it in for testing to confirm if it is ok or defective.

 

[deramp5113]

I have not got around to dumping the 74187 yet, it is on my to do list along with the similar Proms on the Northstar controller card I have for my disk drives. I wasn't quite sure how I would do it yet, because my Rom reader doesn't support those IC's so I would have to make some sort of custom adapter. Maybe someone has already done it though.

I have previously dumped the three PROMs on the NorthStar SD controller and configured the dumps for programming here: http://deramp.com/downloads/north_star/hardware/Single Density Controller/Boot and Decode PROMs/

I have used hobbyproms.com in the past who have the bi-polar PROMs and will program them for you. The prices are reasonable and their service is great.

I have not dumped the Sol-20 keyboard PROM. My PROM is soldered in. Does anyone have a keyboard with that PROM socketed? I asked around last night with a few people I know with Sol-20's and so far, none of the keyboards have a socketed PROM.

If we can get a good PROM, I can dump it by inserting it in one of my NorthStar floppy controllers and reading it.

If we can't get a good PROM, it shouldn't be too hard to figure out what it must contain.

Mike

 

[Corey986]

When I get a chance I'll check my keyboards to see if any are socketed. I have a DataIO 29B, so I can read and even create bipolar proms. Not sure if I'll have time to desolder the chip for a bit as my workbench is full of a disassembled Sanyo monitor.

 

[deramp5113]

(a qualified)Now that I can toggle the UPPER_CASE key, the keys all work perfectly with UPPER_CASE off, but I get odd characters and control codes when UPPER_CASE is active. Since the pin drives an address line on the PROM, I favor a bad PROM.

Dave

With UPPER_CASE off, do upper case letters work correctly when using the SHIFT key?

With UPPER_CASE on, are the odd characters consistent for each given keypress? For example, can you tell what keys A S D F map to when UPPER_CASE is on?

Mike

 

[dfnr2]

Thanks Hugo, Mike, and Corey.

I have dumped my PROM:

:20000000000000000000000000000000000000000F01020F02000302090604050805030789
:200020000F01030F0200020209040607080703050F01020F02000302090604050805030710
:200040000F01000F0200000009000001080103010F01000F02000000090000010801030130
:200060000F01000F0200000009000001080103010F01000F02000000090000010801030110
:200080000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F80
:2000A0000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F60
:2000C0000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F40
:2000E0000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F20
:00000001FF

A7 is tied low, so the F's in the upper half are expected. There are 8 combinations of upper bit patterns, depending on the status of SHIFT, CTRL, and UPPERCASE. Since there are 16 upper-bit patterns per map, this hex dump contains 2 maps per line.

The last two lines are the maps for when the control key is pressed.
The first and third lines are maps for when the UPPERCASE key mode is enabled (LED is lit, address line is low).
The second half of each line is the map for when the SHIFT mode is enabled.

So, breaking the dump out by modifier key combinations (UPC = UPPER CASE):

1. UPC           00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2. SHIFT+UPC     0F 01 02 0F 02 00 03 02 09 06 04 05 08 05 03 07
3. (plain)       0F 01 03 0F 02 00 02 02 09 04 06 07 08 07 03 05
4. SHIFT         0F 01 02 0F 02 00 03 02 09 06 04 05 08 05 03 07
5. UPC+CTL       0F 01 00 0F 02 00 00 00 09 00 00 01 08 01 03 01
6. SHIFT+UPC+CTL 0F 01 00 0F 02 00 00 00 09 00 00 01 08 01 03 01
7. CTL           0F 01 00 0F 02 00 00 00 09 00 00 01 08 01 03 01
8. SHIFT+CTL     0F 01 00 0F 02 00 00 00 09 00 00 01 08 01 03 01

The problem is the first line - all 0's. This will cause all keys to generate control codes in UPPERCASE mode, but not the same codes as the CTRL key would generate (line 7.)

To check this, I tried using the SHIFT key in the UPPERCASE mode, and get the desired keys.

To recreate line 0, it will be the same as line 3(plain), except the ALPHA ASCII characters are shifted. That means all 04 are mapped to 06, and some 05 are mapped to 07.

Since there are only one each of the 04 and 05 mappings in the "plain" map, I think that copying the plain row with the 04 and 05 changed to 06 and 07 should produce the correct behavior. I'll report back when I have had a chance to test this.

Dave

 

[dfnr2]

With UPPER_CASE off, do upper case letters work correctly when using the SHIFT key?

With UPPER_CASE on, are the odd characters consistent for each given keypress? For example, can you tell what keys A S D F map to when UPPER_CASE is on?

Mike

Bingo! SHIFT causes correct characters to be generated. I hadn't picked up on that detail until I examined the ROM dump and went back and tested it.

 

[dfnr2]

Success!

To recreate line 0, it will be the same as line 3(plain), except the ALPHA ASCII characters are shifted. That means all 04 are mapped to 06, and some 05 are mapped to 07.

Since there are only one each of the 04 and 05 mappings in the "plain" map, I think that copying the plain row with the 04 and 05 changed to 06 and 07 should produce the correct behavior. I'll report back when I have had a chance to test this.
Dave

OK, so of course that's backwards. All 06 are mapped to 04 and some 07 are mapped to 05.

I copied the third map (0x20 - 0x2f) to 0x00 - 0x0f, and changed the 0x06 at 0x0A to 0x04.

There are two columns mapping from 07 to 05, at 0x0B and 0x0D. I didn't realize what the numbers on the key matrix were until I wanted to do a continuity check to determine which 05 column to remap. I verified that the alpha keys were in the 0x0B column, so I changed the value at 0x0B from 07 to 05, and burned the PROM.

The new PROM gives the expected behavior for alphanumerics, as well as @', [{, and ]}, ^~, etc, so I'm thinking it's correct.

Here's the dump of the fixed PROM:

:200000000F01030F0200020209040405080703050F01020F02000302090604050805030734
:200020000F01030F0200020209040607080703050F01020F02000302090604050805030710
:200040000F01000F0200000009000001080103010F01000F02000000090000010801030130
:200060000F01000F0200000009000001080103010F01000F02000000090000010801030110
:200080000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F80
:2000A0000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F60
:2000C0000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F40
:2000E0000F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F0F20
:00000001FF

If anyone has a chance to verify against a good original, I'd be very interested in the result.

So now, the Sol-20 is operational! I just need to screw on the new sides, replace some internal screws, and get it all back together. The next step will be to get a floppy system working, but I have other projects ahead of it. Nothing goes back up on the shelf until it's working.

Dave

 

[dfnr2]

BTW, the National 74S287A parts that I have default to '1' in the unprogrammed state, so if the PROM is not quite right, I'll burn the corrected image to the upper half and tie A7 high.

Dave