Import ax25-tools 0.0.2 from tarballax25-tools-0.0.2

8 files changed, 896 insertions, 0 deletions

diff --git a/hdlcutil/Makefile.am b/hdlcutil/Makefile.am
index 32059d1..effca5e 100644
--- a/hdlcutil/Makefile.am
+++ b/hdlcutil/Makefile.am
@@ -5,6 +5,8 @@ sbin_PROGRAMS = setcrystal sethdlc smmixer smdiag
 
 man_MANS = sethdlc.8 smdiag.8 smmixer.8 baycom.9 hdlcdrv.9 soundmodem.9
 
+EXTRA_DIST = $(man_MANS)
+
 setcrystal_SOURCES = 	\
 	setcrystal.c
 
diff --git a/hdlcutil/Makefile.in b/hdlcutil/Makefile.in
index edf7170..a0d16f9 100644
--- a/hdlcutil/Makefile.in
+++ b/hdlcutil/Makefile.in
@@ -58,16 +58,22 @@ NORMAL_UNINSTALL = :
 PRE_UNINSTALL = :
 POST_UNINSTALL = :
 AWK = @AWK@
+AX25IO_LIB = @AX25IO_LIB@
+AX25_LIB = @AX25_LIB@
 CC = @CC@
 MAKEINFO = @MAKEINFO@
 NCURSES_LIB = @NCURSES_LIB@
 PACKAGE = @PACKAGE@
+UTIL_LIB = @UTIL_LIB@
 VERSION = @VERSION@
+Z_LIB = @Z_LIB@
 
 sbin_PROGRAMS = setcrystal sethdlc smmixer smdiag
 
 man_MANS = sethdlc.8 smdiag.8 smmixer.8 baycom.9 hdlcdrv.9 soundmodem.9
 
+EXTRA_DIST = $(man_MANS)
+
 setcrystal_SOURCES =  	setcrystal.c
 
 
