OSDev.org

My previous attempt at asking was justifiably "shot down" , since it was a very generic one...so let me try again.

I know 80x86 assembly and C and I am familiar with many O/S algorithms and topics (between other things). What I do not know is how the actual PC hardware operates, i.e. where to start from in order to have a good overall grasp of how PC hardware works.

First of all, the target: an O/S with preemptive multitasking, threads, a filesystem, a GUI, network support etc...i.e. the usual stuff an O/S offers today (for a unix-like operating system).

I would like to know what is the most common denominator for PC hardware, i.e. what are the PC hardware standards so as that I can write some basic drivers for my operating system. For me, the basic hardware components are (in parentheses, what I consider as "standard", i.e. the lowest common denominator that most devices are compatible with):

1) the CPU (386)
2) the I/O devices: keyboard (AT), mouse (serial), IDE floppy disk/hard disk/CD-DVD drive, network card (3COM)
3) the motherboard devices: the PIC, the PCI bus, DMA, USB.
4) the peripherals: video card (VGA), soundcard (soundblaster).

My questions are:

1) are the above devices enough for the operating system I want to make or I am missing something? are the standards correct?

2) is there a site which has all the necessary information gathered together in one big comprehensive reference book or do I have to go searching?

Thanks a lot for your attention.

By the way, if the reply to #2 is negative, i.e. there is no site which has all the necessary knowledge for a basic o/s, then perhaps I can make such a contribution (and learn, in the way, what I want).

axilmar wrote:What I do not know is how the actual PC hardware operates

You press the 0/1 switch. The PSU will transform 230V into 3,3V (max. 16A), 5V and 12V (max. 4 A). The main part of mainboard is powered on, including the CPU. Vrooom-vroom goes the fans. The mainboard will check if a processor is present, and installed properly. If yes, the actual BIOS code will "extract" from ROM to the RAM and it will perform the whole POST, including ramtest and stuff. Beep-beep goes the speaker if something's wrong.

(...)

After many initializations, checks and such, the BIOS will try to scan the possible disks using the boot sequence specified in the bios setup utility. And here it goes, the boot process. This fully relies on the OS.

...read on
http://en.wikipedia.org/wiki/Power-on_self-test
http://en.wikipedia.org/wiki/Booting
http://en.wikipedia.org/wiki/Operating_system
www.google.com
including OSdev wiki, and many more other links

mouse (serial)

If someone has a mouse, its most likely PS/2, not a serial one. I own 5 mice, of which only one is serial. Besides, ps/2 mice are better documented.

network card (3COM)
(...)
soundcard (soundblaster).

the best denominator is that neither is present. I have enough boxes that do not have a network card, and a few who don't have a soundcard. Also, these devices are quite varied so even with a 3com card you are lucky to get 25% of the share. If you are opting for old machines, the soundblaster is pretty common, but currently the AC'97 and HDA chips are taking over, so that rate is falling as well.
In essence, you'll need to support more than one of those to get a decent coverage, like sb+ac'97 for sound, 3com+rtl+ne2k+intel10/100 for network.

the motherboard devices: the PIC, the PCI bus, DMA, USB.

I'd say PIC, PIT, DMA and KBC. These are present on virtually every machine. PCI usually only if you have a pentium or better, and usb when its slightly newer than that. That said, since you are considering the soundblaster card you will need some form of ISA support as well.

video card (VGA)

While the vga is the common denominator, you probably want to up that to VESA in order to support more than 640x480 in 16 colours.

If you want a good idea of what's around, go to the project announcement forum and look up the test beds thread.

2) is there a site which has all the necessary information gathered together in one big comprehensive reference book or do I have to go searching?

Well, its here. read the link solar gave you in the other thread and you should be able to know how to get it.

Combuster wrote:

mouse (serial)

If someone has a mouse, its most likely PS/2, not a serial one.

Actually, by the time you get anywhere with your OS, it's probably safe to assume the mouse is either USB or Something Completely Different (TM).

PCI usually only if you have a pentium or better, and usb when its slightly newer than that.

Again, by the time you get anywhere, it is likely you will have a hard time finding boxes that are not PCI-E, or whatever they have come up with in the meantime.

That said, since you are considering the soundblaster card you will need some form of ISA support as well.

ISA is dead today, and will be forgotten by the time... you get the idea.

