News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

unreal mode

Started by ninjarider, June 29, 2007, 04:27:43 AM

Previous topic - Next topic

ninjarider

#15
ok. using a .386p

theres a struct for Desc and a struct for table reg
temp_gdt_null_desc is a Desc
temp_gdt_scratch  is a table_reg

/dont remember the syntax but disabled interrupts

the following code has a 66h proceding it
mov ebx, offset temp_gdt
mov dword ptr [ebx], 0
mov dword ptr [ebx] + 4, 0
mov dword ptr [ebx] + 8, Linear_Proto_hi //0000ffffh
mov dword ptr [ebx] + 12, linear_proto_lo //000cf9200h

mov temp_gdt_scratch.table_linear, ebx
mov temp_gdt_scratch.table_lim, 15

lgdt temp_gdt_scratch ////// on this line shouldn't i be loading the address of temp_gdt_scratch


mov ebx, cr0 // is not lead by a 66h
or ebx, 1
mov cr0, ebx ///////////// for some reason when it executes this line the computer reboots.

/enable interrupts

ninjarider

took a look at the program through debug and noticed that is either wasn't decoding the instructions correctly or it is assembling wrong. i've tried both the 66h and the 67h and niether overide seems to help.

what should  the following assemble to in hex
mov ebx, cr0
or ebx, 1
mov cr0, ebx

lgdt GDT_TABLE

i've tried using a already declared gdt
having the first word of the gdt_table being a declared as df // what exactly does this do.

debug will also not run the lgdt instruction to see if it is assembling correctly

im starting to wonder if i just need to write this portion of my code in hex.

MichaelW

AFAIK lgdt FWORD PTR GDT_TABLE will force MASM to encode the instruction correctly.

Also, japheth has an updated version of DEBUG that I think should be able to handle the privileged instructions correctly:

http://www.masm32.com/board/index.php?topic=5934.0

eschew obfuscation

ninjarider

thnx. i've been reading through the forum to find what i can about switching modes and causes of the continues reboots.

sinsi

Apparently code using CR0 doesn't need a 66h override

0F20C3        MOV     EBX,CR0
6683CB01      OR      EBX,00000001
0F22C3        MOV     CR0,EBX


Quote
having the first word of the gdt_table being a declared as df // what exactly does this do.
The first word is the limit of the descriptor tables minus 1 - if you're using 2 descriptors (NULL and flat) then the first word will be (8+8)-1 = 0fh.

Quote
mov temp_gdt_scratch.table_linear, ebx
mov temp_gdt_scratch.table_lim, 15
From this little snippet it seems that the linear address might be wrong - you need the address made from seg:offset

    sub ebx,ebx
    mov bx,ds
    shl ebx,4
    add ebx,offset temp_gdt
    mov temp_gdt_scratch.table_linear, ebx

Light travels faster than sound, that's why some people seem bright until you hear them.

Corwinoid

Quote from: sinsi on June 29, 2007, 10:37:33 AM
So the A20 address line is the only one that can be switched on/off by code. Also notice that the BIOS (supposedly) disables it again - VMWare/Bochs don't seem to...or my actual computer.
VMWare (1.0.2) most certainly does after the virtual "BIOS" transfers control to the boot loader, executing the following from the boot sector shows this clearly (stage 1, or stage 2 if you're not using another boot loader):

mov ax, 2402h
int 15h
jc A20M_Failure
    cmp al, 0
    jne A20_enabled
    ; A20 is disabled here -- vmware will definitely jump here before A20# is enabled

    A20_enabled:
    ; enabled here

A20M_failure:
  ; I haven't tried int 15h, ax = 2402 on Bochs, but VMWare doesn't reach this
...

ninjarider

progress. it no longer continueslly reboots. althou it doesn't display we made it either. all i get is a flashing cursor

.model small
.386p
.stack 200h
.code
org 7c00h

temp_gdt:
dd 0
dd 0
dd 0ffffh
dd 879200h
dd 0ffffh
dd 879a00h

dw 0
df 23
dd 07c42h

xor ax
mov ds, ax
mov es, ax
mov ss, ax

cli
db 66h
lgdt temp_gdt_table
mov ebx, cr0
or ebx, 1
mov cr0, ebx

db 0eah
dd cs:offset Forward
Forward:
mov cx, 8
mov ds, cx
mov es, cx
mov cx, 16
mov cs, cx ; tried with and without this line.

..
some code to display 'yea'
uses si and lodsb with int 10h
..

sinsi

Are you trying protected mode or flat/unreal mode?

  dw 0
  df 23
  dd 07c42h

If that is temp_gdt_table, it is defined wrong -

  dw 23     ;limit of temp_gdt - 1
  dd 7c42h  ;linear address of gdt
;or use the FWORD
  df 7c420017h


When you jump to Forward, you should be jumping to selector:offset - in this case 0010:00007cxx
Don't try to load CS with a value - jumping as above will do it.
INT 10 won't work too well in protected mode either.
Light travels faster than sound, that's why some people seem bright until you hear them.

ninjarider

#23
Main_Start1:

through digging i have found this in another post


;       Load Global Descriptor Table to segment registers.
;       To be loaded into selector/segment register. Selector format is:
;       SSSS SSSS SSSS STRR where:
;       S   = selector number/descriptor number.
;       T   = TI bit. 1 = LDT, 0 = LDT.
;       RPL = Requested Privilege Level.

;       0000 0000 0001 0000. Selector 2, GDT, RPL = 00. Load selector
;       pattern into segment registers.

        mov     ax, 10h
        mov     ds, ax
        mov     es, ax
        mov     ss, ax
        mov     gs, ax
        mov     fs, ax



i this this is part of were my problem is.
question if i setup the gdt with the first valid entry being a data entry and the second entry being a code entry. would i use mov ax, 8h for the data and jmp 10h: offset for the code discriptors



also i thought that if the code was still 16 bit that i would still be able to use the bios functions. maybe i mis understood.

japheth

Here's a fine site about switch from real-mode to protected-mode and back, and also about "unreal-mode" (or "flat real-mode"):

http://my.execpc.com/~geezer/johnfine/segments.htm

sinsi

That's spooky...I looked at that page about 3 hours ago... :eek

The home page is better - http://my.execpc.com/CE/AC/geezer/johnfine/
Light travels faster than sound, that's why some people seem bright until you hear them.

ninjarider

found a couple mistakes in my code. didn't notic ethe mov cs, cx instructions. those seemed to lock up the computer completely. would leave a blinking cursor on the screen. pressed the pwr but and the computer would boot up. and the pwr light on the front of the case would go off.

ninjarider

havn't fully tested it. but i believe we are successfully in unreal mode. yes :dance:

ninjarider


ninjarider

fully test unreal is up and running. now for comming up with a call or an idt to transfer back and forth from 16 to 32.