GEOSLib docs

Maciej Witkowiak

2014-04-11
This is the documentation of cc65's GEOSLib, but information contained here may be also useful for writing GEOS applications in general.

1. Introduction

2. What do you have and what to do with it?

3. Library Functions

4. Library Structures


1. Introduction

As we all know that the best computers in the world are the C64 and C128. They have their GUI too - the excellent GEOS. GEOS seems very difficult and cryptic for many people, from programmer's point of view. That's not true. The designers of GEOS created a flexible and powerful system, which is easy to use and program.

Coding GEOS in C? That's something new. It is possible now - with Ulrich von Bassewitz's cc65 package and my GEOSLib you are able to create GEOS applications in no time.

GEOSLib supports a subset of the standard cc65 libraries. Whenever possible native Kernal functions are used (e.g. memset is an alias for FillRam), however not all are supported. E.g. string functions like strcmp, strcpy are doubled with native CmpString, CopyString because the latter can handle only 256 byte strings. Keep this in mind when you write your program. If you don't need long strings simply use functions from the Kernal, the resulting code will be smaller.

dio - direct disk access is available, but you might have problems with devices other than 1541, 1571 or 1581. RAM drives emulating these should work.

conio - simple console input-output is available for command line applications. This implementation assumes that one character does fit in 8x8 cell, so output with default BSW font, which is has 9 points, might be a bit messy. There is no color support in GEOS 2.0 so color functions are disabled. Both 40 and 80 column modes are supported and automatically detected.

tgi - TGI driver for GEOS that supports both 40 and 80 column modes but mode can not be changed between tgi_init and tgi_done.

joy - JOY driver for GEOS that supports only joystick, not current pointing device.

It is safe to use these standard includes and their contents: assert.h, conio.h, dio.h, errno.h, em.h, geos.h, joystick.h, modload.h, mouse.h, stdlib.h, string.h, tgi.h, time.h

For time.h functions systime() and clock() note that the resolution is one second.

Functions from the headers above are either standard C library functions or cc65-specific, in either case they are not GEOS specific and so they are not described here.

I am an assembler programmer and GEOSLib was designed in such way that cc65 could emit the best available code (well, the best as for machine :-). Many of the void foo (void) functions are just raw calls to the Kernal (assembled just as jsr _foo), look in gsym.h, where you can find many definitions of standard GEOS locations. Access to these addresses is optimized by cc65 to simple lda and sta. Don't be afraid to use C syntax.

1.1 Requirements

You don't need a C64 or C128 for development. The only hardware requirement is a PC capable of running cc65. You do however need C64 or C128 emulator and GEOS disk images (.d64) to test your programs.

The software needed:

VICE and cc65 are portable - they run on variety of platforms - DOS, Win32 and UNIX. GEOSLib only needs cc65.

Update: starting from v2.5.0 GEOSLib is a part of the cc65 package as its GEOS support library.

1.2 Legal

I want to thank Uz for his cc65 package, Alexander Boyce for his excellent GEOS Programmer's Reference Guide and BSW for GEOS.

GEOSLib is covered by the same license as cc65. You can find the whole text among documentation. I would really appreciate if you would like to send me your comments, suggestions, questions, changes, bug reports etc. I will also appreciate if you will just give me a sign that you are using GEOSLib - not especially something big and important, mail me even if you are just playing with it.

You can send postcards with hellos to:

Maciej Witkowiak, ul. Slowackiego 6/57, 77-400 ZLOTOW

POLAND

e-mail: ytm@elysium.pl

2. What do you have and what to do with it?

This chapter describes some rules you ought to obey, and how to use GEOSLib.

2.1 Usage

Apart from this file, which merely describes only standard GEOS library functions, you should read the grc65 (GEOS resource compiler) documentation. There is information about necessary resource files (each GEOS application needs at least one) and the build process - what should be done and in what order. Please also read the cc65 documentation on how to compile C, assembler and link everything together.

All in all, you just need to place

#include <geos.h>
at the top of your source.

As a general rule read the sources of the example programs and read the headers. These are the most reliable sources of knowledge ;-). You will also find there many C macros representing various arguments passed to the functions. Please use them. You will find your sources easier to understand, and it will be easier to find bugs.

All types used in GEOSLib are unsigned.

Screen coordinates are given in pixels unless stated differently.

2.2 Notes on style

Contrary to a typical GEOS assembly program which has a main function called after loading that setups the screen, menus, icons etc. exiting from the main function in C is equivalent to calling exit(). These two are the only safe methods of terminating applications. DO NOT USE EnterDeskTop! Your data may be lost as library destructors and functions registered with atexit are not called.

For GEOS GUI applications the recommended program structure is to have everything initialized in the main function and at the end of it a call to the MainLoop() function. WARNING! This function never returns, any code between MainLoop(); and the end of main will not be executed. You have to call exit() explicitly somewhere in your code (e.g. in a menu handler or via DialogBox action).

Whenever possible use definitions from gsym.h. The resulting code is translated by cc65 into series of lda and sta, so you can't do it better :-).

Don't hesitate to use library functions. Everything was written with size and speed in mind. In fact many calls are just redirections to the GEOS Kernal which results in a simple jsr.

The main function receives the standard argc and argv parameters. There are always either 1 or 3 parameters. The DOS application name is always set as argv[0]. If present, argv[1] and argv[2] will be set to the data filename and data diskname (it only works if the user double-clicks on a data file associated with your application). Note that it is up to your application to determine which of the available (up to four) disk drives has the disk with given diskname inside. If this fails your program should ask to insert the proper disk into one of available drives.

You might wonder why I have chosen a sometimes weird order of arguments in functions. I just wanted to avoid unnecessary pushing and popping of arguments from the stack because cc65 can pass a single unsigned int through CPU registers.

Do not try to compile in strict ANSI mode. The library uses cc65 extensions which are not available in ANSI.

It is possible to use dynamically loaded modules, three such modules are provided: A GEOS TGI driver, a GEOS EMD driver (for VDC extended memory) and a GEOS JOY driver. Just make sure that their filenames appear UPPERCASE in DeskTop. There are no more special recommendations, read the cc65 documentation about modules and the demo programs source code.

3. Library Functions

Functions here are sorted more or less in the way they appear in the header files. This way I am able to keep functions covering similar tasks near each other. All function names are identical to those from the geosSym file provided with the GeoProgrammer package. Only my extensions to geosSym are covered by new names, but I tried to keep them in the naming convention.

3.1 Graphics

This section covers the drawing package of GEOS along with text output routines.

SetPattern

void SetPattern (char pattern)

