The Intel 80376 was an x86 CPU that didn't support Real Mode or paging. It was targeted for embedded applications and it wasn't very successful at that (the 80386EX overtook it).

Under these conditions, it seems hard to believe someone could ever use it to build a PC compatible. Yet BIOS function INT 0x15, AH=0xC9 (included in some IBM PS/2 computers), which is supposed to detect the CPU type, seems to have a code (0x33) saved for the "Intel i376".

This raises a number of questions:

  • Was there any PC using the i376 as its CPU?
  • If yes, how did it remain backwards compatible, since the i376 doesn't support Real Mode?
  • If no, why did the BIOS authors reserve such a code for a CPU clearly targetted towards a different market?
  • 4
    Even as embedded, it's stupid. Many embedded x86 systems needed to leverage PC environments, BIOS, DOS (for example PC-104), and, for the embedded systems that didn't need any PC compatibility (I've seen aircraft equipment based on i386), they needed long term availability of components, not some wacko parts.
    – Grabul
    Commented Sep 19, 2023 at 18:27
  • 7
    Where it might have made sense is without real mode but with MMU - then it might have been a good choice for a workstation or Unix server etc. But no MMU (and according to the article, slower than a stock 386 besides) that wouldn't make sense either. Commented Sep 19, 2023 at 19:32
  • 1
    It had memory management. See: archive.org/details/… It is missing support for paging.
    – Brian
    Commented Sep 19, 2023 at 19:47
  • @Brian: Unix workstations would want to use paging, not segmentation. Perhaps it could run OS/2, which I think I've heard was designed for 286 protected mode and thus actually used segmentation (since 286 didn't have paging)? Oh, John Dallman's answer talks about that as a hypothetical future for OS/2, so I guess actual OS/2 still needed real mode. But yes, 386 segmentation is memory protection, just not the kind most software wants. Commented Sep 22, 2023 at 14:21
  • @PeterCordes there have been PC Unix implementations using segmentation rather than paging, and (as I imagine you know) x86-style segmented protected-mode is capable of supporting some features of virtual memory (e.g. swap). OS/2 didn’t need real mode (other than to support DOS programs on 286s), but it had 16-bit code segments even on 386s. Commented Sep 22, 2023 at 14:33

2 Answers 2


I'm reasonably sure there were never any machines sold for the PC-compatible market that used the i376, simply because of the obvious compatibility difficulties. I remember it appearing, and never hearing of it again.

An obvious reason to be able to identify it in a PS/2 BIOS would be that the developers were looking forwards to a hypothetical future when OS/2 had become a fully protected-mode operating system and DOS compatibility was no longer important. Adding a value for that would have been a trivial amount of work, and might have impressed a supervisor with the developers' thoroughness.

Either that, or someone writing a specification was told to handle all Intel x86-compatible processors and didn't realise that the i376 was not fully compatible.

  • 3
    I don't think you need "didn't realise...". When I write an enumeration, I like it to be complete :-)
    – dave
    Commented Sep 20, 2023 at 1:40
  • 19
    At the point when the PS/2 came out, IBM and compatible makers had already learned that practically every assumption about "PCs will always ...." proved wrong a few years later. And many of these changed assumptions required ugly kludges. Switching to a "we don't expect this to become relevant, but include it anyway so we don't run into big trouble later" model made quite a lot of sense. Commented Sep 20, 2023 at 6:29

To complement John Dallman’s answer, regarding your last question:

If no, why did the BIOS authors reserve such a code for a CPU clearly targetted towards a different market?

The BIOS authors didn’t reserve anything. Interrupt 15h service C9h works by saving the power-up CPU identifier stored in DX; the 80376’s processor type, given in DH, is documented as being 33h (see page 12–1). The list of known processor types simply reflect the known processor identifiers, as documented by their manufacturers.

It’s likely that whoever filled in the table in Ralf Brown’s Interrupt List (or that table’s sources) didn’t consider the characteristics of the 80376. Many CPU detection libraries of the time describe their ability to identify the 80376 (using this type 33h), even though they wouldn’t actually run on any system built around such a CPU, which shows that this was a common error.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .