what is the code for this in asm and please write comments every line and explane how it work
10x

Pretty simple code if you dont want to use bios routines.

The screen starts at physical address 0xb8000.
Each character is represented by a word.
First byte is the ascii character, second byte is the color.
For the color byte, high nyble is text color, low nyble is background color.

here's the code

mov ax,0xb800 ; segment for 0xb8000
mov es,ax ; for string move es:di is destination
push cs
pop ds ; so that we can access our string.
mov di,0 ; start in top left corner
mov si,hello_text ; our text to print
mov cx,hello_text.end-hello_text ; Size of string
cld ; set direction for string instruction to go up
mov ah,17h ; white text, blue background
print_loop: lodsb ; read char
stosw ; display it
loop print_loop ; loop until done
int 20h ; exit back to dos

hello_text:
db "This is a test."
.end

An "OS" that outputs a string? Heh.

An OS has the task to startup and setup computer and then it has to provide some form of an uniform interface to hadware and a basic set of API functions for programmers.

Booting up, setting protected mode and then outputing and string to screen is a good start or testing pad ...
BUT it is NOT an OS

Since it has no relevant API and NO drivers to help access to important hardware devices like: keyboard,mouse,video board/monitor,hard drive, network card...

Also making an OS is for people that have a tendecy to understand every little aspect of a computer and programming either in ASM and/or C/C++/HLL etc.

Having a problem to output an string on screen... is hardly fitting such an person's description.

I have such an function in Solar OS (and many other things also) and there are comments almost everywhere...

But honestly there are so many samples out there on the net, and many simple boot loaders that do just what you ask.

Searching and understanding is an important part of learning...

i know i only want to bulid a simple "os" now i will add it more things do this work on PMode

yes i am only learning how i write a driver for a keyboard in asm/c because my first targets is to make an "os" that:
1.can input something
2.react to the input
and then i will add more complex things(i need a example on simple i/o only keyboard screen so i can make my very early stage "os")
10x alot

try searching the forum for joachim_neu, who had a similar interest, and posted here a couple months ago. regards, tom tobias

If you're building an "OS", neither keyboard input nor screen output are your first concerns... there's DESIGN, protected mode, memory management, process management, ... to take care of first...

I think a os would do whatever you want it to do.

So, if all you want to do is output some text on a screen, then that would be considered an OS.

Memory management, process management, and so on are far down the line. First you got to be able to see something on the screen to know your OS is doing something.

A journey of a 1000 miles begins with a single step. Outputting text to the screen is a good start. As well as the keyboard input.

Yes it is a good start

I remember that i have started like that but i have never considered it an OS until i made some drivers/GUI/API

Brain must always see results and this will keep it running and give an incentive... to much design ...and you will end up in your own mind or even worts: walking the exact same path as millions of others.. even if that path is not really yours

If you want to write something to screen you should consider this:

1)Text mode video buffer is normal at B8000h in protected mode an first byte is ascii char and second byte is attribute with forground color/background colr and blink (all bits in one byte) ... you can find info on this all over the net...

Preatty simple and easy to use, but IMHO today a GUI is a must...and not a text GUI

So you might use this in early testing stages (I did like this) and/or as a fallback for debug/crash info --> like windows did with its "blue screen"

2)VESA graphic mode, best shot is to use VESA BIOS while still in real mode and setup the mode you want like 800x600x65536 and fetch the address of the Linear Frame Buffer and the associated Pitch. writting to this address will show pixels on screen ... btw always assume width = pitch and not = screen_width*bytes_per_pixel

3)VGA old style: use VGA mode 12h = 640x480x16colors (4planes) as this is probablly available in most hardware out there and info about how to setup and use with plain Port I/O is well known... Unfortunately is not very nice to use (4 planes) not very fast and not very nice resolution

As a very low fall back you could use VGA 320x200x256colors mode 13h
No planes here as one byte is one pixel ... but you have to use pallete and the resolution is very very low.

I actually like the 640x480x16 for initial testing.
Very nice and fast for outputing text. Can transfer the character width with one mov instruction, no calculations required. Dealing with colors is not nice.

I also like the 256 color mode because 1 byte equals 1 pixel. Semi-limited in generic colors for displaying bitmaps, but still can get a full range of colors

I plan to support all the modes including text mode in my little os. For the simple fact that the 486 I have doesn't use LFB. The real mode/protected mode swaps when drawing the GUI are kind of painful when switching banks.

but what about input and which file system shold i use build one or new

First Input is from keyboard and mouse .

Keyboard can be standard AT or USB
Mouse can be Serial, PS2 or USB or wireless/card

And from an string output up to file systems is a long way

But start with FAT32 and NTFS and Ext2 and after that maybe make your own

but how i get the key that pressed in asm can you give my an exaple on a program in asm that ask your age and out 'your age is...' please
10x alot

heh, "start with" and "NTFS" don't really go together in the same sentence - the only people who have a working&stable NTFS implementation are MS.

Yes unfortunately,

So above should be read as: start with FAT32

Because MS did not release their propretary filesystem format to public knowledge (as this is their right)..

Today we might have a problem... mainly because most people that install XP also intall NTFS ... and unless somebody is still using FAT32 (like I do) new test OS you will not be able to read people's HDD...

NTFS is superior to FAT32, so it's a good default choice for 2k and XP - especially XP, since it's meant for home users, and NTFS gives a lot less trouble with hard poweroffs, etc.

Would have been nice if MS had released full info on NTFS anyway - it's a good filesystem with a lot of nifty features.

It isn't required to implement GUI in kernel. Let's take as an example *NIX systems where graphical interface is provided by user-mode application (X server).

Also you must know what are your targets. If you are writing desktop os, then, yes, GUI is musthave thing, but if you are writing server or real-time embedded OS then GUI isn't most important thing to do.

Personally I consider things like networking more important than GUI (at least for my own OS ).



IMHO it's better to start with this not VESA 2.0 as there are still many boxes around without VESA 2.0 compatible VGA BIOS (for example, I have AMD K6-233 with Tseng ET4000 768k VESA 1.1 video as my test box).

Ok, we have problems with stable open sourced read/write NTFS implementation, but there are multiple read-only open sourced NTFS implementations around (Linux, OpenBSD).

Inputing information requires a little more coding than outputting text.
This is because when the keyboard is read, the characters input aren't ascii, but a scan code(and sometimes multiple scan codes per character).
You might want to have a look at SolarOS since it has the drivers nicely seperated into individual files.

SolarOS will give you a simple keyboard map.

But to put it basically, the scancode is put into io port 60, each key press sends a keypress code and a key up code.