We have added dual port capibility in DIGI MODE ONLY to allow us to use it
with a Dataengine. Very little needed changing, but we did not document the 
changes.  If you really need to know, diff the package against the original,
which was/is at sunsite.unc.edu.  To specify the second port, do something 
like this...

#to use the second port, we need to be in digi mode
mode digi
#
#port 0 on my tnc goes to vhf
mycall ve3djf-12
myalias vhfdjf
#
#port 1 on my tnc goes to uhf.  
#The callsign and alias must be different for this to work right... 
mycall2 ve3djf-13
myalias2 uhfdjf
#

Everything else is the same.  Note that if you leave out the mycall2 and 
myalias2 defines, it works just like the original in single port mode.  For
recieving on the KISS (dual) port, packets are checked against both callsigns
and aliases.  Whoever is on the other end of the AXIP link can find out what 
port it came from by looking at the who it got digi'd through, although 
I can't think of any reason to do that... For transmiting, you go out the 
port with the callsign matching the digi address.  For example, to go out 
port 0 in the above example, digi through ve3djf-12 or vhfdjf.
To go out port 1, digi through ve3djf-13 or uhfdjf.

Deficencies:  If you specify the same callsign on both
ports, no error is generated, but the way the logic in the code works you
always go out the upper port (port 1), not port 0.  In TNC mode, there is
really no way to specify which port to transmit on that I can think of, so
there is no multiplexing there.  Everything goes out port 0 in TNC mode 
still.  Lastly, none of the dump routines know anything about ports on the
KISS interface, so they look the same, with both ports lumped into one.

Let us know if you like this hack, BTW.  In retrospect, we should have 
written a KISSPlexor (tm:-) HIHI.  I think we will do that next.


73! de Jeff / VE3DJF
Jeff@lnx_rpi.ee.ryerson.ca
VE3DJF@bbs.VE3RPI.ampr.org

