ftp.wwiv.com

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

/ ftp.wwiv.com / ftp.wwiv.com.zip / ftp.wwiv.com / pub / GENUTIL / FKFOS102.ZIP / FKFOSSIL.DOC < prev next >

Wrap

Text File | 1994-12-27 | 81KB | 1,606 lines

| FKFOSSIL v1.02 | Turbo Pascal Fossil Communication/Door Driver Routines | | Copyright 1993-1994 by Tim Strike | and Forbidden Knights Systems. | Released on December 27th, 1994. ____________ INTRODUCTION ____________ I've been programming for the fossil driver for 2 years. It originally started with portions of a simple program, all built-in code. Whenever I needed the routines, I would copy them from program to program. About a year ago I optimized all the code and it became a .TPU unit. I've been using those routines since then, until I recently decided I would optimize the code even MORE with what I had learned since (it's forever an experience). At any rate, some of the biggest complaints of some programmers is the lack of decent fossil routines, and even that fossil routines that exist are far too costly. If you're in need of a small program then you also don't want to pay for the routines. Since I rewrote my routines, I decided that they would make a very good, powerful .TPU unit for programmers -- and I decided that I would surpass as many products as I could in price and quality. I think I've managed to do both. The Forbidden Knights Fossil Routines are absolutely free except for one condition; If you use these routines in ANY of your programs, you must give credit for their use. Forbidden Knights Systems maintains copyright on the fossil routines contained in this unit, which should also be stated upon program execution or clearly in your documentation. Please understand this clause -- if you do not agree with this then you must delete the unit from your harddrives. If people begin to abuse this right, future versions will not be made available to the public. While the copyright is maintained by Forbidden Knights Systems, we are not responsible for damage due to use or misuse of these routines. FKFOSSIL is to be used with Turbo Pascal 6.0 or 7.0. To use with TP6.0, copy the FK6.TPU to FKFOSSIL.TPU and place into your TPU directory. To use with TP7.0, copy the FK7.TPU to FKFOSSIL.TPU and place into your TPU directory. FKFOSSIL is a tool for all programmers who wish quick, reliable fossil communication routines. FKFOSSIL will provide the novice user with a insert-and-run level that can be easily understood, and the expert user with many advanced configuration and control units. Some of the highlights include; o Insert and run -- all variables are pre-defined so that even the novice programmer can quickly get things started. The more advanced users will like the configurability of most of the internal options. o It's free to use! A note saying that the FKFOSSIL routines are being used, and that they are copyright Forbidden Knights Systems must be displayed, and that's all that is required. (however donations are always welcomed by anyone who would like to send anything in). o Full support for TTY, ANSI and Avatar/0 commands. From clearing the screen to setting the text colour, all the ANSI commands and Avatar/0 commands are supported. o Internal ANSI and Avatar drivers -- ANSI.SYS is not required to view/display ANSI lines. Because of this built-in code, ANSI keyboard remapping isn't possible which provides a safeguard for ANSI displayed in the door against "trojans" and other pranks (ever had YOUR terminal turned into a 300x200 mode by an ansi file...?) o OS/2, DESQview and Windows detection - FKFOSSIL releases all unused timeslices to improve CPU usage. This is done whenever keyboard polling occurs automatically by FKFOSSIL. o Configured to read from DOOR.SYS or DORINFO1.DEF drop files, or the information can be manually set/read from other places so that the FKFOSSIL unit is completely portable. If drop files need to be created, FKFOSSIL will create drop files DOOR.SYS and DORINFO1.DEF. o Automatically keeps track of time (including time rolling over midnight), and the last time user pressed a key. These counters can be disabled or changed quickly, and are displayed on the status line. Keyboard inactivity timeouts warn the user and then automatically shut down when violated. o ANSI Music Interface -- Will send ANSI Music string to remote side, and disassemble and play on the local side. o Definable functions -- Local and Remote Input Processing, Carrier loss, Inactivity Timeout, No Time Left, Open and Close. These are used if you want to have the standard routines replaced, for example; the carrier loss routine currently sends a string to the screen saying the carrier was lost, then it deinitializes the fossil driver. If you want to have it write to the log, then close a few files, then say the carrier was lost and exit -- the definable function makes it easy to do without having to trap all of the stuff yourself. And those are just SOME of the highlights of the routines. There are big plans to improve these routines and add even more -- I've already started with the coding and some of them are even at the testing stage right now. I get the full use out of the routines that I expect, so I hope that you enjoy using the routines and get some good use out of them as well. _________________ UNIT INSTALLATION _________________ We have tried to make the installation of FKFOSSIL as simple as possible. If you are using TP6.0, rename FK6.TPU -> FKFOSSIL.TPU and copy it into your main TPU directory (where the other .TPU's are stored). If you are using TP7.0, rename FK7.TPU -> FKFOSSIL.TPU and copy into your main TPU directory. That's the simple part... ;) To setup your program to use the routines, you will need to let Turbo Pascal know that you are using the library. You may or may not already have a "USES <library>[,<library>]" clause in your program. If you do, then simply add FKFOSSIL to that list. If you do not, then right after the "PROGRAM name" clause add "USES FKFOSSIL;". Program Example1_1; USES CRT,DOS,FKFOSSIL; { If using more then one unit } Program Example1_2; USES FKFOSSIL; { If only using FKFOSSIL unit } At this point when compiled, your program will include the FKFOSSIL routines in your program. In order to make these the simplest routines to use, when your program is first run, FKFOSSIL will auto-initialize. You won't even know it's happening, and by that point all the variables will be predefined and FKFOSSIL will have already determined your operating system and it's capabilities. Why are the variables predefined? Because if the "standard setup" was actually a procedure, then some programmers might fail to run the "setup" procedure, and that could cause unpredictable results (sometimes it might work, other times it might not). To save you time and sanity, the variables are initialized automatically -- this means that if you want to change any of the variables, you don't need to worry about the order or what procedures come before or afterward. NOTE; This means that this unit may _not_ be overlayed. There are a couple of good reasons to do this, but the main one is that overlaying this unit will cause extreme slowdowns in communications and it is never recommended to overlay any type of unit which will be used throughout a program (especially if you have a larger overlay file, like a BBS for example). Now that takes care of getting the routines recognized -- but what about starting the fossil driver and getting the actual communications started? Easy enough -- your program should start with FK_INITFOSSIL and end with FK_DEINITFOSSIL. o The fk_InitFossil routine should be called before you start using any of the other routines. This starts the fossil driver and get's the ball rolling. If you want to setup variables or call NON-FKFOSSIL routines beforehand, that's fine. For instance, if you have a "Command Line Help", you may wish to process that before starting the fossil driver. NOTE; If you plan on reading in the DOOR.SYS or DORINFO1.DEF files, then I suggest you read the section for those two drop files -- it's important that you read in the information before the fk_InitFossil routine so that the initialization can use the information that is read in. Also, if you do plan on reading in the DOOR.SYS and DORINFO1.DEF files, there is a special initialization procedure which saves you time. o The fk_DeInitFossil should be the very LAST line your program will run -- this will take care of releasing the fossil driver and exiting your program. Program Example1_3; USES FKFOSSIL; BEGIN if Paramstr(1) = '/?' then BEGIN ... END; fk_InitFossil(1,2400,19200,'Tim Strike','Riim',600,1); if fk_Host.Error = 2 then BEGIN Writeln('Unable to open Fossil Driver.'); Halt(1); END; ... fk_DeInitFossil; END. { main } _______ SAMPLES _______ To allow you to get a full idea of the operation of the FKFOSSIL routines, a sample program demonstrating every aspect of the routines has been enclosed in the SAMPLES.ZIP file in the archive. Full source to the samples have also been provided. _______________ EMULATION MODES _______________ FKFOSSIL supports several different types of emulations modes, all internally. These emulation modes and brief descriptions are listed below. Before setting a users screen mode to one of these emulations, first make sure that the user can handle it. TTY is the most common, and most (if not all) users should be able to handle this mode. TTY is just straight ascii -- in this mode, all characters will be sent to the remote side, but no colours will be sent even if the colour routines are called. Also in TTY mode the functions such as cursor placement, clreol, etc will be disabled (and return an error in FK_HOST.ERROR if there are problems). The only special function in TTY mode is that of CHR(12), which clears the screen. ANSI is another emulation standard supported in FKFOSSIL. ANSI starts off with ESC[ and is followed by a few characters of information, and finally, a character code indicating the function to perform. ANSI has the ability to set foreground and background colours, move the cursor up/down/left/right or to specific locations, clear the line, clear the screen, and the list goes on. All the ANSI routines in FKFOSSIL have been optimized to send the fewest codes to the modem. If you set the colour to 15/0 and the colour is already 15/0, the codes won't be sent. Unlike many other programming units, ANSI is _built_ into this unit. That means ansi displayed with the functions FK_DISPLAY[file] or FK_WRITELN_ANSI will be processed internally. The internal ANSI has everything that most other drivers support except the keyboard remapping, and the screen modes -- both of which are unnecessary in the communications world. Since the routines are internal, the chance of someone using ANSI "bombs" or "trojans" with FKFOSSIL is impossible. This also means that an ANSI.SYS (or compatible driver) need not be loaded into memory. Avatar is a third emulation which is gaining popular acceptance in many programs. Avatar is like ANSI -- except that the codes are smaller and more compact, while providing the same level of control. The Avatar drivers are built into FKFOSSIL, and as a result no external .SYS driver is necessary. The avatar mode in FKFOSSIL is fully compatible with the AVT/0 standard. The AVT/0+ and AVT/1 standards have not been added to this version but will receive treatment in following versions. This is likely not a problem since the AVT/1 series adds windows and scrolling among other things, items which are not usually standard (and that some terminal programs don't even accept). There are probably many other terminal modes that I have avoided adding to this release. If people send me specs on those emulations I'll consider adding them to later releases of FKFOSSIL. _______________ DOOR DROP FILES _______________ One of the powerful features of FKFOSSIL is the ability to read and write door drop files. The files currently supported are DORINFO1.DEF and DOOR.SYS. If you wish to load the user information from the door drop files, you will need to call one of two commands. Your door should know WHICH doorfile it's going to read; if you want the ability to read both, you'd best have a configuration or command line switch to distinguish between the two. The information should be loaded BEFORE you start communications -- this is sort of obvious, because you need the information from those files to start communications. ;) FK_READDOORSYS will read the DOOR.SYS file, and FK_READDORINFO will read the DORINFO1.DEF file. Both are easy to use, and both provide different information. For the DOOR.SYS file, call the command fk_ReadDOORSYS(dir) where dir is the directory that the DOOR.SYS file is to be found in. If you want the current directory, put '' as the value of dir. For the DORINFO1.DEF file, call the command fk_ReadDORINFO(dir) where dir is the directory that the DORINFO1.DEF file is to be found. REMEMBER TO CALL THE DOOR INFO FILE READING _BEFORE_ YOU CALL THE INITIALIZE COMMUNICATIONS COMMAND. To make things easier on you, you do not need to call the FK_INITFOSSIL command. Instead, call FK_INITFOSSIL_DF which only requires 1 parameter instead of the 7 that the FK_INITFOSSIL requires. Please note that the FK_INITFOSSIL_DF should _only_ be run if the doorfile read was done, and is successful. Program Example4_1; fk_ReadDORINFO(''); if fk_Host.Error <> 9 then BEGIN fk_Initfossil_DF(25); {...} fk_DeInitfossil; END; By checking the fk_Host.Error parameter, which handles errors in the FKFOSSIL functions, you can determine whether the doorfile was found and read okay. Writing door files is another matter; it requires that you have loaded the correct information into the fk_Client variables so that when the door drop files are written, they are complete. If you read in one door file, and write another -- the information may not be entirely complete, but it will allow another program to pickup on some of the necessary information. THe procedures for writing door files are fk_WriteDOORSYS(dir) where "dir" is the path where the DOOR.SYS file is to be written, and fk_WriteDORINFO(dir) where "dir" is path to write DORINFO1.DEF to. The node fields in each of the files is controlled with the fk_Host.Node variable -- so if you are on node two, make sure to set fk_Host.Node to 2, so that if you choose to write a door file, the internal changes are made to the data files (notably DOOR.SYS). ____________ FILE SHARING ____________ File sharing is sometimes required by door programs that load in multinode environments. This has been made a little easier by FKFOSSIL, in the sense that it automatically detects upon loadup the existance of SHARE.EXE. You can use the variable FK_TASK.SHARE to determine whether to set FILEMODE to share files or not. Please note that you should not set the FILEMODE variable if SHARE.EXE is not loaded. If you do, your program will only work in a shared environment, and if it runs in an environment where SHARE.EXE is not loaded, will give run-time errors. This is why you must check the FK_TASK.SHARE boolean variable before playing with the FILEMODE variable. So if you check FK_TASK.SHARE and find it's true, you can then set the FILEMODE variable to the value that you want. These values are listed in the table below: SHARING METHOD ACCESS Compat. Deny All Deny Write Deny Read Deny None ------------------------------------------------------------------ Read Only 0 16 32 48 64 Write Only 1 17 33 49 65 Read/Write 2 18 34 50 66 ------------------------------------------------------------------ EXAMPLE 5_1; VAR f:file; BEGIN { Open in Read/Write mode, Deny Write } Assign(f,'EXAMPLE.DAT'); if fk_task.Share then Filemode := 34; Reset(f); ... Close(f); END. Just be careful with what you do and how you set this up. This is just a brief summary to help you get started. I suggest that if you want to write multinode compatible programs that you also look into record locking. ________________________ PROCEDURES AND FUNCTIONS ________________________ The following guide is a quick reference chart to all procedures and functions that FKFOSSIL provides. There are several modifier variables that affect the operation of these subroutines, and are listed in the section "VARIABLES AND CONSTANTS" in the main FKFOSSIL.DOC file. FK_ANSIMUSIC --------------------------------------------------------------------- Procedure fk_AnsiMusic( s : string ); fk_AnsiMusic will play the music string locally and then send it to the remote side. NOTE; Ansi Music is not an ANSI standard -- it only uses the term ansi because the string starts with the escape sequence #27[. Not all terminal programs will support Ansi Music if they support Ansi - check with user before sending anything with fk_AnsiMusic. The format of the music string "s" is like any BASIC PLAY statement, with a few minor exceptions. The commands are noted below; A..G Play musical note If followed by a number, that will be the note length (ignoring the preset length) -- ie, A4 will play "A" as a quarter note If followed by a # or + the note will be played sharp. If followed by a - the note will be played flat. If followed by any number of . (periods), the note length will be multiplied by 3/2 for each period (making the note last a little longer). L n Set the length of the note to n (1..64) MN Music Normal -- each note plays 7/8 length ML Music legato -- each note plays full length MS Music Staccato -- each note plays 3/4 length O n Set the octave number to n (0..6) P Pause (rest) If followed by a number, the pause will ignore the preset length and use the number as the length. T n Set the tempo of the music to n (32..255) > Increase octave one step < Decrease octave one step FK_BS --------------------------------------------------------------------- Procedure fk_BS( n : integer ); fk_BS will send backspace characters "n" times to effectively back the cursor up over already typed information. The cursor however will not backup past column 1 on any given line. FK_CLOCK --------------------------------------------------------------------- Procedure fk_Clock( b : boolean ); fk_Clock will turn off/on the timer clock. If B is set to false, the timer will be turned off. If B is set to true, the timer will be turned back on again. FK_CLREOL --------------------------------------------------------------------- Procedure fk_ClrEol; fk_ClrEol will clear to the end of the line in ANSI or Avatar mode. If the user is in TTY mode, fk_ClrEol will do nothing. FK_CLRSCR --------------------------------------------------------------------- Procedure fk_ClrScr; fk_ClrScr will clear the screen (local and remote) in any emulation mode. For ASCII/Avatar, CHR(12) is sent, and in ANSI mode #27[2J is sent. FK_DEINITFOSSIL --------------------------------------------------------------------- Procedure fk_DeInitFossil; fk_DeInitFossil will release the fossil driver (if running remotely) and remove the status line if active, and then exit the program. NOTE; this should be the LAST line in your source code. All files, and any clean up routines should be called before this procedure is run (or see the section "DEFINABLE FUNCTIONS"). FK_DETECTANSI --------------------------------------------------------------------- Function fk_DetectAnsi : Boolean; fk_DetectAnsi sends out the cursor placement query to the user, and checks for any response. If a response comes, then ANSI is present and fk_DetectAnsi returns TRUE, otherwise if no response if forthcoming and the timer reaches 0, fk_DetectAnsi returns FALSE. This function does not set the users screen type. If you want it to, you will need to do it yourself -- the procedure is only provided to allow you to check for Ansi. FK_DETECTAVATAR --------------------------------------------------------------------- Function fk_DetectAvatar : boolean; fk_DetectAvatar sends out the ANSI cursor placement query, and stores the X screen co-ordinates. If no response comes and the timer reaches 0, fk_DetectAvatar returns FALSE. If the response does come, an avatar repetition sequence is sent to the modem, and the cursor placement query is sent again. If the X co-ordinates move by more then 5 characters, fk_DetectAvatar returns TRUE, otherwise it returns FALSE (because the other terminal did not process the avatar sequence correctly). This function does not set the users screen type. If you want it to, you will need to do it yourself -- the procedure is only provided to allow you to check for Avatar. FK_DISPLAY --------------------------------------------------------------------- Procedure fk_Display( s : string ); fk_Display will send a file "s" to the local and remote screens. The "s" variable should be a full path, filename and extension to a valid file. If the user is in ANSI mode, ansi codes will be accepted. If the user is in Avatar mode, Avatar codes will be accepted. If the user is in TTY mode, straight text is expected. The better alternative to this procedure is FK_DISPLAYFILE; the alternate procedure requires no extension and automatically selects the most appropriate file (and if it doesn't exist, a fallback is chosen). If you need to access files with odd extensions, then this procedure will prove useful. FK_DISPLAYFILE --------------------------------------------------------------------- Procedure fk_Displayfile( s : string ); fk_Displayfile will send a file "s" to the local and remote screens. Any extension passed in "s" will automatically be stripped, and an appropriate extension (based on the users screen setting) will be selected. TTY -> .ASC Ansi -> .ANS Avatar -> .AVT If in Avatar/Ansi mode the file isn't found with .ANS or .AVT extensions, the fallback will be to .ASC extensions. So if any file needs to exist, it should always be the .ASC file as it will always be the fallback file if none of the others are found. FK_FLUSHINPUTBUFFER --------------------------------------------------------------------- Procedure fk_FlushInputBuffer; fk_FlushInputBuffer will clear the inbound keyboard buffers and fossil buffers so that no keystrokes are left pending. It's a good idea to call this before any important queries. FK_FLUSHOUTPUTBUFFER --------------------------------------------------------------------- Procedure fk_FlushOutputBuffer; fk_FlushOutputBuffer will clear the outbound modem buffer if there is anything still in the buffer. It is a good idea to call this before hanging up or dropping the DTR, etc... FK_GOTOXY --------------------------------------------------------------------- Procedure fk_GotoXY( X,Y : Byte ); fk_GotoXY will position the cursor at the (X,Y) coordinates on the screen. This function will only work with ANSI or Avatar modes selected. FK_INITFOSSIL --------------------------------------------------------------------- Procedure fk_InitFossil( Port, BPSrate, Lockedrate : Longint; Name, Handle : String; Timeleft : Longint; Screentype, StatuslinePos : Byte ); fk_InitFossil should be called BEFORE any other FKFOSSIL modem related routines are called. This will initialize the fossil driver and setup the minimal variables that FKFOSSIL requires to run (such as user timeleft, screen mode, etc...). Setting the BPSrate to 0 will cause FKFOSSIL to assume a local orientation. Setting the StatuslinePos to 0 will cause the statusline to not be shown until it is set to something other then 0. FK_INITFOSSIL_DF --------------------------------------------------------------------- fk_InitFossil_DF( StatuslinePos : Byte); fk_InitFossil_DF is an alternative to fk_InitFossil when you are using the DOOR DROP FILES. Since the DOOR DROP FILE routines automatically read the information into the necessary variables, it is not required to set them again via fk_InitFossil. FK_IDLETICK --------------------------------------------------------------------- Procedure fk_Idletick; fk_Idletick gives up timeslices to various multitasking programs -- OS/2, DESQview, DOS and Windows are all supported. This procedure is automatically called when an FKFOSSIL routine is polling the keyboard, but just in case you need it for something, here it is. FK_KEYPRESSED --------------------------------------------------------------------- Function fk_Keypressed : Boolean; fk_Keypressed returns TRUE if there are keys in the keyboard buffer or fossil buffer that are waiting to be read. FK_LOCALBUFFER --------------------------------------------------------------------- Procedure fk_LocalBuffer( s : string ); fk_LocalBuffer will add the string of characters "s" to the inbound local keyboard buffer. This can be used to add characters as if the local keyboard actually typed in those keys. (For remote buffer, see FK_REMOTEBUFFER) FK_LOCALBUFFERCLEAR --------------------------------------------------------------------- Procedure fk_LocalBufferClear; fk_LocalBufferClear will empty the buffer of stored characters. This function does not empty the systems keyboard buffer. fk_FlushInputBuffer will also empty the stored buffer. FK_MOVECURSOR --------------------------------------------------------------------- Procedure fk_MoveCursor( n : byte; dir : char ); fk_MoveCursor will move the cursor n times in the direction of "dir". Dir should be any of the following; U Up L Left D Down R Right This function will only work in ANSI or Avatar modes. FK_NOWAITREAD --------------------------------------------------------------------- function fk_NoWaitRead : Char; fk_NoWaitRead will poll the keyboard if there are any characters waiting. If characters are found in the local or remote buffers, then the character will be returned by fk_NoWaitRead. FK_READ --------------------------------------------------------------------- Function fk_Read : Char; fk_Read will poll the keyboard for any waiting characters. If none are found, fk_Read will wait until there are some (or the last keypress timer runs out). When a character is found, it will be returned by fk_Read. FK_READLN --------------------------------------------------------------------- Function fk_Readln( n : byte; up : boolean ):String; fk_Readln will read in a string of n characters long (max). If UP then the string will be returned in uppercase. fk_Readln will end when the user presses CR or runs out of time. To control the input of strings, see the VARIABLES AND CONSTANTS section. FK_REMOTEBUFFER --------------------------------------------------------------------- Procedure fk_RemoteBuffer( s : string ); fk_RemoteBuffer will add the string of characters "s" to the inbound user keyboard buffer. This can be used to add characters as if the user actually typed in those keys. (For local buffer, see FK_LOCALBUFFER) FK_REMOTEBUFFERCLEAR --------------------------------------------------------------------- Procedure fk_RemoteBufferClear; fk_RemoteBufferClear will empty the buffer of stored characters. This function does not empty to fossil buffer. fk_FlushInputBuffer will also empty the stored buffer. FK_REMOTEKEYPRESSED --------------------------------------------------------------------- Function fk_RemoteKeypressed : boolean; fk_RemoteKeypressed will return TRUE if there are characters waiting in the inbound remote buffer, and FALSE if there are no characters waiting. This only works for the REMOTE keyboard, like the Turbo Pascal function KEYPRESSED works for the local keyboard. To combine the two tests (to see if there are any waiting characters anywhere), see FK_KEYPRESSED. FK_REMOTEWRITE --------------------------------------------------------------------- Procedure fk_RemoteWrite( s : string ); fk_RemoteWrite will send the string "s" to the comport. If it is a local connection, this routine will do nothing. If the remote screen has been turned off (see FK_HOST.REMOTESCREEN variable) then the output won't go to the remote side either. FK_REMOTEWRITELN --------------------------------------------------------------------- Procedure fk_RemoteWriteln( s : string; n : integer ); fk_RemoteWriteln operates exactly like fk_RemoteWrite except will it follow by outputting "n" occurrences of CR/LF (next line). If "n" is 0, then there will be no CR/LF's appended, and fk_RemoteWriteln will operate like exactly fk_RemoteWrite. ie fk_RemoteWriteln('Tim',0) is the same as fk_RemoteWrite('Tim'); FK_TEXTBACKGROUND --------------------------------------------------------------------- Procedure fk_TextBackground( n : byte ); fk_TextBackground will change the background colour attribute, and retain the last foreground attribute. FK_TEXTCOLOR / FK_TEXTCOLOUR --------------------------------------------------------------------- Procedure fk_TextColour( n : byte ); fk_TextColour will set the remote screen attribute and local screen attributes. The n byte is a combined foreground/background/blink number which will be used to set all the colour attributes at once and operates like the TextAttr:= variable in Turbo Pascal. To get the combined number, say for yellow (14) on red (4) do something like fk_TextColour(14+(4*16)); For each background number, the actual n byte will increase by 16. To add a blink to the yellow on red, 128 will be added to the value of n fk_TextColour(14+(4*16)+128); If you are familiar with the TextAttr variable in Turbo Pascal this will be an easy to follow function. If however you wish to set the foreground and background attributes separately there are the FK_TEXTFOREGROUND and FK_TEXTBACKGROUND functions to use. ANSI and Avatar codes will be sent when the user has either of the respective screen emulations. If the user is in TTY mode, the colour will not change. The local screen colour will be changed if the user is in ANSI or Avatar mode, and in TTY mode if strict colour is off (see VARIABLES AND CONSTANTS section). FK_TEXTFOREGROUND --------------------------------------------------------------------- Procedure fk_TextForeground( n : byte ); fk_TextForeground will change the foreground attribute only, leaving the background attribute as is. If you wish the foreground to blink, add 128 to the n byte. FK_TIMELEFT --------------------------------------------------------------------- Function fk_Timeleft : String; fk_Timeleft will return the users timeleft in the string variable in the format of [-]HH:MM:SS. The string will be padded with 0's in empty spaces, so it will always have a length of 8 characters (unless the user has negative time left when the length will be 9). FK_TOGGLEDTR --------------------------------------------------------------------- Procedure fk_ToggleDTR( Up : Boolean ); fk_ToggleDTR will raise or lower the DTR of the modem. If UP is TRUE then the DTR will be raised, if UP is FALSE the DTR will be lowered. Lowering the DTR while there is a carrier will cause the modem to hangup on the user (if the modem has been setup to do so). This is the fastest method of logging off a user. If you drop the DTR for a second or two, and then raise it again, the user should be off. FK_WRITE --------------------------------------------------------------------- Procedure fk_Write( s : string ); fk_Write will send the string "s" to the comport and the local screen. There are several modifier variables that can be used to change the output of this procedure; see FK_HOST.REMOTESCREEN and FK_HOST.HOSTSCREEN in the variables section for more information. FK_WRITELN --------------------------------------------------------------------- Procedure fk_Writeln( s : string; n : integer ); fk_Writeln operates exactly like fk_Write except will it follow by outputting "n" occurrences of CR/LF (next line). If "n" is 0, then there will be no CR/LF's appended, and fk_Writeln will operate like exactly fk_Write. FK_WRITELN_ANSI --------------------------------------------------------------------- Procedure fk_Writeln_Ansi( s : string; n : integer ); fk_Writeln_Ansi operates exactly like fk_Writeln except that the string "s" can contain ansi sequences. FKFOSSIL uses it's own built in ANSI interpreter to handle the sequences -- this disables most of the redundant and dangerous sequences such as Keyboard remapping, etc. If the string is going to have ANSI sequences in it, use this procedure. FK_WRITELN_AVATAR --------------------------------------------------------------------- Procedure fk_Writeln_Avatar( s : string; n : integer ); fk_Writeln_Avatar operates exactly like fk_Writeln except that the string "s" can contain Avatar/0 sequences. FKFOSSIL uses it's own built in avatar interpreter to handle the sequences. _______________________ VARIABLES AND CONSTANTS _______________________ The following guide is a quick reference chart to all variables and constants the FKFOSSIL provides. CONSTANTS -------------------------------------------------------------------- fk_StandardInput = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUV' +'WXYZ1234567890~!@#$%^&*()-+\[]{};:`''".,/<> =_?|' fk_highBitInput = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUV' +'WXYZ1234567890~!@#$%^&*()-+\[]{};:`''".,/<> =_?|' +'ÇüéâäàåçêëèïîìÄÅÉæÆôöòûùÿÖÜ¢£¥₧ƒáíóúñÑªº¿⌐¬½¼¡«' +'»░▒▓│┤╡╢║╕╣║╗╝╜╛┐└┴┬├─┼╞╟╚╔╩╦╠═╬╧╨╤╥╙╘╒╓╫╪┘┌█▄▌▐' +'▀αßΓπΣσµτΦΘΩδ∞φε∩≡±≥≤⌠⌡÷≈°∙·√ⁿ²■'; fk_FilenameInput = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUV' +'WXYZ1234567890~!@#$%^&()-_{}.'; fk_FilespecInput = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUV' +'WXYZ1234567890~!@#$%^&()-_{}.?*'; fk_FilepathInput = 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUV' +'WXYZ1234567890~!@#$%^&()-_{}.?*:\'; fk_NumberInput = '123456790.-+'; The "input" constants can be used to defined the input that is allowed by the fk_Readln function. There are probably other users for these constants, but the primary purpose was for the input definition. See the variable FK_HOST.VALIDINPUT. fk_DriverVersion = '1.02'; fk_DriverName = 'Forbidden Knights Fossil/Door Driver Unit'; fk_DriverAuthor = 'Tim Strike'; On = True; Off = False; All define other constants that can be used. If you want to include a notice of the routines that are being used but don't wish to change the information for changes in FKFOSSIL versions, the info constants fk_DriverVersion, fk_DriverName and fk_DriverAuthor might help you out. For any BOOLEAN function, the ON and OFF constants have been defined. For instance, if you want the boolean variable BOB to be true, you could use BOB:=TRUE or BOB:=ON. This is just for simplicity sake, it really holds no advantage. FOSSIL INFORMATION --------------------------------------------------------------------- The Fossil Information Variables contain information on the fossil driver version and the connection information. Do *NOT* set any of these variables yourself unless you know what you are doing. fk_Fossil.Started Boolean True if fk_InitFossil has been called. If false, the other fossil dependant routines will not run. fk_Fossil.Port Longint Current port fk_Fossil.Baud Longint Current connection BPS rate fk_Fossil.Locked Longint Current locked BPS rate fk_Fossil.Carrier Boolean True if there is a modem carrier fk_Fossil.Driver Str(80) Fossil Driver Name fk_Fossil.Version Byte Fossil Driver Major Version No. fk_Fossil.Revision Byte Fossil Driver Minor Revision No. PROGRAM INFORMATION --------------------------------------------------------------------- The Program information variables contain information about your program. This information is displayed if the title line is in use. These variables need not be set if you are not using the title line. fk_ProgramInfo.Title Str(25) Your Program Title fk_ProgramInfo.Version Str(8) Program Version fk_ProgramInfo.Author Str(20) Author Information fk_ProgramInfo.Other Str(20) Other Information TASK INFORMATION --------------------------------------------------------------------- The Task Information variables contain all the information on the current task type. These variables are automatically tested for when your program is run, and should *NOT* be changed at all. fk_Task.System Str(15) Contains name and version of OS; Supports DOS, Windows, DESQview and OS/2. All OS's compatible with DOS will be listed as "DOS". fk_Task.Tasktype Byte Contains the task type; 0 DOS 1 DESQview 2 OS/2 3 Windows fk_Task.Window Integer Active window number (DESQview Only) fk_Task.Share Boolean If SHARE is active (use for file sharing test -- see the section on FILE SHARING) CLIENT INFORMATION --------------------------------------------------------------------- The Client Information variables hold information on the user who is currently online. Some of the variables require settings -- however if you are not using the door drop file routines to read in the user information, not all of the variables will be available. DS indicates this variable can be retrieved via DOOR.SYS. DI indicates this variable can be retrieved via DORINFO#.DEF. MI indicates this is required information and is set through the fk_InitFossil routine if the doorfiles aren't read. fk_Client.BBSName Str(35) BBS System Name DI fk_Client.Calls Longint # of Calls DS fk_Client.Citystate Str(30) User's City/State DS,DI fk_Client.Downloads Longint # of Downloads DS fk_Client.Firstdate Str(8) First Calling Date fk_Client.Handle Str(35) User's Handle MI,DS,DI fk_Client.HomePhone Str(15) Home/Voice Phone Number DS fk_Client.Lastdate Str(8) Last Calling Date DS fk_Client.Lasttime Str(5) Last Calling Time fk_Client.Name Str(35) User's Real Name MI,DS,DI fk_Client.Pagelength Byte Pagelength DS fk_Client.Password Str(30) User's Password DS fk_Client.RecordPos Longint Record Position (file) DS fk_Client.Screentype Byte Screen Mode; 0 TTY MI,DS,DI 1 ANSI 2 AVATAR fk_Client.Security Longint Security Level DS,DI fk_Client.SysOpName Str(35) BBS SysOp Name DI fk_Client.Timeleft Longint Time Remaining (seconds) MI,DS,DI fk_Client.Uploads Longint # of Uploads DS fk_Client.WorkPhone Str(15) Work/Data Phone DS If the information isn't gathered, default (empty/nul) values will be given for each of the fields. MUSIC INFORMATION --------------------------------------------------------------------- The Music Information variables contain the information that is used by the ANSI Music function; such as default Octave, Tempo, etc. fk_Music.Musictype Byte Current Music Type; 6 Staccato 7 Normal 8 Legato fk_Music.Notelength Byte Note Length (default = 4, Quarter) fk_Music.Octave Byte Current Octave (default = 4) fk_Music.Tempo Byte Current Tempo (default = 120) HOST INFORMATION --------------------------------------------------------------------- The Host Information variables contain all the toggles, switches etc that can be configured by you for your program. The defaults for most general purposes will not need to be changed. fk_Host.AnsiTimer Word Countdown for Ansi Detection. If this count down reaches 0 before the codes are received, the fk_AnsiDetect routine will return false. (default = 2500) fk_Host.Blink Boolean Blinking Attribute. Used by the colour routines; it is not suggested that you reset the value of this variable. fk_Host.Clock Boolean Decrease Time and Increase Lastkey. If FALSE, then time will not be counted (could be used for intensive procedures -- or during chat or something similar). It is a lot better to use fk_Clock to turn the time on and off, since the fk_Clock routine will take care of all the variables that fk_Host.Clock affects. (default = TRUE) fk_Host.CurrentInput Str(80) The default output for fk_Readln. Sets up the string for fk_Readln with this value -- this value is NOT written to the screen (you should do this) but will be used as if the user had already typed this in. fk_Host.Error Byte Contains information on the last run procedure; 0 No Errors 1 Fossil Driver Not Initialized 2 Error Initializing Fossil Driver 9 File Not Found 10 Function Not Compatible with Users Screen Mode 11 Invalid Call to Function fk_Host.ExitCode Byte Contains exit code that fk_DeInitFossil will exit with. If your program encounters an error (and you wish to exit with a different errorlevel) set this variable and then call fk_DeInitFossil. (default = 0) fk_Host.High Boolean High-Bit (bright foreground). Used by the colour routines; it is not suggested that you reset the value of this variable. fk_Host.HostScreen Boolean Send information to local screen - If FALSE, no information from any of the fk_Write[ln] functions will be sent to the local screen (although the status bar will still be active) (default = TRUE) fk_Host.Hostkey Boolean Get information from local keyboard - If FALSE, no keys pressed on the local side will be processed during any of the fk_Read[ln] functions. (default = TRUE) fk_Host.Inactivity Word Count down in seconds for user Inactivity. If the user does not hit a key for this number of seconds, the program will automatically end. (default = 180 seconds, 3 minutes) fk_Host.Lastbg Byte Last background attribute fk_Host.Lastfg Byte Last foreground attribute fk_Host.Mono Boolean Monochrome Monitor (local) ** All three variables are used by the colour/write routines. It is not suggested that they be changed and should be used for reference only (otherwise you create the risk of messing up your program). fk_Host.Multinode Boolean Stores whether the system is running in a multinode environment. If TRUE, the value of fk_Host.Node will be displayed on the status line. fk_Host.Node Byte Stores the node number value. This will be used when reading/writing door drop files, and also displayed on the status line if the fk_Host.Multinode is TRUE. (default = 1) fk_Host.OutputChar Char Send this character in the fk_Readln function. Since the fk_Readln reads in characters and displays them, this function can be used to override the character returned. If it's set to CHR(0) then whatever the user types will be returned. However, if it's set to say, CHR(178) then the ▓ character will be sent, regardless of what the user typed. This is a good function for password input or other sensitive items. ALWAYS MAKE SURE THAT YOU RESET THE VALUE TO CHR(0)! fk_Host.Outputlines Word The number of output lines sent to the user. This is handy if you want to have screen pauses -- Just check this value, if it's greater then the screen length, pause for a key and reset this variable. In some areas, after you clear a screen or any other sort of "pause", you may wish to reset the value. fk_Host.RemoteScreen Boolean Send information to remote screen - If FALSE, no information from any of the fk_Write[ln] functions will be sent to the remote screen (although the status bar will still be active) (default = TRUE) fk_Host.Remotekey Boolean Get information from remote buffer - If FALSE, no keys pressed on the remote side will be processed during any of the fk_Read[ln] functions. (default = TRUE) fk_Host.Sound Boolean Local Sound Toggle - if in Local mode the default is TRUE, otherwise the default is FALSE. To hear any Ansi Music or CHR(7) Beeps locally, this variable needs to be TRUE. fk_Host.StatuslineBuf Byte The number of blank lines setup before the actual status line. (default = 1) fk_Host.StatuslinePos Byte The position of the status line. (default = 25) 0 will disable the status line 1-10 will place the active window below the status line position. 11-25 will place the active window above the status line position. fk_Host.StrictColour Boolean If TRUE, then if the user is in TTY mode any colour changes will be ignored. If FALSE and the user is in TTY mode, all changes of colour will be displayed as normal locally. (default = TRUE) fk_Host.Timeslice Boolean If TRUE, FKFOSSIL will attempt to give up unused timeslices to the OS/Multitasker. (default = TRUE) fk_Host.Titleline Boolean If TRUE and the status line position is 25, then a second title line will be added at line 24. On this line, the information in the fk_ProgramInfo variables will be displayed. (default = FALSE) fk_Host.ValidInput String Determines the allowable characters for the fk_Readln function. If you set this string to 'ABC' then the fk_Readln function will only accept an A, B or C. Several constants have been provided so that you don't need to type in all the characters all the time. (default = fk_StandardInput) For example; number input; fk_Host.ValidInput:=fk_NumberInput; fk_Readln(nums,false); fk_Host.ValidInput:=fk_StandardInput; filename input; fk_Host.ValidInput:=fk_FilenameInput; fk_Readln(fname,true); fk_Host.ValudInput:=fk_StandardInput; defined input; fk_Host.ValidInput:='TIM_STRIKE' fk_Readln(fname,true); fk_Host.ValidInput:=fk_StandardInput; Never set the fk_Host.ValidInput variable to a null string ('') as the fk_Readln function will cease to work. Just remember to ALWAYS turn the input type back so that you don't forget to do it later (unless you need one input type for the whole program, etc...) fk_Host.WaitforChar Boolean If TRUE, the fk_Read function will wait for a character, otherwise it won't. The MUCH better alternative to this variable is the function fk_NoWaitRead since you won't need to remember to reset the variable. (default = TRUE) fk_Host.WarningBell Boolean TRUE if warning bell (inactivity timeout) has been sent to the user. fk_Host.WarningTime Boolean TRUE if timeleft warning has been sent to the user. ** It is not suggested that the warning variables be reset, unless there is a specific need. FKFOSSIL will automatically handle the warning variables itself. COLOUR INFORMATION --------------------------------------------------------------------- The Colour Information variables define the status line display colours. These should be set BEFORE you call the fk_InitFossil procedure. fk_Host.Colour.Baud Baud Rate (default = 9,1) fk_Host.Colour.Handle Handle (default = 11,1) fk_Host.Colour.InfoDesc Descriptors (default = 9,1) fk_Host.Colour.Lastkey Lastkey Timer (default = 11,1) fk_Host.Colour.Multitasker Multitasker Type (default = 9,1) fk_Host.Colour.Name Real Name (default = 14,1) fk_Host.Colour.Node Node Marker (default = 9,1) fk_Host.Colour.NoTimeleft No User Time Left (default = 12,1) fk_Host.Colour.Screentype Emulation Mode (default = 9,1) fk_Host.Colour.Statusline Empty Space (default = 1,1) fk_Host.Colour.Timeleft User Time Left (default = 11,1) fk_Host.Colour.Titleline Program Info (default = 11,1) fk_Host.Colour.Warning Warning Sent (default = 12,1,B) For monochrome monitors the attributes are all set to black on white (reverse video) and should easily be seen. Let me know, I don't have a mono monitor. ;) For colour monitors, the default is listed in the righthand column (foreground, background, blink). The colour attribute is a combination foreground, background & blink. To set it to Cyan on Black the value would be 11. To set it to Yellow on Red, the value would be 14+(4*16). To set the value to blinking Red on Blue, it would be 12+(1*16)+128. This is the same format used for the TextAttr command in TP. There is only one colour scheme setup. You can't switch from Mono to Colour without resetting the variables. When your program is run, FKFOSSIL will predefine the colour set based on whether a mono or colour monitor is detected. This will not work if the user has a black-white VGA system. If you plan on changing the status line colours, you may wish to check the FK_HOST.MONO variable to see if a mono or colour system is in use. Be careful! ___________________ DEFINABLE FUNCTIONS ___________________ What are definable functions? Good question. They are functions and procedures that FKFOSSIL runs internally that you can define externally. Each of these functions has a default "value" which you can override. It's relatively hard to explain how these types of functions work, but let's consider an example. If we have a function called KEY_SPECIAL which is run when a key is pressed -- let's say it resets a timer from the last keypress. Let's say we now create a function variable called "KEY_IN". KEY_IN will be set to equal KEY_SPECIAL, like KEY_IN := KEY_SPECIAL. Now, we only need to call KEY_IN and KEY_IN will notice that it's a pointer to another function, and run KEY_SPECIAL instead. Now, if you had a function called KEY_NORMAL, you could set KEY_IN := KEY_NORMAL and the next time the KEY_IN function was called, it would point to KEY_NORMAL and run that function instead. What is essentially boils down to are functions that are called in a program/part of a program can be given a "tag", and whenever that "tag" is found, it will run the function that tag points to. FKFOSSIL has these routines so that you can replace some of the defaults with other defaults. For instance, if you were writing a callback program, you would quickly find that once you hungup on the user, FKFOSSIL would detect the hangup and bail out. This is obviously undesirable because you wouldn't be able to call the user back. Consider now that we have a function called fk_NoCarrier; fk_NoCarrier has been set to a function which will exit the program. If you set fk_NoCarrier to another (perhaps empty) function, it will no longer exit the program but rather return to whatever it was doing. To setup your "override" functions, you must set them up to match exactly the type of function you are replacing. So if the function are you replacing is Function 8_1(ch:Char):Char then your function must also be (ch:Char):Char. The function must also be setup as a FAR call. To do this, you put {$F+} before the function. Make sure that you put {$F-} after the function so that it saves you memory/space when compiling (no need to setup your entire code to be a FAR call). The replaceable functions are as follows -- the defaults are the values that you should return the variable to after you are done with your "override". All of those functions have the same name as the initial variable, except read fkp_ instead of fk_ (note the one exception to this rule; the input routines). VARIABLE FUNCTION/PROCEDURE TYPE INFORMATION / DEFAULT -------------------------------------------------------------------- fk_LocalInput Function(Ch:Char):Char Processed when local input is received. Char is the return character -- if you are not doing anything with the actual character, make sure that your function returns CH variable. (default = fkp_input) fk_RemoteInput Function(Ch:Char):Char Same as fk_LocalInput except for remote input. (default = fkp_input) fk_CarrierLoss Procedure Run during any input session if the carrier is not online. (default = fkp_Carrierloss) fk_Timeout Procedure Run when the user times out in any input session (doesn't press a key for the specified period). (default = fkp_Timeout) fk_NoTimeLeft Procedure Run when the user's time run's out in any input session. (default = fkp_notimeleft) fk_Close Procedure Run when the fossil driver is shut down via fk_Deinitfossil. (default = fkp_Close) fk_Open Procedure Run when the fossil driver is first started via fk_InitFossil[_DF]. (default = fkp_Open) fk_MCI Function(s:string):string Run when the fk_Display functions are displaying the files. Every line is passed through and a return line is received. (default = fkp_MCI) EXAMPLE 8_1; {$F+} Procedure Replace_NoCarrier; BEGIN END; {$F-} BEGIN fk_Writeln('We are about to drop carrier to call you back.',1); (* Replace fk_Carrierloss so that the program doesn't exit when the carrier is dropped (we want to drop it... ;) *) fk_Carrierloss:= Replace_NoCarrier; fk_DropDTR(false); Delay(1000); fk_DropDTR(true); Delay(1000); fk_Writeln('ATDT416-820-7273',1); ... fk_Writeln('Callback successful!',1); (* Return the fk_Carrierloss function back to normal so that if the user hangs up at this point, it will exit! *) fk_Carrierloss := fkp_NoCarrier; END. If you have never used definable functions and variables, then I highly suggest that you learn how to use them before attempting to set them up with FKFOSSIL. The defaults do everything that you need to them to do in regular release programs, except some items, like callback doors, timebanks, etc... may require specialized versions of those routines. ________ VERSIONS ________ This section will always contain the history/update information on this program. It will list a general summary of bug fixes and new features. Please read this section on every upgrade, even if you don't plan on reading any other section. +:New Feature *:Updated (Fixed) Feature !!:Important to Note v1.00 + Compiled in Turbo Pascal 6.0 and 7.0 + First release to the general public. v1.01 * Internal FKFOSSIL version. v1.02 + Added fk_Clock routine so the clock can be started and stopped without having to worry about the many different variables. fk_Clock(false) turns the timer clock off (users time and last keypress won't be updated), and fk_Clock(true) turns the timer clock on (users time and last keypress will be updated). + Added fk_DetectAvatar routine to determine the presence of avatar on the remote system. + Added keyboard buffers - the buffer can be added to with fk_localbuffer(s) or fk_remotebuffer(s). The buffers can be cleared with fk_localbufferclear and fk_remotebufferclear. Buffers will be processed before the internal keyboard bufferor the fossil buffer if they contain any characters. The buffers can contain key sequences up to 255 characters long. + Added fk_notimeleft definable function so that customized warnings can be sent to the user, or a timebank function can be run, etc. * Fixed fk_Writeln_Ansi so that a variable need NOT be passed; it's just a string now S:STRING instead of VAR S:STRING. * Fixed problems with a routine which would inadvertently wipe out some memory during the initialization of the status line. In most cases, this memory was at the top end and held nothing important. However, in secondary windows on multitasking machines and sometimes on non-multitasking machines, this wiped out memory would cause intermitent problems (incl. system hangs). Thanks to John Zielinksi for tracking this one down - otherwise it likely would have been left unnoticed. * Fixed display(file) routines so that the filemode is returned to it's original value. * Fixed time checking so there are no more midnight timeout's. * Fixed music frequencies so they are a little more correct on the local side. * fk_AnsiMusic routine no longer requires a second parameter. The parameter "Force" turned out to be useless and cumbersome. If you want to send ansi music to the user, check to see if they support it first. Then you can do something like "If userrec.ansimusic then fk_AnsiMusic(music);". * Ansi music strings sent to the modem now start with sequence "ESC[M " instead of "ESC[MN", and now end with " CHR(14)" as the ansi music standard specified. __________ LEGALITIES __________ WARRANTY FKFOSSIL is provided as-is, without a warranty of any kind, either expressed or implied. It is only guaranteed to occupy disk space, nothing more. Under no circumstances shall the author be liable to you or anyone else for any damages, including (but not limited to) any lost profits, lost savings or other incidental or consequential damages arising out of the use or misuse of these programming routines. In other words; USE THESE ROUTINES AT YOUR OWN RISK. You yourself, and nobody else is responsible for the outcome of choosing to use these routines. COPYRIGHT The program, and all documents and files included in the original FKFOSSIL release package are copyrighted by Tim Strike and Forbidden Knights Systems. They are not to be modified in any way, shape or form; The distribution archive may be changed from ARJ/ZIP to another archive form, as long as no files are added or removed from the release archive. When you use FKFOSSIL in your programs, our copyright on the routines is still held and you should acknowledge the fact that portions of your program are copyright by Forbidden Knights Systems. FKFOSSIL may be packaged on a distribution diskette or in a compilation archive, but under no circumstances may any charge be incurred beyond the physical cost of the hardware (disks, CD...) or transfer medium (phone, mail...). To include FKFOSSIL in any type of "compilation archive", you must first have the express written consent of Tim Strike and Forbidden Knights Systems. CREDITS All brand and product names referenced in this document are trademarks, registered trademarks, or copyrighted works of their respective holders. _____________________ CONTACTING THE AUTHOR _____________________ I can be contacted in a number of different methods. When sending netmail or posting in one of the conferences, direct mail to "Tim Strike". Replies will be forthcoming as soon as I can get to them. NETMAIL: Telenet Canada Fidonet Xnet 20:22/101 1:259/423 40:41/108 ECHOMAIL CONFERENCES: PASCAL Pascal Help (FIDO) TNC_FKNIGHTS Forbidden Knights Support (TNC) TNC_PROGRAM Programming Help (TNC) XNET_PROGRAM Programming Help (XNET) POSTAL MAIL: Forbidden Knights Systems Attn: Tim Strike 3360 Council Ring Rd, Unit 11 Mississauga, ON L5L 2E4 BULLETIN BOARD: Forbidden Knights Systems (905)820-7273 2400-16,800 HST/v.32bis Access denied between 4:00am and 5:00am Restricted access between 9:00pm and 10:00pm Guest account available. Any changes or upgrades that need to be made to FKFOSSIL v1.02 will be made as time permits. Further suggestions, comments and/or bug reports can be directed through one of the above methods. Enjoy.