This series is intended to demonstrate and teach operating system development from the ground up.

Introduction

Welcome! :)

In the previus tutorial, we looked at how to switch the processor into a 32 bit mode. We also learned how we can access up to 4 GB of memory. This is great--but, how?

Also, remember that the PC boots into real mode, which has the limitation of 16 bit registers. And, hence, 16 bit segment addressing. This limits the amount of memory you can access in real mode. Because of this, we still cannot access even up to 1 GB of memory yet. Heck, we cannot even go passed the 1 MB barrier yet! What to do? We have to enable the 20th address line. This will require direct hardware programming, so we will talk about that as well.

So, This is what's on the menu:

• Direct Hardware Programming - Theory
• Direct Hardware Programming and Controllers
• Keyboard Controller Programming - Basics
• Enabling A20
• Pizza :)

Do to the use of high level languages, like C, being able to access more then 1 MB of memory can be critical. Because of this, enabling A20 (Address line 20) will be important!

Note: Remember that we cannot access over 1 MB yet! Doing so will cause a triple fault.

Also, because we are going to go over direct hardware programming, this tutorial will be a little more complicated then previous ones. Don't worry - You will get more expeirence with direct hardware programming later when we develop device drivers for the Kernel.

Ready?

Get Ready

Every single controller must be programmed a special way in order to work correctly. For example, to write (or read) a hard drive, you must first determin if it is an IDE or SCSI drive. Then, you have to determin the drive number it is, and program it using either the IDE Controller or SCSI Controller, which control the IDE and SCSI connections, respecitvley. Both of these controllers are different.

To add more complexity, a "Sector" might not be 512 bytes. Hence, "Reading and writing sectors" is vauge.

Then comes memory management and fragmentation. This is where Paging, Virtual Address Space, and the Memory Management Unit (MMU) comes into play.

Reading and writing any drive is very different then any other drive. This is even true at the bootsector level. The typical format and file system is different between media, so code that boots from a FAT12 floppy will Not work to boot a CDFS Filesystem CD ROM. By Abstracting hardware specific (And low level code), we can make most of the code, however, work for these devices.

When we say "Write a file to hard drive", we normally don't want to define what a "file" is, because we shouldn't. We shouldn't have to worry about what controller to read to/from, nor the exact location on disk. This is why abstraction is *very* important!

Everything here is primairly for protected mode (i.e., it is 32 bit code), although it will work in real mode as well. Because of this, remember the rule of protected mode:

• No interrupts are avilable! The use of any interrupt will cause a triple fault

Kernel Debugging

Debuggers in High Level Languages

What this means is that we need a debugger that could work and display memory directly. Bochs has a debugger just for us.

Bochs Debugger

Bochs debugger and display window will now appear, and you should see the line:

	[0x000ffff0] f000:fff0 (unk. ctxt): jmp f000:e05b         ; ea5be000f0
        < bochs:1> _

The first line is the important line. It tells you the current instruction, absolute address, and seg:offset address. It also gives you the machine language Operation Code (Opcode) equivelant.

HELP command

BREAK command

				// BIOS is at 0xea5be000f0
	[0x000ffff0] f000:fff0 (unk. ctxt): jmp f000:e05b
        < bochs:1> b 0x7c00                     // Sets the breakpoint to 0x7c00:0
	< bochs:2> c                            // Continue executon
	< 0> Breakpoint 1, 0x7c00 in ?? < >     // Our breakpoint is hit
        Next at t=834339
                                // We are now at our bootloaders first instruction
        < 0> [0x00007c00] 0000:7c00 (unk. ctxt): jmp 7cb5         ; e9b200/DIV>

Knowing that the bootloader loads stage 2 at 0x500, lets break to it:

	< bochs:3> b 0x500
        < bochs:4> c
	< 0> Breakpoint 2, 0x500 in ?? < >
	Next at t=934606
	<0> [0x000000500] 0050:0000 (ink. ctxt): jmp 00a0        ; e99d00
        < bochs:5> _

