The SCC/ESCC driver for the Atari ST and PC Clones
By R.E. Janssen, PE1CHL.
[updated to reflect status of SCC driver in NET.PE1CHL.930430]
A driver has been written to support a number of Z8530/Z85C30 SCC
chips connected to an Atari ST computer. The driver is
configurable for different hardware configurations, and an
example schematic supporting up to 7 SCC's (14 channels) is
available.
The driver now also runs on PC Clones, although the interrupt
handling capabilities of this type of computer often limit the
maximum speed and number of channels to a lower value than on the
Atari. (depending on the speed and BIOS of your PC, of course)
On the PC, most of the available SCC cards are supported,
including PA0HZP's OptoPcScc, the DRSI PC*PA, PacComm PC-100,
PC-110, PC120, Baycom USCC and others.
The latest version also supports Zilog's Z85130 and Z85230 ESCC
chips, which feature a larger FIFO and can therefore be used at
higher datarates (at a given interrupt latency).
The SCC/ESCC driver can support any mix of SCC and ESCC chips,
provided that the CTRL and DATA ports of the chips are arranged
in some regular pattern. Each SCC or ESCC channel can be
independently programmed to support:
- An asynchronous SLIP line
- An asynchronous interface to a KISS TNC
- Direct AX.25 (HDLC)
The software has been written in such a way that a port to
another environment where Z8530/Z85C30 SCCs and/or Z85130/Z85230
ESCCs are available should be relatively straightforward.
Addresses of the chips are completely configurable, as long as
the chips are addressed using some regular pattern.
Initialization and attachment of the channels
To use the driver, 2 steps must be performed:
1. Global initialization of the driver
2. Attachment of each channel, specifying mode and options
The global initialization is needed to reset all SCCs and to
install a common interrupt handler. Also, the hardware addresses
of the chips are defined in this step. In the second step, each
channel is set up for the intended use.
1. Initialization
Initialization is performed using the "attach scc init" command,
using the following syntax:
attach scc <number of chips> init <base address>
<spacing between chips> <offset to channel A ctrl>
<offset to channel B ctrl> <offset from ctrl to data>
<address of INTACK latch>|0 <interrupt number>
p<PCLK frequency>|r<RTxC frequency>
[<special interface type> <interface parameter>
[<timing channel>]]
To initialize a board with 2 SCCs using my schematic for the
Atari ST, the following command would be used:
attach scc 2 init fffd00 8 3 7 -2 fffd3f 3 p4915200
This specifies interrupt number 3, a normally unused interrupt in
520ST and 1040ST machines. In the newer Mega-ST this interrupt
is used for the Blitter. In this case, it is possible to use the
"ring indicator" input of the RS232 interface as an interrupt
source. It has interrupt number 14.
The INTACK latch (write, then read to get the interrupt vector)
is located at 0xfffd3f. It is also possible to specify 0 for
this address. In that case, INTACK is not used and the driver
finds the interrupting chip by polling each RR3A register. This
allows a more simple hardware design.
The crystal clock is specified as 4915200 Hz (4.9152 MHz). Other
frequencies can be used, and this parameter should be adjusted
accordingly.
The clock used for baudrate generation is connected to the SCC's
PCLK pin. It would also be possible to supply a baudrate clock to
the RTxCA/RTxCB pins, and a clock of a different frequency to
PCLK (like the processor clock). In this case, it is the RTxC
clock frequency that really matters for the "attach scc init"
command. This clocking method is supported by prefixing the
clock frequency with an "r" instead of a "p": r4915200.
On a PC, a similar command can be used to initialize the driver.
The PA0HZP OptoPcScc card would use the following command:
attach scc 2 init 150 4 2 0 1 168 3 p4915200
This command differs only from the "Atari ST" example, in that it
different different addresses and arrangement of the ports. In a
PC, the I/O ports always occupy addresses between 0 and 3ff(hex).
The interrupt number 3 is defined in this command. Of course it
must match the interrupt number that you have selected on the
board using a jumper or dip-switch. Also, the interrupt must not
be in use by a different type of board in the system, e.g. a COM
board or a disk controller.
When using an AT-type machine (with two 8259 interrupt control-
lers), and using the "interrupt 2" line on the BUS, specify
interrupt number 9 in the "attach scc init" command instead of
number 2. This better reflects the actual configuration: the
interrupt line labeled "interrupt 2" on the BUS is actually
connected to interrupt number 9 on the second 8259. The BIOS
will attempt the redirection of interrupt vector #9 to #2, but it
does not completely do the job. The result will be that the
driver hangs after some random amount of interrupts.
In the PC version, the "special interface type" and "interface
parameter" fields in the "attach scc init" command can be used to
specify some special type of interface board to be used. Adding
more types of interface boards requires modification to the
driver software.
Currently, the following special types are supported on the PC:
- type 01: EAGLE
- type 02: PC-100, PC-110, PC-120
- type 04: PRIMUS
- type 08: DRSI PC*Packet
The PC-100 and the PRIMUS types accept an interface parameter,
that is used to control the on-board MODEM. It must be specified
as a hexadecimal value, to be sent to the output port on the
board.
Possible initialisation commands are:
EAGLE: attach scc 1 init 2e8 8 2 0 1 0 3 p3686400 01
PC-100: attach scc 1 init 2e8 16 6 4 1 0 3 p4915200 02 82
PRIMUS: attach scc 1 init 2e8 4 2 0 1 0 3 r2457600 04 02
DRSI: attach scc 1 init 300 16 2 0 1 0 3 p4915200 08
When the DRSI card type is selected, the Z8536 CIO on the DRSI
card is initialized to provide two divide-by-32 counters (see
below), and a timer tick generator that will generate a tick
every 10 ms, to be used as a timing reference for use by AX.25-
type channels.
For other card types on a PC, the system timer will be used to
provide these timer ticks, and it provides a 55 ms resolution.
It turns out that multitaskers like Desqview treat the 55ms
system timer interrupt in such a way that a running task does not
receive all timer ticks. This results in random timing errors
when a program is running in another window. (you can observe
this as unusually long flag leaders and trailers when listening
to your own transmissions)
Also, the 55ms timing interval may be somewhat long when higher
speeds are used (e.g. 9600 bps), and a finer control of the
TXDELAY timing is desired.
When a spare SCC channel is available, it can be set up as a 10ms
timer, to be used instead of the system timer: add the option
"t<n>" at the end of the "attach scc init" command, where <n> is
the channel number to be used for timing. When no "special
interface type" and "interface parameter" options ar used, one or
two zeroes must be inserted between the <frequency> parameter and
the option, to hold their place. Example for use with the PA0HZP
OptoPcScc card:
attach scc 2 init 150 4 2 0 1 168 3 p4915200 0 0 t3
This defines channel number 3 (the last channel on the board) as
a timer tick generator.
The timer tick generator defined this way generates 10ms ticks.
It is also possible to specify the interrupt number to be used
for SCC timer ticks as an optional parameter to the "attach scc
init" command. The default is 08, i.e. the hardware timer
interrupt. Possible other candidates are 1C (software timer
interrupt) and 70 (PC-AT Real Time Clock interrupt). The driver
assumes that the timing hardware has been initialized before, and
a handler is in place that resets the pending interrupt. It only
chains its handler on the specified vector. The tickrate should
be somewhere between 18 and 200 ticks per second.
Example (for the PA0HZP OptoPcScc card):
attach scc 2 init 150 4 2 0 1 168 3 p4915200 0 0 1c
Note that the 1C vector is not suitable when multi-tasking DOS
replacements like DesqView and DoubleDos are in use. Vector 70
can only be used in an AT, and needs a TSR routine to setup and
handle the RTC timer interrupt.
2. Attach commands
When the SCC driver has been initialized, you can attach the
channels. This is done using one of 3 forms of the "attach scc"
or "attach escc" command:
attach scc <channel> slip <mtu> <baudrate>
attach scc <channel> kiss <mtu> <baudrate> <callsign>
attach scc <channel> ax25 <mtu> <baudrate> <callsign>
attach escc <channel> slip <mtu> <baudrate>
attach escc <channel> kiss <mtu> <baudrate> <callsign>
attach escc <channel> ax25 <mtu> <baudrate> <callsign>
These will be refferred to as "slip", "kiss" and "ax25" mode.
The <channel> parameter specifies which half of which SCC will be
programmed, as follows:
channel 0: "A" side of first SCC
channel 1: "B" side of first SCC
channel 2: "A" side of second SCC
channel 3: "B" side of second SCC
and so on. The channel number ranges from 0 to (2 * nchips) - 1,
where nchips is the number of chips specified in the
"attach scc init" command.
SLIP mode
This can be used for a link to another machine, when the channel
has an RS232 interface. Example:
attach scc 0 slip sl0 256 9600
This attaches the "A" side of the first SCC as interface "sl0",
with an MTU of 256 and an initial baudrate of 9600. The baudrate
can be changed later by:
param sl0 <baudrate>
Entering just "param sl0" will display the current baudrate.
KISS mode
KISS mode can be used to talk to a KISS TNC. It can also be used
on an asynchronous link to another computer running NET.
The difference with SLIP is that the interface will be AX.25
type, and can therefore be used for AX.25 connections. A
callsign must be given as a parameter, this will be used for IP
and NET/ROM purposes on the interface. Example:
attach scc 2 kiss 430 256 4800 pe1chl-7
In the example the "A" side of the second SCC will be attached as
interface "430" using an MTU of 256, a baudrate of 4800 and the
callsign PE1CHL-7.
The command "param 430 <paramnum> <decimal value>" can be used to
set the parameters of the KISS TNC. It is not possible to
display the current settings.
AX.25 mode
This is probably the most interesting mode to use with this
interface. It allows AX.25 communication without a TNC. Only a
MODEM is needed. Example:
attach scc 2 ax25 430 256 1200 pe1chl-7
The parameters have the same meaning as in KISS mode. In fact,
the AX.25 mode is emulating an extended KISS TNC, so the same
commands can be used to set the parameters of the interface (see
below).
To be able to run fullduplex using an SCC in AX.25 mode, an
external divider must be available, that divides the baudrate
generator clock available on the TRxC pin by 32, and puts the
resulting signal on the RTxC pin of the same channel of the SCC.
Such a divider is not necessary for normal halfduplex CSMA packet
radio operation, as the driver will re-program the SCC baudrate
generator at each transmit/receive transition. Interrupt overhead
is slightly reduced if you still install it. If you have
installed the divider, prefix the baudrate with a letter "d", as
in:
attach scc 2 ax25 430 256 d1200 pe1chl-7
Note that when using the RTxC input as the baudrate generator
clock source, you will have to feed the exact rate of the
transmitter to TRxC to be able to use fullduplex. For this
reason, it is better to use PCLK as the clocksource whenever
possible.
The DRSI PC*Packet adapter uses the Z8536 CIO on the board as a
divider, so you can (and should) specify the "d" option for that
board.
Another option is to use external clocking, supplied by the
MODEM. This is specified using the keyword "ext" in the baudrate
field, as in:
attach scc 2 ax25 430 256 ext pe1chl-7
The receive clock will be taken from the RTxC pin, the transmit
clock from the TRxC pin. make sure the phase relationship
between the clock and the data is correct!
When "external clocking" is selected, NRZ encoding instead of the
default NRZI can be selected by specifying "ext/nrz" in the
baudrate field. NRZ encoding is used with the DF9IC 9600 baud
modem, which provides NRZ-NRZI conversion.
The SCC driver also allows complete specification of the clocking
mode, so that all modems requiring- or providing external clocks
can be configured. The value to be written to WR11 of the Z8530
can be specified as a hexadecimal value after the existing
baudrate specification, separated by a colon (e.g. d1200:66).
Refer to a Z8530 technical manual for more information about the
value to be written to WR11.
Attaching an ESCC (Z85130 or Z85230)
Besides the original Z8530/Z85C30 SCC chip, the SCC driver also
supports the newer Z85130/Z85230 ESCC chips. The main advantage
of the ESCC is the larger TX FIFO (4 bytes instead of 1) and RX
FIFO (8 bytes instead of 3), allowing a longer interrupt latency
without causing overrun/underrun errors. Therefore, the chip can
be used at the high edge of the speed range supportable using
interrupt-driven I/O (19200 and possibly 38400 baud). It also
solves some bugs in the original SCC, and has introduced a few of
its own... Unfortunately it is quite expensive, so for now
default choice is likely to remain the SCC.
The presence of an ESCC is indicated to the driver by the use of
"attach escc" instead of "attach scc" to attach the channels.
The driver will then automatically use the extra features of the
ESCC. The "attach scc init" attach line can indicate either "scc" or
"escc", with no difference in operation.
The total set of chips driven by the SCC driver can be a mix of
Z8530/Z85C30 (SCC) and Z85130/Z85230 (ESCC).
The ESCC can run fullduplex without the external divide-by-32
counter, because an extra internal clock source selection has
been added to provide its function. You may or may not install
the external divider.
Parameters
The setting of parameters of the emulated KISS TNC is done in the
same way as in the KISS mode of the SCC driver:
param 430 <paramnum> <decimal value>
In AX.25 mode however, it is also possible to display the current
settings using "param 430". This will display a line like:
sp=d1200:66 grp=000 tx=y 1=36 2=50 3=30 4=3 5=0 6=0 7=50 8=7 9=3 10=30 11=0.
The "timer tick" unit mentioned in the descriptions for SCC
channel parameters 1,3,4,7 and 11 below depends on the computer
type and SCC driver initialization.
- On the Atari ST, each timer tick is 10ms.
- On the PC Clones, a timer tick is usually 55ms, but it can
be different when an alternative timing method is selected
in the "attach scc init" command (see above). The actual
value is printed during execution of the "attach scc init".
Consider that the exact time of each delay may be up to 1
timer tick time less than the specified time. It is therefore
unwise to specify a value less than 2 for a "timer tick"-relative
delay (except when the special-case value 0 is selected).
When you have defined your own values for SCC channel parameters
1,3,4,7 or 11: remember to re-calculate the values of these
parameters when you change the timing method.
The parameters have the following meaning:
1: The delay (in units of timer tick) after keying of the
transmitter, until the first byte is sent. "flags" are sent
during this period. This is usually called "TXDELAY" in a
TNC. When 0 is specified, the driver will wait until the
CTS signal is asserted, instead of waiting for a pre-
determined time. This assumes the presence of circuitry in
the MODEM and/or transmitter, that asserts CTS when the
transmitter is ready for data.
The default value of this parameter is 360ms.
2: This is the probability that the transmitter will be keyed
when the channel is found to be free ("persistence"). It is
a value from 0 to 255, and the probability is (value+1)/256.
Selecting a relatively low persistence decreases the chance
that multiple stations send at the same time, when the
channel becomes clear. The value should be somewhere in the
range 20-60, and should be lowered when the channel is used
more heavily.
The default value is 25 (10% persistence).
3: This is the time between sampling of the DCD state, to detect
a free channel. It is expressed in units of timer tick.
About 100-300 ms seems to be a good value.
This parameter should never be 0. The transmitter will not
key when 0 is used!
The default value is 160ms.
4: The time the transmitter will remain keyed after the last
byte of a packet has been transferred to the SCC. This
extra transmission time is necessary because the CRC and a
flag still have to leave the SCC before the transmitter is
shut down. The value depends on the baudrate selected. A
few character times should be sufficient, e.g. 30ms at 1200
baud.
The value of this parameter is in timer tick units, the
default is 30ms (or at least 2 clock ticks).
5: The full-duplex mode switch. This can be one of the folowing
values:
0: The interface will operate in CSMA mode (the normal
half-duplex packet radio operation).
1: Fullduplex mode, i.e. the transmitter will be keyed at
any time, without checking the received carrier (DCD).
It will be unkeyed when there are no packets to be
sent.
2: Like 1, but the transmitter will remain keyed, also
when there are no packets to be sent. Flags will be
sent in that case, until a timeout (parameter 10)
occurs.
The default value is 0, CSMA operation. The fullduplex
modes are only meaningful when a fullduplex modem and
transceiver is in use, e.g. when accessing a packet
satellite. Also, when using an SCC (Z8530 or Z85C30) and
the internal baudrate generator, and external divide-by-32
counter is required for fullduplex operation.
6: Control of the DTR output of the SCC. DTR will be set when
this value is nonzero, it will be reset when the value is 0.
After initialization DTR will be set by default. The DTR
output can be used as a general-purpose output, e.g. to
change between 2 transceiver frequencies or output power
levels.
The default value of this parameter is 1, DTR SET.
7: The initial waittime before any transmit attempt, after the
frame has been queued for transmit. This is the length of
the first slot in CSMA mode. In fullduplex modes it can be
set to 1 for maximum performance, or to a higher value to
give NET a chance to combine several packets in a single
transmission.
The value of this parameter is in timer tick units. It should
never be set to 0. (The channel will not transmit in that
case)
The default value is 500ms.
8: The maximal time the transmitter will be keyed to send
packets, in seconds. This can be useful on busy CSMA
channels, to avoid "getting a bad reputation" when you are
generating a lot of traffic.
After the specified time has elapsed, no new frame will be
started. Instead, the transmitter will be switched off for
a specified time (parameter 9), and then the selected
algorithm for keyup will be started again.
The value 0 will disable this feature, and allow infinite
transmission time.
The default value is 7 seconds.
9: This is the time the transmitter will be switched off when
the maximum transmission time (parameter 8) is exceeded.
This parameter is in seconds, and should never be 0.
The default value is 3 seconds.
10: In CSMA mode, this parameter specifies the maximum time the
transmitter will wait for the channel to become clear,
expressed in units of one second. When this time has
elapsed without an opportunity to transmit, the transmitter
will be keyed. This is a safeguard against situations where
the squelch refuses to close, or a weak carrier is present
on the frequency, to prevent an indefinite pileup of frames
to transmit (with a possible danger of memory overflow). Of
course, the value should be set sufficiently high to prevent
accidental keyups in periods of high channel load, e.g. 60
seconds.
In fullduplex 2 mode, this parameter specifies the maximum
idle time, in seconds. When no frames have been sent for
this time, the transmitter will be keyed down. A value of 0
will disable this feature, i.e. the transmitter will be
keyed indefinitely.
The default value of this parameter is 120 seconds.
11: The DCD hold time, in timer tick units. Whenever DCD falls,
the receiver remains enabled for <n> ticks. Setting this
parameter to a suitable value will eliminate the packet loss
caused by a flickering DCD, as can sometimes be observed
with the G3RUH 9600bps FSK modem. Setting parameter 11 to 0
will select the default operation, where the fall of DCD
will immediately eliminate the packet being received.
This DCD handling option does not affect the "channel busy"
detection that is performed in half-duplex mode (CSMA). The
P-persistent channel access algorithm takes the unsmoothed
DCD as input.
Other parameters
Using the "param" command, some other parameters of the SCC
driver can be controlled. These are detailed below:
param <iface> dcd n
DCD-changes are ignored, the receiver is permanently
enabled. In this mode, a packet is never discarded because
of DCD loss. However, when noise is present on RxD it will
cause a permanent interrupt load on the system.
This mode of operation can be useful in fullduplex systems,
when there is no reliable DCD circuit. Note that a good DCD
circuit is essential when operating halfduplex CSMA!
Normal operation restored by: param <iface> dcd y
param <iface> speed <speed>
Can be used to change the bitrate of a channel after it has
been attached. This command can only change the bitrate, it
cannot change between internal/external clocking, fullduplex
divider yes/no, etc.
param <iface> tx n
This will disable the transmitter of the selected channel.
Can be useful when a channel is receive-only, or to disable
a transmitter when receiving on a channel where you don't
want to transmit, e.g. a satellite downlink.
It can also be useful for remootely controlled stations, to
disable a transmitter when interference or other malfunction
has been observed.
Transmitter Groups
It is possible to build special radio equipment to use more than
one frequency on the same band, e.g. using several receivers and
only one transmitter that can be switched between frequencies.
Also, you can connect several radios that are active on the same
band. In these cases, it is not possible, or not a good idea, to
transmit on more than one frequency. The SCC driver provides a
method to lock transmitters on different interfaces, using the
"param <interface> group <x>" command. This will only work when
you are using CSMA mode (parameter #5 = 0).
The number <x> must be 0 if you want no group restrictions, and
can be computed as follows to create restricted groups:
<x> is the sum of some HEX numbers:
100 This transmitter will only be keyed when the carrier
detect of all other interfaces in the group is off.
200 This transmitter will only be keyed when all other
transmitters in the group are off.
400 This transmitter will be keyed when all other
transmitters in the group are either off, or are
sending flags (TXDELAY period).
0xx A byte that can be used to define different groups.
Interfaces are in the same group, when the logical AND
between their xx values is nonzero.
Examples:
When 2 interfaces use group=101, the transmitters will only
key when both channels are clear at the same time.
When 2 interfaces use group=201, their transmitters will
never be keyed at the same time.
When group=301, the transmitters will not be keyed at the
same time, and only if both channels are clear.
Maximal packet length
Input packets on the SCC driver and the SLIP and KISS protocols
on async ports are checked for a maximal length. Packets longer
than the MTU of an interface plus the header overhead (for AX.25)
are discarded.
This is necessary, because otherwise very long packets could be
received and stored into memory, causing unnecessary use of
buffers.
Make sure the value of MTU specified in the "attach" commands is
correct (i.e. 256 for normal AX.25 use), as there is no
indication for packets that are ignored because they are too
long.
SCCSTAT command
Once the SCC driver has been initialized, some statistic
information can be shown using the sccstat command. The output of
this command shows one line of information per attached channel.
Example:
net> sccstat
Ch Iface Sent Rcvd Error Space Overr Rxints Txints Exints Spints
0 144 88 152 200 0 0 10013 4488 905 235
1 430 6 70 0 0 0 1915 29 0 0
The info shown is:
- channel number of the attach command,
- name of the interface,
- number of frames queued for transmission,
- number of frames received correctly,
- number of receive errors (CRC, ABORT),
- number of times the receiver buffer pool was found empty,
- number of receiver overruns and transmitter underruns,
- number of receiver interrupts,
- number of transmitter interrupts,
- number of receiver special condition interrupts,
- number of external/status interrupts.
It is normal that a SLIP or KISS channel shows no errors, and no
special condition or external/status interrupts, while an AX25
channel has lots of these.
An overrun is abnormal for all operating modes. If lots of these
occur, the product of baudrate and number of interfaces is too
high for the processing power of your computer.
If "Space" errors occur, specify a higher number of buffers in
the "buffers" command. It is, however, normal if these errors
occur when you start a shell, or when you pause the output of any
command using CTRL-S. This is because the processing and
allocation of buffers stops in these cases, while receiver input
keeps coming in under interrupt control.
When you see only transmitted frames, the number of transmitter
interrupts is 1, and all other counters are 0, the SCC is not
generating interrupts to the computer. The single transmitter
interrupt is a "simulated" interrupt that should start the
transmission (but apparently doesn't).
When a channel number is specified in the "sccstat" command,
more detailed information for that channel is displayed:
net> sccstat 0
Ch Iface Sent Rcvd Error Space Overr Rxints Txints Exints Spints
0 144 88 152 200 0 0 10013 4488 905 235
CTRL=fffd03 DATA=fffd01 STATUS=7c
WR0=00 WR1=13 WR2=00 WR3=c9 WR4=20 WR5=e9 WR6=00 WR7=7e
WR8=00 WR9=09 WR10=a4 WR11=66 WR12=3e WR13=00 WR14=03 WR15=88
Timer: 0 DCD_tail: 0 RX_ovr: 0 TX_undr: 0 Too_long: 1
The extra information displayed is:
- the CTRL and DATA register addresses for the channel,
- the last STATUS value that was read from the SCC,
- the last values written to the sixteen Write registers,
- the current values of the "Timer" and "DCD tail"
downcounters,
- the number of Receive Overruns and Transmit Underruns,
- and the number of received frames that were too long.
The number shown under the "Overr" header is the sum of the
receiver overruns and transmitter underruns shown in the detail.
Most other information is only understandable when an SCC
technical manual is used for reference.
The command "sccstat b" shows the percentage of time that an
AX.25 interface was busy:
net> sccstat b
Ch Iface Time Active %DCD %RTS
0 144 002/08:43:01 17 5
1 430 002/08:43:01 43 2
This indicates, during the measurement period shown under the
"Time Active" header, how long the DCD (carrier detect) and RTS
(request to send) signals were active.
Note that some modems or modem/transceiver combinations will
assert the DCD line during the time RTS is activated, so it may
be that the percentage DCD also includes the percentage RTS.
The command "sccstat b c" can be used to clear the counters and
start a new measurement. The "Time Active" will be reset to zero
at that time.
The "sccstat" command also has a few other subcommands, mainly
for testing and aligning modems. They are:
sccstat c <chan#>
sends 30 seconds of zeroes (NRZI pattern 101010...) on
AX.25-type interfaces. This is intended for tune-up of
TCM3105 modems and for link tests.
sccstat f <chan#>
sends 30 seconds of 'flags' on AX.25-type interfaces. This
is useful when evaluating the performance of certain modems
(especially the HAPN 4800 baud modem) on a scope.
These testing/alignment commands work only when the channel is
clear (no DCD, no "transmit group" limitation). They can only
make a 30-second transmission. When 30 seconds isn't enough,
simply re-issue the command.
The 101010 sequence is used to align a TCM3105 modem. Make an
audio loopback connection, or send the sequence on a transmitter
while the modem to be aligned is connected to a receiver. The
output of the modem can then be aligned to provide a 50% duty
cycle signal, using a scope.
Baycom USCC card
The Baycom USCC card is somewhat exceptional. It has 2 SCC chips
driving 3 onboard modems, plus one spare channel to which an
external modem can be connected. One of the modems (the 9600bps
G3RUH-compatible modem) uses external clocking and has an exter-
nal NRZ-to-NRZI converter. Because of the peculiar arrangement
of chip addresses, only a single USCC card is supported by the
SCC driver.
Example configuration for the Baycom USCC, located at address 300
using IRQ7. The 'external modem' channel (#2) is used for 10ms
timing:
attach scc 2 init 300 6 4 1 0 0 7 p4915200 0 0 t2
attach scc 0 ax25 chan0 256 1200 $CALLSIGN-2
attach scc 1 ax25 chan1 256 1200 $CALLSIGN-7
attach scc 3 ax25 chan2 256 ext/nrz $CALLSIGN-10