home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.os2.programmer
- Path: sparky!uunet!mcsun!Germany.EU.net!news.netmbx.de!zrz.tu-berlin.de!math.fu-berlin.de!informatik.tu-muenchen.de!rommel
- From: rommel@Informatik.TU-Muenchen.DE (Kai-Uwe Rommel)
- Subject: Re: IOPL or Accessing hardware ports
- Keywords: IOPL Ring 2
- References: <4012@news.duke.edu>
- Sender: news@Informatik.TU-Muenchen.DE (USENET Newssystem)
- Organization: Technische Universitaet Muenchen, Germany
- Date: Thu, 23 Jul 1992 18:44:22 GMT
- Message-ID: <1992Jul23.184422.24547@Informatik.TU-Muenchen.DE>
- Lines: 33
-
- In article <4012@news.duke.edu> jan@acpub.duke.edu (Jan Gittelman) writes:
- >Hi,
- >
- >Has anyone managed to use IOPL to access hardware ports? I'm having trouble
- >with it. I get an access violation (SYS3175) whenever the code tries to call
- >a subroutine in the IOPL'd (ring 2) segment.
- >
- >I'm currently using a 16 bit compiler (Microsoft 6.00A) and assembler
- >(Microsoft 5.1). There are 6 assembler subroutines that do the actual
- >i/o and the rest of the code is written in C. I have a .DEF file to define the
- >assembler routines segment as IOPL and list the exported subroutines. In fact,
- >it follows the examples in both Duncan's "Advanced OS/2 Programming" and
- >Steven Mastrianni's "Writing OS2 2.0 Device Drivers in C".
-
- I have used IOPL code in my SCRUTIL screen saver. This is a 16-bit
- program, and I have not yet tried such things in a 32-bit app. You need
- to follow the following steps:
-
- - isolate the code with I/O instructions in one segment (use MS C -NT
- option to give this module a special name instead of _TEXT)
- - mark this segment name as IOPL in the module definition file
- - use the DosPortAccess call before doing actual port I/O
- - set IOPL=YES in config.sys or add the module name to the IOPL list
-
- This is what I did in SCRUTIL and it works under 1.x and 2.0.
-
- Kai Uwe Rommel
-
- /* Kai Uwe Rommel --- rommel@informatik.tu-muenchen.de */
-
- DOS ... is still a real mode only non-reentrant interrupt
- handler, and always will be. -Russell Williams
-
-