• Please review our updated Terms and Rules here

How Does the Apple IIc Know a Keyboard is Attached?

O

oldpcguy

Experienced Member
Joined
Sep 23, 2021
Messages
374
I am trying to track down an issue with a ROM 0 Apple IIc system board. For the moment I am suspecting the system may not be detecting the presence of a keyboard. When I check pin 18 of the MMU I see a pulsing signal on the pin. This signal also exits on pin 20 of the keyboard map (UD16). It is present whether or not a keyboard is connected. When I check this signal on a known working board the pulsing exits without the keyboard but goes high when a keyboard is attached. When I pull the MMU on either board this signal floats which tells me it is generated by the MMU.

On both the functional and non-functional boards the keyboard encoder is now socketed making for easy removal. As I suspect the failed system is unable to detect the keyboard I removed the keyboard encoder from both systems. On the functional board I see the "Apple //c" screen as expect but the observed problem remains with the non-functional board. Since I receive the "Apple //c" display on the function system only when the keyboard is attached and without the keyboard encoder this suggestions the system detects the presence of a keyboard without this chip.

A review of the schematics shows the bulk of the keyboard connections are made to the keyboard encoder with a few going to other locations. Specifically:
  • CAPS lock
  • LANGSW (language / keyboard switch)
  • RESET
  • OAPL (Open Apple key)
  • CAPL (Closed Apple key)
  • 80COLSW (80 column switch)
When I test each of these I observe the expected behavior when the appropriate switch is selected or key is pressed. Given this I am not sure how the system is aware that a keyboard is present or not. When I review the J9 connector pinout I see one other signal, FLASH, from a 555 timer chip (UC18). I am not sure what this signal does.

As an FYI I have replaced the 65C02, MMU, IO, Character Generator, and keyboard encoder chips with known good ones along with some DRAM chips that were suspicious. This has been a fantastic learning experience, I know so much more about the Apple IIc before I started. However the keyboard detection, at least for the moment, has me stumped.

TL;DR: Does anyone know how the Apple IIc detects the presence of the keyboard?
 
I would guess it be the display 40/80 column switch since it needs to know what resolution to be in Just a hunch..
 
As far as I know, the MMU is asserting (-) pin 18 when the keyboard address is decoded, enabling the keyboard data on the data bus.
Most versions of firmware check if the open and closed Apple keys are depressed during the boot sequence to run a self test. Since the keyboard contains the resistor to pull down the key switch signal when the switch is open, disconnecting the keyboard lets the key signal float high, causing it to appear to the computer that the apple keys are pressed, and then it enters the self-test mode. Once it enters self-test mode (or it starts looking for a disk to boot from), it is probably not checking for keyboard input, so the signal stops. Once you get a prompt, the signal should start again.

However, the self-test functionality is highly dependent on the ROM version of the Apple Iic, so it is possible that you are seeing the correct behavior for both Apple IIcs when the keyboard is disconnected.

So, It is not really checking for the keyboard, but rather checking the open and closed apple keys and then entering the selftest mode if they are pressed, or if the keyboard is disconnected and it appears that they are pressed.
 
Last edited:
Both of these are great ideas. I will look closer at each suggestion.
 
epooch had the correct answer. With the keyboard disconnected and testing on the working system board I probed pins 2 or 3 of the MUX (UF3) to monitor the behavior. Interestingly when I had the scope probe on either pin the "Apple //c" banner displays. This doesn't occur if I place the probe on after the power is applied. When I put the scope into single shot I do observe both pins will show a float level but, at least with the probe touching the pin, it is insufficient (I think it's < 200mV) to register a high and enter "self test" mode (the working board is a ROM 255 which only displays activity on the screen). When I attach the keyboard the scope doesn't observe a float condition.

I will try the same test on the non-functional board however I do not expect the behavior on these pins to be any different as I do not observe any different behavior from the board with or without the keyboard attached with or without the Apple keys pushed. This is a ROM 0 board so it should display something either way (the "Apple //c" banner or the self test results).
 
Is there any way that I can update the title to indicate the question has been answered?
 
epooch said:
Please let me know if you want any further help troubleshooting. Good luck!
Click to expand...
Thanks. Right now I'm holding off asking for assistance except in places where I'm stumped. This board has been an incredible learning experience given the problems I've discovered so far (a couple of bad DRAMs and the keyboard encoder).

I am now measuring low on pins 14 and 15 of the MUX (UF3). A look at the schematic shows they're tied to the output pins (5 and 9) of the 556 timer (UF2). As there are pull up resistors I shouldn't be seeing a constant low level on these pins (and I do not on the functional board). So it looks as if one of these two chips is holding it low. Any guess as to which one? I am suspicious of UF3 and I'm in the process of pulling it. I'll have it out in a little while and will know.
 
oldpcguy said:
Thanks. Right now I'm holding off asking for assistance except in places where I'm stumped. This board has been an incredible learning experience given the problems I've discovered so far (a couple of bad DRAMs and the keyboard encoder).
Click to expand...
I figured!

oldpcguy said:
I am now measuring low on pins 14 and 15 of the MUX (UF3). A look at the schematic shows they're tied to the output pins (5 and 9) of the 556 timer (UF2). As there are pull up resistors I shouldn't be seeing a constant low level on these pins (and I do not on the functional board). So it looks as if one of these two chips is holding it low. Any guess as to which one? I am suspicious of UF3 and I'm in the process of pulling it. I'll have it out in a little while and will know.
Click to expand...
I would guess the 74ls251 too because it is an unbuffered digital chip connected to an external port. The 556 should be a little more tolerant of weird stuff getting plugged in. I could imagine a DE-9 RS232 cable getting plugged into the joystick port and sending 12V to the poor MUX!
 
epooch said:
I would guess the 74ls251 too because it is an unbuffered digital chip connected to an external port. The 556 should be a little more tolerant of weird stuff getting plugged in. I could imagine a DE-9 RS232 cable getting plugged into the joystick port and sending 12V to the poor MUX!
Click to expand...
It's the 556 which is pulling the two lines low. Now I need to determine if the 556 is bad or if something is causing it to force its output low. I ordered some 556 chips (at $4.00 for four why not) but I want to get the scope out to see if the inputs to it are correct.
 
You must log in or register to reply here.
Back
Top