OSDev.org

Include the rest of the code cause can't see any problems here. could be that you didn't initialize your esi pointer properly or that the data segment is not pointing to the right place
so until we can see that there is little we can do

[attachment deleted by admin]

your IDT reboots my computer when sti is executed

Thats wierd, it works fine on mine

okay,
first of all set your DS to 7C0h (so when hardware does DS*16, it gets 7C00h, just like CS where boot sector is loaded) cause DS is supposed to be the same as CS in boot sector!
try that and get back to us, waiting.. ;D

I have set ds to 7c0h. I originally had zero as my offset for my bootsecter so I am able to get into pmode.

Since I have changed the offset to 7c0h, where are the places in my bootsector that I will have to add that offset to.

I lost on this.

ex: gdt + 7c0h

The code is above, boot_os.asm

You don't need to add any offset to anything in the bootcode cause it will be loaded at 7C00h to 7C00h+512bytes.Have you mad that change and tested it yet? also which printing is failing, is it switching to protected mode or hello from protected mode?
also check that you terminated the protected mode string properly.

Originally my bootsector is set up like this:

[org 07c00h]

xor ax,ax
mov ds,ax

I changed it to this and ran it. It rebooted my computer without even displaying a message.

[org 0]

mov ax,7c0h
mov ds,ax

The hello from protected mode message is whats giving me the trouble.

Should the PE bit be set to 1 like this:

or al,1 or should it be or eax,1?

okay,
change that
mov ax,7c0h
back to what it was earlier.
2. or al,1 and or eax,1 is the same but
or eax,1
should be used to insure that the original value CR0 in eax stays the same after the or cause the
or al,1
could loss a bit which would have moved into ah if
or eax,1
was used. so use
or eax,1(which is also the same as inc eax)

Try this print funtion instead

offset=(cur_x*2+cur_y*160)

mov edi,b8000h
mov esi,message_1 (same as lea esi,[message_1] )
call print_string_32


print_string_32:

.print_char:
mov al,[esi]
cmp al,0
je .exit_print
add edi,offset
mov [edi],al
inc edi
mov [edi],attribute
inc edi
inc esi
jmp print_char
.exit_print
ret

Whats the offset and attribute. Nasm complains about it. Is there supposed to be some value for them?

i just used offest and attribute as place holders, you are to create them
in nasm
in your data segment

cur_x db 0
cur_y db 0
attribute db 0

then write

print_string_32:
push eax
xor eax,eax
mov ax,byte [cur_y]
mov bx,80
mul bx
add ax,[cur_x]
shl ax,1 ;ax=offfset=(cur_y*80+cur_x)* 2=cur_y*160+cur_x*2
add edi,eax
.print_char:
mov al,[esi]
cmp al,0
je .exit_print
mov [edi],al
inc edi
mov [edi],byte [attribute]
inc edi
inc esi
jmp print_char
.exit_print
ret

so before calling this print function
set cur_x to desired x position (0 to 79 inclusive)
set cur_y to desired y position (0 to 24 inclusive)
set attribute to desired value eg 0x07 white on black no blincking
(check http://www.mega-tokyo.com/forum/index.p ... eadid=1516 for more details on this)
set EDI to b8000h (mov edi,b8000h)
set ESI to address of string to print (mov esi,mess_1)
then call print_string_32

this should work,try it!!! ;D

Nasm doesn't like the:

mov ax,byte [cur_y]

and the:

mov [edi], byte [attribute]

Why is this so? How do I fix this problem?

you're trying to load a 16-bits word with a 8-bits value ... i suggest you use note that you can skip the mov ax, 0 stuff as you already have a xor eax, eax (note also that imho, mov eax, byte 0 is the same size and usually pairs better in the complex pipe-line of modern cpus

you can save the cycles needed in byte/dword conversion (xor eax, eax) by allocating a dd to your variables ...
you cannot have 2 memory operands in a single command. i also suggest you avoid the 16-bits computations as much as you can while in 32 bits mode (mul bx should rather be imul eax, ebx)
for speed reasons.

your last lines can be simplified into finally, you can avoid the multiplication every call to print32 if you store the line offset (curr_y*80) rather than just curr_y.
This just means that you'll have to compute y*80 when you perform a goto_xy, but it will surely speed up your computation as you should have more prints than gotoxy

Another trick is to compute curr_y*80 as curr_y*64+curr_y*16

I really dont understand what you are trying to accomplish. Could you re-write the print function with the modified suggestions?

beyondsociety wrote: I really dont understand what you are trying to accomplish. Could you re-write the print function with the modified suggestions?

i could, but i wont... what i tried to do is to give you clues on what you could improve in the code. If this seems too complicated, just get the changes about the lines nasm dislikes (and, if i can afford a suggestion, read a book about ASM programming if you plan to do your OS in asm).
It's pointless to give you a "packaged & optimized" version of the function before you can understand *what* has been optimized and *why* ...

that's my point of vue, at least.