The whole point of my post: You are quoting the "common denominator" of yesteryear. Be aware that getting an OS to a point where it actually can do anything worth mentioning takes years, and you better plan for the next decade if you don't want to find yourself out of testing hardware...

Hi,

@Solar: I got a nice "new" computer yesterday - an AMD Am5x86 CPU with 32 MB of RAM, ISA sound, CD, a pair of 500 MB disk drives, PCI video (Cirrus Logic), etc. There's nothing wrong with it, it cost me nothing, and one day it'll make an nice addition to a distributed cluster. Heck, it's part of my "grand plan" - a cluster of cheap/disposable computers (where all hardware resources are shared) giving similar performance to the same number of modern/expensive computers running a non-distributed OS (where hardware resources aren't shared, and spend most of their time idle).

@Axilmar: Solar does have a valid point. The important thing is the interfaces, protocols, etc that device drivers use to work with the rest of the OS, and not the device drivers (or devices) themselves. These interfaces, protocols, etc should be designed to handle any hardware (past, present and future), so that anyone can add device drivers to support any hardware at any time.

Of course if you're going to write some device drivers it makes the most sense to either write drivers for the simplest hardware (e.g. standard VGA), or the most common hardware (e.g. Intel's 845 integrated graphics?), or whatever you happen to be able to test (e.g. there's no point writing a Trident video driver if you don't have a Trident video card to test it on)...

Alternatively, if you're looking for generic device support (e.g. generic drivers that give basic functionality when there is no suitable device driver), then I'd go for VGA (unless you can use BIOS/VBE to setup a default framebuffer interface during boot or virtual80x86 to use BIOS/VBE after boot), PS/2 keyboard and mouse (and worry about USB much later), ATA/IDE/PATA hard disk and ATA/ATAPI CD-ROM. I wouldn't worry about sound (people can live without it) or networking (I doubt you can get generic support without a device driver designed for the device).


Cheers,

Brendan

Brendan,

Thanks a lot for the input. My question was due to the following reasons:

1) In order to know how to structure the interfaces/protocols of the devices, I need to know what capabilities the hardware has, at least the basic ones.

2) I need to write some basic drivers for testing purposes/reference implementations.

3) I need to know what hardware devices must be initialized so as that the computer can work.

I apologize that my questions might sound stupid, but we all have to start from somewhere .

Hi,

In the (relatively modern) PC, there are a few devices that you can assume are present (such as the PIT, PICs, PCI bus and so on). These are pretty much essentials for the computer to work (ok - you can replace PICs with the APIC and so on, but you get the point).

I would suggest that Bran's kernel development tutorial (http://www.osdever.net/bkerndev/) is a good place to start, as you will be taken through the initialisation of the essential hardware.

Once you get to peripherals such as network cards, sound devices and so on, things are a lot less standard (it sounds like you have already picked this idea up) and the recommendation is to read datasheets and source code to work out how it all fits together. By the time you have successfully implemented Bran's tutorial and extended it a bit (perhaps with PCI detection code and a better diagnostic printf()), you will be more ready to think about how to implement device management in your own OS.

HTH,
Adam

Thanks a lot!

The OSDev wiki actually contains much of the information I need.

From what I understand, there is not a base "standard" which I can rely on, so I have to pick my own "standard" set of hardware to work on, possibly one that emulation is provided for.

Hi,

axilmar wrote:Thanks a lot for the input. My question was due to the following reasons:

1) In order to know how to structure the interfaces/protocols of the devices, I need to know what capabilities the hardware has, at least the basic ones.

No!

For this purpose, your interface/protocols need to be able to handle the capabilities of the most complex devices, not just the capabilities of the most basic devices.

For example, for video you might want to consider 2D/3D acceleration, SLI and stereoscopic/3D monitors. Even for 2D graphics you might want the interface to handle depth, so that icons are little closer to the user than the background/desktop and window borders are raised slightly (if the hardware supports it).

For playing digitized sound, software might tell the sound card where the sound is positioned (e.g. behind the user, to the left of the user, etc). If the sound is meant to come from behind the user but the hardware is stereo and not surround sound, then the driver might just ignore the front/back information (but the interface/protocol still needs it).

For hard disks, you might want an asynchronous interface that can take advantage of Native Command Queuing that modern SATA (and SCSI) drives support (even though a synchronous interface might be fine for basic hardware). There's also SMART (or Self-Monitoring, Analysis, and Reporting Technology), noise/performance controls and security features.

