OSDev.org

Hi all,

I would like to confirm what i think is correct;

I think the "IBM PC" is a standard motherboard, providing what minimum components it provides (PIC, PPI, RTC etc).

Im a bit confused with the close relationship to the x86. Do all IBM PC's use a x86 arch cpu? Im presuming this is because other arch's do not provide a socket based chip?

Is it safe to presume that motherboards come in IBM PC or custom?

cxzuk wrote:I think the "IBM PC" is a standard motherboard, providing what minimum components it provides (PIC, PPI, RTC etc).

I think that's the best definition I've ever heard. I guess an "IBM Compatible" (i.e. a PC) is any computer that is compatible with the software run on the first IBM PC released in 1981.

cxzuk wrote:Im a bit confused with the close relationship to the x86. Do all IBM PC's use a x86 arch cpu? Im presuming this is because other arch's do not provide a socket based chip?

The original IBM PC ran an 8086 chip. In order to be compatible with the IBM PC, other PCs need to run a chip compatible with this, in order to run the same software. The latest Athlons and Core i7 chips, if you give them the right prompting, will very happily run the same software as that on the original PC. This backwards compatibility is both a great blessing and a great curse. Other CPU architectures do indeed provide socket-based chips; the x86 architecture is the only one that is compatible with the original IBM PC.

cxzuk wrote:Is it safe to presume that motherboards come in IBM PC or custom?

Not really. Every "PC" motherboard these days (i.e. one you would buy in a computer shop, from the likes of Gigabyte or ASUS) is an IBM PC-compatible motherboard. Motherboards for different architectures (like the Beagleboard for ARM) aren't compatible at all with the IBM PC.

An IBM PC compatible = A motherboard compatible with the features found on the original IBM PC (PIT, PIC, RTC, etc) + A CPU compatible with the original 8088 by Intel

Then there's all the stuff added to the PC since 1981, such as the standardised audio added by AC'97 or Intel HDA. That also makes up what an "PC" is, but is a lot harder to pin down.

JackScott wrote:

cxzuk wrote:I think the "IBM PC" is a standard motherboard, providing what minimum components it provides (PIC, PPI, RTC etc).

I think that's the best definition I've ever heard. I guess an "IBM Compatible" (i.e. a PC) is any computer that is compatible with the software run on the first IBM PC released in 1981.

To be fair, the term has been (re)defined many times. Here is a list of the versions in chronological order (the ones in bold are Motorola- rather than x86-based):

• IBM
  • PC
  • PC-XT
  • PC-XT/370
  • PCjr
  • Portable PC
  • PC-AT
  • PC-AT/370
  • PC Convertible
  • PS/2
• Microsoft and Intel
  • PC 97
  • PC 98
  • PC 99
  • PC 2001
• Microsoft
  • See Windows Logo Program

Ah thankyou both for the replies!

I do have a few more questions.

Firstly, im trying to avoid writing any code at this time to detect what hardware components I have available.

I am trying to aim for a long mode kernel, but would be happy to create a protected mode kernel.

What I wanted was to create a class IBM_PC_AT or something that I can use as a legacy solution.

So my questions are;

1) if stated as IBM PC compatible, can I really assume a base (IBM PC/ATX) and be guaranteed to work? (I guarantee to have or emulated 8259 PIC, 8237 DMA, 8253 PIT etc) + MMU?

2) If yes, which do you suggest as the best base to create. Both for a long mode and protected mode kernel. (Best in common compatibility and/or Used features)

2a) Would the same class work for both modes? Or does the hardware change depending on mode?

3) Is the IBM PC the whole spec; Software base (8808), Component base, and also the motherboard shape (form factor)?

cxzuk wrote:1) if stated as IBM PC compatible, can I really assume a base (IBM PC/ATX) and be guaranteed to work? (I guarantee to have or emulated 8259 PIC, 8237 DMA, 8253 PIT etc) + MMU?