This function sets the current pattern to the given. There are 32 different patterns in GEOS. You can see them together in the filling box in GeoPaint.

GraphicsString

void GraphicsString (char *myGString)

One of the more powerfull routines of GEOS. This function calls other graphic functions depending on the given command string. See the structures chapter for a more detailed description.

Rectangle functions

Parameters to those functions are grouped in the struct window drawWindow. To speed up things and reduce overhead this structure is bound to zero page locations, where all rectangle functions expect their parameters. You can modify the data directly (e.g. drawWindow.top=10) or via the InitDrawWindow function. Contents of drawWindow are guaranteed not to change when only using graphics functions. In other cases you should keep your data in separate struct window and use InitDrawWindow before the first call to one of the rectangle functions.

InitDrawWindow

void InitDrawWindow (struct window *myWindow)

This function only copies the contents of myWindow into the system area of drawWindow. Use it if for some reason you have to keep your window data out of the zero page space.

Rectangle

void Rectangle (void)

This draws on screen a rectangle filled with the current pattern.

FrameRectangle

void FrameRectangle (char pattern)

This one draws a frame with the given bit pattern (not a pattern from the GEOS palette).

InvertRectangle

void InvertRectangle (void)

Just as the name says...

ImprintRectangle and RecoverRectangle

void ImprintRectangle (void)

void RecoverRectangle (void)

These two functions are for copying parts of the screen to (Imprint) and from (Recover) the backbuffer of the screen. For example when drawing a new menu box GEOS first uses ImprintRectangle to save the area under the box, and restores it by RecoverRectangle upon destroying the menu.

Line Functions

The GEOS drawing package is optimized so there are different functions for drawing vertical and horizontal lines.

HorizontalLine

void HorizontalLine (char pattern, char y, unsigned xStart, unsigned xEnd)

This function draws a horizontal line using the given pattern. Note that pattern is not a pattern number as set in SetPattern but a true bit pattern.

InvertLine

void InvertLine (char y, unsigned xStart, unsigned xEnd)

There is only a horizontal version.

RecoverLine

void RecoverLine (char y, unsigned xStart, unsigned xEnd)

This function recovers a single line. It is utilized by RecoverRectangle. See its description for more details.

VerticalLine

void VerticalLine (char pattern, char yStart, char yEnd, unsigned x)

This function draws a vertical line using the given pattern. Note that pattern is not a pattern number as set in SetPattern but a true bit pattern.

DrawLine

void DrawLine (char mode, struct window *myWindow)

The top parameters of struct window describe the starting point of the line, while bottom ones are for the ending point. If mode is DRAW_DRAW then the current pattern from SetPattern is used for drawing. If mode is DRAW_ERASE then the line is erased from the screen. If mode is DRAW_COPY then the line is copied from/to back/frontbuffer, according to the dispBufferOn setting.

Point Functions

The parameters to these two functions are passed by a pointer to an own struct pixel filled with proper values.

DrawPoint

void DrawPoint (char mode, struct pixel *myPixel)

Depending on mode (see DrawLine) draws/erases/copies a single point on the screen.

TestPoint

char TestPoint (struct pixel *myPixel)

This function tests if the given pixel is set and returns true (non-zero) or false (zero).

Character and string output

PutChar

void PutChar (char character, char y, unsigned x)

This function outputs a single character using the current style and font to the screen.

PutString

void PutString (char *myString, char y, unsigned x)

Same as PutChar except the fact that you can output a whole NULL-terminated string. See ggraph.h for the list of tokens that you can also place in the string - like CBOLDON or COUTLINEON.

PutDecimal

void PutDecimal (char parameter, unsigned value, char y, unsigned x)

This function converts value to its decimal representation and outputs it to the screen. The parameter is the field width in pixels (range 1-31) and the mode bits. Depending on them the string can be filled with zeroes (the string is always 5 characters long) or not and left or right justified to the given pixel. See ggraph.h for predefined values for parameter.

Font Handling

GetCharWidth

char GetCharWidth (char character)

This function returns the real width (in pixels) of the given character with the current font. It can be used for counting the length of a string on the screen, allowing for indentation or justification.

LoadCharSet

void LoadCharSet (struct fontdesc *myFont)

This function forces GEOS to use the given font. myFont should be casted from a pointer to the start of the area where a record from a font file (VLIR structure) was loaded.

UseSystemFont

void UseSystemFont (void)

This function forces GEOS to use the built-in BSW font.

Bitmap handling

I'm not quite sure how these functions are working (except BitmapUp) so you should probably look into the library sources and compare it with your knowledge. Please let me know if something is wrong or broken.

BitmapUp

void BitmapUp (struct iconpic *myPic)

This function unpacks the bitmap and places it on the screen - just as you set it in the struct iconpic pointer which you pass. See gstruct.h for a description of this structure. Note that you can only use packed GEOS bitmaps - a simple Photo Scrap is in this format.

BitmapClip

void BitmapClip (char skipLeft, char skipRight, unsigned skipTop, struct iconpic *myPic)

This function acts similar to BitmapUp but you can also define which parts of the bitmap are to be drawn - you give the number of columns (8-pixel) to skip on the right and left of the bitmap, and the number of rows to skip from the top if it.

BitOtherClip

void BitOtherClip (void *proc1, void *proc2, char skipLeft, char skip Right, unsigned skipTop, struct iconpic *myPic)

Similar to the previous one with some extension. proc1 is called before reading a byte (it returns in .A the next value), and proc2 is called every time the parser reads a byte which is not a piece of a pattern (byte of code greater than 219). Both procedures should be written separately in assembler and declared as __fastcall__ returning char.

3.2 Menus and Icons

Here you will find information about functions related with menus and icons.

Menus

Menus are essential for a GUI. GEOS can handle only one menu at a time, but each menu can call another one, which results in a submenu tree. There can be up to 8 menu levels, each one with up to 32 items.

Menus are initialized with DoMenu and then the Kernal takes care of everything. Your code (called from an event handler) should be a function without parameters, returning void. You should use DoPreviousMenu or GotoFirstMenu at least once in its code to have the screen clean.

DoMenu

void DoMenu (struct menu *myMenu)

This function initializes the GEOS menu processor and exits. See DoMenu structure for more information about it. Know that many GEOS applications just initialize the screen, menu and exit to the main Kernal loop, this proves the power of DoMenu.

ReDoMenu

void ReDoMenu (void)

This simply redraws the menu at the lowest level. It works like calling DoMenu again with the same parameters.

RecoverMenu

void RecoverMenu (void)

This function erases the current menu from the screen. It doesn't change the menu level.

