home *** CD-ROM | disk | FTP | other *** search
/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / utility / gemfst15 / gemfbind.doc < prev    next >
Encoding:
Text File  |  1990-06-29  |  15.5 KB  |  313 lines
  1.  
  2. ***************************************************************************
  3.                                 GEMFAST
  4.                        Public Domain GEM bindings
  5.                               by Ian Lepore
  6. ***************************************************************************
  7.  
  8. This document provides general background on the GEMFAST bindings system,
  9. installation and usage information, and documents some of the internals 
  10. applicable to the C programmer.
  11.  
  12. ---------------------------------------------------------------------------
  13.                             DOCUMENT CONTENTS
  14. ---------------------------------------------------------------------------
  15.  
  16.  1.0  -  Packing List
  17.  2.0  -  Background
  18.  3.0  -  Functions supported by the bindings
  19.  4.0  -  Installation and Usage
  20.  5.0  -  About the GEMFAST.H header file
  21.  6.0  -  Notes
  22.  7.0  -  Bugs
  23.  8.0  -  Support
  24.  9.0  -  About the (non-existant) copyright
  25.  
  26. ---------------------------------------------------------------------------
  27.  1.0                          PACKING LIST 
  28.                  (xx = version, eg '10' = version 1.0)
  29. ---------------------------------------------------------------------------
  30.  
  31.      GEMFSTxx.ARC     - The runtime system, includes the following...
  32.         AESFAST.A     - The AES bindings library.
  33.         VDIFAST.A     - The VDI bindings library.
  34.         GEMFAST.H     - The C-language header file for use with GEMFAST.
  35.         GEMF_Vxx.DOC  - Version-specific release notes and revision history.
  36.         GEMUTIL.DOC   - Documentation on non-standard utility functions.
  37.         GEMXTEND.DOC  - Documentation on GEM extensions (Atari's and mine).
  38.         GEMFBIND.DOC  - Installation and usage documentation.
  39.  
  40.      GEMFSCxx.ARC    - Source code for the package.  
  41.         AESSRCxx.ARC - Source code for the AES bindings and utilities.
  42.         VDISRCxx.ARC - Source code for the VDI bindings.
  43.  
  44.      GEMFXMxx.ARC    - Example programs.
  45.         MINICOLR.ARC - Example desk accessory, a mini color pallete control.
  46.         MEMFIND.ARC  - Example dialog-based program, displays free memory.
  47.         WINDXMPL.ARC - Example of object tree display in a window.
  48.         
  49.      GEMFUTxx.ARC    - The GEMFAST utilities in C source code format.
  50.      
  51. ---------------------------------------------------------------------------
  52. 2.0                            BACKGROUND
  53. ---------------------------------------------------------------------------
  54.  
  55. These binding libraries were written to address two needs: 1) The world 
  56. needed a good set of free GEM bindings to complement the various PD C
  57. compilers that are available, and 2) The bindings available with most 
  58. commercial compilers aren't so hot either.
  59.  
  60. These routines have been written to be faster than your typical GEM 
  61. bindings.  As a secondary consideration, I tried to make them smaller as 
  62. well.  When you recompile an application using these libararies, you 
  63. should notice a drop in program size, and the link phase of the compile 
  64. should run faster (your mileage may vary).  The design goals included 
  65. using as little bss and data memory as possible (the stack is used for
  66. temporary storage as needed), and that references requiring relocation 
  67. fixup be kept to a minimum.
  68.  
  69. These bindings are known to be compatible with Alcyon C, Sozobon C, and 
  70. Laser C.  They should be compatible with any compiler/linker system 
  71. which uses 'DRI-standard' object & library file formats.  In addition,
  72. the C source code version of the utilities should work with any C compiler.
  73. There will be support for MWC *someday*, but I will NOT commit to a date.
  74.  
  75. ---------------------------------------------------------------------------
  76. 3.0               FUNCTIONS SUPPORTED IN THESE BINDINGS
  77. ---------------------------------------------------------------------------
  78.  
  79. The VDIFAST library includes most of the functions documented in the 
  80. Digital Research publication _GEM Programmer's Guide Vol 1: VDI_.  Some 
  81. of the VDI functions are missing from the VDIFAST library, 
  82. notably the 'Polaroid Pallete' stuff, the v_cellarray() functions, and 
  83. similar rarely-used items.
  84.  
  85. The AESFAST library includes all AES functions documented in the DRI 
  86. publication _GEM Programmer's Guide Vol 2: AES_.  Also included are the 
  87. 'standard' AES utility functions (rc_intersect, etc), and a collection 
  88. of non-standard utilities of my own.  The document file GEMUTIL.DOC 
  89. describes the utility functions.  The AES functions that Atari added 
  90. beginning with TOS 1.4 are also supported.  See GEMXTEND.DOC for more
  91. information.  (As of GemFast release 1.4, a new calling standard for AES
  92. functions has been added.  These are documented in GEMXTEND.DOC).
  93.  
  94. The DRI documents cited above are the definitive reference for the 
  95. standard AES & VDI functions.  If you are using other documents (such as 
  96. Abacus books) there may be some variations between your documents and 
  97. the libraries.  Sorry, I decided it was safer to use the original DRI 
  98. docs as my source of info.  TOS 1.4 functions were built to the
  99. specs in the TOS 1.4 developer's release notes, and thus ARE SUBJECT TO
  100. CHANGE, depending on what Atari does with the final release of TOS 1.4.
  101.  
  102. ---------------------------------------------------------------------------
  103. 4.0                       INSTALLATION AND USAGE
  104. ---------------------------------------------------------------------------
  105.  
  106. Copy the VDIFAST.A and AESFAST.A files to the drive and path where your 
  107. linker will look for runtime-library files.  (EG:  \sozobon\lib). Copy 
  108. the GEMFAST.H file to the drive and path where your compiler looks for 
  109. include files (EG: \sozobon\include).
  110.  
  111. If you are using the Atari 'aln' linker, you will need to use aln's 
  112. DOINDEX program to create .NDX files for each of the libraries.  ALWAYS
  113. BE SURE TO RE-INDEX THE LIBRARY WHEN YOU INSTALL A NEW VERSION OF THE
  114. BINDINGS!
  115.  
  116. To link with the GEMFAST libraries, just enter the library names on the 
  117. command line for the linker program.  For example (using Sozobon):
  118.  
  119.   ld -o myprog.prg dstart.o myprog.o dlibs.a vdifast.a aesfast.a
  120.                          or
  121.   cc -o myprog.prg myprog.c vdifast.a aesfast.a
  122.  
  123. It should not matter where on the command line the names of the GEMFAST 
  124. libs appear:  each library is self-contained, and the linker will not 
  125. have to resolve references between libraries.  No special code is needed 
  126. in your startup object file; you may continue to use whatever startup file
  127. (dstart.o, apstart.o, etc) you currently use.  Also, unlike some GEM 
  128. bindings, you do NOT need to include the VDI bindings libarary if your 
  129. program uses only AES function calls.
  130.  
  131. (An aside:  I've seen a lot of programs that open a VDI workstation, and 
  132. then use only AES functions within the program.  If you use only AES 
  133. functions, you do NOT need to open a VDI virtual workstation.)
  134.  
  135. ---------------------------------------------------------------------------
  136. 5.0                   ABOUT THE GEMFAST HEADER FILE
  137. ---------------------------------------------------------------------------
  138.  
  139. All VDI and AES functions return an 'int' or are of type 'void' 
  140. (returning nothing).  Given the lack of ST C compilers which support 
  141. function prototyping, a header file full of 'extern int xxx()' type 
  142. declarations is a waste of compile time.  The GEMFAST.H file contains 
  143. constants and structures commonly used in GEM programming.
  144.  
  145. If your current bindings system uses OBDEFS.H and GEMDEFS.H, remove the
  146. #include statements for those files, and insert #include <gemfast.h> in
  147. your source code.  While it is possible to continue using your old header
  148. files, your code will become less compatible as future versions of GEMFAST
  149. are released, as the GEMFAST.H file now contains #defines to redirect some
  150. old utility function names to the new names.  Also, the GEMFAST.H file
  151. contains #define GEMFAST_H 1, and code is gonna hit the PD pretty soon that
  152. requires that constant to be set to correctly detect that the GEMFAST
  153. bindings are being used.
  154.  
  155. If you have a lot of existing code that #include's OBDEFS and GEMDEFS, you
  156. can painlessly upgrade all your program to GEMFAST by creating an empty
  157. OBDEFS.H file, and a new GEMDEFS.H file that contains only one line,
  158. "#include <GEMFAST.H>"; this will effectively convert all your existing code.
  159.  
  160. The GEMFAST.SH file is included for those brave (foolish?) souls like 
  161. myself who do GEM programming in assembler.  The file is essentially an 
  162. assembler version of the C file, providing names (constants) for typical 
  163. GEM things, and defining the standard GEM structures (as offsets). (As of
  164. v1.3, the GEMFAST.SH file is contained in the AESFAST source code ARC, not
  165. in the normal runtime ARC file).
  166.  
  167. ---------------------------------------------------------------------------
  168. 6.0                               NOTES
  169. ---------------------------------------------------------------------------
  170.  
  171. Stack usage:  The AES bindings use 20-50 bytes of stack space during a 
  172. function call, this should be totally transparent to your application.  
  173. The VDI bindings use about 50 bytes for most calls, but for the 
  174. graphics-text calls (v_gtext, etc), the stack usage will be 50 bytes + 
  175. 2*stringlength.  Still, given a maximum likely output string of 128 
  176. chars, the stack usage is around 300 bytes to process the call.  I 
  177. typically use a 1k stack, and have never had an overflow.
  178.  
  179. Register usage:  A call to any AES, VDI, or utility function will modify 
  180. registers d0-d2/a0-a1.  (as of v1.0:  register a2 is not touched by the 
  181. bindings or utils, to insure Laser C compatibility).  All other registers 
  182. are preserved if used by the binding.
  183.  
  184. VDI variables:  
  185.  
  186. The VDI bindings contain no global variable names which 
  187. can be used by the calling program (other than the function names 
  188. themselves).  This is because there is no fixed storage (data or bss) 
  189. used by the VDI bindings; each VDI call builds temporary arrays (vdipb, 
  190. contrl, intin, etc) on the stack at runtime.  The implication of this for
  191. the C programmer is that you do NOT have to code the contrl, intin, intout,
  192. ptsin, or ptsout arrays into your C program.
  193.  
  194. AES variables:  
  195.  
  196. The AES bindings define several of the required parameter blocks in BSS
  197. storage, since the parm blocks must hold static information between calls.
  198. As of GEMFAST v1.2, globally-visible names have been given to the parm
  199. blocks, and the variables within them, to allow access from the C source
  200. code level.  This has been done primarily to give access to the GEM version
  201. number, which can be a significant issue now that TOS 1.4 is a reality.
  202.  
  203. The following is the complete list of globally visible variable names:
  204.  
  205.     aespb          - The AES parmameter block, pointers to the other 
  206.                      parameter and control structures.   
  207.     aescontrol     - The AES 'control' structure, which holds the counts
  208.                      of items in the other structures, and the AES opcode.
  209.     global         - A name for the whole 'global' array/structure.
  210.     gl_apversion   - The AES version number.
  211.     gl_apcount     - The max # of GEM aps that can be active at once.
  212.     gl_apid        - The application ID.
  213.     gl_apprivate   - A longword of anything the ap wants it to be.
  214.     gl_aptree      - Pointer to the resource rs_trindex array.
  215.     gl_aprsvd      - Array of 4 longwords reserved for future use.
  216.                      (First longword is used by AES as a pointer to the
  217.                      rshdr structure when a resource file is loaded.  The
  218.                      word following this pointer is the resource length
  219.                      in bytes.)
  220.     
  221. You can use these in your C code by defining:
  222.    
  223.    extern int global[];                           /* this is one way. */
  224.    
  225.    extern int gl_apversion, gl_apid, /* etc */ ;  /* this is another. */
  226.    
  227.    extern struct {                                /* yet a third way. */
  228.      int  gl_apversion, 
  229.           gl_apcount, 
  230.           gl_apid;
  231.      long gl_apprivate;                     
  232.      long *gl_apprtree;
  233.      RSH  *gl_aprsvd;                       
  234.      } global;                              
  235.      
  236. If you use the structure, remember to access vars via global.gl_apid, etc.
  237.   
  238. The data in these global variables is not valid until after the 
  239. appl_init() call has been made.
  240.  
  241. The TOS 1.4 release notes say that the appl_init() call will place a
  242. value of $0130 in global[0] under TOS 1.4.  I found that my ROM TOS 1.0
  243. returns a value of $0120, whereas running the beta RAM TOS 1.4 returned
  244. $0104.  
  245.  
  246. Supervisor mode:  It doesn't work.  This is not my restriction, it's 
  247. just an undocumented fact about the ST's implementation of GEM, so I 
  248. thought I'd mention it.  There are workarounds available, by the way.  
  249. The problem is not in supervisor mode itself, but rather the fact that 
  250. GEM always saves registers onto the user stack.
  251.  
  252. There are more notes available in the source code modules AES@NOTES and 
  253. VDI@NOTES, and in the release notes document.  Release notes are cumulative,
  254. that is, the v1.2 release notes will contain the notes from v1.1.
  255.  
  256. ---------------------------------------------------------------------------
  257. 7.0                                BUGS
  258. ---------------------------------------------------------------------------
  259.  
  260. Undoubtedly there are some...especially in the VDI code and the rarer 
  261. AES functions.  I made no attempt to exhaustively test these libraries, 
  262. I just recompiled all my old GEM programs (about fifty of them) and 
  263. made sure they still worked.  The common functions (objc_draw, etc) are 
  264. sure to work.  If anybody wants to write verification suites for VDI and 
  265. AES, I'll be happy to use them to make these bindings bulletproof. Which 
  266. brings us to...
  267.  
  268. ---------------------------------------------------------------------------
  269. 8.0                              SUPPORT
  270. ---------------------------------------------------------------------------
  271.  
  272. I do intend to support these libraries, and to fix all bugs as soon as 
  273. they're reported.  When reporting a bug, please provide the following 
  274. info:
  275.  
  276.      - A description of the bug/symptoms.
  277.      - THE VERSION OF GEMFAST YOU ARE USING - this is important!
  278.      - The source code that leads to the bug (if the program is huge, 
  279.        please just send a suitable code fragment).
  280.  
  281. I can be reached on the STadel network as 'Ian @ FWBBS'.
  282. On BIX, my userid is 'ianl'.  
  283.  
  284. You can also route bug reports through your normal channel for support 
  285. on the Sozobon C compiler (on GEnie, CIS, etc), and it will get back to 
  286. me eventually.  To reach me via snail-mail, please address it to:
  287.  
  288.      Ian Lepore
  289.      6762 Marshall St.
  290.      Arvada CO   80003-4030
  291.      
  292. ---------------------------------------------------------------------------
  293. 9.0                        ABOUT THE COPYRIGHT
  294. ---------------------------------------------------------------------------
  295.  
  296. There is none.  At the last minute I changed my mind about this issue, 
  297. so just ignore any copyright statements that might still exist within 
  298. the source code modules.  
  299.  
  300. You can do anything you want with this code, source or object, but be 
  301. aware that I'm not going to support umpty-hundred modified versions of 
  302. these libraries.  If you make modifications, please distribute them 
  303. under a different name (or, send me the mods for inclusion in the next 
  304. version, then I'll support them).  
  305.  
  306. I would like to ask that the entire package by distributed as a whole, 
  307. with docs included.  (Er, that is...don't break down any of the ARC files
  308. and distribute the contents separately.  I've already broken it down such
  309. that the source is a separate piece, etc).
  310.  
  311. ; end of doc
  312.  
  313.