Solution for NEC D80C42C kbd ctrl bug

[EC1842]

the problem is in a20-ibm.inc, section USE_A20ASM. For some reason it reads bit4=0 from port 60h but has to be written back as "1". Solution is

	in	$0x60,%al	# read output port
	or	%ah,%ah
	jne	2f
	and	$0xFD,%al	# AND ~2 to disable

    or $10,%al
	jmp	3f'

2:	or	$12,%al		# OR 2 to enable
3:	mov	%al,%ah 

But I strongly recommend you use USE_HIMEM_AT way, it works well on all my kbd cntrls. I have PC/XT compatible machine with AT keyboard controller, but bits reading from port 60h are different. bits 1 and 5 (a20,not define) are known and same on 8086 mashine with AT kbd(should be 0 in my case). So DFh and DDh to enable/disable a20 line is best way.

PS small things should be fixed:
1.

#ifdef USE_BIOS
	mov	$1,%ah		# enable A20
	call	bios_set_a20	# try BIOS first
	call	verify_a20	# returns 1 if enabled, 0 if disabled
	and	%ax,%ax
	jnz	1f
#endif
	mov	$1,%ah		# enable A20
	call	set_a20		# call configurable A20 handler
	call	verify_a20	# returns 1 if enabled, 0 if disabled
1:	ret

If option #define USE_BIOS only is chosen, set_a20 is not defined anymore. And we don't need to call verify_a20, if bios_set_a20 returns CF flag (err or AH=86h means not supported)

2. KBD LEDs control shouldn't be based on type of CPU. Could be 286 upgrade card on pc/xt machine, or like my case, 8086 cpu with AT kbd

[ghaerr]

Hello @EC1842,

Thank you for these technical suggestions. Getting A20 turned on has been difficult as some published methods don't work, and finally we have settled on a method that works on many systems, but apparently not all. So I would like to ask a few more questions to fully understand what you are seeing so we can develop a better solution.

Is all your testing on same system, a PC/XT with an AT keyboard?

For some reason it reads bit4=0 from port 60h but has to be written back as "1".

I will need to find a technical manual to know why we need to set bit4=1, as I don't know what it is supposed to do. Are you saying on your system bit 4 reads as 0 but must be set to 1 to work? Then this routine works?

I strongly recommend you use USE_HIMEM_AT way, it works well on all my kbd cntrls.

I don't fully understand your explanation as to whether bits 1 and 5 are different on your machine than others? But nonetheless, I used to use USE_HIMEM_AT and it did not work on various systems, so we finally removed it and replaced it with USE_A20_ASM.

It sounds like what may be required will be to be able to support having both USE_A20_ASM turned on, and also have USE_HIMEM_AT turned on, and called if USE_BIOS and USE_A20_ASM do not pass the verify_a20 check. Will that work for you, or does USE_A20_ASM cause your machine to stop working?

If option #define USE_BIOS only is chosen, set_a20 is not defined anymore.

Will fix, thanks.

And we don't need to call verify_a20, if bios_set_a20 returns CF flag (err or AH=86h means not supported)

This was left in for the case of very old BIOS or incompatible BIOS that does not bother to return CF flag for unknown INT 15h calls.

KBD LEDs control shouldn't be based on type of CPU. Could be 286 upgrade card on pc/xt machine, or like my case, 8086 cpu with AT kbd

Agreed, but how will we know when to automatically decide to attempt programming the keyboard controller? It was figured that the driver should not attempt programming LEDs with OUTB instructions unless it is known for sure there is an AT keyboard attached.

We could add an option to the keyboard controller source code to force program the LEDs, but that would require a kernel recompilation.

[EC1842]

Thanks for your response.

Is all your testing on same system, a PC/XT with an AT keyboard?

No. I've tested 0.9.1 images and recompiled build 0.9.2 on 286 MB SUNTAC chipset nec 80c42, 286 MB VLSI chipset nec 80c42, 286 standard TTL logic (no chipset), fujitsu MLB8742 and Belarus/SU PC (EC-1842), Enhanced 8086 (supports some 186 instr.), 384 kb onboard XMS + 4 Mb ext. board (A20-A23 drives by hardware chip and supports by BIOS int 15h mem services, but No HMA/No A20 gate), cmos/clock, 16 bit data bus etc. (KM1816BE48 kbd AT cntrl, (8048))

it was same kbd issue on all board except 286 no chipset MB, that motherboard works very unstable and it hanged on first attempt. (used standard images and build compiled by default). Then testing MB are 286suntec and 1842 for all REcompiled builds.

I will need to find a technical manual to know why we need to set bit4=1, as I don't know what it is supposed to do.

D0h Read Output Port - This commands caused the controller to read its
output port and place the data in its output buffer. This command

