Back from the Grave: Apple //e (keyboard repeating and ignoring input)

(Originally drafted on February 17, 2018. Blogger just decided not to post it when I asked, for reasons I can't even begin to guess) 

The Apple II series includes a fairly unusual keyboard  A semi-custom decoder chip feeds the input via a ROM to determine which character code should be sent to a system.  This meant that custom keyboard layouts (such as DVORAK) could easily be implemented by only switching the ROM, and modified or extended characters (such as the extras added to the //e Enhanced and Platinum) could be easily dealt with.

It also offers functional advantages and disadvantages.  On the one hand, a full keyboard matrix meant that every key can be read individually - something only more expensive modern keyboards offer.  On the other hand, the decoder provides no feedback when individual keys are released, so the system only really ever knows what the last key pressed was.  These two aspects combined to make it extremely good for typing, but abysmal as a control method.

Unfortunately, this is the same Apple //e as featured in a previous BftG.  While it wasn't entirely unexpected that more faults may develop, given the condition of the board and chips, that it occurred so quickly after having finally got it working was massively disappointing.

In essence, the system now behaves as though a key is held down at all times, while simultaneously ignoring almost all keyboard input. As it is not looping through the self test, it clearly knows that there is a keyboard attached to the system.  While none of the visible keys respond it is still possible to reset the system with the keyboard, which bypasses the decoder chip entirely.  This points towards either the keyboard itself or the AY-5-3600 Pro decoder chip, with the latter feeling more likely.

Blind substitution would make this process much easier and quicker as both parts are easily replaceable, but we don't have access to the appropriate spares.  So we needed to determine which was responsible.  Metering the input to the decoder chip from the keyboard revealed that the keyboard matrix was working perfectly - every combination we tested (though not exhaustively) responded on the correct two pins.  So it's reasonably safe to assume that the keyboard itself is not the issue.

The decoder chip, however, is a different story.  Under normal operating circumstances, the sequence of events should be roughly as follows: the keyboard is polled one key at a time, if a key is detected as being pressed than pin 5 of the decoder (AKD, or Any Key Down) is set high, after a moment (to ensure a good electrical connection) pin 16 of the decoder (KSTRD, or Keyboard STRobeD) pulses high briefly before data is finally sent to the IOU for the system to deal with.  As expected, pin 5 was being held high - but unexpectedly, so was pin 16.

Effectively the system believed a key to be pressed, and continually being informed that new data was present.  Checking the data pins on the decoder showed no activity at all, so it wasn't being fed any actual data.

Out of sheer curiosity, we also attempted running the system without the decoder present.  To our surprise, the exact same behaviour occurred - repeated spaces.  Metering the aforementioned pins, however, showed very different results.  As soon as we put a small load on pin 5 using a scope probe, the errant input stopped and the line measured (correctly) low.  Evidently the empty spaces are something of a default behaviour (despite character 0x00 being Escape), and pin 5 is being pulled up (albeit weakly) by the IOU.



Remember that electricity can be dangerous to both property and life.  If you don't respect it you can wind up seriously hurting or even killing yourself or others, and chances are it's going to be painful while it's happening.  Unless you're sure of what you're doing, avoid tampering with any electrical circuit - especially when it's live or mains powered - and always ensure you have a nearby assistant who can contact emergency services.