The 386's main register bank, at the bottom of the datapath. The numbers show how many bits of the register can be accessed. (Credit: Ken Shirriff)

The Convoluted Way Intel’s 386 Implemented Its Registers

May 5, 2025 by Maya Posch 4 Comments

The fact that modern-day x86 processors still pretty much support the same operating systems and software as their ancestors did is quite a feat. Much of this effort had already been accomplished with the release of the 80386 (later 386) CPU in 1985, which was not only the first 32-bit x86 CPU, but was also backwards compatible with 8- and 16-bit software dating back to the 1970s. Making this work transparently was anything but straightforward, as [Ken Shirriff]’s recent analysis of the 80386’s main register file shows.

Labelled Intel 80386 die shot. (Credit: Ken Shirriff)

Using die shots of the 386’s registers and surrounding silicon, it’s possible to piece together how backwards compatibility was implemented. The storage cells of the registers are implemented using static memory (SRAM) as is typical, with much of the register file triple-ported (two read, one write).

Most interestingly is the presence of different circuits (6) to support accessing the register file for 8-, 16- or 32-bit writes and reads. The ‘shuffle’ network as [Ken] calls it is responsible for handling these distinct writes and reads, which also leads to the finding that the bottom 16 bits in the registers are actually interleaved to make this process work smoother.

Fortunately for Intel (and AMD) engineers, this feat wouldn’t have to be repeated again with the arrival of AMD64 and x86_64 many years later, when the 386’s mere 275,000 transistors on a 1 µm process would already be ancient history.

Want to dive even deeper in to the 386? This isn’t the first time [Ken] has looked at the iconic chip.

[Ken] Looks At The 386

October 16, 2023 by Al Williams 27 Comments

The 80386 was — arguably — Intel’s first modern CPU. The 8086 was commercially successful, but the paged memory model was stifling. The 80286 also had a protected mode, which differed from the 386’s. [Ken Shirriff] takes the 386 apart for us in a recent blog post.

The 286’s protected mode was less successful than the 386 because of several key limitations as it was a 16-bit processor with a 24-bit address bus. It still required segment changes to access larger amounts of memory, and it had no good way to call back into real mode for compatibility reasons. The 386 fixed all that. You could adopt a segment strategy if you wanted to. But you could also load the segment registers once to point to a 4 GB linear address space and then essentially forget them. You also had a virtual 86 mode that could simulate real mode with some work.

The CPU used a 1-micron process, compared to the 1.5-micron process used earlier. The chip had 285,000 transistors (although the 80386SL had many more). That was ten times the number of devices on the 8086. The cheaper 386SX did use the 1.5 micron process for a while, but with a 16-bit external bus, this was feasible. While 285,000 sounds like a lot, a Core i9 has around 4.2 billion transistors. Times have changed.

A smaller design also allowed chips like the 386SL for laptops. The CPU took up only about a fourth of the die. The rest held bus controllers and cache interfaces to cut costs on laptops. That’s why it had so many more transistors.

[Ken] does his usual in-depth analysis of both the die and the history behind this historic device. We spent a lot of time writing protected mode 386 code, and it was nice to see the details of a very old friend. These days, you can get a pretty capable CPU system on a solderless breadboard, but designing a working 386 system took a few extra parts. The 80286 was a stepping stone between the 8086 and 80386, but even it had some secrets to give up.

Version 1.8 of the 80386 ISA SBC in its assembled glory. (Credit: Alexandru Groza)

Building Your Own 80386DX ISA Single Board Microcomputer

March 30, 2022 by Maya Posch 36 Comments

Having grown up with 386-level systems during the early 90s like so many of us, [Alexandru Groza] experienced an intense longing to experience the nostalgia of these computer systems from an interesting angle: by building his own 80386DX-based single board computer. Courtesy of the 16-bit ISA form factor, the entire system fits into a 16-bit ISA backplane which then provides power and expansion slots for further functionality beyond what is integrated on the SBMC card.

Having started the project in 2019, it is now in the home stretch towards completion. Featuring an 80386DX and 80387DX FPU alongside 128 kB of cache and a grand total of 32 MB of RAM, an OPTi chipset was used to connect with the rest of the system alongside the standard 8042-class PS/2 keyboard and mouse controller. A large part of the fun of assembling such a system is that while the parts themselves are easy enough to obtain, finding datasheets is hard to impossible for some components.

Undeterred, some reverse-engineering of signaling on functional mainboards was sufficient to fill in the missing details. Helpfully, [Alexandru] provides the full schematics and BOM of the resulting board and takes us along with bootstrapping the system after obtaining the PCBs and components. After an initial facepalm moment due to an incorrectly inserted (and subsequently very dead) CPU and boot issues, ultimately [Alexandru] gave up on the v1.6 revision of the board

Fortunately the v1.8 revision with a logic analyzer led to a number of discoveries that has led to the system mostly working, minus what appears to be DMA-related issues. Even so, it is a remarkable achievement that demonstrates the complexity of these old systems.

MSDOS Development With GCC

May 14, 2018 by Al Williams 19 Comments

It might seem odd to think about programming in MSDOS in 2018. But if you are vintage computer enthusiast or have to support some old piece of equipment with an MSDOS single board computer, it could be just the thing. The problem is, where do you get a working compiler that doesn’t have to run on the ancient DOS machine? Turns out, gcc can do the trick. [RenéRebe] offers a video demo based on a blog post by [Chris Wellons]. You can see the video, below.

The technique generates COM files, not EXE files, so there are some limitations, such as a 64K file size. The compiler also won’t generate code for any CPU lower than a 80386, so if you have a real 8086, 80186, or 80286 CPU, you are out of luck. The resulting code will run in a real DOS environment on a ‘386 or higher or in a simulator like DOSBox.

You might be thinking why not use the DJGPP port of gcc to DOS. That sounds good, but it actually doesn’t produce true DOS code. It produces code for a DOS extender. In addition, [Chris] had trouble getting it to work with a modern setup.

The only real trick here is using the right combination of gcc flags to create a standalone image with the right codes. A COM file is just a dump of memory, so you don’t need a fancy header or anything. You also, of course, won’t have any library support, so you’ll have to write everything including functions to, say, print on the screen. Of course, you can borrow [Chris’] if you like.

The last pieces of the puzzle include adding a small stub to set up and call main and getting the linker to output a minimal file. Once you have that, you are ready to program like it is 1993. Don’t miss part 2, which covers interrupts.

If you pine away for QuickBasic instead of C, go download this. If you just want to run some old DOS games, that’s as close as your browser.

Continue reading “MSDOS Development With GCC” →