9

Nick Westgate posted a comment a few years back on a question about how slot 7 was unique stating that "Slot 1 on the //e is also unique - it can be used to replace the keyboard".

What was it about slot 1 on the //e that it could do this? How and was it ever implemented? Was it only the //e or did the earlier ]['s or perhaps later IIgs support this?

7

From Sather's Understanding the Apple IIe on page 7-19, at the top of column 2:

Slot 1 has two signals connected which are not available at the other slots, ENKBD' and CLKEN'. These are present primarily for diagnostic and testing purposes, but innovative peripheral card designs could make good use of them. When ENKBD' is high, the keyboard ROM is inhibited and the other devices can place data on MD0-6 of the data bus when read access is made to $C000—$C01F. When the CLKEN' is high, the motherboard 14M signal is disabled, and a card in the auxiliary slot can inject an alternate master clockpulse reference onto the 14M line. If, as normally is the case, ENKBD' and CLKEN' are not connected on the Slot 1 card, motherboard pull-down resistors pull these lines low so the affected circuits can function normally.

The advantage of keyboards interfaced via ENKBD in slot 1 is that they would be compatible with software that directly accessed the soft-switches instead of using the firmware routines.

Many 3rd-party keyboards existed, but I can't confirm if any used ENKBD. Here's a long list of disability keyboards with around 30 supporting the Apple II family, but none exclusive to the //e.

The name "Concept Keyboard" was familiar to me, and there are some references to it using a large interface card, but it's listed as being also compatible with the Apple //c and IIgs, even though according to the Hardware Reference manual the IIgs didn't retain ENKBD in slot 1. The Concept A3 model appeared to use a much smaller card that doesn't use pin 35 which carried ENKBD on the //e.

| improve this answer | |
  • 3
    Can verify this was done! It didn’t need special-purpose hardware, either. In 1980 my father acquired a surplus DECwriter LA36 terminal (serial printer with keyboard, no monitor) and connected it to slot 1 of our Apple II (48k). Typing PR#1 would cause the printer to start echoing the command line, while typing IN#1 would allow the keyboard on the DEC printer to type commands instead of the Apple built-in keyboard. – whiskeychief Feb 18 at 1:56
  • 3
    @whiskeychief interesting note, but are you sure that it wasn't simply using the redirection of CIN as a result of the IN#1 statement? Any card could take over standard input to the Apple II console with an IN#x statement, including the Super Serial Card which may have been the interface card your father used. Non-character I/O cards (such as disk controller) didn't implement the feature, naturally, and instead would just cause a "boot from disk" operation to occur. – bjb Feb 18 at 17:36
  • 1
    @bjb Actually, non-character cards such as the disk controller did take over CIN at times: this was how you'd do text file I/O in BASIC. DOS always had COUT hooked and when it saw a Ctrl-D (CHR$(4)) followed by READ MYFILE would take over CIN so that INPUT A$ would read data from the disk file. – cjs Mar 24 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.