OS/2 Shareware BBS: 8 Other/08-Other.zip/GIFDEV.ZIP/CISGIFON.TXT

Text File | 1989-02-10 | 16KB | 380 lines

NOTE: All references in this document to "B protocol" signify the com-
plete original B protocol including the transport layer for dynamic error
checking of the complete data stream.  Where the document references only
the B protocol file transfer facility, or the specification differs from
the current "Quick B" and "Full B Plus" implementations, I have added
notations to the specific differences.  Where such references occur, [B]
denotes the original B protocol, [QB] denotes the "Quick B" version (a
subset of full B Plus), and [B+] denotes the complete "B Plus" implemen-
tation.  For broader clarity, I have replaced hexidecimal representations
of ASCII printable characters with their printing versions surrounded
by double-quote marks.  Original document provided to me courtesy of Brion
Jones, CompuServe Inc.           Steve Sneed  71520,77  10/11/88

This document was originally put in machine-readable form for a BPlus
protocol developer friend.  I have added additional comments in this
release for those wanting to implement online GIF decoders.  S.S.  11/10/88

        -------------------------------------------------------


                            Interrogation

1.1  Interrogation

Before protocol activity can occur between a host computer and a remote
computer an interrogation process must be performed.  The host computer
must determine that the remote computer is running a communications pro-
gram which supports B protocol.  Otherwise communications will be incom-
patable.


1.2  The Interrogation Procedure

The CompuServe interrogation procedure is used to determine whether a remote
computer is running VIDTEX or another communications program.

The first step to the interrogation process is an automatic terminal recog-
nition.  The CompuServe host computer first transmits an Enquiry Control
Sequence to the remote computer.  The remote computer must reply with a
correct enquiry response for host synchronization to occur.  This will
contain the current B protocol packet number if the remote computer is
running VIDTEX.  Otherwise further investigation will stop.

If the remote computer is not running VIDTEX, the current communications
program may or may not support B protocol.  Software that does not support
B protocol may substitute the following response:

   <DLE>"0"               [B]
   <DLE>"+"<DLE>"0"       [QB]
   <DLE>"+""+"<DLE>"0"    [B+]

If a valid packet number (or the above "generic" response) is received, the
host computer continues its interrogation sequence:

   <ESC>"I"

The remote computer responds to an interrogation sequence with an interrogate
response sequence.


1.3  The Interrogate Response Sequence

The interrogate response sequence describes the features supported by the
remote computer, and can be used to satisfy interrogation requirements
when the communications program supports B protocol, but is not VIDTEX.


Syntax:

   "#"<Mod><Ver><F_Codes><CR>                       [B]
   "#"<Mod><Ver><F_Codes><"+"><Check_Value><CR>     [QB][B+]

Sequence Information

   The value of <Mod> is one of the following three-character ASCII codes
   used to describe the computer:

      AP1  Apple I
      AP2  Apple II
      AP3  Apple III
      APX  Apple Macintosh/Lisa/MacII
      AT8  Atari 400/800
      ATX  Atari 8/16/32-bit
      CC1  Commodore 4032
      CC2  Commodore VIC-20
      CC3  Commodore 64
      CC4  Commodore 8032
      CCX  Commodore C64 and Amiga 500/1000/2000
      CPM  CP/M system
      EH1  Electrohome
      EH2  Electrohome 699
      EH3  Electrohome 709
      IB1  IBM PC
      IB2  IBM PCjr
      IBX  IBM compatable
      RC1  RCA VP-3301
      RS1  TRS-80 Model I (level I)
      RS2  TRS-80 Model I (Level II)
      RS3  TRS-80 Model II
      RS4  TRS-80 Videotex
      RS5  TRS-80 Color Computer
      RS6  TRS-80 Model III
      RS7  TRS-80 Model 12
      RS8  TRS-80 Model 16
      RS9  TRS-80 Model 100
      RSA  TRS-80 Model 4
      RSB  TRS-80 MC-10
      RSC  TRS-80 CoCo II
      RSD  Tandy 2000
      RSE  TRS-80 CoCo III
      RST  Radio Shack, not IBM or CoCo compatable
      RSO  TRS-80 CoCo (other)
      OT1  Bryan Egger's OrcTerm
      OZ1  Steve Sneed's OZBEXT
      TT1  Chris Dunford's Triple Talk
      PCN  Professional Connection
      CM1  McGuinness COMSH
      DTE  Wilhite Dumb Terminal
      HST  Wilhite Host
      NAV  CompuServe Navigator for Macintosh
      XXX  Other model/type (may also be used in place of above choices.)

   The value of <Ver> is the current ASCII software version.  This is up to
   the developer, and can be up to ten of the following characters, concluded
   with a comma:

     Letters
     Digits
     Period


   Each <F_Code> value is a two character ASCII code used to describe a
   function.  When more than one code is supplied they must be separated
   by a comma.  The following values are supported:

      Cursor/Screen Control

         AC     ANSI Color  (not cursor)
         CA     ANSI Cursor (ANSI/VT100 cursor control)
                             (See note 1 at end of document. S.S.)

         CC     VIDTEX/VT52 Cursor control  (See note 2.  S.S.)
         CW     "Wide Mode"                 (See note 3.  S.S.)
         SSyx   Screen Size                 (See note 4.  S.S.)


      Graphics support

         GF     GIF graphics
         GH     RLE high-resolution mode graphics
         GM     RLE medium-resolution mode graphics
         NA     NAPLPS
         NF     NAPLPS full


      Protocols     (See note 5.  S.S.)

         AP     Application protocol
         CB     Capture buffer
         DT     B protocol disk transfer
         PB     B protocol
         PX     XMODEM protocol
         PZ     ZMODEM protocol


      Miscellanious

         HC     Hard copy (support for printer)
         XX     Empty fields, ignored  (optional)

   All other two-character codes are reserved.   The empty fields (XX) code
   is allowed so that a string can adopt a fixed length.  This allows for
   future versions which might support additional features.


   The value of <Check_Value> is the simple addition of characters as they are
   transmitted, with ZERO being the initial value.  The check value is masked
   down to a 16 bit value before conversion and does NOT include itself (See
   note 6.  S.S.):

      1.  Check value = 0
      2.  For i = 1 to n
              begin
              transmit response character [i]
              check value = check value + ord (response character [i])
              end
          (NOTE: the response string includes the trailing ",+")
      3.  check value = check value AND 0xFFFF
      4.  Transmit check value as ASCII decimal value char string
      5.  Transmit <CR>

   For example, a response string of "#IBM,CC,GH,GM,PB,+" would have a
   <Check_Value) of 1085 and would be transmitted as:

      #IBM,CC,GH,GM,PB,+1085<CR>

   An interrogation Response Sequence must be less than 80 characters in
   total length, including checkvalue digits.

        ---------------------------------------------------------


