CHAPTER 3. BOOT SECTOR PROGRAMMING (IN 16-BIT REAL
MODE) 10
3.2 16-bit Real Mode
CPU manufacturers must go to great lengths to keep their CPUs (i.e. their specific
instruction set) compatible with earlier CPUs, so that older software, and in particular
older operating systems, can still run on the most modern CPUs.
The solution implemented by Intel and compatible CPUs is toemulatethe oldest
CPU in the family: the Intel 8086 , which had support for 16-bit instructions and no
notion ofmemory protection: memory protection is crucial for the stabilty of modern
operating systems, since it allows an operating system to restrict a user’s process from
accessing, say, kernel memory, which, whether done accidentally or on purpose, could
allow such a process to circumvent security mechanisms or even bring down the whole
system.
So, for backward compatibility, it is important that CPUs boot initially in16-bit
real mode, requiring modern operating systems explicitly to switch up into the more
advanced 32-bit (or 64-bit) protected mode, but allowing older operating systems to
carry on, blissfully unaware that they are running on a modern CPU. Later on, we will
look at this important step from 16-bit real mode into 32-bit protected mode in detail.
Generally, when we say that a CPU is 16-bit, we mean that its instructions can work
with a maximum of 16-bits at once, for example: a 16-bit CPU will have a particular
instruction that can add two 16-bit numbers together in one CPU cycle; if it was neces-
sary for a process to add together two 32-bit numbers, then it would take more cycles,
that make use of 16-bit addition.
First we will explore this 16-bit real mode environment, since all operating systems
must begin here, then later we will see how to switch into 32-bit protected mode and the
main benefits of doing so.
3.3 Erm, Hello?
Now we are going to write aseeminglysimple boot sector program that prints a short
message on the screen. To do this we will have to learn some fundamentals of how the
CPU works and how we can use BIOS to help us to manipulate the screen device.
Firstly, let’s think about what we are trying to do here. We’d like to print a character
on the screen but we do not know exactly how to communicate with the screen device,
since there may be many different kinds of screen devices and they may have different
interfaces. This is why we need to use BIOS, since BIOS has already done some auto
detection of the hardware and, evidently by the fact that BIOS earlier printed information
on the screen about self-testing and so on, so can offer us a hand.
So, next, we’d like to ask BIOS to print a character for us, but how do we ask BIOS
to do that? There are no Java libraries for printing to the screen --- they are a dream
away. We can be sure, however, that somewhere in the memory of the computer there
will be some BIOS machine code that knows how to write to the screen. The truth is
that we could possibly find the BIOS code in memory and execute it somehow, but this
is more trouble than it is worth and will be prone to errors when there are differences
between BIOS routine internals on different machines.
Here we can make use of a fundamental mechanism of the computer:interrupts.