Could not start the MySQL service on Local Computer.
Error 1067: The process terminated unexpectedly.

First I checked the my.ini file and saw no obvious problems (it was also the default my.ini file produced by the installer). Since the service wouldn’t start, I created a new one that made sure it was reading the right .ini file:

mysqld --install MySql2 --defaults-file="c:\my.ini"

… but to no avail, as the same error occurred. Eventually I gave up and reinstalled MySQL. But it still didn’t work! I did learn two interesting things:

• When trying to delete a service from Windows, make sure that the Services Manager is not open. The deleted service only gets truly deleted when the Services Manager is closed, which may leave you wondering why it’s taking so long (“This service is marked for deletion”).
• When you need to reinstall MySQL, in order to really start fresh, you need to do three things:
  1. Uninstall MySQL (Add/remove programs, etc.)
  2. Delete the MySQL program directory
  3. Delete the MySQL data directory (under Documents and Settings, Application Data, etc.)

When I did a truly “fresh” install of MySQL, it actually worked again. But only till the next reboot. I found out when there was a power outage later during the day. MySQL wouldn’t start, and manually starting the service would produce, again, the error 1067.

This time I had a look at the MySQL log file, which lives in the data directory (called server001.err in my case). I found this:

120420  8:21:38  InnoDB: Operating system error number 87 in a file operation.
InnoDB: Some operating system error numbers are described at
InnoDB: http://dev.mysql.com/doc/refman/5.5/en/operating-system-error-codes.html
InnoDB: File name .\ib_logfile0
InnoDB: File operation call: 'aio read'.
InnoDB: Cannot continue operation.

Ah, more information on the error. It turns out that Windows error 87 is ERROR_INVALID_PARAMETER; in other words: “The parameter is incorrect” (see here). Not particularly helpful, but it gets you something to Google for.

There weren’t too many Google results, but after I while I found this. It seems that the error is related to either the disk driver or the formatting of the disk (neither of which I could easily change on a remote server). But the bug report did include a workaround. Add this to my.ini:

innodb_flush_method=normal

And it works!

In our endeavor to write a boot loader for a toy operating system, we’ve come far already. Our boot loader does the following so far:

• Setup data segments
• Reset the drive system
• Write a “loading” message
• Find the kernel file on disk, using parameters found in the boot sector
• Read the FAT table into memory
• Read the kernel file into memory, using the FAT table
• Reboot gracefully if the file could not be found or if reading fails

We are now in a position to put all the code fragments together and compile our boot loader. We’ll also add some initial code to our kernel, so that it can say “Hello”.

Putting the code together

The bits of code we’ve written so far actually come in two flavors: code that’s used only once and code that’s called various times. The code that’s called in multiple places should be implemented as functions; the rest will be macros. We use macros (a feature of the GNU assembler) merely to be able to give a name to a body of code so our source does not become unreadable.

The functions and macros will reside in their own files. This is because even with what we’ve done so far, the boot process isn’t quite complete yet. We’ll still have to write code that puts the processor in protected mode, sets up protected mode descriptor tables, and starts the kernel (we’ll get to all that later). Since we only have a few bytes left in our boot sector (as you’ll see after compiling), we’ll have to put this code somewhere else: in a “second stage boot loader”. The upshot of this is that while our boot sector code is limited to only one segment of 512 bytes, our second stage boot loader can occupy many sectors.

The second stage boot loader will again need to read the root directory and the FAT table in order to be able to find and read a file. With our functions and macros placed in separate files, we’ll be able to use all that code again easily.

Therefore, the code will be divided into files like this:

• boot.s – Primary boot loader
• 2ndstage.s – Second stage boot loader
• bootsector.s – Macro for the actual boot sector data
• macros.s – Reusable macros
• functions.s – Reusable functions

You can download the source code so far here.

Since we now have to compile each file separately, we’ll tie the build process together with a makefile.

Makefiles

In order to compile our five files, and turn them into a disk image we can test with Bochs, we need quite a few instructions:

as -o boot.o boot.s
ld -o boot.out boot.o -Ttext 0x7c00
objcopy -O binary -j .text boot.out boot.bin
as -o 2ndstage.o 2ndstage.s
ld -o 2ndstage.out 2ndstage.o -Ttext 0x0
objcopy -O binary -j .text 2ndstage.out 2ndstage.bin
imagefs c test.img 720
imagefs b test.img boot.bin
imagefs a test.img 2ndstage.bin

Instead of typing all this at the command prompt each time you test, you’d be better off placing the instructions in a batch file. Better yet, the GNU toolchain comes with a solution: makefiles. Imagine your code growing, so that you have many subdirectories with many files that need to be compiled. You’ll write many batchfiles with similar instructions. Also, you have no way of cleaning up intermediary files. And worst of all, you’ll always compile everything, including files that haven’t changed, which might get slow if you have a lot of code.

With makefiles, its gets easier. GNU make determines automatically which files have changed, and compiles only those files.

Here is a makefile for our boot loader code:

AS  := as
LD  := ld
 
all: boot.bin 2ndstage.bin
 
boot.bin: boot.out
objcopy -O binary -j .text boot.out boot.bin
 
boot.out: boot.o
$(LD) -o boot.out boot.o -Ttext 0x7c00
 
boot.o: boot.s bootsector.s functions.s macros.s
$(AS) -o boot.o boot.s
 
2ndstage.bin: 2ndstage.out
objcopy -O binary -j .text 2ndstage.out 2ndstage.bin
 
2ndstage.out: 2ndstage.o
$(LD) -o 2ndstage.out 2ndstage.o -Ttext 0x0
 
2ndstage.o: 2ndstage.s bootsector.s functions.s macros.s
$(AS) -o 2ndstage.o 2ndstage.s
 
clean:
del *.o
del *.out
del *.bin

Note, for instance, the lines:

boot.o: boot.s bootsector.s functions.s macros.s
$(AS) -o boot.o boot.s

This instructions tells make that the boot.o object file depends on the files boot.s, bootsector.s, functions.s and macros.s. If any of these files change, then boot.o must be recompiled. In short, makefiles allow you to describe dependencies.

In order to build your code, you can now do:

mingw32-make

And to clean everything up except the source code, do:

mingw32-make clean

The second-stage boot loader

We can now write a first version of our second-stage boot loader, just to prove that our concept works. We’ll write one that simply writes “Hello” to the screen, then hangs.

.code16
.intel_syntax noprefix
.text
.org 0x0
.include "macros.s"
 
.global main
main:
  mWriteString msg
hang:
  jmp hang
 
# Booting has failed because of a disk error.
# Inform the user and reboot.
bootFailure:
  mWriteString diskerror
  mReboot
 
.include "functions.s"
 
msg:          .asciz "Hello!\r\n"
rebootmsg:    .asciz "Press any key to reboot.\r\n"
diskerror:    .asciz "Disk error. "
 
.include "bootsector.s"
 
