home *** CD-ROM | disk | FTP | other *** search
/ Virtual Reality Zone / VRZONE.ISO / mac / PC / PCGLOVE / GLOVE / OBJGLV.ZIP / DOC / MEMMODEL.DOC < prev    next >
Text File  |  1992-09-25  |  5KB  |  99 lines
  1.  
  2.                      REND386 DRIVERS AND MEMORY MODELS
  3.                   Written by Dave Stampe, September 1992
  4.  
  5. Since drivers are loaded at run time and do not support relocation, their
  6. data and code segments must be in the same physical segment. This requires
  7. some assembly interface code to reset the data segment.
  8.  
  9. However, the stack will not be in the same segment as the data and
  10. code, since the program's runtime stack is used.  This means that the
  11. usual tiny memory model cannot be used.  Some C compilers support a
  12. varient of the tiny memory model, where SS=DS is not assumed.  But
  13. unfortunately the Borland C tiny mode libraries do not conform to this.
  14.  
  15. So the options are: use tiny model C compilation and no libraries, or
  16. assembly language with .MODEL TINY FARSTACK at the file start.  This is
  17. the way BGI files must be built (although the documentation doesn't say
  18. so).
  19.  
  20. There is a third way that will let the tiny (small mode for Borland C)
  21. libraries be used.  This is to switch to a stack inside the driver.
  22. There is a risk, however.  Since the stack is reset at each entry into
  23. the driver, the code cannot be reentrant.  If one of the functions of the
  24. video driver, for example, is called via an interrupt routine while
  25. another driver routine is being executed, the stack contents of the original
  26. routine will be trashed.
  27.  
  28. The method I chose is to use the program stack for all routines that may be
  29. called from an interrupt routine, and use an internal driver stack for all
  30. others.  The interrupt-processing routines must then either not use any
  31. C library calls or must be written in assembler.  The interrupt-processing
  32. routines include vsync(), set_vpage(), and VGA_select() in the video driver,
  33. any interrupt service routines in pointer drivers, and the entire switcher
  34. driver.
  35.  
  36.  
  37. CREATING DRIVERS
  38.  
  39. You may find it easiest to create a driver from within REND386 for debugging
  40. purposes.  For video drivers, comment out the video driver loading
  41. code in the initialization, and replace the VDRINTE.ASM module with the
  42. modules containing the actual video driver code.  For pointer and switcher
  43. drivers, add a special test to the driver load/initialize call to link to
  44. your code-- examine the internal mouse and PowerGlove drivers to see how
  45. this is done.
  46.  
  47. Once your code is working, you should restore the REND386 code to its
  48. original state and group all your needed modules together.  Make sure that
  49. all your C code will work in the TINY model, and that it will be FAR
  50. callable-- that is, add the "far" keyword to all functions.  Also, add
  51. "far" to all pointers passed to and from driver calls, so that the LARGE
  52. model REND386 code can talk to your driver.  Change all assembly modules
  53. to .MODEL TINY FARSTACK, and declare all procedures as FAR.
  54.  
  55. An assembly header file (supplied in the kit) sets a standard interface
  56. and supplies entry/exit from the driver environment, switching SS and DS.
  57. There are 3 headers available for drivers.  The video driver header has
  58. a jump table and a 2000 byte stack.  There is a reentrant and nonreentrant
  59. (with 2000 byte stack) header file available for driver programs as well.
  60. Reentrant and nonreentrant entry for the video driver is performed in
  61. the VDRINTE.ASM module of REND386, while pointer/switcher driver entry code
  62. is in the header itself.
  63.  
  64. Use one of the sample batch files as a template for your driver compilation.
  65. The steps are to compile all C code (note the options and use them!)
  66. They are -c -mt -N- -k- -f- for no link, tiny, and no stack.
  67. Assemble the assembly modules, link to an .EXE file with any required C
  68. libraries (you may need to change the path here) with no stack.  Then
  69. use EXE2BIN to comvert the .EXE file to a binary driver file.
  70.  
  71. WARNING: IF YOU SEE "FIXUP REQUIRED" WHILE RUNNING EXE2BIN, YOUR DRIVER
  72. WILL NOT WORK.
  73.  
  74. The REND386 standard driver extensions are:
  75.  
  76. .RVD: REND386 video driver
  77. .RPD: REND386 pointer device
  78. .RSD: REND386 switching device
  79. .RHD: REND386 head tracking device.
  80.  
  81. Note that only the first 2 are used now: the .RHD is optional, as any
  82. pointing device may be used as a head tracking device.
  83.  
  84. To debug your driver, I suggest Turbo Debugger 386, which will let
  85. REND386 load and run (you'll need extended memory for this).  You should
  86. set breakpoints (or Run Until..) at the actual call to a driver function,
  87. then switch to the CPU window and step into the driver.  Watch for stuff
  88. like improper pointer conversions, return of near pointers, etc.  If the
  89. code runs OK until you turn on the Sega glasses, you probably should
  90. check for interrupt calls to non-reentrant driver or video driver functions.
  91. Of course, any interrupt functions in your code are FARSTACK (SS != DS)
  92. so should not use C library calls or should be written in assembler if
  93. your compiler doesn't support this mode of compilation.
  94.  
  95. If you're doing anything weird, or having trouble with creating drivers,
  96. contact Dave stampe (dstampe@psych.toronto.edu) for help.  I can't fix
  97. everything, but I may be able to give you pointers on what to do.
  98. Good Luck!
  99.