Deskpro 386 at 30

30 years ago, in September 1986, Compaq announced the Deskpro 386, a PC as revolutionary as it was conservative. Compaq decided to forge its own path and not wait for IBM to introduce a 386-based PC. At the same time, Compaq made only minimal changes to the PC/AT architecture and essentially added a 32-bit CPU (a 16 MHz Intel 80386) to a 16-bit system.

Compaq Deskpro 386 illustration. PC Tech Journal, March 1987, page 53.

Compaq Deskpro 386 illustration. PC Tech Journal, March 1987, page 53.

In retrospect, the Deskpro 386 did much more—and much less—for bringing PCs to the 32-bit era than contemporary observers expected. It was justifiably considered one of the most important new PC products of 1986; for example the PC Tech Journal honored the Deskpro 386 with its 1986 Product of the Year award.

The Deskpro 386 unquestionably set a standard for 386-based PC/AT compatibles, and in hindsight it’s obvious that it was much more successful than IBM’s far more radical 386-based PS/2 machines (we are nowadays running successors of the Deskpro 386, not of the IBM PS/2 systems).

At the same time, the amount of actual 32-bit software that users could run on a Deskpro 386 was negligible. Until the end of the 1980s, the vast majority of PC software was 16-bit, and it took another decade until Windows 95 introduced a more or less 32-bit operating system to the typical PC (neither OS/2 2.0 (1992) nor Windows NT (1993) truly count in that regard).

That said, the Deskpro 386 did enable the development of 32-bit software. Almost immediately, DOS extenders (notably Phar Lap’s 386|DOS) popped up, allowing users to run specialized applications on top of DOS while taking advantage of increased address space and 32-bit processing.

The first 32-bit PC operating systems also didn’t take too long to materialize (386 XENIX and other 32-bit UNIX variants), although early Intel 386 chips had major bugs making it very difficult or impossible to run a 32-bit protected-mode OS with paging. And as mentioned above, it took another decade before the mainstream moved to a 32-bit OS.

Other manufacturers started releasing 386-based PCs before the end of 1986 and in the late 1980s, essentially every OEM except IBM offered a 386 system that was more or less a Deskpro 386 clone. Software written for the Deskpro 386 runs well on later 32-bit PCs.

The Deskpro 386 was expensive yet attractive. It didn’t sell in huge numbers but anyone needing top PC performance in 1986 got one. A 16 MHz 386 was at least twice as fast as a then-typical high-end 8 MHz PC/AT and clones. It is no surprise that for example Microsoft developers used Deskpro 386 machines as soon as they were available.

While the Deskpro 386 was typically used with MS-DOS, an operating system designed for the original IBM PC, Compaq made one very notable addition: CEMM, or Compaq Expanded Memory Manager. CEMM, which later morphed into EMM386, was a critical piece of software which worked with DOS but took advantage of 386 capabilities. It’s fair to say that CEMM and its successor and competitors (EMM386, 386MAX, QEMM) extended the useful life of DOS by several years.

Not to be forgotten is one later arrival, Windows/386. The initial mid-1987 release of Windows/386 specifically claimed to be designed for the Deskpro 386. And although Windows/386 was not a hugely popular product, and was often considered inferior to its contemporaries like Quarterdeck’s DESQview, it was a direct ancestor of Windows 3.0 and Windows 95.

Repeating technical details about the Deskpro 386 would be somewhat redundant. Readers can easily find contemporary reports, such as Compaq Deskpro 386: The New Standard in the March 1987 issue of PC Tech Journal (page 48). Apart from the CPU itself, the only major difference from a PC/AT was the addition of a special slot for a 32-bit memory expansion board.

One notable curiosity is that it was not possible to install a 387 FPU because there was no socket. Due to the major delays in the availability of the 80387, the original Deskpro 386 only had a socket for a 287 FPU—much slower than a 387, but actually available in 1986.