.fill 1024, 1, 1  # Pad 1K with 1-bytes to test file larger than 1 sector

You’ll note several things here. We’ve included the files functions.s and macros.s which were originally written for the primary boot loader. We’ll need them later when we load our kernel file. Also, we need the mWriteString macro in order to write text to the screen. The bootFailure section is also present, along with the messages it prints. We’ll also need this later, but right now we must include it since the code in functions.s and macros.s requires it. Since we’re not actually calling much of the code in macros.s, the resulting binary file for the second stage boot loader will be quite small.

Also, I’ve added 1024 bytes with a value of 1 to the end of the file, just to give it a size of over two sectors. This will allow us to see that our primary boot loader does in fact use the FAT table correctly to load a 3-sector file into memory.

Debugging the code

All right, now that we’ve put it all together (don’t forget to download the final code here) we can compile and run it. If you like, you can use the makefile above to do this, or you can do it manually. Next, create a disk image from it. (You could add the required instructions to the makefile as an exercise.)

The resulting disk image can now be run in Bochs as we’ve seen before. However, can and will go wrong and this is as good a time as any to get acquainted with Bochs’s built-in debugger, which will become your friend soon. Bochs actually comes with two main executables: bochs.exe and bochsdbg.exe, the latter being the debugger. You can start it directly, or you can use configuration files. The latter will be easier for reuse of your configuration.

In order to create a configuration file, load up Bochs (doesn’t matter which executable you start) and use the configuration window to setup your test system (also see part 3 of this guide for a refresher). When you’re all done, do not start the emulator, but save your configuration to file:

This will create a file called bochsrc.bxrc on your disk which contains your configuration settings. Close the configuration window now with the Quit button. In order to start the emulator, you can now right-click on the bochsrc.bxrc file and select Debugger:

Of course, you can also select Run to run in normal, non-debug mode. When debugging, Bochs stops execution of the emulator at the very beginning: inside the POST (Power-On Self Test) code. You can use the debugger to step through this code, if you like, and follow exactly what is does. Eventually your boot sector will be loaded and you can step through that code, as well:

With every step, you can study the value of the processor’s registers and the contents of the physical memory, which will be solid gold when you run into trouble. Of course, it’s pain in the neck so have to step through all the BIOS code every time you run the emulator. What we really need are breakpoints. You can either use the debugger itself to place breakpoints by double-clicking an assembly instruction, but that would require scrolling through lots of code, and some of your code hasn’t even been loaded yet! It’s easier to actually add a breakpoint instruction to your source code.

Magic Breakpoints

Bochs supports a concept called magic breakpoints. The Intel IA-32 processor has an instruction that no-one uses since it does nothing (no, it’s not NOP). The instruction is:

xchg bx, bx

This simply exchanges with contents of the bx register with itself. Bochs assumes you’ll never use this instruction in your code, so when the debugger encounters it, it stops execution: a breakpoint. Sprinkle some of these instructions through your code and you can just use the “Continue” option in the Bochs debugger to move from one breakpoint to the next. Finally, you can debug properly!

Note that you may need to enable magic breakpoints in the Bochs configuration.

Summary

In this section, we’ve put all our code together and compiled it (here is the source for download). We’ve seen how to use makefiles to make the compilation process easy and repeatable. We’ve also seen how we can use Bochs’s internal debugger to step through our code as it executes, and how to set magic breakpoints. Finally, we’ve added a tentative second-stage boot loader to our toy OS that, for the time being, says “Hello”.

In the next part, we’ll talk about fleshing out our second-stage boot loader with switching the processor to protected mode, and launching our kernel. Stay tuned!

In the previous parts of this guide, we wrote assembly code for a simple boot sector and set up the GNU toolchain we use for compiling it and writing it to a floppy disk image. We then used the Bochs IA-32 emulator to boot from that image and see it run.

Our current boot loader resets the drive system, writes a “loading” messages to the screen, waits for a keypress and reboots. It’s now time to make it do what it’s supposed to do: find our kernel file on the disk, so it can be loaded into memory and run.

Reading from disk

Before we get into how to find a file, we need to get some basics sorted first: we need some way to actually read data from our disk. Reading from a disk is done through calling BIOS interrupts (built-in functions that come with the BIOS of any computer). We’ll require interrupt 0×13, subfunction 2. Its arguments are these:

Interrupt 0×13 – 2: Read sectors

The interrupt tries to read one or more sectors from disk, and sets the carry flag if it fails. Failures are common, and read operations should always be tried several times before giving up.

Logical Block Addressing (LBA)

Did you notice the track and head parameters? So far we’ve been talking about sectors only. In facts, we’ve assumed that a disk is simply a long sequential list of sectors. That would be nice, but reality is not nice in this case. We’ve been thinking in terms of what is known as Logical Block Addressing (LBA), while actual disks work differently. Disks can actually have multiple sides that are read by multiple reading heads. Also, sectors are grouped in tracks or cylinders (like on a vinyl record) which further complicates matters. However, the math required to convert an LBA number to a head, cylinder and sector combination is this:

Sector   = (LBA mod SectorsPerTrack) + 1
Cylinder = (LBA / SectorsPerTrack) / NumHeads
Head     = (LBA / SectorsPerTrack) mod NumHeads

What we need to do, then, is write a function that converts an LBA number into these low-level values, reads a sector, and gives it back. That way, the rest of our code can focus on thinking in terms of logical block addresses which avoids headaches.

Read sector code

Here is the code that reads a logical sector from disk:

# Read sector with logical address (LBA) AX into data
# buffer at ES:BX. This function uses interrupt 13h, subfunction ah=2.
.func ReadSector
ReadSector:
  xor     cx, cx                      # Set try count = 0
 
 readsect:
  push    ax                          # Store logical block
  push    cx                          # Store try number
  push    bx                          # Store data buffer offset
 
  # Calculate cylinder, head and sector:
  # Cylinder = (LBA / SectorsPerTrack) / NumHeads
  # Sector   = (LBA mod SectorsPerTrack) + 1
  # Head     = (LBA / SectorsPerTrack) mod NumHeads
 
  mov     bx, iTrackSect              # Get sectors per track
  xor     dx, dx
  div     bx                          # Divide (dx:ax/bx to ax,dx)
                                      # Quotient (ax) =  LBA / SectorsPerTrack
                                      # Remainder (dx) = LBA mod SectorsPerTrack
  inc     dx                          # Add 1 to remainder, since sector
  mov     cl, dl                      # Store result in cl for int 13h call.
 
  mov     bx, iHeadCnt                # Get number of heads
  xor     dx, dx
  div     bx                          # Divide (dx:ax/bx to ax,dx)
                                      # Quotient (ax) = Cylinder
                                      # Remainder (dx) = head
  mov     ch, al                      # ch = cylinder                      
  xchg    dl, dh                      # dh = head number
 
  # Call interrupt 0x13, subfunction 2 to actually
  # read the sector.
  # al = number of sectors
  # ah = subfunction 2
  # cx = sector number
  # dh = head number
  # dl = drive number
  # es:bx = data buffer
  # If it fails, the carry flag will be set.
  mov     ax, 0x0201                  # Subfunction 2, read 1 sector
  mov     dl, iBootDrive              # from this drive
  pop     bx                          # Restore data buffer offset.
  int     0x13
  jc      readfail
 
  # On success, return to caller.
  pop     cx                          # Discard try number
  pop     ax                          # Get logical block from stack
  ret
 
  # The read has failed.
  # We will retry four times total, then jump to boot failure.
 readfail:   
  pop     cx                          # Get try number             
  inc     cx                          # Next try
  cmp     cx, word ptr 4              # Stop at 4 tries
  je      bootFailure
 
  # Reset the disk system:
  xor     ax, ax
  int     0x13
 
  # Get logical block from stack and retry.
  pop     ax
  jmp     readsect
