Introduction ------------ This chapter is an introduction to the Trion BBS system. It contains lists of contents of the chapters of this manual. Information on how to install the BBS system. Information on how it came to be and on the trion design philosophy and the programs involved. Design philosophy ----------------- First a little history in computers :) I bought my first computer in februari 1983, it was a Commodore Vic-20, at that point in time it was apparantly so new that the tape-recorder for data storage and a basic course where delivered weeks later. But that didn't matter at the time, I was almost 15 years old and it was very exiting. After tuning the TV to the computer it was ready to accept commands !! All I had was the little thin manual that came with it, but it had all the information you needed and a step by step course with example programs. So add the end of that day I had worked through the whole manual and was modifying the examples and writing my own little programs. But the Vic-20 was very limited, it could only fit 22 x 23 characters on the screen and the whole system had 5,5 KB of RAM memory. Even with a 16 KB expansion module it was time for something better. In juli 1984 I bought a Commodore-64 !! It had sprites, a synthesizer chip and real hires graphical modes instead of the kludge on the Vic-20 with the user-definable characters. It was like the Amiga of it's time !! It popped up in every magazine that had something to do with electronic machines. In may 1995 I got a diskdrive for it which made it a real computer ! :) On this machine I really start experimenting, everytime there was something about computers on TV I started to wite a program for it. Fractals, little games, simulators, mathematics you name it. I learned machine language which could accelerate the basic programs enormously. I started to write a little graphical library and even a little multitasking kernel for it. This code was used in little demos and all kind of experimental things. Later me and a friend started to wire our computers together with the serial ports and started to write like little terminal and BBS programs for it deep into the night. That was the first step altough we had never heard of BBS's. Later we started playing with old terminals which we connected through our own little circuits with a computer. Later we started to read about the Amiga in the commodore magazines, there were even adds for demonstrations in the newspaper but it was far to expensive. So I bought a Sinclair Quantum Leap which were sold at dump prises at that time. It cost only a fifth of the prize it was when it was introduced. It was powered by a 68008 processor had nice 16 color hi-res modes a quick basic with many commands a tiny loudspeaker that could only make beep noises little buildin tape drives (stringy floppies) .. but it certainly was no Amiga. But along came the Amiga 500 !! It was unbelievable, a real Amiga for a very low price. So when I saved enough money in august of 1987 an Amiga replaced the Quantum Leap but the Vic-20 and C-64 got a place next to it. The Amiga was great, but it only had this slow basic and not the programming information and the total in control feel you had while programming it like the C-64 had. So the C-64 was still used a lot for programming and testing little things. In januari 1989 the A-500 had to make place for an A-2000 with an A-2088 PC-bridgeboard and an A-1084 monitor. A year later followed with a 40 MB Golem harddisk card which came with a PC-controller board kludged to the Zorro bus. In that same time I got a "state of the art" 2400 baud modem and started downloading and pointing !! Calling BBS's was great but it was even greater if my computer would be reachable by phone. So along came the big search for BBS programs. I found a few but nothing really useable. In the meantime the NEC 40Mb harddisk broke down, and was replaced with a Macrosystem Evolution SCSI-controller with a Quantum LPS-240 MB harddisk. Also i got a A2630 Turbo-board and a C-compiler ! Which gave me a top of the line system, but cost a fortune at the time. In april of 1992 we moved house and I got a phone line of my own !! So in may 1992 I shelved out a few hundred US dollars and bought the Xenolink BBS program. Not the V2.0 that is around now but something like "V1.0 y1". It turned out that the "feature list" was a "todo list". And for things like Allfiles programs, Full screen editors you had to wait until some third party made one. Tick processors and Areafix programs were a long way of. Also it had its quirks, if it got a message that was bigger than 32K (UUencoded files) it crashed. And if it survived than it crashed for other reasons. It could do all kind of things like include a random piece of harddisk in a message, which it still does in V2.0 to this very day !! Other sysops in the neighbourhood ran it too, we even setup maillinks and altough I checked their configuration files often systems wouldn't call out or export mail. I wrote a few programs for Xenolink but after a little time the old C-64 mentality came up. I got a stack of "AMIGA ROM Kernel reference Manuals" so I could really understand and program the Amiga. In september of 1992 the first affordable V32B modem with a rockwell chipset appeared it was the Suprafax V32B, altough it cost about the same as I paid for the Vic-20 or the C-64 when they just appeared at the market I got one !! Mainly because simple calculations showed that with 6 times the speed of the 2400 modem it should pay for itself in no time by reducing my phone bill ;) Halfway 1993 I started to write experimental parts of a BBS program. And in early 1994 I combined it into a complete little BBS program. In the same time something weird happend, the Xenolink support site had swindled a number of people, including me. The person who ran the site had a key generator to suply buyers with the complete package including a manual but at a certain moment he stopped transfering the money he received to the programmer. This was discovered after a new support site was set up, so suddenly I became an "illegal user" and was trown out of the xenolink support, altough I not only had paid the old official support site for the software but also just paid the new official support site the yearly contribution for updates and third party programs. The weirdest part of this incident was that half of the sysops that paid the old support site was accepted, and the other half was thrown out .. depending on when you bought the program. If you where thrown out you could get back in by paying again .. the amount of money depended on how long you waited before you did it. At the beginning you had to pay the same as "new" sysops .. if you waited a few years until the Version 1.90 upgrade including manual was released it was free. So the Tron BBS system was born. I switched to my own software and started really developing it. And in September 1994 the first interested sysops started calling me. Soon I had a couple of beta testers and was writting things like an allfiles program and a mail processor. In 1995 the source got so big I got a second hand tape-streamer to be able to make Quick back ups. Also I got a second hand 1x speed CD-rom device to be able to make a CD-rom door. Also that year the Quantum HD only worked part of the time after a lightning hit in a field very nearby. So it was replaced with a 512MB IBM SCSI harddisk. Later someone setup a web-page for "the Tron-BBS system", but a company called "Tron" used a BBS-system to be reachable for it's clients. Which also was called "the Tron-BBS system". They actually had the name Tron registered so the name Trion BBS system was born :) Before I started to program the BBS program, I had written down how it should look like when it was finished. The system I described then is basically what a modern Internet Web browser looks like. But the result is a little bit conservative compared with BBS's and web browsers. During the programing I had a simple philosophy: Keep things simple, don't start with difficult constructions. Take little steps at a time, to keep the code solid and bug free. Do things right the first time! Don't write weird hacks. Write things yourself, don't shop around for source code that if you can find it doesn't live up to the standard and is probably less sophisticated then what you already have thought up in your head looking for the function. Speed and storage efficiency are important, but should not cause stability problems with weird complex code. Build in debug code so all (memory) bugs turn up in a log. It should be Shareware so people can play with it, so they see what they are paying for. Also the system should be integrated and complete, so you don't have to find a third party allfiles program that borderline works. So you don't need lastcaller hacks that have to scan log files each time they are started. So you have a system that is aware of what happens in the different parts like mail processor, tick processor, areafix program etc. Note that it is no coincedent that there are a few superficial simularities with xenolink. This does not mean that Trion is a clone of xenolink, it just means that the programmer of xenolink had some good ideas. All the Amiga BBS programs have some simularities but that doesn't mean that for instance xenolink would be a paragon clone. Architecture ------------ Introduction ------------ Trion BBS is a multi line BBS system with File and Mail capabilities. It has a mailer to poll other BBS systems to transfer mail and spawn voice and fax programs. It can run Cli and paragon doors. It can be controlled from dos by scripts and a cron utility. It can run doors and display RIPscrip graphics locally. Note: features are listed in "trion:docs/features.doc" How does it work ---------------- Resource manager The Trion BBS system is a multiline BBS package. Multiline means that you can start multiple BBS 'nodes' (each with a unique node number). These nodes can run locally or be connected to a serial port. Also multiple users can use the same 'resources' at the same time, this means that for instance 2 users can look at the same filecatalog section. To make all this possible a "resource manager" was needed. This resource manager is called "TrionRM" and must be run before any other Trion program can run. The 'Resource Manager' regulates all access to the data files, thanks to this more than 1 program can access the same file at the same time. This is needed so you can read mail at the same time as the mail processor is running, or 2 users can browse through the same file area. Also a user can't log on to two nodes at once because the resource manager won't allow it. Also this program has a "monitor" window which shows all kinds of important information, like what the status of a node is, a list of last callers and statistical data. This window can be Iconized if you don't need it at the moment. Also you can start all the GUI editors from this window. Note that the program has an option to open the "monitor" window on a public screen instead of on the workbench. In this mode the GUI's are able to use more colors. Mail The Trion BBS system is capable of running a fido compatible node. Which means it can call other BBS systems and exchange electronic mail and files. Mail means that users can write public (Echomail) or private (Netmail) messages that are exchanged with other BBS's in a "net". The best know of these nets is "Fido-net". For this purpose a number of programs are provided. When systems call each other the files that are received end up in the "inbound" directory. Files that are send to the other system are kept in the "outbound" directory. The mail processor is needed to to "unpack" archived packets of messages that are received in the "inbound" directory and store them in the messagebase. Also it collects the messages in the messagebase that have to be send to other systems and makes archived packets that are stored in the "outbound" directory until other systems pick them up. Also there is a "Tick processor", which is a program that collects files from the "inbound" directory and adds them to the "file catalogue". Also it can send files to other systems by making so called ".tic" files which contains all the information that is needed to send a file through a net and add it to the "file catalogue" of an other system. Also important for the mail is the Areafix program. It is a program that can connect or disconnect echomail sections by means of netmail. A user sends netmail to your system with commands to change the list of sections he is connected to. Areafix reads the message makes the changes and sends a netmail back to the user. All the programs needed for mail processing are usually started in the "mail" script which can be found in the Trion:scripts/ directory. This script will be executed when a user logs off, or after a mail call is made. Trion The BBS can be largely controlled from scripts and shells. A good example of this is the "trion" program. It is a little program to send commands to BBS nodes. You simply type a command on the command line, with the BBS nodes it aplies to, and some arguments. With the trion program you can make nodes call to other BBS nodes. It can display text messages on the screen of the BBS node. It can quit a node or logoff a user. It can switch a serial port off, or turn the modem sound off. And some other things that are usefull for a BBS node. Menus The system is for a very big part configurable to your own wishes/likes, this includes the menus which are completely configurable. In a menu you can call other menus, so you can expand it almost infinitly. The first menu which is started when someone 'logs in' is the 'start.menu'. To make a menu is very easy , they consist of readable text files with commands, and a pascal like structure. Before you can use a menu you have to 'compile' it, this is done by calling the 'menu' utility which checks your menus on errors and makes a binary file from it. The text files are called 'source' and the result of the menu compiler are the menus. You find the sources of the menus in the 'trion:menus/' directory, this also contains a subdirectory for the compiled menus. Compiling a menu: 'menu door.src' (compiles the 'door' menu) Wildcards are allowed: 'menu #?' (this compiles all menus) For more information on menus and menu commands look in the "trion:docs/lists/" directory. Doors Clidoors are expansions of the system, they are programs which can range from games to questionaires. They are programs which are capable of running in a shell which is emulated by the BBS program. Configuring The BBS system consists of a number of programs and data files. Most of the programs have there own configuration file. Configuring at the moment consists of editing text files in the configuration directory with your favorite editor. The editors can be started from GUI windows with buttons for most files. For some of the configuration files like the echomail feed config there are special GUI editors to make life easier. System Hardware and Software Requirements ----------------------------------------- - An Amiga compatible Computer - AmigaDOS Release 2 or higher - An IBM.font would be usefull (suplied in the archive) - Xprzmodem.library V3.5 (suplied in the archive) - Xprzedzap.library V3.5 (suplied in the archive) Optional: - Archivers like LHA, LZX, ZIP, ZOO, ARJ and ARC - An ANSI editor for example BBS-draw - More Xpr file transfer librarys - nullmodem.device to call a node without using modems or to poll yourself with your point package Installation ------------ The basic installation conists of just a few steps, then you will be able to run the system. But tayloring it to your needs is a lot more work and is descriped in the configuration chapters. Move the directory Trion with it's contents to a place on a harddisk where you want to use it. Or just copy the contents of the trion directory to an empty directory. Copy the contents of the fonts directory to your fonts: directory (if you don't already have the suplied fonts). In the libs directory you will find an archive containing Xprzmodem and Xprzedzap libraries. If you don't already have these installed copy an apropriate copy to your libs: directory of both. The only thing you now need is an assign "TRION:" to the directory where you have put the contents of the trion directory. To start the system there is a "startup" script provided in the trion directory. In the script trion:startup you will find a sample of how to startup the system. You can change the script to fit your system. Note that there is an assign Trion: in the startup script that you have to change. To start the BBS just type: 'execute startup' or 'execute trion:startup' Or add a line to a startup-sequence: newshell con:5/154/690/115/Trion from dh2:trion/startup or: newshell con:5/154/690/115/Trion from trion:startup You have to change the Trion: part in the lines above to the path where you stored the BBS or make an assign before the startup like this: assign trion: dh2:trion With the trion:down script you can stop the system and release it from memory. All the executables have some sort of build in help, just use a ? on the command line to display all the flags. Note that there is more information about the executables in the "trion:docs/utils/" directory. In the "trion:docs/lists/" directory you will find all kind of lists with important information like function keys and menu commands. Note that the Xprzmodem.library V3.50 and Xprzedzap.library V3.50 don't work on a machine with a 68000 for some reason. Older Xprzmodem.library's do work , but there is no old Xprzedzap.library that works 100% , so if you want to use the mailer with an 68000 you have to disable ZEDZAP in the trion:cfg/trion-X.cfg , this doesn't influence the workings of the system .. because the mailer will still function fully with only the Xprzmodem library available. Default configuration: node 0 -> configured as a 'local' node. node 1 -> conected to port 0 of the serial.device node 6 -\ Nodes 6 & 7 are configured as port 6 and 7 of the node 7 -/ nullmodem.device , so these two can call each other in de terminal mode. To simplify testing nodes 6 & 7 are default configured to use the 'nullmodem.device' .. this is a public domain device which is available on a lot of BBS systems. This device emulates 2 modems and a phone line, so you can call a node without using an actuall phone line. This is also very usefull if you want to use a point package to read and write mail, you just run node 6 and configure your point packet to node 7 of the nullmodem.device. The system expects an assign 'trion:' to the directory with all the data to run the BBS. You could for example make a directory 'dh0:trion/' with all the files and directories, the name and place are not important as long as there is an assign to it. In this directory the following directories are expected: (these are present in the distribution package) (Sometimes while unpacking archives or writing back backups empty directories disappear, the provided startup script tries to create directories if they are missing) Trion: <- Obligatory assign to this directory. InBound <- This is where incoming information goes. with mail-connections. Backup <- Subdir where processed mail is stored. Decode <- Subdir where files decoded from mail are stored. Bad <- Subdir where bad packets are moved to. OutBound <- This is the Outgoing mail. Attaches <- Subdir where attached files are stored. NodeLists <- Nodelists with the data of other BBSes. cfg <- The configuration files of the BBS-system. data <- This is where internal data for the system is kept. docs <- Textfiles with FI command lists and util. descriptions. Utils <- Subdir with descriptions of all utilities. Lists <- Subdir with Lists with MenuCommands, Keys, Tildecodes. Updates <- Subdir with changes from version to version. DemoDoor <- Subdir with C source of a demo CLI door. doors <- Directories with 'external programs' (doors). filecat <- This is where the file database is kept. files <- This is where the downloadable files are (default). icons <- RIPscrip graphic icons. log <- All the logs of the system. mail <- This is where the message bases are (default). menus <- This is were the 'menu programs' are. bin <- Subdir where the binairy compiled menus are stored. menutext <- This is where the screens of the menus are. menutext1 <- This is where the screens for menuset 1 are. menutextX <- This is where the screens for menuset X are. samples <- Sound samples for paging and Ctrl-G. scripts <- All sorts of scripts to controll the BBS. text <- All kind of screens for use in the BBS. upload <- Temporary place for processing Uploaded files. users <- This is where the User database/information is. utils <- Most of the executables of the BBS system. KilledFiles <- This is where files go when they are removed. Furthermore there are in the distribution archive in the "trion:" directory are few little texts/scripts: important <- Information on docs and how to startup. startup <- A little sample startup script. down <- A script to exit the system. Keyfile ------- The system will only startup when a trion key file is on your harddisk. In the distribution archive a public demokey is provided with some minor limitations. The key must be named "TrionBBS.key" or "TrionDemo.key" and be placed in the "L:" or "Trion:" directory. The "L:" directory is prefered for "TrionBBS.key", because if you make a copy or backup of your BBS the key is not included. The "Trion:" directory is prefered for the "TrionDemo.key", so the program will always start, even if it was on a backup. Note that the system always looks for the "TrionBBS.key" first in the L: and Trion: directory before looking for the "TrionDemo.key" so it doesn't matter if you have both keys on disk. Note that when TrionRM is active it will "lock" the key that is used so it can't be downloaded by someone who somehow has find access to dos or a shell or something like that. Note that if you want to backup a directory with the key, TrionRM must not be running or the key will not be backed up correctly. Take a look at chapter one to find out what the limitations of the demo key are and how to register and receive an unlimited "TrionBBS.key". Support ------- To support the sysops who run with the Trion BBS system a few methodes are available. There is a fido-style "Trion-net" with echomail and tick sections. For more information about trion-net look at the file: Trion:docs/trion-net.doc Also a recent nodelist is provided with systems that are running with Trion and have the Trion-net. Trion:nodelists/trionlist.* If you have an Internet account you can get all kinds of support via Internet. The host of Trion-net has some capabilities to send you the Trion-net via E-mail. Also there is a Trion BBS newsgroup where you can reach the author and other Trion BBS Sysops. alt.bbs.amiga.trion Complete versions of the Trion BBS system can be found on Aminet sites and Aminet CDroms. Or visit the Trion homepage on the World Wide Web for updates and some third party programs: http://www.tip.nl/users/c.brugman http://www.trion.club.tip.nl BugReports ---------- If you encounter any bugs please contact the author. Please give as much information about the problem as possible. Especially important are: The minimum steps to take which will reproduce the problem. If a crash occurs give the error number in the red software failure box. Also note what you mean with a "crash", if you mean something else than a "software failure". For instance a single node may hang, but everything else still works. The computer may completely hang, so even the mouse is frozen. The computer may be extremely slow, so the mouse moves now and then (something like the CPU is 100% used). Please note how often the problem occurs. If it is a crash how often does it happen. Or if it is an other problem how often does it happen, is it for instance often, rarely or has it just happend once. Sometimes it maybe usefull to know what your hardware setup is. What machine you use and what type of CPU it has, and what for cards are installed or which operating system version you use. Contacting me ------------- For registering, questions, comments or suggestions write to: A.Paul Spijkerman Bernhard Fabritiuslaan 19 9462 SM Gasselte,DR The Netherlands, Europe You can send me E-mail at: Personal: Paul.Spijkerman@ddimedia.com BBS related: Trion@ddimedia.com Any sign of intelligent life welcome ! (preferably in English, Dutch or German) ------------------------------------------------------------------- Or call my BBS : +31-599-564696 24 Hours V32B/V42B (located in The Netherlands, Europe) FIDO: 2:284/324.20 Trion: 350:1002/100 AMY : 39:152/200 NLA : 14:107/200