unreal mode

[turdus]

Seems plausible but not practical.

The whole unreal mode is not practical! Therefore it's pointless to talk about whether it's runs-only-once check is practical or not.
It was a necessary pain for backward compatibility (see how opcode 0F05h and 0F07h used by early windows and OS/2). It's obsoleted for several decades (!) now. Nobody should use it.

[Brendan]

Hi,

Seems plausible but not practical. In fact that is the official way to detect CPU fault.

It's the official way to detect software faults. The official way to detect CPU/hardware faults is with either NMI or the machine check exception.

Now think about virtual memory tricks (including "copy on write", swapping, etc), virtual8086 mode, emulation of unsupported instructions and debugging. When a page fault, general protection fault, invalid opcode fault or debugging fault (e.g. "instruction fetch breakpoint") occurs, you determine the cause of the problem, and (where appropriate) fix the problem and let everything continue as if the fault had never occurred. The "enable unreal mode within the general protection fault handler" idea is no different to this (widely accepted) practice.

However, I would suggest that any software that overrides the BIOS "interrupt 0x0D" handler should ask the PIC chip if IRQ5 occurred and pass control to the original BIOS handler if it did.

Unreal mode is activated by not following the manual(at least for IA processors), thus unofficial.

Unfortunately, a lot of things are "de facto standards" and not mentioned in any official standard. This includes various BIOS functions, the MBR partitioning scheme, the BPB, anything where there is a specification that isn't specific enough (parts of ACPI, parts of PXE, etc) and unreal mode.

The difference between "official" and "de facto" is mostly irrelevant in practice. What is relevant is whether or not it works and whether or not it will continue to work in the foreseeable future. Unreal mode does work on every "80x86 compatible" CPU that supports 32-bit protected mode. Unreal mode will also continue to work on every "80x86 compatible" CPU in the foreseeable future; not just because of backward compatibility, but because it relies on the only sane way of implementing segmentation in silicon (especially now that the internal/"hidden" state of segment registers has been made visible by official standards due to SMM and hardware virtualisation).

Looking beyond the foreseeable future (into the un-foreseeable future); I do hope that one day (after everyone has moved to UEFI) Intel/AMD are brave enough to discard real mode completely (and a lot of legacy hardware baggage - A20 gate, PIC chips, etc). If that ever actually does happen, then unreal mode will stop working at that time.


Cheers,

Brendan

[brain]

Didn't Intel try to throw away all the trash and start again with itanium 64, creating a cpu completely incompatible with x86 and x64, and nobody used it because there were no apps or oses around that were written to run on it? a case of too much, too soon.

[Combuster]

creating a cpu completely incompatible with x86 and x64, and nobody used it

Well, yes. Try selling something as *THE* replacement for x86 when you can't sanely run x86 stuff on it. Which is why AMD64 worked.

[dileep]

Hi guys , below the code , that i am using to switch in to the unreal mode.

Code: Select all

DESCRIPTOR struct
    segment_limit_0_15   dw  ?
    base_addr_0_15       dw  ?
    base_addr_16_23      db  ?
    segment_properties   db  ?
    seg_limit_16_19_gran db  ?
    base_addr_24_31      db  ?
DESCRIPTOR ends

gstart  label  qword

nullDescriptor          DESCRIPTOR    <0,0,0,0,0,0>
code16Descriptor        DESCRIPTOR    <0ffffh,0000,00,9Fh,00h,00>
code32Descriptor        DESCRIPTOR    <0ffffh,0000,00,9Fh,08Fh,00>
data16Descriptor        DESCRIPTOR    <0ffffh,0000,00,93h,00h,00>
Stack16Descriptor       DESCRIPTOR    <0ffffh,0000,00,93h,00h,00>
bigData16Descriptor     DESCRIPTOR    <0ffffh,0000,00,92h,0CFh,00>

gend label qword

gbase label     fword
limit dw   gend-gstart-1     ;limit
addr  dd    ?

 
org_gdt label fword
orig_gdt_limit      dw  0000h     
orig_gdt_addr       dd  00000000h 

unrealmode proc
    push eax
    push ebx
    push ds
    push es
    push fs
    push gs
	
    db  66h
    sgdt fword ptr cs:org_gdt
   
    xor eax,  eax
    mov ax, cs
    shl eax, 4
    add eax, offset gstart
    mov dword ptr cs:[addr], eax

    pushf
    cli

    mov bx, bigData16Descriptor - gstart	
    lgdt    fword ptr cs:[gbase]
	
     
    mov eax, cr0
    or  al, 1    
    mov cr0,eax
 
    mov ds, bx
    mov es, bx
   
    mov eax, cr0
    and al,  0FEh
    mov cr0, eax

     nop
    db 66h
    lgdt cs:orig_gdt

     popf 
      pop gs
    pop fs
    pop es
    pop ds
    pop ebx
    pop eax
    ret
unrealmode endp		

While setting PE bit in CR0 the system reboots.
Can anyone help me in this.?

Once i started coding to switch to unreal mode, i used wrong GDT table along with LGDT instruction as follows.

Code: Select all

   
GDT_LENGTH EQU gend-gstart-1

gbase label     fword
       dw  GDT_LENGTH
limit  dw  gend-gstart-1     ;limit
addr  dd   0000h

and also forgot to set the linear address to "addr " . But unfortunately it was working for me.
How did it work with this ? Can anyone help me ?

[Rudster816]

Looking beyond the foreseeable future (into the un-foreseeable future); I do hope that one day (after everyone has moved to UEFI) Intel/AMD are brave enough to discard real mode completely (and a lot of legacy hardware baggage - A20 gate, PIC chips, etc). If that ever actually does happen, then unreal mode will stop working at that time.

Just as a quick note: Intel dropped support for the A20 line with their Nehalem microarchitecture and later CPU's. Specifically, there is no longer an A20E pin on the CPU. I'm not sure on the status of newer AMD chips as far as A20 support.

[Brendan]

Hi,

Looking beyond the foreseeable future (into the un-foreseeable future); I do hope that one day (after everyone has moved to UEFI) Intel/AMD are brave enough to discard real mode completely (and a lot of legacy hardware baggage - A20 gate, PIC chips, etc). If that ever actually does happen, then unreal mode will stop working at that time.

Just as a quick note: Intel dropped support for the A20 line with their Nehalem microarchitecture and later CPU's. Specifically, there is no longer an A20E pin on the CPU. I'm not sure on the status of newer AMD chips as far as A20 support.

I've heard that rumour before. It's true (the CPU doesn't have an actual A20 pin) but it's also false (the CPU still supports A20). Basically, to reduce pin count on the CPU, they're using an "A20 message" sent over the CPU's bus instead.

If you look at a recent Intel chipset datasheet you'll probably find a section called "Virtual Legacy Wires" (VLW). For my chipset, the signals NMI, SMI#, INTR, INIT# and A20M# (from the IO Hub) are all converted into "VLW messages" that are sent to the CPU; and the CPU can send a FERR "VLW message" to control the FERR# signal.


Cheers,

Brendan