.endfunc

This code will attempt to read the sector with LBA specified in AX up to four times before giving up and jumping to bootFailure. After each failed read attempt, the disk system is reset. Most of the code focuses on doing the divisions required to get the values needed by the interrupt call. If all goes well, the sector’s 512 bytes are placed in ES:BX.

As a side note, we’re actually lucky to have interrupt 0×13 at this stage. Once we’ve put our processor in protected mode, we won’t have access to the BIOS anymore (all its code only runs in 16-bit real mode) and we’ll have to access the disk drive ourselves which is very tricky.

Introduction to FAT

There are many file systems in use these days (NTFS, ext, BFS, UFS, etc.) and we need to pick one to use for our bootable disk. FAT (“File Allocation Table”) is not the most advanced system available, but it’s simple, and on Windows we have the tools for format a disk with it. Plus, rawrite and ImageFS understand it. At a later stage in the development of a toy OS, you can implement support for bags of other file systems if you want.

There is no actual requirement to use any file system. A (floppy) disk is just a bag of bytes, grouped in sectors, clusters and tracks (we’ll get to that), that you can read from and write to. The BIOS expects the first sector of a bootable to disk to be a boot sector, but that’s the only requirement. However, at some point we’ll want to store files and it’s a good idea to pick a file system now, so FAT it is.

FAT comes in different flavors. There’s FAT12, FAT16 and FAT32. The difference is in the size of the disk supported. For FAT12, references to sectors on disk can be up to 12 bits (a maximum value of 4,096 sectors), while with FAT32 we can point to 4,294,967,296 sectors. Since we’re working with floppy disks, FAT12 is enough. The discussion below applies to all FAT versions.

The basic structure of a 720 KB floppy disk formatted with FAT is this:

A 720 KB floppy disk contains 1440 512-byte sectors, some of which are reserved as shown. The remaining 1,407 sectors contain the data of our files.

The boot sector

Here is a quick refresher of the layout of the boot sector (see also part 1 of this guide).

I’ve filled this table with the values you would typically get for a 720 KB floppy disk formatted with FAT. The values in the boot sector are used to determine where exactly on the disk the FAT tables and the root directory live.

The root directory

In order to find a file on the disk, we need to start by looking at the root directory. This is a list of up to 224 entries (according to the boot sector) of 32 bytes each. Each entry contains data about a file:

So the root directory is a list of files on disk. In order to find our kernel file, all we need to do is read it and look for the kernel filename (“KERNEL.BIN” would be good). The directory entry then tells us in which cluster the file resides.

Finding a file on disk

The original boot sector code for DOS and Windows 95 required that the OS kernel file (IO.SYS) be the first file in the root directory of the boot disk. This allowed the programmer to write less code: he did not have to scan the disk’s root directory looking for the file but could simply assume that the file would reside at a fixed position. We can do better, though, by actually scanning the root directory to find our file – and you will see that it’s still possible to squeeze all required code in the 448 bytes that we’re allowed to use.

• In order to find a file, we need to take the following steps:
• Prepare a memory area to load sectors of the root directory into (one sector at a time will do)
• Calculate the size of the root directory in sectors
• Figure out where the root directory starts on disk (see above)
• For each sector:
  • Read the sector into memory
  • Scan it to see if it contains the filename we’re looking for
  • If found, calculate its starting sector and file size
• If not found, the boot process fails

Root directory size

The size of the root directory in sectors is the number of entries it contains, times 32 bytes:

# The number of sectors that the root directory occupies
# is equal to its max number of entries, times 32 bytes per
# entry, divided by sector size.
# E.g. (32 * rootsize) / 512
# This normally yields 14 sectors on a FAT12 disk.
# We calculate this total, then store it in cx for later use in a loop.
mov     ax, 32
xor     dx, dx
mul     word ptr iRootSize
div     word ptr iSectSize          # Divide (dx:ax,sectsize) to (ax,dx)
mov     cx, ax
mov     root_scts, cx
# root_scts is now the number of sectors in the root directory.

Root directory start

To get started, we’ll first need to know where the root directory begins. The information we need is in the boot sector, where the following values are important:

• Number of FAT tables (2)
• Number of sectors per FAT (9)
• Number of reserved sectors (1)
• Number of hidden sectors (0)

The root directory comes after and reserved or hidden sectors and the file allocation table (FAT). The starting cluster of the root directory is therefore:

