Where Can I Find Information About Ports

This article's tone or style may not reflect the encyclopedic tone used throughout the wiki. See Wikipedia's article on tone for suggestions.

This page or section refers to its readers or editors using I, my, we or us. It should be edited to be in an encyclopedic tone.

Question: Where Can I Find Information About Ports?

I have been trying to code a kernel (starting from Brandon's tutorial at osdever). I was lucky to find the ports to display data on screen, to read from a sector, to read the time (CMOS) and to reboot. Where can I find more information? I want to get into graphics mode, so that I can display images.

The long version: So, I started with a tutorial, writing hello world was easy. Earlier I had worked on assembly and wrote a simple text-drawing program using BIOS interrupts. But, this time I faced the kernel stuff, and it used ports to display data ("Hello World"). I have yet to read the documents properly to appreciate everything. But, anyways I went on searching and I was able to replace "Hello World" with some data on the disk, which required the knowledge of LBA. I had stumbled on cylinders etc ... the earlier way of reading sector which did not work for me. After knowing the LBA ports, and going through Ext2 Documentation, I was able to read a small file on the disk. Later, going through other people's code, I came across the code to access CMOS time and how to reboot.

But, now when I want to add shutdown, graphics mode, network and other things, its getting a little painful. I feel the need of a guide.

Kindly help!

Thank You.

Hi,

In general, all I/O ports are either part of a legacy/ISA device (serial ports, parallel ports, PS/2 keyboard, floppy, CMOS) and/or part of the chipset, or part of a PCI device. Regardless of what it is you need the documentation for the specific thing (for e.g. for "XYZ ethernet card" you'd need the documentation for "XYZ ethernet card", and the documentation for "ABC ethernet card" will be useless).

Legacy Hardware And Backwards Compatibility

In some cases there's a legacy hardware interface for backward compatibility - for e.g. most video cards support the old VGA I/O ports (until you put them into "native mode" so you can actually use most of it's features). These legacy interfaces are probably worth supporting until you've got proper device drivers. In this case you need the documentation for the legacy device (rather than the documentation for the correct/actual device). For e.g. for a "top of the line" ATI video card you'd want IBM's original VGA documentation (or equivalent information).

Legacy Software Interfaces

Also, for some devices there's a legacy software interface. This is mostly limited to video cards though (the VESA/VBE interface) because the rest is too crappy^[how?] (no sane person uses the BIOS for serial ports, parallel ports, PS/2 keyboard, floppy, or hard drives^[why?] even though it's possible in theory). Like the "legacy hardware interface", this is mostly just a short-term solution (basic functionality with no extra features and poor performance^[how?]).

Standard Interfaces

Lastly, for some device types there's a standard interface. This includes USB controllers (AFAIK there's only 4 different standards for this - UHCI, EHCI, XHCI and OHCI) and IDE/ATAPI hard disk controllers (but not SCSI controllers), and not much else. These standard interfaces are actually good interface (not legacy interfaces).

Supporting Devices Is Difficult

Mostly, to support all devices properly (without using legacy interfaces) you need to read through thousands of pieces of documentation and write thousands of different device drivers (and no, there are not thousands of guides, one for each device, or any other "hand holding" - you need to find, read and understand the manufacturer's documentation).

Keep It Minimal

Fortunately (IMHO), for a good OS design you don't actually need to write many device drivers^{[according to who?]} (a few common drivers to get things started perhaps). You only really need to design, implement and document suitable device driver interface/s, so that other programmers can easily write the device drivers later. For example, you might write one device driver for one ethernet card, and (hopefully, one day) twenty more people might use your documentation (and your first device driver, as a reference) to implement fifty more device drivers for fifty more ethernet cards.

Basically what I'm saying is that (IMHO) sane OS developers don't actually write an OS. Instead they write Bootloaders, kernels, and documentation. Only after the kernel and documentation are entirely complete do they worry about device drivers, file systems, applications, etc (except for some common/special case stuff that they need to test the kernel and the kernel's interfaces).

Question: Shutdown, Graphics, Network, and Others

But, now when I want to add shutdown, graphics mode, network and other things, its getting a little painful.

Shutdown (APM or ACPI)

For shutdown there's 2 different "legacy software interfaces" (APM and ACPI). APM is old but simple, while ACPI is new but a huge over-complicated pain in the neck. To do it without these legacy software interfaces you'd need to see the documentation for each motherboard/chipset.

Video (BIOS, VESA/VBE, VGA Interface, or Native)

For video there's 2 legacy software interfaces (the original BIOS Int 0x10 interface, and the VESA/VBE extensions), plus one legacy hardware interface (the "VGA standard"). To do it properly you need programming information for each video card (which can be very difficult to obtain in some cases). Even if you do have good information a modern video a device driver is complex (especially if you start looking at 3D special effects and implementing a JIT compiler for shader language - e.g. similar features and performance to DirectX 10), and it could easily take over a year to implement a good device driver for one video card.

Network Cards

For network cards there is no legacy software interface and no legacy hardware interface - to do it properly you need the manufacturer's documentation (or equivalent documentation).

Source

The information contained here was roughly compiled from a post on the forums here, http://forum.osdev.org/viewtopic.php?f=15&t=17704.