axilmar wrote:2) I need to write some basic drivers for testing purposes/reference implementations.

Yes, but you need hardware to test these drivers on. For example, SoundBlaster is/was a very popular sound card but I don't have any of them here and couldn't test it, so I'd choose AC'97 or ESS AudioDrive instead. The ESS AudioDrive cards I have contain sound, joystick and a non-IDE (Sony/Panasonic/Creative?) CD-ROM interface, so I couldn't say I support these cards unless the device driver supports joystick and CD too. For this reason I'd probably start with an AC'97 driver instead, but I've heard there's differences between different AC'97 chipsets so it might be a "Intel 945 chipset AC'97 sound driver".

axilmar wrote:3) I need to know what hardware devices must be initialized so as that the computer can work.

How do you define "work"? If I want to run a headless server, then the computer works fine without any keyboard, mouse or video drivers. If I want to run a diskless X client, then the computer works fine without any hard disk or CD-ROM drivers. If I only want to play single-player games, then the OS would work without networking, printers, scanners, modems, etc. None of the hardware is actually needed by everyone.

Once you've got a working kernel (and support for gateA20, PIC and/or I/O APICs, RAM and some sort of timer for the scheduler, and maybe multi-CPU), you'll hopefully start thinking about auto-detection (e.g. scanning the PCI bus).

After that you'll choose pieces you want to do next (e.g. video, keyboard, disk drives or networking), design the device driver interface for whatever you chose (see #1 above), and then write a device driver for whatever you chose (see #2 above). You'll repeat this forever.

What you're probably after is a list of generic drivers that you could use when you don't have complete drivers. For example, a "generic VGA" driver that someone might be able to use until there's a proper driver for their fancy Nvidia card.

For this purpose, for video you could setup a default video mode during boot and use a "framebuffer" video driver, use BIOS/VBE (e.g. with virtual8086 mode), and/or have a "VGA only" driver.

