home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.barnyard.co.uk
/
2015.02.ftp.barnyard.co.uk.tar
/
ftp.barnyard.co.uk
/
cpm
/
walnut-creek-CDROM
/
CPM
/
CIS
/
PROTCISA.TXT
< prev
next >
Wrap
Text File
|
2000-06-30
|
15KB
|
365 lines
PROTOCOL NOTES: CIS A PROTOCOL
by Bob Richardson, Carl Raff, and Scott Lowe
Copyright (C) 1982
Performance Business Machines
A Division of MicroPro International Corporation
101 Lucas Valley Road
San Rafael, California 94903
Revised by Ken Brassler, 4/2/83
Note: this material was not prepared for or by CIS and they have no
responsibility for the accuracy or completeness of the contents. We
gratefully acknowlege their cooperation and the super job they are doing,
and simply wish to help document the file transfer protocol.
INTRODUCTION
The information presented here is intended to provide an outline of the
written specifications for the CIS A Protocol. It is designed to be used by
programmers who may need to debug or write programs to interface with
Compuserve Information Services (CIS) terminal programs.
The PBM 1000 supports a communication subsystem based on the CIS protocol.
One reason is that the CIS protocol is a step in the direction of software
standardization and higher compatibility among different computer systems.
The CIS protocol supports flexible file transfer and is practical for
in-house use on a direct-connect medium speed network. PBM tests show that
the protocol runs effectively at 19.2 KB and can transfer data at a rate
of up to 50 KB.
In transferring files from one system to another, one CP/M- based system
(with a copy of any of the CIS executives that supports the A protocol)
acts as a terminal. The other system, referred to as the "host," treats the
"terminal" system both as a console and as the source or target of the file
transfer protocol.
The following is a brief description of the CIS A Protocol used by CIS.
Also included is a list of Executives compatible with it, and two new
files which allow anyone with a CP/M remote system to support this
protocol between CP/M systems. Note: CP/M is a registered trademark of
Digital Research.
The Executives
1. MNEXEC [Old Executive]
An older version of the Executive, MNEXEC supports ASCII transfer only .
This executive is primarily useful for those who wish to buy programs from
Softex, as its ESC I response is the only one that the Softex system
currently recognizes as a file-xfer executive (see ESC I response). This
program does not really support the A protocol, but rather a subset.
2. CSEXEC [The Compuserve Executive]
CSEXEC was the first "vanilla" version with binary support. It is a good
executive to start with for those wishing to heavily modify the source
because it suffers less from "rampant equate-itis" than BUFEXEC (i.e, it
accomplishes tasks in a more general fashion without presenting too many
options to the user). The current version seems to be modified for the
Apple computer.
3. BUFEXEC [Buffered CSEXEC]
BUFEXEC adds memory buffered hard copy to CSEXEC, as well as many
customization equates. The Osborne version is called "BUFEXO.ASM," and is
identical to BUFEXEC except for modifications for the Osborne I.
4. IOBEXEC [IO/Byte Executive] This executive is identical to BUFEXEC,
except that it uses IOBYTE dispatch to access the serial port. If your
system is interrupt driven, you must use IOBEXEC or modify one of the
other executives. In addition, IOBEXEC allows use of cursor positioning.
Note: There are a number of customized protocols floating around; most
are based on BUFEXEC and represent adaptation for particular hardware
such as the Osborne, Kaypro, Apple, etc.
PROTOCOLS
Characteristics of the physical protocol: asynchronous; 8-bit; 8 bits to
the byte; 1 stop bit; no parity.
The protocol mode is turned "on" by an SI instruction (shift in) from the
host and the terminal then functions in protocol mode until an SO (shift
out) instruction is received.
The ESC "I" Response: Each terminal responds to an ESC "I" with an ID
string (see diagrams below).
The ESC "A" Sequence: This initiates a file transfer.
The ESC "L" Sequence: This starts a load sequence.
Notes: The "." (period) is used to ACK a message (acknowledge and accept).
The "/" (slash) is used to NAK a message (negative acknowledge; request
retransmission). If Ack or Nak is not sent to CIS in a given period of time,
CIS responds by re-sending ETX a total of 4 times, then aborts. A CTRL U
sent to the host will abort the file transfer.
A list of fields enclosed in [ ] marks indicate that 1 of the list will be
transmitted, depending on the conditions at the time.
ESC "I" Sequence
Host Terminal
"SI" (Protocol on)
------------------------------------>
ESC I (Who are you?)
------------------------------------>
ID String (see below)
<-----------------------------------
"SO" (Protocol off)
[---------------------------------->]
error; feature lock; end of function
Continue in Protocol
[----------------------------------->]
Action: The terminal sends its ID string to the host. The host checks the
features list, etc.
ID String: A full sample of the ESC I response for the IOBEXEC protocol
(assigned by CIS) is as follows:
<#> <CPM> <MYSYSTEM>, CC, HC, PA, PL, <CR>
The first character is the protocol ID, followed by the OS name and the
computer name (optional). The string of four pairs of characters are a
series of features to be assigned if the system supports them:
CC, HC, PA, and PL <CR>
CC = full cursor control
HC = hard copy
PA = "A" protocol
PL = "L" protocol
See the comments in any version of the executive for a more detailed
discussion of these fields.
MNEXEC is an older version of the executive, and so the ID string is
slightly different in format than the one for the CIS Executive. A sample
response follows:
<01>,<BF>,<SYSTEM2>,<&CPM>,<D> <CR>
The first character is the page address of the lowest available page of
memory in the terminal, followed by the page address of the highest
available page in memory, the computer ID, OS name, and "D" for disk
drives.
ESC "L" Sequence
Host Terminal
SI
------------------------------------>
ESC L
------------------------------------>
<count-1 byte> <low addr> <hi addr> <data> <CHKSUM>
------------------------------------>
"." = ACK (Received; OK)
[<----------------------------------]
"/" = NAK (Error; request retransmission)
[<----------------------------------]
ESC L
------------------------------------>
Next record
------------------------------------>
"." = ACK (Received; OK)
[<-----------------------------------
"/" = NAK (Error; request retransmission)
[<-----------------------------------
SO (Done)
[----------------------------------->
Action: The terminal loads <data> into memory starting at address <low>
<hi> for <count> bytes.
ESC "A" Sequence: File Transfer
Host Terminal
SI (Protocol on)
------------------------------------>
ESC A (Start file transfer)
------------------------------------>
<1-byte SOH> <1-byte rec #> <U/D> <A/B> <file spec> <CR> <LF> <ETX> <CHKSUM>
------------------------------------>
"." ACK (Received; OK)
[<----------------------------------]
"/" NAK (Retransmit)
[<----------------------------------]
Action: The terminal sets up to read or write the file given in <file
spec>.
ESC "A" Sequence: File Transfer
Download Subsequence
Host Terminal
<SOH> <R/N> <Text> <ETX> <CHKSUM>
------------------------------------>
"." ACK (Accepted record)
[<----------------------------------]
"/" NAK (Rejected; retransmit)
[<----------------------------------]
<SOH> <R/N> <Text> <ETX> <CHKSUM>
------------------------------------>
"." ACK (Accepted record)
[<----------------------------------]
"/" NAK (Rejected; retransmit)
[<----------------------------------]
<SOH> <R/N> <Text> <EOT> <ETX> <CHKSUM>
------------------------------------>
"." or "/"
<------------------------------------
SO (Shift out; protocol off)
[---------------------------------->]
ESC A (Next file)
[---------------------------------->]
^
|
Note: This is currently unused by CIS.
ESC "A" Sequence: File Transfer
Upload Subsequence
Host Terminal
"." ACK
------------------------------------>
<SOH> <R/N> <Text> <ETX> <CHKSUM>
<------------------------------------
"." ACK (Record accepted)
[---------------------------------->]
"/" NAK (Record rejected; retransmit)
[---------------------------------->]
<SOH> <R/N> <Text> <ETX> <CHKSUM>
<------------------------------------
"." ACK (Record accepted)
[---------------------------------->]
"/" NAK (Record rejected; retransmit)
[---------------------------------->]
<SOH> <R/N> <Text> <EOT> <ETX> <CHKSUM>
<------------------------------------
"." ACK (Record accepted)
[---------------------------------->]
"/" NAK (Record rejected; retransmit)
[---------------------------------->]
SO (Shift out; exit protocol)
[---------------------------------->]
ESC A (Next file)
[---------------------------------->]
Field Definitions
SI - Shift in (CTRL O). When received in the communications loop, the
terminal software should jump to protocol mode. SI can be expected to
include a parity bit, so ANI 7FH is necessary. Once in protocol, parity is
disabled.
SOH - Start of header (CTRL A). Each record begins with SOH.
R/N - An Ascii character, starting with 1, and incremented by one ASCII
number after each previous record is acknowledged (ACK). After 0, the R/N
wraps back to 1.
U/D - An Ascii character, the U/D instruction determines the direction of
transfer. U = Upload, transfer to host; D = Download, transfer from host.
A/B - An Ascii character, signifying an ascii or binary file. Careful
consideration indicates that this is not necessary, since 8 data bits are
received in either case.
FILE SPEC - Standard CP/M file specification, with optional drive
reference. This is a literal echo of what the terminal sends to CIS when a
filename is requested. The terminal software should select the requested
disk, Create the file for a download sequence, or Open the file for an
upload sequence.
CR - Carraige return, (CNTRL M). Signifies end of file spec in A Protocol
header.
LF - Linefeed, (CNTRL J). Inclusion of this character by the host MAY be
determined by your personal DEFAULT settings. Although not mentioned in
previous protocol definitions, it is transmitted by CIS in my case. (KCB)
After CR is received, looping until ETX will cover either posibility.
ETX - End of text, (CNTRL C). ETX ends each packet (a group or string of
related characters), and is followed by CHKSUM.
EOT - End of transmission, (CNTRL D). When EOT is encountered in the text
field of a record, it ends the current file. CP/M end of file, 1AH (^Z) is
not transmitted by the host, and should be inserted by the terminal
software whenever EOT is received. A purist may elect to insert it only at
the end of an Ascii file, but it does no harm at the end of a binary file
also. For an upload sequence, EOT should be sent to the host in place of
the 1AH Ascii end of file, or after the last sector in a binary file.
Character Masking
Data characters in the text field that would normally conflict with control
characters (those less than 20h), are sent 'masked' by adding 40h to their
value and preceeded by a DLE (unmasked).
Control characters (those meant for control) are always sent unmasked.
CHKSUM - Check sum on record calculated on all characters sent after (and
not including) start of header (SOH) and until (and not including) ETX.
Except that, DLE is not included in the checksum, and the following
'masked' character is checksumed in it's unmasked state. EOT, however, is
included in the checksum. How other control characters in the text field
are checksummed is unknown, however, these appear to be the only two used.
1. CHKSUM <--- (CHKSUM * 2) mod 256
2. CHKSUM <--- CHKSUM + character
3. CHKSUM <--- CHKSUM + carry
If the check sum is less than hex '20', it is increased by hex '40' and
sent masked (preceded by a DLE character).
APPENDIX
Since the heart of the CIS Protocol is the checksum routines, the following
code is included to amplify the verbal description. There are better ways
to do everything, so feel free to hack away. This particular sequence is
for a download.
;
;
;a side effect of docks is that it returns with b=a. since etx is not
;included in the checksum, the calling program can recognize that etx
;has been received when a is not equal to b.
;
CHARCKS: CALL CHARIN ;get a char from modem
CPI ETX ;end of packet?
JZ CHARETX ;yes, don't include in checksum
CPI DLE ;is next char masked?
JZ UNMASK ;dle not included in checksum
CPI EOT ;end of xmission?
JZ SETEOT ;yes, set flag, and replace with 1ah
JMP DOCKS ;compute checksum and ret to caller
;
UNMASK: CALL CHARIN ;get masked char
SUI 40H ;unmask before checksum
JMP DOCKS ;compute checksum and ret to caller
;
SETEOT: STA EOTFLG ;make flag non zero
CALL DOCKS ;include in checksum
MVI A,1AH ;replace with eof
MOV B,A ;set a = b for etx test
RET ;to caller
;
CHARETX: MVI B,0FFH ;tell packet etx received
RET ;to caller
;
DOCKS: MOV B,A ;save original char
LDA CHKSUM ;get last check sum
RLC ;do math
ADD B
ACI 0
STA CHKSUM ;replace new checksum
MOV A,B ;replace orig char
RET
;
; end of prtcol.cis