Program: GRAF-D v2.11 Author: Steve Catmull Date: 05/27/93 DESCRIPTION ======================================================================== PPE (PCBoard Programming Executable) that you can replace PCBTEXT record #149 with. What this PPE offers that PCBoard does not is to do some checking for graphics capability before asking the caller if they want graphics or not. By testing for graphics before the prompt is ever issued, the appropriate default value can be set for the user. If they have ANSI capabilities (as per the [6n test) then the default for the prompt will be "Yes". A test will also be made if they have RIPscrip capabilities (as per the [! test). If neither of these are detected in the default wait period then the default will remain as no. INSTALLATION ======================================================================== Installing this PPE is very simple. Use MKPCBTXT to load your PCBTEXT file. Press F3 and enter 149. You will now see the "Do you want graphics" record. Simply change it to an ! followed by the full path and filename to the ANSI-D.PPE file. In addition, make sure that you have not told PCBoard that you want to default to graphics at login. If you do, GRAF-D will attempt to leave a message addressed to the SysOp informing you that your system is improperly configured. That's all there is to it. COMMAND LINE PARAMETERS ======================================================================== You can control the wait time for ANSI and RIP detection from the command line. You may also choose to run this program in "compatible" mode via command line switches. The following details the command line options that are available. /WAIT:[clock ticks] Gives you the ability to over-ride the default wait time for graphics detection. The default wait is for 50 clock ticks which is equal to about 3 seconds (There are roughly 18.2 clock ticks per second). For example, if you wish to make the new wait time about 4 seconds, then you would enter the following in PCBTEXT: C:\PCB\PPE\GRAF-D.PPE /WAIT:73 /COMPATIBLE Because this PPE will change the "Do you want" graphics prompt based on the graphics capability detected then there is a good chance that login scripts might fail. In other words, a user could login and receive "Do you want graphics (Enter)=no?" but the next time they login it may say "Do you want graphics (Enter)=yes?" Obviously, if the user has a script which checks for "(Enter)=no" then their second login attempt will fail. This command line switch will tell ANSI-D to report the graphics mode detected above the "Do you want graphics" prompt and explain that it will be the default response. The prompt will then be modified to always display: "Do you want grpahics (Enter)=default?" It may break a few scripts initially, but once the user has modified their end they can be assured that they will always receive that prompt. The following is an example of how to specify this parameter on the commandline: C:\PCB\PPE\GRAF-D.PPE /COMPATIBLE /AUTO Some sysops may not want to give the user a choice as to what graphics mode is selected. If you are one of these folks, then this switch is for you. This switch will make the user use ANSI or RIP if detected by the PPE. If neither ANSI or RIP is detected, then the user will be asked what graphics mode they would like to use. The reason that the PPE does not simply go with non-graphics mode is because the user's communication package may not properly handle the ANSI auto-detection. Example: C:\PCB\PPE\GRAF-D.PPE /AUTO ERROR RATES ======================================================================== Not every user will have their graphics capabilities properly detected upon login. If an invalid (or no response) at all is detetcted during the wait time then it must be assumed that the user does not have graphics capabilities. Some terminal programs are just plain slow in responding to ANSI or RIPscrip requests. I have tested with the following communications software and all respond swiftly: Telemate v4.x Telix v4.x Robocomm v4.x ProComm Plus v2.x Qmodem v4.31 Even if you are using one of these programs it would still be likely for a response to not be detected. This may happen if you are using error-correcting modems and the modem happens to be experiencing line noise. In a case such as this, there is nothing that can be done. In my testing (about 1800 calls to Salt Air) I have seen that about 17% of all connections will fail to even get a response from the remote user. Another 4% of all connections will fail due to incorrect responses from the remote terminal. This may happen if you start typing while graphics are being attempted to be detected. Of course, you could bump up the wait time to catch some of these connections. The problem with this thinking though, is that users who truly do not have graphics capabilities will *have* to wait for the wait period (a default of about 3 seconds). Extending that time any longer may really cause you to have some upset callers. For your reference, the following report shows the statistics for the 1800 or so calls that I talked about previously: +-- Number of | calls where | no response + Incomplete | was recorded | responses | | ************************************************************************* Report ran: 05-07-93 08:24:53 <= 2400 : Calls: 69 Average ticks: 17 Exc: 8 Inv: 7 Inc: 2 2400-9600 : Calls: 153 Average ticks: 12 Exc: 43 Inv: 12 Inc: 1 9601-14400 : Calls: 1101 Average ticks: 13 Exc: 245 Inv: 68 Inc: 13 14400+ : Calls: 150 Average ticks: 15 Exc: 13 Inv: 1 Inc: 5 ************************************************************************* | | | | Baud---+ +-- Number +-- Average | of clock ticks +- Invalid calls elapsed responses before a response MODIFYING SOURCE ======================================================================== Feel free to modify the PPS (source) file as your needs dictate. That is why the source is included. :-) Last, but certainly not least. HAVE FUN!