For hard disk and CD-ROM you could do generic ATA/ATAPI (which won't help for SCSI and might not support bus mastering, NCQ, SMART, RAID, etc).

For network cards AFAIK you're mostly screwed (you need something designed for the card).

For keyboard use PS/2 (for USB keyboards the BIOS emulates PS/2 for backwards compatability).

For sound I wouldn't bother with generic driver/s (sound isn't important - if there isn't a driver designed for the card, then give them silence).

Serial ports, parallel ports and floppy are standard (no need for generic drivers).

For USB controllers, AFAIK there's only 3 standards and all USB controllers comply with one of those standards. For USB devices there's standards for some device types - one standard for all human interface devices (e.g. keyboard), one standard for all storage devices (e.g. hard disks, flash memory), etc. These standards cover basic functionality (not full functionality), so you may eventually need drivers designed for specific devices.

Modems are mostly all compatible with the Hayes AT command set, but I don't know much about how fax modems or voice modems work.

For scanners and printers, I have no idea - I think most printers will still print raw ASCII in black & white (like they used to in the good old "type foo.txt > lpt1" days).


Cheers,

Brendan

No! Smile

For this purpose, your interface/protocols need to be able to handle the capabilities of the most complex devices, not just the capabilities of the most basic devices.

For example, for video you might want to consider 2D/3D acceleration, SLI and stereoscopic/3D monitors. Even for 2D graphics you might want the interface to handle depth, so that icons are little closer to the user than the background/desktop and window borders are raised slightly (if the hardware supports it).

For playing digitized sound, software might tell the sound card where the sound is positioned (e.g. behind the user, to the left of the user, etc). If the sound is meant to come from behind the user but the hardware is stereo and not surround sound, then the driver might just ignore the front/back information (but the interface/protocol still needs it).

For hard disks, you might want an asynchronous interface that can take advantage of Native Command Queuing that modern SATA (and SCSI) drives support (even though a synchronous interface might be fine for basic hardware). There's also SMART (or Self-Monitoring, Analysis, and Reporting Technology), noise/performance controls and security features.

Now we are talking! that's the kind of info I wanted.

How do you define "work"? If I want to run a headless server, then the computer works fine without any keyboard, mouse or video drivers. If I want to run a diskless X client, then the computer works fine without any hard disk or CD-ROM drivers. If I only want to play single-player games, then the OS would work without networking, printers, scanners, modems, etc. None of the hardware is actually needed by everyone.

Work as by doing most of the tasks an average user does, i.e. office work, internet, play some games.

Once you've got a working kernel (and support for gateA20, PIC and/or I/O APICs, RAM and some sort of timer for the scheduler, and maybe multi-CPU), you'll hopefully start thinking about auto-detection (e.g. scanning the PCI bus).

So what devices I need exactly for a working kernel? my list so far includes: CPU (setup), PIT, PIC, gateA20.

I know nothing about multi-CPU kernels, and I did not see anything in the wiki, so any links/help will be appreciated.

For sound I wouldn't bother with generic driver/s (sound isn't important - if there isn't a driver designed for the card, then give them silence).

I have to disagree with that - audio feedback is quite important.

Brendan, again, many thanks. You've been more than helpful.

axilmar wrote:I have to disagree with that - audio feedback is quite important.

...unless you're working with a couple of other blokes in an office, in which case you'll get killed if you don't disable any fancy "audio feedback".

Solar wrote:

axilmar wrote:I have to disagree with that - audio feedback is quite important.

...unless you're working with a couple of other blokes in an office, in which case you'll get killed if you don't disable any fancy "audio feedback".

Sure, there should be an option to turn the sound off . Still, this does not diminish the importance of it.

Hi,

axilmar wrote:

Once you've got a working kernel (and support for gateA20, PIC and/or I/O APICs, RAM and some sort of timer for the scheduler, and maybe multi-CPU), you'll hopefully start thinking about auto-detection (e.g. scanning the PCI bus).

So what devices I need exactly for a working kernel? my list so far includes: CPU (setup), PIT, PIC, gateA20.

The complete list of hardware required by a (micro)kernel is very short - gateA20 (enabled it and forget about it), PICs and/or I/O APICs, CPU/s, RAM and some sort of timer for the scheduler...

For the timer, it doesn't really matter which timer (PIT, CMOS/RTC, localAPIC, HPET), and you might want to use a pair of timers (one for scheduling and another for keeping track of "time of day") but the same timer can do both. For multi-CPU your scheduler might want a seperate timer for each CPU (you can expect to find a local APIC timer in each CPU in this case).

I/O APICs are similar to PICs (but designed for multi-CPU and with more inputs and less IRQ sharing).

Don't forget RAM - the need to manage memory can be responsible for half the code in a micro-kernel.

Note: Monolithic and hybrid kernels have the same hardware requirements (some hardware is required by the kernel, while most hardware is not required by the kernel but may be supported so applications, etc can use them).

axilmar wrote:I know nothing about multi-CPU kernels, and I did not see anything in the wiki, so any links/help will be appreciated.

I'd recommend starting with Intel's System Programming Guide (the chapter called "Processor Management and Initialization" followed by the "Advanced Programmable Interrupt Controller" chapter, then the "Multi-Processor Management" chapter). I'd also recommend reading these chapters twice - the first time through ignore anything you don't understand and just keep reading, and the second time ask us about anything you don't understand.

There's also Intel's Multiprocessor Specification which is a specification that describes how the BIOS tells the OS about other CPUs and contains some information on IRQ routing in SMP systems. There is another specification called ACPI that an OS can use to get the same information (and a lot of other stuff) but ACPI is an over-complicated mess (don't bother with ACPI until you understand everything else).

You might also want to look at this discussion - it covers a lot of the practical considerations.

axilmar wrote:

For sound I wouldn't bother with generic driver/s (sound isn't important - if there isn't a driver designed for the card, then give them silence).

I have to disagree with that - audio feedback is quite important.

I wouldn't know - the computer I use for everything (except playing games) doesn't even have a sound card.

None of my computers have smell cards or touch cards either - it's lucky humans rely on sight so much (and I'm glad - the annoying startup jingle Windows machines have before I disable it is bad enough without the "Microsoft Smell")...


Cheers,

Brendan

axilmar wrote:Sure, there should be an option to turn the sound off . Still, this does not diminish the importance of it.

What I meant to say is that sound is strictly optional. It can add to the overall pleasant experience of a good OS / UI, but it should never carry vital information exclusively - i.e., never rely on sound.

Unless you are writing a system which may be used by sight impaired users.