RecoverAllMenus

void RecoverAllMenus (void)

This calls RecoverMenu and erases all menus from the screen. Then the menu level is set to 0 (topmost).

DoPreviousMenu

void DoPreviousMenu (void)

This functions causes the menu processor to go back one menu level. You should use it in menu handler code to have the screen clean.

GotoFirstMenu

void GotoFirstMenu (void)

This one jumps back to the topmost menu. If there is only a menu and one submenu it works the same as DoPreviousMenu.

Icon Functions

Icons are working similar to menus except the fact that there is only one level. Icons are defined as a screen area filled with a bitmap, but if you would setup icons and erase the screen they would still be active and clicking in the place where formerly an icon was would cause an effect. Similarly if you would setup icons and then turn them off with ClearMouseMode the bitmap would still be on the screen but clicking on it would not cause any action. There is only one, but powerful icon function.

DoIcons

void DoIcons (struct icontab *myIconTab)

This function initializes all icons that are present on the screen at once. For more information look at the Icons chapter in this manual.

3.3 DialogBoxes

This chapter covers the most powerful GEOS user interface function - DoDlgBox.

GEOS standard

DoDlgBox

char DoDlgBox (char *dialogString)

This function returns one byte. It can be the value of one of six standard icons (see gdlgbox.h) or whatever the closing routine passes. Register r0L also contains this value.

Read the structures chapter for the specs of the dialogString.

RstrFrmDialogue

char RstrFrmDialogue

This function is called from within DoDlgBox event. It immediately closes the DialogBox and returns the owner ID (or whatever caller has in the .A register).

GEOSLib extensions

To simplify the usage of DoDlgBox from C I wrote some helper functions - wrappers for DoDlgBox, with predefined data. In one word - these are standard DialogBoxes you can see in almost every GEOS application.

DlgBoxYesNo, DlgBoxOkCancel, DlgBoxOk

char DlgBoxYesNo (char *line1, char *line2)

char DlgBoxOkCancel (char *line1, char *line2)

void DlgBoxOk (char *line1, char *line2)

These function show two lines of text in a standard-sized DialogBox. You can read the code of the pressed icon from the return value. E.g. for DlgBoxYesNo it can only be YES or NO. You can pass an empty string or NULL to get a blank line.

DlgBoxGetString

char DlgBoxGetString (char *string, char strlen, char *line1, char *line2)

This function prompts the user to enter a string of at most strlen characters. It is returned in string. The two given lines of text are shown above the input line. Please remember that there is also a CANCEL icon in the DialogBox and you should test if user confirmed his input or gave up. The string is also shown so you can place a default input there or remember to place NULL at start.

DlgBoxFileSelect

char DlgBoxFileSelect (char *class, char filetype, char *filename)

This routine is the standard file selector. It can return OPEN, CANCEL or disk error on reading the directory or opening the disk. There is also a DISK icon shown, but it is handled internally. You pass as input parameters filetype and a pointer to a string containing the first part of a file's class. If this string is empty (NULL at the start), then all files with given filetype will be shown.

At present this file selector handles only first 16 files of given type and supports only one (current) drive.

MessageBox

char MessageBox (char mode, const char *format, ...)

This function is a more general one. It works very much like printf in a box. The only difference is the mode parameter which allows for placing default icons (see gdlgbox.h for list of possible MB_ values). Any too wide text will be clipped to the size of the default window. If mode is invalid or equal to MB_EMPTY then the window will be closed after a click. Otherwise the user must choose an icon.

Note: Use it if you really need (or if you use it in many places) as it adds quite amount of code to your program.

Note: the formatted text cannot exceed 255 bytes in length, there is no check for that.

3.4 Mouse, Sprites and Cursors

You will find here functions related to sprite and mouse drawing and handling.

Mouse related functions

These cover the mouse - as a general pointing device, but expect users to utilize as different devices as a digital or analog joystick, a mouse, a lightpen or a koalapad (whatever it is).

StartMouseMode

void StartMouseMode (void)

This function initializes the mouse vectors - mouseVector and mouseFaultVec, and then calls MouseUp.

ClearMouseMode

void ClearMouseMode (void)

This function disables all mouse activities - icons and menus stop to respond to mouse events, but they are not cleared from the screen.

MouseUp and MouseOff

void MouseUp (void)

void MouseOff (void)

The first function turns the mouse pointer on. It appears on the next IRQ. The second one does the opposite - it turns off the pointer, but its position is still updated by the input driver.

IsMseInRegion

char IsMseInRegion (struct window *myWindow)

This function tests if the mouse pointer is actually in the given range of the screen. See gsprite.h for a description of the bits in the return values - they describe the position in detail.

Sprites

You are free to use any of the eight sprites, but keep in mind that sprite 0 is actually the mouse pointer and sprite 1 can be overwritten when using a text prompt. You don't have to worry about 40/80 column issues because GEOS128 has a pretty good sprite emulator for the VDC.

DrawSprite

void DrawSprite (char sprite, char *mySprite)

This function initializes the sprite data. mySprite is a 63-byte table with bitmap data, which is copied to the system sprite area (at sprpic - see gsym.h). Hardware sprite registers are not initialized and the sprite is not yet visible.

PosSprite

void PosSprite (char sprite, struct pixel *myPixel)

This function positions the sprite on the screen. The given coordinates are screen ones - they are converted to sprite coordinates by GEOS. Due to this you cannot use this function to position your sprite off the left or top to the screen.

EnablSprite and DisablSprite

void EnablSprite (char sprite)

void DisablSprite (char sprite)

These two functions are responsible for making the sprite visible or not.

Cursors and Console

InitTextPrompt

void InitTextPrompt (char height)

This function initializes sprite 1 for a text prompt with given height. This parameter can be in range 1-48.

PromptOn and PromptOff

void PromptOn (struct pixel *myPixel)

void PromptOff (void)

The first function places a text prompt in given place and enables blinking. The second one is pretty self-explanatory.

GetNextChar

char GetNextChar (void)

This function gets the next character from the keyboard queue. If the queue is empty it returns NULL, otherwise you receive the true ASCII code of a character or the value of a special (function) key. See gsprite.h for the list of them.

3.5 Disk

This chapter covers rather low-level disk routines. You should use them with care, because you may easily corrupt data on disks. Also remember that contemporary GEOS supports many various devices and sticking to 1541 track layout (e.g. expecting the directory on track 18) might be dangerous.

For some purposes you might consider using the dio.h interface to disk access. It is native.