should be used only if the output buffer is empty.

	│7│6│5│4│3│2│1│0│  8042 Output Port
	 │ │ │ │ │ │ │ └──── system reset line
	 │ │ │ │ │ │ └───── gate A20
	 │ │ │ │ └─┴────── undefined
	 │ │ │ └───────── output buffer full
	 │ │ └────────── input buffer empty
	 │ └─────────── keyboard clock (output)
	 └──────────── keyboard data (output)

Means reading bit4 has to be "0"

Im not sure, why we need to send it back as"1", but somehow it works.)) That bit/pin is connected to...!?

I don't fully understand your explanation as to whether bits 1 and 5 are different on your machine than others?

on 86/1842 MB out signals/output bits/chip pins 1 and 5 are reserved/not connected/not used and bits4,6,7 swapped with others. HIMEM_AT mode works, because it sends all "1" to port except bit1 and bit5. According EC1842 docs, they (bit 1 and 5) should be "0".

#define USE_BIOS not supported by those MB
#define USE_HIMEM_AT works on all my 286 and EC1842 MB
#define USE_A20ASM both 286 MBs (nec kbd chip) and 86/1842 MB - kbd hanged.
#define USE_A20ASM and fix OR AL,10h/OR AL, 12h - works on 286 MB
#define USE_A20ASM and fix OR AL, 40h/OR AL,42h works for EC1842 MB (bit6 is scancode mode)

Agreed, but how will we know when to automatically decide to attempt programming the keyboard controller?

mm. perhaps we can use some BIOS info at least, as ms/pc dos kbd drv does...

[ghaerr]

Hello @EC1842,

Thanks for more technical info.

It seems from your discussion that USE_HIMEM_AT will work for all your MBs. I don't think we should modify USE_A20_ASM method, since that has been reliably tested with other systems, but doesn't work on yours.

I haven't had time to fully understand the technical info, but it sounds like simply disabling USE_A20_ASM and enabling USE_HIMEM_AT should work for you and others, but I want to ensure I understand the full difference between the methods.

USE_A20_ASM was from an old article by Chris Giese with A20.ASM source code while USE_HIMEM_AT is supposed to be the method used by Microsoft's himem.sys. It sounds like MSFT perhaps knows a bit more than Chris did at the time?

perhaps we can use some BIOS info at least, as ms/pc dos kbd drv does...

Do you have any information on the particular BIOS Data Area location that we can use to determine what type of keyboard is attached?

Thank you!

[parabyte]

I have had a long hard look at the issue it's likely cause is that the read-modify-write in USE_A20ASM trusts command D0 to return the real output port latch, and on many 8042 variants it does not. Bits 4 and 5 are
output-buffer-full status lines rather than latched outputs, and bits 6 and 7 are the keyboard clock and data. Whatever those read back as, D1 writes them straight back out, so if any read
low the keyboard clock or its interrupt is pulled down and the keyboard stops answering. That would explain why the bit that matters differs per controller, bit 4 on the NEC part and bit
6 elsewhere, and why no single OR mask fixes them all.

It also explains why himem.sys is reliable: it never reads. DF and DD assert bits 0, 2, 3, 4, 6 and 7 unconditionally and vary only bit 1, so the keyboard critical lines are always driven
high regardless of what the controller would have reported. Forcing bit 4 in the existing code only patches the one case that was tested.

On keyboard type, BDA 40:96 bit 4 is set by POST when a 101/102 key keyboard is present, and 40:97 holds the LED state. That is independent of CPU, so it covers both a 286 card in an XT
and an 8086 with an AT keyboard.

[EC1842]

additionally check for BDA 40:96 bit 4

This is a sign, but not a definitive indicator of an AT/XT keyboard. That bit is set after a system reset, but the keyboard can be connected afterward—or it could be a rare 84-key AT keyboard. As far as I know, the DOS keyboard driver looks for the BIOS ID (mashine type) byte at F000:FFFEh. FCh-AT mashine. On my xt with at kbd that byte is FCh as well

[parabyte]

freedos keyboard driver

take note they are only parsing bit 4 at 0040:0096h

[ghaerr]

take note they are only parsing bit 4 at 0040:0096h

Thanks, this is just what my PR does also. @EC1842 will be testing the committed PR when able and will report back. If it works, I will consider this matter closed, as I don't think we need to write lots of special code to handle this case: we already assume a 101/102 key keyboard when CPU >= 80206, as well as now reading the BIOS at 40:96 otherwise and checking bit 4.

[parabyte]

I concur due to elks target cpu/s,

we are running in real mode!!

EC1842 i imagine that backwards compatibility is not on the agenda for a board like yours?

[EC1842]

@EC1842 will be testing the committed PR when able and will report back.

if you test bit4 of BDA 40:96, you will get info about 8X/10X key kbd, but statement of bit4 != statement of AT/XT kbd (standard or enhanced kbd is not same as XT, AT).

I don't think we need to write lots of special code to handle this case:

Correct! Just chk ID byte at F000:FFFEh.

EC1842 i imagine that backwards compatibility is not on the agenda for a board like yours?

