info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Yet another way to enable A20
88 views
Skip to first unread message
James Harris
Apr 21, 2021, 10:19:32 AM4/21/21
to
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
http://halicery.com/8042/8042_1503033.TXT which includes:
; 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.
--
James Harris
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
http://halicery.com/8042/8042_1503033.TXT which includes:
; 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.
--
James Harris
James Harris
Apr 21, 2021, 10:54:15 AM4/21/21
to
On 21/04/2021 15:19, James Harris wrote:
> 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.
...
> 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.
> ; 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
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
Apr 21, 2021, 7:24:17 PM4/21/21
to
On Wed, 21 Apr 2021 15:19:30 +0100
James Harris <james.h...@gmail.com> wrote:
> 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.
>
The main source I used for my routines doesn't seem to mention this.
James Harris <james.h...@gmail.com> wrote:
> 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.
>
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.
--
Rod Pemberton
Apr 21, 2021, 7:25:05 PM4/21/21
to
https://www.win.tue.nl/~aeb/linux/kbd/scancodes-11.html
> 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.
>
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
> And, of course, machines vary. But at least the 'magic values' of
> 0xDF and 0xCF (and perhaps others) finally seem to make some sense.
>
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
--
ATarpai
Apr 22, 2021, 1:26:02 AM4/22/21
to
On Wednesday, April 21, 2021 at 4:54:15 PM UTC+2, James Harris wrote:
> On 21/04/2021 15:19, James Harris wrote:
>
...
> On 21/04/2021 15:19, James Harris wrote:
>
> 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:
>
Hi James,
> 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:
>
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
Apr 22, 2021, 5:07:10 AM4/22/21
to
On 22/04/2021 01:26, Rod Pemberton wrote:
> On Wed, 21 Apr 2021 15:54:12 +0100
> James Harris <james.h...@gmail.com> wrote:
...
> On Wed, 21 Apr 2021 15:54:12 +0100
> James Harris <james.h...@gmail.com> wrote:
>> 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
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.
>
>> 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.
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
James Harris
Apr 22, 2021, 5:49:20 AM4/22/21
to
take a look.
--
James Harris
wolfgang kern
Apr 22, 2021, 6:50:12 AM4/22/21
to
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
Apr 23, 2021, 6:22:36 AM4/23/21
to
On 22/04/2021 11:48, wolfgang kern wrote:
> On 21.04.2021 16:19, James Harris wrote:
...
> On 21.04.2021 16:19, James Harris wrote:
>> As for whether I would issue 0xAA to the KBC I don't know. I might.
>
> There are better ways to control A20
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.
> (isn't always connected to KBC).
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
> 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:
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
Apr 23, 2021, 7:05:33 AM4/23/21
to
On 23.04.2021 12:22, James Harris wrote:
...
>>> 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.
...
>>> 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.
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.
> 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.
>> (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
mask A20 off were simply ignored.
__
wolfgang
James Harris
Apr 23, 2021, 12:35:10 PM4/23/21
to
On 23/04/2021 12:04, wolfgang kern wrote:
> On 23.04.2021 12:22, James Harris wrote:
>>> There are better ways to control A20
...
> On 23.04.2021 12:22, James Harris wrote:
>>> 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 ?
strange in 2021.
--
James Harris
Rod Pemberton
Apr 23, 2021, 3:05:23 PM4/23/21
to
On Fri, 23 Apr 2021 11:22:33 +0100
James Harris <james.h...@gmail.com> wrote:
> On 22/04/2021 11:48, wolfgang kern wrote:
> > On 21.04.2021 16:19, James Harris wrote:
> >> 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?
James Harris <james.h...@gmail.com> wrote:
> On 22/04/2021 11:48, wolfgang kern wrote:
> > On 21.04.2021 16:19, James Harris wrote:
> >> 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.
--
wolfgang kern
Apr 23, 2021, 9:40:00 PM4/23/21
to
__
wolfgang
James Harris
Apr 24, 2021, 5:05:48 AM4/24/21
to
at 1 IBM AT or 100% compatible
ps2 2 IBM PS/2
ptlcascade 3 Phoenix Cascade BIOS
hpvectra 4 HP Vectra (A & A+)
att6300plus 5 AT&T 6300 Plus
acer1100 6 Acer 1100
toshiba 7 Toshiba 1600 & 1200XE
wyse 8 Wyse 12.5 Mhz 286
tulip 9 Tulip SX
zenith 10 Zenith ZBIOS
at1 11 IBM PC/AT (alternative delay)
at2 12 IBM PC/AT (alternative delay)
css 12 CSS Labs
at3 13 IBM PC/AT (alternative delay)
philips 13 Philips
fasthp 14 HP Vectra
ibm7552 15 IBM 7552 Industrial Computer
bullmicral 16 Bull Micral 60
dell 17 Dell XBIOS
What I hadn't realised before is that many of them are too old to bother
about - e.g. they have 286 processors or even earlier.
Refs.
* http://www.manmrk.net/tutorials/DOS/help/himem.sys.htm
*
https://www.thecomputerarchive.com/Computers/PC%20desktops/ATT%206300%20Plus.pdf
* https://github.com/MikeyG/himem/blob/master/oemsrc/himem.asm
--
James Harris
0 new messages