All GEOS disk functions return an error code in the X register. In some cases this is returned by the GEOSLib function (if its type is char), but in all cases the last error is saved in the __oserror location. If it is nonzero - an error occured. See gdisk.h for the list of possible errorcodes. You need to include errno.h to get __oserror, together with the standard errno. The latter gives less verbose, but still usable information and can be used with strerror. Probably you will get more information using _stroserror in a similar way.

For passing parameters use almost always a pointer to your data e.g. ReadBuff (&myTrSe).

Buffer functions

These functions take a single data sector (256 bytes) to read or write on the disk.

ReadBuff and Writebuff

char ReadBuff (struct tr_se *myTrSe)

char WriteBuff (struct tr_se *myTrSe)

These functions read and write a sector placed at diskBlkBuf.

GetBlock and ReadBlock

char GetBlock (struct tr_se *myTrSe, char *buffer)

char ReadBlock (struct tr_se *myTrSe, char *buffer)

These two functions read a single block directly to the 256 byte array placed at buffer. The difference between them is that GetBlock initializes TurboDos in the drive if it was not enabled. ReadBlock assumes that it is already enabled thus being slightly faster.

PutBlock, WriteBlock, VerWriteBlock

char PutBlock (struct tr_se *myTrSe, char *buffer)

char WriteBlock (struct tr_se *myTrSe, char *buffer)

char VerWriteBlock (struct tr_se *myTrSe, char *buffer)

Similar to previous but needed for writing the disk. VerWriteBlock verifies the data after writing. In case of an error five tries are attempted before an error code is returned.

Directory header

The functions described here operate on curDirHeader where the current disk header is stored. On larger (than 1541) capacity drives the second part of the directory header is in dir2Head.

GetPtrCurDkNm

void GetPtrCurDkNm (char *diskName)

This function fills the given character string with the name of current disk. It is converted to C standard - the string is terminated with NULL character instead of code 160 as in Commodore DOS. Note that the passed pointer must point to an array of at least 17 bytes.

GetDirHead and PutDirHead

char GetDirHead (void)

char PutDirHead (void)

These functions read and write the directory header. You should use GetDirHead before using any functions described below, and you should use PutDirHead to save the changes on the disk. Otherwise they will be lost. Operating area is the curDirHead.

CalcBlksFree

unsigned CalcBlksFree (void)

This function returns the number of free blocks on the current disk. It is counted using data in curDirHead so you must initialize the disk before calling it.

ChkDskGEOS

char ChkDskGEOS (void)

This functions checks curDirHead for the GEOS Format identifier. It returns either true or false, and also sets isGEOS properly. You must initialize the disk before using this.

SetGEOSDisk

char SetGEOSDisk (void)

This function initializes disk for use with GEOS. It sets the indicator in directory header and allocates a sector for the directory of border files. You don't need to initialize the disk before using.

FindBAMBit

char FindBAMBit (struct tr_se *myTrSe)

This function returns the bit value from the BAM (Block Allocation Map) for the given sector. The bit is set if the sector is free to use. The returned value is always zero if the sector is already allocated. In fact, this function could be used in a following way:

#define BlockInUse FindBAMBit
...
if (!BlockInUse(&myTrSe)) {
... block not allocated ...
}

Anyway, I feel that this function is too low-level.

BlkAlloc and NxtBlkAlloc

char BlkAlloc (struct tr_se output[], unsigned length)

char NxtBlkAlloc (struct tr_se *myTrSe, struct tr_se output[], unsigned length)

Both functions allocate enough disk sectors to fit length bytes in them. You find the output in output which is a table of struct tr_se. The last entry will have the track equal to 0 and sector equal to 255. The simplest way of using them is to use predefined space in the GEOS data space and pass fileTrScTab, which is a predefined table.

The difference between those two is that NextBlkAlloc starts allocating from the given sector, and BlkAlloc starts from the first nonused sector.

You need to use PutDirHead later to save any changes in BAM.

FreeBlock

char FreeBlock (struct tr_se *myTrSe)

Simply deallocates a block in the BAM. You need to update the BAM with PutDirHead.

SetNextFree

struct tr_se SetNextFree (struct tr_se *myTrSe)

This function finds the first free sector starting from given track and sector and allocates it. It might return the same argument if the given block is not allocated. I wanted it to be type clean, but this made the usage a bit tricky. To assign a value to your own struct tr_se you have to cast both variables to unsigned. E.g.

struct tr_se myTrSe;
...
(unsigned)myTrSe=(unsigned)SetNextFree(&otherTrSe);

In this example otherTrSe can be replaced by myTrSe.

Note: you must use casting to have the correct values.

Low-level disk IO

Functions described here are more usable in Kernal or drivers code, less common in applications, but who knows, maybe someone will need them.

EnterTurbo, ExitTurbo, PurgeTurbo

void EnterTurbo (void)

void ExitTurbo (void)

void PurgeTurbo (void)

These functions are the interface to the GEOS TurboDos feature which makes slow Commodore drives a bit more usable. EnterTurbo enables TurboDos unless it is already enabled. If not, then you will have to wait a bit to transfer the TurboDos code into disk drive RAM. ExitTurbo disables TurboDos. This is useful for sending some DOS commands to a drive e.g. for formatting. Note that before any interaction with the Kernal in ROM you have to call InitForIO. You don't have to worry about speed. EnterTurbo will only enable TurboDos (no code transfer) if TurboDos was disabled with ExitTurbo. PurgeTurbo acts differently from ExitTurbo - it not only disables TurboDos, but also removes it from drive RAM (not quite true, but it works like that). After using PurgeTurbo the next call to EnterTurbo will reload drive RAM.

ChangeDiskDevice

char ChangeDiskDevice (char newDevice)

This function changes the device number of the current device (in fact drives only) to the given one. It is usable for swapping drives. There's no check if the given newDevice already exist, so if you want to change the logical number of drive 8 to 9 and you already have a drive number 9 then GEOS will probably hang on disk access. Use safe, large numbers. Note that the safe IEC range is 8-30.

Disk Initialization

GEOS has two functions for initialization ('logging in' as they say on CP/M) of a disk.

OpenDisk

char OpenDisk (void)

This function initializes everything for a new disk. It loads and enables TurboDos if needed. Then the disk is initialized with NewDisk. Next, GetDirHead initializes curDirHead. Disk names are compared and if they differ then the disk cache on REU is cleared. Finally the format is checked with ChkDkGEOS and the disk name is updated in the internal tables.

NewDisk

char NewDisk (void)

This function is similar to the DOS command I. It clears the REU cache and enables TurboDos if needed.

3.6 Files

This section covers the GEOS file interface.

Directory handling

The functions described here are common for SEQ and VLIR structures.