root_sector = (FAT tables) * (#sectors per FAT)
            + (reserved sectors)
            + (hidden sectors)

The one reserved sector is of, course, the boot sector. There are no hidden sectors on our disk.

# Calculate start sector root directory:
# root_strt = number of FAT tables * sectors per FAT
#           + number of hidden sectors
#           + number of reserved sectors
xor   ax, ax                      # find the root directory
mov   al, byte ptr iFatCnt        # ax = number of FAT tables
mov   bx, word ptr iFatSize       # bx = sectors per FAT
mul   bx                          # ax = #FATS * sectors per FAT
add   ax, word ptr iHiddenSect    # Add hidden sectors to ax
adc   ax, word ptr iHiddenSect+2
add   ax, word ptr iResSect       # Add reserved sectors to ax
mov   root_strt, ax
# root_strt is now the number of the first root sector

Reading and scanning each sector

We can now use the ReadSector function we developed earlier to read the sectors into memory, one by one. For each sector, we then loop through the entries and check each filename (the first 11 bytes of the directory entry) for a match:

# Load a sector from the root directory.
# If sector reading fails, a reboot will occur.
read_next_sector:
push   cx
push   ax
xor    bx, bx
call   ReadSector
 
check_entry:
mov    cx, 11                      # Directory entries filenames are 11 bytes.
mov    di, bx                      # es:di = Directory entry address
lea    si, \filename               # ds:si = Address of filename we are looking for.
repz   cmpsb                       # Compare filename to memory.
je     found_file                  # If found, jump away.
add    bx, word ptr 32             # Move to next entry. Entries are 32 bytes.
cmp    bx, word ptr iSectSize      # Have we moved out of the sector yet?
jne    check_entry                 # If not, try next directory entry.
 
pop    ax
inc    ax                          # check next sector when we loop again
pop    cx
loopnz read_next_sector            # loop until either found or not
jmp    bootFailure                 # could not find file: abort

Getting the file start position

Now that we have found the root directory entry for the kernel file, we need to get from it the position of the file (the cluster number) :

  found_file:
    # The directory entry stores the first cluster number of the file
    # at byte 26 (0x1a). BX is still pointing to the address of the start
    # of the directory entry, so we will go from there.
    # Read cluster number from memory:
    mov    ax, es:[bx+0x1a]
    mov    file_strt, ax

The end result is that file_strt contains the file’s starting cluster number.

FAT Clusters

All right, after all this digging through the disk’s root directory, we’ve found our file and we’ve got a cluster number in hand. However, so far we’ve only talked about sectors, not clusters (you can safely ignore the cylinder, track and head story from here on – they have nothing to do with it). A cluster is another logical structure introduced by FAT.

The idea is that in FAT, a file may occupy a number of sectors. And most files certainly will, because one sector is only 512 bytes. Files on disk will often be much larger than that! So imagine that we have a disk with two of files on it. They’re both 3 sectors in size, and they were physically written to the disk so as to occupy precisely the first 6 sectors of the data area. Now, the first file is deleted. That means we now have 3 empty sectors at the start of the data area. Next, a new file, 4 sectors in size, is copied onto the disk. Where does it go? There’s no space to put new file before the remaining existing file, since there’s only space for 3 sectors. We can only place the new file after the existing file. Maybe at some point a user will want to write a 3-sector file that can fill the gap!

Naturally, if you consider writing and deleting lots of files on a disk, this will leave the file system fragmented and with lots of gaps that we can’t use. And this is where FAT comes in. With FAT, a file that occupies multiple sectors on disk may be broken up into non-contiguous sectors. So a 3-sector file could occupy physical sectors 40, 21 and 304. The bits and pieces can go wherever there is space and all available space is used to the fullest.

The problem then is administration. How does FAT know where the loose pieces of each file are? For this, the FAT system uses its namesake, the File Allocation Table. This table lives right before the root directory and contains an index of all the sectors on the disk. There are actually two copies of the FAT on every disk: one is a backup, for safety. You’ll see that the bootsector actually contains a field with the number of FAT tables on the disk.

The FAT table is actually an index of linked lists of sectors (hello?). An example illustrates how this works. Imagine we have a disk with 10 data sectors on it (we’re ignoring the sectors occupied by boot sector, root directory, FAT etc., and the fact that 10 sectors is a really small disk):

There are actually three files on this disk. From the root directory we get:

• File 1 – cluster index = 0
• File 2 – cluster index = 2
• File 3 – cluster index = 3

The directory entry for file 1 points to cluster index 0. In the FAT table, the value for this index is 0×001: it points to index 1. Index 1′s value is 0×004: it points to index 4. Index 4′s value is 0×006: is points to index 6. Index 6′s value, finally, is 0xff8, a special value which means that it is the last index of the file.

What this all means is that file 1 occupies sectors 0, 1, 4 and 6. Actually, sector 0 is actually the sector after the root directory on the disk, but that’s a detail.

For file 2 we can now determine that it occupies only one sector (sector 2). The FAT-value for this index is 0xFf8, so there are no more sectors.

For file 3, we see that it occupies sectors 3 and 7. You’ll get the idea by now.

• Some of the FAT indices have the value 0. That means that the sector is free.
• Any value of 0xff8 or higher means end-of-file
• A value of 0xff7 means the sector is bad and should not be used.

A cluster, therefore, is a linked list where each entry points to the next, until the end of the cluster. Each entry relates to an actual physical sector on disk. When reading a file, we’ll have to follow its FAT cluster and read each corresponding sector into memory.

It sounds simple enough, after all, but there’s a catch: the FAT entries occupy 12 bits each (a byte and a half), which will make reading and using the data bit tricky later. You will now see that since each the FAT consists of 9 sectors, it can address 9*512/1.5 = 3072 sectors, which is more than enough, since our disk has 1440 sectors.

Reading the FAT

The FAT lives on the disk, and in order to access it, we’ll have to get it in memory first. The following code does just that: it loads the FAT into a memory segment (I use segment 0x0ee0, so as to place it just under where I’ll be loading the next file):

# The FAT will be loaded in a special segment.
# Set ES to this segment.
mov   ax, \fatsegment
mov   es, ax
 
# Calculate offset of FAT:
mov   ax, word ptr iResSect       # Add reserved sectors to ax
add   ax, word ptr iHiddenSect    # Add hidden sectors to ax
adc   ax, word ptr iHiddenSect+2
 
# Read all FAT sectors into memory:
mov   cx, word ptr iFatSize       # Number of sectors in FAT
xor   bx, bx                      # Memory offset to read into (es:bx)
read_next_fat_sector:
push  cx
push  ax
call  ReadSector
pop   ax
pop   cx
inc   ax
add   bx, word ptr iSectSize
loopnz read_next_fat_sector       # continue with next sector

After this code has executed, all 9 sectors of the FAT now live in memory at 0ee0:0000.

Reading a file

With out FAT in memory, we are not ready to read a file from disk. By scanning the root directory we had earlier determined the starting index in the FAT table, so we’re good to go:

# Set memory segment that will receive the file:
mov     ax, \loadsegment
mov     es, ax
# Set memory offset for loading to 0.
xor     bx, bx
 
# Set memory segment for FAT:
mov     cx, file_strt             # CX now points to file's first FAT entry
 
read_file_next_sector:
# Locate sector:
mov     ax, cx                    # Sector to read is equal to current FAT entry
add     ax, root_strt             # Plus the start of the root directory
add     ax, root_scts             # Plus the size of the root directory
sub     ax, 2                     # ... but minus 2
 
# Read sector:
push    cx                        # Read a sector from disk, but save CX
call    ReadSector                # as it contains our FAT entry
pop     cx
add     bx, iSectSize             # Move memory pointer to next section
 
# Get next sector from FAT:
push    ds                        # Make DS:SI point to FAT table
mov     dx, \fatsegment           # in memory.
mov     ds, dx
 
mov     si, cx                    # Make SI point to the current FAT entry
mov     dx, cx                    # (offset is entry value * 1.5 bytes)
shr     dx
add     si, dx
 
mov     dx, ds:[si]               # Read the FAT entry from memory
test    dx, 1                     # See which way to shift
jz      read_next_file_even
and     dx, 0x0fff
jmp     read_next_file_cluster_done
read_next_file_even:
shr     dx, 4
read_next_file_cluster_done:
pop     ds                        # Restore DS to the normal data segment
mov     cx, dx                    # Store the new FAT entry in CX
cmp     cx, 0xff8                 # If the FAT entry is greater or equal
jl      read_file_next_sector     # to 0xff8, then we've reached end-of-file

What happens here is that we start with cx = first sector of file (we know this from the root directory after all). We read that sector into memory, then use the cx value to access the corresponding index in the FAT. There’s a bit of trickiness where we juggle with the 12-bits issue, but then all that remains is whether to continue reading, or stop because end-of-file (FAT-entry 0xff8 or higher) was reached.

Summary

From a bare-bones boot loader, we’ve now come to a point where we can load the kernel (or rather the second-stage boot loader – this will become clear later on)! We’ve seen how the root directory and FAT work, and neatly read both to load the required file from disk. Since we squeezed all this functionality in, the file we’re loading can actually live anywhere in the root of the disk. Gone is the requirement for SYS.COM that DOS and Windows imposed. In our future OS, making a disk bootable should not require a formatting operation. Writing a boot sector and simply coping the OS files onto the disk will suffice.

So far I’ve shown here some sections of code that still need to be sewn together. In the next part of this guide, we’ll add a small kernel (something along the lines of “hello world”) to be loaded and executed. We’ll then have a complete source that can be compiled and run on Bochs (or from a floppy disk if you’re hardcore).

Continue to part 5!

In part 2 of this guide to writing your own toy operating system, we set it to write our own (floppy) disk boot sector in assembly code. We ended up with a piece of code that writes a message to the screen, initializes the drive system, waits for a key press, and reboots. Before we move in, let’s create a development environment: a toolset that we can use to compile and test our code repeatedly (and when fiddling with low-level assembly code, you’ll find that “repeatedly” is the operative word here).

Our code so far was written in for the GNU assembler, as, although we use the Intel syntax (which GNU supports) as this is easier on the eyes for most people (I like the GNU syntax, but if you’ve never used it, you’ll find that it requires looking at everything upside down). The GNU assembler is free, and any other tools we’ll use will also be free.

We’ll also use Windows as our development platform, which we’ll require some extra work to set things up.

Assembling & linking

Assembling code turns that code into an object file. An object file contains machine code that the processor can execute. But before that, the object file must be linked into an executable. This is because programs in assembly code (or any other language) more often than not consist of many source files, which must be combined into one executable. The tool responsible for putting it all together is called a linker. It joins up all the code, and makes sure that all the references in that code (jumps, variables, memory references) actually point to the correct spot. It does all the math required to turn all references into numbers, so you don’t have to (a very good thing).

So: the next tool we’ll be using is the GNU linker, ld.

Getting the GNU toolchain: MinGW

The GNU assembler and the GNU linker are ideal tools for our purposes, but they are not readily available for Windows. You’ll find as and ld on any UNIX/Linux system, but not on Windows. Of course we could decide to use some Windows-based assembler, but these assembler simply don’t have enough switches to fiddle with, so it’s GNU or nothing.

Luckily, we have two options: Cygwin and MinGW. Both are complete GNU toolsets that were compiled for and run on Windows. Cygwin requires that you work in a special shell, while MinGW (“Minimalist GNU for Windows”) can be used directly from the ordinary Windows command line, which is how I like it. (You can still opt for Cygwin, it shouldn’t make any difference). So go and get a copy of MinGW here (or here for direct download) and install it. I’ll wait.

After installing MinGW, don’t forget to set your PATH to include your MinGW’s /bin directory. That way you’ll have access to as, ld and make from your shell.

Compiling the code

Now that we have MinGW, we can open a shell and find our code file (let’s call it boot.s). Here’s how we assemble the code:

as -o boot.o boot.s

This will turn boot.s into boot.o.

Now to link it:

ld -o boot.out boot.o -Ttext 0x7c00
objcopy -O binary -j .text boot.out boot.bin

That’s a mouthful. Here, we use the GNU linker to create a linked intermediary file. Normally, we could tell the linker which output format it should produce, and there are quite a few of those (Windows PE, Linux ELF, flat binary etc.). What we want is for the linker to produce a flat binary: no operating-system specific headers, just the code. And that’s just what we cannot do.

This is where objcopy comes in. It takes the linker output, strips off any headers and leaves us with a flat binary with just the code. It produces, in fact, a file of 532 bytes (on my computer), which is 20 bytes too many. Closer inspection with a hex editor shows that the code is in fact exactly 512 bytes and ld/objcopy added 20 excess bytes that we can ignore. (I have yet to find out why – when I compiled similar code some years ago this did not happen. Also see this post.)

What we have now produced is exactly like a .com file in the olden days of DOS gone by. These files (as opposed to .exe files) also included just the code. You could run one, and DOS would know what to do with it. No such luck now: if you run your file (renaming it to .com or .exe) you’ll get this:

Of course, this is a good thing, because our code would bring Windows down if it were allowed to execute. Also, our code was written for 16-bits real mode, and your Windows computer is in protected mode. Thus, our boot loader can only be tested if we were to actually boot our computer with it, or within some sort of simulator (we can actually do both).

Bochs

There actually exists a simulator that we can use for our purposes. The good people of Bochs (“The Open Source IA-32 Emulation Project”) have produced a program that precisely simulates a computer with an Intel processor, loaded with a BIOS ROM and with support for common I/O devices. Bochs can run old DOS versions by running image files of the old DOS floppy disks, and we can do the same. If we can produce an image file of a floppy disk with our boot sector on it, then we’re good to go!

Now would be a good time to download and install Bochs if you haven’t already done so.

Making a disk image

The final tool we’ll need for now is tool that can help us create a disk image with a custom boot sector. rawrite is such a tool, but it’s not available for Windows (although here is an implementation for Windows, but it doesn’t take command-line argument so it can’t be used in an automated build process). I rolled my own at some point and the result was ImageFS (you can download it here). Its usage is:

Usage:
imagefs [c/create] [image file name] [number of sectors]
imagefs [b/boot]   [image file name] [bootsector file name]
imagefs [a/add]    [image file name] [file] [more files]
imagefs [r/remove] [image file name] [file] [more files]
imagefs [d/dir]    [image file name]

To create a disk image, do this:

imagefs c test.img 720
imagefs b test.img boot.bin

You’ll get:

C:\code\os\boot) imagefs c test.img 720
Create new image file [test.img] with [720] sectors.
Image opened, current size is 0 sectors.
Formatted 720 sectors with fill character ÷.
 