NOTES:

  1.  Both DOS ANSI and the DEC VT100 emulation sets are improper and unequal
      subsets of the complete ANSI X3.64 terminal control code standards.
      CIS uses the DEC VT100 commands.  Due to inconsistancies in the various
      "<ESC>[?J" clear part/all screen commands in the two emulations, you
      cannot do all screen writes unfiltered via ANSI.SYS on a DOS system;
      doing so will cause screen clears after menus are displayed but before
      the final menu prompt is displayed (anoying!)  The specific ANSI "J"
      commands should be mapped as follows:

      <ESC>[J or <ESC>[0J    Clear from cursor position to end of screen
      <ESC>[1J               Clear from "Home" position thru cursor position
      <ESC>[2J               Clear entire screen, "Home" cursor.

      The default numeric parameter for the "assumed" J command ( <ESC>[J )
      under VT100 is "0", while under most versions of the DOS ANSI.SYS
      driver it is "2" - hence the confusion.  Sigh...

      CIS uses 3 "private" ANSI commands, for GIF image data processing/
      control.  These are:

      <ESC>[>0g   GIF support interrogation  (See the GIF 87a or 88h docs for
                                              reply info.)
      <ESC>[>1g   Start GIF screen image processing
      <ESC>[>2g   Start GIF printer image processing

      Unless you want to support GIF image processing (a *real* chore!),
      filter these private commands when received.  (DOS ANSI, not under-
      standing these sequences, will blindly display them onscreen.  Yuk!)
      If you do want to handle GIF, be aware that the host sends the private
      escape scquences at N81, and expects the responses to also be at N81 -
      even if the user is currently at E71!  A comm program must therefore,
      upon receiving the <ESC>[>0g sequence, switch to N81 to send the
      response... and then remain at N81 until it is sure the next incomming
      data is not a <ESC>[>1g or 2g initiator sequence.  In most areas of
      CIS, this is easy; the host does not interrogate for GIF support until
      just before it is ready to initiate the actual image send, and you can
      therefore switch to N81 and stay there until the image processing is
      done.  HOWEVER... in COLMAPS, TREND and possibly some other areas of
      CIS, the <ESC>[>0g interrogation is performed *on entry to the area*
      rather than just before image send - you must switch *back* to E71
      to handle the following prompts and replies.  Therefore, the comm prog
      must, on seeing the <ESC>[>0g, switch to N81 and send the reply, then
      see if the next 3 chars are "<ESC>[>" and switch back if they are not.
      You must look at at least 3 chars.  In COLMAPS and TREND, the next
      bytes sent are an ANSI clear-screen ( <ESC>[0J ) command if ANSI/VT100
      support is in use, and the program must see that it is not the image
      send init sequence before switching.  I chatted with Brion on this once
      and agree with CIS' reasoning for doing it (the image, being LZW
      compressed data, *must* be handled in 8bit format)... but it's a pain
      in the butt to code around.  Of course, if the user is already at N81,
      none of this processing is nessessary.  The easy way out is to tell the
      user that he must be at N81 to work correctly.  Explain that to the
      average novice user... <grin!>


  2.  The VIDTEX terminal control set is an improper subset of the DEC VT52
      control set.  However, unlike the ANSI/VT100 conflicts mentioned above
      there are no known conflicts between like commands.  VIDTEX does contain
      private special sequences for CIS-specific functions concerning printer
      and hardware control, capture buffer control, RLE high- and medium-res
      graphics, etc.  Most specifically, the <ESC>I Interrogation Sequence
      is considered part of the CIS private VIDTEX set (although I have seen
      it listed as the "who are you" command in the SCO Xenix termcap set
      for some versions of the VT52.)  A document file that _used_ to be
      available on CIS gave complete specs for the VIDTEX command set.  I
      have a copy.  I'm afraid to open it for fear the pages will fall apart.
      It's *OLD*!  If you need specific VIDTEX command information, let me
      know and I can provide what you need (the document is circa 40 pages.)

  3.  Wide mode is an example of the VIDTEX commands.  <ESC>m  enters wide
      (32/40 column) mode and  <ESC>l  returns to 64/80 column mode.  Easy
      to do on a CGA card, but...  The functionality was originally designed
      around the TRS-80 Model I, which could change between the two modes
      without clearing the screen - and the VIDTEX document specifies that
      the functionality is done without inherently clearing the screen.
      I've never seen a CGA card that could switch between 40- and 80-col
      modes without clearing the screen automatically.  I've also never
      seen a use for it on CIS.  Oh, well...

  4.  The screen size (SSyx) parameter should always be provided, although
      if it is not your default settings for screen size in GO TERMINAL will
      be used automatically.  The values for "y" and "x" are the ASCII
      equivalent of the screen coordinate plus 31 (considering a "home"
      coordinate of 1,1.)  "Y" and "x" are, of course, the lines and columns
      count respectively.  For example, a 24-line by 80-col screen would
      be calculated as follows:

              Coord.    Add     NewValue      ASCII equiv.     HEX Value
      Lines     24       31        55             "7"              37
      Columns   80       31       111             "o"              6F

      and would be sent as:

      ...,SS7o,...


  5.  Protocols - the AP (Application Protocol) designation refers to the
      remote supporting the "Applications Layer" of the B protocol, an as-
      yet-unused (with the possible exception of HMI, the code for which I
      have no access to) extension of the B+ proto.  It is mentioned in the
      B+ spec document and then dropped, and the original QB source as pro-
      vided by CIS contained code to acknowledge an AP packet whereas the
      later B+ code had the acknowledgement curiously missing.  I smell
      something comming...

      While the PB and DT codes are listed in a manner that indicates either
      may be inserted in the response string independently, in practice CIS
      balks if the DT code is used without being preceeded in the string
      by the PB code.  Sa la vie.

      The PZ code is accepted by the host.  I wish the protocol was!  Connie
      has tested it and says it works fine.  It had to be run on a special
      test host, however; I would suspect there would be some serious problems
      implementing ZMODEM CRC-32 on a 36-bit architecture, 64K core system
      with a large user load.

  6.  The <check_value> computation is straightforward.  Some documents and
      example-source files on CIS show the 3-4 digit ASCII representation
      being mapped down to the low-order 2 digits, or being ANDed with
      0xFF rather than 0xFFFF - these are incorrect, and CIS will choke
      if either of these incorrect methods are used.  I guess a response
      string limited to 80 characters could exceed 0xFFFF... my code
      doesn't even try to AND the check value as it's never even close
      to that high a number.



As examples, I'm including the response strings my programs send:

OZBEXT
   #OZ1,9.2h,AC,CA,CC,SS7o,PB,DT,+<chkval>

OZRLE
   #OZ2,5.1g,AC,CA,CC,SS7o,GH,GM,GF,+<chkval>

OZQB
   #OZ3,9.1b,AC,CA,CC,SS7o,HC,GH,GM,GF,PB,DT,+<chkval>



Here is an example GIF image startup in PICS: (r = remote  h = host)

(h)"<ESC>[>0g"
(r switches to N81, sends response string, stays at N81)
(h)"<ESC>[>1g"
(r enters GIF processing mode)
(h)...image data...
(r processes image, returns to E71 and normal processing)


Here is an example GIF image startup in COLMAPS: (r = remote  h = host)

(h)"<ESC>[>0g"
(r switches to N81, sends response string, stays at N81)
(h)"<ESC>[2J<ESC>[37;44m..."
(r switches back to E71 and returns to normal processing)
(h sends info and prompts)
(r responds)
(h)"<ESC>[>1g"
(r switches back to N81, enters GIF processing mode)
(h)...image data...
(r processes image, returns to E71 and normal processing)



     ----------------------------------------------------------

I hope this info proves helpful.

Steve Sneed
Ozarks West Software
71520,77
BBS  805-925-0378 3/12/24

<eof>