Yep, topic is not about my board or backwards compatibility, but is about reported issue on 286 motherboard with nec d80c42, buggy code of A20 line and wrong detection kbd for LEDs control, based on CPU, and additionally about wrong detection AT kbd by bit 4 in BDA. You may read it from beginning of this topic and in Issues section as well to be sure.

[parabyte]

/*
SetKeyboardType(flag);
Set the keyboard type depending on flag:
0 = force standard 83/84 keys keyboard
1 = force enhanced 101/102 keys keyboard
2 = autodetect keyboard type from the keyboard mode/type byte at 40:96h
Returns the keyboard type and sets the keyboard mode/type byte accordingly
*/
uint SetKeyboardType(uint flag)
{
uchar far status= MK_FP(0x40, 0x96);
if (flag == 0) {
/ Set standard keyboard type */
*status &= ~0x10;
} else if (flag == 1) {
*status |= 0x10;
}
DBGprintf("Keyboard status byte: %04x\n", *status);
return (*status & 0x10);
}

[EC1842]

if (flag == 0) { / means enhanced kbd was not connected at the moment of check or not enhanced, nothing about AT or XT or kbd controller etc*/

[EC1842]

freedos keyboard driver

Known limitations
mKEYB is known to work on my machines: the Amstrad PC5086 and the Olivetti PCS86. Both are XT clones with an enhanced 101 keys keyboard. Consider it untested on anything else.
Most of the layouts are for 101/102 keys enhanced keyboards only. They are not accurate for 83 keys keyboard.
**Autodetect of BIOS features and keyboard type may not work.**

elks gonna be more buggy than it is...

[parabyte]

i still feel that supporting > 286 correctly also brings with it, instructions, task handing etc etc once you down the rabbit hole of ensuring elks correctly supports < 286 targets.

as there wont ever be a binary release for every possible combination of device and board, and most advanced users are building this anyway,

perhaps a halfway clean compromise would be to have a build time option, or perhaps a bootops bit/s,

I found out the hard way EC1842 comprehensive support is defiantly not a thing no one can do with elks, without stealing heap from something, or stealing precious user space ram, especially on 8088/8086 targets, I am referring to having lots of code to detect a keyboard type.

or another option i guess is internal fork of the elks keyboard driver, that is selected at build time for various targets and chipsets i cant not ghaeer cannot predict. lots of wacky boards out there!

I am referring to my workplace with there pc104 boards, The boards have literally no bios hooks for keyboard io ! but there is facility on the boards for ps/2 keyboards, and a strange controller from the embedded world.

[ghaerr]

@EC1842,

but statement of bit4 != statement of AT/XT kbd (standard or enhanced kbd is not same as XT, AT).

In that case, my fix checking BIOS data area won't work. At this point, I am quite confused as to what the difference is between an 83 key keyboard, a 101/102 key keyboard, an XT keyboard and an AT keyboard. Can you explain the differences so I can understand more exactly what we're talking about?

the DOS keyboard driver looks for the BIOS ID (mashine type) byte at F000:FFFEh. FCh-AT mashine.

I will go ahead and replace BIOS 40:96 bit 4 check with looking at whether BIOS ID (machine type) is FCh; if so, then set keyboard LEDs. This is easy to do and seems to be the fix for your problem, even though I don't fully understand exactly what the differences between keyboard and/or keyboard types are.

is about reported issue on 286 motherboard with nec d80c42, buggy code of A20 line and wrong detection kbd for LEDs control, based on CPU, and additionally about wrong detection AT kbd by bit 4 in BDA.

Yes: the A20 code should be fixed, and I will replace the incorrect bit 5 BDA detection with using BIOS machine type == FCh instead. This should fix all problems in this issue. I will push that commit later today, thank you.

[ghaerr]

@EC1842 Commit 9d9eb52 should fix the keyboard LED capability for your testing. Please let me know when you have tested. On QEMU, the machine type byte is also FCh, FYI.

[ghaerr]

Can you explain the differences so I can understand more exactly what we're talking about?

Thanks! Now I get it: All AT-style keyboards, including the 84-key keyboard, have LEDs!! :) So using BIOS 40:96 doesn't work. Good to know.

[EC1842]

testing...

[EC1842]

@EC1842 Commit 9d9eb52 should fix the keyboard LED capability for your testing. Please let me know when you have tested. On QEMU, the machine type byte is also FCh, FYI.

test has been complete successfully.
PC XT with XT kbd on 8255- works
PC XT compatible with AT kbd/controller and kbd leds- work
PC AT 286 with nec d8041AHC works, kernel in HMA, leds -ok
PC AT pentium 1 - works, kernel in HMA, leds -ok
PC AT 286 nec D80C42C works, kernel in HMA, leds -ok

build is compiled by default settings.

Do you need any screenshots of that?

[ghaerr]

No screenshots necessary. I'm glad all your issues have been fixed, so you can close this issue, thank you!