diff --git a/hdlcutil/baycom.9 b/hdlcutil/baycom.9
new file mode 100644
index 0000000..5e91100
--- /dev/null
+++ b/hdlcutil/baycom.9
@@ -0,0 +1,62 @@
+.\" Copyright 1996 Thomas Sailer (sailer@ife.ee.ethz.ch)
+.\" May be distributed under the GNU General Public License
+.\" "
+.TH BAYCOM 9 "2 October 1996" "Linux 2.1.x" "Kernel Reference Guide"
+.SH NAME
+baycom \- amateur (AX.25) packet radio network driver for baycom modems
+.SH SYNOPSIS
+
+.nf
+.B #include <linux/baycom.h>
+.B #include <linux/hdlcdrv.h>
+.fi
+
+.SH DESCRIPTION
+The driver currently supports three different modems: ser12, par96 and
+par97.
+.SS ser12
+This is a very simple 1200 baud AFSK modem. The modem consists only
+of a modulator/demodulator chip, usually a TI TCM3105. The computer
+is responsible for regenerating the receiver bit clock. The modem 
+connects to a serial port, hence the name. Since the serial port is
+not used as an async serial port, the kernel driver for serial ports
+cannot be used, and this driver only supports standard serial 
+hardware (8250, 16450, 16550).
+.SS par96
+This is a modem for 9600 baud FSK compatible to the G3RUH standard.
+The modem does all the filtering and regenerates the receiver clock.
+Data is transferred from and to the PC via a shift register.
+The shift register is filled with 16 bits and an interrupt is
+signalled. The PC then empties the shift register in a burst. This
+modem connects to the parallel port, hence the name.
+.SS par97
+This is a redesign of the par96 modem by Henning Rech, DF9IC. The
+modem is protocol compatible to par96, but uses only three low
+power ICs and can therefore be fed from the parallel port and
+does not require an additional power supply.
+
+.SH "IOCTL CALLS"
+The \fBioctl\fP calls follow the implementation in the \fIhdlcdrv\fP.
+
+.TP
+.B BAYCOMCTL_GETMODEMTYPE
+returns the modem type (i.e. \fIser12\fP or \fIpar96\fP) and the 
+options in effect (currently only the source of the DCD signal)
+.TP
+.B BAYCOMCTL_SETMODEMTYPE
+sets the modem type and the options. Only superuser can do this.
+.TP
+.B BAYCOMCTL_GETDEBUG
+return some debugging values. Not always available.
+
+
+.SH "SEE ALSO"
+.BR baycom " (9), " soundmodem " (9),"
+linux/drivers/net/hdlcdrv.c,
+
+.SH AUTHOR
+baycom was written by Thomas Sailer, HB9JNX/AE4WA, (sailer@ife.ee.ethz.ch).
+
+
+
+
diff --git a/hdlcutil/hdlcdrv.9 b/hdlcutil/hdlcdrv.9
new file mode 100644
index 0000000..3a46948
--- /dev/null
+++ b/hdlcutil/hdlcdrv.9
@@ -0,0 +1,220 @@
+.\" Copyright 1996 Thomas Sailer (sailer@ife.ee.ethz.ch)
+.\" May be distributed under the GNU General Public License
+.\" "
+.TH HDLCDRV 9 "2 October 1996" "Linux 2.1.x" "Kernel Reference Guide"
+.SH NAME
+hdlcdrv \- HDLC amateur (AX.25) packet radio network driver
+.SH SYNOPSIS
+
+.B #include <linux/hdlcdrv.h>
+
+.B linux/drivers/net/hdlcdrv.c
+
+.BI "extern inline void hdlcdrv_putbits(struct hdlcdrv_state * " s ", unsigned int " bits ");"
+
+.BI "extern inline unsigned int hdlcdrv_getbits(struct hdlcdrv_state * " s ");"
+
+.BI "extern inline void hdlcdrv_channelbit(struct hdlcdrv_state * " s ", unsigned int " bit ");"
+
+.BI "extern inline void hdlcdrv_setdcd(struct hdlcdrv_state * " s " , int " dcd ");"
+
+.BI "extern inline int hdlcdrv_ptt(struct hdlcdrv_state * " s ");"
+
+.BI "void hdlcdrv_receiver(struct device *, struct hdlcdrv_state *);"
+
+.BI "void hdlcdrv_transmitter(struct device *, struct hdlcdrv_state *);"
+
+.BI "void hdlcdrv_arbitrate(struct device *, struct hdlcdrv_state *);"
+
+.BI "int hdlcdrv_register_hdlcdrv(struct device * " dev ", struct hdlcdrv_ops * " ops ", unsigned int " privsize ", char * " ifname ", unsigned int " baseaddr " , unsigned int " irq ", unsigned int " dma ");
+
+.BI "int hdlcdrv_unregister_hdlcdrv(struct device * " dev ");"
+
+.SH DESCRIPTION
+This driver should ease the implementation of simple AX.25 packet radio
+modems where the software is responsible for the HDLC encoding and decoding.
+Examples of such modems include the \fIbaycom\fP family and the 
+\fIsoundcard\fP modems. 
+
+This driver provides a standard Linux network driver interface.
+It can even be compiled if Kernel AX.25 is not enabled in the Linux
+configuration. This allows this driver to be used even for userland
+AX.25 stacks such as \fIWampes\fP or \fITNOS\fP, with the help of
+the \fInet2kiss\fP utility.
+
+This driver does not access any hardware; it is the responsibility of
+an additional hardware driver such as \fIbaycom\fP or \fIsoundmodem\fP
+to access the hardware and derive the bitstream to feed into this
+driver.
+
+The hardware driver should store its state in a structure of the
+following form:
+
+.nf
+struct hwdrv_state {
+	struct hdlc_state \fIhdrv\fP;
+
+	... the drivers private state
+};
+.fi
+
+A pointer to this structure will be stored in \fIdev->priv\fP.
+
+\fBhdlcdrv_register_hdlcdrv\fP registers a hardware driver to the
+hdlc driver. \fIdev\fP points to storage for the \fIdevice\fP structure,
+which must be provided by the hardware driver, but gets initialized by
+this function call. \fIops\fP provides information about the hardware driver
+and its calls. \fIprivsize\fP should be \fIsizeof(struct\ hwdrv_state)\fP.
+\fIifname\fP specifies the name the interface should get. \fIbaseaddr\fP,
+\fIirq\fP and \fIdma\fP are simply stored in the \fIdevice\fP structure.
+After this function succeeds, the interface is registered with the kernel.
+It is not running, however, this must be done with
+\fBifconfig\ \fP\fIifname\fP\fB\ up\fP.
+
+\fBhdlcdrv_unregister_hdlcdrv\fP shuts the interface down and unregisters
+it with the kernel.
+
+\fBhdlcdrv_putbits\fP delivers 16 received bits for processing to the HDLC
+driver. This routine merely stores them in a buffer and does not process them.
+It is thus fast and can be called with interrupts off. The least significant
+bit should be the first one received.
+
+\fBhdlcdrv_getbits\fP requests 16 bits from the driver for transmission.
+The least significant bit should be transmitted first. This routine takes
+them from a buffer and is therefore fast. It can be called with interrupts
+off.
+
+\fBhdlcdrv_channelbit\fP puts a single bit into a buffer, which can be
+displayed with \fBsethdlc\ \-s\fP. It is intended for driver debugging
+purposes.
+
+\fBhdlcdrv_setdcd\fP informs the HDLC driver about the channel state
+(i.e. if the hardware driver detected a data carrier). This information
+is used in the channel access algorithm, i.e. it prevents the driver
+from transmitting on a half duplex channel if there is already a
+transmitter on air.
+
+\fBhdlcdrv_ptt\fP should be called by the hardware driver to determine
+if it should start or stop transmitting. The hardware driver does not
+need to worry about keyup delays. This is done by the HDLC driver.
+
+\fBhdlcdrv_receiver\fP actually processes the received bits delivered
+by \fBhdlcdrv_putbits\fP. It should be called with interrupts on.
+It guards itself against reentrance problems.
+
+\fBhdlcdrv_transmitter\fP actually prepares the bits to be transmitted.
+It should be called with interrupts on. It guards itself against
+reentrance problems.
+
+\fBhdlcdrv_arbitrate\fP does the channel access algorithm
+(p-persistent CSMA). It should be called once every 10ms. Note that the
+hardware driver \fBmust\fP set the \fIhdrv.par.bitrate\fP field prior
+to starting operation so that \fBhdlcdrv\fP can calculate the transmitter
+keyup delay correctly.
+
+.SH "HARDWARE DRIVER ENTRY POINTS"
+The hardware driver should provide the following information to
+the HDLC driver:
+
+.nf
+struct hdlcdrv_ops {
+        const char *\fIdrvname\fP;
+        const char *\fIdrvinfo\fP;
+        int (*\fIopen\fP)(struct device *);
+        int (*\fIclose\fP)(struct device *);
+        int (*\fIioctl\fP)(struct device *, struct ifreq *, int);
+};
+.fi
+
+\fBdrvname\fP and \fBdrvinfo\fP are just for informational purposes.
+
+The following routines receive a pointer to the \fIdevice\fP structure,
+where they may find the io address, irq and dma channels.
+
+\fBopen\fP must be provided. It is called during
+\fBifconfig\ \fP\fIifname\fP\fB\ up\fP and should check for the hardware,
+grab it and initialize it. It usually installs an interrupt handler
+which then gets invoked by the hardware.
+
+\fBclose\fP must be provided. It is called during
+\fBifconfig\ \fP\fIifname\fP\fB\ down\fP and should undo all actions done
+by \fBopen\fP, i.e. release io regions and irqs.
+
+\fBioctl\fP may be provided to implement device specific ioctl's. 
+
+.SH "IOCTL CALLS"
+
+The driver only responds to \fISIOCDEVPRIVATE\fP. Parameters are passed
+from and to the driver using the following struct:
+
+.nf
+struct hdlcdrv_ioctl {
+        int cmd;
+        union {
+                struct hdlcdrv_params mp;
+                struct hdlcdrv_channel_params cp;
+                struct hdlcdrv_channel_state cs;
+                unsigned int calibrate;
+                unsigned char bits;
+        } data;
+};
+.fi
+
+Since the 16 private \fIioctl\ request\fP numbers for network drivers
+were not enough, the driver implements its own \fIsub\ request\fP number
+with \fIcmd\fP. The following numbers are implemented:
+
+.TP
+.B HDLCDRVCTL_GETMODEMPAR
+returns the IO parameters of the modem in \fIdata.mp\fP. This includes
+the io address, irq, eventually dma, and ports to output a PTT signal.
+
+.TP
+.B HDLCDRVCTL_SETMODEMPAR
+sets the modem parameters. Only superuser can do this. Parameters
+can only be changed if the interface is not running (i.e. down).
+
+.TP
+.B HDLCDRVCTL_GETCHANNELPAR
+returns the channel access parameters.
+
+.TP
+.B HDLCDRVCTL_SETCHANNELPAR
+sets the channel access parameters. Only superuser can do this.
+They may also be changed using the \fBkissparms\fP command if using
+kernel AX.25 or the \fBparam\fP command of \fB*NOS\fP.
+
+.TP
+.B HDLCDRVCTL_GETSTAT
+statistics and status information, such as if a carrier is detected
+on the channel and if the interface is currently transmitting.
+
+.TP
+.B HDLCDRVCTL_CALIBRATE
+instructs the driver to transmit a calibration pattern for the
+specified number of seconds.
+
+.TP
+.B HDLCDRVCTL_GETSAMPLES
+returns the bits delivered by the hardware driver with
+\fIhdlcdrv_channelbit\fP. The bits are returned 8 at a time
+with the least significant bit the first one. This command may not be
+available, depending on debugging settings.
+
+.TP
+.B HDLCDRVCTL_GETBITS
+returns the bits delivered by the hardware driver to the HDLC decoder.
+The bits are returned 8 at a time with the least significant bit the
+first one. This command may not be available, depending on debugging
+settings.
+
+.SH "SEE ALSO"
+.BR baycom "\ (9), " soundmodem "\ (9), " sethdlc "\ (8), "
+linux/drivers/net/hdlcdrv.c,
+
+.SH AUTHOR
+hdlcdrv was written by Thomas Sailer, HB9JNX/AE4WA, (sailer@ife.ee.ethz.ch).
+
+
+
+
diff --git a/hdlcutil/sethdlc.8 b/hdlcutil/sethdlc.8
new file mode 100644
index 0000000..d232b6c
--- /dev/null
+++ b/hdlcutil/sethdlc.8
@@ -0,0 +1,282 @@
+.\" Copyright 1996 Thomas Sailer (sailer@ife.ee.ethz.ch)
+.\" May be distributed under the GNU General Public License
+.\"
+.\" portions from setserial.8 by Rickard E. Faith (faith@cs.unc.edu)
+.\" "
+.TH SETHDLC 8 "1 October 1996" "Sethdlc 0.1" "Linux Programmer's Manual"
+.SH NAME
+sethdlc \- get/set Linux HDLC packet radio modem driver port information
+.SH SYNOPSIS
+.B sethdlc
+.B "[ \-bdhs ]"
+.B "[\-i device]"
+
+.B "sethdlc [\-i device] -c"
+cal
+
+.B "sethdlc\ -p"
+.B "[\-i\ device]"
+.BR "[\ mode\ " mode "\ ]"
+.BR "[\ io\ " iobase "\ ]"
+.BR "[\ irq\ " irq "\ ]"
+.BR "[\ dma\ " dma "\ ]"
+.BR "[\ dma2\ " dma2 "\ ]"
+.BR "[\ serio\ " seriobase "\ ]"
+.BR "[\ pario\ " pariobase "\ ]"
+.BR "[\ midiio\ " midiiobase "\ ]"
+.BR "[\ options\ " options "\ ]"
+
+.B "sethdlc\ -a"
+.B "[\-i\ device]"
+.BR "[\ txd\ " txdelay "\ ]"
+.BR "[\ txtail\ " txtail "\ ]"
+.BR "[\ slot\ " slottime "\ ]"
+.BR "[\ ppersist\ " ppersistence "\ ]"
+.BR "[\ full\ ]"
+.BR "[\ half\ ]"
+
+
+.SH DESCRIPTION
+.B sethdlc
+is a program designed to set and/or report the configuration information
+associated with a soundcard radio modem port.  This information includes the
+modem type, what I/O port, IRQ and DMA channel a particular modem
+port is using, and where to output a transmitter keying (PTT) signal.
+
+With the
+.B \-p
+option,
+.B sethdlc
+sets and/or reports the port configuration.
+
+With the
+.B \-a
+option,
+.B sethdlc
+sets and/or reports the AX.25 channel access parameters. These parameters can also
+be set with the
+.I kissparms
+utility.
+
+With the
+.B \-c
+option,
+.B sethdlc
+instructs the driver to send a calibration pattern for
+.I cal
+seconds.
+
+Without the 
+.B \-p,
+.B \-a
+and
+.B \-c
+option,
+.B sethdlc
+will stay in the foreground and display received packets. The AX.25 header
+and eventually a FlexNet compressed header are decoded. CTRL-C terminates
+.B sethdlc.
+Specifying additional options, 
+.B sethdlc
+may display additional information.
+
+
+.SH OPTIONS
+.B sethdlc
+accepts the following options:
+
+.TP
+.B \-b
+Trace the bits at the output of the demodulator, after RX clock recovery. 
+This option is only available if \fBsethdlc\fP
+and the soundcard modem kernel driver is compiled with debugging support on.
+This is useful for driver debugging.
+.TP
+.B \-d
+Trace DCD, PTT and other status information on stdout. \fBsethdlc\fP
+displays two times per second a line containing these informations.
+.TP
+.B \-h
+Display an overview of the available command line parameters and exit.
+.TP
+.B \-i
+The
+.I device
+argument specifies the HDLC modem device which should be configured or
+interrogated.  It will usually have the following form:
+\fIbc[0-3]\fP for the baycom driver and
+\fIsm[0-3]\fP for the soundcard modem driver.
+.TP
+.B \-s
+Trace the bits at the demodulator output, \fIbefore\fP
+the RX clock recovery, to stdout. This option is only available the modem driver
+is compiled with debugging support on. It may not be available on some modem, such 
+as the \fIpar96\fP.
+
+.SH PARAMETERS
+The following parameters can be assigned to a soundcard radio modem port.
+
+All numerical parameter values are assumed to be in decimal unless preceeded by "0x".
+
+The
+.B mode
+parameter sets the type of hardware and the operating mode of the driver.
+\fIser12\fP and \fIpar96\fP are valid modes for the \fBbaycom\fP driver.
+A star "\fI*\fP" may be added to enable software DCD. The \fBmode\fP string
+format of the \fBsoundmodem\fP driver is as follows: \fIhw:mode\fP.
+\fIhw\fP may be either \fIsbc\fP, \fIwss\fP or \fIwssfdx\fP. The first
+one specifies SoundBlaster compatible soundcards, the second one
+WindowsSoundSystem compatible hardware, and the third one WSS fullduplex
+operation (which currently works with Crystal Semiconductor Chipsets
+CS423[126]). The \fImode\fP portion may be \fIafsk1200\fP or \fIfsk9600\fP.
+Optionally, the receive and transmit modes may be different
+(\fIhw:txmode.rxmode\fP).
+
+The
+.B ioport
+parameter sets the I/O port address. Typical values for the \fIser12\fP modem are
+0x3f8, 0x2f8, 0x3e8 or 0x2e8, for the \fIpar96\fP modem 0x378, 0x278 or 0x3bc, for
+the \fIsbc\fP modems 0x220 and for the \fIwss\fP modems 0x530, 0x608, 0xe80 or 0xf40.
+
+The
+.B irq
+parameter sets the hardware IRQ number. Typical values for the \fIser12\fP modem are
+4 and 3, for the \fIpar96\fP modem 7 or 5, for the \fIsbc\fP modems are 7 or 5 and for
+the \fIwss\fP modems, any free IRQ from the set 2, 7, 9, 10, 11 will do. The driver
+automatically configures the WSS soundcard to the correct IRQ.
+
+The
+.B dma
+parameter sets the hardware DMA number. Typical values for the \fIsbc\fP modems are
+1 or 0 and for the \fIwss\fP modems, any free DMA from 0 to 3 (except 2) will do.
+The driver automatically configures the WSS soundcard to the correct DMA.
+The Baycom modems do not need DMA.
+
+The
+.B dma2
+parameter sets the second hardware DMA number. This is only needed for
+full duplex operation with the \fBsoundmodem\fP driver.
+
+The
+.B seriobase
+parameter optionally sets the address of a serial port, where
+the driver will output a PTT signal at the TxD and RTS pins, and a DCD
+signal at the DTR pin. As Baycom modems do have their own PTT pin, this 
+parameter is not used by the Baycom modem driver.
+
+The
+.B pariobase
+parameter optionally sets the address of a LPT port where
+the driver will output a PTT signal on the DATA0 line and a DCD signal
+on the DATA1 line. As Baycom modems do have their own PTT pin, this 
+parameter is not used by the Baycom modem driver.
+
+The
+.B midiiobase
+parameter optionally sets the address of a MPU401 compatible
+MIDI port, where the driver will output a PTT signal. Since the MIDI port is
+effectively an UART and therefore cannot output a DC signal, the output must
+be fed through a retriggerable monoflop with a period of about 15ms. See
+.I http://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html
+for a sample schematic diagram. As Baycom modems do have their own PTT pin,
+this parameter is not used by the Baycom modem driver.
+
+The
+.B txdelay
+sets the transmitter keyup delay time. Unlike \fIkissparms\fP, the unit is
+\fItens of ms\fP. This is the time the transmitter needs to switch its PA
+on and for its frequency synthesizer to settle. Typical values for a handheld
+transceiver are 200ms (i.e. 20), and for a good crystal driven transceiver
+20ms (i.e. 2).
+
+The
+.B txtail
+sets the time PTT is held after the last packet. Unlike \fIkissparms\fP, the unit
+is \fItens of ms\fP. Do not set this value to 0. Most modems need some extra
+time to actually clock the last bits out to the transmitter.
+
+The
+.B slottime
+parameter specifies how often the channel access algorithm is executed.
+Unlike \fIkissparms\fP, the unit is \fItens of ms\fP. Unless you have very 
+specific requirements, set this to 100ms (i.e. 10).
+
+The
+.B ppersist
+sets how "eagerly" the station starts to transmit as soon as the channel
+gets free. The optimum value is 256 divided by the number of stations on the
+channel. (This should really be done automatically by the L2)
+
+.B full
+sets the modem to full duplex mode. Note that some modems do not actually support
+full duplex mode, in this case this parameter makes the modem start its transmission
+as soon as it gets packets from the upper layer, without waiting for the channel
+to become free. This is needed by some implementations of alternative channel
+access algorithms, e.g. \fIDAMA\fP.
+
+.B half
+sets the modem to half duplex mode.
+
+.SH CONSIDERATIONS OF CONFIGURING BAYCOM PORTS
+It is important to note that sethdlc merely tells the Linux kernel
+where it should expect to find the I/O port and IRQ lines of a
+particular serial port.  It does 
+.I not
+configure the hardware to use a
+particular I/O port.  In order to do that, you will need to physically
+program the serial board, usually by setting some jumpers or by
+switching some DIP switches.
+
+This section will provide some pointers in helping you decide how you
+would like to configure your baycom ports.
+
+The "standard MS-DOS" port associations are given below:
+
+.nf
+.RS
+COM1, port 0x3f8, irq 4
+COM2, port 0x2f8, irq 3
+COM3, port 0x3e8, irq 4
+COM4, port 0x2e8, irq 3
+LPT1, port 0x378, irq 7
+LPT1 (on hercules graphics adapter), port 0x3bc, irq 7
+LPT1, port 0x278, irq 5
+.RE
+.fi
+
+.SH CONSIDERATIONS OF CONFIGURING SOUNDCARD RADIO MODEM PORTS
+Some cards need to be initialized before they act as a WSS or SoundBlaster
+compatible card. This driver does \fInot\fP do this. You can use the standard
+linux sound driver, if compiled as a module. Just load the sound driver
+(insmod sound) and remove it again (rmmod sound). The card should then be
+configured for either soundblaster or WSS compatibility. If this does not work
+for some reason, you'll have to write your own soundcard configuration
+utility. This is not as complicated as it sounds; it can be done from
+user space (but requiring root privileges) using \fIioperm\fP and/or \fIiopl\fP.
+
+It is important that the audio levels of your radio match those of the
+soundcard. To help achieve this, there are two utilities: \fIsmdiag\fP
+and \fIsmmixer\fP. See their respective manpage.
+
+The sound driver and the soundcard modem driver are mutually exclusive, i.e. they
+cannot both access the same soundcard at the same time. Even worse, the sound driver
+reserves the soundcard as soon as it gets loaded. The souncard modem driver however
+reserves the card only when the interface is started, i.e. during ifconfig sm[0-3] up.
+
+9600 baud may not currently work on SoundBlaster cards with DSP revision 4.x, i.e.
+SB16 and SB32 AWE. This is because they seem to not be fully backwards compatible.
+
+.SH CAUTION
+CAUTION: Using an invalid port can lock up your machine.
+
+.SH "SEE ALSO"
+.nf
+.BR smdiag "\ (8), " smmixer "\ (8), " kissparms "\ (8),"
+linux/drivers/net/hdlcdrv.c,
+linux/drivers/net/baycom.c,
+linux/drivers/net/soundmodem.c
+.fi
+
+.SH AUTHOR
+sethdlc was written by Thomas Sailer, HB9JNX/AE4WA (sailer@ife.ee.ethz.ch).
+Inspired by setserial.
diff --git a/hdlcutil/smdiag.8 b/hdlcutil/smdiag.8
new file mode 100644
index 0000000..276a1b7
--- /dev/null
+++ b/hdlcutil/smdiag.8
@@ -0,0 +1,78 @@
+.\" Copyright 1996 Thomas Sailer (sailer@ife.ee.ethz.ch)
+.\" May be distributed under the GNU General Public License
+.\" "
+.TH SMDIAG 8 "1 October 1996" "Smdiag 0.1" "Linux Programmer's Manual"
+.SH NAME
+smdiag \- Linux soundcard packet radio modem driver diagnostics utility
+.SH SYNOPSIS
+.B smdiag
+.B "[\-i device]"
+.B "[\-d display]"
+.B "[ \-ce ]"
+
+.SH DESCRIPTION
+.B smdiag
+may help to adjust the audio levels of the soundcard modem driver, as well
+as to control the quality of the radio link. It may either display an
+oscilloscope like view of the input signal, or display an eye diagram.
+The display may be gated with DCD, i.e. only updated if the modem detects
+a data carrier.
+
+.SH OPTIONS
+.B smdiag
+accepts the following options:
+
+.TP
+.B \-i
+The
+.I device
+argument specifies the soundcard modem device which should be configured or
+interrogated.  It will usually have the following form:
+.I sm[0-3].
+.TP
+.B \-d
+sets the address of the X server to display the window.
+.TP
+.B \-h
+display an overview of the available command line parameters and exit.
+.TP
+.B \-c
+toggle the carrier gating of the display.
+.TP
+.B \-e
+display an eye diagram (overlay of the synchronized demodulator output)
+instead of an oscilloscope view of the input signal.
+
+.SH KEYS
+.TP
+.B C
+clears the window
+.TP
+.B D
+toggles the DCD gating.
+.TP
+.B E
+displays an eye diagram
+.TP
+.B I
+displays the input signal
+.TP
+.B Q
+quits
+.I smdiag
+
+.SH BUGS
+.B smdiag
+Reacts sluggishly to keypresses. The window size is fixed. For speed reasons,
+two square root operations per sample are not implemented in the AFSK 1200 
+baud modes. The eye diagram for the AFSK 1200 baud mode is therefore
+distorted.
+
+.SH "SEE ALSO"
+.BR smmixer " (8), " sethdlc " (8),"
+linux/drivers/net/soundmodem.c
+
+.SH AUTHOR
+smdiag was written by Thomas Sailer (sailer@ife.ee.ethz.ch).
+
+
diff --git a/hdlcutil/smmixer.8 b/hdlcutil/smmixer.8
new file mode 100644
index 0000000..c6fc2bb
--- /dev/null
+++ b/hdlcutil/smmixer.8
@@ -0,0 +1,164 @@
+.\" Copyright 1996 Thomas Sailer (sailer@ife.ee.ethz.ch)
+.\" May be distributed under the GNU General Public License
+.\" "
+.TH SMMIXER 8 "1 October 1996" "Smmixer 0.1" "Linux Programmer's Manual"
+.SH NAME
+smmixer \- get/set Linux soundcard packet radio modem driver mixer
+.SH SYNOPSIS
+.B smmixer
+.B "[\-i device]"
+.BR "[ " params " ]"
+
+.SH DESCRIPTION
+.B smmixer
+displays and/or sets the input source and input and output levels of a
+soundcard modem port.
+
+.SH OPTIONS
+.B smmixer
+accepts the following option:
+
+.TP
+.B \-i
+The
+.I device
+argument specifies the soundcard modem device which should be configured or
+interrogated.  It will usually have the following form:
+.I sm[0-3].
+
+.SH PARAMETERS
+The
+.B AD1848 (WSS)
+mixer accepts the following parameters:
+.TP
+.B ol=val
+sets the level of the left output to the specified value. Legal values are from
+-100..0dB.
+.TP
+.B or=val
+sets the level of the right output to the specified value. Legal values are from
+-100..0dB.
+.TP
+.B o=val
+sets the level of both outputs to the specified value. Legal values are from
+-100..0dB.
+.TP
+.B il=val
+sets the level of the left input to the specified value. Legal values are from
+0..43dB.
+.TP
+.B ir=val
+sets the level of the right input to the specified value. Legal values are from
+0..43dB.
+.TP
+.B i=val
+sets the level of both inputs to the specified value. Legal values are from
+0..43dB.
+.TP
+.B sl=val
+sets the source of the left input to the specified value. Legal values are
+.I line, aux1, mic
+or
+.I dac.
+.TP
+.B sr=val
+sets the source of the right input to the specified value. Legal values are
+.I line, aux1, mic
+or
+.I dac.
+.TP
+.B s=val
+sets the source of both inputs to the specified value. Legal values are
+.I line, aux1, mic
+or
+.I dac.
+
+.in \n[IN]u
+The
+.B CT1335 (SB2.x)
+mixer accepts the following parameter:
+.TP
+.B o=val
+sets the output level to the specified value. Legal values are from -46..0dB.
+
+.in \n[IN]u
+The
+.B CT1345 (SBPro)
+mixer accepts the following parameters:
+.TP
+.B ol=val
+sets the level of the left output to the specified value. Legal values are from
+-46..0dB.
+.TP
+.B or=val
+sets the level of the right output to the specified value. Legal values are from
+-46..0dB.
+.TP
+.B o=val
+sets the level of both outputs to the specified value. Legal values are from
+-46..0dB.
+.TP
+.B s=val
+sets the input source to the specified value. Legal values are
+.I mic, cd
+or
+.I line.
+
+.in \n[IN]u
+The
+.B CT1745 (SB16, SB32 AWE)
+mixer accepts the following parameters:
+.TP
+.B ol=val
+sets the level of the left output to the specified value. Legal values are from
+-62..18dB.
+.TP
+.B or=val
+sets the level of the right output to the specified value. Legal values are from
+-62..18dB.
+.TP
+.B o=val
+sets the level of both outputs to the specified value. Legal values are from
+-62..18dB.
+.TP
+.B il=val
+sets the level of the left input to the specified value. Legal values are from
+-62..18dB.
+.TP
+.B ir=val
+sets the level of the right input to the specified value. Legal values are from
+-62..18dB.
+.TP
+.B i=val
+sets the level of both inputs to the specified value. Legal values are from
+-62..18dB.
+.TP
+.B s=val
+enables the specified value as a source. Legal values are
+.I line, line.l, line.r, midi, midi.l, midi.r, cd, cd.l, cd.r
+or
+.I mic.
+
+.SH CONSIDERATIONS
+It is important that the audio levels of your radio match those of the
+soundcard. To help achieve this, use the
+.I smdiag
+utility.
+
+This utility can only be used after the interface is started up, i.e. after
+ifconfig sm? up.
+
+The sound driver and the soundcard modem driver are mutually exclusive, i.e. they
+cannot both access the same soundcard at the same time. Even worse, the sound driver
+reserves the soundcard as soon as it gets loaded. The souncard modem driver however
+reserves the card only when the interface is started, i.e. during ifconfig if up.
+
+9600 baud may not currently work on SoundBlaster cards with DSP revision 4.x, i.e.
+SB16 and SB32 AWE. This is because they seem to not be fully backwards compatible.
+
+.SH "SEE ALSO"
+.BR smdiag " (8), " sethdlc " (8),"
+linux/drivers/net/soundmodem.c
+
+.SH AUTHOR
+smmixer was written by Thomas Sailer (sailer@ife.ee.ethz.ch).
diff --git a/hdlcutil/soundmodem.9 b/hdlcutil/soundmodem.9
new file mode 100644
index 0000000..c65837c
--- /dev/null
+++ b/hdlcutil/soundmodem.9
@@ -0,0 +1,82 @@
+.\" Copyright 1996 Thomas Sailer (sailer@ife.ee.ethz.ch)
+.\" May be distributed under the GNU General Public License
+.\" "
+.TH SOUNDMODEM 9 "2 October 1996" "Linux 2.1.x" "Kernel Reference Guide"
+.SH NAME
+soundmodem \- amateur (AX.25) packet radio network driver for soundcards
+.SH SYNOPSIS
+
+.nf
+.B #include <linux/soundmodem.h>
+.B #include <linux/hdlcdrv.h>
+.fi
+
+.SH DESCRIPTION
+The driver currently supports both 1200 baud AFSK and 9600 baud FSK
+(G3RUH compatible) using a standard SoundBlaster compatible or 
+WindowsSoundSystem compatible soundcard. The whole decoding is done
+in software, so you definitely do not want to use it on a 386SX class
+machine.
+
+.SH "KEYING THE TRANSMITTER"
+Soundcards do not have a DC coupled output that could serve as a
+PTT signal. So there are basically for possibilities for
+obtaining a PTT signal. Sample schematic diagrams can be found on
+\fIhttp://www.ife.ee.ethz.ch/~sailer/pcf/ptt_circ/ptt.html\fP.
+.SS "VOX circuitry"
+A simple VOX circuitry that detects output signals at the output of
+the soundcard can be used, especially as it can be built with a single
+transistor plus a few passive components and typical soundcards have
+strong output signals.
+.SS "Parallel Port"
+A parallel port line can also be used to signal PTT. If selected,
+the PTT signal is output on the DATA0 line and DCD is output on the
+DATA1 line.
+.SS "Serial Port"
+A standard serial port (8250, 16450, 16550) can also be used to output
+PTT. PTT is output on RTS and TxD, while DCD is output on DTR.
+.SS "MPU401 MIDI Port"
+The MIDI port is basically an asynchronous serial interface and
+thus cannot output a straight DC level, however it may be used if
+connected through a retriggerable monoflop with about 15ms pulse
+duration. Note that only newer SoundBlaster models have a genuine
+MPU401 MIDI port. The older SB MIDI port cannot be used.
+
+.SH "IOCTL CALLS"
+The \fBioctl\fP calls follow the implementation in the \fIhdlcdrv\fP.
+
+.TP
+.B SMCTL_GETMODEMTYPE
+returns the modem type (i.e. \fISBC1200\fP, \fISBC9600\fP, \fIWSS1200\fP
+or \fIWSS9600\fP)
+.TP
+.B SMCTL_SETMODEMTYPE
+sets the modem type. Only superuser can do this.
+.TP
+.B SMCTL_GETMIXER
+returns the mixer type and the contents of the specified
+mixer register.
+.TP
+.B SMCTL_SETMIXER
+sets the specified mixer register, if the specified
+mixer type matches the mixer type of the soundcard. Only 
+superuser can do this.
+.TP
+.B SMCTL_DIAGNOSE
+returns the contents of the diagnose buffer, which is used by
+\fIsmdiag\fP to display the eye and oscilloscope diagrams.
+.TP
+.B SMCTL_GETDEBUG
+return some debugging values. Not always available.
+
+
+.SH "SEE ALSO"
+.BR baycom " (9), " soundmodem " (9)," smdiag " (8)," smmixer " (9),"
+linux/drivers/net/hdlcdrv.c,
+
+.SH AUTHOR
+soundmodem was written by Thomas Sailer, HB9JNX/AE4WA, (sailer@ife.ee.ethz.ch).
+
+
+
+