Tuesday, January 20, 2009

Needle in the haystack!

Last week my co-worker and me searched the internet for the document that lists all the PnP ID (used in ACPI mostly). It took for both of us a while to get that document, supposed to be maintained by Microsoft. It is maintained as a text document hidden in MSDN documentation online. That made me think about other specifications and documents - we, the BIOS Engineers search time to time.

All those documents are scattered in 100's of websites. I decided to create a link to those documents in one of my blog post here and maintain it! Let us see how it goes.. if you have any suggestions/corrections let me know.

Wednesday, January 14, 2009

Size does matter!

Around 1992 the BIOS vendors started to compress part of their BIOS. Before that the BIOS was uncompressed and kept in 64KB EPROM. I remembered spending lot of time in EPROM UV erasers and blank checking the EPROMs.

During the early stage of the BIOS there are not many chips to initialize. Memory detection is simple and straight forward, super I/O initialization is simple and nothing to enumerate - most of the configuration is through hardware jumpers. So 64KB was enough and it is kept as a 'tiny' memory model - single 64KB segment! Since the ROM is an EPROM no worry of corruption and thus no hardware protected boot block!

When more companies started making x86 clone CPUs, introduction of various storage formats (5 1/4, 3 1/2 Floppy drives, various HDD drives) and PnP buses (ISA PnP anyone?) made BIOS size grew dramatically. Every extra byte was squeezed out of BIOS. BIOS vendors started providing OEM with tools to select what CPU support they need in their BIOS. There was a time when people can choose 8 different CPU vendors each with different flavors of 386 or 486 compatible chips.

Compressing a certain portion of the BIOS was the only solution at that time. Initially only a very small portion of the BIOS was compressed. BIOS code was also separated into boot (or POST) and runtime code at this time. Mostly runtime code was compressed. Boot and runtime code were kept in two different segments. Boot code normally invokes runtime code using a single entry point with function numbers. The boot code should wait till runtime code gets uncompressed before using this interface. This was an ugly implementation that lived for quite sometime.

The main design choice for this ugly idea was Time-To-Market (famous TTM). There were not much Engineers to do parallel development of a better BIOS core (at least in the company I worked for). It worked perfectly for 1/2 decade, then the interface got uglier and EEPROM size increased to 128KB in newer systems. At this point, BIOS moved out of Shadow RAM and into RAM.

For a while it looked like we had lot of space both in ROM & in RAM, but not for long!

Saturday, January 10, 2009

BIOS and me!

My first contact with BIOS was with my final year under grad project in 1992. Our project is to create a compressed disk by hooking to INT13h handler for MS-DOS. It was fun playing with low level interrupts and x86 Assembly.

After graduation my first job was mainly with Unix System V & SCO Unix. Next job was in Networking drivers.. where I worked with fun MS-DOS/Windows 3.1 technologies like Extended Memory, Expanded Memory & Cloaking - art of using 32bit code/data in MS-DOS. I lasted a year each in my first two jobs.

Then I got my contact with BIOS again in my third job in 1995. It was a long affair with BIOS from that time. I was with that company till 2007 worked in various locations. I might soon move away from BIOS as full time job. This blog - biosism - is my journey to past into this world of 'neglected elitism'.