File contents

                      Update-Information for Version 2.4h
                      ===================================

The version 2.4H can be regarded as a "small update" in order that the
new command "TNC" may be used. This new command allows programmes such
as TOP, WinGT and SP to be started without problem when using the PTC-II.
A few other extras and the obligatory "bug-fixes" are certainly also a
reason for loading this "interim-update" into the PTC-II.

New Commands
============

TNC   (cmd-Menu, Default: 0, Range: 0-2)
---
The "hostmode" terminal programmes are virtually all written for pure PR-
controllers (TNC's) using "the firmware" (TF) as firmware. Some of the
specialties of the simple command interpreter originally suggested by
WA8DED are unfortunately no longer valid for modern multi-mode controllers
such as the PTC-II. TF for example uses a simple star as a prompt, which
for systems with many sub-menus, is naturally not very helpful. The PTC-II
for example, gives "cmd:" as the prompt for the main menu. On switching to
other sub-menus, the prompt is changed accordingly in order that users are
quickly aware of "where" they are.
Some "hostmode" programmes test very carefully for the presence of a
controller with TF - especially to see if the controller is presently in
"Hostmode" or in "terminal-mode". Here, a star prompt as echo to an ESC-
character is expected. Under normal conditions, the PTC cannot deliver this
star prompt, as it gives its own (e.g. "cmd:"). Programmes such as TOP or SP
thus never switch to "hostmode" and simply break off the initialisation
phase. Without special tricks it was not possible to employ such programmes
together with the PTC-II.
It is here that the "TNC" command may be used.
The command allows, within limits, a closer emulation of the WA8DED command
interpreter. The PTC with an activated TNC-command, behaves similarly to a
normal TNC, which naturally leads to a certain incompatibility to its own
standard. The necessary adjustments are, luckily however, not too great.

The individual commands:

TNC 0: Normal PTC terminal-mode, prompt as usual.

TNC 1: The CTRL-A character is always echoed back from the PTC to the
       computer, as long as the PTC is not in hostmode.
       Seeing as a CTRL-A character is normally never sent to the PTC in
       terminal-mode, this is no real limitation or incompatibility.
       (Binary data must be transmitted in Hostmode!).
       The CTRL-A echo is however essential in order that WinGT for example,
       may start correctly. When it is missing, the programm pauses for a
       while on start-up. As soon as one uses the command TNC 1, this wait
       is suppressed, and the program starts at once.
       When TOP or SP are never to be used, then the PTC can be left in
       the TNC=1 condition.

TNC 2: The PTC behaves as in TNC=1 mode, however in addition, the prompt
       is changed to "* ", in other words, the PTC replies to an ESC
       character with a star instead of its normal prompt. This is required
       for TOP and SP to accept the PTC as a controller.
       Unfortunately however, this simple star naturally collides with the
       requirements of diverse terminal programmes which expect the "cmd:"
       prompt. For operation with PlusTerm and similar programmes, the TNC-
       parameter should never be set higher than 1.

TIP: In order to operate with all programmes as comfortably as possible
(without having to set the TNC-parameter by hand), it is recommended that
the PTC initialisation file of NON-HOSTMODE programmes (e.g. STARTUP.PTC in
PlusTerm) should contain the command "TNC 0". The PTC hereby behaves as a
"normal PTC" irrespective of what has occurred previously. It delivers
the correct prompts expected by NON-HOSTMODE programmes.
(Previous programmes may have set the TNC-command to other another value,
which is retained by the PTC even after switching off).
The de-initialisation file (e.g. SHUTDOWN.PTC in PlusTerm) should contain
the command "TNC 2" so that on ending the NON-HOSTMODE program, the PTC is
returned to a "TNC-similar" condition. This should allow virtually any
hostmode program to start correctly.


PDTimer (cmd-Menu, Default: 12, Range: 2-30)
-------
Sets the Pactor-duplex BREAK-IN time. This is the time in seconds, that the
PTC must remain in an IRS condition (data receiver) after which it may
(when data is available) automatically initiate a BREAK-IN, to "take the
keys" and send the data. This time was previously set by the firmware to
12 seconds and could not be changed.
The PDTimer value is only relevant when Pactor-duplex is in use, i.e. when
PDuplex is set to 1


PACLen (pac-Menu, Default: 255, Range: 1-255)
------
Sets the maximum PR transmit packet length, when the PTC is in Terminal-
mode. (In Hostmode is the PAClen value not used, as the Hostmode programm
itself dictates the packet length).
Packet lengths smaller than 255 are only useful when the link to the
partner station causes a lot of errors.
The PTC in  Terminal-mode sends a packet immediately it receives a
<Carriage-Return> (which the usual "sendpack-character").


RESptime (response time delay) (pac-Menu, Default: 500, Range: 0-30000)
--------
Sets the value for the AX.25 timer-2 in milliseconds.


@T2 and @T3 (Hostmode, Default: 500 and 300000, range: 0-30000 and 0-3000000)
---     ---
Sets the value for the AX.25 timers 2 and 3.


Other improvements and changes.
===============================

Automatic recognition and support of "foreign" modems (e.g. DF9IC)
------------------------------------------------------------------

As from firmware version 2.4h, the PTC-II supports "foreign" modems. It is
now possible to connect modems for satellite operation or special
modulation systems to the PTC-II. The connectors normally used for
connecting the SCS modems serve as "Modemdisconnect".

Connector location within the PTC-II:


    �������������������
    �                                   �
    �                                   �
    �1�                                �
    � �                                �
  F � �                                �
  r � �                                �
  o �                                   �
  n �                                   �
  t �                                   �
    �                                   �
    �1�                                �
    � �                                �
    � �                                �
    � �                                �
    �                                   �
    �������������������



The connections of pins 1 to 20 conform exactly to the recommendation for
high speed modems by DF9IC from the ADACOM-magazine nr 2. The pins 21 to
26 are an extension especially used for the PTC-II.


Pin connections for the modem connector:

  +5V  1 # *  2 GND
  +5V  3 * *  4 GND
 /RES  5 * *  6 GND
 /DCD  7 * *  8 GND
 /CTS  9 * * 10 GND
 /PTT 11 * * 12 GND
  TxD 13 * * 14 GND
  RxD 15 * * 16 GND
  TxC 17 * * 18 GND
  RxC 19 * * 20 GND
   -- 21 * * 22 --
 CFG1 23 * * 24 CFG2
  CLK 25 * * 26 GND

The modem signals and their function:

 Pin   Signal    Function
-----------------------------
  1   +5 Volt    Power supply to modem from the PTC-II
  3   +5 Volt    Power supply to modem from the PTC-II
  5   /Reset     PTC-II reset line
  7   /DCD       Carrier recognition (from modem to PTC-II)
  9   /CTS       Transmitter is keyed (from modem to PTC-II)
 11   /PTT       Key transmitter (from PTC-II to modem)
 13   TxD        Transmitter data (from PTC-II to modem), NRZI coded!
 15   RxD        Received data (from modem to PTC-II), NRZI coded!
 17   TxC        Transmitter clock (from modem to PTC-II)
 19   RxC        Receiver clock (from modem to PTC-II)

The signals with a / before them are active low.

The even numbered pins from 2 to 20 are connected to ground. This enables
good screening to be obtained, even against crosstalk within the cable.

The modem can be supplied with power via the two 5 volt pins. The current
drawn should not exceed 150 mA.

The transmit and receive data (TxD / RxD) are processed by the PTC-II as
an NRZI coded signal. The NRZ-NRZI converter contained in many modems is
not required. In the original DF9IC modem, the NRZ-NRZI converter is
programmed in the GALs. Here, the GAL-FSKR and GAL-FSKT must be replaced
with the appropriate NRZI-GAL.

The pins 21 to 26 are PTC-II specific extensions, and must remain unused
when an external modem is connected!

The connection of the external modem is easiest using flat-band cable and
the appropriate connector using the well known crimp fittings. For a
modem a 26 pin in-line header socket plus another 20 pin in-line header
socket and a 20 way flat-band-cable is required. The in-line header sockets
are crimped to the cable according to the following plan:


      26-pin                       20-pin
 in-line header                in-line-header
   to PTC-II                     To Modem


        #*----------------------------#*
        **                            **
        **                            **
        **        20-way              **
        **     Flat-band cable        **
        **                            **
        **                            **
        **                            **
        **                            **
        **----------------------------**
        **
        **
        **

The hash (#) marks the in-line-header pin 1.

The length of the flat-band-cable is not critical. If however, the cable is
extended outside the PTC-II case, then the radiation of interference from
it may be quite high.


Error-trapping when a try is made to set up two fully identical links.
----------------------------------------------------------------------

Until now, the PTC would allow two fully identical links to be made. This
is illegal according to the AX.25 protocol.
In practice, trying to set up two links using the same "Mycall" on two PR-
channels to the same digi (e.g. DL6MAA, without SSID to DB0OFB), invariably
led to a breakdown due to collapse of the AX.25 protocol.
The PTC now traps such a situation with the error message "STATION ALREADY
CONNECTED" when a link with the same source and destination call as an
existing link is tried.

Some Hostmode programmes on recognising this error message, automatically set
an SSID in the "Mycall" and carry out a new connect attempt.


Improved memory management in the STBY-condition
------------------------------------------------

Buffer overflow in STBY-operation, when a terminal is not connected is now
hopefully a thing of the past. (Even when XOFF-condition or TERM=0).
Data that flows into an active PR-BBS-Channel (commands, text input, etc.),
are NO LONGER output to the terminal, and are also not under any condition
buffered unnecessarily.
PR and PT monitors are temporarily switched off if there are less than 400
buffers of 32 Bytes free. There should now be enough buffer memory
available, even in the most unfavourable circumstances, for trouble free
operation of the PTC-box.


Hostmode switch-on message improved
-----------------------------------

The modems found and the Baud-rate is now also displayed.


Improved commands
-----------------

* the %F command (FSK-filter) in Hostmode, is now port independent of port.

* the %B command (Baudrate) in Hostmode now works as in Terminal-mode, i.e.
  also independent of the port and optionally with a separate RX and TX
  Baudrate for "split-baud" operation.

Bug-fixes
=========

* XUser-command corrected: self written files can always be read, even via
  remote-control, independent of if the reading of non-own files is allowed
  or not.

* CTRL-A to CTRL-F are no longer sent out in PT-II monitor-mode.
  Terminal-programmes which process the control characters CTRL-A to CTRL-F
  no longer "go mad" when binary data is received from the PT-monitor.

* Processing of RNR-Frames (RX) corrected: (On Upload to the Digi with a
  fast baud-rate, the digi may send RNR signalling that its acceptance
  capability is temporarily exceeded. If in addition then transmission
  errors occur on the link, then protocol problems may occur).

Have fun with the new update!


Peter, DL6MAA, representing the entire PACTOR-team.