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

Introduction

We have went over alot so far, havn't we? You should now be aware of the amount of complexity there is in OS development. And yet--it only gets harder.

This is our first two-part tutorial. The first part will describe all of the new code in detail. We will cover basic 32 bit graphics programming in assembly. This includes: Basic VGA Programming concepts, accessing video display, printing strings, clearing the screen, and updating the hardware cursor. There is a little math involved, but not too much :)

The demo itself is completed. It will be shown in the second part of this tutorial, along with an overview of the completed Stage 2 source code, including its new little FAT12 driver, Floppy driver. These are not "real" drivers by definition that we will add. However, they will help demenstrate the functionality of drivers, and why they are usefull. All of the code is a heavily modified version of our FAT12 loading code from the bootloader, so I will not be describing FAT12 again in detail.

With that, Part two--as being the last tutorial for Stage 2--will go over the loading and executing of a basic (pure binary) Kernel image at 1 MB.

This two part tutorial is the last tutorial for Stage 2! When we start the Kernel, we will need to cover different executable format files. We will need to insure Stage 2 executes the object files correctly. Because of this, when we start the Kernel, we will add the loader to our current Stage 2 bootloader to insure it loads our Kernel correctly. This is later, though :)

With all of that in mind, Part 1 of this tutorial covers:

• Basic VGA Programming Concepts
• Accessing the Display
• Printing characters
• Printing strings
• CRT Microcontroller theory and updating the hardware cursor
• Clearing the screen

Ready?

The Display

VGA - Theory

The VGA consists of the video buffer, video DAC, CRT Controller, Sequencer unit, Graphics Controller, and an Attribute Controller. Please note that, we will not cover everything in detail yet until we start talking about video drivers. This is primarily to preseve space, and to make things more easier as programming the VGA can get quite complex.

Video Buffer

Video DAC

CRT Controller

Sequencer

Graphics Controller

Don't worry if you do not understand these yet. I do not plan on going into much detail here. We will cover everything in detail later when we talk about developing a video driver. For now, just remember that: The Graphics Controller refreshes the display from the parallel data from video memory. This is automatic based on the active display times. This simply means, that By writing to video memory (Default mapped to 0xA0000) we effectivly write to video display, depending on the current mode. This is important when printing characters.

Remember that it is possible to change the address range used by the Graphics Cotroller. When initializing, the BIOS does just this to map video memory to 0xA0000.

Video Modes

The VGA supports two types of modes: APA Graphics, and Text.

APA Graphics

Pixel

A "Pixel" is the smallest unit that can be represented on a display. On a display, it represents the smallest unit of color. That is, basically, a single dot. The size of each pixel depends heavily on the current resolution and video mode.

Text Modes

A Video Controller implimenting text mode uses two buffers: A character map representing the pixels for each individual character to be displayed, and a buffer that represents what characters are in each cell. By changing the character map buffer, we effectivly change the characters themselves, allowing us to create a new character set. By changing the Screen Buffer, which represents what characters are in each cell, we effectivly change what characters are displayed on screen. Some text modes also allow attributes, which may provide a character color, or even blinking, underlined, inversed, brightened, etc.

MDA, CGA, EGA

MDA - Theory

The MDA did not have any graphics mode of any kind. It only had a single text mode, (Mode 7) which could display 80 columns by 25 lines of high resolution text characters.

This display adapter was a common standard used in older PC's.

CGA - Theory

The CGA only supported a Color Palette of 16 colors, because it was limited to 4 bytes per pixel.

CGA supported two text modes and two graphics modes, including:

• 40x25 characters (16 color) text mode
• 18x25 characters (16 color) text mode
• 320x200 pixels (4 colors) graphics modes
• 640x200 pixels (Monochrome) graphics mode

EGA - Theory

Remember that the VGA adapters are backward compatible, simular to the 80x86 microprocessor family. Because of this, and to insure backward compatibility, the BIOS starts up in Mode 7 (Originally from the MDA), which supports 80 columns, by 25 lines. This is important to us, because this is the mode we are in!

VGA Memory Addressing

Typically, the Video Memory is mapped as the following:

• 0xA0000 - 0xBFFFF Video Memory used for graphics modes
• 0xB0000 - 0xB7777 Monochrome Text mode
• 0xB8000 - 0xBFFFF Color text mode and CGA compatible graphics modes

It is possible to change the memory mappings used by the video adapter cards through the CRT Microcontroller. Normally this is done through Video Drivers. More on this later, though.

One can also modify how the Video Controller uses this memory. In doing so, we can create "new", or rather, "undocumented" modes. One common mode is the infamous "Mode X".