C:\code\os\boot) imagefs b test.img boot.bin
Write boot sector [boot.bin] to image file [test.img].
Image opened, current size is 720 sectors.
Warning: boot sector file (532 bytes) is larger than one sector (512 bytes).
- skipping excess bytes.
Boot sector copied successfully.

This creates an empty floppy disk of 720 KB and stores our boot sector on it.

Running the simulator

Now run Bochs. You’ll get the emulator’s start menu. From it, select “Disk & Boot” before you hit Start. Fill out the following:

In particular, don’t forget to set your boot disk as “inserted“! Now hit Start and watch your code work:

Note that you can access Bochs’s log file to see the boot procedure in more detail, and if it crashes, you can see why.

If you want, you can actually run this code from a real floppy disk on a real computer. For this, you’ll need rawrite to write your boot sector to the disk. After that, you should be able to boot your computer with it (if you actually have a floppy drive).

Summary

We now have the tools in place that we need to develop our boot sector further. The Bochs simulator allows us to test our code. In the next section, we’ll flesh out our boot loader with code that finds and loads our kernel file. Since we’ll be using multiple source files, we’ll also begin using GNU make to automate our build process.

Resources

• MinGW: home page, download
• Cygwin: home page
• Bochs: home page
• ImageFS: direct download

Continue to part 4 of this guide!