There is a common subset, but it's not the entire IBM PC (or XT or AT). For starters, most modern computers don't have tape drives or floppy drives, where those computers did. Most of the hardware is still compatible in a BIOS-based system (UEFI is a whole different beast).

Things like the MMU, FPU and the choice of PIC or APIC really depend on the CPU in question. On a 286 you only have the PIC and (rarely) a FPU. On a modern Core iX chip you have your choice of all this CPU hardware and more (MXX, SSE, etc).

Firstly, im trying to avoid writing any code at this time to detect what hardware components I have available.

When you begin writing your kernel, this is certainly easiest. It's pretty safe to assume that you'll have access to a VGA controller (emulated by the modern powerful Geforce or Radeon chip inside your machine), a standard keyboard (usually emulated by the BIOS from a USB keyboard), some PICs, a PIT, DMA and an IDE-mode HDD controller. This allows you to concentrate on kernel writing instead of writing device drivers for everything.

In a finished kernel, what you really want to be doing is assuming nothing. Most production kernels, for example, uses the ACPI and PCI tables on a modern PC (or probing and guesswork on a not-so-recent PC) to figure out what devices are attached to the system.

I can see you're really concerned about backwards compatibility but I would strongly recommend dropping support for anything that came before the PS/2, which introduced the 80386 chip. After all, it's probably not the case that your user base actually has that kind of old hardware.

The 8086 can only access 1 MiB of memory, offers no protection, and uses a segmented memory model; the 80186 is an 8086 with a few extra features but was mostly used in embedded devices; the 80286 can access 16 MiB of memory and introduced the 16-bit protected mode but its memory model is still segmented and requires an expansion board---you'll even need to reverse engineer the accompanying drivers for the various peripheral boards unless you can find the appropriate documentation (unlikely).

JackScott wrote:In a finished kernel, what you really want to be doing is assuming nothing. Most production kernels, for example, uses the ACPI and PCI tables on a modern PC (or probing and guesswork on a not-so-recent PC) to figure out what devices are attached to the system.

That would be nice but, unfortunately, is problematic. While buses like MCA, EISA, PnP, and PCI have automatic configuration, ISA and LPC do not. There are three possible solution to this problem:

• Assumimg. Advantage: It's the simplest option; disadvantage: the assumptions may be wrong.
• Manual probing. Advantage: It's a form of automatic configuration; disadvantages: it's a hack, it's not always possible, and it may even be harmful in some very unlikely scenarios.
• User configuration. Advantage: Clean solution; disadvantage: users can be stupid, although someone with lots of ISA cards probably knows a thing or two about how they work.

You could, of course, do manual probing first, then try checking the user configuration settings, and if there's a problem with that then fall back to the assumptions; but I would personally recommend just the latter.

your comments and documentation I've read says im 20 years too late to make this idea worth while.

still I've alot of unanswered questions so will be doing a prototype with these assumptions and qemu before a proper kernel. thankyou for your help!

p.s i may stick some of this on the wiki. is that ok?

wow a IBM PC i haven't heard such a term in a while, I have some actual documentation of the 5150 but i doubt it's of any use besides in compatibles. (august 1981) that makes three decades.

cxzuk wrote:2) If yes, which do you suggest as the best base to create. Both for a long mode and protected mode kernel. (Best in common compatibility and/or Used features)

It all depends how compatible you want to be. If you wanted to be compatible with the original IBM PC, you would be severely restricted, and you would end up writing an operating system which was something like MS-DOS.

It needs to be remembered that any operating system you start writing today probably won't be in something like a finished form until ten years from now. So things which are a concern today, such as the prevalence of 32 bit processors, might be less of a concern ten years hence, when almost all computers will have 64 bit processors.

The same goes for the other things on the mother board, such as the HPET and APIC, which were no part of the IBM PC's original design, but are very common today, and will be universal in a few years time.