OSDev.org

[attachment deleted by admin]

I've only taken a cursory peek, but there was something that struck me as odd.

You use ORG 0x100, which is going to add this amount to the offsets in the file. Then you put DS into EBX, shift it left by 4 then add the offset to GlobalDescriptorTableBeginning to it. Unless I'm mistaken, this won't put you where you want to be.

DS isn't set (as far as I can see), and the ORG will just screw the offsets. If this is boot code and it was stuck at 0x7c00, your offsets will be relative to that. You still ought to tell DS what to be (such as 0x07c0 and kill the ORG).

There may, of course, be other matters. I would suggest eliminating the IDT setup until you have this worked out.

crazybuddha wrote:
DS isn't set (as far as I can see), and the ORG will just screw the offsets. If this is boot code and it was stuck at 0x7c00, your offsets will be relative to that. You still ought to tell DS what to be (such as 0x07c0 and kill the ORG).

Hey, buddah? forgot the old time of Dos programming ? org 0x100 is typical for .COM programs, where DS and CS are set by default to the segment where the program is loaded (i.e. your program starts at CS:100, not sure of the value given to DS, but i think DS=SS=CS

WriteStringAndHalt_Done:
Xor Ax,Ax
Int 21h

reinforces me in my conviction this is a nice old DOS program ...

a few things. ...

Add Eax,GlobalDescriptorTableBeginning
;;;;; ----- shouldn't it be "add ebx, Global ..."
Mov [GlobalDescriptorTableRegister + 2],Ebx

Add Eax,InterruptTableBeginning
Mov [InterruptTableRegister + 2],Eax

As buddah said, i suggest you to leave IDT alone until you got a clean interruptless switch. Pmode switching is like eating an elephant: do it one spoonful at a time !

Inc Ax      ; This instead of Or Al,1 saves 1 byte

keep your 1 extra byte, at least you'll be sure of what you do

WriteA20WasNotEnabled:
Movsb
Inc Edi
Lodsb
Cmp Al,0
Jne WriteA20WasNotEnabled
Hlt

Your text display loop seems weird to me. You read one byte and display it, then skip one byte, write one, skip one ...

SystemCodeDescriptor:
   dw 0xFFFF      ; Limit/Length
   dw 0         ; Base 0
   db 0         ; Base 0
   db 10011110b      ; P=1, DPL=0, DT=0, ?, Code: conforming, exec/read (1,0,0,1,1110)
   db 11001111b      ; G=1, D=1, 0, AVL=0, 1111=F: Limit/Length (1,1,0,0,1111)
   db 0         ; Base 0

You set up code with base = 0 while your code is likely to have !=0 segment in real mode, therefore, all your offsets are wrong. You should prepare your GDT entries to have one code segment which base is CS_real * 16 and a data segment which base is DS_real * 16...

I also suggest you forget about the conforming code for now ...

That's all i can see for now ...

Pype.Clicker wrote:

crazybuddha wrote:
DS isn't set (as far as I can see), and the ORG will just screw the offsets. If this is boot code and it was stuck at 0x7c00, your offsets will be relative to that. You still ought to tell DS what to be (such as 0x07c0 and kill the ORG).

Hey, buddah? forgot the old time of Dos programming ? org 0x100 is typical for .COM programs, where DS and CS are set by default to the segment where the program is loaded (i.e. your program starts at CS:100, not sure of the value given to DS, but i think DS=SS=CS

WriteStringAndHalt_Done:
Xor Ax,Ax
Int 21h

reinforces me in my conviction this is a nice old DOS program ...

You're right. It didn't really occur to me that this was supposed to be a COM, in which case DOS fixes up the offsets. Oh well. It won't be the last mistake I make before this day is done.

Could you tell us how you were trying to run it, Peter, and under what kind of system? While it should run as a program under DOS (including booting to command-line under Windows 9x), I believe it would break in a Windows DOS box - you can't switch from real to protected mode if you're really in v86 mode. I think Windows traps attempts to do so, but I'm not sure; while I doubt it would bring down an NT kernel, it may very well crash a 9x kernel.

It would certainly not work as a boot sector, though.

Schol-R-LEA wrote: Could you tell us how you were trying to run it, Peter, and under what kind of system? While it should run as a program under DOS (including booting to command-line under Windows 9x), I believe it would break in a Windows DOS box - you can't switch from real to protected mode if you're really in v86 mode. I think Windows traps attempts to do so, but I'm not sure; while I doubt it would bring down an NT kernel, it may very well crash a 9x kernel.

It would certainly not work as a boot sector, though.

Of course I try to run it from native DOS...

And I think I check whether or not the computer is in Pmode... somewhere in the top of the code...

To Pype.Clicker:
--------------------
Yeah the IDT maybe shouldn't be there yet but since I don't enable the interrupts I can create it while creating the GDT since they have a very similar structure... But of course I understand what you mean...

I know what "Inc Ax" do where I used it: It increases Ax which set the PE-bit. But I understand your point.

Next, the display loop skip one byte in the destination. In textmode, the screen memory have one byte for which character to display and one for the colors used...

Thanx for pointing that out... I really hadn't thought about the fact that I must change the base in the descriptor (stupid me ).

Eh? I must set the conforming-bit to something and the best thing is to set it to the value that makes the segment grow upwards...

Peter_Vigren wrote:
Next, the display loop skip one byte in the destination. In textmode, the screen memory have one byte for which character to display and one for the colors used...

Of course, but i was talkin' about skipping odd bytes of the "source" string :
movsb : you copy 'A' at b8000 through al
inc edi : you move to b8002
lodsb : you put '2' in al
cmp al, 0 etc.
movsb : now you copy '0' to b8002
lodsb : you put ' ' in al and test it vs 0
movsb : ...
see what i mean ?

Eh? I must set the conforming-bit to something and the best thing is to set it to the value that makes the segment grow upwards...

uh ?? conforming code isn't about segment growing direction, but about some protections: a conforming segment at DPLn will allow some code from other DPLi to call it and have its priviledge level raise/lower to reach the caller level. i don't really remember if it allows only raising, or only lowering, or both, but this is certainly not something you'd like to have for your kernel initialization code

Pype.Clicker wrote:

Peter_Vigren wrote:
Next, the display loop skip one byte in the destination. In textmode, the screen memory have one byte for which character to display and one for the colors used...

Of course, but i was talkin' about skipping odd bytes of the "source" string :
movsb : you copy 'A' at b8000 through al
inc edi : you move to b8002
lodsb : you put '2' in al
cmp al, 0 etc.
movsb : now you copy '0' to b8002
lodsb : you put ' ' in al and test it vs 0
movsb : ...
see what i mean ?

Eh? I must set the conforming-bit to something and the best thing is to set it to the value that makes the segment grow upwards...

uh ?? conforming code isn't about segment growing direction, but about some protections: a conforming segment at DPLn will allow some code from other DPLi to call it and have its priviledge level raise/lower to reach the caller level. i don't really remember if it allows only raising, or only lowering, or both, but this is certainly not something you'd like to have for your kernel initialization code

Oh my fault... You have right in both cases... however, I must point out that I must set that bit to something... and it is pretty good to know what either value means when setting the bit to it...