How To use INT DOS in Protected Mode

[xavmoss]

Hi I have project to make program in protected mode. I want use int from DOS in protected mode. Anyone can help me

[smiddy]

There a few things you have to do to switch back and forth between real mode and protected mode:

1) IDT vs IVT; you'll have to swap between them
2) Remapping the PIC, to and from for both environments
3) Save register states between each environment
4) Make certain your selectors align for 16-bit and 32-bit code and data segments (and possibly 24-bit if you use PnP or PCI BIOS)

Off the top of my head, I think that is the basics. There are some things you may want to do, like update the BDA, or EBDA since those BIOS interrupts rely on those data points to do their routines, depending on what you want to do. Also, if you are running ontop of DOS too, all the DOS data areas will need to be updated as well, so things don't get missaligned.

I have a FASM example routine at the house, I'll share once I get home. It basically calls INT 10h and uses the passed general registers.

[smiddy]

Here some FASM code to digest:

Code: Select all

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; VideoModeInt - Uses interrupt 10h from real mode to change text modes
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

VideoModeInt:

    pushad
    push es

    mov word [RealModeAX],ax
    mov word [RealModeBX],bx
    mov word [RealModeCX],cx
    mov word [RealModeDX],dx
    ;; Need to save our stack stuff
    mov eax,esp
    mov [ProtectedModeStackPointer],eax
    mov byte [RealModeError],0

    call DisableAllIRQs                     ; Turn off every IRQ (bitmap is 0FFFFFFFFh or all off)
    mov al,11h
    out 020h,al
    out 0A0h,al

    mov al,08h
    out 021h,al

    mov al,070h
    out 0A1h,al

    mov al,4
    out 021h,al

    mov al,2
    out 0A1h,al

    mov al,1
    out 021h,al
    out 0A1h,al
    jmp 28h:RealModeVGA

use16

RealModeVGA:

    mov ax,30h
    mov ds,ax
    mov ss,ax
    nop

    mov bx,[RealModeCS]
    push bx
    lea bx,[DoVideoRealMode]
    push bx

    mov eax,cr0
    and al,0xFE
    mov cr0,eax

    retf

DoVideoRealMode:

    mov ax,cs                               ; Save CS to AX
    mov ds,ax                               ; Put DS to CS
    mov ax,[StackSegment]                   ; Save original stack segment to AX
    mov ss,ax                               ; Replace original stack segment
    mov ax,[StackPointer]                   ; Save the stack pointer to AX
    movzx esp,ax                            ; and Replace original stack pointer (force 16 bit)
    nop                                     ; Take a CPU clock tick
    mov es,ax                               ; Update ES with AX
    mov fs,ax                               ; Update FS with AX
    mov gs,ax                               ; Update GS with AX

    ;;;;;;;;;;;;;;;;;;;;;;;
    ;; Load real mode IDTR
    ;;;;;;;;;;;;;;;;;;;;;;;

    lidt [RIDTR]                            ; Load original IVT from 0000:0000
    push cs                                 ; Put CS on stack
    pop ds                                  ; Put CS from stack to DS
    push ds                                 ; Save DS to the stack
    pop es                                  ; Update ES with DS from stack

    mov al,0                                ; Re-enable realmode IVT by turning on all IRQs
    out 0A1h,al                             ; Updates lower 7 IRQs
    out 021h,al                             ; Updates upper 8 IRQs
    sti                                     ; Re-enable interrupts

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;; Now to do the real mode interrupt
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

    mov ax,word [RealModeAX]
    mov bx,word [RealModeBX]
    mov cx,word [RealModeCX]
    mov dx,word [RealModeDX]



    int 10h

    jnc .NoError

    mov  byte [RealModeError],1

.NoError:

    mov word [RealModeAX],ax
    mov word [RealModeBX],bx
    mov word [RealModeCX],cx
    mov word [RealModeDX],dx

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;; Going back to Protected Mode
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

    cli                                     ; Turn off interrupts

    lgdt [GDTR]                             ; Load GDTR
    lidt [IDTR]                             ; Load IDTR

    mov eax,cr0
    or al,1
    mov cr0,eax

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;; Jump to Protected Mode
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

    jmp 10h:ReturnToProtectedMode

    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
    ;; 32-bit Protected Mode
    ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

use32

ReturnToProtectedMode:

    mov ax,18h
    mov ds,ax
    mov es,ax
    nop
    mov fs,ax
    mov gs,ax
    mov ax,08h
    mov es,ax
    mov ss,ax
    mov eax,[ProtectedModeStackPointer]
    mov esp,eax                             ; Re-establish our ESP
    mov al,0FFh                             ; Disable realmode IVT by turning on all IRQs
    out 0A1h,al                             ; Updates lower 7 IRQs
    out 021h,al                             ; Updates upper 8 IRQs

    call RemapPIC                           ; Remap to smiddyOS
    call EnableAllIRQs                      ; Enabled already mapped IRQs
    sti                                     ; Turn them interrupts back oh, honky!

    pop es
    popad

    ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Data
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

RealModeError               db 0
RealModeAX                  dw 0
RealModeBX                  dw 0
RealModeCX                  dw 0
RealModeDX                  dw 0
ProtectedModeStackPointer   dd 0

Questions?

[xavmoss]

Thx. I wander if I want use all the interrupt, can I use the same way?

[digo_rp]

maybe you should do that using vm86 I think is much easier then switching back to Real mode and then go into pmode.

this switches makes your OS much slow.

in case you want to do that using vm86 I have some sources that I can send to you. just let me know.

[smiddy]

Thx. I wander if I want use all the interrupt, can I use the same way?

