PCPMX+.DOC by Rick Charnes, San Francisco; September 5, 1988 ************************************************ ** TIME- AND DATE-SUPPORTING MEXPLUS SCRIPT ** ** FOR LOGGING ONTO ** ** REMOTE BBS'S THROUGH PC-PURSUIT ** ************************************************ WARNING! BEFORE RUNNING THIS SCRIPT BE SURE TO READ THE SECTION 'UNUSED BYTES OF MEMORY' BELOW!! This is less an update and more a complete rewrite of the MexPlus script that I released in April 1987 (in PCPMX+11.LBR) to facilitate the calling of BBSes through PC-PURSUIT. It fully utilizes the MexPlus features dealing with date and time, and requires MexPlus to be integrated with a real-time clock, either through one of the native MexPlus clock drivers, with DateStamper, or for the future if some work is done with a proper overlay, perhaps with the superb new datestamping DOSes ZSDOS and ZDDOS to be available from Alpha Systems (presently in the final stages of beta-testing). Features of PCP.MEX: * Displays to the user in attractive box graphics: o Time of day first logged on to Telenet o Continuously updated time at each call to attempted PCP city o Continuously updated number of minutes and number of attempts dialing current PCP city o Previously called PCP city and BBS o Number of minutes and number of attempts dialing previous PCP city o Time of day at logon and logoff of previous BBS o Number of minutes connected to previous BBS o Descriptive "motto" for each city o All "time" displays in easily-readable 12-hour civil, not 24-hour military time. ********************************************************* * * * Perhaps its most unique feature: the user can * * completely exit not just the PCP.MEX script but * * MEX itself, to work on his own system for an * * unlimited amount of time for whatever purpose. * * UPON RETURN ALL RELEVANT INFORMATION, INCLUDING * * THAT ABOVE, IS "REMEMBERED" AND/OR DISPLAYED. * * Has to be seen to be believed. Extremely * * powerful feature. * * * * ZCPR3 users use the system registers to store * * this information. Non-ZCPR3 users may use any * * unused 15 bytes of memory. * * * ********************************************************* * Comes with auxiliary script allowing for viewing of number of minutes connected to current BBS. * Unlike other similar scripts, allows for execution of complete customized log-on sequences for each individual BBS (password, user id, skip through bulletins, etc.) * Automatically adjusts for whether a PCP node will accept 2400 or 1200 bps. (The PCP outdial modems do NOT have automatic stepdown). If there is a discrepancy between current and previous node, PCP.MEX will *automatically* disconnect and redial. * Unlimited retries for both PCP city and individual BBS, with Racal-Vadic protocol for the latter. * ZCPR3 users using ARUNZ may log on to up to 25 different BBSes and execute an opening log-on sequence for each, with a SINGLE command from the ZCPR3 command line -- using a SINGLE alias! * Is able to "sense" if the BBS you are currently calling is in the same PCP node as the previous one. If so, it will not disconnect. * * * ============= USING PCP.MEX ============= If you are using this script for the first time I would advise running it through MENU.MEX first. Simply type 'MENU' and choose from its selections; it will transparently chain to PCP.MEX. After you become more familiar with the names of the BBS's you will probably not want to use the menu and will use PCP.MEX directly. The syntax for PCP.MEX is simple once everything is configured. From within Mex, simply type 'PCP BBSNAME where 'BBSNAME' is the name of the desired BBS, or 'PCP BBSNAME C' (note the 'C' parameter) if you are still connected to PC-Pursuit/Telenet. (Note the status of the 'CD' light on your modem to determine if you are still connected.) When using MENU.MEX care must be exercised to tell the script whether you are connected to PC-Pursuit. If using PCP.MEX you indicate this with a 'C' parameter after the BBS name. When using MENU, however, you must select the '100' option to manually inform the script of the 'connect status.' Note that the script has no way of actually detecting whether you are connected; the status display simply reflects the manual setting by the user of the '100' option. The purpose of both the 'C' parameter from PCP.MEX and setting MENU.MEX to 'CONNECTED' is simply to tell the script to NOT dial Telenet. Finally, if using ZCPR3 and at the ZCPR3 command prompt, if PCPMEX.CMD is properly inserted into your ALIAS.CMD, simply type 'BBSNAME' or 'BBSNAME C'. ARUNZ will generate the appropriate command line. NOTE: when logging off from a BBS, do not do it the way you ordinarily would, by typing "BYE." You should always log off from a BBS by running the script OFF.MEX. This sends information (via the ZCPR3 registers) to the _next_ run of PCP.MEX and ensures that it will be given the proper information regarding time of log-off. OFF.MEX is defaulted to send out the string "BYE." If you provide it with the parameter "g" it will assume you are connected to the message base of a PBBS system (my local San Francisco Morrow BBSes) and will send out the proper responses to its prompts. If you provide it with any other parameter it will send out that parameter instead. REPEAT: Try to get in the habit of always logging off from a BBS by running OFF.MEX rather than manually in your accustomed fashion. A separate script, TIMEON.MEX is provided to remind one of how many minutes one has been logged on to the current BBS. PCP.MEX will dial both PC-Pursuit and -- once it gets through to a node -- the desired BBS, continously until CTL-C is pressed by the user. Some scripts allow for the user to specify a limit on the number of attempts; this does not. If after pressing CTL-C to abort an attempted call you wish to try another BBS, simply type 'PCP BBSNAME C' or MENU once again. Once in MENU, if you are still connected to Telenet/PCP be sure to set the status to 'CONNECTED.' ============================================ REQUIREMENTS AND VARIOUS ACTS OF PREPARATION ============================================ There are a number of things you will need to do to adapt PCP.MEX for your own use, so please read these thoroughly. You might want to print out PCP.MEX or PCP-CMNT.MEX on paper so some of these items will be more readily understandable. Once the basic structure is clear, configuration will be simple and straightforward. (1) TPA CONCERNS ------------ PCP.MEX as currently distributed will allow for the calling of 20-25 different BBSes (my most frequently called), complete with full log-on sequences (sub-scripts) for many of these. It requires around 49k or 49.5k TPA. The script can easily be reconfigured to allow for less. Simply eliminate some of the BBS LABELs in the second half of the script; TPA requirements will decrease accordingly. With my Morrow MD3 with 20 meg Mini-Winnie hard disk, 35 named directories, full IOP, RCP and FCP, an extra large shell stack of 256 bytes, a clock driver in the BIOS and a beta-test version of ZDDOS, the new operating system to be released soon from Alpha Systems with datestamping routines in the DOS, I have 49.75k TPA, which suits me fine. For ZCPR3 users with TPA cramps, I highly recommend Alpha Systems' NZ-COM which with its dynamic variable TPA configuration is absolutely made for this kind of application. Alpha Systems may be contacted at Alpha Systems 711 Chatsworth Place San Jose, CA 95128 (2) UNUSED BYTES OF MEMORY ---------------------- All users must find 14 (optionally 15) bytes of unused memory in which various information concerning time of day and other matters may be stored. This information is referenced in PCP.MEX by various PEEK and POKE commands which you can readily see throughout the script. ZCPR3 users have an easily-accessible area of memory for this purpose in the user registers. These instructions will be addressed primarily to them. Non-ZCPR3 users may simply use any 14 (15) contiguous bytes of free memory. The first step in preparing this script for use will be to find the address of your message buffer. This information is easily obtained with SHOW.COM's '1' option. PCP.MEX as distributed is set up for my own system, which locates the message buffer at F580. Unless your buffer is at the same place, you will have to change the script accordingly. The script uses NONE of the 'standard' ZCPR3 registers but ALL of the "system-reserved bytes" and 8 of the "user-defined bytes". See SHOW's '2' option for a visual representation of this infrequently-used part of the message buffer. The "system-reserved bytes" begin at 3A hex bytes past the start of the message buffer. Therefore, simply add 3A to the address SHOW.COM gives you. Since my buffer starts at F580, my first reserved bytes are at F5BA hex (F580+3A). I use F5BA - F5BF, and then F5C0-F5C7 in the "user-defined bytes" for a total of 14 bytes in PCP.MEX. Let's say your message buffer begins at EC80. Add 3A and you get ECBA. You will be using ECBA - ECC7 with PCP.MEX. PCP.MEX uses the ZCPR3 message buffer area for MEXPLUS's (mostly undocumented) POKE and PEEK commands. You will have to change all my POKEs and PEEKs to reference the correct addresses for YOUR system. I'll give two examples below of correct addresses, one with your message buffer at EC80 and the second with your buffer at F080. Mine Msg buffer at EC80 Msg buffer at F080 ---- ----- ------------------ F5BA ECBA F0BA F5BB ECBB . F5BC ECBC . F5BD ECBD . F5BE ECBE . F5BF ECBF F0BF F5C0 ECC0 F0C0 F5C1 ECC1 . F5C2 . . F5C3 . . F5C4 . . F5C5 . . F5C6 . . F5C7 ECC7 F0C7 I think most implementations of ZCPR3 have the message buffer begin at XX80, so all you will need to change is the second and perhaps the first number. Be sure to change _all_ the PEEKs and POKEs in PCP.MEX. I can confirm that all occurrences of the string "f5" are definitely relating to the PEEK and POKE commands, so your search and replace can proceed without a verification check. Eric Meyer's FINREP (or, of course, a word processor) will do quite nicely here: finrep pcp.mex yourpcp.mex /w/ "f5" "f0" would do the job perfectly if your message buffer starts at F080. You'll also need to go into PCP.MEX's two auxiliary files, TIMEON.MEX and OFF.MEX and do the same changing of PEEKs and POKEs. NOTE: after the foregoing I presume it is understood that this script may be used with only one memory configuration! In other words, users of the extraordinary NZ-COM may not run it under two different systems, unless of course you make a second copy with different PEEK'ed and POKE'ed addresses. (3) TELENET INFO AND THE BBS LABELS ------------------------------- There are four places in the script where you must provide relevant information concerning your local Telenet phone number, user ID and password. I have marked the first with "<--ENTER YOUR TELENET NUMBER HERE" and the others are similarly noted. To find all four places, simply search the script for the string "HERE" and that will take you to each of the four lines to change. You _may_ additionally need to change the routine that gets past Telenet's opening sequence, in which you are displayed "TERMINAL=". It works for me, but if you find you are not connecting properly, search for this string in PCP.MEX and work with it a bit. The connection sequence for 2400 bps connection (we send out a "@" and then a "D1") is a little different from that for 1200, in which we send out only two carriage returns. I have distributed PCP.MEX as I use it; that is, it is set up to call the ZCPR3 Z-Nodes that I use most frequently, complete with log-on id sequences for those I use most often. The part of the script containing these log-on sequences begins on line 409, about 3/4 of the way through the script. Look for it and find all the labels that begin with the name of a BBS. You will need to add those you use, and should delete those of mine you don't use, to save memory. The form will be clear from what I have done, but an explanation follows below. Begin each entry with a label of a one-word name of the BBS; you will use this name as the command to begin PCP.MEX and send it on its merry way to log in to the board. You should also enter this name into your ARUNZ alias. The ideal way to execute PCP.MEX from the command line is with an ARUNZ alias. See the PCPMEX.CMD that I have provided. It is a single, multi-name alias in which all its names are the various BBS labels. Separate the alias names with a "=". Entering any of these names on the command line will execute the alias and send MexPlus to the appropriate label. String variable "a" is full name of the BBS, and "b" the PCP node code. After "phone n =" enter the phone number. Next comes a POKE, in my system to F5C7. I have arbitrarily chosen this byte to hold a number that will represent the name of the BBS. Next time PCP.MEX is run, the script will PEEK at this byte and translate the number it finds there into the name of the (previously) logged BBS in order to display the name to the user. As I will explain later, this POKE/PEEK technique is necessary because we want to allow for the possibility that the user will exit MexPlus completely. This of course would lose any information held in any string or numeric variables, eliminating the possibility of storing any such information in the MexPlus variables. Hence we rely on our ever-present operating system for this information. What you will need to do when adding your own BBS labels is simply to continue (or use as is) the numbering system I have started. The numbers are arbitrary, where the first BBS listed in the script is "1" and the last is however high you go. After you have assigned each BBS a number for this POKE command, the next step is to insert this information at the beginning of the script. Look at the first screen of the script where you will see 25 or so lines of if %a=nn c="name of BBS" This is where the script reads the POKE we have just done in the label section. Simply make sure you have a line here indicating your BBS name corresponding to the poke in each BBS label. (Just as John Shotsky says about his script, many things here may seem somewhat convoluted and would not be necessary if MexPlus had (1) more string variables and (2) an INTERNAL "shell-to-operating- system" facility that preserved all variables. But this _is_ CP/M and we are living in the real world. One learns how to work with the tools one has -- which, by the way, is _always_ a good skill.) Continuing with the BBS labels, next you will see a GOSUB CALL which of course goes to the "call" subroutine which occupies the main body of the script. After this subroutine executes, we are connected to our BBS -- and PCP.MEX returns to the BBS label. Insert the log-on sequence for your BBS here. Change all occurrences of "Bill Smith," that wonderful mythical creature, to your own name, and substitute your own password where you find "password." We utilize here the full power of MexPlus' wonderful WAIT STRING command, so noticeably missing in the public domain version. (4) PRESERVING THE PREVIOUS CITY ---------------------------- At LABEL BEGIN near the top of PCP.MEX you will see a PEEK $F5BB followed by a number of lines looking like: if %f=nn f="Cityname" This is similar to how above we preserved the name of the previously-logged BBS; here we do the same for the previously-called PCP city. We peek into F5BB, the byte where I store this information, then set string variable "f" accordingly. If you take a look at LABEL ASSIGN you will see where the actual POKEing is done. For every PCP city you add in addition to those I already have, you should be sure to add your own, both here and at LABEL ASSIGN. (5) ASSIGN CITY INFORMATION ----------------------- If you are adding additional PCP nodes, at LABEL ASSIGN you should also include a "logo" and assign it to string variable "e," and a corresponding city which should be assigned to variable "d". (6) BPS RATE -------- The script assumes you have a 2400 bps modem and has much code dealing with this. If your modem is capable of only 1200 bps it should still work fine. Simply take out the 20 lines beginning with "comp b..." and "if value %s=24" at LABEL BEGIN. Even though it works fine for me entirely at 1200, I did have one report of a problem; I'd like to hear from people on this. PCP.MEX also assumes baud rate is changed with the command 'SET BAUD XX00'. If you change the rate simply with 'SET XX00', find the SET BAUD command in the script and eliminate the word 'BAUD.' (7) TERMINAL OVERLAY ---------------- I assume you have a good, full, working terminal overlay with straight-line graphics characters, which will allow for the BOX command to work properly. Video attributes should be functional in the overlay so that START REV, START BRITE, etc. all work properly. I assume most of you, as I do, have START BRITE implemented so it really turns on dim video [ESC )] for ADM-3A-compatible terminals]. That should do it as far as preparing PCP.MEX for your own use. I _think_ you can use the program without reading the next section, contained in PCPMEX2.DOC, but I'd urge reading it when you can. * * *