Single Step

	< bochs:6> s
	Next at t=934607
	<0> [0x0000005a0] 0050:00a0 (ink. ctxt): cli             ; fa
	< bochs:7> s
	Next at t=934608
	<0> [0x0000005a1] 0050:00a1 (ink. ctxt): xor AX, AX      ; 31c0
	< bochs:8> _

dump_cpu

print_stack

Conclusion

Direct Hardware Programming - Theory

"Direct hardware programming" simply referrs to communicating directly (and controlling) individual chips. As long as these chips are programmable (In some way), we can control them.

In Tutorial 7, we took a very detailed look at how the system works. We also talked about how software ports work, port mapping, the IN and OUT instructions, and I gave a huge table with common port mappings on x86 architectures.

Remember that, whenever the processor recieves an IN or OUT instruction, It enables the I/O Access Line on the Control Bus, which, of course, is part of the System Bus, in the Motherboards North Bridge. Because the system bus is connected to both the Memory Controller and I/O Controller, both controllers listen for specific addresses and activated lines in the control bus. If the I/O Access line is set (Electricity runs through it--which means it is active (1), The I/O controller takes the address.

The I/O Controller then gives the port address to every other device, and awaits a signal from a controller chip (meaning that it belongs to some device--so give whatever data to that device). If no controller chip responds, and the port address is set back, it is ignored.

This is how port mapping works. (Please see tutorial 7 for more detail.)

Also, remember that a single controller chip may be assigned a range of port addresses. Port addresses are assigned by the BIOS POST, even before the BIOS is loaded and executed. Why? Alot of devices need different types of information. Some ports may represent "registers", while others may be "data" or "ready" ports. It's ugly, I know. But it gets worse. On different systems, port addresses may vary widely. Because x86 architectures are backword compatible, basic devices (Such as keyboards and mice) are useually always the same address. More complex devices, however, may not be.

Direct Hardware Programming and Controllers

Many PCs are based off of the early Intel 8042 Microcontroller chip. This controller chip is either embedded as an IC (Intergrated Circuit) chip, or directly in the motherboard. It is useually locaed in the South Bridge.

This microcontroller communcates through a cord connecting to your keyboard, to another microcontroller chip in your keyboard.

When you press a key on the keyboard, It presses down on a rubber dome setting beneath the key itself. On the underside of the rubber dome is a conductive contact that, when pressed down, comes in contact with two conductive contacts on the keyboard circuit. Because of this, current can flow through. Each key is connected by a pair of electrical lines. As each signal changes (Depending on weather keys are pressed), a make code is generated (From the series of lines). This make code is sent to the microcontroller chip inside of the keyboard, and sent through the cord connecting to the computer hardware port. It is sent through as a series of on and off electrical pusles. Depending on the clock cycles, each pulse can be converted to a series of bits representing a bit pattern.

We are on the motherboard. This series of bits goes through the south bridge as electrical signals, all the way to the 8042 microcontroller. This microcontroller decodes the make code into a scan code, and stores it within an internal register. That is, our buffer. The internal registers can be an EEPROM chip, or simular, so we can electrically overwrite the data whenever we want.

When booting, the BIOS POST assigns each device (Through the I/O Controller) port addresses. It does this by quering the devices. In the useual case, the BIOS POST sets this internal register at port address 0x60. This means, Whenever we refrence port 0x60, we are requesting to read from this internal register.

You know the rest of the story reguarding port mapping, and IN/ OUT instructions, so lets read from that register:

		in al, 0x60		; get byte from 8042 microcontroller input register

You might be wondering why you have to communicate to the keyboard controller to enable A20. We will look at this next.

Gate A20 - Theory

Enabling the A20 line may require programming the keyboard microcontroller. Because of this, I will cover a little bit about programming the keyboard controller but will not go into keyboard programming just yet.

A little history

When IBM designed the IBM PC AT machines, it used their newer Intel 80286 microprocessor, which was not entirely compatible with previous x86 microprocessors when in real mode. The problem? The older x86 processors did not have address lines A20 through A31. They did not have an address bus that size yet. Any programs that go beyond the first 1 MB would appear to wrap around. While it worked back then, the 80286's address space required 32 address lines. However, if all 32 lines are accessable, we get the wrapping problem again.

To fix this problem, Intel put a logic gate on the 20th address line between the processor and system bus. This logic gate got named Gate A20, as it can be enabled and disabled. For older programs, it an be disabled for programs that rely on the wrap wround, and enabled for newer programs.

When booting, the BIOS enables A20 when counting and testing memory, and then disables it again before giving our operating system control.

There are alot of ways to enable A20. By enabling the A20 gate, we have access to all 32 lines on the address bus, and hence, can refrence 32 bit addresses, or up to 0xFFFFFFFF - 4 GB of memory.

The Gate A20 is an electronic OR gate that was originally connected to the P21 electrical line of the 8042 microcontroller (The keyboard controller). This gate is an output line that is treated as Bit 1 of the output port data. We can send a command to recieve this data and even modify it. By setting this bit, and writing the output line data we can have the microcontroller set the OR gate thus enabling the A20 line. We can either do this ourself directly or indirectly. We will look more in the next section.

During bootup, the BIOS enables the A20 line to test the memory. After the memory test, the BIOS disables the A20 line to retain compatability with older processors. Because of this, by default, the A20 line is disabled for our operating system.

There can be several different ways to re-enable gate A20 depending on the motherboard configuation. Because of this, I will cover several different more common methods to enable A20.

Lets look at this next. ;)

