home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / alt / msdos / programm / 2298 < prev    next >
Encoding:
Text File  |  1992-09-01  |  1.4 KB  |  33 lines
  1. Newsgroups: alt.msdos.programmer
  2. Path: sparky!uunet!stanford.edu!rock!taco!dspascha
  3. From: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
  4. Subject: Re: Trapping 386 IO port accesses
  5. Message-ID: <1992Sep1.143350.10587@ncsu.edu>
  6. Originator: dspascha@c00075-100lez.eos.ncsu.edu
  7. Lines: 18
  8. Sender: news@ncsu.edu (USENET News System)
  9. Reply-To: dspascha@eos.ncsu.edu (DAVID SCOTT PASCHAL)
  10. Organization: North Carolina State University, Project Eos
  11. References:  <1992Aug31.191659.672@Schultz.ON.CA>
  12. Distribution: na
  13. Date: Tue, 1 Sep 1992 14:33:50 GMT
  14.  
  15.  
  16. Hi.  The 386 and better can be set up to generate a general protection fault
  17. when a process does an IN or OUT to a specific I/O port based on an I/O
  18. permission bitmap in the Task State Segment, but this only works in protected
  19. mode where there are TSS's, not in real mode in which MS-DOS operates.  I
  20. guess you could write a little (not!) DOS extender that runs DOS in V86 mode
  21. (which is really a real mode process running within protected mode which is how
  22. Windows multitasks DOS applications in 386-Enhanced mode), but this would be
  23. extremely difficult to design properly to handle BIOS interrupts and DMA.
  24.  
  25. Simulating interrupts would be pretty easy to do in real mode -- in your
  26. "custom" interrupt handler, just call any interrupt handler you want.
  27.  
  28. Since this is your "own custom hardware", why don't you just simulate these I/O
  29. ports in your adapter?
  30.  
  31. Tschuess,
  32. David Paschal
  33.