Get1stDirEntry and GetNxtDirEntry

struct filehandle *Get1stDirEntry (void)

struct filehandle *GetNxtDirEntry (void)

These two functions are best suited for scanning the whole directory for particular files. Note that the returned filehandles describe all file slots in the directory - even those with deleted files. The return value can be obtained by casting both sides to unsigned - as in the SetNextFree function or read directly after a call to those two functions from r5. The current sector number is in r1 and the sector data itself is in diskBlkBuf.

FindFile

char FindFile (char *fName)

This function scans the whole directory for the given filename. It returns either 0 (success) or 5 (FILE_NOT_FOUND, defined in gdisk.h) or any other fatal disk read error. After a successful FindFile you will have struct filehandle at dirEntryBuf filled with the file's data and other registers set as described in GetNxtDirEntry.

FindFTypes

char FindFTypes (char *buffer, char fType, char fMaxNum, char *classTxt)

This function scans the directory and fills a table at buffer with char [17] entries. fType is the GEOS type of the searched files and classTxt is a string for the Class field in the file header. Class matches if the given string is equal or shorter than that found in the file's header block. If you want just to find all files with the given GEOS type you should pass an empty string or NULL as classTxt. Be warned that for searching NON_GEOS files you must pass NULL as classTxt. fMaxNum is the maximal number of files to find, thus the buffer must provide an area of size equal to 17 * fMaxNum. This function returns the number of found files, ranging from 0 to number passed as fMaxNum. The return value can be also restored from r7H.

DeleteFile

char DeleteFile (char *fName)

This function deletes a file by its name. It works for SEQ and VLIR files.

RenameFile

char RenameFile (char *oldName, char *newName)

I think it is obvious...

GetFHdrInfo

char GetFHdrInfo (struct filehandle *myFile)

This function loads the file header into the fileHeader buffer. Using after e.g. FindFile you can pass the address of dirEntryBuf.

Common and SEQ structure

Functions described here are common for SEQ and VLIR structures because the arguments passed are the starting track and sector which may point either to the start of a chain for VLIR or the data for SEQ.

GetFile

char __fastcall__ GetFile(char flag, const char *fname, const char *loadaddr, const char *datadname, const char *datafname)

This routine loads and runs a given file fname. The file must be one of following types: SYSTEM, DESK_ACC, APPLICATION, APPL_DATA, PRINTER, or INPUT_DEVICE. The execution address is taken from the file header. If it is zero, then the file is only loaded. Only the first chain from VLIR files is loaded. If flag has bit 0 set then the load address is taken from loadaddr and not from the file header. In this case APPLICATION files will be only loaded, not executed. This does not apply to DESK_ACC. If either bit 6 or 7 of flag are set, then 16 bytes from datadname are copied to dataDiskName and 16 bytes from datafname go to dataFileName thus becoming parameters for the new application. Pass NULL for any unused parameter.

ReadFile

char ReadFile (struct tr_se *myTrSe, char *buffer, unsigned fLength)

This function reads at most fLength bytes into buffer from chained sectors starting at myTrSe.

ReadByte

char ReadByte (void)

This function returns the next byte from a file. Before the first call to it you must load r5 with NULL, r4 with the sector buffer address and r1 with the track and sector of the first block of a file. Remember to not modify r1, r4 and r5. These registers must be preserved between calls to ReadByte.

The returned value is valid only if there was no error. The end of file is marked as BFR_OVERFLOW in __oserror, this is set when trying to read one byte after the end of file, in this case the returned value is invalid.

SaveFile

char SaveFile (char skip, struct fileheader *myHeader)

SaveFile will take care of everything needed to create a GEOS file, no matter if VLIR of SEQ structure. All you need to do is to place the data in the proper place and prepare a header which will contain all information about a file. The skip parameter says how many directory pages you want to skip before searching for a free slot for the directory entry. In most cases you will put 0 there.

You have to declare a struct fileheader and fill it with proper values. There is only one difference - the first two bytes which are a link to a nonexistent next sector are replaced by a pointer to the DOS filename of the file.

When saving sequential files the two most important fields in struct fileheader are fileheader.load_address and fileheader.end_address.

FreeFile

char FreeFile (struct tr_se myTable[])

This function deallocates all sectors contained in the passed table.

FollowChain

char FollowChain(struct tr_se *myTrSe, char *buffer)

This function fills a struct tr_se table at buffer with the sector numbers for a chain of sectors starting with myTrSe. You can pass such data (buffer) to e.g. FreeFile.

VLIR structure

Here is information about VLIR files (later called RecordFiles) and functions.

A VLIR structure file consists of up to 127 SEQ-like files called records. Each record is like one SEQ structure file. Records are grouped together, described by a common name - the VLIR file name and an own number. Each record pointed to by its number is described by the starting track and sector numbers. VLIR structures allow records to be empty (tr_se of such record is equal to {NULL,$ff}), or even non-exist ({NULL,NULL}). Any other numbers represent the starting track and sector of a particular file.

