Yet another way to enable A20

...

Post by James Harris
; Entry point when Host sends Command AA
0700: 89 FF   ORL P1,#$FF
0702: 23 CF   MOV A,#$CF
0704: 3A      OUTL P2,A
0705: C5      SEL RB0

One of the issues we discussed at length was when using the KBC to
enable A20 what value to write to the KBC output port.

One might need that because some machines cannot be depended on to
report what the port is set to (for example, "The Jetway NC-91 machine
times out waiting for KBC response" at
http://aodfaq.wikidot.com/mc-a20-controls).

IIRC, perhaps for that reason, Linux doesn't try to read the output
port's value before writing a new value. It just sets the output port to
0xDF.

If using the command 0xD1 xx (set output port to xx)

(http://aodfaq.wikidot.com/kbc-commands)

the question is what value to write for xx? Some options:

0xDF - as used in Linux (copied from an early BIOS?)
0xCF - what the KBC itself uses in the disassembly

When the now-disassembled firmware was written there was no mouse
attachment but the bits of the output port are now

7 - Keyboard data
6 - Keyboard clock
5 - IRQ12
4 - IRQ1 (pin 24)
3 - Mouse clock
2 - Mouse data
1 - A20 gate
0 - System reset

(Ref. http://aodfaq.wikidot.com/kbc-output-port)

Well, I just read in http://www.halicery.com/8042/8042_INTERN.TXT that
the IRQ1 output "may be inhibited by writing a '0'" to its pin (pin 24).

I think this means that writing 1 to that pin does not set the pin high
- as I've always assumed - but that writing a 1 to the pin allows the
KBC to control it - which it does in hardware in that the state of that
pin is automatically asserted to indicate that the KBC has something in
its output buffer for the host to read.

Of course, since the above firmware was written the mouse has been added
and I haven't found a disassembly of firmware which takes the mouse into
account but if it functions in the same way as the KBC then the above
values suddenly make a lot more sense:

0xDF (2x1101_1111) would disable the mouse and enable the keyboard
0xCF (2x1100_1111) would disable both mouse and keyboard

Can it be that simple - the mystery over what value to write to the
output port coming down to which interrupts one wants to enable at the
time? Presumably they would be enabled later as part of device discovery
and setup.

And, of course, machines vary. But at least the 'magic values' of 0xDF
and 0xCF (and perhaps others) finally seem to make some sense.

--
James Harris

Rod Pemberton

2021-04-22 00:26:16 UTC

On Wed, 21 Apr 2021 15:54:12 +0100

Post by James Harris
One of the issues we discussed at length was when using the KBC to
enable A20 what value to write to the KBC output port.
One might need that because some machines cannot be depended on to
report what the port is set to (for example, "The Jetway NC-91
machine times out waiting for KBC response" at
http://aodfaq.wikidot.com/mc-a20-controls).
IIRC, perhaps for that reason, Linux doesn't try to read the output
port's value before writing a new value. It just sets the output port
to 0xDF.
If using the command 0xD1 xx (set output port to xx)
(http://aodfaq.wikidot.com/kbc-commands)
0xDF - as used in Linux (copied from an early BIOS?)
0xCF - what the KBC itself uses in the disassembly
When the now-disassembled firmware was written there was no mouse
attachment but the bits of the output port are now
7 - Keyboard data
6 - Keyboard clock
5 - IRQ12
4 - IRQ1 (pin 24)
3 - Mouse clock
2 - Mouse data
1 - A20 gate
0 - System reset
(Ref. http://aodfaq.wikidot.com/kbc-output-port)

section 11.5
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-11.html

Post by James Harris
Well, I just read in http://www.halicery.com/8042/8042_INTERN.TXT
that the IRQ1 output "may be inhibited by writing a '0'" to its pin
(pin 24).
I think this means that writing 1 to that pin does not set the pin high
- as I've always assumed - but that writing a 1 to the pin allows the
KBC to control it - which it does in hardware in that the state of
that pin is automatically asserted to indicate that the KBC has
something in its output buffer for the host to read.
Of course, since the above firmware was written the mouse has been
added and I haven't found a disassembly of firmware which takes the
mouse into account but if it functions in the same way as the KBC
0xDF (2x1101_1111) would disable the mouse and enable the keyboard
0xCF (2x1100_1111) would disable both mouse and keyboard
Can it be that simple - the mystery over what value to write to the
output port coming down to which interrupts one wants to enable at
the time? Presumably they would be enabled later as part of device
discovery and setup.

Have I misunderstand you here? ...

You don't write to the output port (nor input port). You write to the
command byte. The command byte is used to enable or disable the
keyboard, mouse, IRQ1, IRQ12, and scancode translation.

The command byte is section 11.2. The output port is section 11.5.
https://www.win.tue.nl/~aeb/linux/kbd/scancodes.html

Post by James Harris
And, of course, machines vary. But at least the 'magic values' of
0xDF and 0xCF (and perhaps others) finally seem to make some sense.

I send keyboard commands (section 12) values of f5h (defaults/disable),
f3h (set typematic rate), f4h (enable). Next, I send edh to set led
lights. Finally, I send a keyboard controller command byte 47h
(section 11.2) to enable mouse and keyboard, enable mouse and keyboard
interrupts, and translate scan codes.

https://www.win.tue.nl/~aeb/linux/kbd/scancodes-11.html
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-12.html

For the mouse, I send mouse command (section 13) f5h (disable), f6h
(defaults), e8h (resolution), ..h (resolution data), send IM
(intellimouse) init sequence, conditionally send IM Explorer sequence
based on mouse type identifier, set mouse rate sequence (as the IM
sequences reset them), and f4h (enable).

https://www.win.tue.nl/~aeb/linux/kbd/scancodes-13.html

--

James Harris

2021-04-22 09:07:07 UTC

Post by Rod Pemberton
On Wed, 21 Apr 2021 15:54:12 +0100

...

Post by Rod Pemberton

Post by James Harris
Can it be that simple - the mystery over what value to write to the
output port coming down to which interrupts one wants to enable at
the time? Presumably they would be enabled later as part of device
discovery and setup.

Have I misunderstand you here? ...
You don't write to the output port (nor input port). You write to the
command byte. The command byte is used to enable or disable the
keyboard, mouse, IRQ1, IRQ12, and scancode translation.
The command byte is section 11.2. The output port is section 11.5.
https://www.win.tue.nl/~aeb/linux/kbd/scancodes.html

You can write to either the Command Byte or to P2 (the output port)
depending on which command you use.

You could think of the KBC's connections as

port 0x60 port 0x64
###########################
########### KBC ###########
###########################
P1 P2
(input) (output)

where the top ports go to the CPU and the bottom ports go to the
keyboard, to the PIC, to the A20 gate and to the system-reset circuitry.

/Where/ you write a byte to depends on the command you use.

Command 0x60 X - write X to Command Byte (internal RAM, not shown)
Command 0xD1 X - write X to P2 (output port)

However, it turns out to be a bit more complicated than that. The 8042
has an EN FLAGS instruction which changes the behaviour of two of the
pins on P2. If EN FLAGS is set then the 8042 will automatically clear or
set pins 4 and 5 of P2 depending on whether certain of the KBC's
internal registers are vacant or occupied.

For example, pin 4 can be set up to tell the PC's hardware that the 8042
has something for the CPU to read.

But it's more complicated than that. AIUI with EN FLAGS what gets
/programmatically/ written to pins 4 and 5 either enables them or
disables them. Writing a 0 to such a pin will disable it. Writing a 1 to
it will enable it. And if it's enabled then it will automatically
reflect the state of the internal register. I don't know what state the
pin will be in if it's disabled.

It seems according to

http://www.halicery.com/8042/8042_INTERN.TXT

that the 8042 will always automatically update bits 0 and 1 of the
status register (which we can read from port 0x64) but with EN FLAGS it
will also reflect those bits on to pins 4 and 5 of P2.

I haven't got to the details of pin 5 but if pin 4 is enabled then it
will be automatically set to 1 when a byte is written into the KBC's
output buffer and automatically cleared when the byte is read by the
CPU. It is therefore routed to the PIC's IRQ1. I gather the pin is
raised high whenever the KBC has a byte for us and is pulled low as soon
as we read the byte.

Post by Rod Pemberton

Post by James Harris
And, of course, machines vary. But at least the 'magic values' of
0xDF and 0xCF (and perhaps others) finally seem to make some sense.

Some of those sound like commands to the keyboard. They are largely
unrelated to commands sent to the KBC. (The two devices are completely
separate even though the way to communicate with the keyboard is
/through/ the KBC.)

Commands to KB: http://aodfaq.wikidot.com/keyboard
Commands to KBC: http://aodfaq.wikidot.com/kbc-commands

--
James Harris

ATarpai

2021-04-22 05:26:01 UTC

...

Post by James Harris
Of course, since the above firmware was written the mouse has been added
and I haven't found a disassembly of firmware which takes the mouse into
account but if it functions in the same way as the KBC then the above

Hi James,

FYI I've made a few other disassemblies also including the firmware of the PS/2 controller with keyboard/mouse, please look at them here:

http://halicery.com/Hardware/Intel%208042%20and%208048/8042%20and%208048%20ROM%20disassemblies.html

BR,
A. Tarpai (Halicery)

James Harris

2021-04-22 09:49:17 UTC

Post by ATarpai
...

Hi James,
http://halicery.com/Hardware/Intel%208042%20and%208048/8042%20and%208048%20ROM%20disassemblies.html
BR,
A. Tarpai (Halicery)

Cool! Thanks for helping demystify the complexity of this stuff. I'll
take a look.

--
James Harris

Rod Pemberton

2021-04-22 00:25:32 UTC

On Wed, 21 Apr 2021 15:19:30 +0100

The main source I used for my routines doesn't seem to mention this.
So, that could be why it wasn't discussed by me, if it wasn't.

https://www.win.tue.nl/~aeb/linux/kbd/scancodes.html

My opinion on the keyboard controller commands was that there was no
guarantee they'd be widely implemented. So, I avoided them.

--

wolfgang kern

2021-04-22 10:48:52 UTC

Post by James Harris
In all the years I've been posting to this newsgroup and all the deep
discussions we used to have about A20 I don't recall us ever discussing
the info below about what AFAICS is another way to enable the A20 gate.
Alright, it's not a method one would choose as a matter of course but it
has interesting implications.
But some people knew about it all along. The page at
https://www.os2museum.com/wp/ibm-pcat-8042-keyboard-controller-commands/
says there that when the KBC is told to test itself with 0xAA, "the self
test command also effectively resets the KBC and puts it into a known
state. That means, among other things, that the A20 address line is
enabled, keyboard interface is disabled, and scan code translation is
enabled."
So the 0xAA selftest command doesn't just test the KBC, as one might be
led to believe from its name, but reinitialises the KBC as well. And as
part of the reinitialisation it enables A20. OK!
It turns out to be correct if I understand
; Entry point when Host sends Command AA
0700: 89 FF   ORL P1,#$FF
0702: 23 CF   MOV A,#$CF
0704: 3A      OUTL P2,A
0705: C5      SEL RB0
Note the out of 0xCF (2x1100_1111) to P2 (port 2) setting bit 1 (the A20
gate enable) and others.
If that's what the keyboard controller sets on bootup then 'A20 enabled'
would be the default state.
That makes sense when you think that the BIOS can do a lot of memory
testing and other stuff before it hands us control. To initialise the PC
fully it would naturally need access to all memory addresses.
As at http://aodfaq.wikidot.com/mc-a20-boot we found that at the point
when we get control the state of the A20 gate varies: some machines
start our code with A20 enabled, others with it disabled. But where a
machine starts up with the gate disabled it certainly looks as though
the BIOS would have had to have taken deliberate steps to do so.
Basically, the BIOS must do a load of work in normal mode then, shortly
before it hands control to a boot sector, it would disable A20.
As for whether I would issue 0xAA to the KBC I don't know. I might.

There are better ways to control A20 (isn't always connected to KBC).
and btw:
all my BIOS are less than 25 years old, and all boot with A20 ON.
__
wolfgang
------------------------------------
here is what I have in my info-book:

PS/2 KEYBOARD
(only ports 60 and 64 are involved)

INPUT PORT [WRITE 60] command or parameter
OUTPUT PORT [READ 60] ACK, ERROR or SCANcode

STATUS register [READ port 64]:
7 parity ERROR on transmission from keyboard
6 any TIMEOUT
5 ** mouse output buffer FULL
4 ** OVERRIDE keyboard lock
3 port 60 data is for COMMAND(controller)/data(keyboard)
2 SELFTEST OK/power up or reset
1 input buffer FULL (no write allowed until bit clears)
0 output buffer FULL (is cleared after port 60 read)

COMMAND register [WRITE port 64]:
available commands: response:
(+n two byte commands data to/from port 60)
20+00 readback RAM_0 aka I/O control port see below
some brands can access more RAM (up to 255)
but standards for are idx>0 aren't well defined

60 write I/O control port -
I/O control port:
7 0
6 1 IBM COMPATIBLE mode5 DISABLE/enable mouse
4 DISABLE/enable keybord
3 0 reserved (was OVERRIDE KEYLOCK)
2 unused/available
1 ENABLE IRQ_12 (mouse)
0 ENABLE IRQ_01 (keyboard)
--- response:
21..3F+n readback RAM_1..1F any written
61..7F write data -
A7 *disable mouse (set bit 5 in I/O-ctrl) -
A8 *enable mouse -
A9 *test mouse port 00 if OK
AA *test controller 55 if OK
AB *test keyboard 00 if Ok
AC *diagnostic dump (16 or more RAM bytes) varies
AD disable keyboard -
AE enable keyboard -
C0 *read input port any
D0 read output port as below
Output port:
7 keyboard data (output)
6 keyboard clock (output)
5 mouse OBF (to IRQ12 if enabled)
4 keyboard OBF (to IRQ1 if enabled)
3 mouse data (output)
2 mouse clock (output)
1 A20 enable (may be at port 092 instead)
0 0 RESET all and forever if not pulsed!
--- response:
D4 next command goes to mouse instead of KBD -
DD disable A20 (wont work if at port 092) -
DF enable A20 (ditto) -
ED+n same as for INPUT PORT command on some controllers
F0..FF PULSE masked OUTPUT bits 3..0 for 6uSec depends
but only bit0 seem to be common used:
FE RESET, b0 is connected to the RESET-pin we wont see it

*) seem to be obsolete/not required/useless,
I enable/disable the mouse by D4+AE and D4+AD

INPUT PORT Commands [WRITE PORT 60]
ED+n LED-control FA
7..3 = 0
2 CapsLk
1 NumLk
0 ScrlLk
---
EE diagnostic echo EE
(EF+26 [Cherry MF2 G80-1501HAD] 256 bytes)
F0+00 get scancode set 1/2/3
F0+01 select scancode set1 FA
F0+02 select scancode set2 (AT, PS/2, default) FA
F0+03 select scancode set3 FA
F2 GET keyboard ID (read two ID bytes) AB 41/AB 83/FA
F3+n SET typematic rate/delay FA
values for n:
7 0 reserved
6,5 typemativ delay
00=250ms 01=500mS 10=750ms 11=1000ms
4..0 typematic rate 00=30/sec ... 1F=2/Sec
---
F4 enable keyboard FA
F5 disable keyboard set default parameters FA
F6 set default parameters FA
F7 set all keys to typematic (scancode set 3) FA
F8 set all keys to make/release FA
F9 set all keys to make only FA
FA set all keys to typematic/make/release FA
FB+n set specific key n to typematic FA
FC+n set specific key to make/release FA
FD+n set specific key to make only FA
FE resend last scancode previous
FF RESET keyboard and controller AA or error FC/FD
eof

James Harris

2021-04-23 10:22:33 UTC

...

Post by James Harris
As for whether I would issue 0xAA to the KBC I don't know. I might.

There are better ways to control A20

You think? :-) I just found it interesting that after so long I still
came across something which would enable A20 which I wasn't aware of.

When I say I might use 0xAA to re-initialise the KBC that was more for
data gathering than for A20 control but it is potentially useful to know
that it ought to enable A20 as a side effect.

Post by wolfgang kern
(isn't always connected to KBC).

Do you know of a machine in which the KBC cannot be used to control A20?
In all my tests so far the KBC method (writing to the output port with
0xD1) has been the only one which has worked on all of them. See KBC
Method, SCPA Method and BIOS Control headings at

http://aodfaq.wikidot.com/mc-a20-controls

Post by wolfgang kern
all my BIOS are less than 25 years old, and all boot with A20 ON.

OK.

Post by wolfgang kern
__
wolfgang
------------------------------------

...

Some interesting stuff in there (now snipped) especially what I think is
a note of what responses one should expect for certain commands.

--
James Harris

wolfgang kern

2021-04-23 11:04:14 UTC

On 23.04.2021 12:22, James Harris wrote:
...

Post by James Harris
As for whether I would issue 0xAA to the KBC I don't know. I might.

There are better ways to control A20

You think? :-) I just found it interesting that after so long I still
came across something which would enable A20 which I wasn't aware of.

the better way to achieve rollover at 1MB is to set the limit in GDT.
I doubt it's not of much use and who want's such dangerous behavior ?
.
KBC and other legacy stuff is all just emulated in the south-bridge yet.
And even some PCs have a real port 92 it's rare usable for A20 control.

Post by James Harris
When I say I might use 0xAA to re-initialise the KBC that was more for
data gathering than for A20 control but it is potentially useful to know
that it ought to enable A20 as a side effect.

Post by wolfgang kern
(isn't always connected to KBC).

my latest machines doesn't have an A20-gate at all. So all attempts to
mask A20 off were simply ignored.
__
wolfgang

James Harris

2021-04-23 16:35:08 UTC

Post by wolfgang kern
There are better ways to control A20

...

Post by James Harris
You think? :-) I just found it interesting that after so long I still
came across something which would enable A20 which I wasn't aware of.

the better way to achieve rollover at 1MB is to set the limit in GDT.
I doubt it's not of much use and who want's such dangerous behavior ?

I don't know anyone who wants A20 to be turned off. That would be very
strange in 2021.

--
James Harris

Rod Pemberton

2021-04-23 20:06:39 UTC

On Fri, 23 Apr 2021 11:22:33 +0100

Post by James Harris
As for whether I would issue 0xAA to the KBC I don't know. I might.

There are better ways to control A20

You think? :-) I just found it interesting that after so long I still
came across something which would enable A20 which I wasn't aware of.

Didn't DOS' HIMEM.SYS have a bunch of A20 methods we didn't identify?

--

wolfgang kern

2021-04-24 01:38:42 UTC

Post by Rod Pemberton
On Fri, 23 Apr 2021 11:22:33 +0100

Post by James Harris
As for whether I would issue 0xAA to the KBC I don't know. I might.

There are better ways to control A20

You think? :-) I just found it interesting that after so long I still
came across something which would enable A20 which I wasn't aware of.

Didn't DOS' HIMEM.SYS have a bunch of A20 methods we didn't identify?

I have only DOS 6.00. its Himem show only the KBD method and port 92.
__
wolfgang

James Harris

2021-04-24 09:05:45 UTC

Post by Rod Pemberton
On Fri, 23 Apr 2021 11:22:33 +0100