Garbo/Garbo.cdr/pc/gifutil/ozrle93b.arc/OZRLE.DOC

Text File | 1989-09-16 | 48KB | 910 lines

                                     OZRLE
                                  Version 9.3b
    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.

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.

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:  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.



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 imformation 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 SVGA 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
capabilities and is a quite 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 only 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
     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
     "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.



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, because 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 Chart
------------------------------

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 Mono           BGI           640x350x2

EGA (64K card)     BGI           640x200x16
                                 640x350x4

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          640x350x256/640x400x256
                                 640x480x256
                                 800x600x256
                                 1024x768x16



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 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>