Where can I find information about ports?

[21or23]

Hi!

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.

[Brendan]

Hi,

In general, all I/O ports are either part of a legacy/ISA device (serial, parallel, 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).

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).

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 (no sane person uses the BIOS for serial, parallel, keyboard, floppy, hard drives, etc, 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).

Lastly, for some device types there's a standard interface. This includes USB controllers (AFAIK there's only 3 different standards for this - UHCI, EHCI 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).

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 isn't thousands of guides, one for each device, or any other "hand holding" - you need to find, read and understand the manufacturer's documentation).

Fortunately (IMHO), for a good OS design you don't actually need to write many device drivers (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 boot code, 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).

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

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.

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 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.

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).


Cheers,

Brendan

[bewing]

As Brendan said, you need to do a lot of reading (and make sure you take notes!) before you can start doing much coding. A good place to start a few weeks of reading is our wiki: Expanded_Main_Page

[21or23]

Such nice people here! I thought no one would care to read the longer version of my question, but you are giving me a run for words. Thanks a lot for the detailed reply and the tips. Hopefully, I will be reading some material and specific specifications to get the things working. Moreover, I will be hanging around at this place, if I get enough time.

[codemastersnake]

try out ralf brown's port list. I'll help!

[eddyb]

go http://www.cs.cmu.edu/~ralf/files.html, download the part D, and in it you have port.a, port.b, port.c.
I have no ideea if i can attach them, they are copyrighted.

[21or23]

Wonderful! Thats exactly what I was looking for. I knew about Ralf Brown's interrupt list, but had no clue about the port list. That guy is a genious. Thanks Shiner/Snake.

I might need your help Snake. So, be ready!