OZBEXT Short Docs 03/03/88 -------------------------------- OZBEXT version 3.7x Copyright(c)1987,1988 Steve Sneed/Ozarks West Software Placed in the public domain by the author. ============================================================================ Syntax ------ OZBEXT [port] [baud] [parity] [data bits] [stop bits] {-x} {-v} {-d} Params in square brackets are required, those in curly braces are optional. REQUIRED PARAMETERS: port: 1,2,3,4 - the standard COM number for the port in use. COM 3 & 4 at the "standard" address for these devices: COM3 - IRQ4, 03E8h COM4 - IRQ3, 02E8h baud: 300,1200,2400,4800,9600,19200. CTS support for high-speed modems - CTS monitoring automatically implemented above 4800 baud. parity: N,E,O,M,S. None, Even, Odd, Mark, Space. databits: 5,6,7 or 8 (almost always 7 or 8). stopbits: 1 or 2 (almost always 1). OPTIONAL PARAMETERS: -x: if set, causes OZBEXT to return to it's own terminal mode after the com- pletion of a Standard B transfer or the completion of a QuickB file transfer. The default is to exit back to the calling program. Note that QuickB "Applications Packet" and "Transport Parameters Packet" transfers do not invoke this exit. -v: if set, causes OZBEXT to use the CIS "VidTex" terminal emulation for cur- sor positioning. The default is to emulate an ANSI graphics terminal. -d: if set, causes OZBEXT to drop DTR on exit, hanging up any call in progress. The default is to leave DTR high on exit so connection is not broken when returning to the calling program. -s: if set, uses "silent" mode. Default is to use audible warnings. -h: if set, uses half-duplex mode. Default is full-duplex. Use --- This program was designed to be called from within another comm program to add support for the CIS "B" and "QuickB" protocols and simple VidTex term emulation. Examples of programs with this capability are Boyan and OzCom5. The program can also be used with most any commware that has a "Shell to DOS" capability. When using OZBEXT with a program that has "Shell-to-DOS" but does not directly support external modules, it is suggested that you create a batch file calling the program with the correct parameters. In order for the program to function, it must be loaded prior to requesting the transfer from CIS. CIS "interrogates" your program when a "B" protocol transfer is requested, and unless this program is running it will not be responded to properly. Where possible, it is suggested that you load OZBEXT as soon as possible after logging on to CIS, using the "-X" command-line switch, and stay in OZBEXT for the duration of the call. Commands -------- The following keystroke commands are available within OZBEXT: Alt-Z : Clears the screen. Alt-X : Exits OZQB. "B" Protocol ------------ OZBEXT fully supports both standard "B" and the new "QuickB" protocols. Detection of protocol type and transport parameter setting is fully automatic. To abort a transfer in progress, use ^X (NOT Alt-X!) The setting of the -x parameter is respected. Note that CompuServe normally logs on at 7 bits/Even parity, while the "B" protocols require 8 bits/No parity. The switching of these parameters for the transfer is automatic. Upgrades -------- * (3.71) Two figures are now displayed at the end of a transfer - the overall transfer rate and the effective rate. The overall rate is the average bytes per second for all bytes sent or received during the transfer, while the effective rate is for the actual contents of the file sent/received. Because of the way the B/QB protocols use "masking" bytes, and because of at least 2 extra packets containing control information only, there will almost always be a difference between the two figures - a difference that usually will increase somewhat as the size of the transfered file increases. While the effective rate is the true measure of worth for any transfer, the quest for the highest possible bytes/second number leads most programmers to use the overall figure. So that my programs will appear "competitive", I provide the overall figure, but I suggest that you use the effective rate number when comparing actual transfers. Comments -------- Thanks to IBMNet SysOps Connie Kageyama and Don Watkins for the idea for this program. This program was designed to be as small and compact as possible - there are darn few "bells and whistles". It's "big brother" OZQB (also available here and elsewhere) has many added features such as RLE graphics support on most any monitor, "Split-Screen" mode for easy conferencing, full function key support, Shell-to-DOS capability including calling other external protocol modules such as DSZ, automatic VidTex/ANSI support selection and more. It is quite a bit larger and requires at least 450K when called from within another comm program (192K stand-alone) but is still small enough and quick enough to be used as a called module on the typical 512K - 640K system. If you like this program but need the added capabilities, try OZQB. With the release of OZQB, the two programs will take different directions - OZBEXT will continue to be small and compact, providing only the minimum functions nessessary in support of "B" and "QuickB", while OZQB will be the "featureitis" version. I am also working on a new version of OzCom for the full-featured commware user. This program was written completely in Turbo Pascal 4.0. Enjoy! Steve Sneed 71520,77 or The C2G BBS 805-922-3318 3/12/24 24hrs FidoNet Node 102/2872 U.S. Mail: Computers To Go 1539 S. Broadway Santa Maria, CA. 93454 ============================================================================= Starting with this release of this document, I will attempt to add information concerning specific comm programs that may possibly have problems with OZBEXT, or answer questions about OZBEXT and other comm programs. SmartCom (versions II and III): This program does some really wierd things with both the serial port and the video. Since OZBEXT does *all* of its screen output thru DOS via DOS service 06h, and I do not have access to the inner workings of the various versions of SCom, I can't say why a video lockup occurs when SCom returns from OZBEXT... but video lockup it does. The port still functions normally (after much work) and is properly re- initialized on return, but still no video. Final recomendation: do NOT use OZBEXT with SCom unless you intend to use OZBEXT for the entire CIS session. You will be forced to exit SCom after returning from OZBEXT. BitCom (various versions): BitCom has changed a great deal across versions in the port-handling and port-reset-on-return-from-shell areas. Earlier ver- sions (2.6 et al) do not reset the port on return from a shellout, which causes BitCom to seemingly lock up on return. A simple way to cure this is to, on return, use BitCom's parameter-setting function to change the port params from 8/N/1 to 7/E/1 (or vice versa) and back. This resets the port and returns control to BitCom. Note that you may loose a few char- acters from the host while you do this switch. Also, this is another program that I recomend you use OZBEXT in -X mode and stay within OZBEXT while connected to CIS. SmartTerm 220/240 (latest versions): OZBEXT works fine with these programs. While they are primarily terminal emulators (exellent ones!) and are seldom used as modem communications programs, some folks use 'em for both. PROCOMM ("Plus" version and earlier): While version 2.4.2 of this program's B implementation seems to work OK, earlier versions and the new "Plus" version's B protocol is full of bugs. You definately should use OZBEXT or another external B module with PROCOMM. PROCOMM's shellout function presents no known problems. QModem, Boyan, OzCom5: All of these programs work fine with OZBEXT and every other external module for any protocol type known. They should - they were designed for external modules! I've used QModem in its various releases for years and know John Friel's program to be rock-solid. Boyan, while lacking some of the bells-and-whistles of some of the other comm programs, is by far the smoothest and friendliest commware around for the novice to medium-power user. OzCom5... well, I wrote it. Oh, yes... Telix 2.12 is another exellent program that supports OZBEXT and other external modules nicely. AutoSIG and TAPCIS: Don't waste your time with OZBEXT. Both of these pro- grams have exellent B protocol implementations internally. They are de- signed exclusively for CIS use and provide many features no other comm programs can match for accessing CompuServe. TAPCIS does a few things AutoSIG will not, while AutoSIG is free and TAPCIS is shareware at $79. Take your pick - you won't be disappointed with either. ----- If you use OZBEXT with a program (especially commercial) not listed here, please drop me a note at one of the above addresses letting me know how it works for you. If you have a problem, don't hesitate to let me know that either. While I'm a very busy man, I'll do what I can to help you. Connie Kageyama, Co-SysOp of IBMNet on CIS, has been extremely helpful while I developed and debugged this program (as have all of the IBMNet SysOps!) and can also provide you with help and information. I can respond much faster to messages sent either directly to my board or to my board via FidoNet NetMail. Thanks! Steve