Now on an iPad, I know that apps developed for the iPhone can be “zoomed 2x”, thus filling the iPad screen nicely. It would naturally be better to produce a HD version of the app, but at least zooming allows the original app to be readable. This doesn’t happen with Android. Google says it will add a zoom feature in Android 3.2, but since my tablet (and others) uses Android 3.1, it doesn’t solve my problem.

I did however find a way to stretch (not zoom) the app on a tablet. Apparently stretching is only possible from SDK version 7 onwards. Setting the minimum SDK level in your Android manifest to 7 will do the trick:

<uses-sdk android:minSdkVersion="7" />

Now the app stretches on the tablet, at least using all screen real estate available. It’s not pretty, since the controls remain small. Apparently the way to go is creating a Processing app, as explained here.

<Survey>
  <Questions>
    <Question class="SingeLineQuestion">
      <Title>What is your name?</Title>
      <MaxLength>50</MaxLength>
    </Question>
    <Question class="NumericQuestion">
      <Title>How old are you?</Title>
      <Minimum>10</Minimum>
      <Maximum>80</Maximum>
    </Question>
  </Questions>
</Survey>

The survey contains a list of question instances, and upon saving the XML, Simple XML has added an attribute to each question stating what the actual Question class is (e.g. class=”SingleLineQuestion”).

The problem is this: loading a survey into memory actually works perfectly on Android 1.5, but fails on Android 2.1 and higher. It produces a ClassNotFound exception:

java.lang.ClassNotFoundException: SingleLineQuestion
in loader dalvik.system.PathClassLoader@4001b605

What is happening? Studying the source of Simple XML shows that the required SingleLineQuestion question is instantiated using a ClassLoader. This ClassLoader may run in a different thread context than the main code, and therefore it cannot find the required class to load. This may happen when Simple XML gets called through an synchronous request in order to avoid the application from blocking.

In order to make sure that Simple XML has access to the correct class loader, you can do this:

Thread.currentThread().setContextClassLoader(context.class.getClassLoader());
Serializer serializer = new Persister();
...

Fun at the Water Park

The local “Adil” water park shares some goodness:

“We will not tolerate any offense against public morals, ethics and lack of bad behavior on the grounds of the park.”

That’s right. ethics are good, but bad behavior is better.

Resumé gems

Excerpt from a great cover letter (sent to 100+ organizations – To, not BCC):

Waiting for Your Excellency the greatest consideration and care to nurture more professional experience, hereby express their willingness to join in your workgroup.

Naturally closely followed by this, in case there were any lingering doubts:

English: Spoken and written fluently.

Also lifted from a CV:

Curso de Inglês no JEMES INGLiSH SCHOOL ΙΙ nivel;

We’d like to introduse herbly our company

Oh good. What does your company do then?

(Yes, it’s hard to read. The email was sent as an image.) It’s nice to know that the “trainnings” will be offered by world-renowned experts. Somehow I do hope that these industry and academia giants did not write this introduction letter. But fear not, we are in good hands:

That’s a relief, whatever it means. Ah, I see now that this message was brought to me not by the world-renowned experts but rather the company’s sales team:

Thank you! Sales Team! It was certainly “pleasent” to hear from you!

Now that we know the structure of the boot parameter block (BPB) and extended boot parameter block (EBPB), we can start writing our first code. (If you need a refresher, have a look at part 1 of this article).

First code in GNU assembler

We’ll be using the GNU assembler, since it’s free, comes with a boatload of options, supports AT&T and Intel assembly syntax and plays nice with gcc and ld later on. Some of the preprocessor directives used may need some explanation, but all code will be in straightforward Intel syntax.

Here’s some boilerplate code to get started:

.code16
.intel_syntax noprefix
.text
.org 0x0
 
LOAD_SEGMENT = 0x1000
 
.global main
main:
  jmp short start
  nop
 
  # BPB and EBPB here
 
start:
  # rest of code

The pile of preprocessor instructions at the top tell the assembler to assemble code for real mode. Since all (intel-based) computers start up in real mode with 16-bit instructions, we won’t be able to write 32-bit code here yet. We also instruct GNU assembler that we’ll be using Intel syntax (e.g. mov ax, 1 instead of movw $1, %ax – some prefer the latter, but most readers of this text will be familiar with Intel).  The origin of our code will be 0×0, i.e. all absolute addresses start at 0×0, which will be convenient.

Then there’s the main entry point of our code, which corresponds to the first byte of actual output when assembled. The code under “main” simply jumps over the BPB and EBPB located at offset 0×3, resuming execution at the label start. We’ll flesh out the BPB/EBPB in a bit, since it’ll have to have a very exact size.

We’ve also defined a constant LOAD_SEGMENT, which is the segment where we’ll be loading our second stage boot loader (more about that later).

The Boot Parameter Block

The structure of the boot parameter block can be coded like this:

bootsector:
 iOEM:          .ascii "DevOS   "    # OEM String
 iSectSize:     .word  0x200         # bytes per sector
 iClustSize:    .byte  1             # sectors per cluster
 iResSect:      .word  1             # #of reserved sectors
 iFatCnt:       .byte  2             # #of FAT copies
 iRootSize:     .word  224           # size of root directory
 iTotalSect:    .word  2880          # total # of sectors if over 32 MB
 iMedia:        .byte  0xF0          # media Descriptor
 iFatSize:      .word  9             # size of each FAT
 iTrackSect:    .word  9             # sectors per track
 iHeadCnt:      .word  2             # number of read-write heads
 iHiddenSect:   .int   0             # number of hidden sectors
 iSect32:       .int   0             # # sectors for over 32 MB
 iBootDrive:    .byte  0             # holds drive that the boot sector came from
 iReserved:     .byte  0             # reserved, empty
 iBootSign:     .byte  0x29          # extended boot sector signature
 iVolID:        .ascii "seri"        # disk serial
 acVolumeLabel: .ascii "MYVOLUME   " # volume label
 acFSType:      .ascii "FAT16   "    # file system type

The fields in this structure correspond to the specification in part 1 of this text, and since they’re nicely labelled, we’ll be able to refer to them later on.

Real-mode Segments

