home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
researchmachines
/
rmlinfdoc.txt
< prev
next >
Wrap
Text File
|
1985-07-10
|
33KB
|
720 lines
File RMKINFO.DOC
---------------- 10th July 1985.
C. J. Kennington
Research Machines Ltd.
Mill Street
OXFORD.
Research Machines Kermit for 480Z & Nimbus
------------------------------------------
0. Overview & Status
-----------------
RM Kermit is an implementation of the KERMIT file-transfer protocol
to run on RML 480Z and Nimbus computers. Kermit is a file-transfer
system developed by the University of Columbia, New York, and implemented
on a large number of both mainframe and micro computers. It is fully
described in the Kermit User Guide, a shortened version of which is included
on this disk. In the rest of this note, familiarity with the contents of
the User Guide is assumed. Complete copies of both the User Guide and the
Kermit Protocol Manual are available from:
Center for Computing Activities
Columbia University
New York, N.Y. 10027
at $10 (ten dollars) apiece.
RM Kermit used as a starting-point the (1983) C-coded version for Unix
systems, published as an appendix to the Protocol Manual The status of
this is not "Public Domain", but "Copyright - freely available". The status
of RM Kermit is "Copyright Research Machines and U. of Columbia", but
free permission is given to copy the binary version and use it.
The high-level program (i.e. that part which is coded in C) is also made
freely available, as requested by Columbia; the low-level routines which
drive keyboard, screen and the various communications devices on 480Z and
Nimbus are RML copyright, and may not be further distributed without
permission from RML.
RM Kermit Capabilities At A Glance:
Local operation: Yes
Remote operation: No
User Interface: Menu-driven
Transfers text files: Yes (with CR/LF validation)
Transfers binary files: Yes (image or prefixed)
Wildcard send: Yes
ESC interruptions: Many
Filename collision avoidance: Yes (with filename validation)
Can time out: Yes (fuzzy)
8th-bit prefixing: Yes
Repeat count prefixing: Yes
Alternate block checks: No
Terminal emulation: Yes (dumb)
Communication settings: Most (depends on hardware)
Transmit BREAK: Yes (fixed length)
IBM communication: No
Transaction logging: No
Session logging: No
Raw upload/download: No
Act as server: No
Talk to server: Yes
Advanced commands for servers: Some
Local file management: Yes
Handle file attributes: No
Command/init files: No
Printer control: No
1. Hardware Supported and Program Versions.
----------------------------------------
RM Nimbus Kermit supports communications via the Nimbus Auxiliary Port
in RS422 mode and via the Piconet Serial Interface Module. Support for the
RS232C Data Communications Controller will be added in due course. For a note
on connection of the RS422 port to RS232 equipment, see Appendix I.
RM 480Z Kermit has been designed specifically to make use of the
facilities of the Mark II 480Z (ROS level 2.?), but will run with a few minor
imperfections on earlier 480Zs. This version supports three quite different
configurations. On a Link-480Z connected to a Chain Network, without local
disks, the communications-line is plugged into the SIO4 port on the back of the
480Z. Where local disk units (MD1, MD2 or MQ2) are connected to the 480Z, they
also use this port; the communications-line is therefore plugged into the SIO4
port on the back of the Disk Unit ("IDC") and all communications are relayed
by the processor in the IDC. If both an IDC and Chain Network are in use,
the port on the IDC is once again used but the program logic is different.
Quite different code is used for driving the communications in these three
configurations, and it is essential that the correct version of 480Z Kermit
is loaded.
RM Kermit will not run on 380Z, but a version for 380Z (double-density
disk models only) is available from the Computer Centre at Oxford University.
480Z Kermit consists of a single .COM module, whose name is:
dKMITnn.COM
Nimbus Kermit consists of a single .EXE module whose name is:
cKMITnn.EXE
where:
d = I for IDC (local disks),
N for Network disks,
X for IDC and Network;
c = A for communications by Aux port (RS422),
P for communications via Piconet SIM (RS232C),
D for communications via DCC (RS232C);
nn = decimal part of version-number.
The versions current at the time this is written are IKMIT22.COM
(480Z for local disks), NKMIT22.COM (480Z for network disks),
XKMIT13.COM (480Z for both local and network disks), AKMIT22.EXE
(Nimbus via Aux port) and PKMIT22.EXE (Nimbus via Piconet SIM).
480Z silicon disk and shared disk systems have not been tested.
The header information displayed when Kermit is loaded identifies
the type of communications for which the version is designed. You are
advised to check this before proceding!
2. Program Loading and Startup.
----------------------------
Kermit (the appropriate version) is loaded from disk in the normal
way by a command such as:
d:NKMIT21
When loaded, Kermit puts up a 4-line heading which identifies it
and provides a display for monitoring file-transfer activity. This
display, with a divider underneath it, occupies the top 5 lines of the
screen, leaving 19 lines for general use (20 on Nimbus). An additional
header is placed on lines 20-22 whenever command-mode is entered.
Included in this second header is a field "Communications:", which will be set
to either "Direct" or "via Disks" (480Z), "by Aux" or "via Piconet"
(Nimbus), showing which version has been loaded.
In the Nimbus Piconet version only it is necessary to select
the piconet address of the SIM before the program proper starts;
this can be in the range 1-8 (the recommended addresses for SIMs).
The prompt for this address must be answered by a single digit or
ENTER (which defaults to 1); invalid entries are rejected. If the
SIM is not found at this address, the program immediately aborts.
3. Line-Speed and Performance.
---------------------------
480Z Kermit handles line-speeds from 75 to 19200baud; the same speed
must be used both for transmission and receipt of data. Nimbus Kermit will
handle line-speeds from 110 to 9600baud via tha Aux port or 110 to 2400baud
via the Piconet SIM.
In the both versions, during CONNECT, data can be displayed on the screen
at up to 1000 char/sec depending on the proportion of line-feed characters in
the data. Kermit's data-reception is buffered, so that if the screen falls
behind the data received, it will catch up without data loss when the
incoming flow pauses. (The size of the receive buffer is 600 bytes; data
will be lost if the screen falls this much behind.) Flow-control by
CTS/RTS, XON/OFF or ENQ/ACK is available on the 480Z version, but is not
needed for running Kermit transfers.
Net transfer rates during SEND and RECEIVE operations are about
60% of the basic line-speed, e.g. some 600 char/sec at 9600baud. This
performance will degrade if any debugging or listing display is switched
on, or if the responses from the mainframe are less than prompt, or if
there are delays in the connecting network. Contention for the Winchester
disks on an RML Network can also reduce throughput.
4. Facilities Supplied and User Interface.
---------------------------------------
RM Kermit is still under development. The current (July 1985)
version supplies the normal communications facilities of a local-only Kermit,
but with an easy-to-use menu-driven interface for commands etc.
Control of RM Kermit is by menus. The main menu is displayed when the
program is loaded, and again whenever any major activity is completed. The
various facilites of the program are listed, and a cursor shows which one is
currently selected. The up and down arrow-keys and F1 & F3 keys are used to
move this cursor; help information is automatically displayed at the bottom
of the screen. When the desired facility has been selected, RETURN / ENTER
causes it to be started.
When any activity is complete, Kermit returns automatically to the
main menu (in some cases after a RETURN has been entered, so that information
on the screen is not wiped before it can be read). At almost any time a
precipitate return to the main menu may be caused by hitting the F4 key
and entering K in response to the special prompt displayed; entering
Q rather than K will cancel the Kermit program (after seeking confirmation).
If a file-transfer is in progress, there may be a pause while this is
suitably aborted in cooperation with the mainframe Kermit.
In modes other than CONNECT, the ESC key has the same effect as F4.
On Nimbus the F9 & F8 keys generate the character-pairs ESC K and ESC Q
respectively, producing the same effects with a single keystroke. In many
modes, an isolated RETURN will also cause reversion to the main menu.
Entering CTRL-C when any input is expected (e.g. file-names) usually
causes cancellation of the immediate activity; it also cancels displays
in disk-maintenance mode.
When in CONNECT mode, all the normal keys (including ESC) and
key-combinations will transmit the expected characters to the mainframe.
In addition, F2 will send a TAB character. The 4 arrow-keys (up, down,
right & left) send control-characters 0bH, 0aH (LF), 18H and 08H respectively.
DELT/DEL sends 7fH. Most other special keys will send either nothing or
character-combinations which are meaningless.
Data transfers may be carried out in two ways. If the remote
mainframe is running a simple Kermit, this must be set to either
send or receive files and the corresponding Receive or Send mode
then used on RM Kermit. If the mainframe Kermit has server capability,
it may be set going in this mode and RM Kermit then used in Commands to
Server mode.
The way in which data is handled depends on whether 7-bit, 8-bit-image
or 8th-bit-prefixed mode has been selected (see below). In 7-bit mode,
all data is sent and received as 7-bit ASCII characters. In image mode
it is sent and received as 8-bit characters, but there is no guarantee
that the communications path may not have altered the 8th-bit values
en route; if this happens the received file is likely to be garbage, and
no warning message will be given. In 8th-bit-prefixed, special encoding
is used to transfer the setting of the 8th bit of every character, but this
slows down the transfer. In general, for text files, 7-bit mode should be used.
To transfer binary files image mode may be used with direct local
communications; prefixed may be used over any communications path provided
the mainframe Kermit will cooperate. Both these last modes may require special
instructions to be given to the mainframe Kermit.
In 7-bit mode only, special processing is used on all incoming CR
and LF characters, particularly CR/LF and LF/CR pairs to ensure that all
lines of text are terminated by a CR/LF pair before being stored in the
received file. This is to avoid problems which have been encountered with
mainframe systems which use different conventions to terminate lines in
text files. 8-bit transfers are assumed to be binary and are stored as
received.
RM Kermit implements repeat-count-prefixing, which enables strings
of repeated characters to be compressed in transmission. This facility
is always active but has to be accepted by the mainframe Kermit before
it can be made use of. Its use it may speed up transfers considerably,
but does not affect the data received in any other way.
On Nimbus, care must be taken with the "CAPS LOCK" and "NUM LOCK"
keys. These are "push-push" switches, i.e. they alter the overall state
of the keyboard without remaining locked down or giving any other indication.
The effect of the CAPS-LOCK should be obvious. NUM-LOCK however nullifies all
the special sequences which have been installed in the arrow and F keys; this
is very inhibiting and non-obvious. If the arrow and F keys are not responding
as expected, try hitting NUM-LOCK!
5. Help Systems & Confirmation.
----------------------------
The main & server-command menus display help-texts automatically.
When in the parameter-setting menu, help may be obtained at any time by
entering "?" (for specific help) or "H" (for general help). Help on the
possible F4 break-in actions may be obtained at (almost) any time
by the sequence "F4 ?". The amount of text displayed is limited since no
separate help-file on disk is currently implemented.
There are a number of points in controlling RM Kermit where action
can be requested which is potentially catastrophic (e.g aborting a file
transfer). In these cases the query "Yes?" will be displayed. If the
user's response is "Y", "y" or RETURN/ENTER, then the action will be taken;
any other character will prevent the action from being carried out.
6. CP/M & MSDOS File-Handling.
---------------------------
All names of files in CP/M and MSDOS are inherently upper-case.
When using RM Kermit they may be entered in either upper or lower case
and will be translated to upper before action is taken; similarly
if lower-case characters occur in filenames received from the mainframe
Kermit (which they should not), they will be converted to upper-case.
Filenames under CP/M or MSDOS are of the format:
d:name.ext
where:
d = disk-letter,
name = filename, 1-8 alphanumerics,
ext = extension, 0-3 alphanumerics.
If the extension is null, the dot preceding it is omitted. All
alphabetics are upper-case. If the disk-letter is omitted, so is the
colon following it; in this case the default-disk is used. The name
and extension normally consist only of letters, digits and "$"; although
a few other special symbols are not illegal, their use is discouraged.
(Under MSDOS only, the names of files whose extension is null may need
to have the dot appended before MSDOS utilities will recognize them
correctly.)
Two wildcard characters are accepted whenever a filename is specified
by the user. A "?" in any position matches any valid character (including
blank/null); a "*" is the equivalent of entering enough ?s to complete
either the filename or the extension. (In general neither CP/M nor MSDOS
diagnose names which are too long; surplus characters are merely ignored.
The Kermit name-input routines, however, do check for such overlong names.)
In MSDOS the file may also have a "path"; in CP/M it may have a
"user-number". RM Kermit takes no account of these; the user must make sure
that path or user number are correctly set before the transfers commence
(which can be done in Disk-mode.) Filenames are sent without disk-letters.
Received filenames are processed to remove any disk-letter and ensure
that they conform to this format. Invalid characters are dropped (including
special characters other then "$"). A single dot is accepted as terminating
the filename and starting the extension. For names (not including a dot)
of between 9 and 11 characters, the first 8 characters are taken as the name
and the next 1-3 as the extension. Surplus characters (beyond 11) are dropped.
If processing results in a null name, the file is stored as "INVALID.NAM".
The same processing is applied to overriding names specified for files
received, except that the disk-letter is respected. If a disk-letter only
(which must be entered with its normal trailing colon) is
given as an override, the incoming file is stored under its own name
but on this disk. If overriding names are entered but more files are sent by
the remote Kermit than names entered, then the extra files will be stored
under their received names.
Filename collision avoidance (which ensures that an incoming file
cannot overwrite an existing one of the same name without warning) is
under control of the user. By default, collisions are avoided, by
modification of the incoming file's extension, in cases where a file of
the same name already exists on the specified disk. Alternatively, the
File-Collision parameter may be changed to overwrite existing files,
to reject incoming files which would cause collisions, or to query
the user as to whether overwriting is permissible. The modification is
to replace the second character of the extension by "$" and/or to increment
its last character by 1. If the extension is null, this algorithm is
applied to the last letters of the name; if extension or name is less than
3 characters long, it is extended to 3 characters before the modification
is applied. If the name after modification
still matches an existing file, the same algorithm is reapplied to the
modified name. If after successive modifications the result is an invalid
name (e.g. if the extension was originally .A$9 and the last character has
been incremented to ":"), the transfer is refused.
8. Parameter Setting and Displaying.
---------------------------------
All adjustable parameters may be inspected and set in Parameter Mode
(entered from the main menu); the current and all possible values may be
displayed. A few of these parameters may also be set by low-level breakins.
In the list below, if a key-letter is given, this is what is to be entered
after ESC/F4 when breaking-in.
Baud-Rate Sets line-speed to one of the permitted values.
E Local Echo If ON, all characters sent in Connect Mode are
also displayed on the screen.
File Collision See above for the meanings of the settings of
this parameter.
Flow-Control Selects either no flow-control, or CTS-RTS,
of XON/OFF (Tandem), or ENQ/ACK, or combinations
of these.
8th-bit If off, 7-bit characters are handled; if "image"
8-bit characters are sent and received
(image-mode); if "prefixed", then 8th-bit prefixing
will be attempted.
L List/Debug Normally set to display a dot for each good block
sent/received (and a letter for each bad block).
May be set OFF, in which case nothing is displayed
to show progress of the transfer; or may be set to
value 2 to list all data as it is sent/received
(this is not advised on binary files).
Extra settings (values 3-6) permit increasing
amounts of debug information to be displayed
on the screen as blocks are sent and received.
N Slow-Network If ON, steps are taken to discard any duplicate
packets which may have been buffered by the
network. This is OFF by default, since if it is
used with high-speed (back-to-back) connections
it may cause the loss of blocks of genuine data.
Packet-Size Defines an overriding maximum to the size of packet
which will be sent or received.
Page-Wait Normally OFF. If set to a number of lines, then during
Connect or Disk-Utility Modes the screen will wait for
an input character (which is then discarded) after
every so many lines. (The legend "[more]" is
displayed at the end of the last line, if there
is room, while waiting for this input.)
Parity Defines the parity to be generated as 0 = none,
1 = odd, 2 = even, 3 = mark; applies to data sent.
(There is no provision to check the parity of
data received; this is stripped to 7-bit unless
image or 8th-prefixed has been set.) For image
transfers, parity must be 0.
In modes where loss of information is not likely to be caused, ESC-P
also calls up the main parameter-setting menu so that any parameters may be
changed. Exit from this menu (by RETURN) picks up whatever activity was
interrupted.
On any particular version of RM Kermit, there will be parameters or values
on the menu which are not implemented. An attempt to use such a parameter
results in a warning message and no other action.
9. Other Break-Ins.
----------------
At most times either the F4 or ESC keys cause a break-in which
interrupts the current activity; CTRL-C usually does the same; all
other normal keys have no effect. In Connect mode, only the F4 key
causes a break-in, since ESC is a valid character to be sent to the
mainframe (see above).
As well as the parameters that may be set by break-in after F4,
various other actions can be requested. For any given mode, only some
of them are valid; "F4 ?" at any time will show which are and are not
currently possible.
The possible actions, and the break-in key-letters which call
them, are:
? - Get Help
* A - Abort current transfer
B - Send line-break, approx 1 second
C - Clear screen
F - Call "Front-Panel" (480Z only)
H - Get general Help
K - Return to Kermit Main Menu
P - Call Parameter-Setting Menu
* Q - Quit - Cancel Kermit program
R - Enter Receive Mode
S - Enter Send Mode
T - Simulate Timeout / Send NAK
Z - Toggle DTR up/down
* these actions request confirmation before proceding.
Note particularly that after F4 causes a breakin, all other activities
(except interrupt-driven data reception) are inhibited. If this is done
during a file transfer, timeouts will occur; if the period of inactivity is
prolonged, the transfer will probably abort.
On Nimbus, the extra F-keys are programmed so that they send the
following sequences:
F5 ` back-quote character
F6 ESC S enter Send mode
F7 ESC R enter Receive mode
F8 ESC Q Quit (after confirmation)
F9 ESC K back to main menu
F10 ESC B send Break
In addition, PG UP and PG DN are programmed to correspond with F1 & F3
(up and down page), and END is also programmed as down page. The pound-
sign (shift-3), which sends a non-ASCII character when in its standard
state, is reprogrammed to send back-quote (`).
10. Terminal Emulation.
-------------------
In Connect Mode, RM Kermit does not attempt to emulate any particular
screen-editing terminal. Its responses to control-characters are a small
subset of those defined for the 480Z in the RML Firmware Reference Manual.
It is always in "scroll" mode, i.e. any attempt
to write text beyond the right or bottom margin causes wrap-around and/or
screen scrolling. The cursor reponds to CR by inserting a newline (but
special code traps CR/LF and LF/CR pairs so that each produces only a
single newline). The cursor moves up, down, right or left in response to
the characters transmitted by the arrow-keys (see above).
It is assumed that if a substantial terminal session is required with
a mainframe, the RML VT100 Terminal Emulator Program will be used rather
than Kermit.
11. Disk Utility Mode.
------------------
This mode emulates (in a system-independent manner) the basic
file-control functions of CP/M or MSDOS. The commands available are:-
* CHAnge - Reset all disk drives;
DELete - Remove named files;
DIRectory - List file directory;
ERAse - synonym for DELete;
HELp - Print help-text;
* REName - Rename one file to another;
TYPe - List a file on the screen;
UPAth - Show user environment;
* USEr - Set user-number;
d: - Change default drive to "d";
? - synomym for HELp.
The starred functions differ between CP/M and MSDOS, and the action
is altered to resemble that of the OS being used.
Only the first 3 letters of each command need be entered.
Wildcards (? = any character, * = any string of characters) are
accepted, but since the code is emulating the OS they may not work in
quite the same way. Note that on a 480Z network system, wildcards take
a considerable time to interpret.
ERAse (DELete) lists all the files it proposes to delete and
requests confirmation before doing so. Only one filename (possibly with
wildcards) may be entered for a single ERAse.
12. Sending Commands to Server-Kermits.
-----------------------------------
If the mainframe Kermit is a "Server", it is capable of performing
a range of activities on command from the local (micro) Kermit. Commands
of this nature may be sent if the item "Commands to Server" is selected
on the RM Kermit Main Menu. Since there are very many different mainframe
Kermits, it may be necessary to consult the documentation or help-texts of
the one being used in order to find out which server commands are accepted
by it. If an unacceptable command is sent, most server Kermits will
return a sensible error-message.
The commands which may be sent are shown on a "Commands to Server"
menu. This provides the following options:-
a. Kermit Commands.
----------------
In this case a line of text entered by the user will be sent
to the mainframe Kermit for execution as though it had been
typed in (to the mainframe Kermit) when in Connect mode.
b. Mainframe Commands.
-------------------
In this case a line of text entered by the user will be submitted
by the mainframe Kermit to the mainframe Operating Sytem for action
as though it were a normal command to the OS.
c. Get Files.
----------
In this case the line of text entered by the user should be a
list of files for the mainframe Kermit to send to the micro. The
user should remember that wildcards (* & ?) will be sent to the
mainframe "as is"; whether this is useful depends on the mainframe
Kermit.
d. Send Files.
-----------
This is the equivalent of "Send Files" from the Main Menu,
and the list of files should be entered in the same way.
e. Cancel Mainframe Kermit.
------------------------
This sends an error-message to the mainframe Kermit, which
should force it to abort and leave you connected to the
mainframe Operating System (in Connect mode).
f. Logout from Mainframe.
----------------------
This sends a "BYE" message to the mainframe Kermit, which
should cause it to disconnect you and terminate your mainframe
session.
g. Back to Main Menu.
------------------
No message is sent to the mainframe; RM Kermit returns
to the Main Menu to permit further actions.
h. Terminate Kermit Run.
---------------------
No message is sent to the mainframe; RM Kermit is cancelled
and control returns to CP/M or MSDOS.
The last 4 actions do not require any additional input from the user.
The user input to "Send Files" consists of filenames as known to the micro.
For the first three actions, the text input by the user will be sent to
the mainframe Kermit without any editing at all; its format must therefore
be exactly what the mainframe requires, and this will differ according to
the make of mainframe and type of server-Kermit running on it. For details,
reference should be made to the documentation of the mainframe Kermit.
(Note particularly that text will be sent in upper or lower case as entered;
this is highly significant to certain mainframes.)
The first two actions may be expected to generate a smaller or greater
amount of data in reply. This is displayed on the 480Z/Nimbus screen. It
is not buffered on disk, so if it is held up by paging, the mainframe Kermit is
likely to time out. A risk of cancellation of the whole mainframe session
exists if this output is held up for more than a minute or so.
(These facilities have not been subject to the same amount of testing
as the Connect-Send-Receive facilities; reports of bugs, omissions or problems
would be very welcome.)
13. Adaptation of RM Kermit.
-------------------------
RM Kermit has been produced to run on the 480Z and Nimbus micros,
under CP/M and MSDOS respectively. The C-code which controls the overall
program behaviour is however not believed to depend on specific hardware and
could be adapted to run on other systems. RML will permit the code to
be used for this purpose (since it is a fundamental principle of the
Kermit world that all Kermit code is to be made freely available),
but are not in any way liable for anything which may result from such actions.
The way in which this code interfaces to the low-level routines which
drive the keyboard, the screen and the communications port in a way is
defined in file RMKIFACE.DOC. Techniques and tools for handling the code
and modules of RM Kermit are described in file RMKGEN.DOC.
Chris Kennington.
Appendix
--------
Connection of Nimbus RS422 Port to RS232 Equipment.
---------------------------------------------------
RS232 & RS422 use different signalling systems and voltage levels, but
in practice most RS232 equipment will connect to and function with the
Nimbus RS422 port. An interworking standard is in fact defined in an
annexe to the ISO specifications. RS232 voltages are higher than RS422
ones, so there is little likelihood of damage to an RS232 equipment by
connecting it to Nimbus' RS422 port (provided that the connections are
not inadvertently miswired). Nimbus itself is considered to be relatively
robust.
The RS422 port on Nimbus uses a small 6-wire "Bell" connector and a
standard flat 6-wire cable. This is fully described in RML documentation,
but not all cables/connectors comply with the description. The rest of
this appendix assumes that the cable is inserted into the connector so
that the blue wire is on the left, with the other 5 in the order
yellow, green, red, black, white. This is as viewed with the plastic
spring on your side of the connector, and the cable coming out of the
bottom of the connector. If the cable has been inserted the other way
round (and it is a 50/50 chance), then the following colour-interchanges
should be (mentally) performed:
blue <===> white
yellow <===> black
green <===> red
The Nimbus RS422 provides only two signals, each using two wires. In
principle these may be used to provide a simplex data channel (either sent or
received) with a flow-control handshake in the opposite direction, or a
duplex data-channel with no handshake or control signals. It is this
limited full-duplex mode which is used by Kermit.
Different pinning-out of the wires in the connecting cable is required
for the three different modes of use. The duplex connection is provided if
a standard Nimbus bell plug and 6-wire cable is connected to an RS232 25-pin
plug with the following colour-coding:
Green - Tx, RS232 pin 2
Red - Rx, RS232 pin 3
Yellow )
White ) - Both paralleled to RS232 pin 7
This is for a cable to a DCE (modem), i.e. no crossover of the data wires.
If connection to another DTE (e.g. another micro) is required, the Tx & Rx
wires should be crossed over.
The other two wires carry the power-supply used in Piconet mode and
should be left disconnected.
Appendix II
-----------
Current Restrictions.
---------------------
There are a number of restrictions and infelicities in
the current version of the program. Among those known are:-
a. The 480Z IDC-version cannot hold DTR high during a disk transfer;
the connecting cable must be wired to hold DTR high at the
modem/mainframe/switch if this is needed. The Nimbus Aux
version handles no control-lines at all. The control-line
handling of the Nimbus Piconet version is not yet validated.
b. There are no facilities for half-duplex or split-speed working.
c. A few disk I/O errors (e.g. file locked) are not trapped effectively.
On 480Z, either NDOS error-messages are displayed,
or the Kermit program fails and returns control to CP/M.
Under MSDOS, normal disk-error messages appear (in a different
colour), but normal Kermit activity resumes if and when the
problem has been solved. An extreme case of undiagnosed
disk problems is that if the receiving disk is removed from
a 480Z in mid-transfer, no error is sent to the mainframe.
d. If a Mark I 480Z is in use, block-graphics characters are displayed
in place of inverse-video ones at a few points.
e. RML Kermit cannot act as a server.
f. Flow-control is not yet implemented on Nimbus Kermit.
g. The Piconet SIM generates errors when receiving data at 4800baud
or above; it can transmit data (and receive the ACK/NAK packets)
at up to 9600baud.
h. Nimbus Kermit uses code for communications which is not yet
integrated with the MSDOS drivers. After running Kermit it
is necessary to reload MSDOS by CTRL-ALT-DEL; this should be
done before attempting to load another program, otherwise it
will be necessary to switch off the Nimbus power-supply to
regain control.
********************************************************