Remember that modifying the display buffer and text buffers effectivly change what is displayed on screen? This is do to the video controller refreshing the display based on the current refresh rate. The Video Controller sends commands to the CRT Controller inside the Monitor through the VGA Port. This generates a Vertical and Horizontal Retrace of the CRT to refresh the monitors' display. And, because the text and display adapter is mapped to the above PC memory addresses:

Writing to this region of memory changes what is displayed on screen

For an example, remember that we are in Mode 7? Mode 7 is a color text mode, hence uses memory that begins at 0xB8000. Because this is the text buffer used by the Video Controller to determin what to display, Writing to 0xB8000 effectivley displays text on screen.

	%define	VIDMEM	0xB8000		; video memory
 
	mov	edi, VIDMEM		; get pointer to video memory
	mov	[edi], 'A'		; print character 'A'
	mov	[edi+1], 0x7		; character attribute

Printing characters

A special property about memory is how it is linear. If we reach the end of a line being displayed, the next byte is on the line right below it. Because of linear addressing, we have to be able to convert an x/y location to a linear address to render it to screen. And, a special forumula to do that is: x + y * screen width.

Here is an example. Lets say, we want to print a character, 'A', into location x/y (5,5). Knowing that video memory begins at 0xb8000, and is linear, we can use the formula to convert this x/y location to an absolute address:

		address = x + (y * screen width)
		address = 5 + (5 * 80)
		address = 5 + 400
		address = 405
 
		This means, from the start of video memory, location 5,5 is 405 bytes away.
		So, add this to the base address of video memory:
 
		0xB8000 + 405 = 0xB8195

Knowing this, lets first provide a way to store the current location at where we are on screen. This is so that we can act like the BIOS, so that the rest of the program does not need to:

_CurX db 0					; current x/y location
_CurY db 0
 
%define		VIDMEM	0xB8000			; video memory
%define		COLS	80			; width and height of screen
%define		LINES	25
%define		CHAR_ATTRIB 14			; character attribute (White text on black background)

Text Mode 7 actually uses two bytes per character, not one. Remember this! The first byte represents the actual character, and the second byte is a ...wait for it... attribute byte! Because of this, when writing a character to screen in Mode 7, you will need to write two bytes, not one.

The attribute byte provides a way of supplying color, as well as certain attributes, such as blinking. The values can be...

• 0 - Black
• 1 - Blue
• 2 - Green
• 3 - Cyan
• 4 - Red
• 5 - Magenta
• 6 - Brown
• 7 - Light Gray
• 8 - Dark Gray
• 9 - Light Blue
• 10 - Light Green
• 11 - Light Cyan
• 12 - Light Red
• 13 - Light Magenta
• 14 - Light Brown
• 15 - White

The attribute byte is a byte that defines certain attributes, and defining both foreground and background colors. The byte follows the format:

• Bits 0 - 2: Foreground color
• Bit 0: Red
• Bit 1: Green
• Bit 2: Blue
• Bit 3: Foreground Intensity
• Bits 4 - 6: Background color
• Bit 4: Red
• Bit 5: Green
• Bit 6: Blue
• Bit 7: Blinking or background intensity

Setting up

Putch32 is the pmode routine that will display a character in stage 2. Don't worry, we will rewrite these routines for the Kernel using C. By showing how it's done in assembly, we can compare assembly language relationships with C. More on this later.

Anyways, heres the startup code:

bits 32
 
%define		VIDMEM	0xB8000			; video memory
%define		COLS	80			; width and height of screen
%define		LINES	25
%define		CHAR_ATTRIB 14			; character attribute (White text on black background)
 
_CurX db 0					; current x/y location
_CurY db 0
 
;**************************************************;
;	Putch32 ()
;		- Prints a character to screen
;	BL => Character to print
;**************************************************;
 
Putch32:
 
	pusha				; save registers
	mov	edi, VIDMEM		; get pointer to video memory

Before displaying characters, we have to find out where to display it. To do this, just write it to the current x/y location (_CurX and _CurY). This is not quite simple though.

As you remember, video memory is linear, so we have to convert the x/y location into linear memory. Remember our formula x + y * screen width. This can be easily computed. However, remember that every character is two bytes in size. Remember that _CurX, _CurY, COLS, LINES, are based off characters, not bytes. i.e., COLS=80 characters. Because there are two bytes per character, we have to compare with 80*2. Simple, huh?

