# PB686: there is no fast A20 on port 92h On the Packard Bell PB686, port 92h is an alias of DMA page register 82h and does not gate A20. Use the 8042 for A20. 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 Source page: https://barelybooting.com/library/pb686-no-fast-a20-port-92h/ 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](/library/pb686-chipset-ti-tact82000-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], on the PB686, except the one documented-only [D] line, which says so: - Port 92h aliases port 82h [I]. On 2026-09-12 a probe wrote `52` to port 82h, and port 92h read `52`. It wrote `64`, and 92h read `64`. Both ports were restored to `00` and read back `00`. A control port with nothing on it (`300h`) read `FF` the 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]. That's the standard PC/AT I/O map, not something I measured. - Bit 1 of port 92h does not gate A20 [I]. Run three times on 2026-09-12. With A20 off, the byte at `FFFF:0520` is the same memory as `0000:0510`. The test wrote `5A`, then `A5`, at `0000:0510` and read them back at `FFFF: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]. Atlas 286 drives A20 only through the 8042 output port. Its own A20 gate test passes on the PB686, and HIMEM.SYS with `DOS=HIGH` runs on it with 2 MB of extended memory. - D0h, read output port, does answer, if you ask it the right way [I]. 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: 1. Read both ports as found: `i 82` and `i 92`. Note both values. 2. Write a test value to 82h and read 92h: `o 82 52`, then `i 92`. On the PB686, 92h reads `52`. Try a second value (`o 82 64`, `i 92`) so a single lucky match can't fool you. 3. Read a control port that you've already established nothing on your machine decodes. Mine happened to be `300h`, which read `FF`, 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. 4. Put 82h back to the value from step 1 (`o 82 00` on 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 at `0000:0510`, wrote a signature there, and read it back at `FFFF:0520` (the same byte when the address wraps), with port 92h bit 1 clear and then set, restoring everything afterwards. Poking low memory from `DEBUG` is 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: . 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 hello@barelybooting.com.