Skip site navigation (1)Skip section navigation (2) 
Date:      Tue, 19 Nov 1996 15:00:29 +0900
From:      Kazutaka YOKOTA <yokota@zodiac.mech.utsunomiya-u.ac.jp>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        current@freebsd.org, nate@mt.sri.com, sos@freebsd.org, yokota@zodiac.mech.utsunomiya-u.ac.jp
Subject:   Re: UserConfig is broken + PS/2 support success 
Message-ID:  <199611190600.PAA03041@zodiac.mech.utsunomiya-u.ac.jp>
In-Reply-To: Your message of "Mon, 18 Nov 1996 04:18:12 %2B1100." <199611171718.EAA22673@godzilla.zeta.org.au> 
References:  <199611171718.EAA22673@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help 

>>According to his book, the bit 5 and 1 of the keyboard command byte
>>are related to the PS/2 mouse but are treated differently for the
>>ISA/EISA systems and the MCA systems (p.304-305):
>>
>>ISA/EISA
>>bit 5	0 Check parity form keyboard, with scan conversion (0 is 
>>	  normal operation).
>>	1 Ignore parity from keyboard, no scan conversion.
>...
>I think I know what bit 5 does: setting it makes XT keyboards work.  XT
>keyboards send scancodes that don't need any conversion (see Van Gilluwe).
>However, I couldn't get this to work in practice for an old keyboard with 
>an XT/AT switch.  Neither the BIOS nor standard syscons nor syscons
>tweaked to set the bit can see the keyboard in XT mode, and the tweaked
>syscons can see the keyboard in AT mode.  Perhaps my keyboard controller
>is MCA compatible.

As far as I understand, the bit 5 does not turn on/off conversion by
itself. It must be used in conjunction with the bit 6 which, I think,
is the bit to control the scan code translation/conversion.

bit 6	0 No conversion of keyboard scan codes.
	1 Standard Scan conversion - the scan code from the keyboard is
	  converted into the normal scan codes used in PCs (1 is normal
	  operation). MCA Type 2 controllers cannot set this bit to 1. 
	  In this case scan code conversion is set using keyboard
	  command F0h to port 60h.

This applies to both ISA/EISA systems and MCA systems (Van Gilluwe, 
p304-305).

My understanding on scan code sets and conversion is as follows (is 
this right?):

The bit 5 should be set/reset according to the keyboard device
attached to the system.

The XT keyboard sends scan codes without the parity bit. The AT
keyboard, on the other hand, sends them with the parity bit. In
addition, the AT keyboard can send three different sets of scan codes:

	set 1	XT scan code set
	set 2	AT scan code set (default)
	set 3	for manufacturing test?

So, I think we can have the following hardware combinations to get 
XT scan codes:

1. XT keyboard with an ISA/EISA style keyboard controller
The keyboard sends XT scan codes without the parity bit, thus, 
we should set:
	bit 6 - 0, bit 5 - 1.

2. AT keyboard with an ISA/EISA style keyboard controller

2.1 If the keyboard is programmed to use the scan code set 2
The keyboard sends AT scan codes with the parity bit; 
	bit 6 - 1, bit 5 - 0.

2.2 If the keyboard is programmed to use the scan code set 1
The keyboard sends XT scan codes with the parity bit;
	bit 6 - 0, bit 5 - 0.

3. AT keyboard with a MCA style keyboard controller

3.1 If the keyboard is programmed to use the scan code set 2
The keyboard sends AT scan codes with the parity bit:
	bit 6 - 1

3.2 If the keyboard is programmed to use the scan code set 1
The keyboard sends XT scan codes with the parity bit:
	bit 6 - 0

I guess it is not possible to use the XT keyboard with the MCA style
keyboard controller, because parity checking cannot be turned off on
this controller.

Most AT systems, except some ThinkPad models?, operate in 2.1 or 3.1
above.

The `syscons' driver can be flagged to make the keyboard to send the
scan code set 1; this corresponds to the cases 2.2 and 3.2.

>>>3.	KBDS_CONTROLLER_BUSY	0x0002
>>>aka	KBS_IBF		0x02
>>
>...
>	KBS_OBF (1)	/* KeyBoard Status [reg] [any] Output Buffer Full */
>	KBS_IBF	(2)	/* KeyBoard Status [reg] Input Buffer Full */
>	KBS_OBF_AUX (0x20)	/* KBS_OBF for Aux port */
>
>I prefer not to OR bits together in #defines.

I think you are referring to:

#define KBDS_BUFFER_FULL	0x0021
#define KBDS_ANY_BUFFER_FULL	0x0001
#define KBDS_KBD_BUFFER_FULL	0x0001
#define KBDS_AUX_BUFFER_FULL	0x0021
#define KBDS_CONTROLLER_BUSY 	0x0002

I intended to use these constants in the following ways:

To test if a keyboard data byte is available
    if (inb(status_port) & KBDS_BUFFER_FULL) == KBDS_KBD_BUFFER_FULL)
To test if a mouse data byte is available
    if (inb(status_port) & KBDS_BUFFER_FULL) == KBDS_AUX_BUFFER_FULL)
To test if a keyboard OR mouse data byte is available
    if (inb(status_port) & KBDS_ANY_BUFFER_FULL) != 0)

If we use:

#define KBDS_AUX_BUFFER_FULL	0x0020

and undef KBDS_BUFFER_FULL, then these tests have to be:

    if (inb(status_port) & (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL)) 
		== KBDS_KBD_BUFFER_FULL)
    if (inb(status_port) & (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL)) 
		== (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL))
    if (inb(status_port) & (KBDS_KBD_BUFFER_FULL | KBDS_AUX_BUFFER_FULL))
		!= 0)

The first and the third tests look all right. But the second test
looks less intuitive to me than before.

Kazu

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611190600.PAA03041>