Printing To Screen: Difference between revisions

Jump to navigation Jump to search
General rework.
[unchecked revision][unchecked revision]
(→‎Printf: The explanations were not enough to base a stdarg.h implementation upon them, factually not quite correct, and as such probably more confusing than helpful.)
(General rework.)
Line 1:
==Basics==
 
Working on the assumptionAssuming that you are in [[protected mode]] and not using the [[BIOS]] to dowrite screentext to writesscreen, you will have to do screen writeswrite directdirectly to "video" memory yourself.
 
This is quite easy. to do, theThe text screen video memory for colour monitors resides at <tt>0xB8000</tt>, and for monochrome monitors it is at address <tt>0xB0000</tt> (see [[Detecting Colour and Monochrome Monitors]] for more information).
 
Text mode memory takes two bytes for every "character" on the screen. One is the ''ASCII code'' byte and, the other the ''attribute'' byte. so <tt>the text "HeLlo</tt>" iswould be stored as:
 
Text mode memory takes two bytes for every "character" on the screen. One is the ''ASCII code'' byte and the other the ''attribute'' byte. so <tt>HeLlo</tt> is stored as
<pre>
0x000b8000: 'H', colourforHcolour_for_H
0x000b8002: 'e', colourforecolour_for_e
0x000b8004: 'L', colourforLcolour_for_L
0x000b8006: 'l', colourforlcolour_for_l
0x000b0008: 'o', colourforocolour_for_o
</pre>
 
The ''attribute'' byte carries the ''foreground colour'' in its lowest 4 bits and the ''background color'' in its highest 3 bits. The interpretation of bit #7 's interpretation depends on how you (or the BIOS) configured the hardware (see [[VGA Resources]] for additional info).
 
For instance, using <tt>0x00</tt> as attribute byte means black-on-black (you'll see nothing). <tt>0x07</tt> is lightgrey-on-black (dosDOS default), <tt>0x1F</tt> is white-on-blue (Win9x's blue-screen-of-death), <tt>0x2a</tt> is for green-monochrome nostalgics.
 
For colour video cards, you have 16kb of text video memory to use, and. sinceSince 80x25 mode (80x25x2==4000 bytes per screen) does not use all 16kb, you(80 havex what25 isx known2, as4000 'pages'bytes and in 80x25per screen mode), you have 8 display pages to use.
 
When you print to any other page than 0, it will ''not'' appear on screen until that page is ''enabled'' or "''copied"'' into the page 0 memory space.
 
==Printing Strings==
Line 27 ⟶ 28:
 
<pre>
/*/ note this example will always write to the top
// line of the screen */
void write_string( int colour, const char *string )
{
volatile char *video = (volatile char*)0xB8000;
while( *string != 0 )
{
{
*video++ = *string++;
*video++ = colour;
string++;
}
video++;
*video=colour;
video++;
}
}
</pre>
Line 47 ⟶ 45:
==Printing Integers==
 
Just like in any environment:, convertyou repeatedly divide the numbervalue intoby athe stringbase, andthe remainder of the division giving you the least significant thendigit printof the stringvalue.
 
E.g.For example, since 1234 = 4 + 10*3* 10 + 100*2 * 100 + 1000*1* 1000, if you recursivelyrepeatedly divide "1234" by ten and use the result of the division, you get all the digits:
 
<pre>
Line 57 ⟶ 56:
</pre>
 
As this algorithm retrieves the digits in the "wrong" order (last-to-first), beyou have to displayedeither arework '1'recursively,'2','3','4' ..or invert the sequence of digits afterwards. ifIf you know the numerical value of <tt>number % 10</tt>, you simply have to add this to the character '0' to have the correct character (e.g. '0'+4 == '4')
 
Here is an example implementation of the itoa() function (which is not standard, but provided by many libraries):
Line 103 ⟶ 102:
(see more on [http://www.osdev.org/phpBB2/viewtopic.php?t=10319 the forum].)
 
== printf and variable argument lists ==
== Printf ==
 
If you're working with C, you may want to print any number of arguments, like <tt>printf()</tt> does. For this, you need to handle variable argument lists. Looking at the <tt>stdarg.h</tt> file from other operating systems (e.g. Linux 0.1), you might be a bit confused by the macro definitions in that file, as they are basically black magic depending on the C calling conventions. As such, they are not exactly portable.
Line 125 ⟶ 124:
=== Nothing is Displayed ===
 
Keep in mind that this way of writing to video memory will _only_ work if the screen has been correctly set up for 80x25 video mode (which is mode 03). You can do this either by initializing every VGA register manually, or by calling the ''Set Video Mode'' service of the BIOS Int10h while you're still in real mode (in your bootsector, for instance). Most BIOS's doesdo that initialization for you, but some other (mainly on laptops) do not. Check out [[Ralf Brown's Interrupt List]] for details. Note also that some modes that are reported as "both text & graphic" by mode lists are actually graphic modes with BIOS functions that plot fonts when you call char/message output through Int10h (which means you'll end up with plain graphic mode once in [[Protected Mode]]).
 
([GRUB] does this setup for you.)
Another common mistake is to, by following numerous tutorials spread across the net for example, link the .text section of your kernel/OS to the wrong memory address. If you don't have memory management in place yet, make sure you're using physical memory locations in the linker script.
 
Another common mistake is to, bye.g. followingin numerous tutorials spread across the net, foris example,to link the .text section of your kernel/OS to the wrong memory address. If you don't have memory management in place yet, make sure you're using physical memory locations in the linker script.
===Printing in Real Mode===
 
''It's '''real''' easy...''
 
While still in [[Real Mode]], try to write directly to Video memory. If this doesn't work either you haven't set up the Video mode properly to 0x03 (check out [[RBIL]]) or you're assuming the wrong video memory address (<tt>0xb8000</tt> instead of <tt>0xb0000</tt>)
 
===Printing a Character===
 
While in Protected Mode, try a simple command like:
 
<pre>
// C
*((int*)0xb8000)=0x07690748;
</pre>
 
// NASM
which should display 'Hi' in grey-on-black on top of your screen. If the previous step worked and not this one, check your paging / segmentation setup correctly maps your assumed video memory address onto 0xB8000 (or 0xB0000). NASM-only developers may use
<pre>
mov [0xb8000], 0x07690748
</pre>
 
// GAS
and GAS-guys will have
<pre>
movl $0x07690748,0xb8000
</pre>
 
which should display 'Hi' in grey-on-black on top of your screen. If thethis previous step worked anddoes not this onework, check your paging / segmentation setup correctly maps your assumed video memory address ontoto 0xB8000 (or 0xB0000). NASM-only developers may use
 
=== Missing Strings ===
 
ThatSometimes mayprinting soundindividual stupidcharacters works, but it'sprinting astrings commonfails. mistakeThis tois forgetusually due to the <tt>.rodata</tt> section missing in the linker script. The GCC option <tt>-fwritable-strings</tt> can beis a substitute workaround, but stillthe ifreal yousolution hadis to add <tt>.rodata</tt> to the script.
<pre>
kprint("Hello World");
</pre>
and that no "Hello World" string appear in your kernel.bin (or whatever), don't search any further
 
[[Category:Video]]
448

edits

Cookies help us deliver our services. By using our services, you agree to our use of cookies.

Navigation menu