This makes things a little more complex, but not that hard:

	;-------------------------------;
	;   Get current position	;
	;-------------------------------;
 
	xor	eax, eax		; clear eax
 
		;--------------------------------
		; Remember: currentPos = x + y * COLS! x and y are in _CurX and _CurY.
		; Because there are two bytes per character, COLS=number of characters in a line.
		; We have to multiply this by 2 to get number of bytes per line. This is the screen width,
		; so multiply screen with * _CurY to get current line
		;--------------------------------
 
		mov	ecx, COLS*2		; Mode 7 has 2 bytes per char, so its COLS*2 bytes per line
		mov	al, byte [_CurY]	; get y pos
		mul	ecx			; multiply y*COLS
		push	eax			; save eax--the multiplication

		;--------------------------------
		; Now y * screen width is in eax. Now, just add _CurX. But, again remember that _CurX is relative
		; to the current character count, not byte count. Because there are two bytes per character, we
		; have to multiply _CurX by 2 first, then add it to our screen width * y.
		;--------------------------------
 
		mov	al, byte [_CurX]	; multiply _CurX by 2 because it is 2 bytes per char
		mov	cl, 2
		mul	cl
		pop	ecx			; pop y*COLS result
		add	eax, ecx

Yey! Okay, now EAX contains the offset byte to print our character to, so lets add it to EDI--which holds the base address of video memory:

		;-------------------------------
		; Now eax contains the offset address to draw the character at, so just add it to the base address
		; of video memory (Stored in edi)
		;-------------------------------
 
		xor	ecx, ecx
		add	edi, eax		; add it to the base address

	;-------------------------------;
	;   Watch for new line          ;
	;-------------------------------;
 
	cmp	bl, 0x0A		; is it a newline character?
	je	.Row			; yep--go to next row
 
	;-------------------------------;
	;   Print a character           ;
	;-------------------------------;
 
	mov	dl, bl			; Get character
	mov	dh, CHAR_ATTRIB		; the character attribute
	mov	word [edi], dx		; write to video display
 
	;-------------------------------;
	;   Update next position        ;
	;-------------------------------;
 
	inc	byte [_CurX]		; go to next character
	cmp	[_CurX], COLS		; are we at the end of the line?
	je	.Row			; yep-go to next row
	jmp	.done			; nope, bail out

	;-------------------------------;
	;   Go to next row              ;
	;-------------------------------;
 
.Row:
	mov	byte [_CurX], 0		; go back to col 0
	inc	byte [_CurY]		; go to next row
 
	;-------------------------------;
	;   Restore registers & return  ;
	;-------------------------------;
 
.done:
	popa				; restore registers and return
	ret

Working with strings

To print actual information, we will need a way to print full strings. Because we already have a routine that tracks current position (and updates it), and prints the characters, all we need to do to print a string is a simple loop.

Puts32:
 
	;-------------------------------;
	;   Store registers             ;
	;-------------------------------;
 
	pusha				; save registers
	push	ebx			; copy the string address
	pop	edi

Now, we loop:

.loop:
 
	;-------------------------------;
	;   Get character               ;
	;-------------------------------;
 
	mov	bl, byte [edi]		; get next character
	cmp	bl, 0			; is it 0 (Null terminator)?
	je	.done			; yep-bail out

	;-------------------------------;
	;   Print the character         ;
	;-------------------------------;
 
	call	Putch32			; Nope-print it out

All we need to do now is to go to the next character, and loop:

	;-------------------------------;
	;   Go to next character        ;
	;-------------------------------;
 
.Next:
	inc	edi			; go to next character
	jmp	.loop
 
.done:
	;-------------------------------;
	;   Update hardware cursor      ;
	;-------------------------------;
 
	; Its more efficiant to update the cursor after displaying
	; the complete string because direct VGA is slow
 
	mov	bh, byte [_CurY]	; get current position
	mov	bl, byte [_CurX]
	call	MovCur			; update cursor
 
	popa				; restore registers, and return
	ret

Voila! We got ourselves a way to print strings in 32 bit protected mode. Not to hard, is it? Oh wait.. What is MovCur for? We will look at that next.

Updating the hardware cursor

This cursor is handled by the hardware. The CRT Microcontroller, in fact. So, we have to know some basic vga programming in order to move this cursor.

CRT Microcontroller

Warning for CRT users

CRT Monitor failures are violent in nature, and can explode and produce sharp glass fragments to fly at high speeds. It is possible to change frequency settings greater then the devices can handle. This may increase the chanches of a device or microchip to malfunction, producing unpredictable or desasterous results.

Because of this, if you, the reader, like experementing with the code, I recommend testing all experemental code in an emulator to its fullest first, before attempting real hardware.

I will not explain everything reguarding video programming yet until we talk about Video Drivers. We will look at everything in detail then, cool?

Anywhoo...On to the CRT Controller!

Port Mapping

So, in order to give data to the CRT Controller, we have too write two values. One to the Index Register (Containing the type of data we are writing), and one to the Data Register (Containing the data). Not too hard :)

