home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / os2 / programm / 8109 < prev    next >
Encoding:
Text File  |  1993-01-28  |  2.1 KB  |  50 lines
  1. Newsgroups: comp.os.os2.programmer
  2. Path: sparky!uunet!spool.mu.edu!caen!batcomputer!lynx@msc.cornell.edu!tommy
  3. From: tommy@lynx.msc.cornell.edu.UUCP (Mike Thompson,332,54714,2734927)
  4. Subject: Re: Memory access
  5. Message-ID: <1993Jan28.222022.4702@msc.cornell.edu>
  6. Originator: tommy@snoopy.msc.cornell.edu
  7. Sender: news@msc.cornell.edu
  8. Organization: Cornell-Materials-Science-Center
  9. References: <13903@icarus>
  10. Date: Thu, 28 Jan 1993 22:20:22 GMT
  11. Lines: 37
  12.  
  13. From article <13903@icarus>, by rickr@Semi.Mitel.COM (Rick Reitmaier):
  14. > In article <C0z6r0.KGK@bunyip.cc.uq.oz.au> walker@s1.elec.uq.oz.au (Steven Walker) writes:
  15. >>I have to write code that accesses memory mapped dual port RAM 
  16. >>on a board connected to an AT bus. Any suggestions on how to do 
  17. >>this in OS/2?
  18. >>Do I need a device driver to allocate and lock the physical memory?
  19. >>Or can I use IOPL levels to access it directly?
  20. >>Thanks for any tips,
  21.  
  22. Well, this is your lucky day.  A month ago, I asked a similar question and
  23. received enough information to write a generic device driver that I call
  24. labhelp.sys.  You add it to your config.sys, and it implements a device
  25. that lets any Ring 3 program access any physical block of memory, 
  26. unprotected.  
  27.  
  28. This is clearly a form of unsafe sex.  It bypasses all OS/2 memory
  29. protection and grants ANY protected mode application access to ANY 
  30. physical block of memory.  I am using it currently for accessing memory
  31. mapped A/D converters, and a memory mapped frame buffer.
  32.  
  33. The driver has been used under both CSET/2 programming and MSC 6.0.
  34.  
  35. I will make it available for anonymous FTP from 128.84.249.11
  36. (lore.msc.cornell.edu).  Feel free to modify or use as you desire.
  37. (I will make a LABHELP.ZIP file and hang it there tonight.)
  38.  
  39. > I don't know if or how it will work, but I would caution against building
  40. > a device driver, as it's a grueling example of how evil an operating system
  41. > can be to a programer.
  42.  
  43. But elegant once it is done!  In the end, it was quite simple.  Most of the
  44. intelligence was put in the user shell running protected.
  45. -- 
  46. Michael O. Thompson            tommy@msc.cornell.edu
  47. Cornell University             (607) 255-4714
  48.  
  49. OS/2:  For the few, the proud, the devoted!
  50.