PB686: there is no fast A20 on port 92h
Revised . Applies to: Packard Bell PB686, TI TACT82000 chipset; 92h tests 2026-09-12 under the original Phoenix 3.10 BIOS; D0h test 2026-10-12 under Atlas 286 M14
The Packard Bell PB686 has no "fast A20" gate at port 92h. Writing bit 1 of port 92h does not switch the A20 address line, and the reason is plain once you look: on this board, port 92h is the same register as port 82h, the AT's DMA page register for channel 3. The only working A20 gate I've found on the PB686 is the usual one, through the 8042 keyboard controller's output port. If your software or BIOS assumes every AT-class board has a fast A20 gate at port 92h, it will quietly fail on this machine, and it will move a DMA page register while it's at it.
Applies to
- Packard Bell PB686, TI TACT82000 chipset (TACT82301, 82302, 82303). See PB686 chipset: TI TACT82301, 82302 and 82303, not Chips and Technologies.
- Port 92h and A20: measured on 2026-09-12 with the board's original Phoenix ROM BIOS PLUS 3.10 fitted. Port decoding is hardware, so the BIOS shouldn't matter, but that is the BIOS the tests ran under.
- The 8042 command D0h (read output port): measured 2026-09-12 under the original BIOS and 2026-10-12 under Atlas 286 M14.
- Tools: my own probe programs, which aren't published yet. The steps below say what they did.
Evidence
Everything here was measured on real hardware [I] (measured on real hardware), on the PB686, except the one documented-only [D] (documented only, not measured) line, which says so:
- Port 92h aliases port 82h [I] (measured on real hardware). On 2026-09-12 a probe wrote
52to port 82h, and port 92h read52. It wrote64, and 92h read64. Both ports were restored to00and read back00. A control port with nothing on it (300h) readFFthe whole time, so the matching reads weren't left-over bus values. The two addresses differ only in address bit 4, which suggests the board doesn't decode A4 in this range. That last part is my inference from the reads, not a separate measurement. - Port 82h is the DMA channel 3 page register: documented only [D] (documented only, not measured). That's the standard PC/AT I/O map, not something I measured.
- Bit 1 of port 92h does not gate A20 [I] (measured on real hardware). Run three times on 2026-09-12. With A20 off, the byte at
FFFF:0520is the same memory as0000:0510. The test wrote5A, thenA5, at0000:0510and read them back atFFFF:0520, with port 92h bit 1 clear and then set. The wrap stayed live both ways, so A20 stayed off whatever bit 1 said. - A20 works through the 8042 [I] (measured on real hardware). Atlas 286 drives A20 only through the 8042 output port. Its own A20 gate test passes on the PB686, and HIMEM.SYS with
DOS=HIGHruns on it with 2 MB of extended memory. - D0h, read output port, does answer, if you ask it the right way [I] (measured on real hardware). Read on five of five cold boots on 2026-10-12, under Atlas M14: with the keyboard interface switched off first (command ADh) and the output buffer emptied, D0h returned
ED. Bits 6 and 7 read high in that window.
An earlier result said the opposite about D0h. On 2026-09-12, under the original BIOS, a probe sent D0h twice and got nothing back: the status register sat at 1C with the output buffer empty through 400,000 polls. I haven't proved why they disagree. The earlier probe sent D0h with the keyboard interface still switched on (I've checked its source: no ADh first). The later one switched the keyboard off and emptied the buffer before asking. Why that changed the outcome isn't established. The 2026-10-12 reading is the current answer.
Check it yourself
Two warnings first. Writing port 92h or 82h on a PB686 moves the DMA channel 3 page register, so do it only with the machine idle: no floppy access, and no card using DMA channel 3 (on my machine nothing is on DRQ3). And put back every value you change.
I ran these through probe programs, not by hand. The same port operations in DOS DEBUG look like this:
- Read both ports as found:
i 82andi 92. Note both values. - Write a test value to 82h and read 92h:
o 82 52, theni 92. On the PB686, 92h reads52. Try a second value (o 82 64,i 92) so a single lucky match can't fool you. - Read a control port that you've already established nothing on your machine decodes. Mine happened to be
300h, which readFF, but on plenty of vintage PCs 300h belongs to a network or sound card, so don't assume. If the control port also returns your test value, you're reading bus residue, and step 2 proved nothing. - Put 82h back to the value from step 1 (
o 82 00on my machine) and read both ports again. The A20 half isn't something I'd do by hand. For the record, my probe booted without HIMEM.SYS so A20 was off, saved the byte at0000:0510, wrote a signature there, and read it back atFFFF:0520(the same byte when the address wraps), with port 92h bit 1 clear and then set, restoring everything afterwards. Poking low memory fromDEBUGis an easy way to crash a machine, so the better route is the probe program itself, which saves and restores state and fails safely. I'll publish it.
The D0h reading needs a program rather than DEBUG at the keyboard, because the keyboard interface is switched off while it runs, and I drove mine over a serial console. Here's exactly what can go wrong: if the program crashes or hangs after switching the keyboard off and before switching it back on, the keyboard stays dead until you reset the machine. That's another reason to wait for the published probe program rather than writing your own.
Sources
- Microsoft Knowledge Base Q96711, "HIMEM.SYS Reports Error: Unable to Control A20 Line!", archived copy: https://jeffpar.github.io/kbarchive/kb/096/Q96711/. How HIMEM.SYS chooses an A20 method and how to override it with
/MACHINE.
Revised
2026-10-25.
Revision log:
- 2026-10-25: first version. Takes the 2026-10-12 D0h reading as current, replacing the "the 8042 ignores D0h" result of 2026-09-12. Reviewed before publishing: an untested explanation for that difference was removed, and the reproduction steps were made more cautious.
Wrong about something? Tell me at [email protected].
