🚀 go-pugleaf

In article <1992Oct29.075500.15529@cis.ohio-state.edu> madia@gecko.cis.ohio-state.edu (joseph anthony madia) writes:
>>	   I have a question involving Protected mode for 386/486 (no 286)
>>programming. The scenario is as follows:  The program is a normal DOS
>>executable that is designed to take COMPLETE control of the pc. (ie it has
>>no intention of returning to dos once it is running). This program sets up
>>a simple protected mode 32-bit operating environment solely for the purpose
>>of experiment with the full power of the 386/486. I have a question about
>>handling hardware IRQs in this environment. 
>>	   BIOS originally sets the hardware IRQs 0 -7 to use INTs 8 - 15, and 
>>IRQs 8 - 15 to use INTs 70h - 77h. The IRQ 0 - 7 assignments cause confilcts 
>>with the reserved exception INTs (ie INT 8 is reserved by Intel for Double 
>>Fault exceptions, and is also set by BIOS to receive IRQ0 hardware interrupts)
>>	   How should this be handled? Is there anything that needs handling, or
>>am I missing something in this picture. Do the IRQs have to be re-mapped to 
>>different INTs that aren't reserved by Intel (map IRQs 0-7 to INTs 32-30)?
>>If I do have to remap the IRQs, then how do I do so in the 386 environment.
>>I have seen the BIOS source for an AT that does the original IRQ to INT 
>>mapping, and how to accomplish this, but its written for a 286 AT and Im 
>>not sure if that will work on this machine. (PS/2 model 70 386). 
>>	   Any help regarding this, or Protected mode programming in general 
>>would be appreciated. Unfortunately, most of the information that I have
>>found on Protected mode has few, if any examples. Thanks in advance...
>>
>>Joe Madia				       madia@cis.ohio-state.edu

I am always amazed at how timely netnews can be.  I was just about to post
about this topic, when 'lo and behold, someone already did!

This problem of interrupt-mapping seems to not be limited to just pure
protected mode.  If you read the Compatibility sections of the Intel 386DX
and 486 Programmer's Reference Manuals, you will find that exceptions 8
(Double Fault), 12 (Stack Exception), and 13 (Segment Overrun) are just
three of the 386/486-specific exceptions that can occur *even* in
Real-address Mode.  These three exceptions in particular conflict with the
default 8259A mapping which must be performed by just about every PC clone.
And in Real-address Mode, no exception error code is returned anyway!

So the obvious question is, could this mapping conflict be the cause of a
number of system crashes people observe on today's 386 or higher clones?
Since most real-mode software is completely ignorant of which CPU it's
executing on, and things like a stack or segment overflow are fairly common
occurences, it would seem that more things would break on a 386 or higher
machine.  In virtual-86 mode, this should also be a problem, but more
controllable because of the presence of a virtual-86 monitor and the return
of exception error codes to help distinguish exceptions from bonafide
interrupts (the famous QEMM Exception Error #13 comes to mind right now
:-).

On a related note, I see a lot of references in memory management
documentation about enabling/disabling the A20 address line, and I've heard
about programming the 8042 bus controller to do this.  Is this operation
non-standard, i.e. different from machine to machine, and in what
literature would it be documented?  Also, is it necessary to manually
enable A20 even in Protected Mode, or is this only done in Real-address
Mode to take advantage of the extra 64KB at 1MB on 286 or higher machines?

Finally, can one expect a V86 EMS memory manager (such as QEMM, EMM386,
CEMM, etc.) to faithfully virtualize attempts to directly read the CR0 and
CR3 registers?  Reading these registers when one of these managers is
loaded will always cause an exception because the CPU is in virtual-86
mode, however it seems what is returned as the "virtual" CR0/CR3 value
varies, and is certainly not what is actually stored in the register (the
V86 bit will be turned off, for example).  With one manager, I found that
the machine would die when an attempt was made to read these registers!

Gary Hildebrand
--
/ Gary A. Hildebrand                 Internet: gah@mew.mei.co.jp       \
/  Matsushita Electric Works, Ltd.   UUCP:     uunet!mew.mei.co.jp!gah \
/   13-2, Mita 5-chome, Minato-ku    Fax:      03-3451-0793            \
/    Tokyo 108, JAPAN                Tel:      03-3452-4941            \