SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 331 / gemfst14 / gemfbind.doc < prev next >

Wrap

Text File | 1990-07-20 | 15.5 KB | 313 lines

*************************************************************************** GEMFAST Public Domain GEM bindings by Ian Lepore *************************************************************************** This document provides general background on the GEMFAST bindings system, installation and usage information, and documents some of the internals applicable to the C programmer. --------------------------------------------------------------------------- DOCUMENT CONTENTS --------------------------------------------------------------------------- 1.0 - Packing List 2.0 - Background 3.0 - Functions supported by the bindings 4.0 - Installation and Usage 5.0 - About the GEMFAST.H header file 6.0 - Notes 7.0 - Bugs 8.0 - Support 9.0 - About the (non-existant) copyright --------------------------------------------------------------------------- 1.0 PACKING LIST (xx = version, eg '10' = version 1.0) --------------------------------------------------------------------------- GEMFSTxx.ARC - The runtime system, includes the following... AESFAST.A - The AES bindings library. VDIFAST.A - The VDI bindings library. GEMFAST.H - The C-language header file for use with GEMFAST. GEMF_Vxx.DOC - Version-specific release notes and revision history. GEMUTIL.DOC - Documentation on non-standard utility functions. GEMXTEND.DOC - Documentation on GEM extensions (Atari's and mine). GEMFBIND.DOC - Installation and usage documentation. GEMFSCxx.ARC - Source code for the package. AESSRCxx.ARC - Source code for the AES bindings and utilities. VDISRCxx.ARC - Source code for the VDI bindings. GEMFXMxx.ARC - Example programs. MINICOLR.ARC - Example desk accessory, a mini color pallete control. MEMFIND.ARC - Example dialog-based program, displays free memory. WINDXMPL.ARC - Example of object tree display in a window. GEMFUTxx.ARC - The GEMFAST utilities in C source code format. --------------------------------------------------------------------------- 2.0 BACKGROUND --------------------------------------------------------------------------- These binding libraries were written to address two needs: 1) The world needed a good set of free GEM bindings to complement the various PD C compilers that are available, and 2) The bindings available with most commercial compilers aren't so hot either. These routines have been written to be faster than your typical GEM bindings. As a secondary consideration, I tried to make them smaller as well. When you recompile an application using these libararies, you should notice a drop in program size, and the link phase of the compile should run faster (your mileage may vary). The design goals included using as little bss and data memory as possible (the stack is used for temporary storage as needed), and that references requiring relocation fixup be kept to a minimum. These bindings are known to be compatible with Alcyon C, Sozobon C, and Laser C. They should be compatible with any compiler/linker system which uses 'DRI-standard' object & library file formats. In addition, the C source code version of the utilities should work with any C compiler. There will be support for MWC *someday*, but I will NOT commit to a date. --------------------------------------------------------------------------- 3.0 FUNCTIONS SUPPORTED IN THESE BINDINGS --------------------------------------------------------------------------- The VDIFAST library includes most of the functions documented in the Digital Research publication _GEM Programmer's Guide Vol 1: VDI_. Some of the VDI functions are missing from the VDIFAST library, notably the 'Polaroid Pallete' stuff, the v_cellarray() functions, and similar rarely-used items. The AESFAST library includes all AES functions documented in the DRI publication _GEM Programmer's Guide Vol 2: AES_. Also included are the 'standard' AES utility functions (rc_intersect, etc), and a collection of non-standard utilities of my own. The document file GEMUTIL.DOC describes the utility functions. The AES functions that Atari added beginning with TOS 1.4 are also supported. See GEMXTEND.DOC for more information. (As of GemFast release 1.4, a new calling standard for AES functions has been added. These are documented in GEMXTEND.DOC). The DRI documents cited above are the definitive reference for the standard AES & VDI functions. If you are using other documents (such as Abacus books) there may be some variations between your documents and the libraries. Sorry, I decided it was safer to use the original DRI docs as my source of info. TOS 1.4 functions were built to the specs in the TOS 1.4 developer's release notes, and thus ARE SUBJECT TO CHANGE, depending on what Atari does with the final release of TOS 1.4. --------------------------------------------------------------------------- 4.0 INSTALLATION AND USAGE --------------------------------------------------------------------------- Copy the VDIFAST.A and AESFAST.A files to the drive and path where your linker will look for runtime-library files. (EG: \sozobon\lib). Copy the GEMFAST.H file to the drive and path where your compiler looks for include files (EG: \sozobon\include). If you are using the Atari 'aln' linker, you will need to use aln's DOINDEX program to create .NDX files for each of the libraries. ALWAYS BE SURE TO RE-INDEX THE LIBRARY WHEN YOU INSTALL A NEW VERSION OF THE BINDINGS! To link with the GEMFAST libraries, just enter the library names on the command line for the linker program. For example (using Sozobon): ld -o myprog.prg dstart.o myprog.o dlibs.a vdifast.a aesfast.a or cc -o myprog.prg myprog.c vdifast.a aesfast.a It should not matter where on the command line the names of the GEMFAST libs appear: each library is self-contained, and the linker will not have to resolve references between libraries. No special code is needed in your startup object file; you may continue to use whatever startup file (dstart.o, apstart.o, etc) you currently use. Also, unlike some GEM bindings, you do NOT need to include the VDI bindings libarary if your program uses only AES function calls. (An aside: I've seen a lot of programs that open a VDI workstation, and then use only AES functions within the program. If you use only AES functions, you do NOT need to open a VDI virtual workstation.) --------------------------------------------------------------------------- 5.0 ABOUT THE GEMFAST HEADER FILE --------------------------------------------------------------------------- All VDI and AES functions return an 'int' or are of type 'void' (returning nothing). Given the lack of ST C compilers which support function prototyping, a header file full of 'extern int xxx()' type declarations is a waste of compile time. The GEMFAST.H file contains constants and structures commonly used in GEM programming. If your current bindings system uses OBDEFS.H and GEMDEFS.H, remove the #include statements for those files, and insert #include <gemfast.h> in your source code. While it is possible to continue using your old header files, your code will become less compatible as future versions of GEMFAST are released, as the GEMFAST.H file now contains #defines to redirect some old utility function names to the new names. Also, the GEMFAST.H file contains #define GEMFAST_H 1, and code is gonna hit the PD pretty soon that requires that constant to be set to correctly detect that the GEMFAST bindings are being used. If you have a lot of existing code that #include's OBDEFS and GEMDEFS, you can painlessly upgrade all your program to GEMFAST by creating an empty OBDEFS.H file, and a new GEMDEFS.H file that contains only one line, "#include <GEMFAST.H>"; this will effectively convert all your existing code. The GEMFAST.SH file is included for those brave (foolish?) souls like myself who do GEM programming in assembler. The file is essentially an assembler version of the C file, providing names (constants) for typical GEM things, and defining the standard GEM structures (as offsets). (As of v1.3, the GEMFAST.SH file is contained in the AESFAST source code ARC, not in the normal runtime ARC file). --------------------------------------------------------------------------- 6.0 NOTES --------------------------------------------------------------------------- Stack usage: The AES bindings use 20-50 bytes of stack space during a function call, this should be totally transparent to your application. The VDI bindings use about 50 bytes for most calls, but for the graphics-text calls (v_gtext, etc), the stack usage will be 50 bytes + 2*stringlength. Still, given a maximum likely output string of 128 chars, the stack usage is around 300 bytes to process the call. I typically use a 1k stack, and have never had an overflow. Register usage: A call to any AES, VDI, or utility function will modify registers d0-d2/a0-a1. (as of v1.0: register a2 is not touched by the bindings or utils, to insure Laser C compatibility). All other registers are preserved if used by the binding. VDI variables: The VDI bindings contain no global variable names which can be used by the calling program (other than the function names themselves). This is because there is no fixed storage (data or bss) used by the VDI bindings; each VDI call builds temporary arrays (vdipb, contrl, intin, etc) on the stack at runtime. The implication of this for the C programmer is that you do NOT have to code the contrl, intin, intout, ptsin, or ptsout arrays into your C program. AES variables: The AES bindings define several of the required parameter blocks in BSS storage, since the parm blocks must hold static information between calls. As of GEMFAST v1.2, globally-visible names have been given to the parm blocks, and the variables within them, to allow access from the C source code level. This has been done primarily to give access to the GEM version number, which can be a significant issue now that TOS 1.4 is a reality. The following is the complete list of globally visible variable names: aespb - The AES parmameter block, pointers to the other parameter and control structures. aescontrol - The AES 'control' structure, which holds the counts of items in the other structures, and the AES opcode. global - A name for the whole 'global' array/structure. gl_apversion - The AES version number. gl_apcount - The max # of GEM aps that can be active at once. gl_apid - The application ID. gl_apprivate - A longword of anything the ap wants it to be. gl_aptree - Pointer to the resource rs_trindex array. gl_aprsvd - Array of 4 longwords reserved for future use. (First longword is used by AES as a pointer to the rshdr structure when a resource file is loaded. The word following this pointer is the resource length in bytes.) You can use these in your C code by defining: extern int global[]; /* this is one way. */ extern int gl_apversion, gl_apid, /* etc */ ; /* this is another. */ extern struct { /* yet a third way. */ int gl_apversion, gl_apcount, gl_apid; long gl_apprivate; long *gl_apprtree; RSH *gl_aprsvd; } global; If you use the structure, remember to access vars via global.gl_apid, etc. The data in these global variables is not valid until after the appl_init() call has been made. The TOS 1.4 release notes say that the appl_init() call will place a value of $0130 in global[0] under TOS 1.4. I found that my ROM TOS 1.0 returns a value of $0120, whereas running the beta RAM TOS 1.4 returned $0104. Supervisor mode: It doesn't work. This is not my restriction, it's just an undocumented fact about the ST's implementation of GEM, so I thought I'd mention it. There are workarounds available, by the way. The problem is not in supervisor mode itself, but rather the fact that GEM always saves registers onto the user stack. There are more notes available in the source code modules AES@NOTES and VDI@NOTES, and in the release notes document. Release notes are cumulative, that is, the v1.2 release notes will contain the notes from v1.1. --------------------------------------------------------------------------- 7.0 BUGS --------------------------------------------------------------------------- Undoubtedly there are some...especially in the VDI code and the rarer AES functions. I made no attempt to exhaustively test these libraries, I just recompiled all my old GEM programs (about fifty of them) and made sure they still worked. The common functions (objc_draw, etc) are sure to work. If anybody wants to write verification suites for VDI and AES, I'll be happy to use them to make these bindings bulletproof. Which brings us to... --------------------------------------------------------------------------- 8.0 SUPPORT --------------------------------------------------------------------------- I do intend to support these libraries, and to fix all bugs as soon as they're reported. When reporting a bug, please provide the following info: - A description of the bug/symptoms. - THE VERSION OF GEMFAST YOU ARE USING - this is important! - The source code that leads to the bug (if the program is huge, please just send a suitable code fragment). I can be reached on the STadel network as 'Ian @ FWBBS'. On BIX, my userid is 'ianl'. You can also route bug reports through your normal channel for support on the Sozobon C compiler (on GEnie, CIS, etc), and it will get back to me eventually. To reach me via snail-mail, please address it to: Ian Lepore c/o Computer Avenue 90 S. Wadsworth Blvd. Suite 105-502 Lakewood CO 80226 --------------------------------------------------------------------------- 9.0 ABOUT THE COPYRIGHT --------------------------------------------------------------------------- There is none. At the last minute I changed my mind about this issue, so just ignore any copyright statements that might still exist within the source code modules. You can do anything you want with this code, source or object, but be aware that I'm not going to support umpty-hundred modified versions of these libraries. If you make modifications, please distribute them under a different name (or, send me the mods for inclusion in the next version, then I'll support them). I would like to ask that the entire package by distributed as a whole, with docs included. (Er, that is...don't break down any of the ARC files and distribute the contents separately. I've already broken it down such that the source is a separate piece, etc). ; end of doc