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 

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 
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 
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 

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 

     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 

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 

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.


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 
     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 
     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 

     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) 

     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 
     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 
     The value of this parameter is in timer tick units. It should 
     never be set to 0. (The channel will not transmit in that 
     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 

     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.

     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 
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 

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.


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"
     - 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 

     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