On Sat, 17 Nov 2001 at 16:37:40, Peter wrote:
(ref: <[EMAIL PROTECTED]>)
>Hi Ian,
>
>>Similar information about the Q40 keyboard port would be useful too.
>
>The input is a 6 pin DIN connector. Almost every keyboard has a leaflet to
>describe the pinout, so I don't repeat it here.
>
>The Q40/Q60 keyboard transmission protocol is clocked serial (with the
>keyboard as clock source), 11 bits in length. One start bit (logic 0), 8
>data bits (LSB first), one odd parity bit and a stop bit (logic 1). The
>clock rate is about 10-20 KHz and can vary from keyboard to keyboard. The
>keyboard data format is similar to 8-odd-1 asynchronous transmission
>format. However, the bit rate
>from keyboard to keyboard can vary significantly so it is necessary to use
>a clocked serial interface with a receive clock input. The Q40/Q60 LSI
>logic reads the data bits on the falling "edge" of each clock pulse. The
>exact timing and analogue rise/fall behaviour is very tricky and not well
>defined. I had to use things like digital oversampling to support a wide
>range of keyboards. Both CLOCK and DATA lines are implemented on the
>keyboard end as open-collector outputs with pull-up resistors to +5V.
>
>The PC keyboard interface is fairly nasty to implement.
I second that. We just managed with sH but used only the latest of the
many different protocols.
It is worth noting that the LEDs are controlled by input data to the
keyboard. That in particular is why the capslock LED under sH is a mite
slow toggling the keyboard LED.
>The problem with
>the PC keyboard is that it uses the PC's on-board Intel 8741 (or
>equivalent) single-chip microprocessor and the only way to exactly
>reproduce its behaviour is to use the same chip. AFAIK the 8741 is still
>implemented as part of new PCs, within the PC chipset. Of course, I wanted
>no Intel chips on the Q40 ;-)
Yes - without the 8741 many 'standard' keyboards do not work well.
Even if the reset pin is documented, don't use it. It is not used with
modern keyboards. We connect it with sH, but I don't wire it in, as it
can cause the QL to reset at unpredictable times.
We tried to get definitive data on the protocols from Cherry, who had
particularly good data sheets. To quote "We will not supply this. We
spent many thousands of man hours getting around the bugs in the specs
and won't share that with anyone"
That is the PC world for you.
I remember Tony Tebby spending a whole week working around the MSDOS
bugs in 'format' when starting SMSQ coding.
Ditto Phil Borman when coding for Qubide.
Ditto me when writing code for the IBM QL file transfer. The C package
I used had its own serial driver code, as the MSDOS routines 'did not
work'
The PC only seems to work well because people code around the bugs - but
don't document what they do.
--
QBBS (QL fido BBS 2:257/67) +44(0)1442-828255
mailto:[EMAIL PROTECTED] http://www.firshman.demon.co.uk
Voice: +44(0)1442-828254 Fax: +44(0)1442-828255
TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG
