https://nand2mario.github.io/posts/2026/80386_protection/
I'm building an 80386-compatible core in SystemVerilog and blogging the process. In the previous post, we looked at how the 386 reuses one barrel shifter for all shift and rotate instructions. This time we move from real mode to protected and talk about protection.
The 80286 introduced "Protected Mode" in 1982. It was not popular. The mode was difficult to use, lacked paging, and offered no way to return to real mode without a hardware reset. The 80386, arriving three years later, made protection usable -- adding paging, a flat 32-bit address space, per-page User/Supervisor control, and Virtual 8086 mode so that DOS programs could run inside a protected multitasking system. These features made possible Windows 3.0, OS/2, and early Linux.
The x86 protection model is notoriously complex, with four privilege rings, segmentation, paging, call gates, task switches, and virtual 8086 mode. What's interesting from a hardware perspective is how the 386 manages this complexity on a 275,000-transistor budget. The 386 employs a variety of techniques to implement protection: a dedicated PLA for protection checking, a hardware state machine for page table walks, segment and paging caches, and microcode for everything else.
(Score: 2) by DadaDoofy on Thursday February 26, @02:45PM (1 child)
"I'm building an 80386-compatible core in SystemVerilog"
Why? Life's short.
(Score: 4, Funny) by VLM on Thursday February 26, @03:18PM
All progress in the world comes from stubborn individuals:
"bet you can't"
"hold my beer and watch this"
An alternative interpretation is its exercise. I have the golang tutorial books to implement the monkey language as both an interpreter and a compiler and I can do it (I think so, anyway?) and it would be a good exercise. In my infinite spare time LOL.
(Score: 5, Insightful) by VLM on Thursday February 26, @03:28PM (2 children)
I enjoyed this article. Sometimes I feel bad when someone posts a cool article and there's nothing to say but "thats cool". See this a lot with some hackaday posts, some bloggers like Mr. Shirriff, space news, etc.
The only complaint I have, is having lived thru this era and messed around with stuff when it was new, I assure you that even back in the day nobody could decide if the whole A20 gate thing to work around 80286 protected mode was brilliant or insane. I guess thats a reasonable criteria for "a really good hack".
The dude really should have mentioned this. Its ... an interesting solution. Making your software protection rely on your keyboard controller seems insane. Probably is. But if it works...
I donno if the wikipedia article is the best explanation but, at least its long:
https://en.wikipedia.org/wiki/A20_line [wikipedia.org]
The wiki article seems to focus more on how removing functionality means modern (post Y2K) PCs are no longer technically backwards compatible. IF you want the full "glory" of 286 mode on a new PC you have to run it in a CPU emulator not on bare metal.
The A20 gate was stupid and crazy and brilliant and effective. I dated a chick like that in uni a long time ago.
To make a long story short, PCs were 16 bit machines back in the day and could only use more than 64K with crazy bank switching and A20 was a ... hack I guess to upgrade from a 1 MB hardware bank switching system on 8086 to a 80286 in protected mode able to talk to 16 MB
(Score: 5, Informative) by owl on Thursday February 26, @07:10PM (1 child)
Almost. Yes, it was a hack in it's most delirious sense. But it wasn't to allow '286 protected mode to work. '286 protected mode needed the A20 hack turned off, lest things go very wonky (i.e., crash).
The A20 hack was to work around the fact that Intel, when creating the '286 chip, and setting it up with a "real mode" where it supposedly acted just like an 8086, did not in fact make it act just like an 8086.
Because the 8086 had only 20 bits of address bus, the largest address the chip could output was F FFFF (spaces to show chunks for readability). As well, due to the totally unprotected nature of an 8086, one could easily setup segment register values that, when shifted and added to a 16-bit pointer value, would overflow 20-bits of address bus. I.e., it was classic unsigned integer addition overflow for fixed bit quantities. But because the chip only had 20 physical bits of bus, only the low 20 bits appeared to the outside world for any overflow address.
The result was that any segment+offset addition that overflowed actually wrapped around from the very top of memory to the very start of the memory space. I.e., if the addition resulted in 10 1234 (a value that overflows 20 bits) the actual address out of the pins was 0 1234 (an address in the first 64K of the memory space.
Next, because of the 'unprotected' nature of the 8086, some programmers took advantage of this wraparound to actually update low memory addresses (why? -- well you'll have to ask them).
But, on the '286, Intel either 1) did not realize this wrapping occurred, 2) did know but did not care, 3) was arrogant enough to assume no one would ever use their shiny new '286 with its fancy protected mode to run any old legacy DOS code 4) some combination of all three. With the result that, the '286, when running in 'real mode' (acting like an 8086) if one pulled the same "wrap off the top of memory" game, because the '286 had more than 20 address pins, the overflow bits that used to be dropped on the 8086 were actually output on the 286. So now, instead of addressing 0 1234 what was actually addressed was the actual address 10 1234 from the overflow example above. And so lots of DOS software refused to run, because it relied on this overflow wrap-around (more likely, one or two critical big company expensive enterprise software packages refused to run) and so IBM needed a way to "ignore" that one extra address bit that the '286 output which did not appear from an 8086 chip, and the A20 gate was born.
As to why the attached control of it to the keyboard control CPU, what I saw somewhere (no longer have the link) was that the keyboard control CPU had an extra, software controllable, I/O pin available, and so they used what was present.
Had Intel simply have included, in the '286, when in real mode, a "truncate all addresses to 20-bits" operation before outputting them, then the '286 would have been "even more compatible" with an 8086 and the A20 hack would never have been necessary.
(Score: 2) by janrinok on Friday February 27, @01:25AM
[nostyle RIP 06 May 2025]
(Score: 2) by Freeman on Thursday February 26, @05:04PM
I've used DOSBox for years to play old games. The vast majority of that time spent playing Master of Magic. However, I recently got kiddo and wife to play the original Oregon Trail and Oregon Trail II with me. Kiddo made it to Oregon, but alas the wife was killed by a bear after having survived a snake bite. I've tried out FreeDOS as well, but the convenience of DOSBox just keeps me coming back. I stumbled on Faux86 and Faux86-remake recently (8086/8088/V20/80186/partial 286 support). https://github.com/ArnoldUK/Faux86-remake [github.com] https://github.com/jhhoward/Faux86 [github.com] (originally based on the Fake86 emulator by Mike Chambers) The original Fake86 emulator site linked to on the Faux86 github is not functional. They call them "bare metal emulators". I've made a first stab at getting the Faux86-remake to work on my Raspberry Pi 4, but all I got was a black screen with a blinking cursor. (I would prefer to not format a 16GB USB drive as a 32MB drive.) There's probably some fiddly bits I need to get just right, but I am hopeful that I can have an extremely fast to boot DOS emulation station. That said, LibreElec only takes 20 seconds or so to boot and is a nice little package with more functionality. Kiddo watched some Mr. Rogers Neighborhood through the PBS Kids app this morning on the little "PiStation" I setup.
Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"