Gate A20 - Enabling

Method 1: System Control Port A

Sone systems, including MCA and EISA we can control A20 from the system control port I/O 0x92. The exact details and functions of port 0x92 vary greatly by manufacturer. There are several bits that are commonly used though:

• Bit 0 - Setting to 1 causes a fast reset (Used to switch back to real mode)
• Bit 1 - 0: disable A20; 1: enable A20
• Bit 2 - Manufacturer defined
• Bit 3 - power on password bytes (CMOS bytes 0x38-0x3f or 0x36-0x3f). 0: accessible, 1: inaccessible
• Bits 4-5 - Manufacturer defined
• Bits 6-7 - 00: HDD activity LED off; any other value is "on"

mov	al, 2	; set bit 2 (enable a20)
out	0x92, al

mov	al, 1	; set bit 1 (fast reset)
out	0x92, al

Warning!

Other Ports...

The most common of these are I/O port 0xEE. If I/O port 0xEE ("FAST A20 GATE") is enabled on these systems, reading from this port enables A20, and writing to it disables A20. A simular effect accors for port 0xEF ("FAST CPU RESET") as well for resetting the system.

Other systems may use different ports (ie; AT&T 6300+ needs a write of 0x90 to I/O port 0x3f20 to enable A20, and a write of 0 to disable A20). There are also rumours of systems that exist that use bit 2 of I/O port 0x65 or bit 0 of I/O port 0x1f8 for enabling and disabling A20 (0: disable, 1: enable).

As you can see, there are alot of headaches when it comes to working with A20. The only way to be sure is with your motherboard manufacturer.

Method 2: Bios

Bochs Support

INT 0x15 Function 2400 - Disable A20

mov ax, 0x2400
int 0x15

INT 0x15 Function 2401 - Enable A20

mov ax, 0x2401
int 0x15

INT 0x15 Function 2402 - A20 Status

mov ax, 0x2402
int 0x15

INT 0x15 Function 2403 - Query A20 support

mov ax, 0x2403
int 0x15

BX contains a bit pattern:

• Bit 0 - 1 if supported on keyboard controller
• Bit 1 - 1 if supported on bit 1 of I/O port 0x92
• Bits 2-14 - Reserved
• Bit 15 - 1 if additional data is available.