After the start label, we can write some actual code. Let’s start by defining our real mode data segments:

  cli
  mov  iBootDrive, dl  # save what drive we booted from (should be 0x0)
  mov  ax, cs          # CS = 0x0, since that's where boot sector is (0x07c00)
  mov  ds, ax          # DS = CS = 0x0
  mov  es, ax          # ES = CS = 0x0
  mov  ss, ax          # SS = CS = 0x0
  mov  sp, 0x7C00      # Stack grows down from offset 0x7C00 toward 0x0000.
  sti

Here, we mask interrupts so that interrupt calls don’t mess up our sector declarations. We set ES = DS = SS = CS = 0×0, and make the stack grow down from 0x7C00 (our boot loader was loaded at 0x7C00). When done, we turn the interrupts back on. It’s important to note that the BIOS places the number of the boot drive in the DL register. We store it in our BPB for later use.

Resetting the disk system

Next, we need to prepare the floppy drive for use. This is done through BIOS interrupt 0×13, subfunction 0. We call it with the boot drive in DL:

  mov  dl, iBootDrive   # drive to reset
  xor  ax, ax           # subfunction 0
  int  0x13             # call interrupt 13h
  jc   bootFailure      # display error message if carry set (error)

If the reset fails, the carry flag will be set and we jump to a label where we handle a boot failure by showing a message, waiting for a keypress and rebooting. Come to think of it, we’ll need a way to print a string to the screen.

Printing a string

We’ll add a short function that uses BIOS interrupt 0×10, sub-function 9 to print characters to the screen. The calling code must point DS:SI to the null-terminated string to be printed.

.func WriteString
 WriteString:
  lodsb                   # load byte at ds:si into al (advancing si)
  or     al, al           # test if character is 0 (end)
  jz     WriteString_done # jump to end if 0.
 
  mov    ah, 0xe          # Subfunction 0xe of int 10h (video teletype output).
  mov    bx, 9            # Set bh (page nr) to 0, and bl (attribute) to white (9).
  int    0x10             # call BIOS interrupt.
 
  jmp    WriteString      # Repeat for next character.
 
 WriteString_done:
  retw
.endfunc

We can now define the “bootFailure” label:

diskerror: .asciz "Disk error. "
bootFailure:
  lea si, diskerror
  call WriteString
  call Reboot

Great. We’ve got code to reset the floppy drive, and if it fails, there’s code that prints failure strings and reboots. Although, we still have to write a Reboot function.

Rebooting

Here is some code that prints a “Press any key to reboot” message, waits for a keystroke, and reboots the machine.

rebootmsg: .asciz "Press any key to reboot\r\n"
.func Reboot
 Reboot:
  lea    si, rebootmsg    # Load address of reboot message into si
  call   WriteString      # print the string
  xor    ax, ax           # subfuction 0
  int    0x16             # call bios to wait for key
 
  .byte  0xEA             # machine language to jump to FFFF:0000 (reboot)
  .word  0x0000
  .word  0xFFFF
.endfunc

Here, we use BIOS interrupt 0×16, sub-function 0 to read a key (any key). We then add a far jump to 0xffff:0000 we causes the machine to reboot.

Putting it all together

When we combine the functions above into a single source file, we end up with this:

.code16
.intel_syntax noprefix
.text
.org 0x0                                        
 
LOAD_SEGMENT = 0x1000             ; load the boot loader to segment 1000h
 
.global main
 
main:
  jmp short start                 # jump to beginning of code
  nop
 
bootsector:
 iOEM:          .ascii "DevOS   "    # OEM String
 iSectSize:     .word  0x200         # bytes per sector
 iClustSize:    .byte  1             # sectors per cluster
 iResSect:      .word  1             # #of reserved sectors
 iFatCnt:       .byte  2             # #of FAT copies
 iRootSize:     .word  224           # size of root directory
 iTotalSect:    .word  2880          # total # of sectors if over 32 MB
 iMedia:        .byte  0xF0          # media Descriptor
 iFatSize:      .word  9             # size of each FAT
 iTrackSect:    .word  9             # sectors per track
 iHeadCnt:      .word  2             # number of read-write heads
 iHiddenSect:   .int   0             # number of hidden sectors
 iSect32:       .int   0             # # sectors for over 32 MB
 iBootDrive:    .byte  0             # holds drive that the boot sector came from
 iReserved:     .byte  0             # reserved, empty
 iBootSign:     .byte  0x29          # extended boot sector signature
 iVolID:        .ascii "seri"        # disk serial
 acVolumeLabel: .ascii "MYVOLUME   " # volume label
 acFSType:      .ascii "FAT16   "    # file system type
 
.func WriteString
WriteString:
  lodsb                   # load byte at ds:si into al (advancing si)
  or     al, al           # test if character is 0 (end)
  jz     WriteString_done # jump to end if 0.
 
  mov    ah, 0xe          # Subfunction 0xe of int 10h (video teletype output)
  mov    bx, 9            # Set bh (page nr) to 0, and bl (attribute) to white (9)
  int    0x10             # call BIOS interrupt.
 
  jmp    WriteString      # Repeat for next character.
 
WriteString_done:
  retw
.endfunc
 
.func Reboot
 Reboot:
  lea    si, rebootmsg # Load address of reboot message into si
  call   WriteString   # print the string
  xor    ax, ax        # subfuction 0
  int    0x16          # call bios to wait for key
  .byte  0xEA          # machine language to jump to FFFF:0000 (reboot)
  .word  0x0000
  .word  0xFFFF
.endfunc
 
start:
  # Setup segments:
  cli
  mov  iBootDrive, dl  # save what drive we booted from (should be 0x0)
  mov  ax, cs          # CS = 0x0, since that's where boot sector is (0x07c00)
  mov  ds, ax          # DS = CS = 0x0
  mov  es, ax          # ES = CS = 0x0
  mov  ss, ax          # SS = CS = 0x0
  mov  sp, 0x7C00      # Stack grows down from offset 0x7C00 toward 0x0000.
  sti  
 
  # Display "loading" message:
  lea  si, loadmsg
  call WriteString
 
  # Reset disk system.
  # Jump to bootFailure on error.
  mov  dl, iBootDrive  # drive to reset
  xor  ax, ax          # subfunction 0
  int  0x13            # call interrupt 13h
  jc   bootFailure     # display error message if carry set (error)  
 
  # End of loader, for now. Reboot.
  call Reboot
 
bootFailure:
  lea  si, diskerror
  call WriteString
  call Reboot
 
# PROGRAM DATA
loadmsg:          .asciz "Loading OS...\r\n"
diskerror:        .asciz "Disk error. "
rebootmsg:        .asciz "Press any key to reboot.\r\n"
 
.fill (510-(.-main)), 1, 0  # Pad with nulls up to 510 bytes (excl. boot magic)
BootMagic:  .int 0xAA55     # magic word for BIOS

Points of note

