A question about MBR ,and switch real mode to protect mode.

[debugee]

;;i want to make a MBR code ,and switch real mode to protect mode.
;;but this code faild
;;can somebody help me ,please?,where the bugs is  ? :red
.model tiny
.386p
code   segment
org   07c00H
assume   cs:code
char_size_start   equ   this byte
jmp   start
   gdt0   dw   ?
      dw   ?
      db   ?
      dw   ?
      db   ?
      
   gdt   dw   0FFFFH;限长
      dw   ?   ;基地
      db   ?   ;基地
      
      dw   0CF9cH
      
      db   ?   ;基地

gdtbase      dw   ?   ;限长
      dd   ?   ;基地址
      
      
      
wen:   jmp   $
   db   ?
   db   ?
   db   ?
   db   ?
   
start:   
   mov   ax,cs
   mov   ds,ax
   mov   es,ax
   
   xor   eax,eax
   mov   ax,ds
   shl   eax,4
   add   eax,offset wen
   
   mov   bp,offset gdt
   mov   word ptr [bp + 2],ax
   shr   eax,16
   mov   byte ptr [bp + 4],al
   mov   byte ptr [bp + 7],ah

   xor   eax,eax
   mov   ax,ds
   shl   eax,4
   add   eax,offset gdt0
   
   mov   bp,offset gdtbase
   mov   dword ptr [bp + 2],eax
   mov   word ptr [bp],015H   ;gdt限长
   
   lgdt   fword ptr [bp]
   
   
   cli
   in   al, 92h
   or   al, 00000010b
   out   92h, al   
   sti
   
   mov   eax, cr0
   or   eax, 1
   mov   cr0, eax
   
   db   0eah
   dw   0
   dw   08H
char_size_end   equ   this byte
   db (510 - (char_size_end - char_size_start)) dup(?)
   dw   0aa55H
code   ends

end   

[vanjast]

I vaguely remember seeing an example in the Intel manual, describing the switch from Real to P-Mode... have a look there.

[MichaelW]

debugee,

Instead of trying to get both parts of your project working at the same time, why not work on the boot code and the mode-switch code separately? I can tell you from experience that if you try to combine both parts you are likely to waste a large amount of time trying to diagnose the inevitable problems, and rebooting, over and over again. For the mode switch code I would create a small, simple 16-bit test program that I could run in a debugger to test everything up to the mode switch. And for the debugger I would use Japheth's extended MS debug clone (Debug.com), available here:

http://www.japheth.de/debxxf.html

Edit: I see now that the debxxf programs can debug a mode switch, both ways, so it may be possible to test your mode-switch code completely within deb16f.exe, and be done with it.

[allynm]

Hi MichaelW-

I was intrigured by Japheth's debugx program and downloaded the most recent version of it (v 2.9.6) for DOS.  I'm having trouble running the program from the command line.  When I run the program from its own directory it works as expected.  However, if I attempt to load it from a different directory, I get an error message:  Cannot find loader DPMILD16.EXE and the program aborts. 

Note that I have set the path to the directory in which deb16f.exe resides, along with DPMILD16.exe

Any suggestions? 

I'm raising this issue on this thread because others reading the original post may run into what I have.

I'm running under Windows XP professional  SP3.

Regards,
Mark Allyn

[FORTRANS]

Hi,

   Perhaps APPEND would work?  Append changes the "path"
used for data file searchs.

Regads,

Steve N.

[allynm]

Hello Fortrans,

No, the append fix didn't work.  I tried various combinations of append and none of them was successful.

If I use the command "dpmild16.exe mypgrm.exe" the command runs the program.  It does this from the directory in which myprgrm.exe resides.  However, deb16f.exe will not run from the command shell when the directory is not the same as the directory in which deb16f.exe resides.

I don't get it.

Thanks
Mark

[MichaelW]

Hi Mark,

If it's version 2.9.6 then it must be one of the debxxf programs, and not debugx.com. I can't recall ever before doing anything with the debxxf programs. In the few minutes that I spent on it, testing under Windows 2000, I could not find any way to get DEB16F.EXE to run without apparent error from a directory that did not also contain DPMILD16.EXE, DEB16F.OVL, DEBXXF.HLP, DEBFVESA.DLL, DEBXXF.MAC, and RMDBGHLP.BIN. Among the things I tried was setting a path in my SYSTEM32\AUTOEXEC.NT that specified a directory with all of the above files.

[allynm]

Hi MichaelW,

Thanks for investigating this.  Your experience is exactly the same as mine.  I reckon the best course of action is to get a copy of Debugx. 

Regards,
Mark

[debugee]

hi  MichaelW,allynm ,FORTRANS
thanks for you replay
i had found the bugs,

this error:
mov ax,cs
mov ds,ax
ds == 7c00h is wrong
ds must  = 0