The Index Register is mapped to ports 0x3D5 or 0x3B5.
The Data Register is mapped to ports 0x3D4 or 0x3B4.

There are more registers then these two (Such as the Misc. Output Register), but we will focus on these two for now.

Index Register Mapping

By writing an index offset value into the index Register, it indicates what register the Data Register points to (That is, what it refrences.)

Most of what is in the above table we don't need to worry about right now. However, look at indices 0xE and 0xF for a moment:

• 0x0E: Cursor Location High Byte
• 0x0F: Cursor Location Low Byte

Moving the hardware cursor

	mov	al, 0x0f
	mov	dx, 0x03D4
	out	dx, al

	mov	al, bl                  ; al contains the low byte address
	mov	dx, 0x03D5
	out	dx, al			; low byte

Here is the complete routine:

;**************************************************;
;	MoveCur ()
;		- Update hardware cursor
;	parm/ bh = Y pos
;	parm/ bl = x pos
;**************************************************;
 
bits 32
 
MovCur:
 
	pusha				; save registers (aren't you getting tired of this comment?)
 
	;-------------------------------;
	;   Get current position        ;
	;-------------------------------;
 
	; Here, _CurX and _CurY are relitave to the current position on screen, not in memory.
	; That is, we don't need to worry about the byte alignment we do when displaying characters,
	; so just follow the forumla: location = _CurX + _CurY * COLS
 
	xor	eax, eax
	mov	ecx, COLS
	mov	al, bh			; get y pos
	mul	ecx			; multiply y*COLS
	add	al, bl			; Now add x
	mov	ebx, eax
 
	;--------------------------------------;
	;   Set low byte index to VGA register ;
	;--------------------------------------;
 
	mov	al, 0x0f		; Cursor location low byte index
	mov	dx, 0x03D4		; Write it to the CRT index register
	out	dx, al
 
	mov	al, bl			; The current location is in EBX. BL contains the low byte, BH high byte
	mov	dx, 0x03D5		; Write it to the data register
	out	dx, al			; low byte
 
	;---------------------------------------;
	;   Set high byte index to VGA register ;
	;---------------------------------------;
 
	xor	eax, eax
 
	mov	al, 0x0e		; Cursor location high byte index
	mov	dx, 0x03D4		; Write to the CRT index register
	out	dx, al
 
	mov	al, bh			; the current location is in EBX. BL contains low byte, BH high byte
	mov	dx, 0x03D5		; Write it to the data register
	out	dx, al			; high byte
 
	popa
	ret

Next up: Clearing the screen!

Clearing the screen

;**************************************************;
;	ClrScr32 ()
;		- Clears screen
;**************************************************;
 
bits 32
 
ClrScr32:
 
	pusha
	cld
	mov	edi, VIDMEM
	mov	cx, 2000
	mov	ah, CHAR_ATTRIB
	mov	al, ' '	
	rep	stosw
 
	mov	byte [_CurX], 0
	mov	byte [_CurY], 0
	popa
	ret

Okay, so we have a way to print text, which also updates the hardware cursor, and clear the screen. If we wanted to, we can expand this stage 2 loader to include a small menu and advanced options when giving control to the Kernel. More on this later...

Demo

I decided to create a little demo to demenstrate everything in this tutorial. The next tutorial builds directly on this code.

This tutorial uses everything we talked about in this tutorial. It sets the foreground and background colors based on the character attribute byte. And, because of our ClrScr32() routine, effectivly clears the screen to that background color. Cool, huh?

You can download the demo Here.

Conclusion

We have went over alot of stuff here, more specifically graphics concepts. We talked about basic VGA concepts, printing characters, strings, clearing the screen, and updating the hardware cursor. By changing the attribute byte of the text we print out, we could easily print characters out in all shorts of colors! You can even get a new background by changing the color in the attribute byte, and calling our ClrScr32 () function! Cool, dont you think? It certanly beets the boring black and white... :)

The next tutorial finishes Stage 2, and loads and executes a basic pure binary 32 bit Kernel image at 1 MB. Don't worry--When we get into the Kernel section of this series, we will change the way the Kernel is built, and modify how it is loaded. This will allow us to load the Kernel as an object format--allowing it to import or export symbols, and mix it in with C. I cannot wait!

The next tutorial is not a tutorial in a sense of learning new things. Instead, it covers all of the code that has already been explained. This code, however, is modified for better code layout, and provide the interface (and seperation) between a basic FileSystem (FAT12) Driver and a Floppy Driver. Nontheless, it is the closing tutorial for Stage 2.

We will go back to Stage 2 a bit later, as Stage 2 can be modified to provide more options, or even to support Multibooting, and Boot Options. We shall see... ;)

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 9

Home

Chapter 11