OSDev.org

Ok, I have done bit of research etc into OS's but now I am wondering since you have to write your own drivers to access the hardware (note this is not built on top of DOS) how do you write the drivers etc? I dont really know asm very well either... so is there like a bunch of registers somewhere for like geting information about the mouse, keyboard etc? is there a list of these somewhere? or are these like interupts? (im not sure if I really no the difference when talking about this, register is a mem local and interupt is interupting the hardware etc) eg like the way to access mode 13h, anyway, I may not really know tons yet, but humor me

well, basically, your driver will access hardware (i/o read & writes, memory-mapped registers, etc) and hook some interrupts to be notified of hardware events (IRQ1 on keyboard, ...). Its job is to translate those informations in something the kernel can use like converting scan codes read out of port 0x60 into ASCII chars that you can write in some STDIN buffer and notify the target program it has input.

For infos about PC hardware, you can search for HelpPC documentation : this is a good place to start...

Note that registers on hardware devices are different to CPU registers. You can read and write CPU registers really quickly because they're on the same piece of silicon; to read and write registers on devices you've got to use the IN/OUT x86 instructions. Device registers are more like ports where you write values and the hardware interprets them; in the right circumstances, the hardware will make values available for reading from its registers.

True hardware interrupts also take on a different meaning to what you might be used to. You can use software interrupts to e.g. call DOS or the BIOS and carry out functions; in this sense, software interrupts are like another form of subroutine call. Hardware interrupts are triggers by a device attached to the computer when something happens and the device needs to notify the CPU. For example, you can set your network card to receive any packets addressed to it; each time it receives a suitable packet, it will trigger an IRQ (Interrupt Request), which gets passed to the CPU and your interrupt handler is called.

Hello, You can detect various mice, keyboards, controllers, sound cards, video cards, etc(you get the idea) using the ISA PnP BIOS(aka BIOS32). You could also probe the PCI bus controller and it could find devices for you. After that detection, you could get your code to load the correct driver. You could also make generic drivers. It is a good idea to make a driver for US (or english/german/japanese, etc. EASY to expand on - change a single table) keyboards and include that in your OS. Most PCs out there access IDE disks. SCSI is out there, but too expensive. IDE drives all have the same ports, so you only need a single driver. If you don't need protected mode, then an IDE driver isn't needed - use Int13h

Cool, thanks guys, also, as far as I know the only 2 cpu modes you can use is protected and real, and AFAIK you cant use real anyway as you can only access 1MB of ram so it is very impractical, so why do I always see people bitching about protected mode etc?

eliscool wrote: Cool, thanks guys, also, as far as I know the only 2 cpu modes you can use is protected and real, and AFAIK you cant use real anyway as you can only access 1MB of ram so it is very impractical, so why do I always see people bitching about protected mode etc?

Actually, there is one other mode option - real flat mode (unreal mode). However, it's is not a very useful option generally speaking, except (for reasons explained below) for video game programming.

The complaints come mainly because all PCs start in real mode, and have to be shifted to p-mode by the OS. This is one of the first actions that any p-mode OS has to make on bootup, and in development it can be very tricky to get it to work right - especially since it involves drastic changes in the memory model, interrupt handling, etc., any of which might cause a triple fault if the tables aren't set up correctly.

The other main reason for the complaints is regarding the ROM BIOS, especially in regards to the video system. Save for a handful of recently added features (e.g., power management), all BIOS functions are 16 bit real mode code; the only way to use them in p-mode is to shift to v86 emulation, which is itself a rather difficult task, and unacceptable slow for general use.

While most of the BIOS features (disk access, keyboard and mouse input, text video, etc.) can and often should be replaced by OS drivers even in real mode, the lack of a 'default' mechanism adds to the up-front development work needed for a p-mode OS. More importantly, certain BIOS features are very specifically dependent on the motherboard's hardware configuration; memory testing, for example, requires specific, a priori information about the memory banking structure, and address decoding mechanisms that the motherboard's chipset uses. Similarly, some add-on cards provide a BIOS interface for real mode, but not p-mode; to use them in p-mode requires proprietary information about the card that the manufacturer may not provide to the general public (in OSes like WIndows, they either provide their own drivers for the systems they are willing to support, or offer a NDA to companies like Microsoft or Red Hat to let them write their own).

The most serious of these cases is regarding accelerated video cards. While (IIUC) the current VESA standard does provide for a p-mode BIOS, most video cards only support the real mode standard. Since even such basic features as resolutions higher than 800x600 are not standardized at the register-access level, this makes writing SVGA drivers for new systems a serious problem.

The choices become to a) use real mode exclusively, b) use unreal mode exclusively, or c) switch back and forth to v86 mode when writing to the video, or d) sign the manufacturer's NDA and pay for the specs for each and every video card you intend to support. None of these are very appealling options, hence the wailing and gnashing of teeth that occurs whenever the issue comes up. While p-mode BIOS support is becoming more and more common, it is far to little too late to really help much.

I'll leave further explication on this issue to those more familiar with the specific issue of video programming.

Comments and corrections welcome.

Also, I would personally recommend that your drivers are seperate modules that you load up on startup rather than the Linux idea of having all the drivers compiled into the Kernel

Ok, I took the big leap and have pretty much learnt asm now, what I knew before was only various tidbits I picked up, and guessing at instruction names, eg mov, push, pop, but I now know it ;D
Anyway, now I have a couple of questions, the resource im using for it adds an 'h' after most of the values, eg 13h, im assuming this is to indicate that the value is hex? I just thought at first everything HAD to be in hex as it didnt prepend the "0x" as in C, so with out the 'h' it would be decimal?
Also I dont really want to use DOS so I cant use DOS interupts like mode 13h for graphics, so where can I get a list or something of BIOS interupts? I am using the AWARD something-or-rather BIOS so I assume basicly everyone else does and whatever BIOS interupts I use will be just about completly portable? (obviously excluding apple computers... am I right here?)
Thanks.

Ok, I think I may be slightly confused, with BIOS and hardware, BIOS is on the rom chip etc, I was thinking you had to do like all the hardware accessing via the BIOS...
please correct me...

ps. I really should get round to registering...

If your operating system is running in protected mode, you can't use DOS at all, and using the BIOS is very inefficient and not straightforward. All BIOS does is act as a set of simple real-mode hardware drivers; for your protected mode OS you will have to fulfil the same role as the BIOS code.

Protected mode is much better than real mode, by the way, so don't worry about the people who complain about it. IMO it's easier to program protected mode anyway.