I have only tried INT 10h, though I suspect you can do it with all the others too, except DOS INTs, unless you are running on top of DOS.

digo_rp's idea may work too, I haven't done a VM86 so I can't comment on it. I would like to see the source though and see your analysis on the speed differences of VM86 versus full protected mode to realmode to protected mode.

[Dex]

@digo_rp, i think you may be surprised how fast this method can be, example of this is, i use this method for a special floppy driver that goes to realmode and back every 512 bytes, to load a program, when timed to load the same file in windows and using this driver, they are about the same in speed .
Also this type of driver as some advantages, like being able to load from usb keyfobs or CD's etc.

[smiddy]

Dex, have you done a VM86? It would be interesting to see the difference in speed. The comparison between your code, mine, and a VM86, I suspect mine may be slower since I am careful with the IRQ rerouting, though it may not be needed to get the job done.

[xavmoss]

I working on DOS, so I can use the same way for DOS interrupt, I want use DOS interrupt in protected mode

[smiddy]

I would say it should work. You may have other registers you want to bring from protected mode to real and back again. There are pointers for some interrupt calls too, but as long as you realize what they are, I think it is do-able.

[gaf]

I use this method for a special floppy driver that goes to realmode and back every 512 bytes, to load a program, when timed to load the same file in windows and using this driver, they are about the same in speed

That's hadly surprising when you consider that floppy drivers spend almost all of their time waiting for the sectors to finally come in: Whether it takes 100 or 100000 cycles to send a command is somewhat irrelevant as long as the floppy drive needs several dozen milliseconds to execute the command.

My personal guess would be that v86 is a bit faster, albeit it shouldn't make any real difference. If you're worried about performance, your design must have some serious flaws as both methods should only be used for legacy support: BIOS based code in protected-mode operating system may only be a temporary solution until you get up some native support. Before that there's no point in worrying about performance..

I working on DOS, so I can use the same way for DOS interrupt, I want use DOS interrupt in protected mode

In protected-mode you're meant to write your own drivers. If you want to use BIOS services just stick to real-mode. In case that you really need the DOS calls design your system as a shell running on top of it.

regards,
gaf

[smiddy]

In protected-mode you're meant to write your own drivers. If you want to use BIOS services just stick to real-mode. In case that you really need the DOS calls design your system as a shell running on top of it.

Please qualify this statement. I disagree, if BIOS is available why not use it, that makes your job that much easier, instead of reading hardware specs and writing tons of drivers if you're only doing it as a hobby your mainly just trying to accomplish things within your own system, not the world of systems. In his case he is working on top of DOS, since DOS does everything for you, why not use it. Also, there are 32-bit BIOSes out there that can be used within protected mode instead of writing your own lowlevel routines. I think it makes sense to write to what is there and worry about low level programming once you are familiar with your own system. Hardware timing and port programming is far more difficult starting out it can be over whelming. Protected mode is meant to protect and isolate seperate processes, it is not meant for writing low level drivers. Your point about performance on the other hand is right on par, why worry about performance at first. Get it to work, then optimize it until you've tweaked it to a point where not another tweak will make it faster. I am a hoddyist OS developer, not a professional who has the resources and time to develop tons of drivers for others, personally, perhaps you are?

Sorry if this sounds kurt, but I think what you wrote is kind of misleading.

[Dex]

That's hadly surprising when you consider that floppy drivers spend almost all of their time waiting for the sectors to finally come in: Whether it takes 100 or 100000 cycles to send a command is somewhat irrelevant as long as the floppy drive needs several dozen milliseconds to execute the command.

But this is the point, 99% of call are not speed related eg: mode change, even in dos, no one does speed critical stuff using dos functions, but write there own functions, eg: graphics put pixel

@Smiddy, i have not code a V86, as it seem like a lot of work, compared to going to and from realmode, but it would be interesting to see the speed differanc .

[xyjamepa]

Hi
can i use virtual mode with my kernel witch is identity mapped.
so it isn't a higher half kernel ..okay.
digo_rp would you please send me some simple code in the forum
or by my email:[email protected]
tow weeks ago you just send me a picture of your os.
Thanx

[gaf]

Protected mode is meant to protect and isolate seperate processes, it is not meant for writing low level drivers.

Nevetheless all modern operating systems (f.ex. linux, windows) use their own low-level drivers. The x86 BIOS is merely a relic of the 16bit real-mode days that is today hardly ever used for anything more than boot-strapping. It never managed to make the step to a modern architecture and its support for modern devices is still very limited.

In my opinion the decline of the PC BIOS is mainly due to its limited interface. The services it provides are too high-level taking control from the operating system. Another point is the lack of a official standard that would allow the operating system to rely on the services.

In last few years the PC BIOS regained some importance as ACPI and SMBIOS became mainstream. At the same time hardware companies are developing the UEFI standard to establish a more powerful and modern firmware system. If this attempt succeeds I'll be more that happy to use the built-in graphics driver, rather than having to write my own support. For the time being you're in my opinion better off ignoring the BIOS.

In his case he is working on top of DOS, since DOS does everything for you, why not use it.

That's the same mistake that Microsoft made with its Win9x series. Danger is that your system will never be anything more than an advanced shell that inherits all the mistakes of the underlying system.

Why bother about a proper system design if DOS does everything for you ?

If BIOS is available why not use it, that makes your job that much easier, instead of reading hardware specs and writing tons of drivers.

You seem to somewhat overestimate the amount of drivers that would be needed. Almost all of the devices that can be found in a modern computer are based on an open standard, so that you only have to write a single driver for each device class. I would also be very surprised if the BIOS supported any of the non-standard device..

regards,
gaf