bs - Bootstrap Back to the Source Index
Change log:
23/5/2010 File extension revision, .HTM now .html, .LNK now .link. Please note that this is the early non-EDD ChaOS bootstrap for a FAT16 partition, however it is useful study material for anyone interested in writing bootstrap code for Intel processors. ChaOS now has two other bootstraps, bs1 (EDD FAT16) and bs2 (EDD CFS).
25/12/2008 VESA structure occupies memory just beyond end of bootstrap image in memory. (part of ChaOS multiple VGA support)
16/11/2008 bootstrap now stores active video mode in vmode or vesamode just before switch to protected mode. Operating system now responsible for checking and setting the graphics mode, as necessary on startup
15/11/2008 biSUBDIRBOOT flag added to indicate boot from OS image in the CHAOS.DIR subdirectory
bs.html - - - - - bootstrap source code file
bs.link - - - - - linker control file
Bootstrap Notes
Having grown up with MSDOS, it has always frustrated me that parts of the bootstrap are overwritten by Microsoft during the boot process - this makes it impossible to re-enter the MSDOS bootstrap to do a fast restart of the system - often needed when developing operating system software! Another massive hurdle to development of new operating systems over MSDOS are those BIOS interrupt vectors which MSDOS overwrites during booting. Early ChaOS was developed over MSDOS using WatCOM DOS4GW, so fast rebooting of MSDOS was essential to speed the devlopment cycle. It took two or three years for me to develop this bootstrap. which allowed me to see the BIOS machine state, unadulterated by Microsoft, for the first time. Booting ChaOS from cold, I saw a virgin IVT with all vectors pointing to the BIOS ROM at segment 0Xf000 or the VGA ROM at segment 0xc0000, it looked beautiful. I could then reboot MSDOS instantly by reinstating the IVT, loading a partition table, or MSDOS boot sector to address 0x7c00 and jumping into it.
As ChaOS boots, no part of the bootstrap is overwritten, so it can be re-entered. And ChaOS does not modify the BIOS interrupt vectors. This makes it possible to switch to any of 4 bootable partitions on the hard disk without any fuss. This is great for testing new versions of ChaOS. I usually have the main development partition, a stable backup partition and two test partitions on my ChaOS hard disk.
Furthermore the ChaOS partition table executable code preserves the passed-in value for the BIOS drive identifier and passes this to the boot sector code. (MSDOS boot hard-codes this value to 0x80, which means MSDOS will only boot from the first hard disk). The bootstrap can be re-entered with a new value in register dl to boot from a different hard drive. This is far quicker than entering the BIOS setup program to change the boot device. ChaOS IDE drive names are Linux-like, so after booting from drive hda (IDE1-Master), ChaOS can switch to hdb (IDE-Slave) using the command boot hdb.
This small project (bs) contains all the components of the ChaOS bootstrap, i.e. partition table executable code, boot sector executable code, and the operating system loader itself. Great care need to be taken when modifying a bootstrap,small changes can easily cause a system to be unbootable. I have found the best way to control the bootstrap is by keeping these critical components in one source file.
There are also some test functions left over from development work - real-mode selectors can be loaded with 4Gb segment limits to access memory above 1Mb without switching to protected mode - but this does not work on all my computers so this public version of the bootstrap uses BIOS interrupt 0x15 function 0x87 to move the operating system image into extended memory (which means the ChaOS kernel is loaded within the first 16Mb memory boundary).
The bootstrap makes heavy use of custom features of the ChaOS compiler written specifically to simplify the bootstrap code, particularly the generation of 32-bit Intel instruction prefixes in 16-bit code segments, forcing the processor to use 32-bit arithmetic most of the time.
The compiled bootstrap is about 12kbytes in size, and is embedded in ChaOS as an #includebin. When creating bootable disks, the ChaOS sys command extracts the relevant portions of the bootstrap, modifies data fields as necessary and writes the boot sector and loader portions to disk in the correct places. The loader is written to the file LOADER.BIN. The ChaOS partition command extracts the partition table executable code from the #includebin data when required to create a ChaOS Master Boot Record (MBR).
First in bs.html is the source code to the partition table, followed by the source code to the boot sector, then the source code to the loader.
BIOS loads the boot sector (or partition table sector) to location 0x0000:0x7c00 and then passes control to the executable code within that sector, which in turn relocates the partition table sector to 0x0000:0500. The partition table executable supports multibooting, with a default partition and timeout for automatic booting, or any of the other partitions, if bootable, selectable by a keypress. The boot sector for the chosen partition is then loaded, and relocated to 0x0000:0x0700. Finally the boot sector loader LOADER.BIN to 0x0000:0x0900 and transfers control to the loader itself.
The partition table and boot sector are written in assembly language, whilst the bootstrap is mainly C language. Instead of struggling with 16-bit registers, the ChaOS compiler generates 80x86 overrides to force 32-bit register usage even though the processor is running in 16-bit mode at this point. This is mainly invoked by #pragma rmode16.
The bootstrap looks first for a directory branch in the boot drive root directory called CHAOS.DIR (more on this below). Then it looks for a file called CHAOS in the root directory. If found, the first sector of the file is loaded (this is the .XEC file header) to prime the bootstrap for loading the operating system image in the rest of the file. A few idiot checks are performed to reject corrupt data before loading the image to a memory address chosen by the programmer, switching to 32-bit protected mode, and jumping to the operating system code start address.
In this way, after booting ChaOS, none of the boot trail is overwritten and can be examined to debug the boot process itself. Also, the bootstrap components reside in memory in the same relative positions as their source code file locations.
If the CHAOS.DIR directory is found, the bootstrap displays up to ten operating system images in that directory,available to boot from this partition. In this way ChaOS can hold up to 40 user-selectable boot images on a hard disk. Great Fun!
Booting from Memory Sticks
Most Memory Sticks, when attached to a PC, emulate an IDE/ATA interface with a hard disk attached on the Master channel. Also, modern PC BIOS allows memory stick slots to be selected as a boot device for the PC. So once the ChaOS bootstrap and OS image is written to a memory stick, that can be used to boot ChaOS on the target PC.
I use PCMCIA adapters to write ChaOS to CF and SmartMedia cards, and have a working USB memory stick too.