All in all, the Deskpro 386 made Compaq a respected industry leader. After IBM announced the PS/2 line, Compaq ran three-page ads with the following text: Recent PC announcement left Compaq in an enviable position. Compaq still works better. It’s safe to say that history did not disagree with Compaq.

This entry was posted in 386, Compaq, IBM, PC history, PC press. Bookmark the permalink.

19 Responses to Deskpro 386 at 30

  1. Yuhong Bao says:

    Of course, you know that the OS/2 2.0 fiasco is one of my favorite topics. The other fun thing is that MS abandoned the original 386 processor soon after Win95 (and NT 3.51) was released.

  2. bhtooefr says:

    If you’re referring to the original production steppings (the B-step CPUs – at least I don’t think A-steps were production?)…

    NT 3.51 detects in the following order: (based on http://www.geoffchappell.com/studies/windows/km/cpu/identification.htm)

    16 BIT S/W ONLY (by actually doing a calculation known to fail on a defective part)
    B0 stepping (by trying the XBTS instruction and seeing whether it works)
    B1 stepping (by setting the TF bit in eflags, running REP MOVSB, and seeing if a debug exception is thrown at the end of the instruction, or after one iteration)

    If any of those tests fail, NT 3.51 fails to boot. I would be unsurprised if that’s also the case in NT 3.10 and 3.50, but the B1 stepping may not necessarily be an issue – NT isn’t doing mixed bitness in the kernel (the same reason it’s not an issue in Windows 3.1 – apparently Windows 95’s kernel actually had more 16-bit code than 3.1 386 Enhanced’s).

    Also, B0 steppings were a fatal error in Windows 3.1 386 Enhanced…

    Windows 95 has many workarounds in place to handle mixed 16/32-bit code on B1-stepping 80386s, but ultimately Microsoft decided very late in development (soon before, not soon after release) to abandon B1 support: https://blogs.msdn.microsoft.com/oldnewthing/20110112-00/?p=11773

  3. The biggest blunder the CSRG ever made was ignoring the consumer 80386. If they had made a BSD available in the late 80s, and ready to run with the Net/2 drop of 1991 it would have been a contender… but the rise of Linux via FSF tools is pretty amazing too. Up until recently I never tried to cross compile from Windows.. I guess the limited disk space and CPU really held me back.

    At the time it feels like the dos extender market was so entrenched and established, and as the years go by, it’s tiny window of opportunity gets smaller and smaller, just as the incredible delays of Chicago in 1993-1995 seem so trivially minute.

    Maybe I’m just getting old.

  4. Michal Necasek says:

    I don’t know if you can call it a blunder. I expect it never occurred to the CSRG at the time that the 386 was something they ought to care about. Remember that at the time, people ran UNIX on VAXes and Motorola 68000s and MIPSes and SPARCs. It’s not really fair to assume that the CSRG should have guessed in the late 1980s that x86 was going to kill off all the other architectures.

    But I agree that if 386BSD (or something like that) had been available earlier, we probably wouldn’t have Linux everywhere nowadays.

  5. Michal Necasek says:

    Mixed bitness was just one problem. The old steppings also had major issues with paging + 387 (probably because the 387 took so long) which required all kinds of nasty workarounds. The well known 386 POPAD bug was pretty harmless in comparison.

    For NT, the 386 was such an inadequate CPU even when the OS was first released that the decision to not support broken chips should have been very easy. With Windows 95 it was probably a matter of timing. If it had been released in ’93 like originally promised, Microsoft would have probably cared about 386s more. But in August ’95 the broken chips were likely all but gone.

  6. Don’t forget we also got the 80287xl, to try to make things better….

  7. Michal Necasek says:

    We did, and the 287XL is good. But it only came out in 1990, after the i486. I don’t think it was ever intended for 386 systems, only for 286s because it’s much faster than the crummy 287.

    That said, combining a 287XL with a 386 confuses a lot of software in a fun way 🙂

  8. Richard Wells says:

    There was one major difference between the original Deskpro 386 and later 32-bit designs. Compaq eschewed the typical cache design in favor of using static column RAM. That gave the Compaq great memory performance at a low price when running a DOS application or as a file server but wasn’t so good as a general purpose multi-tasking system so later Compaq rejoined the industry in designing around cache.

    The Deskpro 386 was also one of the first system designed to use what became known as shadow RAM to bolster video speed.

    At roughly the same time as the Deskpro 386, PC’s Limited (Dell) introduced a 16 MHz 286 system which was very competitive with the 386-16s but about $3000 less expensive.
    Deskpro 386 with 1MB RAM, HD floppy, 40 MB Hard Drive, EGA card plus monitor was about $7,897; 286-16 with same components was $4,638.

  9. Yuhong Bao says:

    “The old steppings also had major issues with paging + 387 (probably because the 387 took so long) which required all kinds of nasty workarounds.”
    Reminds me of: http://archive.computerhistory.org/resources/text/Oral_History/Intel_386_Design_and_Dev/102702019.05.01.acc.pdf

  10. MiaM says:

    This might be the most stupid question ever, but what is/was CSRG?

  11. Yuhong Bao says:

    The group that developed BSD at Berkeley.

  12. Michal Necasek says:

    CSRG was the Computer Systems Research Group at UC Berkeley. It was formed in 1980, several years after the University got involved in UNIX. It kept going until 1995 or so. In that time, CSRG maintained BSD UNIX and developed things like BSD sockets and the BSD TCP/IP stack. FreeBSD et al are basically the survivors of CSRG, but there is a lot of BSD or BSD-inspired code in other operating systems as well.

  13. Michal Necasek says:

    The original Deskpro had the distinction of using a relatively slow CPU where wait states could still take care of the discrepancy between CPU and RAM speeds. Once they moved to 20 and 25 MHz, there wasn’t really any other option besides cache; DRAM was just too slow. But I’m sure it made the initial design a lot simpler. With a cache controller thrown in, the board/chipset needed all kinds of fun logic to know which address ranges are cacheable and which are not, etc.

    Shadow RAM was definitely a clever idea, almost unavoidable once it made sense to spare the 32K or 128K or so of RAM.

    At the time, 286s were certainly a much better value for anyone who didn’t require 32-bit software. The press was full of stuff about how wonderful 386s were, but only a tiny percentage of the installed systems were 386s. Today we have the Intel Extremely Expensive CPUs instead 🙂

  14. bsd107 says:

    “Until the end of the 1980s, the vast majority of PC software was 16-bit, and it took another decade until Windows 95 introduced a more or less 32-bit operating system to the typical PC (neither OS/2 2.0 (1992) nor Windows NT (1993) truly count in that regard).”

    Wait – Windows NT 3.1 was not a 32-bit operating system???

  15. Michal Necasek says:

    NT 3.1 doesn’t count because it was way too far from a mainstream OS. Even NT 4.0 wasn’t.

  16. MiaM says:

    A nitpick would say that the correct expression would be “typical PC user” as the typical PC were able to run NT if it were able to run Win95 🙂

  17. Michal Necasek says:

    That’s not really true though. NT had significantly higher minimum requirements than Windows 95 (8MB vs. 4MB), and probably even higher practical requirements, especially the amount of RAM required for non-painful operation.

  18. StephenC says:

    Also let to the release of Digital Research Concurrent DOS/386, that used virtual8086 mode
    Havent had chance to read your DR section yet, but will add comments from my memories

  19. MT says:

    NT felt slow as a dog to me, even with decent hardware. I guess it performed well at the things it was designed for (32-bit server tasks with high concurrency etc.) but lagged in what gives high performance to end-users. Here Win95 excelled: Very lean on RAM (less swap on RAM starved machines), high performance and low-weight graphics path/framework (perhaps at some cost to stability) and high quality optimized drivers for same, in general, leaner binaries. This ties into RAM but also gives much faster speed in starting apps. In general, optimized boot speed – NT gave a really bad impression here: slow as a dog to boot compared to Win95, probably not due to bad design, just not a big focus on a server os).

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.