In GEOS there can be only one file opened at a time. Upon opening a VLIR file some information about it is copied into memory. You can retrieve the records table at fileTrScTab (table of 128 struct tr_se) and from VLIRInfo (struct VLIR_info. E.g. the size of whole VLIR file can be retrieved by reading VLIRInfo.fileSize.

OpenRecordFile

char OpenRecordFile (char *fName)

This function finds and opens a given file. An error is returned if the file is not found or if it is not in VLIR format. Information in VLIRInfo is initialized. VLIR track and sector table is loaded at fileTrScTab and will be valid until a call to CloseRecordFile so don't modify it. You should call PointRecord before trying to do something with the file.

CloseRecordFile

char CloseRecordFile (void)

This function calls UpdateRecordFile and clears internal GEOS variables.

UpdateRecordFile

char UpdateRecordFile (void)

This function will check the VLIRInfo.fileWritten flag and if it is set, then curDirHead is updated along with size and date stamps in the directory entry.

PointRecord

char PointRecord (char recordNumber)

This function will setup internal variables (and VLIRInfo.curRecord) and return the track and sector of the given record in r1. Note that the data may not be valid (if the record is non-existing you will get 0,0 and if it is empty - 255,0).

NextRecord and PreviousRecord

char NextRecord (void)

char PreviousRecord (void)

These two work like PointRecord. Names are self-explanatory.

AppendRecord

char AppendRecord (void)

This function will append an empty record (pair of 255,0) to the current VLIR track and sector table. It will also set VLIRInfo.curRecord to its number.

DeleteRecord

char DeleteRecord (void)

This function will remove the current record from the table, and move all current+1 records one place back (in the table). Note that there's no BAM update and you must call UpdateRecordFile to commit changes.

InsertRecord

char InsertRecord (void)

This function will insert an empty record in place of VLIRInfo.curRecord and move all following records in the table one place forward (contents of VLIRInfo.curRecord after a call to InsertRecord can be found in VLIRInfo.curRecord + 1).

ReadRecord and WriteRecord

char ReadRecord (char *buffer, unsigned fLength)

char WriteRecord (char *buffer, unsigned fLength)

This function will load or save at most fLength bytes from the currently pointed record into or from buffer.

3.7 Memory and Strings

The functions covered in this section are common for the whole C world - copying memory parts and strings is one of the main computer tasks. GEOS also has an interface to do this. These functions are replacements for those like memset, memcpy, strcpy etc. from standard libraries. If you are dealing with short strings (up to 255 characters) you should use these functions instead of standard ones, e.g. CopyString instead of strcpy. It will work faster.

However some of them have slightly different calling conventions (order of arguments to be specific), so please check their syntax here before a direct replacement.

Please note that the memory areas described here as strings are up to 255 characters (without counting the terminating NULL), and regions can cover the whole 64K of memory.

CopyString

void CopyString (char *dest, char *src)

This function copies the string from src to dest, until it reaches NULL. The NULL is also copied.

CmpString

char CmpString (char *s1, char *s2)

This function compares the strings s1 to s2 for equality - this is case sensitive, and both strings have to have the same length. It returns either true (non-zero) or false (zero).

CopyFString and CmpFString

void CopyFString (char length, char *dest, char *src)

char CmpFString (char length, char *s1, char *s2)

These two are similar to CopyString and CmpString except the fact, that you provide the length of the copied or compared strings. The strings can also contain several NULL characters - they are not treated as delimiters.

CRC

unsigned CRC (char *src, unsigned length)

This function calculates the CRC checksum for the given memory range. I don't know if it is compatible with standard CRC routines.

FillRam and ClearRam

void *FillRam (char *dest, char value, unsigned length)

void *ClearRam (char *dest, unsigned length)

Both functions are filling the given memory range. ClearRam fills with 0s, while FillRam uses the given value. Be warned that these functions destroy r0, r1 and r2L registers. The functions are aliases for memset and bzero, respectively.

MoveData

void *MoveData (char *dest, char *src, unsigned length)

This functions copies one memory region to another. There are checks for an overlap and the non-destructive method is chosen. Be warned that this function destroys contents of the r0, r1 and r2 registers. This function is an alias for memcpy.

InitRam

void InitRam (char *table)

This function allows to initialize multiple memory locations with single bytes or strings. This is done with a table where everything is defined. See the structures chapter for a description of InitRam's command string.

StashRAM, FetchRAM, SwapRAM, and VerifyRAM

void StashRAM (char bank, unsigned length, char *reuAddress, char *cpuAddress)

void FetchRAM (char bank, unsigned length, char *reuAddress, char *cpuAddress)

void SwapRAM (char bank, unsigned length, char *reuAddress, char *cpuAddress)

char VerifyRAM (char bank, unsigned length, char *reuAddress, char *cpuAddress)

These functions are the interface to a REU - Ram Expansion Unit. I think that they are self-explanatory. You can check for REU presence by taking the value of ramExpSize. You have to do it before using any of these functions.

3.8 Processes and Multitasking

Weird? Not at all. GEOS has some limited multitasking ability. You can set up a chain of functions called in specified intervals and you can put the main program to sleep without disturbing other tasks and making the user interface unresponsive.

InitProcesses

void InitProcesses (char number, struct process *processTab)

This is the main initialization routine. After calling it processes are set up, but not enabled. The parameters for InitProcesses are:

A single task is described by an entry in processTab, it contains two values - a pointer to the task function and a number of jiffies which describe the delay between calls to task. On PAL systems there are 50 jiffies per second, while on NTSC there are 60.

The maximum number of tasks is 20. Be warned that GEOS doesn't check if parameters are valid and if processTab would be too large it would overwrite existing data in GEOS space.

There's one important thing - the last entry in processTab has to be NULL,NULL, so the maximum size of processTab is equal to 21.

See the description of process structure for a more detailed discussion on this.

RestartProcess and EnableProcess

void RestartProcess (char processNumber)

void EnableProcess (char processNumber)

These two functions start the task counter. RestartProcess should be called for each process after InitProcesses, because it resets all flags and counters and it starts the counters.

RestartProcess enables the counters and sets their initial value to that given in processTab.

EnableProcess forces the given process to execute by simulating the timer expiring.

BlockProcess and UnblockProcess

void BlockProcess (char processNumber)

void UnblockProcess (char processNumber)

BlockProcess disables the execution of the given process, but this does not disable the timers. It means that if you call UnblockProcess before the timer runs out, the process will be executed.

UnblockProcess does the opposite.

FreezeProcess and UnfreezeProcess

void FreezeProcess (char processNumber)

void UnfreezeProcess (char processNumber)

FreezeProcess disables timer for given process. UnfreezeProcess does the opposite. This is not equal to RestartProcess as timers are not reloaded with initial value.

Sleep

void Sleep (unsigned jiffies)

This function is a multitasking sleep - the program is halted, but it doesn't block other functions e.g. callbacks from menus and icons. The only argument here is the number of jiffies to wait until the app will wake up. It depends on the video mode (PAL or NTSC) how many jiffies there are per second (50 or 60, respectively). If you don't want to worry about it and need only full second resolution, call the standard sleep function from unistd.h.

3.9 System Functions

FirstInit

void FirstInit (void)

This function initializes some GEOS variables and mouse parameters. This is called on GEOS boot up. You shouldn't use this unless you know what you are doing.

InitForIO and DoneWithIO

void InitForIO (void)

void DoneWithIO (void)

These functions are called by some disk routines. You should call them only if you want to do something with IO registers or call one of the Kernal ROM routines. Note that this is rather an expensive way of turning off IRQs and enabling IO.

MainLoop

void MainLoop (void)

Returns control to the system. Any code between call to MainLoop and the end of current function will never be executed. When in MainLoop the system waits for your action - using icons, keyboard or menus to force some specific action from the program. You have to define proper handlers before that.

EnterDeskTop

void EnterDeskTop (void)

This is an alias for exit(0) so you will never burn yourself. Anyway, you should not use it. Always use exit() instead. Library destructors and functions registered with atexit() are called.

ToBASIC

void ToBASIC (void)

This one is another way of terminating an application - forcing GEOS to shutdown and exit to BASIC. I was considering whether to include it or not, but maybe someone will need it - which I doubt.

WARNING: library destructors and functions registered with atexit() will not be called so it is quite unsafe way to terminate your program.

Panic

void Panic (void)

This calls system's Panic handler - it shows a dialog box with the message

System error at:xxxx
where xxxx is last known execution address (caller). By default this is bound to the BRK instruction, but it might be usable in debugging as kind of assert. (Note that assert is available as a separate function and will give you more information than that).

The system is halted after a call to Panic which means that library destructors will not be called and some data may be lost (no wonder you're panicking).

CallRoutine

void CallRoutine (void *myFunct)

This is a system caller routine. You need to provide a pointer to a function and it will be immediately called, unless the pointer is equal to NULL. This is the main functionality of this function - you don't need to check if the pointer is valid.

GetSerialNumber

unsigned GetSerialNumber (void)

This function returns the serial number of the system. It might be used for copy-protection. However, please remember that Free Software is a true power and you are using it right now.

GetRandom

char GetRandom (void)

This function returns a random number. It can be also read from random e.g.

a=random;
but by calling this function you are sure that the results will be always different. random is updated once a frame (50Hz PAL) and on every call to GetRandom.

Note that this is not the same as the rand function from the standard library. GetRandom will give you unpredictable results (if IRQs occur between calls to it) while rand conforms to the standard and for a given seed (srand) always returns with the same sequence of values.

SetDevice

void SetDevice (char device)

This function sets the current device to the given. It might be used together with InitForIO, DoneWithIO and some Kernal routines. Unless the new device is a disk drive this only sets new value in curDevice, in the other case new disk driver is loaded from REU or internal RAM.

get_ostype

char get_ostype (void)

This function returns the GEOS Kernal version combined (by logical OR) with the machine type. Read gsys.h for definitions of the returned values.

get_tv

char get_tv (void)

This function returns the PAL/NTSC flag combined (by logical OR) with the 40/80 columns flag. This is not the best way to check if the screen has 40 or 80 columns since a PAL/NTSC check is always performed and it can take as long as a full raster frame. If you just want to know if the screen has 40 or 80 columns use the expression graphMode & 0x80 which returns 0 for 40 columns and 0x80 for 80 columns. Remember that this value can be changed during runtime. It is unclear if this will work for GEOS 64 so you probably do not want to test anything if not running under GEOS128. Use get_ostype to check it. Read gsys.h for definitions of the returned values.

4. Library Structures

To simplify usage and optimize passing parameters to functions I have declared several structures which describe the most common objects. Some of these structures are bound to static addresses in the GEOS data space ($8000-$8fff), so you can use their fields directly in an optimized way. Please see gsym.h to find them. All structures are defined in gstruct.h and you may find also some comments there.

4.1 Graphics Structures

pixel

A simple structure describing a point on the screen.

fontdesc

This structure describes a font in one pointsize. There is the current font - struct fontdesc bound to curFontDesc. You can also force GEOS to use your own fonts by calling LoadCharSet. You just need to open a VLIR font file and load one record - one pointsize - somewhere. At the start of this area you already have all data for fontdesc so you can pass a pointer to the load address of that pointsize to LoadCharSet. (Note that although it has 'Load' in the name, that function loads only GEOS internal data structures, not data from disk).

window

This widely used structure holds the description of a region of the screen. It describes the top-left and bottom-right corners of a window.

iconpic

Maybe the name isn't the best - it has nothing with DoIcons but with bitmap functions - BitmapUp for example. This structure holds the parameters needed to properly decode and show a bitmap on the screen. The bitmap has to be encoded - if you have some non-GEOS bitmaps simply convert them to Photo Scraps - this is the format used by all GEOS bitmap functions - DoIcons too.

4.2 Icons

These structures describe click boxes (icons) that can be placed on screen or in a dialog box.

icondef

This is the definition of a single click box. Please see gstruct.h for a description of its fields.

icontab

This is the toplevel description of icons to be placed and enabled on the screen. This structure has the following fields:

4.3 File and Disk

tr_se

This simple structure holds the track and sector number of something. Do not expect the track to be in range 1-35, as GEOS can support many various and weird devices. For example my C128 256K expansion is utilized as RAMDisk with a layout of 4 tracks of 128 sectors each. However assuming that a track number equal to 0 is illegal might be wise.

f_date

This is a placeholder for a file datestamp. This structure is also present in struct filehandle. GEOS is not Y2K compliant, so if the current file has in filehandle.date.year a value less than 86 you can safely assume that it is e.g. 2004 and not 1904.

filehandle

This is the main file descriptor. It is either an entry in the directory (returned from file functions) or its copy in dirEntryBuf. This is optimized so you can safely get to the file's year e.g. by testing dirEntryBuf.date.year - it will be compiled to simple LDA, STA.

fileheader

This structure holds the fileheader description. You can load a file's header into the fileHeader fixed area using GetFHdrInfo. (note that fileHeader is a place in memory while fileheader is a structure). You will also need your own fileheader for SaveFile.

4.4 System Structures

s_date

This structure is defined only for system_date. It is slightly different from f_date so I prepared this one. You can e.g. get or set the current time using system_date.s_hour and system_date.s_minute. Accesses to these will be optimized to simple LDA and STA pair.

process

You should declare a table of that type to prepare data for InitProcesses. The maximum number of processes is 20, and the last entry has to be equal to {NULL,NULL}, so this table may hold only 21 entries. The first member of this structure (pointer) holds the pointer to the called function (void returning void), you will probably have to cast that pointer into unsigned int. The second field jiffies holds the amount of time between calls to that function. On PAL systems there are 50 jiffies per second, while NTSC have 60 of them.

4.5 A few things in detail...

GEOSLib uses cc65 non-ANSI extensions to easily initialize data in memory. This is done with a kind of array of unspecified length and unspecified type. Here is how it works:

void example = {
    (char)3, (unsigned)3, (char)0 };
Which will be compiled to following string of bytes:
_example:
        .byte 3
        .word 3
        .byte 0
As you see this way it is possible to define data of any type in any order. You must remember to cast each member to proper type.

DoMenu structure

DoMenu is responsible for everything concerned with menu processing. Many, many GEOS programs are just initializing the screen and menu and returning to MainLoop. In GEOSLib it is the same as returning from main function without using exit(0).

A menu is described by two types of data - menu descriptors and menu items. A descriptor contains information about the following menu items, and items contain names of entries and either pointers to functions to execute or, in case of nested menus, pointers to submenu descriptors. Note that submenu descriptor can be top-level descriptor, there's no difference in structure, just in the content.

Here is how a single descriptor looks like:

void myMenu = {
        (char)top, (char)bottom,                // this is the size of the menubox
        (unsigned)left, (unsigned)right,        // counting all items in the current descriptor
        (char)number_of_items | type_of_menu,   // number of following items ORed with
                                                // type of this menu, it can be either
        // HORIZONTAL or VERTICAL if you will have also bit 6 set then menu won't be closed
        // after moving mouse pointer outside the menubox. You can have at most 31 items.
This is followed by number_of_items of following item description.
        ...
        "menuitemname", (char)item_type, (unsigned)pointer,
        "nextitemname", (char)item_type, (unsigned)pointer,
        ...
        "lastitemname", (char)item_type, (unsigned)pointer };
        // Note that there isn't ending <tt/NULL/ or something like that.
pointer is a pointer to something, what it points for depends from item_type. This one can have following values:

MENU_ACTION - a function pointed by pointer will be called after clicking on the menu item

SUB_MENU - pointer points to next menu descriptor - a submenu

Both of them can be ORed with DYN_SUB_MENU and then the pointer points to a function which will return in r0 the needed pointer (to function to execute or a submenu).

For creating nested menus (you can have at most 8 levels of submenus) you need to declare such a structure for each submenu and top level menu.

DoDlgBox command string

DoDlgBox is together with DoMenu one of the most powerful routines in GEOS. It is responsible for creating dialog boxes, that is windows which task is to interact with the user. The format of the command string is following:

    (window size and position)
    (commands and parameters)
    NULL
There is a custom type defined for the command string: dlgBoxStr.

Size and position

The first element can be specified in two ways - by using the default size and position or specifying your own. The first case results in

const dlgBoxStr example = {
        DB_DEFPOS (pattern_of_shadow),
        ...             // commands
        DB_END };
And the own size and position would be:
const dlgBoxStr example = {
        DB_SETPOS (pattern, top, bottom, left, right)
        ...             // commands
        DB_END };

Commands

The next element of the DoDlgBox command string are the commands themselves. The first six commands are default icons and the number of the selected icon will be returned from window processor. The icons are OK, CANCEL, YES, NO, OPEN, and DISK. You can use predefined macros for using them, e.g.:

        ...
        DB_ICON(OK, DBI_X_0, DBI_Y_0),
        ...
Note that the position is counted from top left corner of window, not entire screen and that the 'x' position is counted in cards (8-pixel) and not in pixels. This is also true for all following commands. DBI_X_0 and DBI_Y_0 are predefined (see gdlgbox.h for more), the default positions which will cause icons to appear on a default window exactly where you would expect them.

DB_TXTSTR (x, y, text) will cause to show the given text in the window.

DB_VARSTR (x, y, ptr) works as above, but here you are passing a pointer to a zero page location where the address of the text is stored. This is useful for information windows where only the text content is variable. Consider following:

char text = "foo";
        ...
        r15=(unsigned)text;             // in code just before call to DoDlgBox
        ...
        DB_VARSTR (TXT_LN_X, TXT_LN_1_Y, &r15),
        ...
will cause the word ``foo'' to appear in the window, but you may store the pointer to any text in r15 (in this case) before the call to DoDlgBox.

DB_GETSTR(x, y, ptr, length) - will add a input-from-keyboard feature. ptr works as in the previous example and points to the location where the text is to be stored. Note that the contents of this location will be shown upon creating the window. length is the maximum number of characters to input.

DB_SYSOPV(ptr) - this sets otherPressVec to the given pointer. It is called on every keypress.

DB_GRPHSTR(ptr) - the data for this command is a pointer for GraphicsString commands.

DB_GETFILES(x, y) - for a standard window you should pass 4 for both x and y. This function draws a file selection box and searches the current drive for files. Before the call to DoDlgBox you must load r7L with the GEOS filetype of searched files and r10 with the class text. In r5 you have to load a pointer to a char[17] where the selected filename will be copied. It works like FindFTypes but is limited to first 16 files.

DB_OPVEC(ptr) - this sets a new pointer for the button press function, if you pass RstrFrmDialogue here you will cause the window to close after pressing mouse button.

DB_USRICON(x, y, ptr) - places a single user icon (click box) on the window, ptr points at a struct icondef but fields x and y are not used here. You can have at most 8 click boxes in a window, this is an internal limit of the GEOS Kernal.

DB_USRROUT(ptr) - this command causes to immediately call the user routine pointed by ptr.

GraphicsString command string

GraphicsString is a very powerful routine to initialize the whole screen at once. There are predefined macros for all commands, names are self-explanatory, see them in ggraph.h. The last command has to be GSTR_END. There is a custom type defined for the command string: graphicStr.

Here is an example for clearing the screen:

const graphicStr example = {
        MOVEPENTO(0,0),
        NEWPATTERN(0),
        RECTANGLETO(319,199)
        GSTR_END };

InitRam table

This type of data is used to initialize one or more bytes in different locations at once. The format is the following:

void example = {
    (unsigned)address_to_store_values_at,
    (char)number_of_bytes_that_follow,
    (char)data,(char)data (...)
    // more such definitions
    (unsigned)NULL // address of 0 ends the table
    };

Intercepting system vectors

It is possible to intercept events and hook into the GEOS Kernal using vectors. Here is a little example:

void_func oldVector;

void NewVectorHandler(void) {
        // do something and at the end call the old vector routine
        oldVector();
}

void hook_into_system(void) {
        oldVector = mouseVector;
        mouseVector = NewVectorHandler;
}

void remove_hook(void) {
        mouseVector = oldVector;
}

In your main function you should call hook_into_system() but after all calls to the GEOS Kernal (like DoMenu, DoIcons, etc.) - right before passing control to the MainLoop(). Be warned that vectors are most likely to be changed by the GEOS Kernal also via other functions (like GotoFirstMenu, DoDlgBox and its derivatives etc.). It depends on what Kernal functions you use and which vectors you altered. Unfortunately there is no exact list for GEOS 2.0, a complete list for GEOS 1.x can be found in A. Boyce's Programmers' Reference Guide mentioned before. Most of the information contained there should be still valid for GEOS 2.0. When calling a function that restores the vector you should add a hook_into_system() call right after it.

It is critical to restore old vector values before exiting the program. If you have more than one place where you call exit() then it might be worth to register remove_hook function to be called upon exiting with atexit(&remove_hook); call. This way you will ensure that such destructor will be always called.

That little example above intercepts mouseVector. The NewVectorHandler function will be called every time the mouse button changes status. Other important vectors you should know about are: