[Q] Need help with protected mode
Peter Andersson
I have two questions regarding protected mode under DOS due to
lack of good documention. I'm currently writing a protected mode
handler which works with VCPI but I'm going to add XMS support too.
First: Under XMS can I use the V86 mode or do I have to exit protected
mode? If I can use the V86 mode how do I handle TSRs and other
program which use XMS?
Second: My VCPI driver sometimes hangs my machine. The program will still
run but I can't use the keyboard due too some PIC failure. This is
what my program does when the PIC sends an IRQ:
1: turns off all the interrupts and returns to V86 mode.
2: reprogrammes the PIC and reports the PIC change to the VCPI server
3: int xx (where xx is the corresponding IRQ (08h-0Fh and 70h-77h))
4: reprogrammes the PIC (again) and reports the PIC change
5: returns to protected mode and restarts the interrupted task.
This is maybe not the best method and it's certainly not correct
otherwise my machine wouldn't hang... Can somone help my with this?
Well, that's it and happy new year to all of you.
--
Peter Andersson, Sweden | Look mom, my left leg walks | (Comment from a kid,
email: pa...@kullmar.se | faster than my right leg!!! | everyting is relative)
Ross Ridge
>First: Under XMS can I use the V86 mode or do I have to exit protected
> mode?
To call the XMS functions you must be in real or V86 mode. The simplest
thing to do is to allocate all XMS memory (or the largest free block)
when your programme starts (in real mode). Unless your programme spawns
other programmes that might need XMS memory this should work fine.
>If I can use the V86 mode how do I handle TSRs and other program which
>use XMS?
Why do you need to handle them?
>Second: My VCPI driver sometimes hangs my machine. The program will still
> run but I can't use the keyboard due too some PIC failure. This is
> what my program does when the PIC sends an IRQ:
> 1: turns off all the interrupts and returns to V86 mode.
> 2: reprogrammes the PIC and reports the PIC change to the VCPI server
Why reprogram it? What exactly do you mean by reprogramming?
Ross Ridge
Peter Andersson
>pa...@kullmar.se (Peter Andersson) writes:
>>If I can use the V86 mode how do I handle TSRs and other program which
>>use XMS?
>Why do you need to handle them?
Smartdrive and similar diskcaches uses XMS memory. I have the source for
himem version 3.0 and it uses protected mode to transfer memory between
DOS real (below 640KB) and extended memory (above 1MB). This will cause a
general protection under V86 mode because himem need to load the GDT
pointer. How does EMM386 handle it?
>>Second: My VCPI driver sometimes hangs my machine. The program will still
>> run but I can't use the keyboard due too some PIC failure. This is
>> what my program does when the PIC sends an IRQ:
>> 1: turns off all the interrupts and returns to V86 mode.
>> 2: reprogrammes the PIC and reports the PIC change to the VCPI server
>Why reprogram it? What exactly do you mean by reprogramming?
The PIC interrupts are normally between 08h-0Fh and 70h-77h. If you are using
protected mode you'll have to change where the PIC interrupts are because
the processor is using interrupt 0 to 1Fh for exception interrupts (eg.
general protection). By reprogramming the PIC I mean that I'm moving the
first PIC's interrupts from 08h-0Fh to 78-7Fh. (PIC = Programmable Interrupt
Controller)
> Ross Ridge
Keep coming with suggestions!
Ross Ridge
>Smartdrive and similar diskcaches uses XMS memory. I have the source for
>himem version 3.0 and it uses protected mode to transfer memory between
>DOS real (below 640KB) and extended memory (above 1MB). This will cause a
>general protection under V86 mode because himem need to load the GDT
>pointer.
Well the version HIMEM.SYS I have source for, 2.03, uses INT 15 to
transfer memory if in protected (ie. V86) mode.
>How does EMM386 handle it?
Maybe it intercepts INT 15.
>The PIC interrupts are normally between 08h-0Fh and 70h-77h. If you are using
>protected mode you'll have to change where the PIC interrupts are because
>the processor is using interrupt 0 to 1Fh for exception interrupts (eg.
>general protection). By reprogramming the PIC I mean that I'm moving the
>first PIC's interrupts from 08h-0Fh to 78-7Fh. (PIC = Programmable Interrupt
>Controller)
So why are you doing this while you're servicing an interrupt? It's
too late to change the interrupt number of the interrupt you're in the
middle of servicing and there is no need to change the interrupt
number of other interrupts you might receive during the processing of
the interrupt.
Ellster
thought XMS was a specification for sharing protected memory?
*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Elliott Coates
coa...@umuc.umd.edu
Kendall Bennett
>Well the version HIMEM.SYS I have source for, 2.03, uses INT 15 to
>transfer memory if in protected (ie. V86) mode.
>>How does EMM386 handle it?
>Maybe it intercepts INT 15.
No, EMM386 actually requires an XMS driver to be installed so that it can
allocate it's extended memory using the XMS interface. Then the memory that
it has allocated will be compatible with other XMS products. Using this
allocated XMS memory it then uses the 386's MMU and page tables to emulate
the EMS interface by mapping the XMS memory into the EMS page frame at
C000:0000 in memory.
>So why are you doing this while you're servicing an interrupt? It's
>too late to change the interrupt number of the interrupt you're in the
>middle of servicing and there is no need to change the interrupt
>number of other interrupts you might receive during the processing of
>the interrupt.
I doubt that he would be doing this while _servicing_ the interrupt, but
it is one of the things that needs to be done by a DOS extender if it wants
to be able to service interrupts from protected mode programs (like the
Int 10h BIOS interrupt). These interrupts needs to be re-vectored out of
the way from the hardware exceptions that the 386 uses (bloody IBM stood
on Intel's reserved interrupts when it design the PC).
+-------------------------------------------+------------------------------+
| Kendall Bennett | Internet: k...@citri.edu.au |
| Software Engineer, SciTech Software | Compuserve: 100237,2213 |
| G.P.O Box 4216NN | Fax: +61 3 690 2137 |
| Melbourne 3001 AUSTRALIA | |
+-------------------------------------------+------------------------------+
Peter Andersson
[some stuff deleted]
>Well the version HIMEM.SYS I have source for, 2.03, uses INT 15 to
>transfer memory if in protected (ie. V86) mode.
enter protected mode, load a segment with the base 0 and limit 4GB and
return back to real mode. The segment can then be used to access 4GB under
DOS (until it is reloaded(?)).
>>How does EMM386 handle it?
>Maybe it intercepts INT 15.
I will investigate this!
[more deleted]
>So why are you doing this while you're servicing an interrupt? It's
>too late to change the interrupt number of the interrupt you're in the
>middle of servicing and there is no need to change the interrupt
>number of other interrupts you might receive during the processing of
>the interrupt.
Hmm, maybe you're right, I will try to just mask all PIC interrupts while
it is processing the DOS interrupt.
Peter Andersson
>I thought v86 mode used protected memory to create virtual DOS machines? I
>thought XMS was a specification for sharing protected memory?
to map memory for UMBs (upper memory blocks). This must be done under V86
mode or the processor can't handle page faults and memory mappings.
The XMS standard must be used with DOS 5.0 and later! Smartdrv, ramdrive and
many other programs refuses to use extended memory without a handler. If you
want to allocate memory with those programmes installed you _have_ to use XMS
(if there isn't a VCPI/DPMI(/other) compliant server installed).
For further help(/disorientation:-) please email me.
Paul Schlyter
Peter Andersson <pa...@kullmar.se> wrote:
> >Well the version HIMEM.SYS I have source for, 2.03, uses INT 15 to
> >transfer memory if in protected (ie. V86) mode.
> Version 3.0 uses an undocumented feature in the 80386 and later. It will
> enter protected mode, load a segment with the base 0 and limit 4GB and
> return back to real mode. The segment can then be used to access 4GB under
> DOS (until it is reloaded(?)).
real-mode programs. Probably there are some 386-specific real mode programs
out there that uses FS and/or GS as temporary scratch storage (which works
fine in real mode but may bomb the system if attempted in protected mode).
Just out of curiosity I fired up TD (Borland's Turbo Debugger) and examined
the contents of the FS and GS segment registers -- they were both set to
zero, which in protected mode is used to indicate a "null selector" i.e.
that no segment at all has been loaded into that segment register.
Therefore, if one needs to, in real mode, access 4GB RAM using this trick,
it seems like one had better not rely on HIMEM.SYS doing the proper
initialization of the segment, but instead do it oneself in the beginning
of the program.
--
---
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Nybrogatan 75 A, 6 tr, S-114 40 Stockholm, Sweden
InterNet: pau...@saaf.se
Kendall Bennett
>Version 3.0 uses an undocumented feature in the 80386 and later. It will
>enter protected mode, load a segment with the base 0 and limit 4GB and
>return back to real mode. The segment can then be used to access 4GB under
>DOS (until it is reloaded(?)).
Are you sure about this? I know this is possible (Al Williams talks about
it in his book DOS 6: A Developers Guide, but I didn't think that this
works in V86 mode but only in DOS real mode.
Once you load the segment register and then return to real mode, all of
your real mode code can then use the ESI and EDI registers to go past the
end of the 64k block. In real mode the limit it set to 64k.
Ross Ridge
>Well the version HIMEM.SYS I have source for, 2.03, uses INT 15 to
>transfer memory if in protected (ie. V86) mode.
>
>>How does EMM386 handle it?
>
>Maybe it intercepts INT 15.
k...@cgl.citri.edu.au (Kendall Bennett) writes:
>No, EMM386 actually requires an XMS driver to be installed so that it can
>allocate it's extended memory using the XMS interface. Then the memory that
>it has allocated will be compatible with other XMS products. Using this
>allocated XMS memory it then uses the 386's MMU and page tables to emulate
>the EMS interface by mapping the XMS memory into the EMS page frame at
>C000:0000 in memory.
What EMM386 needs to handle is HIMEM.SYS transfering memory to and
from extended memory. It needs to go in to protected mode to do this
but you can't normally go into protected mode if EMM386 is using the
386's MMU, which can only be used in protected or V86 mode, to emulate
EMS (or provide UMB's).
>>So why are you doing this while you're servicing an interrupt?
>I doubt that he would be doing this while _servicing_ the interrupt,..
He said he was doing this while servicing interrupts. Please read the
previous articles in this thread, it should give you a better idea of
what we're talking about.
Ross Ridge
Ross Ridge
>Well the version HIMEM.SYS I have source for, 2.03, uses INT 15 to
>transfer memory if in protected (ie. V86) mode.
pa...@kullmar.se (Peter Andersson) writes:
>Version 3.0 uses an undocumented feature in the 80386 and later.
Well, I don't know if you can really say it's undocumented. It's just
a not very obvious side effect of the segment caches 286+ and later
CPU's use.
>It will enter protected mode, load a segment with the base 0 and
>limit 4GB and return back to real mode. The segment can then be used
>to access 4GB under DOS (until it is reloaded(?)).
HIMEM.SYS 2.03 also does this, but only if the CPU is not in protected
mode. btw. if you look closely you'll probably find that you have the
version of the HIMEM.SYS source as I do. Microsoft distributes the
source for HIMEM.SYS 2.03 with the XMS 3.0 spec.
>Hmm, maybe you're right, I will try to just mask all PIC interrupts while
>it is processing the DOS interrupt.
Why even do this? The only processing you need to do is to redirect
the protected mode interrupt to correct real mode interrupt. Let real
mode code handle the PIC as it should be handling it correctly
already.
Ross Ridge
Peter Andersson
In <1994Jan2.1...@utopia.druid.com> ro...@utopia.druid.com (Ross Ridge) writes:
>pa...@kullmar.se (Peter Andersson) writes:
>>it is processing the DOS interrupt.
>Why even do this? The only processing you need to do is to redirect
>the protected mode interrupt to correct real mode interrupt. Let real
>mode code handle the PIC as it should be handling it correctly
>already.
That wouldn't work! I think I can't handle the V86 mode while I'm using a
VCPI server because of the problems with each INT XXh (stealth) and IOPL.
That is why I can't handle the interrupts myself by using a V86 callgate.
> Ross Ridge
Okey, I give up! Has anybody a VCPI textfile to send me?
Adam Craig Seychell
>In <1994Jan1.1...@utopia.druid.com> ro...@utopia.druid.com (Ross Ridge) writes:
>[some stuff deleted]
>>Well the version HIMEM.SYS I have source for, 2.03, uses INT 15 to
>>transfer memory if in protected (ie. V86) mode.
>Version 3.0 uses an undocumented feature in the 80386 and later. It will
>enter protected mode, load a segment with the base 0 and limit 4GB and
>return back to real mode. The segment can then be used to access 4GB under
>DOS (until it is reloaded(?)).
>>>How does EMM386 handle it?
>>Maybe it intercepts INT 15.
>I will investigate this!
I wrote my own DOS extender which supports TSRs that use XMS
( eg SMARTDRV.EXE , RAMDRIVE.SYS ..)
I found ( after many hours ) that these TSRs call the XMS services
for copying extended memory blocks. The XMS driver then calls
the BIOS int 15h extended memory copy service.
INT 15 AH=87h ,service will switch the 386 form real mode to protected
mode and copy a block of memory.
So I needed to modify my DOS extender to trap any INT 15h when in V86
mode. The extender then reads the registers values and copies the
block. This has worked on all machines I've tried it on and
with HIMEM.SYS versions 2.x and 3.07.
You can find a copy of my DOS extender with complete source on the net
in any SIMTEL directory in /asmutl/dos32v12.zip
[deleted]