home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / msdos / programm / 10431 < prev    next >
Encoding:
Internet Message Format  |  1992-11-09  |  4.9 KB

  1. Path: sparky!uunet!sun-barr!sh.wide!wnoc-kyo!icspub!oskgate0.mei!chorus.mei!saturn.mew!srl!gah
  2. From: gah@trc.mew.mei.co.jp (Gary A. Hildebrand)
  3. Newsgroups: comp.os.msdos.programmer
  4. Subject: Re: Protected Mode Interrupts
  5. Message-ID: <GAH.92Nov9190759@HP370T.trc.mew.mei.co.jp>
  6. Date: 9 Nov 92 10:07:59 GMT
  7. References: <1992Oct29.075500.15529@cis.ohio-state.edu>
  8. Sender: usenet@srl.mew.mei.co.jp (USENet News Admin)
  9. Organization: Matsushita Electric Works Ltd., Tokyo, Japan.
  10. Lines: 71
  11. In-Reply-To: madia@gecko.cis.ohio-state.edu's message of 29 Oct 92 07:55:00 GMT
  12.  
  13. In article <1992Oct29.075500.15529@cis.ohio-state.edu> madia@gecko.cis.ohio-state.edu (joseph anthony madia) writes:
  14. >>       I have a question involving Protected mode for 386/486 (no 286)
  15. >>programming. The scenario is as follows:  The program is a normal DOS
  16. >>executable that is designed to take COMPLETE control of the pc. (ie it has
  17. >>no intention of returning to dos once it is running). This program sets up
  18. >>a simple protected mode 32-bit operating environment solely for the purpose
  19. >>of experiment with the full power of the 386/486. I have a question about
  20. >>handling hardware IRQs in this environment. 
  21. >>       BIOS originally sets the hardware IRQs 0 -7 to use INTs 8 - 15, and 
  22. >>IRQs 8 - 15 to use INTs 70h - 77h. The IRQ 0 - 7 assignments cause confilcts 
  23. >>with the reserved exception INTs (ie INT 8 is reserved by Intel for Double 
  24. >>Fault exceptions, and is also set by BIOS to receive IRQ0 hardware interrupts)
  25. >>       How should this be handled? Is there anything that needs handling, or
  26. >>am I missing something in this picture. Do the IRQs have to be re-mapped to 
  27. >>different INTs that aren't reserved by Intel (map IRQs 0-7 to INTs 32-30)?
  28. >>If I do have to remap the IRQs, then how do I do so in the 386 environment.
  29. >>I have seen the BIOS source for an AT that does the original IRQ to INT 
  30. >>mapping, and how to accomplish this, but its written for a 286 AT and Im 
  31. >>not sure if that will work on this machine. (PS/2 model 70 386). 
  32. >>       Any help regarding this, or Protected mode programming in general 
  33. >>would be appreciated. Unfortunately, most of the information that I have
  34. >>found on Protected mode has few, if any examples. Thanks in advance...
  35. >>
  36. >>Joe Madia                       madia@cis.ohio-state.edu
  37.  
  38. I am always amazed at how timely netnews can be.  I was just about to post
  39. about this topic, when 'lo and behold, someone already did!
  40.  
  41. This problem of interrupt-mapping seems to not be limited to just pure
  42. protected mode.  If you read the Compatibility sections of the Intel 386DX
  43. and 486 Programmer's Reference Manuals, you will find that exceptions 8
  44. (Double Fault), 12 (Stack Exception), and 13 (Segment Overrun) are just
  45. three of the 386/486-specific exceptions that can occur *even* in
  46. Real-address Mode.  These three exceptions in particular conflict with the
  47. default 8259A mapping which must be performed by just about every PC clone.
  48. And in Real-address Mode, no exception error code is returned anyway!
  49.  
  50. So the obvious question is, could this mapping conflict be the cause of a
  51. number of system crashes people observe on today's 386 or higher clones?
  52. Since most real-mode software is completely ignorant of which CPU it's
  53. executing on, and things like a stack or segment overflow are fairly common
  54. occurences, it would seem that more things would break on a 386 or higher
  55. machine.  In virtual-86 mode, this should also be a problem, but more
  56. controllable because of the presence of a virtual-86 monitor and the return
  57. of exception error codes to help distinguish exceptions from bonafide
  58. interrupts (the famous QEMM Exception Error #13 comes to mind right now
  59. :-).
  60.  
  61. On a related note, I see a lot of references in memory management
  62. documentation about enabling/disabling the A20 address line, and I've heard
  63. about programming the 8042 bus controller to do this.  Is this operation
  64. non-standard, i.e. different from machine to machine, and in what
  65. literature would it be documented?  Also, is it necessary to manually
  66. enable A20 even in Protected Mode, or is this only done in Real-address
  67. Mode to take advantage of the extra 64KB at 1MB on 286 or higher machines?
  68.  
  69. Finally, can one expect a V86 EMS memory manager (such as QEMM, EMM386,
  70. CEMM, etc.) to faithfully virtualize attempts to directly read the CR0 and
  71. CR3 registers?  Reading these registers when one of these managers is
  72. loaded will always cause an exception because the CPU is in virtual-86
  73. mode, however it seems what is returned as the "virtual" CR0/CR3 value
  74. varies, and is certainly not what is actually stored in the register (the
  75. V86 bit will be turned off, for example).  With one manager, I found that
  76. the machine would die when an attempt was made to read these registers!
  77.  
  78. Gary Hildebrand
  79. --
  80. / Gary A. Hildebrand                 Internet: gah@mew.mei.co.jp       \
  81. /  Matsushita Electric Works, Ltd.   UUCP:     uunet!mew.mei.co.jp!gah \
  82. /   13-2, Mita 5-chome, Minato-ku    Fax:      03-3451-0793            \
  83. /    Tokyo 108, JAPAN                Tel:      03-3452-4941            \
  84.