CBBS - COOKBOOK Rev. 3.5 11/28/81 This file is a COOKBOOK for the installation of a Computerized ¨ Bulletin Board System (CBBS). Any comments, errors, omissions, ¨ etc should be referred to the Chicago CBBS, online at (312) ¨ 545-8086, or to Ward Christensen at (312) 849-6279, or Randy¨ Suess, (312) 545-7535. <> Most of the comments are SUGGESTIONS. For example, ideas are¨ presented for the format of the BULLETIN and WELCOME files. ¨ You are of course free to changes these any way you like. HARDWARE: THE FOLLOWING ENVIROMNENT IS REQUIRED: Mainframe: This used to say "S-100" but technically that is not¨ true; Randy and I are only familiar with S-100. All the¨ programming is in 8080 assembler, so the CPU must be 8080 (or¨ '85) or Z80, etc. Our original CBBS used a kludge chassis, but¨ we are now running a Vector 1 and IMSAI CPU. Memory: 32K. 28 will probably work. If you have more avail-¨ able, then you will be able to increase the size of the write ¨ buffer used in message and summary kill (now 2K). Also, if ¨ your system has many (300 or so) messages and you want to run ¨ the BUILDSUM program to rebuild the summary file, 28K would be ¨ required. In our 24K system, I ran BUILD with 330 messages, ¨ and only got 4/5 of the way thru the messages before running ¨ out of room. (We are now a 40K system.) BUILD stores the ¨ summaries in memory, so it could not complete successfully. ¨ Also, if you want to run CBBS under FAST (FX) which is a full ¨ track buffering program, then you will need about 40K. Modem: CBBS is written for a PMMI, or D. C. Hayes or I.D.S. ¨ modem running thru a DAA. An external modem can be accomo-¨ dated, and some generalized code is provided which assumes the ¨ availability of a way to detect ring and carrier, and to go ¨ off-hook. Disks: Standard size floppy disk and controller capable of ¨ supporting CP/M. Our original system used the Tarbell control-¨ ler, and an Innovex disk, very successfully). The software ¨ supports one or two disks. Smaller disks could be used, but ¨ the number of messages would have to be kept fairly low. Additional hardware: Local console and interface - This may ¨ consist of a terminal such as a Soroc or ADM-3, and serial ¨ port to access it, or a keyboard-VDM or other similar combina-¨ tion. (Note the CP/M BIOS does not have room for a scroll ¨ routine for a memory mapped display such as the VTI or VDM. We ¨ use a scroll routine burned into a PROM, calling it from the ¨ BIOS). Software: The system requires the use of the CP/M operating ¨ system. (or, technically, a "compatible" system). The system is running under both CP/M 1.3, 1.4, and 2.0. I doubt there is any interest in 1.3 any more; The STAT command¨ in CBBSOPER has been rewritten to support 1.4 and 2.2. Steve¨ Vinokuroff found that the "extend" routine which positions to¨ the last sector of a file, backs up 1, then scans for EOF, had¨ to be changed to back up two sectors (testing for backing to a¨ "negative" number). Now, you must decide the mode of operation of the system: The preferred mode, and the only one I know people have tried,¨ is to put the modem's I/O directly in CP/M's BIOS. This is¨ preferred because it allows remote maintenance of the system¨ via the XCPM command (eXit to CPM). It requires that both the¨ modem, and the local console I/O be included in the 3 routines:¨ console status, console in, and console out. The original¨ system made use of a sense switch (80H bit value on port 3) to¨ determine if the system was in remote (modem I/O) mode, and if¨ not, dealt only with the local console. Note that a system¨ with no front panelcan be accomodated as the original system did, by¨ putting a switch on an unused parallel port, such as on a 3P+S,¨ as we did. If this mode is chosen, do the following: Modify your BIOS console status, in, and out, to look like the ¨ ones in CEBIOS.ASM on the supplied disk. This BIOS has the ¨ following required features: 1. Console status, console in, and console out all deal with¨ the local console, and if the sense switch is on, with the¨ modem. 2. Console status is reflected as true if loss of carrier ¨ occurs. This prevents hanging in the status routine, after¨ loss of carrier. 3. Character in sends back an 0FFH if loss of carrier occurs.¨ CBBS.ASM checks for this. This implies you "ANI 7FH" for all¨ normal ASCII characters, to ensure an FF won't be seen except¨ due to carrier loss. ---------------- If in addition, you want the system to automatically come up ¨ running the CBBS program from cold boot: 4. Cold boot checks the sense switch, and if in remote mode,¨ does not go into CP/M command mode, but instead loads CBBS.COM¨ and transfers control to it. Thus the user never sees or is¨ allowed access to the CP/M environment. Note that with CP/M 1.4 and higher, the auto-load feature ¨ whereby you patch the CBBS command into CCP's input buffer (at ¨ CCP+7: 7 is the length and 8-on is the ¨ upper case, actual command to be executed) is much "cleaner" ¨ than our original "load it yourself" trick. With 1.4 and auto-¨ boot, when you JMP to CCP, the command is automatically exe-¨ cuted. In warm boot, JMP to CCP+3 which skips the auto-boot ¨ into CP/M. This is so the "XCPM" command would allow you to ¨ get into CP/M in operator mode. We supply a Tarbell single¨ density BIOS for CP/M 1.4. An alternate mode of operation is to put the modem I/O¨ directly in the CBBS.ASM program. I don't know of anyone who¨ has done this. If you do, the XCPM command should be¨ nullified. If XCPM were to be used, the system would go into¨ CP/M, but would then sit there communicating only with the¨ local console, and the phone would be off hook. Note that¨ built-in I/O drivers are not in CBBS.ASM. The supplied¨ version is intended to work with modem I/O via CP/M BIOS as¨ described above. An "apparently" attractive alternative is to run CBBS under¨ Dave Jaffe's BYE program, a general-purpose program for remote¨ access into a CP/M system. It is distributed on CP/M Users¨ Group volumes 40 and 46, and via various SIG/M disks, and¨ remote CP/M systems. H O W E V E R, CBBS is written to have a¨ "DISK BUSY" flag, which is tested. For example, if someone¨ leaves comments, then hangs up without ending, the disk busy¨ flag causes a C/R to be written into the file. With BYE, the¨ loss of carrier causes BYE to "yank" control away. This could¨ leave an un-terminated file open on disk, since message entry,¨ log, kill, and comments, all "extend" disk files, i.e. over¨ write the previous EOF (^Z)) characters in the file. BYE MAY be used, but you may occasionally experience¨ strangeness in your files. I don't know a good solution,¨ except having BYE handle the disk busy switch, returning 0FFH¨ upon carrier loss, like CBBS expects. But then when BYE is¨ running something OTHER than CBBS, it should handle the¨ carrier loss itself. An as yet unsolved problem. ------------------ Obtain hard copy listings of all files, particularly the¨ CBBS.ASM source files: CBBSxxxx.ASM. Study these listings until you are familiar with the basic ¨ operation of the program. Select the options, such as if you have a log teletype, and ¨ make the appropriate source changes (TTY EQU TRUE or TTY EQU¨ FALSE). Also change the equates for the TTY, which are now: ¨ status port 0, data port 1, ready bit 80H. The routine which ¨ checks if the TTY is ready does a RZ if it is not ready. If ¨ your TTY is LOW ready (ours was HI ready) then change this to ¨ RNZ. If you will be running a system which is able to cold boot ¨ itself, set REINIT to FALSE. If you just want to type CBBS¨ and then have it sit in memory, use REINIT EQU TRUE - when¨ one call completes, CBBS just monitors ring detect and¨ handles the next call. It reinitializes itself (clears¨ operator mode, # of nulls, etc) Make other appropriate source changes. For example, at label ¨ TELLUS is a message which tells the user that a system error ¨ has occurred (such as if the file NEXT isn't found on disk, or ¨ if the disk is full). This label has associated with it a ¨ message explaining who to call to notify that the system had a ¨ problem. Change this as appropriate. Note the availability¨ of the FIND command to find any label in the many CBBS .ASM¨ files: FIND CBBS*.ASM TELLUS for example. I eventually hope to pull ALL system-dependent pieces of CBBS¨ into a single module, so "technically" you would only have to¨ change a single .ASM file. Sorry for not having done that¨ yet. Make a running copy of CP/M for the system, having made the ¨ appropriate changes to the BIOS. It should be at least a 28K ¨ system. (Note this is actually 27K in a Tarbell controlled ¨ system). You might want to try running CBBS under another¨ CP/M system, i.e. without the modem I/O. CBBSTEST.COM on the¨ distributed diskettes is just for this purpose. It has the¨ SSW input NOPed, as well as modem I/O, etc. Assemble CBBS and place the COM files on the disk which will ¨ run in the CBBS system itself. Pip over the files required by CBBS: Location in a NAME 2 drive system: BULLETIN B: WELCOME B: NEXT A: FIRSTIME B: ENTINTRO B: ENTRHELP B: FUNCTION A: HELP B: HELP2 B: HELP.IDX B: PASSWORD B: SCANHELP B: Initialize your PASSWORD file to contain the operator access ¨ password: any word or phrase terminated by C/R. CBBSPASS is¨ used in the test system supplied. Initialize file NEXT to contain: 00020(cr)(lf) <-- next message number (MUST have leading 0s) 1(cr)(lf) <-- next caller number 10(cr)(lf) <-- number of active messages 300(cr)(lf) <-- Maximum number of active msgs (ctl-z) 00020 is the starting message number; This is assuming that ¨ you will leave the first 20 message numbers open for permanent ¨ CBBS operational messages. See the sample CBBS supplied for ¨ the contents of these messages. You might even wish to just ¨ edit these messages, deleting the other test messages, and do¨ a BUILD to get the summary, and use this for the start of¨ your system. The second line is the next caller number, treated as a lead-¨ ing zero suppressed ASCII 5 digit number, which is incremented ¨ and printed each time someone calls the system. It is also ¨ written to the LOG before the person's name. The third line is the number of active messages. This may be¨ manually initialized if you have a small number of messages,¨ or you may execute "T SUMMARY #" which prints the number of¨ lines in the summay file, then divide that number printed by¨ 2, to get the number of active msgs. The summary may,¨ however, have flag-deleted messages, so this number won't be¨ absolutely correct. The best way is to run BUILDSUM which¨ will not only build a new summary file, but tell you exactly¨ how many messages there are. Back to file NEXT: The fourth line is a maximum number of¨ active messages. This prevents the disk over-filling so that¨ kill wouldn't work. NOTE this is compared character by¨ character with the line above it, so both must be leading zero¨ suppressed numbers. Edit the file WELCOME to put in your own welcome message. ¨ Leave the comments about the control characters. Please leave ¨ the (R) next to "CBBS(R)" and "Computerized Bulletin Board ¨ System"(R) as we have trademarked the terms. Edit the BULLETIN file. Keep the top line up to date as to¨ how many lines it contains, and when it was last updated. ¨ You'll have to decide yourself how big you want to let it¨ grow, and what it will contain. Rather than having a super­ big bulletin, its better to refer people to specific messages¨ by number, in the bulletin. Note: With CBBS 3.5, there is now a NEWS file, which may be¨ considered to be an extension of the BULLETIN file. You may¨ wish to make reference to it in the BULLETIN, e.g. for more¨ news about the system, type: NEWS Edit the file FIRSTIME to make it appropriate to your environ-¨ ment. Feel free to add any questions which you might like to. ¨ A question starts on a line by itself, starting with the char-¨ acter [. The question may not be more than 1 line long, and¨ is terminated by cr/lf, without any '?'. The information to¨ be typed in response to a Y answer to the question is entered ¨ directly following the question line. When you have completed ¨ the answer, type a ] character which signals the end of the ¨ question. This is so if the caller replies N to the question, ¨ the CBBS software will skip past the ] character. Typing the ¨ reply ends with the ']' character, so it should be on a line¨ by itself, not on the end of the previous line. You will want to edit the first 20 messages, to put in infor-¨ mation about your system. For example message 1 contains the ¨ system history. Other than acknowledging "Ward and Randy" as¨ the original source, make it whatever you feel is appropriate. ¨ Also, update the line count in the header. Then remember to¨ run BUILDSUM after changing these messages, so the SUMMARY¨ matches your messages. Now try the system from the local console or modem, which ever ¨ you feel more comfortable with. Try all commands, and all ¨ options (first time user, help file, full/half duplex, bulle-¨ tin, welcome, etc.) to make sure all the functions work and¨ all the files are present. Even though you may be familiar¨ with CBBS operation, it is probably best to STAY OUT OF EXPERT¨ MODE TO be sure all the prompts are OK. Now try entering a message. Use all of the enter functions, ¨ such as retyping a line, editing a line, insert, delete, etc. ¨ Abort out and make sure that works. Then leave a legitimate ¨ message. Your system should now be ready to go 'on the air'. DAY TO DAY OPERATIONS If there are multiple operators on the system, they will prob-¨ ably want to leave messages for each other, which they would ¨ like to be more "private" than just leaving a regular message ¨ permits. The most obvious way is to leave a comment, since ¨ only the operators can view them via the TYPE LOG command of ¨ operator mode. This is inconvenient, however, as it becomes ¨ hard to find the other operator's comments among the user's ¨ comments. For this reason, a special function "NOTE" is imple-¨ mented when in operator mode. Typing NOTE results in being ¨ able to key lines into a file NOTES. It works just like the ¨ comments function, i.e. enter a null line (two returns in a ¨ row) to terminate input. 'FROM firstname:' is placed at the ¨ front of the notes. Repeated use of NOTE results in¨ additional notes appended to the original. Each is date/time¨ stamped. To avoid time/date stamping, use NOTEN. When using¨ NOTE, the other operator then only has to issue the command¨ TYPE NOTES (or TYPE B:NOTES, etc) to see the notes, and the¨ command ERA NOTES (or ERA B:NOTES, etc) when they have been¨ seen. When an operator uses the PASS command to get into¨ operator mode, the the NOTES file is automatically typed if¨ there is one on disk. Control-C will skip a single note,¨ Control-K will skip them all. The NOTE function is even¨ useful when there is only one operator - to leave notes to¨ yourself! The operators will want to frequently see the LOG files. Get ¨ into operator mode (via PASS command, and the correct¨ password). Use the TYPE command to TYPE LOG. If the LOG file¨ is large, control-x may be used to skip blocks of 10 lines,¨ or Control-C to skip to the next comment. Each comment,¨ unsuccessful message kill, password violation, or request for¨ a keyword not in the HELP file, has a "]" character before it. ¨ This is the character which control-c skips to. The name of¨ the person leaving the comment is logged again at the end of¨ the comment. CBBS didn't used to do this, so you didn't know¨ who the comment was from. If you have a clock, and want to¨ see comments after a certain date, use "type b:log,mm/dd"¨ since any string following TYPE will be skipped to. ^C skips¨ to the next occurrence. I use "TYPE c:log,ward christensen"¨ for example, so that I can skip to right AFTER MY OWN last¨ LOGIN. I let 2 lines print, to see what date, and if I see¨ its not the most recent previous login, press  again to skip¨ to the next one. When the LOG file nears 1 extent (DIR B:LOG shows over 100 or ¨ so sectors) we suggest renaming the LOG file. We use Lyymmdd¨ as the new name. This is to minimize the time it takes to ¨ access the file online. (Note that in CBBS 3.4 or so, a more¨ efficient algorithm was introduced, so large files are not as¨ bad as they used to be. EXTEND looks for the highest extent,¨ rather than scanning thru each extent after the first. Also,¨ this will be an operator convenience in typing the LOG file as¨ it won't be as long. A new LOG or KILLED file is¨ automatically created if none is found. Note the TYPE command allows a character string search. I¨ have a notebook in which I type the current caller number¨ every time I call in. Then, the next time I call in, I can¨ just TYPE B:LOG,nnnnn where nnnnnn is the caller number the¨ last time I called in. See more comments on limitations of¨ TYPE in CBBSOPER.DOC. Periodcally pull the LOG files and the KILLED files off to ¨ another disk, as the online disk gets full. If it becomes necessary to edit a message file, such that the ¨ message header would change, be sure to edit the SUMMARY file ¨ to reflect the changes. An alternative would be to run¨ BUILDSUM to rebuild the summary, but make sure you have enough¨ memory to do this. (The summaries are read into memory by¨ scanning all message files) (An alternative is to take the¨ message disk to a larger CP/M system and do the BUILD there). On CBBS/Chicago, we used the first 20 messages for system use. ¨ This was not done initially, but later the editor was used. ¨ We suggest you keep this policy. If you have a need such as¨ this, or want to create a message without CBBS (i.e. any¨ message not at the end) you should know the following about¨ the format of each message header: MESSAGE HEADER A bell chaaracter (07H). Then the 5 digit message number a comma the date (m or mm, '/', d or dd, '/', yy) a comma who the message is from (SYSTEM OPERATORS, etc) a comma Who the message is to new line (i.e. crlf) subject comma password (the word NONE if you don't want it killable) Together these would look like this: (where ^G is a control-G) ¨ NOTE the header MUST be in UPPER CASE so that the S and Q ¨ string search commands work. (S;1,t=ward looks for WARD in¨ upper case only) ^G00003,05/08/78,SYSTEM OPERATORS,ALL SAMPLE MESSAGE,NONE When the disk or directory becomes fairly full, you will have¨ to kill off messages. We keep messages for 2 months on ¨ CBBS/Chicago. More lately, we have decided to keep 320 active ¨ messages. This means keeping them about 50 days. Use your own ¨ judgement. N-O-T-E The message kill function works like an editor: a file is¨ created, and the message file is passed thru memory, to the¨ temporary file, with the requested message deleted. This ¨ means you must have enough room on disk for this temporary ¨ file, i.e. enough room for a second summary file (since the ¨ summary will typically be bigger than the largest message ¨ file, once you get a few messages). REV: CBBS 3.4 no longer ¨ passes the summary file thru memory on every Kill. The PURGE ¨ command must be used to physically delete flagged summary ¨ messages, or alternatively, run BUILDSUM to "blow away" the¨ summary file and rebuild it (IF you have enough memory to hold¨ the entire summary along with CP/M and BUILDSUM.COM). NOTE that this version of CBBS no longer packs messages. Mes-¨ sage numbers will never be reused, except the low numbered ¨ messages which are "reused" by editing them. When¨ CBBS/Chicago reached 10,000 messages, a few people asked that¨ we start over at 100 or so, but we "like" seeing the 10000+,¨ numbers, and with "+" and "-" retrieval, and flagged¨ retrieval, they are not "that" inconvenient. Well, that's it!! Hope this helps get you on the air, and have ¨ fun!! Don't forget to back up the disk periodically "just in ¨ case". We do it once a week + whenever software changes are ¨ implemented. As stated in the Terms and Conditions, you're on your own, but ¨ we wouldn't refuse an occasional chat (question, etc) to: Ward Christensen (312) 849-6279 Randy Suess (312) 545-7535 NOTE that CBBS is licensed to you. I was recently¨ disappointed to hear the entire CBBS source files are in a¨ local "scroung- er's" "hot" program library. ..and did we remember to say "THANKS" for supporting CBBS??? Ward C. 11/25/81