Reset problem !

[stebra]

Can anyone tell me why my computer immediately reboots when i try to enter protected-mode in dos at the following instructions ?
mov eax,cr0
or    al,1
mov cr0,eax.........reboots system here !!
regards, steve.

[guyenMasm]

i had this problem for days.
The problem was in the p-mode exit code:
instead of anding :

and eax, 0fffffffeh
mov cr0, eax

i was oring:

or ax, 0fffffffeh
mov cr0, ax.

Check for something like this goofy. Also make sure you disable interrupts if you haven't set up the IDT. Check your GDT and there must be null descriptor at the beginning of GDT. If this null descriptor is accessed CPU generates GP fault.

Also you can't debug past the mov cr0, ax if you haven't setup the IDT because debugger will re-enable interrupt and CPU will triple fault at the first interrupt generated.

I sprinkled a small code that sends a char to the 3f8h port to debug inside the p-mode code so that i can observe where in the code the reset was actually occurring.

You can also use one descriptor pointing to b800h and directly write to the screen buffer, but that is laborous and complicated.

[japheth]

Since you know the exact instruction where it reboots I assume you tried to run the code inside a debugger. This won't work on a real machine. Also make sure that interrupts are disabled when setting the PE bit.

[stebra]

i had this problem for days.
The problem was in the p-mode exit code:
instead of anding :

and eax, 0fffffffeh
mov cr0, eax

i was oring:

or ax, 0fffffffeh
mov cr0, ax.

Check for something like this goofy. Also make sure you disable interrupts if you haven't set up the IDT. Check your GDT and there must be null descriptor at the beginning of GDT. If this null descriptor is accessed CPU generates GP fault.

Also you can't debug past the mov cr0, ax if you haven't setup the IDT because debugger will re-enable interrupt and CPU will triple fault at the first interrupt generated.

I sprinkled a small code that sends a char to the 3f8h port to debug inside the p-mode code so that i can observe where in the code the reset was actually occurring.

You can also use one descriptor pointing to b800h and directly write to the screen buffer, but that is laborous and complicated.

  Hi Guy,     The exit code is ok ..............I've tried various snippets of this code that is floating about in order to reach 32bit addressing but hav'nt been successful with any of it as yet !!...........I'm beginning to wonder if my ibm600x(p3) laptop does'nt like pmode in dos !!

[guyenMasm]

HMM well i am running out of idea.
You're not from virtual dos window right?
If you're in real mode, perhaps try disabling some TSR memory manager programs like himem.sys, dos extender etc. I heard some of the programs like dos extended emm386 (forgot exact name) puts the cpu in pe mode. Can't know the details.

Also, are you enabling and checking A20 gate before going to pmode with Granularity bit set? If you do these successfully you can enter into at least big real mode and have an access to 4GB range. And after getting this to work, i would concentrate on actual PE bit.

[japheth]

> I heard some of the programs like dos extended emm386 (forgot exact name) puts the cpu in pe mode. Can't know the details.

You really should know the basics if you want to to use protected-mode in DOS. An Emm386 indeed puts the cpu in protected mode and runs the DOS "real-mode" code in "v86-mode". Being in v86-mode it is indeed impossible to use instructions like "mov cr0, eax", since v86-mode runs at privilege level 3, not allowing such things. Therefore the Emm386s provide a special API (VCPI) to make the "true" protected-mode accessible for other programs like DOS extenders.

It's very easy to detect if you are in v86-mode:

   smsw ax
   test ax,1
   jnz v86mode
   jmp realmode

[guyenMasm]

> I heard some of the programs like dos extended emm386 (forgot exact name) puts the cpu in pe mode. Can't know the details.

You really should know the basics if you want to to use protected-mode in DOS. An Emm386 indeed puts the cpu in protected mode and runs the DOS "real-mode" code in "v86-mode". Being in v86-mode it is indeed impossible to use instructions like "mov cr0, eax", since v86-mode runs at privilege level 3, not allowing such things. Therefore the Emm386s provide a special API (VCPI) to make the "true" protected-mode accessible for other programs like DOS extenders.

It's very easy to detect if you are in v86-mode:

   smsw ax
   test ax,1
   jnz v86mode
   jmp realmode

good to know that. But I am bit confused by your code. You said in order to test V86 and checked PE bit in CR0 in actual code.
But as far as I know VM86 test bit is in the BIT17 of EFLAG.
(SWSW ax -> stores bottom half of CR0 in ax.)

[japheth]

> But as far as I know VM86 test bit is in the BIT17 of EFLAG.

Yes, but it is accessible from ring 0 code only. So it cannot be tested by code running in v86-mode. It will always be cleared. That is, it depends a bit, since the ring 0 code can indeed provide an emulated EFL register, and the bits set/cleared there are totally controlled by the software then. But such things are almost never seen today, because the Pentium invented a "virtual interrupt flag", making software emulation of EFL for v86-mode superfluous.