Page 2 of 2
Re:Printing to screen
Posted: Thu Mar 11, 2004 1:04 pm
by Candy
if you really are loading it at realmode 8:1000 then it's org 1080h yes. If it triple-faults, don't you get further in the code somehow?
Re:Printing to screen
Posted: Fri Mar 12, 2004 1:31 am
by ManOfSteel
This is my GDT:
Code: Select all
GDT db 0,0,0,0,0,0,0,0 ;null segment
GDTCode db 0ffh ;code segment
db 0ffh
db 0h
db 0h
db 0h
db 10011011b
db 11011111b
db 0h
GDTData db 0ffh ;data segment
db 0ffh
db 0h
db 0h
db 0h
db 10010011b
db 11011111b
db 0h
GDTEnd:
The bases are all 0, so the kernel should begin at 8h x 0h + 1000h = 1000h, right?
"org 1000h" didn't work, so I wrote "org 0" and "db 1000h dup (0)", and it didn't work neither.
if you really are loading it at realmode 8:1000 then it's org 1080h yes. If it triple-faults, don't you get further in the code somehow?
In my bootloader, I read the 5 sectors from the floppy, load the GDT, switch to PM, set the segments (ds, es, ...), then jump to the kernel (db 0eah - dw 1000h - dw 8h).
In the kernel, I wrote a routine to print a single character, then "org 1000h" or "org 1080h" and it triple-faulted right after it had printed the character.
Re:Printing to screen
Posted: Fri Mar 12, 2004 2:21 am
by Pype.Clicker
So you load it at 0x0000:0x1000 in real mode and then jump using 0x0008:0x1000. Forget all we said about 0x0008*16+0x1000: this is only valid in real mode.
The 'org 0x1000' should be the very first thing your assembler sees, as it defines the logical location of your code. What it does it telling the assembler "Hey, the first instruction you'll assemble is to be at offset X in the segment, not offset 0" ...
As your segment starts at physical address 0, the offset will be the physical loading address ... Now there are two pitfals you should be aware of:
- 0x1000 is actually below your bootsector address, so when your kernel will grow above 0x6C00 bytes, the bootsector will be overwritten (except if you moved it somewhere else first, of course
- the combination of ORG and a "target address!=0" in a linker script may produce odd results (like patching with relocations offsets that were already patched by ORG). If you have such a linker script, disassemble your final binary file to make sure it has the expected values ...
Re:Printing to screen
Posted: Sun Mar 14, 2004 9:18 am
by ManOfSteel
Ok, I decided to use NASM instead of TASM from now on, it seems TASM is not really good for OS programming. With NASM, the print routine is working.
Anyway, thanks to everyone who helped me.
Re:Printing to screen
Posted: Mon Mar 15, 2004 4:42 am
by Pype.Clicker
ManOfSteel wrote:
it seems TASM is not really good for OS programming.
Well, as most of us are used to Netwide ASseMbler, you'll find most of the tutorials in asm written for nasm ... But beside this i don't see why TASM could not fit the task ...