Simtel MSDOS 1992 September

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

/ Simtel MSDOS 1992 September / Simtel20_Sept92.cdr / msdos / cis / ozrle94h.arc / OZRLE.DOC next >

Wrap

Text File | 1989-10-09 | 49.9 KB | 975 lines

OZRLE Version 9.4h An external protocol module for the CompuServe "B" and "BPlus" protocols and supporting the CompuServe GIF and RLE graphics images Copyright(c)1987,1988,1989 Steve Sneed CIS ID 71520,77 Welcome to OZRLE! ----------------- OZRLE is an "external protocol module", a program that allows you to add the CompuServe "B" and "BPlus" file transfer protocols into other communi- cations programs. While not designed primarily as such, the program can also be used as a (limited) stand-alone communications package for accessing the CompuServe Information Service (CIS). Popular file transfer protocols such as XMODEM do not function well under CompuServe's complex packet-switching network. The KERMIT protocol, while operational, is very slow on CIS. CompuServe developed the B/B+ protocols to provide optimum performance on the network - it is the recomended method of file transfer when using CIS. Also (and for many users, more importantly), OZRLE supports the CIS graphics standards RLE (Run Length Encoded) and GIF (Graphics Interchange Format) for both offline and realtime-online image display. Additionally, OZRLE captures received images to disk - this means you can "preview" an image while downloading so you can verify you really want the image, and save connect time charges. In addition, OZRLE supports both the ANSI/VT100 and VT52/Vidtex terminal emulations used by CIS for attractive screen handling. A wide range of options, both on the command line and within the program, allow you to configure the program to match your needs. The program automatically matches itself to your existing communications port configuration, meaning you do not have to worry about setting things like baud rate and parity when calling the program. OZRLE works with most all major commercial and shareware/freeware comm programs, and can be used with any comm program that can shell out to DOS without dropping the connection. On those programs that provide the capa- bility, OZRLE works best when set up as an external protocol callable from within the program (examples are ProComm Plus, QModem, Boyan and GT-PowerComm.) At this writing the only known major commercial comm program known not to work with this program is Hayes' SmartCom II, because it provides no way to shell out to DOS. Before we start... ------------------ Please read this documentation completely. I know you want to get using the program right away, but taking a few minutes now may well save you time and money (in connect-time charges) later. The program is very simple to use, and for most users' configurations is fully automatic, but an ounce of pre- vention is worth a pound of cure. Thanks! It is assumed throughout this document that you have a good basic under- standing of DOS commands, batch files and batch file commands, what "environment variables" are and how to set them. If this is not the case, please have a good MS-DOS tutorial book handy in case I use unfamiliar terminology. Help for this program is available online in the IBMNew forum on CompuServe. Many program-specific help files written by SysOp Connie Kageyama are available in LIBrary 2 of that forum. Do a "DIR *.HLP" at the "!" prompt in that library for a list of those files, or do a "BRO/KEY:HELP" at the same prompt. Another place to get help on the program with GIF- and graphics- related questions is in the GRAPHSUPPORT Forum. The sysops in both forums are familiar with the program and can answer questions, and of course I frequent the forums to help users. The Legalese... --------------- This program is the copyrighted work of its author, Steve Sneed. All rights under US copyright law are reserved. The author hereby grants to private, noncommercial users of this program a limited license to use, copy and distribute the program free of charge, as long as: a) the program and its accompanying files are not modified in any way other than changing the "archive format" used to store and transmit the program; b) no charge is made for any distribution beyond a nominal disk/duplication fee; and c) the distribution of the program is not done by a business, company or private entity whose primary business purpose is the distribution of public domain and/or "shareware" software, by any means magnetic or electronic, for profit. Specific exclusion of this clause is hereby granted by the author to The First Osborne Group (FOG), The Public (Software) Library, CompuServe Inc. and PCMagNet. If the program is used for commercial purposes, a license from the author is required along with payment of a $15 license fee per copy. Multi-copy and site licenses are available; contact the author at the address listed at the end of this document for more information. "Commercial purposes" as used above is defined as use by a company or government service or organization in an official capacity, or use by a company or individual whereby financial profit is made from such use - for example, a stock broker who uses the program to aquire ticker information for clients. Specific exclusion of this clause is hereby granted by the author to CompuServe Inc., Borland International, TurboPower Software, and PCMagNet. No other rights are in any way relinqushed by the author, and the author reserves sole right to grant and administer licensing and distribution. This software is provided "as-is", without warranty of any kind, including but not limited to any warranty of mercantibility or suitability for a specific purpose. At no time will the author be held liable for any loss or damage, including loss of data or time, due to any operation or use of this program, even if the author has been informed of such loss or potential for loss. "GIF", "GIF Format" and "Graphic Interchange Format" are Service Marks of CompuServe Inc., an H&R Block Company. Installing OZRLE ---------------- OZRLE generally should be installed in the same location as your comm program. If you use a hard disk, this means in the same subdirectory. If you use more than one comm program with OZRLE and have different programs in different subdirectories, be sure to place OZRLE in a subdirectory that is on your DOS path. OZRLE is delivered to the CompuServe forums in "archived" format, using the standard ARC format utility ARCA.COM by Vern Buerg and Wayne Chin. Some forums (and BBS systems, if that is where you aquired this program) may re- compile the program files into a different archive format such as the .ZIP format, or may use a utility like LHARC to create a self-extracting program archive. Once you have copied the archive file or self-extractor onto your disk, you will need to use the appropriate un-arc utility (if not a self- extractor) to un-arc the program files back to their original runable state. Utilities for this purpose are available in most forums on CompuServe, and on nearly every BBS in America. OZRLE comes with a special installation program called SETSVGA.EXE. You only need to use this installation utility if you will be using the program on an Super VGA card. SETSVGA tells OZRLE what SVGA chipset to support and what maximum resolution your card/monitor combination can support. If these terms are unfamiliar to you, especially if you do not know what chipset your brand of video card uses, stop by the PICS Forum on CompuServe - we'll be glad to help you. Please consult the chart at the bottom of this document for a list that covers approx. 90% of the cards currently on the market and their max resolutions. A second installation utility is also available separately to change the text colors the program uses. It is called OZPATCOL.ARC and is available in the PICS and IBMNEW Forums. See the readme file with OZPATCOL for instructions on its use. Configuring OZRLE ----------------- Configuration of OZRLE is very simple. The program uses a "standard" internal configuration that will be correct for 90% or better of users. The program is quite flexible, however; almost any type of special con- figuration used on CIS is supported by the program, as well as several options governing the way the program functions or performs. The following list contains OZRLE's nominal configuration. Only if your particular configuration differs from this list should you worry about the various settings available. * Uses the COM1: serial port/modem. * Uses the chosen port's existing baud rate, parity and data/stopbits settings. * Uses full-duplex communications. * Provides an audible alarm at the end of a protocol transfer. * Returns to its own internal terminal mode at the end of a transfer. * Uses the DOS current working directory for storage of downloaded files, and looks in the same directory for files to upload. Ditto for graphics image files. * On exit, leaves the modem CarrierDetect line high and restores the port to the same configuration in which it was found. Setting Options --------------- If one or more of the above settings does not match your configuration, there are two possible ways to change things. The first, and recommended, way is thru setting variables in the DOS environment. The second is to use command line parameters when executing the program. If you are calling OZRLE from a program such as QModem that wants to see a batch file rather than a free- standing program to execute, it is simpler to use the command line parameters within the batch file (saving the DOS environment space for other programs.) Parameters set via environment variables can be overridden via command line options. Below is a list of OZRLE's environment variable names and the associated options: OZPORT=? Replace ? with your commport number (1 thru 4) OZBASE=? Replace ? with the Base Address of your port hardware OZIRQ=? Replace ? with the Int Request # of your port hardware (NOTE: the above two variables are used *only* if your comm port resides at a non-standard base address and/or int request line (for example, PS/2 systems on COM3 or 4.) If one is used, the other *must* be used as well.) OZPATH=? Replace ? with the full path to use for up/downloaded files OZMAC=? Replace ? with the full path/filename of your macros file OZGIF=? Replace ? with the full path to your GIF/RLE files OZOPT=?... Replace ? with one or more of the option letters in the parameters list below. When using command line parameters, all parameters must begin with either a dash (-) or a forward slash (/) character. Parameters that require qual- ifying information (such as the port selection parameter) must have the information immediately after the option letter with no space. At least one space must separate each parameter. Below is the list of available parameter option letters: C{portnumber} Select the comport. If you use COM2, this would be "/C2". The default is COM1. Ports 1 thru 4 are available. A{baseaddress} Specifies the non-standard base address for the chosen port. I{irqnumber} Specifies the non-standard Int Request line # for the chosen port. If either the A or I parameters are used, both must be used. If you are using the program as a stand-alone comm program rather than from within another comm program (and, generally, _only_ when you use it as such), 4 other parameters are available to configure the port. They are: B{baudrate} Specifies the baud rate setting at which to open the port. Available baud rates are 300, 1200, 2400, 4800, 9600 and 19200. The default is to use whatever setting the port currently holds. P{parity} Specifies the parity setting to use. Normally either None or Even, but Odd, Mark and Space settings are available as well. You only have to provide the first letter of the parity type word (so setting None parity would be "/PN".) W{dataword} Specifies the data word length; 5, 6, 7 or 8 databits. S{stopbits} Specifies the number of stop bits (almost always 1.) The other available parameters are used to configure the way OZRLE works. These are the "options" settable with the OZOPT= environment variable. They are: X Exit OZRLE immediately on completion of a protocol transfer. The default is to return to OZRLE's internal terminal mode so you can download more files or navigate to another area of CIS. This option is normally only used when the program is being called from within another comm program's script file for automatic execution. D Drop carrier on exit. The default is to leave CarrierDetect high. Using this parameter will mean that OZRLE will break any existing connection on the modem when exiting - not a good idea when you are loading the program from within another comm package. N Turn off the audible alarm normally provided at the end of a protocol transfer. The default is to provide a beeper at the end of a proto transfer and wait for a keypress before continuing. When this switch is used, no alarm sounds and the program does not wait for the keypress. Q Automatically send an XON character on startup. This param is normally only used with the CIS-specific "auto-navigator" programs AUTOSIG and TAPCIS, both of which send an XOFF flow control command to CIS when shelling out to DOS. Some versions of the TELIX comm program seem to need this switch as well. U Automatically send a Ctrl-U character on startup. Using this parameter means that, on startup of OZRLE, the CIS system will automatically interrogate OZRLE for its terminal-type and protocol-support capabilities. This option should be used with caution; in a few places that you might call OZRLE the sending of the Ctrl-U may confuse the CIS system or may abort the imput prompt that was waiting when you called OZRLE. Z Forces use of program's monochrome screen colors set. Some monochrome video hardware tries to "emulate" color; on these video systems the normal colors used for the prompt line and protocol status window may be unreadable. If you find this to be the case (common on some Leading Edge machines), use this option. Also see my OZPATCOL program for setting colors. L{filespec} Tells OZRLE to look for and load a macros file named {filespec}. OZRLE does _not_ search the DOS path for this file, so you must explicitly provide any path information if the file is not in the DOS current working directory. F{path} Tells OZRLE to put all downloaded files in the {path} drive and/or subdirectory, and to take all uploaded files from that same location. OZRLE verifies that the specified path does exist and if it does not notifies you of the error and reverts to the current DOS working directory. Note that you can override this path by including any desired path with the filename when answering the "Filename for your computer:" prompt from CIS right before beginning the transfer. T{size} Set the size in lines of the scrollback buffer. The default size is 48 lines (two screenfulls) to keep memory usage to a reasonable size. You can increase this value up to 400 lines (about 16 screenfulls.) If you increase the value beyond the size of available memory, the buffer will not be turned on; keep this in mind when setting the buffer size. EGA480 Tells OZRLE to support the 640x480x16 mode many EGA cards provide. Default is to not support this mode for several reasons; see "Video Stuff" below for more information. Running OZRLE ------------- OZRLE is simple to use. Depending on what general communications software you use, it can be made almost automatic. Due to the wide range of different communications programs available, no one setup will always be right for your particular configuration. However, following these guidelines will make using the program simple and straightforward. A) If your comm program supports it, always install OZRLE as an external protocol module. Some programs or versions of programs do not support defined external protocol modules but do allow the definition of external programs (like editors.) If this is true for your software, use that type of setup. Only use OZRLE from a "general" DOS shell if your soft- ware provides no other support for external programs. Installing OZRLE as an external protocol module means calling OZRLE will be done in the same manner as all other protocols, giving you a consistant interface. B) If your program requires batch files for external protocol modules (ala QModem and a few others), do all parameters options on the batch file command line. Here is an example batch file for QModem: ECHO OFF CLS OZRLE /c2 /fA:\DNLD\TODAY /lC:\QMODEM\VT100.KEY %1 %2 %3 %4 %5 %6 %7 CLS There are several things to notice here. First, we establish the port to use as COM2: (/c2), then the path for downloaded files to be stored under (/f...), and finally the macros file to use (/l...), then we provide for passing other command line settings as we may need from time to time. Note that the files path can be on any drive. Also note that QModem's VT100.KEY file redefining the keyboard to more closely emulate a true DEC VT100 terminal will work nicely in OZRLE. Finally, you can set the standard settings you use most of the time as environment variables, and then remove the /c, /f and /l parameters from the command line above but leave the batch variable identifiers; this way allows you to easily override your envirnment variable settings with command line parameters if a special case warrants. This type of setup is also recommended if you use the program from a "plain" DOS shell or from within AutoSIG or TAPCIS, or if you run the program standalone. C) If your communications program is like Boyan (where you can call the program directly), it is better to use environment variables to set any needed options. This is best done in your AUTOEXEC.BAT file so that the variables are always set. Programs like Boyan make it easy to set a single configuration but make it difficult to modify that configuration for special cases; make your setup flexible. D) In all the above cases, note that unlike most other protocol modules OZRLE does not distingush between upload and download on the command line. This is handled at the start of a protocol transfer by the protocol itself. Therefore, you generally only need one configuration for both the upload and download entries in your comm program. However, a tip here is that if you use different subdirectories for storing downloads and finding uploads, you can set up separate configurations with different paths on the /F option on the command line (either batch file or direct command methods), or set an environment variable for the files path for downloads and override it with a command line setting in the upload setup. Using OZRLE ------------ Most protocol modules, when executed, immediately enter the protocol itself. The B protocols do not work this way. CIS sends a special interrogation sequence to the remote system (you) to make sure the remote can in fact do B and/or B+ before initiating the protocol itself. OZRLE _must_ be loaded and running to reply to this interrogation properly, or you may well not be able to do the transfer. (This is not a deficiency, it is a safety mechanism for both CIS and you.) Many places on CIS where you can transfer files, this interrogation may not be done immediately prior to the protocol initiation; often it is done when you first request a transfer but before CIS has asked you for the filename to process and the file type (binary or ASCII.) Because of this you should call OZRLE _before_ you request the transfer. OZRLE comes up in terminal mode so that you can answer any pending prompts, etc. Usually, when you shell out to OZRLE from another comm program, there is a prompt from CIS pending input. There is no way OZRLE can know what this prompt was and therefore redisplay it (or anything else that was on the screen when you called it) so you must remember what the prompt was and reply to it after OZRLE is operational. This is no problem; just type in what you would have had you been sitting at the prompt. CIS never sees OZRLE load so it never knows you were not able to see the prompt. (If you use the /U or /Q options, CIS will know but won't care.) Some users have noted that they "forget I'm in OZRLE rather than my main program." OZRLE provides a status line at the bottom of the screen at all times to remind you. I have tried to make sure it does not resemble too closely the status lines provided by many other comm programs, to make this recognition easier. Since OZRLE only has 1 set of colors for color video systems and another for mono, you may want to make sure your main comm program uses a different set of colors on its status line as a further reminder. You can change the colors the program uses; get my OZPATCOL program to do so. Many CIS users (most?) log in at 7 bits/Even parity. OZRLE has no problem with this; it knows how to switch to 8 bits/No parity for the actual transfer and back at the correct times. HOWEVER... some serial ports and/or modems do not handle the "flying switch" properly and will cause grief. For this reason I recommend you use 8 bits/No parity at all times on CIS. To do so you must change some of your "user profile" parameters that CIS maintains on you. Enter GO TERMINAL at any ! prompt, amd follow the menus to set your parity to None/Zero. OZRLE provides both a clock and an online timer on its status line. The online timer displays and "ticks" only when a connection is established. If you use the program standalone this timer will be accurate, but if you call OZRLE from another program it will only display the amount of time you have been in OZRLE. Video Stuff ----------- OZRLE supports most common IBM video types, including Hercules Monochrome, CGA, MCGA, EGA and VGA. It also supports many "Super" VGA types, at reso- lutions (depending on the card) up to 1024x768. A chart (below) lists the resolutions supported as well as video hardware types and what mode is used for that hardware. Some important notes concerning graphics modes and this program: All video types: TEST FIRST!!! Save yourself some possible grief and connect time - test the program's video handling in offline mode first, to make sure your hardware and OZRLE get along and that you have used the SETSVGA utility correctly. Download a few GIF images using a normal protocol file transfer, making sure the image sizes match up to your video modes, and check OZRLE out before trying to view online. If by some rare occurance the program and your hardware don't see eye to eye, you'll know about it before you try to view online and waste time. All video types: Where the program has multiple video modes to choose from (all color systems), the mode will be as closely matched to the image reso- lution as possible. Most images created on IBM hardware will exactly match one of these modes, but images created on other hardware (Macs, Amigas, etc.) may well be "odd" resolution dimensions. Since the vast majority of these odd-sized images will be tall-and-narrow rather than short-and-fat, the pro- gram concentrates on the image height as the determining factor in selecting a mode. Some odd-sized images can "fool" the program though, so be aware of image resolutions before viewing or downloading a specific image. The same goes for colors; trying to view a 256-color image on 4-color CGA hard- ware is usually a disapointment. CGA users take note: I recommend Tom Potoki's exellent TWOBIT program for offline viewing high-color images on CGA hardware. The offline decoders have two advantages over the online decoders: they have the luxury of time (I have to concentrate on the serial port) and they have the complete file already at hand to simplify the process of dithering multiple colors down to 4 or 2 (I only have what has already come in the port so I can't "look ahead" to balance tonal qualities, and due to the nature of this program I can't make it much larger by adding the code nessessary to do the dithering.) Another one for all video types: If you have used offline decoders you may try the first online view and wonder why it is so s-l-o-w and why it displays in spurts. Keep in mind that image data arriving to the program via the serial port is comming in at one/one-thousandth or less the speed a program can read data from a hard disk; it _has_ to be far slower. The reason the program displays in spurts is because of the transfer protocol protection being used. The actual image data is in compressed binary format as it is received and must be uncompressed by the program before it is displayed; because one byte corrupted by line noise can cause the decompression code to enter hyperspace at Warp IX, a transfer protocol must be used to insure the data's integrity before it ever is handed to the decoder. Because proto- cols send data in blocks, a block must be received and verified before it is handed to the decoder; the decoder processes the data to the screen before turning control back over to the protocol section... thus the "display/wait" spurts. This is also a limitation of the operating system, as environments that can process multiple "threads" of programming can easily be receiving one block while they process the previous block. Good ol' DOS... Hercules Mono and InColor(tm) cards: This code has been designed on and tested on a true-blue Hercules(tm) brand card and 3 "clone" herc cards of various heritage; I cannot guarantee it will work correctly on all clone cards. Most herc clone cards on the market today are quite compatible, but many earlier cards have problems with graphics modes. Caveat emptor. If you have two video systems (one herc mono and a color system of some type), the program should always detect and use the color system. If for some reason it wants to detect and use the herc card, I'm sorry... you typically will have all kinds of grief and will not be able to use the program; try removing one card or the other. Finally, while I have gone to some lengths to provide decent display of >2 color images on Herc hardware, it will always be somewhat of a disapointment. I do recommend that, if you have Herc mono and want to view the weather maps, do so in the BWMAPS section using RLE instead of the GIF format in the COLMAPS section. Note that Hercules InColor cards are treated as monochrome and not color. EGA (true): Like VGA, there are a multitude of EGA cards on the market. Many are "Super"EGA cards and support modes above the normal EGA level (640x350x16). OZRLE supports only one of these enhanced modes, the 640x480x16 mode 0x12 that is the same as VGA 640x480x16. Many users will have a system made up of one of these "SEGA" cards and a generic vanilla EGA monitor. (A sad but common occurance in the cheap clone marketeering game is to advertise a super-gee- wowie EGA card... and deliver the system with a standard EGA monitor that can't take advantage of the card's capabilities. The unknowing, hapless purchaser almost always gets stuck. End of editorial.) Because of this, OZRLE defaults to only supporting up to 640x350x16. If you can handle the 640x480x16 mode, use the /EGA480 command line switch to enable support for mode 0x12. If you use this switch and nothing displays, or you get a few garbage pixels, or (rare) the system locks up, your card can't support the 640x480 resolution as a BIOS-directed mode. (A few cards support it but not via the video BIOS, only thru direct hardware programming.) If you get what seems to be an image but it wavers or jitters rapidly, or has a bad vertical roll, your monitor cannot handle the higher sync rate used on the 0x12 mode. Try this offline to verify before you use it online. EGA (true): The EGA low-resolution mode (320x200x16) is an oddball. IBM in their infinite wisdom made the handling of this mode a little different on the card than the other EGA modes, and then compensated in their EGA monitor. Some aftermarket EGA cards follow right along with this different handling, but very few monitors do the resultant nessessary compensation; some EGA cards just don't support the full 16-of-64 palette in 320x200x16 mode. As a result, this mode will usually provide very poor color resolution on a given image compared to a higher resolution mode on the same image. As a result, the EGA 320x200x16 mode is not normally supported and 320x200 images on EGA use the 640x350 mode to maintain aspect ratio. CIS weather maps and TREND charts, however, will use this mode as the colors are good for these images and give a close-to-full-screen display. VGA ("standard"): You do *not* need to use the SETSVGA utility. In fact, it's important that you do not; if you use it and tell OZRLE that you have a super VGA system when in fact you do not you're sure to see all kinds of problems. SVGA ("SuperVGA"): OZRLE now supports the 7 major SVGA chipsets internally in assembler (no linked-in drivers, etc.) Support is provided for Tseng Labs, Paradise, Video7, ATI, Everex, Trident and Chips&Tech. OZRLE needs to know two things about your video system: which chipset it should support, and what the highest 256-color image size is that your combination of card and monitor can support. The SETSVGA program gets this information from you and patches the appropriate information directly into the executable file. Before you use OZRLE the first time you need to run SETSVGA and answer its two questions. Note that the question on max resolution is for the highest *256-color* mode your hardware can handle, not nessessarily the max mode the card can do. If for instance you have a Paradise PRO with only 256K of video memory, you should use the 640x400 setting as a max mode because you can only do 16 colors at higher modes. Another example would be if you have an STB VGA/em with 512K but only have a "standard" (non-MultiSync) analog monitor, you need to set the max mode to the 640x480 setting. OZRLE will always do at least to 640x480 even when it has to use 16 colors. Also note that the Everex SVGA support is limited to 640x400 (this is all most Everex cards will do at 256 colors.) The Video7 type does not support the 720x540 mode. The 360x480x256 mode 0x13 "special" is not supported in this version; I hope to get it working in a future release. I also hope to get IBM8514/A support added in a future release. Commands Within OZRLE ---------------------- OZRLE provides several commands while operational. These all are used to modify the same functions you set with command line options or environment variables. Generally, the letter used for a particular option setting will be the key used with the [Alt] key to modify that option while in OZRLE. To see a menu of available Alt-Key commands in the program, press the [Home] key. Most all of the commands are self-explanitory. The "Offline View" part of OZRLE is a program within itself. This section allows you to view offline those GIF images you have captured. Press Alt-G to enter offline view mode. Offline view gives many features only found in the powerful offline-only decoders such as a "tag-and-shoot" interface, "slides" mode (display multiple files automatically), large image scroll and "banded" interlacing. Note that while OZRLE has these and other capa- bilities and is a fairly fast offline decoder, it should not be considered a replacement for a good offline-only decoder such as VPIC or FASTGIF. These programs provide faster display speed and many special features that there simply isn't room for in a program such as OZRLE. The available commands in offline view mode are these: while in filepick mode: cursor keys, pgup/pgdn, home/end - move around in the files list enter - display the highlighed file spacebar - "tag" the highlighted file for slides mode display Alt-S or F2 - display tagged files (slides mode) Alt-N - toggle alarm sound on/off Alt-B - toggle banded interlace on/off Alt-A - toggle autosize on/off (Herc, CGA and EGA only) while a single image is displayed (only the esc command works in slides mode): cursor up/dn, pgup/pgdn - scroll large image into view (EGA, VGA only) "1" - force standard image sizing \ "2" - force autosizing / (Herc, CGA, EGA only) enter - exit display esc - abort slides display Another new command is available in OZRLE - the Alt-V (View Scrollback buffer) command. This allows you to see what has scrolled off the top of the screen. Currently this is only one screen in size; I will be expanding it (up to 400 lines user-settable) in a future version. Macro "QuickKeys" ----------------- OZRLE allows you to define up to 40 "QuickKeys" to simplify its use. These keys are the function keys, and the function keys used in conjunction with [Ctrl], [Shift] and [Alt]. Each may have a string of up to 127 characters assigned to it (a "macro".) Macros 1 thru 10 are assigned to function keys [F1] to [F10], macros 11 thru 20 are assigned to [Shift][F1] thru [Shift][F10], macros 21 thru 30 go with [Ctrl][F1] thru [Ctrl][F10], and 31 thru 40 are assigned to [Alt][F1] thru [Alt][F10]. Pressing a QuickKey causes the program to send the macro assigned to that key out the serial port. The definition for macro keys are stored in a flat ASCII text file. Do not use a word processor that inserts special control codes or other non-standard characters to create this file, or be sure to save the file in ASCII or "non-Document" mode. The file is read by the program sequentially a line at a time, each line being assigned to the next macro (line 1 goes to macro 1, line 2 to macro 2, and so forth.) The file does not have to be 40 lines long. To skip a macro, insert a blank line in the file. The default name for this file is OZRLE.FKS, but you can name the file anything you like as long as you set that name to the OZMAC environment variable or set the /L command line option to that filename. Previous versions of OZRLE gave a warning if it could not find the OZRLE.FKS file on startup and no new file name was provided; many users found this confusing so the warning has been removed unless OZRLE.FKS (or the filename you specify) is found but corrupt in some way, or if you provide an overriding filename and _that_ file is not found. Macro Subcommands ----------------- OZRLE provides further flexibility by allowing several embedded subcommands within macros. These subcommands allow you to insert the current port, baud rate and parity setting, have a macro request input and then place that input in the macro before sending, wait until a character is received, and to use a macro to shell to DOS and execute the macro as a DOS command line. Addition- ally, subcommands are available to insert a carrage return in a macro and to delay macro processing 1/2 second. Finally, standard "carat notation" is allowed to insert control characters in a macro. Where found in a macro, the subcommand is replaced with the data it specifies. All embedded subcommands (except the CR and delay characters and the control character notation) begin with the "at" symbol (@). The following list defines the available subcommand letters: O Force a DOS shell, and use the macro as a DOS command line. This only works when the first 2 characters of a macro are "@O", otherwise they are ignored. The macro is processed for insertion of all other subcommands before executing. The macro is not sent to the port. M The "M" subcommand takes a second qualifying letter defining the specific modem parameter to be inserted in the macro. these qualifiers are: C - insert the current port number. B - insert the current baud rate. P - insert the current parity setting. For example, placing "@MC" in the macro when the current port is COM1 would cause the subcommand to be replaced with "1". W The "W" subcommand takes a second qualifying character or string and waits until received. This gives a very limited but useful "script" capability. Example: "@W!" would wait until the "!" char was received (or the <esc> key is pressed) before continuing execution of the macro. When waiting for more than one character (a string) you need to enclose the specified string in double-quote marks. Example: to wait for the string "User ID:" you would use `@W"User ID:"' in the macro. You can place up to 10 "Wait" commands in a macro and each can wait for a different character or string. I The "I" subcommand forces the macro to prompt you for input, and then insert that input in place of the subcommand. An example macro to call the DSZ external ZModem protocol module from within OZRLE to upload a file to a BBS would probably contain this: @O DSZ port @MC speed @MB sz @I When you press the QuickKey assigned to this macro, you would first be prompted for input. Assuming you input "FOO.BAR", and you were using COM1 at 2400 baud, the following command line would be executed by DOS: DSZ port 1 speed 2400 sz FOO.BAR --- The pipe character (|) is used as a carrage-return in a macro. The tilde character (~) forces a one-half second delay where it is found in the macro. These two special characters are provided to simplify using macros as modem command strings. As an example, let's say you want the F1 key to send a command to your "Hayes-compatible" modem to reset and then dial the number of your CIS node. Assuming the number of the node I use and the way I normally set my modem, the following macro would be used: ATZ|~~~~ATM3V1X4DT922-3308| This sends the "ATZ" command to the modem with a carrage-return, waits two seconds (so the "OK" reply from the modem can display), then sends the setup/ dial command string and a carrage-return. Another example is the macro I use to log on thru Tymnet: |~~~~~~~~A@W:CIS02|@W"User ID:"70000,000|@W"Password:"my-password| Once I get the "CONNECT 2400" from the modem, I press F2 for this macro. It sends a carrage-return, waits four seconds for Tymnet to give its "Please enter your terminal identifier:" prompt and replies with the "A" nessessary, waits for the "Please log in:" Tymnet prompt, sends the "CIS02" and carrage-return to tell Tymnet to connect me to CIS, then waits to allow CIS to issue the "User ID:" prompt and sends a userid and carrage-return, and finally waits for the "Password:" prompt and sends a password. The Protocol Window ------------------- During a protocol transfer a window appears on screen detailing the transfer activity. Most things about the window are pretty self-explanitory, but one area deserves clarification - the "Port" and "Data" percentages on the "Ef/Tm" (Efficiency/Time) line. The percentage displayed in the "Port" column is the comparison of current protocol "raw" port rate to the current port baud rate setting of the UART. In other words, at 2400baud this figure would optimally be 100% if we were seeing 240 bytes per second comming in the port during a transfer. Since CIS uses its packet-switching network and network delays of some magnitude are inevitable, this figure will almost always be less than 100%. Normally you can expect greater than 230 cps "raw" rates on downloads, but uploads often fall below 200. Connections established thru suplimental carriers such as Tymnet may well be less. The percentage under the "Data" column, on the other hand, is the ratio of total data bytes received to the protocol's average "raw" port rate. In other words, the efficiency of the actual data comming in the port. This figure normally runs around 92 - 96% for binary files and 97 - 99% for ASCII text files. However, bad packet resends when an error occurs and is corrected cause this figure to drop, sometimes dramatically. Providing both figures makes it easier for you to decide when to abort a transfer. If the "Port" figure is dramatically low (usually due to a high network traffic load but can also be due to delays caused by suplimental carrier networks), you may want to abort the transfer and wait until network traffic had dropped so good port rates are possible. If the "Data" figure is low (usually due to a high error-packet count), you may want to abort and call back on another node. The time display under the "File" column is the time the transfer has taken so far, while the time under the "Remaining" column is an estimate of the time it will take the rest of the transfer to complete. The "Remaining" time figure will vary based on the cur- rent port rate as it is recalculated at the end of each packet. On GIF image views that are protected by protocol (right now only the TREND area of CIS does not use B+ protocol protection), a small window is displayed after the image view is complete, and notes the important protocol performance results. Because the actual image data display process between blocks takes a little time, it is very rare that you will get the same performance figures on an image view that you get on a file download, but they should be pretty close. Remember, the TREND area does not provide protocol protection on the image stream, and if that unprotected image data gets corrupted it will usually cause the system to lock up. While on the subject of the TREND area of CIS, another note: TREND works funny. When you enter the TREND area you are prompted for a stock (either name or ticker symbol) and then for "number of periods". After this last prompt, you get nothing - for as long as 2 to 3 minutes. No "Please wait" message, nada. What is happening is that the CIS computers are analyzing your request and "building" the graphic image in real time, and that _takes_ time. The problem is that the host appears to have "died" or disconnected; hitting [enter] a few times does nothing, nor does the usual Ctrl-P or Ctrl-C abort commands. Just be aware of the delays and don't think CIS has dropped you. I've hit FEEDBACK about this problem, and since FEEDBACK is free I hope all of you who use TREND will also stop by there and leave a complaint message (not nasty of course, just a polite reminder) that there needs to be some sort of "Please hang on - this can take a few minutes" message after that last prompt. Thanks. Video Modes Capabilities Charts ------------------------------- The following chart lists the video modes OZRLE uses for graphics images. RLE images always use the lowest size mode available on a given video system, usually 320x200; since Herc mono has only one size mode, RLE and small GIF images will show only in the upper lefthand corner of the screen. Mode numbers are Decimal. Adapter Mode # Description (WDTH x HT x NUMCOLORS) ------- ------ -------------------------------------------- Herc Mono xxx 720x348x2 CGA 04 320x200x4 (grayscale) 06 640x200x2 EGA 13 320x200x16 (normally used only on CIS images) 14 640x200x16 16 640x350x16 18 640x480x16 (requires /EGA480 switch) MCGA 17 640x480x2 19 320x200x256 VGA 14 640x200x16 (and "std" VGA 16 640x350x16 modes on most 18 640x480x16 SVGA cards) 19 320x200x256 SVGA varies 640x350/400x256 (see below) 640x480x256 800x600x256 1024x768x16 Here is a list of VGA/SVGA chipsets, popular cards that use them and the max 256-color image size (these are currently supported in OZRLE): Chipset/card Max 256-color mode ------------ Tseng Labs: Orchid Designer 800x600 640x480 STB VGA/em 800x600 640x480 Genoa 5200 800x600 640x480 Paradise: AST 640x400 AST VGA Plus 640x480 Compaq 640x480 Dell 640x480 Paradise VGA Pro 640x480 Trident: Maxxon 800x600 640x480 Logix 800x600 640x480 ATI Prism Elite 640x480 Everex: EV-673 640x400 ATI: VGA Wonder 800x600 640x480 Video 7: VRAM 640x480 V7 VRAM 800x600 FastWrite 640x400 FastWrite AD 640x480 Popular cards that currently support only 320x200x256 in OZRLE: Rennasance GRX I & II (CIRRUS chipset) Zenith VGA, Tecmar VGA & VGA-AD (early Tseng Labs) Sigma VGA/H (another early Tseng Labs) most other VGA cards IBM 8514/A (VGA emulation mode) IBM MCGA and VGA Where two sizes are listed, the first is for that make/model card with 512k video RAM memory installed and the second is for the same card with 256k. OZRLE supports almost all VGA cards at 320x200x256 and 640x480x16. Some cards are still on the market with older chipsets by one of these mfgrs that do not match up modes properly (example: the Zenith, Sigma VGA/H and Tecmar "std" and VGA-AD cards use chipsets made by Tseng Labs but with grossly dif- ferent setups; these can only do 320x200x256) so be aware that older cards may not work properly. I hope to have these "oddball" chipsets supported in a future release (especially the IBM 8514/A.) Many of these cards have other resolution modes as well, but these are the only ones that are both common across most chipsets and also generally used for GIF images. Kudos, Credits, Karma Enhancements ---------------------------------- The sysops of the IBMNet forums on CIS: Don Watkins, Connie Kageyama, Chris Dunford and Vern Buerg. My primary beta testers, and the greatest group of folks around. Ditto for Valerie Zen and Tom Potoki, sysops of the Graphics Trilogy forums on CIS, who also help test. Really have to include the whole of the Developer's Group in the PICS forum as many have tested, provided suggestions, etc. Kim, Brian and Rich of TurboPower Software, for writing and maintaining the best library of Turbo Pascal utility routines in the free world. Chris Young, HSX-200 SysOp and GIF wizard, for the asm LZW decompress and GIF header decoding, and the EGA video routines. *BIG* help! John Bridges (of GRASP fame) for his SVGA bankswitch and modesetting code. Russ Ranshaw ("Wiz10") and others at CIS, for providing exellent documentation on the B+ protocols, and understandable source code for same. Ditto to Brion Jones of CIS for informative literature on interrogation/response sequences and terminal reply codes. Most importantly... you, the users. Your questions, criticisms and sugges- tions have helped make the program what it is. If you like it thank yourself, not me. Point of Contact ---------------- I can most easily be reached via CompuServe; my ID# is 71520,77. Please leave questions in either IBMNEW or IBMCOM rather than EasyPlex; other users or the sysops may well be able to give you a faster answer. If you need to contact me concerning registration, please do so by EasyPlex or US mail: Steve Sneed 71520,77 409 San Juanico Santa Maria, CA. 93455 This program is not shareware in the traditional sense; I do not require private non-commercial users to register or pay a license fee (see the section on license requirements at the top of this document.) If you have a burning urge to send me money anyway... I won't turn it down. <grin> Please make checks payable to Steve Sneed. Updates are only done thru CIS; I do not notify users of updates (except for fully-licensed commercial users.) If you are registering for full license, please plainly state so in your corospondence along with how you are using the program. Site licenses and multi-license discounts are available; please contact me for specific info. Finally, please do not call me voice, and I cannot accept any collect calls. I don't mind helping folks, but 7am and 11pm calls do not help my baby daughter sleep. Thanks. I hope you enjoy the program! <eof>