Method 3: Keyboard Controller

This is also the reson why I wanted to cover hardware programming first. This will be our first glimps into direct hardware programming, and what it is all about. Don't worry, it's not too bad ;) It can get quite complex at times though :)

8043 Keyboard Controller - Port Mapping

This controller has the following port mapping:

We send commands to this controller by writing the command byte to I/O Port 0x64. If the command accepts a parameter, this parameter is sent to port 0x60. Likewise, any results returned by the command may be read from port 0x60.

We must note that the keyboard controller itself is quite slow. Because our code will be executing faster then the keyboard controller, we must provide a way to wait for the controller to be ready before we continue on.

This is useually done by quering for the controllers status. If this seems confusing, don't worry--everything will be clear soon enough.

8043 Keyboard Controller Status Register

• Bit 0: Output Buffer Status
• 0: Output buffer empty, dont read yet
• 1: Output buffer full, please read me :)
• Bit 1: Input Buffer Status
• 0: Input buffer empty, can be written
• 1: Input buffer full, dont write yet
• Bit 2: System flag
• 0: Set after power on reset
• 1: Set after successfull completion of the keyboard controllers self-test (Basic Assurance Test, BAT)
• Bit 3: Command Data
• 0: Last write to input buffer was data (via port 0x60)
• 1: Last write to input buffer was a command (via port 0x64)
• Bit 4: Keyboard Locked
• 0: Locked
• 1: Not locked
• Bit 5: Auxiliary Output buffer full
• PS/2 Systems:
• 0: Determins if read from port 0x60 is valid If valid, 0=Keyboard data
• 1: Mouse data, only if you can read from port 0x60
• AT Systems:
• 0: OK flag
• 1: Timeout on transmission from keyboard controller to keyboard. This may indicate no keyboard is present.
• Bit 6: Timeout
• 0: OK flag
• 1: Timeout
• PS/2:
• General Timeout
• AT:
• Timeout on transmission from keyboard to keyboard controller. Possibly parity error (In which case both bits 6 and 7 are set)
• Bit 7: Parity error
• 0: OK flag, no error
• 1: Parity error with last byte

As you can see, there is alot going on here! The important bits are bolded above--they will tell us if the controllers output or input buffers are full or not.

Here is an example. Lets say we send a command to the controller. This is placed in the controllers input buffer. So, as long as this buffer is still full, we know our command is still being performed. Here is what our code might look like:

wait_input:
        in      al,0x64		; read status register
        test    al,2		; test bit 2 (Input buffer status)
        jnz     wait_input	; jump if its not 0 (not empty) to continue waiting

Now that we are able to wait for the controller, we must be able to actually tell the controller what we need it to do. This is done through command bytes. Lets take a look!

8043 Keyboard Controller Command Register

The keyboard controller has alot of commands. Because this is not a tutorial on keyboard programming, I will not list them all here. However, I will list the more important ones:

Again, please take note there are alot more commands then this. We will look at them all later, don't worry :)

Method 3.1: Enabling A20 through keyboard controller

; Method 3.1: Enables A20 through keyboard controller
mov al, 0xdd	; command 0xdd: enable a20
out 0x64, al	; send command to controller

Method 3.2: Enabling A20 through Output Port

This method is a little bit more complex then the other methods, but it is not too bad. Basically, we can disable the keyboard and read the output port from the controller. The 8042 containes thee ports: One is input, the other is output. Oh right... The third is for testing. These "ports" are just the hardware pins on the microcontroller.

To keep things simple (And because this isnt a keyboard programming tutorial), we will just look at the output port for now.

Okay... read from the output port, simply send the...erm...read output port command (0xD0) to the controller: (Please see the keyboard controller commands table for refrence)

; read output port into al
mov     al,0xD0
out     0x64,al

Lets take a look...