• The WriteString and Reboot sections are functions, that we’ll want to call various times in the other boot code that we’ll write soon. They are not part of the main body of code. That is why they are placed before the start label, so that execution will jump over them.
• The loader will not print a “Loading OS…” message right after it sets the segments.
• After having reset the disk system successfully, the loader will reboot. We’re doing that only because we haven’t written any more code yet that does interesting things.
• The source code ends with a .fill preprocessor directive. This causes the assembler to fill up the output file with null bytes all the way to offset 510. The final two bytes contain the magic word required by some BIOSes. Compilation will now yield a file of exactly 512 bytes, which is what we need for our boot sector.

Summary

We’ve written assembler code that prepares data and stack segments and resets the floppy drive. We’ve also added functions for writing text to the screen, waiting for a keypress, and rebooting, which wraps up

I don’t know about you, but I’m just about ready to see this code in action! In the next section, we’ll see how we can actually compile and test this code.

On to section 3!

Note that you can actually start developing other components of your toy operating system before writing boot code, since you can use GRUB (GNU Grand Unified Boot Loader) or LILO to start your kernel. Using one of these tools brings advantages, since they’ll switch the processor to protected mode for you, and allow you to load kernels that are placed beyond cylinder 1024 of a hard disk.

However, writing your own boot code can be a very interesting exercise in assembly programming, and you’ll have full control over what your boot loader actually does. Plus, you get to try and do it better than the people who wrote the DOS/Win95 boot loaders (which isn’t saying a lot as you’ll see below).

Boot loader requirements

The boot code lives in the first sector of a floppy disk, which typically has a size of 512 bytes. However, 61 of those bytes are occupied by data, placed on the disk when it is formatted. This data includes the size of a disk sector, number of FAT tables, number of tracks per sector, volume ID, and more. This yields 451 bytes available for code, which is not a whole lot. That’s one reason we’ll use assembler to write our code.

The DOS/Windows bootloader and its limitations

Let’s consider the boot loader that most of us have used many times: the boot loader that comes with DOS or Windows (up to Windows 95). What does it do?

• Reset the floppy disk system
• Read the first sector of the root directory from the disk
• Verify that the first file found there is IO.SYS (the kernel)
• Load IO.SYS into memory
• Transfer control to IO.SYS

Since the space available for actual code in the boot sector is limited, the author of the DOS boot loader introduced an important requirement: the file IO.SYS must be the first file in the root directory. The DOS code does not scan the entire root directory looking for the required file. If IO.SYS is not the first file found, then the boot code fails.

This is why DOS/Windows comes with the SYS.COM program, which is used to make a disk bootable. This program actually cleans the root directory of a floppy disk and copies IO.SYS into it as the first entry, effectively removing all the other files. It would have been much nicer if it had been possible to copy IO.SYS to the root directory of a disk, at any position. Then any disk could be make bootable without sacrificing the files on it. This can actually be done, but it requires more assembly code, something the DOS developers apparently did not find any space for – but we can do better.

At any rate, modern operating systems will switch the processor to protected mode, which allows us to address up to 4 GB of memory in a flat model (not segmented), and switch on paging to protect processes from one another. This wasn’t part of the DOS/Windows 95 boot loader, but we’ll need to do it.

How a boot loader gets called

When the computer starts up, it executes a power-on self test (POST). It then performs the following actions:

• Determine which device (drive) to use for booting, using preferences stored in the CMOS.
• Try to load the first sector (and only the first sector) from the boot drive into memory at address 0:0x7C00.
• Verify that the the first sector is in fact bootable by checking for the presence of a magic number (see below).
• Store the number of the drive used in register DL.
• Point the CPU’s instruction pointer to 0:0x7C00, and start execution from there.

The computer knows how to do these things, and does them automatically, because the code for this is in its BIOS ROM. In other words, these procedures we get for free with any computer.

What a boot loader should do

Here’s a list of things that a modern boot loader should do in order to load and start your operating system’s kernel (we’ll cover concepts like the A20-line, IDT and GDT tables later):

• Reset the floppy disk system
• Write a “loading” message to the screen
• Find the kernel in the root directory of the disk (at any position)
• Read the kernel from disk into memory
• Enable the A20-line
• Setup the IDT and GDT tables
• Switch to protected mode
• Clear the processor prefetch queue
• Run the kernel

Boot Sector Layout

The boot sector of a floppy disk has a very specific layout, because the BIOS requires access to certain data which it needs to find in the place it expects it to be. Also, an operating system will need to access this data to determine how large the disk is, what file system it uses, what its volume label is and so on. For this article, we’ll assume a floppy disk formatted with a FAT16 file system. The layout of the boot sector is then:

Offset	Size		Contents	Typical value
0000	3	Code	Jump to rest of code
0003	8	BPB	OEM name	Great-OS
0011	2		Bytes per sector	512
0013	1		Number of sectors per cluster	1
0014	2		Number of reserved sectors	1
0016	1		Number of FAT tables	2
0017	2		Number of root directory entries (usually 224)	224
0019	2		Total number of sectors	2880
0021	1		Media descriptor	0xf0
0022	2		Number of sectors per FAT	9
0024	2		Number of sectors/track	9
0026	2		Number of heads	2
0028	2		Number of hidden sectors	0
0030	2	EBPB	Number of hidden sectors (high word)	0
0032	4		Total number of sectors in filesystem
0036	1		Logical drive number	0
0037	1		Reserved
0038	1		Extended signature	0x29
0039	4		Serial number
0043	8		Volume label	MYVOLUME
0054	8		Filesystem type	FAT16
0062	448	Code	Boot code
0510	2	Required	Boot signature	0xaa55

A required element of the boot sector is the boot parameter block (BPB) and the extended boot parameter block (EBPB, for FAT16). This block must be placed at offset 3, size 59 bytes. Also, the boot sector must end with the magic number 0xaa55: (some) BIOSes will check whether this value is present at offset 510. If not, the BIOS will refuse to boot from the disk. All other bytes are available for us to fill in. We can calculate that that adds in fact up to 451 bytes. Also, the first three bytes are separated from the rest and should only be used to jump to the rest of the code, so that’s less 3 bytes for interesting code…

Here is a typical hex dump of a boot sector without any code. Colored in red are the parts in the BPB and EBPB as decribed above, and the magic number at the end. Everything else is available for code:

0x0000 00 00 00 47 72 65 61 74 2d 4f 53 00 02 01 01 00 ...Great-OS.....
0x0010 02 e0 00 40 0b f0 09 00 09 00 02 00 00 00 00 00 .à.@............
0x0020 00 00 00 00 00 00 29 73 65 72 69 00 00 00 00 00 ......)seri.....
0x0030 00 00 00 00 00 00 46 41 54 31 36 20 20 20 fa 88 ......FAT16   ú^
0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0170 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x0190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x01f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa ..............Uª

Summary

This article described how a computer bootstraps. The Power-On Self Test (POST) causes the first sector of a (floppy) disk to be read into memory. This boot sector contains information about the disk and (at most) 451 bytes of code. In the next part of this guide, we’ll see how we can write assembly code to roll our own boot loader.

This article continues in part 2 of this series.