• Bit 0: System Reset
• 0: Reset computer
• 1: Normal operation
• Bit 1: A20
• 0: Disabled
• 1: Enabled
• Bit 2-3: Undefined
• Bit 4: Input buffer full
• Bit 5: Output Buffer Empty
• Bit 6: Keyboard Clock
• 0: High-Z
• 1: Pull Clock Low
• Bit 6: Keyboard Data
• 0: High-Z
• 1: Pull Data Low

Most of these bits we do not want to change. Setting bit 0 to 1 resets the computer; setting bit 1 enables gate A20. You should OR this value to set the bit to insure none of the other bits get touched. After setting the bit, just write the value back (Command byte 0xD1).

The commands used to read and write the output port use the input and output buffers of the controller for its data.

This means, if we read the output port, the data read will be in the controllers input buffer register. Looking back at the I/O port table, this means to get the data we read from I/O port 0x60.

Lets look at an example. During any read or write operation, we will want to wait for the controller to be ready. wait_input waits for the input buffer to be empty, while wait_output waits for the output buffer to be empty.

; send read output port command
mov     al,0xD0
out     0x64,al
call    wait_output
 
; read input buffer and store on stack. This is the data read from the output port
in      al,0x60
push    eax
call    wait_input
 
; send write output port command
mov     al,0xD1
out     0x64,al
call    wait_input
 
; pop the output port data from stack and set bit 1 (A20) to enable
pop     eax
or      al,2		// 2 = 10 binary
out     0x60,al		// write the data to the output port. This is done through the output buffer

Cautions to look for

Controller executes the wrong command

Unkown Controller Command

Some controllers may malfunction, however. Please see the "Malfunction" section for more information.

Controller Malfunctions

The foof problem is more series. When the processor is given the command bytes 0xf0 0x0f 0xc7 0xc8, which is an example of an Hault and Catch Fire (HCF) instruction. (An Undocumented Instruction). Most of these instructions may lock up the processor itself, forcing the user to hard reboot. Others may cause unusual side effects from the use of these instructions.

One should coinsider these problems that may happen. It does happen, and controllers are no exception. (Remember that we send instruction bytes to individual ports? For example, Port 0x64--The Command Register in the Keyboard Controller).

Most of these malfunctions can easily be coinsidered "Design Flaws" of the device, though.

Physical Hardware damage

Triple Fault

Controller problems in Bochs

For example, if you try to send an unkown command (Such as 0) to the keyboard controller:

	mov		al, 0x00		; some random command
	out		0x64, al		; try to send command to controller

	[KBD   ] unsupported io write to keyboard port 64, value = 0

Demo

All of the A20 code is in A20.inc. I wrote several different routines that uses different methods of enabling A20. So if one method fails, try using another method.

Do to the increase in complexity, I have decided to have this demo downloadable. The current Stage2.asm has not changed that much either.

Because the demo does not display anything new, there is not a new picture to display.

Download the latest demo (*.ZIP: 8KB) Here.

Conclusion

We looked at alot of new concepts here. We also got experience with hardware programming. Remember: This is the only way of communicating with hardware in protected mode! Good bye interrupts. Good bye BIOS. Good bye everything--we are now completely on our own.

Right now, you can probably start appreciating Windows a little more :) After all, they all had to start at our level.

Don't worry if you do not understand everything yet--It is complicated, I know. When we get to our Kernel, we are going to have an entire tutorial dedicated to programming the keyboard microcontroller, and writing a driver for it. Cool?

The next tutorial will be much easier. We are going to put Protected Mode on hold for now, and go back to the real mode code. We will add the FAT12 loading code to load our kernel. Now that A20 is enabled, we can load it at 1MB!

Also, we will get some BIOS information, and anything else that comes to mind :) See you there.

Until next time,

~Mike
BrokenThorn Entertainment. Currently developing DoE and the Neptune Operating System

Questions or comments? Feel free to Contact me.

Would you like to contribute and help improve the articles? If so, please let me know!

Chapter 8

Home

Chapter 10