۱۱۱ ۱۱ ۱ ۱ ۱ ۱ ۱۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ ۱ The Firmware PC Extended Version 2.71 (23. March 1998) Resident AX.25-Controller for PC and BayCom-Modem, SCC-Boards, PAR96, YAM96 PA0HZP-OptoPcScc Board, KISS with WA8DED-Hostmode-Interface and DRSI cards by Henk de Groot, PE1DNN Based on TFPCX 2.21 by Ren Stange, DG0FT Based on TF2.7b by NORD>: n = 1-4 (Number of the COM-Port) The default address is the address known by the BIOS. default 4 (COM1 or COM3) or 3 (COM2 or COM4) will be used when not otherwise specified. The YAM modem does not support Soft-DCD. The @C will have no effect. The parameter @D (Duplex) will be ignored. - Added -SA option. For transmission the 'frame-sammler' function is off by default. By using -SA you can switch it on again. - At link-setup time timer T1 (frame-acknoledge timer) did not run, this resulted in an unusable link if at startup the first I frame was missed (T1 regulates retransmission). This problem occured freqently when the UA response to SABM at setup was missed and the CTEXT (U command) was send directly following the UA (occurs often when using SP or GP). - Before generating a RR response a check is done if DCD is active. If so the generation of the response is postphoned. This allows the use of much smaller @T2 values then those needed for KISS use. This will make the link faster and should be compatible now with TFPCX221 and earlyer. - Changed TF2.3b to TF2.7b - corrects the usage for DAMA - Due to the use of TF2.7b, the "Framesammler" is supported - When connected to a DAMA master the DCD is now ignored like in TFX and TheFirmware 2.7b based TNCs (with the latest TF2.7b). - When using the -ST option on the commandline the DOS-Time will be used to set the clock in the TNC. This will give the real time to the timestamps (K command) - When you wanted to start Windows95 after TFPCX has been loaded and unloaded, Windows95 would complain about a non-conformant TSRs and use a so-called 'compatibility mode', in effect using 16-bit DOS drivers instead of 32-bit Windows95 drivers. This has now been solved. - The BayCom PAR96 and PICPAR modems are supported Option -PPARn:: n = 1-4 (Number of the LPT-Port) The default address is the address known by the BIOS. 7 will be used when not otherwise specified. The Soft-DCD can be activated by the @C command. All values other than 0 have the same effect. The value only has influence on the DCD-indicator (more stable with larger values). The parameter @D (Duplex) will be ignored. - RMNC-CRC-KISS is supported when using -PKISS and automatically activated. The command @ST shows for both SMACK and RMNC-CRC-KISS a "+" symbol. - The BayCom Digi SCC-card is supported (only Ports 0 to 3). Option -PDSCC::: (Default -PDSCC:300:7:2222) - The TheFirmware K command (Timestamp) can be used. The flag -ST should be given on the command line to enable it. - FlexNet frames with header-compression are shown in the monitor. The command M +/- is used here. Format of the monitor-header: fm # to ctl ... fm to ctl SABM+ # fm to ctl UA- # = FlexNet QSO Number - For KISS, BayCom PAR96-Modem and PA0HZP OptoPcScc-card, the real-time clock will be used as timebase for internal timers so the time measurement will be more precise (not under Windows). - The option -ND has been removed. - KISS-Mode (including SMACK support) for up to 4 Ports and 57600 baud is supported (Option -PKISS). Frame errors (e.g. through character loss) will be ignored and counted (See Section 6.2.1 and 8.3.). By means of TFPCX and KISS the program GP (DH1DAE) can now control more TNCs simultaneously. - The PA0HZP OptoPcScc-card is supported (option -POSCC, see section 6.2.1). - The BayCom 9K6 USCC-card now functions with TFPCX (Option -PUSCC, see section 6.2.1.). When using some BayCom USCC-cards, meaningless data was transmitted because of timing problems. This problem has been avoided by using another way of driving the SCC-controller, . - For SCC-Cards and COM-Ports (with KISS) AT-IRQs (9, 10, 11, 12, 14, 15) can be used. - The number of free buffers (Option -BU) and the number of channels (Option -CH), and therefore the required RAM-Space, can now be configured. (Default values: 600 Buffers/10 Channels, see section 6.2.3.) - The initialisation file (option -F) may now contain empty lines and comments. ESC-Characters will be recognised automatically and no longer require defining with '^' (See section 6.2.3). - When using the DRSI-interface (Option -DR), the incompatibilities with respect to the DRSI TNCTSR-driver have been removed. These incompatibilities previously lead to problems with the monitor and heard-list in combination with FBB (F6FBB). In cases where these modifications now give problems with other programs (e.g. with TOP), using the option -DX will enable the previous (modified) DRSI-Interface again (See section 6.2.2.1). - The new @PO command enables selective allocation of a channel to a port, so the channel can only be connected from this port. This is useful when using the Program TOP (DF8MT) or TstHost (IK1GKJ). (See section 7.8 and 8.2.). - By means of a Transparent-Mode during reception (Command @M) and switchable character echoing (Command @E). #BIN#-Reception in is possible in Terminal-mode (e.g. with TERM (DL5FBD)). (See section 7.4 and 8.2) - Internal connects (Loopback) can be switched off when needed (Option -NL, see Section 6.2.3.). - TXTAIL (Command @TA) in combination with the serial modem and SCC-Card will be optimally installed according to the baud-rate and timer inaccuracy. Previously it gave some problems with operation at 300 Baud. - If the Option -P is not specified, it will not longer default to a serial modem on COM1 as before , but to no port at all, which is only meant for test purposes with internal connects. Therefore -P should always be specified in normal cases. - From now on, the option -D (Debug) is on only applicable to the most recently specified option -P (Port). This will enable monitoring of a specific port, even during multiport operation (See section 6.2.3.). - Disconnecting in the background mode or terminal mode is possible by means of the remote command '//Q' (Command U, see section 8.2.) - Because of a DAMA-change (since TF 2.6) the known "complaint- messages" from of TheNetNode-Digis during multiconnect should now be eliminated. - The Extended Host-Mode (DG3DBI) is now supported and enables faster communication with a terminal program. - The default-values for the Parameters F, N, P, R, T, U, @I, @T2, @T3, AND @TA have been changed. 4. Quick Start Because of the many different configuration settings and the existence of many different terminal-programs no general 'recipes' can be given. In most cases it will be sufficient if you read sections 6.2.1 and 7 (depending on the program used). In case of trouble read appendix 2. For multiport operations, the sections 8.1 and 8.2 are important. In section 8.3 important tips for operation using KISS are given. If you used a previous version without the '-P' option and were using the default COM-1 port you now have to include the option '-PCOM1'. If you previously used version 2.0 with more than 10 channels, you now have to supply the option '-CHnn' during startup of TFPCX, where nn is the number of channels required. If you used the option 'DR', and this version introduces problems with your monitor or heared list, you should supply the option '-DX' instead of '-DR'(e.g. with TOP) If you worked with version 1.1x up till now and only want to use one modem you can additionally specify the option '-C' when loading TFPCX if you want the send-/receive indicator - it is not switched on by default anymore. If you used the option 'NC' up 'til now you have to delete that. Command 'TFPCX -H' will show all allowed options in a shorthand form. Command 'TFPCX -U' removes TFPCX from RAM. 5. Introduction A few years ago packet radio was mainly operated using Terminal-Node Controllers (TNCs) which took care of the execution of the PR-specific protocol (AX.25), and used the computer as a tool to look at the data in a convenient way. The TNC itself is nothing more than a small computer with a serial port and a modem. Due to the wide distribution of software for the TNC2 (WA8DED-Firmware or the compatible TheFirmware from NORD> | -T | -U ] All options start with a '-' sign and are seperated by a space character. The space character shall not appear as part of the option. Options are case-insensitive (no difference between upper and lower case. Certain options (e.g. '-P') have more than one parameter, separated by a ':'. For those values which are not explicitly specified default values will be used. Example: Option '-PUSCC::5' will be interpreted as '-PUSCC:300:5:1103', since the omitted values default to 300 and 1103. It makes sense to start TFPCX from a batch-file so you won't have to type in the same options over and over again. All options are listed in short-hand form, which will also be presented as help-text if you enter 'TFPCX -H', The are only relevant while loading TFPCX as a TSR, and remain valid until TFPCX is unloaded from memory. -N no messages -T terminal mode -U unload -P[:xxx:nn:nnnn] packet port [addr:IRQ:] -Bnnnn[:nnnn ...] baud rate (1 number/port) -F[file] read init file -D debug mode -C[xx] show DCD [color] -DM use DRSI messages -Ixx TFPCX interrupt -DR emulate DRSI driver -BU[nnnn] number of buffers -DX modified DRSI interface -CHnn number of channels -NB no blinking rectangle -ST time stamp -NL no loopback -SA sammler on for TX COMn | LPTn | PARn | YAMn | KISSn | DSCC | OSCC | USCC (n = 1-4) 0 = disable 2 = hardclock 4 = PA0HZP port (1 digit/ 1 = softclock 3 = DF9IC modem 5 = PA0HZP timer channel) [] optional use | alternative command x Hexadecimal number n Decimal number 6.1. General Options These options can be used together with every other option. Currently there is only one: -N Suppress Messages In case messages from the progam are not wanted (e.g. in batch-files), they can be suppressed by using this option. Error messages are not supressed. 6.2. Options for loading as TSR TFPCX will always load as a resident program in RAM, except when either option '-T' or '-U' are specified, or when TFPCX, TFPCR or DRSI-TNCTSR are already running resident in memory. If you want to use multiple drivers simultaneously, TFPCX has to be the first TSR to be loaded. I cannot guarantee that it will work without problems in this case. The TFPCX program can also be loaded high in upper-memory (UMB) using the LOADHIGH command if there is sufficient room. Keep in mind that there are some problems when using EMM386-drivers however (see appendix 2.1.). In order to addapt TFPCX to different hardware, transmission speeds, terminal programs and user preferences there are a lot of options, which will be descibed here. After loading, the following report will appear (example) Ŀ TFPCX v2.71 (Mar 23 1998) by PE1DNN Based on TF2.7b/TNC2 07Jun95 code TheFirmware by NORD>:xxx'. Example: TFPCX -PCOM3:338 Using this connamd a modem connected to COM3 will be used, using base address 0x338. This address should be be looked up in the manual or desciption of the interface. The number of the port (in this example 3) will be ignored if the base adress is explicitly specified but has to be present and between 1 and 4. The IRQ of the interface is of no interest to TFPCX since it is not used. When using 2 modems, the first modem specified shall be the one which is most frequently used because the first modem has a higher priority. It is evident that other programs can't use the same ports as used by TFPCX. -PUSCC::: use BayCom USCC-card -POSCC::: use PA0HZPcOptoPcScc-card -PDSCC::: use BayCom Digi SCC-card The base address of the SCC card, the IRQ and a 4 digit number can be specified as parameters. The 4 digit number specifies the type of the SCC ports (up to 4). The following settings are possible (see also appendix 3.2.): 0 Disable Port disabled (Switched Off) 1 Softclock The transmit and receive clocks are created internally for use with AFSK-Modems (duplex mode not possible) 2 Hardclock The transmit clock will be generated by the modem, the receive clock is created internally (e.g. G3RUH) 3 DF9IC-Modem The transmit and receive clock will be generated by the modem, NRZ-Mode 4 PA0HZP-Port The receive clock will be created internally, divided externally by 32 and passed back to the SCC-Controller as transmit clock. (for OptoPcSCC-card) 5 PA0HZP-Timer This port generates a timing reference for timing purposes (Only for OptoPcSCC-card). The modem types 1-3 are reserved for the USCC- and DSCC card, type 4 only functions with the OptoPcScc-Card. Number 5 has a special meaning. TFPCX requires a regular timer-tick for internal timing. This timer-tick can be deliverd by the OptoPcScc card, but not when running under Windows. In this case the system timer of the PC will be used, which is, however, not so accurate. This can cause a problem for some parameters (e.g. TXDELAY and TXTAIL). TFPCX offers the possibility to use an otherwise unused SCC-Port for generation of an accurate timer-tick, which is recommended when not all ports are in use. Examples: TFPCX -PUSCC:300:7:1103 Base address is 0x300 and IRQ is 7. USCC-ports 0 and 1 are using Softclock for use with normal AFSK-modems (the two '1' digits), port 2 is disabled and port 3 is used with a DF9IC-modem (the '3' digit). This is also the default setting when only '-PUSCC' is supplied. TFPCX -PUSCC:300:7:31 USCC-Port 0 is now setup for a DF9IC modem. Port 1 uses the Softclock and ports 2 and 3 are switched off. This setting is required for the 9K6-USCC Card, which offers only 2 SCC-ports. If no clock specification is supplied '1103' is used by default (as above), but then a setting is given using less than 4 digits the missing digits will interpreted as '0'. TFPCX -POSCC:150:3:4445 OptoPcScc-Card with base address 0x150, IRQ 3. Port 0, 1 and 2 will be used as modem ports with an external clock. Port 3 deleivers a timer-tick. This is also the default setting when using '-POSCC' without additional parameters. TFPCX -PDSCC:300:7:2222 BayCom-Digi-SCC-Card with base address 0x300, IRQ 7. All ports are used with G3RUH modems, which will also deliver the clock. This is also the default setting when using '-PDSCC' without additional parameters. -PKISSn:: KISS-Port on COMn (n = 1-4) The base address will be determined automatically, but can be overrulled if a base-address is specified. IRQ 4 will be used by default for COM1 and 3, IRQ 3 for COM2 and 4. When this is not according to the assingment in your PC you have to specify the correct IRQ. Examples: TFPCX -PKISS1 KISS-Port on COM1, base address determined automatically and default IRQ for COM1 used. For COM1 and COM2 this setting will be sufficient in most cases. TFPCX -PKISS3:338:5 KISS-Port on COM3, base address 0x338 and IRQ set to 5 -PPARn: BayCom PAR96 and BayCom PICPAR-Modem connected to LPT 'n', where 'n' is the number of the LPT port. The base address will be determined automatically, but can be overridden by specifying a base-address. The default IRQ is set to 7. When this is not in accordance with your installation, you have to specify the correct IRQ. Examples: TFPCX -PPAR1 BayCom PAR96 or PICPAR modem on LPT1, base address determined automatically and default IRQ 7 used. TFPCX -PPAR2::5 BayCom PAR96 or PICPAR modem on LPT2, base address determined automatically and IRQ set to 5. -PYAMn: YAM96-Modem connected to COM 'n', where 'n' is the number of the COM port. The base address will be determined automatically, but can be overridden by specifying a base-address. IRQ 4 will be used by default for COM1 and 3, IRQ 3 for COM2 and 4. When this is not according to the assingment in your PC you have to specify the correct IRQ. Examples: TFPCX -PYAM1 YAM96 modem on COM1, base address determined automatically and default IRQ 4 used. TFPCX -PYAM2::5 YAM96 modem on COM2, base address determined automatically and IRQ set to 5. -Bnnnn[:nnnn ...] specification of the baudrate for each port When using multiple ports the values separated by a ':' are assigned to each port in order (first value for port-0, second value for port-1 and so on). The following values can be specified: Default Serial Modem 300, 1200, 2400 or 4800 Baud 1200 SCC Softclock 50-38400 Baud 1200 PA0HZP-Port 50-38400 Baud 1200 Hardclock 50-38400 Baud 9600 DF9IC-Modem 1-65535 Baud (without significance) 9600 KISS 2400, 4800, 9600, 19200, 9600 38400 or 57600 Baud PAR96/PICPAR 9600, 19200 Baud 9600 YAM 45-19200 Baud (without significance) 9600 When using serial modems, only the above specified values are possible; when using SCC cards intermediate values are also possible. When using Hardclock the delivered transmit-clock shall be equal to the specified value. When using a DF9IC modem the value is meaningless because the clocks are generated externally, but it is adviseable to specify the correct value anyway, because that value will be displayed when using the 'P' command. When using the YAM96 modem the given baudrate is cosmetic too (just like for DF9IC), the communication speed to the YAM96 modem is fixed at 19200 Baud. The initialisation of the modem (using YAMINIT - supplied with the modem) determines the actual speed on the air interface. Example: TFPCX -PCOM1 -PUSCC:::1003 -B300::19200 Modem on COM1 at 300 baud, USCC-Port 0 with Softclock at 1200 baud (Default, '::') and USCC-Port 3 with DF9IC-modem at 19200 baud. Which baudrates are possible on a particular PC, depends on its computing power (see table in appendix 2.1.). When using a a serial modem at 300 baud the system clock will lose half a minute every hour. -ST This option will enable the use of timestamps on status messages and monitor messages by means of the 'K' command. This option will also cause setting of the TNC time according to the DOS time on the PC. The default date style is european style. This can be changed using the 'K' command but you have to supply the current date yourself in that case. -SA This option will enable the so called 'frame-sammler' for transmission (TFPCX's reception always uses this feature). If enabled TFPCX will only re-transmit the I frame for which a REJ was received. If the receiver also has a 'frame-sammler' build in the receiver will 'remember' subsequent I frames and will acknoledge those immediatly after the 'lost' I frame has been received. If the receiver does not have this feature you should not specify -SA at the command-line since re-transmission takes much more time in that case. When not specified TFPCX will (re)transmit as much I frames as possible. 6.2.2. TFPC- and DRSI-Interface For communication with a terminal program TFPCX offers 4 different variations from which one has to chosen, depending on the program. Appendix 4.1 describes the calling and parameterparsing for programmers. The TFPC-Interface was developed by Sigi (DL1MEN) for his KISS-driver TFPCR and is widely supported by many programs (e.g. SP, GP, TSTHOST, THP, TERM, DIEBOX). Therefore this method is also selected as the default interface for TFPCX. The disadvantage of this variation is the limited Multi-port capability, because the transfer of port numbers (e.g. of the Port on which one has been connected) is not possible. Because of this, connections and monitor frames are displayed as if they were originating from one frequency. If you are using only one port this variant is recommended. -DR DRSI-Interface usage. This interface uses the TNCTSR driver which belongs to the DRSI-PCPA-Addapter. Since TFPCX now supports multiport usage, a method had to be found for the terminal program to be able separate the different ports. This variant was a suitable alternative since it was already fully supported by SP and FBB. The difference with the TFPC interface is mainly the parsing of the port numbers in link status reports and monitor information. This option does not use hardware support of a DRSI-PCPA-Adapter. -DX Modifies DRSI-Interface operation This option corresponds to the 'DR' option of TFPCX v2.0x. That version introduced an incompatibillity with the TNCTSR-Driver when using DRSI-Interfaces, which has been corrected later. If that correction leads to problems in other programs (e.g. TOP), the option '-DX' should be used instead of '-DR'. -DM Modifies TFPC-Interface operation This variant is specificly designed for multiport operation with programs which so far only support the TFPC interface. It will deliver the same type of messages as the DRSI interface (so it will include port numbers) but uses the already known TFPC interrupt. The usage of this variant is a compromise. With many programs (e.g. TERM) it does not lead to any problem but there are some side-effects and some programs (e.g. THP) can not handle the port numbers at all. The best solution is to try your program with or without the '-DM' option and hope for an update of the program to support multiport operation. The program GP forinstance was changed to suppors this. WARNING! Please do not overload the developer of your terminal program (or me) with messages, if, while using the '-DM' option, something screws up. This option is a compromise and has caused strange effects with certain programs in the past. Hopefully is has been corrected by now. 6.2.3. Other Options -BU[nnnn] Size of the TFPCX-Buffer TFPCX saves most data in 64 byte buffers. The number of buffers needed may be totally different from one application to the other. If TFPCX has a small number of buffers only a few frames can be kept in intermediate buffers and every now and then 'TNC BUSY' messages will be reported, which leads to a disconnect by the terminal program in most cases. Too many buffers waste memory. The buffer size changed from 32 bytes in TF2.3b to 64 bytes in TF2.7b. The designers of TF2.7b decided to keep the reported number of buffers compatible with earlier versions, so when the number of buffers is defined it is divided by 2, and when it is reported it is multiplied by two. The same is applied to TFPCX. The number of buffers is still defined as if the buffers are still 32 bytes. With this option the number of buffers set between 400 and approx. 1400 which will result in 200 to 700 buffers of 64 bytes internally. When reporting the number of free buffers the internally kept number of free buffers is multiplied by 2, the reported number will never have an odd value. The maximum value depends on the number of channels specified and will be allocated when the option -BU is used without an actual number. The default value of 600 buffers (300 real buffers) is usually adequate. If many channels are in use, Gateway-Functions are used, a Mailbox is serviced or large Files transferred on fast Digi-links it makes sense to increase the value. When using SP (except for V7.50) you should not specify more than 999 buffers (see Section 7.1). If there is very little RAM available, then also a smaller number of buffers can be used. -CHnn Number of Connect-Channels With this option, the required number of channels can be specified. The number of channels should be the same as the number of channels selected in the Terminal Program, if defined more it wil just waste valueble RAM space. Selection of 4 to 40 channels are possible (Default 10). -C[xx] Transmit-/Receive indicator switch When using this option an indication of the transmit-/receive status will be displayed while in Host mode. The indicator appears at the top right hand corner of the screen ('S' for transmit (Send), 'R' for receive). When more ports are to be used, each port will have a separate indicator, the left indicator will be the the indicator for port 0. When using KISS mode the indicator will display the status of the connection between PC and TNC. The indication only works in textmode. The additonal parameter specifies a color attribute. Example: TFPCX -C17 ^ Foreground (here White) ^ Background (here Blue) Numbers of the Colour Attributes: 0 Black 4 Red 8 Dark-Grey C Light-Red Monochrome: 1 Blue 5 Magenta 9 Light-Blue D Light-Magenta 2 Green 6 Brown A Light-Green E Yellow 07 Normal 3 Cyan 7 White B Light-Cyan F Light-White 70 Inverse ^ ^ only foreground -F File for the setup parameters (default TFPCX.INI) When using this option (and only then!) the specified file (or when no file name is given TFPCX.INI) will be read during the starup of TFPCX and send character by character to the TheFirmware core inside TFPCX. This makes it possible to give a pre-defined value to the parameters. Normally this option can be omitted, because most terminal programs will initialise the TNC themselfs. The file will be looked for in the current directory if no pathname is given. The file can be created using normal text editor and may contain comments (preceded by '#' or ';') and empty lines. For each command found an escape-character will be sent first automatically. Older versions required a '^' first. This is not longer required and will be ignored when found, so old files can still be used. Tabs will be handled as spaces and will be ignored at the beginning and end of a Line. An example-file is included in the distrubtion package of TFPCX. -Ixx Software-Interrupt for TFPCX-Interface (40-FF) The communication between TFPCX and the terminal-program uses the sepecified software-interrupt. Default value is interrupt 0xFD. You only need to change this if the specified interrupt is already in use by another program or when the terminal program only works with a specific setting (e.g. '-IFF' with CT (K1EA) and FBB (F6FBB)). -NB Switch off Status Flash When TFPCX has unread information or status changes in its buffers and is not running in hostmode (so it is running background) a rectangle will start flashing in the upper right hand corner of the screen. This will allert the user that for example a connect is pending. The user can now start his terminal program to react to the connect. This will not work if a DOS-Shell is started from a terminal program which will keep TFPCX in hostmode (as e.g. with SP). The flashing can suppressed using this option. -NL Internal Connects (Loopback) Switch Off In normal cases all transmitted frames are handled as if they were also received: this enables internal connects for test purposes. In some cases this is not wanted (e.g. during tests with an external loopback) and therefore this option can be used to prevent this. Under high load the use of this option will also reduce the CPU load a little because the transmitted frames don't have to be handled twice. -D Test Mode (Debug) This option is valid for the most recently supplied '-P' option issued before the '-D' option on the command-line. It will activate a test-mode for this port or these ports. Each interrupt for this port will lead to a voltage change on the internal PC speaker which results in a ticks (cracks) or a tone. The test mode is mainly used for fault-finding when there are transmit or receive problems during modem operation. (see Appendix 2.1.). When using 1200 baud you should hear a 1800 Hz-Tone (baudrate * 1.5). This tone should be clear and without interruptions. An unclear tone is caused by delayed interrupts. If the qualtity of the tone sounds disturbed or interrupted then the CPU is overloaded. What is and what is not acceptable is hard to define: some background noice is most likely still acceptable. When using this option with a KISS, SCC-Card, PAR96/PICPAR or YAM96 modem you can check if interrupts are generated at all. These interrupts can occur constantly or only during transmission and reception. When the option '-D' is specified in before any '-P' option then you will hear ticks in time with the system clock. 6.3. Removal of TFPCX from RAM By using the command 'TFPCX -U' you can remove the resident TFPCX from the memory. 6.4. Terminal Mode The command 'TFPCX -T' will start a simple terminal so you can use TFPCX without additional terminal sofware. TPFCX should already have been loaded (as described previously). This means that the program should be invoked twice with different parameter settings (first to load it resident and the second time using this -T option), in order to get into the terminal mode. The key combination ALT-X will stop this terminal program. Before doing that you should switch off the monitor (if activated) using ESC 'MN', because otherwise the internal buffers will be exhausted quite quickly, and it may cause problems when starting a host-mode program afterwards. 7. Installation In this section some advice is given for the installation with some programs using TFPCX. In all cases TFPCX has to be loaded resident before the terminal program is started. Additionally, some settings in configuration files or menus are needed. On the other hand the specified baudrates in these files or menus are irrelevant most of the time: the option '-B' at the start of TFPCX takes care of this. Some programs have problems with multiport use (option '-DM'). In these cases you should skip this option and with it the display of port numbers. The use of port numbers is still possible in the commands so you can still use multiport operation anyway. You just don't see on which port somebody connects or on which port which monitor-frame is received. When using these kind op programs it makes sense to use the '@PO' command (see chapter 8.2). You should be aware that TFPCX occupies a part of menory, so it is not free for use by the terminal program anymore. This may require you to decrease the number of buffers and the number of connect channels to get both TFPCX and the terminal program in memory. 7.1. SP (DL1MEN) Depending on the number of ports, two variants are available: When only one port is required you can opt for the TFPC-Interface, which is supported since SP v5.0. In this case you should install SP according to the SP-manual or using the INSTALL program install SP for TFPCX (or TFPCR) usage. The file CONFIG.SP (previously SP.CFG) shall include the line 'CFG=PORT0:5H'. In practice there is hardly any difference between TFPCX and TFPCR. For multiport use you should use the DRSI-Interface. The file CONFIG.SP shall include the line 'CFG=PORT0:DH' and TFPCX has to be started using the '-DR' option. Apart from that you should keep in mind that everything said about the DRSI-PCPA-Addapter in the SP manual is also applicable to TFPCX, with the following exceptions: - SP-Commands 'DR' and 'HB' do work, the parameter will be set using the normal TNC-Commands with and additional port designation (see Section 8.1). - The port selection mechanisme (described in chapter 8.1) without an explicit specification of the port does not work for some commands. SP will send those to the monitor channel 0 instead of to the actually selected channel. When you are not sure, always specify the port number explicitly. - Commands 'TP' and '//par' will show the correct baud rate (and not a number) When using the DRSI variant with SP, the SP program will allocate an extra QRG for each of the 8 ports , except for the monitor channel. Switching off ports can be accomplished through 'C 1:', on the monitor channel this will select the unproto port. The selected default port will be selected automatically when a connect command is given, but can also be specified directly. TFPCX can also be used in parallel using TNCs in hostmode. How well this will function depends on the computing power of the PC. When using SP6.0 (or earlier), the QRG indication is a bit unstable in some cases and the connect bell doesn't sound the same compared to the sound you hear when using a normal TNC. This is normal and does not cause problems. With early versions of SP v7.00 a bug may cause problems when using a modem. Another problem arises if, while using this SP version, you use 2 modems and a TNC in parallel (which I'm sure somebody will do) and are unsing the DRSI interface. At the startup of SP you will immediately get a Resync message and it will refuse to run. This problem can be solve with a patch for SP.EXE. When using SP v7.00 (or earlier) you should not allocate more than 999 TFPCX buffers (option '-BU') because these versions have problems displaying more than 4 digits, and the transmission will be very slow. In SP version 7.50 this problem is solved. 7.2. GP (DH1DAE) GP will use TFPCX automatically if it is loaded, therefore no additional configuration settings are required in normal cases. For multiport use you have keep the following in mind: - GP version 1.50 or better is required. Earlier versions can only cope with one port, and they also have problems with higher baudrates. - You have to start TFPCX using the option '-DM'. - You must specify at least one PORT command in the file NAMES.GP, because without this command all connect attempts are terminiated with an error message. Example: PORT0 = DB0BLN,438.450 PORT1 = DB0BLO,438,300 With the use of TFPCX, GP is able to control more than one TNC simultaneously. For this to work, these TNCs have to support KISS mode operation (see section 8.3.). 7.3. THP (DL1BHO) THP supports the TFPC-Interface (that is, version 3.03 did). In the configuration file CONFIG.PR you have to specify port number '5' in the 'TNC-Configuration' section. In the file CMD.PR a few commands are normally executed which lead to an error message in TFPCX (for example 'A' and 'Z'). The best solution is to comment these lines out by putting a '#' a the beginning of the offending lines. Multiport-operation using the option '-DM' gains nothing since the port numbers are not correctly displayed. 7.4. TERM (DL5FBD) This TFPCX-version works best with TERM version 9.71 or later. Earlier versions of TERM used another method for transmit- handshaking. This method is not supported by TFPCX anymore. When you want to use more ports you should load TFPCX using the '-DM' option. Since TERM does not process the TFPCX messages itself, it does not exhibit problems with the port numbers. After starting TERM, press the key combination ALT-P: this will open the parameter-menu. The following settings will work for TFPCX: V24-COMx: 5 Handshake: S Protect Time: 0 (without BREAK) It is possible to receive #BIN# files with this version of TFPCX. Proceed as follows (tested with TERM v9.98): - Switch off character echoing by using the 'E0' command. This version off TFPCX will always run in 8 bit mode (transparent) so the command '@M' is not longer supported. - start the BIN reception using key combination ALT-U and answer the questions (read command as last). - restore character echoing at the end of the transfer by means of the 'E1' command. For more information read the TERM documentation. 7.5. CT (K1EA) The contest program by K1EA also supports TFPCX (tested with CT v6.26). During CW-Contests you can only use KISS or a SCC Card because CT will otherwise have problems with the correct generation of morse code. The options '-DR' and '-IFF' are required when starting TFPCX. It also makes sense to set up the parameters in TFPCX using the '-F' option. In the first dialogue box, the item 'TNC' shall be set to 'Local' and when using a modem the 'Mode' should be set to 'SSB'. No adjustments are requiredi n the communications setup (CT will not access the modem-port itself). The command 'DRSI' should be entered in the QSO-screen, and then by using key combination ALT-T the TALK mode has to be selected, and ENTER has to be pressed once. Now you can connect to the DX-Cluster and using key combination ALT-A will display the DX-Information in the opened ANNOUNCE-Window. You will have to find out the rest for yourself. It is advisable to set CT up as Single Unlimited since the Single Operator setting will prohibit some options. 7.6. DIEBOX (DF3AV) You can use DIEBOX with TFPCX by using the TFPC-Interface. Of course you can hardly run a Box with only one simple modem, but this operation makes sense with a SCC-Card . You can also use the KISS mode to establish a direct connection to a digipeater (e.g. RMNC), this setup will save a TNC. TFPCX should be started without the '-DR' option. I don't know whether or not the '-DM' option will work: you have to check this out yourself. It makes sense to increase the number of the channels (option '-CH') and the number of buffers (Option '-BU'). I can not give more information about the configuration of the DIEBOX software because I have not tested this myself. 7.7. WINPR (DG6BI) WINPR version 2.0 supports TFPCX via the TFPC- Interface. Since WINPR runs under Microsoft Windows it only works on a fast computer using a KISS TNC or a SCC-Card (see Section 7.10.). Multiport use is not supported by WINPR. The option '-DM' should not be used with WINPR. TFPCX should be loaded before Windows starts up, or started from the WINSTART.BAT file. Windows has to run in 386 Enhanced Mode. The File WINPR.INI requires the settings: Port = Com5 TfpcrInq = 253 7.8 TOP (DF8MT) The TOP documentation describes how to use TFPCX so I will stick to the items which are new. For multiport operation, TFPCX has to be started with the '-DX' option instead of '-DR' option/ Under TOP, the different TFPCX-ports are handled as separate TNCs, and each channel is directly allocated to a single port in sequence. That is why a connect command does not need a port-number. This may seem fine but up 'til now it did not work consistently, connect requests from ouside just used the lowest available channel with the correct MYCALL, regardless of the channels-to-port allocation in TOP. Using the command '@PO' (see section 8.2.) will fix this problem. Example: You want to use TFPCX with 2 ports and 20 channels with 10 channels on each port. In addition to the setup of TNC Configuration, you should enter the following INI-Command in TOPSET: @PO 00000000001111111111 In this case you should load TFPCX using the '-CH20' option because the default number of channels is only 10. 7.9 FBB (F6FBB) The F6FBB-BBS-Software supports both TFPC- (from v5.15) and DRSI- Interfaces. Since the DRSI multiport interface will be used in most cases, I will elaborate on that. For modem operation you need at least FBB v5.15 or better. TFPCX should be loaded with the '-DR' and '-IFF' options. If you need to support more than 10 channels, the '-CH' option is also required (see section 6.2.3.). When using 2 ports, the configuration file PORT.SYS will look as follows: # PORT.SYS for FBB 5.15 # #Ports TNCs 1 2 # #Com Interface Address (Hex0) Baud 7 4 0 4800 # #TNC NbCh Com MultCh Pacln Maxfr NbFwd MxBloc M/P-Fwd Mode Freq 1 5 7 0 230 2 1 10 00/60 UDYW 144.650 2 5 7 1 230 2 1 10 00/60 UDYW 438.458 TFPCX simulates 2 TNCs via a virtual COM-Port (COM7). Interface 4 means DRSI: the address and baudrate will be ignored, but these have to appear in the file. The sum of the number of ports allocated to the channels (NbCh) shall not be greater than the total number of available TFPCX channels (given with option -CH or otherwise 10). There is however only one INITTNC1.SYS or MAINT1.SYS file needed which will set all the needed parameters and port settings (see Section 8.1) for all ports. The 'P'-command in TFPCX cannot be used to set all parameters of a port simultaneusly like the DRSI-TNCTRS driver can. For more information refer to the FBB-Documentation. 7.10. MS-Windows 3.1x, OS/2 and others. When using a modem TFPCX requires a very low interrupt latency (see apendix 2) which can not be accomplished when running under Windows 3.x or IBM OS/2 2.0 (although there are a lot of people who find it hard not accept this fact). That is why TFPCX will generate an error message if an attempt is made to start TFPCX for modem use while running one of these systems. Operating an SCC-Card using these systems is possible. Actually,this works quite well when using 1200 baud under Windows. When using higher baud-rates runnig SCC cards will also cause problems. Running OS/2 will not work as well as running under Windows, but this was only tested during a short test. I have no idea how well a PAR96, PICPAR or YAM96 modem will work under these systems. KISS mode works in my setup on both systems up to at least 38400 baud without any problem. The COM ports are fully supported by Windows and OS/2 drivers, which is unfortunatly not the case for the SCC cards (which is of course reasonable). When using other multitasking systems you may find a similar behaviour. 8. Operation In this section the most important differences and extensions in TFPCX compared to the TNC-Firmware TF 2.7b. will be explained. 8.1. Multiport extensions. The most significant extension is without any doubt the option of using more than one port simultaneously, which enables control of multiple modems and tranceivers. If you only use one port you can skip this section and move ahead to next section. TFPCX-Firmware can manage up to 8 ports. I think that using them all will only occur in exceptional cases. The unused ports can be used for internal connects. This will enable you to check your CTEXT message without disturbing the Digi uplink (which seems to be a popular passtime with some people) A unique number (0-7) is assigned to each port. The assignment of those numbers follows the exact same order as the '-P' options which are given at the start of TFPCX. These port numbers are displayed by TFPCX in conjunction with link status reports, in the Monitor, and when using certain commands ('C', 'L' and 'S'), so you can associate the message with a specific port. This portnumber is only displayed if one of the options '-DR', '-DX' or '-DM' is used when starting TFPCX. Example: 1:fm DG0FT to DB0BLN ctl SABM+ 1:fm DB0BLN o DG0FT ctl UA- CONNECTED to 1:DB0BLN The exact format of the messages can be found in appendix 4.2. Where the portnumber is displayed on the screen depends on the type of message, and on the terminal program. Some firmware-commands (see section 8.2. and appendix 1.) are extended to accept a port number so you can set some parameters for one specific port or connect a station on one specific port. Command Format: :[Parameter] is a digit between 0 und 7, no space is allowed between the digit and the ':'. Example: C 1:DB0BLN T 2:15 If the port number is not specified for a command which normally needs a port number, either the port on which a channel just became active is used, or the port which is specified on monitor channel as unproto port is used. There are, however, hostmode terminal programs which do not send a command to the same channel as the channel from which the command was originated, and this will undermine correct port selection. Therefore, always specify the port number when in doubt. Most of the times the parameter settings are defined in the configuration files of the terminal program and have to be defined individually for each port. The file TFPCX.INI is an example of this and can, once the personal data has been set, be used directly to initialise the ports (Option '- F', Section 6.2.3.). Incoming connects are normally assigned to the first free channel which has an matching MYCALL setting, regardless of the port on which the connect was recieved. By using the command '@PO' (see Section 8.2.) a port can be assigned to use only specific channels. 8.2. Some special command characteristics. There are a number of commands - which all start by using the ESC-Key and which are executed by pressing (see Appendix 1.). The TF27b commands 'A', 'H', 'K', 'Z', '@F' and '@K' do not exist in TFPCX. The Parameters 'B', 'O', 'P', 'T', 'W', 'X', '@C', '@D', '@T2' and '@TA' are used separately for each port. The internal timer works with an accuracy of +/- 20 ms or +/- 60 ms if KISS or the OptoPcScc-Card without timer port is used. This could be important for some parameters . For TXTAIL (Command '@TA') this inaccuracy is automatically taken into account. The individual commands: C Connect When using multiple connects to the same station with the selected SSID already in use, the SSID will be incremented automatically (up to a maximum of 15). The terminal program may not be aware of this and may show the wrong SSID. You can specify a port number when using the C command. If not specified, the number will be sought in the Link-List (see '@L') or the Unproto port is used if the search fails. If the channel is allocated to a port by means of the '@PO' command, that port will act as default port for that channel. On the monitor channel you can select the Unproto port by specifying a port number, the UI frames will be transmitted (Default port 0) on this port. Examples: C 1:DB0BLN Connect DB0BLN on Port 1 C 2:TEST \ Monitor-Channel Set Unproto-Port to 2 and set Unproto-ID C 2: / Set only Unproto-Port to 2 F Frack The FRACK-parameter can set in seconds or alternatively in 10ms units. Values 0 to 15 are considered to be given in seconds and are converted internally to the new 10 ms units. O MAXFRAME MAXFRAME be set individually for each Port and each connection. At connect time, the value specified for the port will used for the connection and can be changed independently from other connections on the same port. P P-Persistence Under DAMA-operation the non-DAMA-Value will be displayed, but actually P=255 will be used . If the indicated parameter has a value between 0 and 7 (Portnumber) the P-Value will not be set but instead some parameters of the indicated port will be displayed using the following format: R P W F O N @T2 @T3 T @D This had to be built-in to keep TFPCX compatible with the DRSI-TNCTSR driver when it is used by SP. is the configured baudrate in readable text formal, not like TNCTSR which uses a designated number. The DRSI-driver also uses this command to set the P-parameter, this will not in work TFPCX. TFPCX will ignore the entire command if additional values are given following the port number. QRES Reset QRES simply resets TFPCX back into Terminalmode (like 'JHOST0') and does not RESET the computer. This command is needed because SP uses it when the DRSI-Command 'HB' is executed. U Unattended Mode (CTEXT) This comamnd is mainly important when using TFPCX in terminal mode. With setting 'U0' link-status messages are sent out immediately, even if another channel is active at that moment. With setting 'U1' these messages kept and only displayed when the appropriate channel becomes active by means of the 'S' command. This setting will also cause a readable text to be send back when someone connects from outside. The default setting 'U2' behaves almost the same as setting 'U1', but additionally it allows disconnection of a connected station by means of the remote command '//Q' (or '//q'). This command has to appear at the start of a frame (otherwise it will not be handled). You can also switch unattended mode on if no CTEXT has been defined. The only effect of this command in host mode this the handling of the connect text (CTEXT). @C DCD-Working TFPCX has a Soft-DCD (software squelch). When using slow tranceivers (slow meaning a slow squelch cirquit) you can leave the squelch of the receiver fully open. TFPCX will determine for itself whether or not a packet signal is being received. The Soft-DCD can be controlled by means of the '@C' command, the given parameter controlls the noise-cancelling level. This parameter can be a number between 0 and 63. When using '@C0' the Soft-DCD is switched off (default)- all other values activate the Soft-DCD. The lower the value the more unstable and faster the Soft-DCD becomes, the higher the value, the more stable and slower it becomes. The ideal DCD should be both stable and fast. Therefore the best setting will good compromise between the two extremes. To simplify the job of finding the right value you can use the DCD indicator (see option '-C'). When using a small value you will see the unstable DCD indication, when using a large value you will see slow and inaccurate recognition of signals. The best way to set this correctly is to slowly increase the parameter value while listening to the signals on the PR QRG, until the indication is correct. A good start value is '@C25'. When using SCC, PAR96 or PICPAR ports an adjustment is not really needed, all values above 0 will activate the Soft-DCD and they all have the same meaning for the operational software. I was, however, annoyed by the constant flickering of the indicator, so you can still adjust the value to reduce the flicker. For the YAM96 modem the @C command will not work at all since it always uses a hardware DCD. IMPORTANT! The soft-DCD only recognises PR-Signals at the same baud rate. You can _not_ use the soft-DCD on packet QRGs which carry PR signals at different baud-rates. When using KISS, the TNC handles the DCD, and this command only defines the time (in 10ms-Units) after which the RX indication will be removed from the screen if no further data was received from the TNC. When you are connected to a DAMA station the DCD will be ignored for the used port. The DAMA station will regulate the traffic and will ensure a free QRG when it sends a DAMA-poll to you, so TFPCX doesn't need to double-check this. The advantage is a very fast response from TFPCX, which makes the DAMA handling better. This was introduced with TheFirmware TF2.7b, and is also used in TF2.7b based TNCs. @L Link List Using this command an internal link-list is managed which is used to allocate up to 8 calls (with SSID) to a specific port. The list is used for the digipeating function ('R' command) to select the port on which the recieved frame should be re-transmitted. If there is no appropriate entry in the link-list, the frame will be re-transmitted to the same port as where it was recieved from. Syntax: @L : : ... Example: @L 0:DB0BLN 1:DB0BLO Using '@L-' will clear the link list. The contents of the list will be displayed using '@L' without any parameters. For crossband-digipeating both source and destination calls have to be present in the link list, otherwise the connection will only work correctly in one direction. @PO By using this command you can define for each channel if it can be used for all ports, only for a specific port or if it cannot be used by any port. If a channel is set-up to use one specific port, this port will also be used as the default port if a 'C' command is given on this channel. As parameter a string is passed. The first character belongs to channel 1, the second to channel 2 and so on. When using 10 channels the string will normally consist of 10 characters. When a lower number of characters are given the allocation of remaining channels are not changed. When more characters are given the extra characters are ignored. The following character can appear in the parameter string: '0' to '7' Connect only possible from one port (Port Number) '*' Connect possible from all ports '-' No connect from outside possible Examples: @PO 0000011111*****----- Channels 1 to 5 can only be accessed from outside though port 0, channels 6 to 18 only through port 1. Channels 11 to 15 are accessible by every port when someone connects from outside and channels 16 to 20 are not accessible from outside at all and can only be used for outgoing connections. @PO ********** All channels can be accesed from all ports: this is the default setting and is compatible with earlier TFPCX versions. Incomming connects are assigned to the lowest free channel to which the port is allowed to connect (the channel either has been assigned to this port or can be connected by all ports ('*')) and on which an appropriate MYCALL is present. If there is no appropriate channel available the connection will be refused (BUSY). @ST Statistics By using 'ST :' some statistical values will be displayed for the given port. These values are gathered for all connects on this port. Be aware that the counters will wrap to 0 after reaching 65535. Example: 0 SCC0 TX 87 11 10 RX 547 201 201 ERR 1 ^ ^ ^ ^ ^ ^ ^ ^ ^ 1)2) 3) 4) 5) 6) 7) 8) 9) 1) portnumber 2) interface port ('NULL', for internal Port) 3) total number of transmitted frames 4) number of I-frames sent 5) number of acknowledged I-frames ( 4)-5) are lost ) 6) total number of received frames 7) number of received I-frames 8) number of effectivly received I-frames ( 7)-8) REJects ) 9) number of errors occurred (will be shown for SCC and KISS and only if it isn't 0) It is possible to do some statistical calculations and draw some conclusions by using these values . The interface port name 2) will have a '+' appended to the name if KISS is used and SMACK or RMNC-CRC-KISS is active. When using SCC cards value #9 shows the number of over- and underruns of the SCC controller, which will occur if the interrupts are not serviced fast enough. When using KISS the counter will be incremented each time a byte is lost or when a KISS frame or CRC error occurs (with SMACK or RMNC-CRC-KISS). When you notice a rapid increase of the number of errors your PC might be too slow for the used baudrate or, when using KISS, the connection to the TNC is not okay. You can clear the statistics by means of the '@ST :-' command (for the indicated port). @TA TXTAIL You can specify the TXTAIL value in 10ms units (0-6000) but this value is in normal cases (for the selected baudrate and timer inaccuracy) already set to the most optimal value (@TA=4 for 300 baud, @TA=1 otherwise). When using KISS the correct value depends on the used TNC, therefor there it is not set automaticly in this case. @U Unproto-Poll By using this command you can specify if unproto-frames should be sent with (Default) or without a set poll-bit. 8.3. KISS When using KISS there are some special things you'll need to know. We will elaborate on this in this section . Before you start TFPCX the TNC has to be switched on should have been set to KISS mode. TFPCX does not offer the option of putting the TNC into KISS mode. The TFPCR command @K does not exist in TFPCX. To set the TNC to KISS mode you can use the program SETKISS (which sould be in the package from which included TFPCX). TFPCX supports the KISS-enhancements SMACK (Version 1.0) and RMNC-CRC-KISS, which both improve the reliability of transfers between the TNC and the PC. SMACK or RMNC-CRC-KISS will be activated automatically if the connected TNC supports it. By using the command @ST (see section 8.2) you can check if one of these enhancements is activated (a '+' sign is shown if SMACK or RMNC-CRC-KISS is active e.g. 'COM1+'). SMACK or RMNC-CRC-KISS is only activated when least 1 Frame has been sent and received. With KISS, the Send-/Receive indicator does not show the send/receive status on the radio channel, but the send/receive status on the serial port to the TNC or to a connected other PC. To couple two PCs together (e.g. one running a digipeater and another running a mailbox) you need a null-Modem-Cable. When using this setup TFPCX always works in duplex mode (the command @D is meaningless). The parameters sould be setup accordingly. The following descriptions are mainly important for normal use with a TNC (no direct cable connection). In KISS-Mode, TFPCX has no direct control over the radio channel, because the TNC is in between. TFPCX has no possibility to detect whether or not the frequency is free and when the frames to be sent are actually transferred, which may lead to unwanted transmissions. Two situations are especially interesting. - Assume TFPCX has transferred one frame to the TNC for transmission and waits for an acknoledgement from the other station. It at that moment the radio link is occupied for some time by another station (for instance a Digi) the TNC will not be able to transmit the frame. After some time however TFPCX assumes the frame was lost and starts a retransmission, but in reality the original frame was not transmitted at all at that time. The result of this is an unwanted duplicate transmission of a frame. The time beween sending a frame and reception of the acknoledgement is measured by TFPCX and it will 'learn' how long on avarage TFPCX has to wait before receiving a response. This mechanism will adapt itself to the traffic on the readio channel and avoids the double transmissions. In TheFirmware 2.7b, the parameter @A3 (with which you could manipulate the delay in earlier TF versions) is fixed and cannot be adjusted anymore. - When more frames are received in a row, all these frames can normally be acknoledged with a single response frame. The question is, when can TFPCX assume no further frames will be sent so it can generate the single response frame? When using a serial modem or SCC Card, TFPCX can wait until the other station stops transmitting and the radio channel is free again. This method is not usable anymore when using KISS. The correct setting of parameter @T2 is very important ehen using KISS. @T2 specifies the time the receiver of the frame is going to wait before a response is generated. If a new frame is received during this time, the wait-time is starts all over again. The wait-time should only expire if no further frame is going to be received, so all received frames can be acknowledged using one response frame. If the wait-time specified with @T2 is too short then unneeded response frames will be send (wasting time and channel occupation). Which value should @T2 have? The wait-time should be just a little longer with respect to the transmit-time of one frame from the peer station. The following times are derived from the used baudrate and can be used a guideline: Baud @T2 1200 250 2400 150 (Default) 4800 100 9600 50 These times are valid when using 256 data-bytes in a frame and are a bit on the high side. If you want to experiment with this value you should watch the monitor to see if sequentially recieved frames are acknowledged with only one RR-frame. It is probably acceptable if more RR-frames are sent occasionally. IMPORTANT The default-value @T2=150 is too short to use for 1200 baud. You should certainly use a larger delay setting for @T2 if you use 1200 baud. The value @T4, to be used as @T2 with DAMA, which was present in previous versions of TFPCX, does not exist anymore. For DAMA @T2 is not needed at all since the response can be generated as soon as the DAMA station polls for a response (result of the new TF2.7b firmware used in TFPCX). 8.4. DAMA As soon as a connection is established to a DAMA-master (digipeater, box or bbs), TFPCX will only transmit if it receives a frame from the master with the request to respond. TFPCX will send all pending transmit-frames for all channels which are using the same port as the port on which de DAMA connection exists. The DAMA-slave mode is only activated on the port which carries the connection to the master. The connections using other ports will run normally without DAMA. When a connection to another DAMA master exists using another port it will handle the channels using that port independently from the DAMA connection on the other port (i.e. for DAMA all the ports are independent of each other). You don't need to change any parameter setting for DAMA. This will enable you to use the same port also for non-DAMA connections. By looking at the monitor you can see '[DAMA]' appended to the frames from the DAMA master. If the frames are sent to you, TFPCX will also have switched to DAMA. The 'B' command which existed in previous versions of TFPCX does not exist anymore (TF2.7b uses this command for another purpose). This version of TFPCX changed to the DAMA handling of TF2.7b. This means TFPCX now supports the latest version of the DAMA protocol. All previous versions of TFPCX did not. In fact this was one of the major reasons to upgrade TFPCX to the latest TheFirmware version. This also means the layer 1 DCD is ignored when connected to a DAMA master. The DAMA master ensures a free QRG so there is no need to double-check it. This will ensure a fast response on a DAMA request. This solution may lead to problems for KISS however, since TFPCX does not control the DCD in the KISS TNC. If the KISS TNC has a good DCD it should work anyway because the QRG is clear after being polled by the DAMA-master. Appendices 1. Overview of Commands Command Parameter Description ------ --------- ------------ * C Call ... Connect-route Connect on channel 0 sets port and name and name for unproto messages D Disconnect E(1) 0 No echo of input characters 1 Echo input characters F (250) 1-15 Start value for T1 (in seconds) 16-65535 Start value for SRTT (10ms) G [0] Obtain information in hostmode [1] Obtain status in hostmode I Call Set own call sign JHOST (0) 0 Change to terminal-mode 1 Change to hostmode K 0 No timestamp 1 Timestamp on status messages 2 Timestamp on status and monitor messages hh:mm:ss Set TNC time dd.mm.yy Set TNC date (european style) mm/dd/yy Set TND date (american style) L [0-10] Status display of a channel, if no channel given, displays all channels M (N) NIUSC+- Monitor-Operation Type N (20) 0-127 Number of Tries (0 = unlimited) * O (2) 1-7 Maximum number of unacknowledged packets allowed * P (32) 0-7 Parameter request for a port 8-255 P-Persistence value for non-DAMA QRES Reset into terminal-mode R (1) 0 Digipeater function off 1 Digipeater function on S (0) 0-10 Select channel (number, 0 = unproto) * T (25) 0-127 Time between PTT on and frame start (10ms) U (2) 0 Suppress connect text 1 [Text] Connect text active 2 [Text] Connect text and remote-//Quit active V Display TF version string * W (10) 0-127 Time slot for P-Persistence (10ms) Ignored for DAMA * X (1) 0 PTT switching off, TX suppressed 1 PTT switching on, TX allowed Y (10) 0-10 Maximum number of connections @B Shows number of free buffers * @C (0) 0 Software-DCD off 1-63 Threshold value for software-DCD * @D (0) 0 Full duplex off 1 Full duplex on @I (80) 0 IPOLL off 1-256 maximum Length of an IPOLL-Frame @L Port:Call ... Linklist setup (max. 8 Entries) '-' Linklist clear @PO ('*') cccccccccc Port assignment (each channel one character) c = '0'-'7' Connect only possible from port c '*' Connect from all ports possible '-' No connect from external stations possible @S Current link state * @ST Status indicator per Port '-' Reset status counters * @T2 (150) 0-65535 Timer T2 (10ms) @T3 (30000) 0-65535 Timer T3 (10ms) * @TA (1/4) 0-65535 Time between frame end until PTT off (10ms) @U (1) 0 Unproto-frames without Poll 1 Unproto-frames with Poll @V (0) 0 Call sign check switched off 1 Call sign check switched on * Parameter : possible [] optional Parameter () Standard installation ... additional Parameters possible A lot of these commands can be used without parameters to display the current setting for the command. 2. Error Remedies (Modem Operation) When you have a problem you should first find out what could have caused it. Besides TFPCX, it could be caused by the Terminal program, the modem, the SCC Card, DRSI, PAR96/PICPAR or YAM96 modem, or the tranceiver. This section focuses mainly on use with a modem. TFPCX demands more from your PC compared to the use of a normal TNC. When your PC cannot live up to this demand you will be in trouble. To understand this I will explain how TFPCX works when sending and receiving. When using packet radio the information is transmitted using a synchronous serial link. The PC's serial port can, when used in the normal way, only transmit asynchronous serial information using start and stop-bits which do not exist with packet radio. The serial port can therefore not be used in the normal way. This means TFPCX has to handle each and every bit itself: the serial port is only used as a simple latch which can store only one bit. To enable TFPCX to handle the data in a predefined speed of, for example, 1200 bits/s it needs a accurate clock. To transmit the clock has to delever 1200 ticks/s. The method used to receive data needs a clock which can deliver 3600 ticks/s which makes it possible to constantly synchronise on the recieved signal. TFPCX uses a software PLL. The modem RX line is sampled 3 times per bit to detect if the RX line changed from a logical 1 to 0 or 0 to 1. In the ideal situation such a change should only occur on every third sample. Due to inaccuracies the timing drifts away with respect to the sender. Since three samples are taken per bit the direction of the drift can be detected and compensated. As accurate clock I used the PC's internal timer which is present in any PC and is normally used for the date/time in DOS. TFPCX re-programs the timer to supply an timer-interrupt 3600 times per second. The interrupt handler (the so called Interrupt Service Routine, ISR) will take control over the CPU and suspend what ever was executing at that moment and will call the functions which take care of sending and recieving. It is inevitable this can only work correctly if all the interrupts are handled in a steady repetition and without too much delay. This will be a problem when running Windows or OS/2, that's the reason why it does not work right when using these systems. If you compare the load on the PC caused by TFPCX compared to a TNC, TFPCX will cause a 30 times higher load when using the same baudrate, using 1200 baud it can be compared with a 36000 baud TNC on your PC, which gives problems on a lot of slow PCs. Luckily enough for us,PCs are getting faster and faster, so this has become a less of a problem over the years. The timing inaccuracies are causing most problems nowadays when TFPCX doesn't run under plain DOS. This is still a big difference between using TFPCX or using a TNC. 2.1. Send- and Receive Problems The used PC should in the first place be capable of handling the large number of interrupts. When your PC is not able to handle this it will run very slowly, or your PC will lock-up or crash. From experience the following table may used as a guideline (without guarantee): PC XT XT 286 386 MHz 5 8 12 20 Baud 300 * * * * 1200 ? ? * * 2400 - ? * * 4800 - - ? * * Operation possible ? Operation probably possible (with Limitations) - Operation impossible As you see, a modern PC with at least a 486 or Pentium processor should not cause any problems with processing speed any more. There are, however, also problems with PCs which are in principle fast enough. Most of the time the installation suffers from unstable reception, which leads to many REJects, which in turn will result in many retransmissions. This is in most of the cases caused by some residential program, driver or additional hardware which delay the interrupts handling too long. When the timer interrupt handling is delayed for more than 200s during the reception of a frame the whole frame will be lost (even if it occurs only once). When you experience these kind of problems you could start TFPCX using the '-D' option. When you hear interruptions of the tone you hear from the PC speaker, you experience this problem. Common sources of problems: - Usage of Extended (XMS) or Expanded Memory (EMS) as buffer for the terminal program (e.g. SP, GP) and disk-caches (especially on a 286 PC) To avoid this you should prevent usage of this RAM as long as TFPCX is used. When using SP you should not use SPO.EXE and XMS-Swapping ('SWP=1' in CONFIG.SP). GP should be started with the option '/NOXMS'. - A driver, which enables resident programs to be loaded in high memory (e.g. EMM386) If the previous solution did not work for you, you could disable the whole EMM386 driver while using TFPCX. - Slow Keyboard-Driver (KEYB) If frames are always lost when a key is pressed you could try another keyboard driver (like CKEYGR.COM from the SP-Disk). - VGA-cards and HD-controllers Many VGA-Card disable interrupts for some time when running in graphic mode. I also heard there are HD controllers which give the same kind of problem. When the controller was removed everthing worked again. It is a problem for me to give a general solution for this. You could try a program which does not run in graphic mode. - Running under Windows Although you can not start TFPCX in a DOS session under Windows for use with a serial modem, you can start TFPCX in DOS before starting windows. Some people have reported this works for them, but most users will get nothing but trouble using this setup. Windows will delay the timer interrupts to much to make a reliable connection. The only solution is to quit using TFPCX this way. Sometimes you have to live with a compromise to use TFPCX. If you are not willing to accept this then TFPCX is not the right way to go. If you wonder why TFPCX stopped working all of a sudden you have to question if you loaded a new driver or changed anything else in the setup of your PC. Something I do NOT want is somebody using TFPCX on a Digi QRG with a setup which only receives a frame correctly after 3 retries each time. 2.2. Problems with other Programs While TFPCX is active you should not run programs which use the PC timer which is in use by TFPCX. If you do your system may crash, run extremly slowly, or the DOS clock will not run correctly anymore. Among these programs are: - MS-Word 5.0 and 5.5 - EDIT in MS-DOS 5.0 - MS-Windows - many Mouse Drivers Using the following programs also gave problems, the exact cause is unknown: - Keyboard driver from DR-DOS 6.0 (keyboard hangup), use another drivers (e.g. CKEYGR.COM, which was distributed with SP). - Microsoft mouse driver (MOUSE.COM). Cure: use another driver - IBM VCPI.SYS-Driver (used in notebooks), removal of the driver might solve the problem 2.3. Hardware Problems There are PCs (especially Laptops), which do not have 100% compatible serial ports. The demands on the ports are not so high as for BayCom, when the deviations are too big it can also cause problem with TFPCX on these computers. In many cases receiving works buy sending does not. Up till now I received some reports of this for the following computers: - Toshiba 1000XE - NEC Multispeed - Olivetti M24 TFPCX offers the posibility to use the modem on the LPT port, which might be an option to bypass the problem. Most laptops and notebooks have build-in Power Management to save (battery) power. When the keyboard is not pressed for some time Power Management may reduce de processor speed, which may reduce the processing power for TFPCX below a usable level. When using this kind of PCs (e.g. Olivetti Quaderndo) it is often required to deactivate the Power Management (especially the reduction of the processor speed). If your PC has enough power even with reduced processor speed you can try to leave it enabled. 3. Hardware Connections 3.1. Serial Modems BayCom-compatible modems can be used without changes. In rare cases there could be problems which are caused by the more stable supply of power to the modem in TFPCX compared BayCom. In TFPCX the TXD line remains steady at approximately +12V, the BayCom solution has a pulse signal on this control line. Therefore the supplied voltage to the modem is a little higher, the voltage on pin 7 of the TCM3105 may not have the ideal voltage anymore. In this case a re-adjustment of the voltage on pin 7 is required (see modem documentation). Tip: this voltage is also very important for the correct functioning of the software DCD, you can use the Soft DCD indicator to adjust the voltage. Additionally there is a option of connecting the modem (e.g. from DigiCom) to a LPT-Port. When using this, 6 data output lines are switched to a stable 5V which could be used as voltage supply to the modem (Use at your own risk) Here are the connections for the Modem-Ports COM-Port Signal 25pol. 9pol. Meaning DTR 20 4 Transmit data +/- 12V RTS 4 7 PTT, High active, -12V=RX, +12V=TX CTS 5 8 Receive data GND 7 5 Signal ground TXD 2 3 +12V for BayCom-Modem LPT-Port Signal 25pol. Meaning DATA1-6 2-7 constant 5V approx. for Modem DATA7 8 Transmit data, TTL-Level DATA8 9 PTT, High active, 0V=RX, 5V=TX BUSY 11 Receive data GND 18-25 Signal ground Modems using the AM7911 can also be used. You may have to increase the TXTAIL-parameter (command @TA) a little for this. At this point I like to point out you need different modems for higher baudrates. 3.2. BayCom-USCC-Card The connections needed for the USCC card can be found in its documentation. Here I will only supply the numbering given to the ports and the default setting of the modem clock supply and baudrate: Port SCC Modem-Clock Baud Modem SCC0 1A Softclock 1200 AFSK (TCM3105) SCC1 1B Softclock 1200 AFSK (AM7911) SCC2 2A Disable 9600 External SCC3 2B DF9IC-Modem 9600 FSK (DF9IC) The second SCC controller (Z8530) does not have to be present when the appropriate channels are not used, the first controller is mandatory. Therefore you can also use the 9k6 USCC card (option -PUSCC:::31). The following table shows the exact clock source for receive (RxC) and transmit (TxC) and also the used encoding mode. The column contains the number to be supplied with the -PUSCC option, the last column shows the equivalent values for the BayCom parameters CARRIER and HENNING. Soft-DCD and Duplex-Operation can be switched on by means of the commands @C and @D. -P RxC TxC Mode CARRIER HENNING 1 Softclock DPLL BRG NRZI 0/1 0 2 Hardclock DPLL RTxC NRZI 2-4 0 3 DF9IC-Modem TRxC RTxC NRZ 1-4 1 BRG Baud rate generator \ embedded inside the DPLL Digital PLL / SCC-Controller RTxC \ Connections of the TRxC / SCC-Controller It looks like some USCC cards have timing problems in accessing the data port of the SCC-controller. In TFPCX v2.00 sometimes nonsense was transmitted because of this. After lowering the bus-clock and exchange of the SCC contollers by original ZILOG types this problem could be partly eliminated. TFPCX does not send the transmit data via the data port anymore, just like BayCom does it. I hope this problem is now of something of the past. 3.3. BayCom PAR96 and PICPAR modem You can use the PAR96 and PICPAR modem with TFPCX (since version 2.21). There are some things to note: The PAR96 and PICPAR modem are connected to one of the LPT ports. TFPCX assumes a normal LPT port is present. On modern PC's this can be an EPP port (Enhanced Printer Port). TFPCX assumes this port is set as if it is a normal LPT port at startup. If not TFPCX might fail to communicate with the modem (I do not have information how to setup the EPP port as normal printer port so I can't do it). There is a particulair problem with the PICPAR modem. The power to the PICPAR modem is supplied by the LPT port. If the modem is not powered at the start of TFPCX, the initialisation by TFPCX is finished before the power on the PICPAR is stable. The communication to the modem completely fails in that case. A way to solve it seems to be lowering the value of the capacitors on the power line or to switch over to an external power supply. You must specify the correct IRQ at startup: the default IRQ is 7. If you attempt to use the wrong IRQ, the communication to the modem will also fail. 3.4. YAM96 modem You can use the YAM96 modem with TFPCX (since version 2.71). There are some things to note: Before you can use the YAM96 modem you have to download the software into the FPGA by means of the YAMINIT program you got with the modem. If this is not done before TFPCX starts, TFPCX will give an error message. The YAM96 modem is connected to one of the COM ports. TFPCX assumes a normal COM port is present. When no port address is given TFPCX tries to retrieve this address from the BIOS area. When using COM ports 3 or 4 this port address maybe invalid. In that case you have to specify these values yourself. You must specify the correct IRQ at startup: the default IRQ is 4 when using COM1 or COM3, 3 when using COM2 or COM4. If you attempt to use the wrong IRQ, the communication to the modem will fail. Also be aware not to use COM1 and COM3 or COM2 and COM4 at the same time. If your mouse is connected to COM1 you should not use COM3 for example. You can use this combination however if COM3 is assigned to another IRQ (so in fact there should be only one active COM-port using the IRQ at the same time). 4. Information for Software Developers 4.1. Program-Interface The communication with TFPCX is done using a software-interrupt. There are several sub-functions which are selected by the value in register AH. Parameters are passed in the AL register when needed. On return register AX will hold the result or 0xFFFF when an unknown sub-function was selected. All input characters have to be read before the output can be send again. TFPCX supports 2 different interfaces which only differ slightly. 4.1.1. TFPC-Interface Sub functions: AH = 1 Check, whether a character is available on the input Returns : AX = 0 No character available on the input AX = 1 Character available on the input AH = 2 Character input (call only if sub function 1 reported the availability of a character on the input) Returns: AL Character code AH = 3 Output a character Parameter: AL Character to output Three bytes behind the entry of the TFPCX interrupt routine a recognition string 'N5NX' is available, which can be used to find out which interrupt is used by TFPCX. 4.1.2. DRSI-Interface The implementation in TFPCX is derrived from SP because I didn't have a description or a TNCTSR driver myself. Therefore I could only find out the functions used in conjunction with SP. It is possible that this interface deviates from the original TNCTSR deiver. Sub functions: AH = 0 Input of a character Returns : AH = 0 No character available on input AH = 1 Character available on input AL Character code (only if AH = 1) AH = 1 Output a character Parameter: AL Character to output The Interrupt-Routine starts with the following Bytes: 0x53 0x1E 0xBB 0x?? 0x?? 0x8E 0xDB 0x84 0xE4 0x74 0x20 You can find out which interrupt is used by TFPCX by comparing the start of the interrupt routines for vectors 0x40 till 0xff with the byte sequence above. The byes noted as 0x?? can have value and should be skipped in the comparison. This method also works with the DRSI-TNCTSR driver and is also used by SP. 4.1.3. Special Functions The following sub functions are extensions which only exist in TFPCX. They are available for both interface methods mentions above. AH = 0xFB Request number of Ports and Channels (from v2.00) Returns: AL Number of used ports (0 to 8) AH Number of available Channels (4 to40) The number of channel is defined by the option '-CH' AH = 0xFC Request the send-/receive status (from v2.00) Returns: AL Receive status (Bit-Nr. = Port) AH Send status By using this functions a send/recieve indicator can be build in the terminal program. The option '-C' only works in text-mode and the location is fixed (which may not be the optimal place for it in the terminal program). For every port uses one bit of AL and AH. Bit 0 (LSB) belongs to Port 0, Bit 1 to Port 1 and so on. Something is recieved (DCD) or send on the port if the respective bit is set. During duplex-operation both bits can be set at the same time. The Function 0xFB returns the number of ports, which should be indicated. AH = 0xFD Request TFPCX busy status (from v1.11b) Returns: AX = 0 Busy (free Buffer < 88) AX = 1 not Busy This sub function enables the implementation of a send handshake in the terminal mode. AH = 0xFE Request for the TFPCX-Version (from v1.01) Returns: AH = 2 Main Version Number AL = 0 Lower Version Number (no BCD) This sub function makes it possible to make a destinction between TFPCX and TFPCR (delivers AX = 0xFFFF) or DRSI-TNCTSR (delivered in a test AX = 0). You should test whether 1<=AH<=20 is true and only in that case conclude it is TFPCX. In addition you can use this sub function to check if an old TFPCX version is used which does not support a certain function. 4.2. Format of Reports In this section the messages of TFPCX are presented which deviate from the TNC-Firmware. Most deviations are just the addition of a port number to the message. Another deviation has to do with the display of FlexNet frames. is a digit between 0 and 7. The : part is only displayed if TFPCX is started with the option '-DR', '-DX' or '-DM'. The monitor messages with '-DR' are kept compatible to the DRSI-TNCTSR driver. - Link-Status BUSY fm : via CONNECTED to : via LINK RESET fm : via LINK RESET to : via DISCONNECTED fm : via LINK FAILURE with : via FRAME REJECT fm : via (x y z) FRAME REJECT to : via (x y z) - Monitor (with options '-DX' and '-DM') :CONNECT REQUEST fm via :fm to via ctl pid - Monitor (with options '-DR' and TNCTSR) :CONNECT REQUEST fm via : fm to via ctl pid ^ extra space character - Response of the 'C' command if used without a parameter : via - Monitor output when receiving FlexNet frames with header compression Format of the Monitor-header: :fm # to ctl ... :fm to ctl SABM+ # :fm to ctl UA- # = FlexNet QSO number 4.3. Extended Host-Mode The extended hostmode (DG3DBI) is a compatible extension to the 'G'- command, which it enables, using a global query-command, to gather information about all channels of the firmware on which data is pending to be read next. The use of the extended host mode is an inprovement, especially if you are using many channels with very different data traffic loads: the exchange of data between TFPCX and the terminal program will be improved. The global query uses the 'G' command on virtual channel 255 (byte sequence: 0xFF 0x01 0x00 'G'). Parameters supplied with this command are ignored. TFPCX will respond with a 0 terminated list of all channels, which have buffered data (byte sequence: 0xFF 0x01 channel+1 ... 0x00). Channel+1 ... is a row of channel numbers which are increased by 1. Example: The channels 0 (monitor channel), 1 and 5 have data pending. TFPCX responds with: 0xFF 0x01 0x01 0x02 0x86 0x00 The terminal program should use this response to read the data from the indicated channels until all data is read. When all channels are empty the response 0xFF 0x01 0x00 will be given on the extended hostmode command. On the first global query you should check, if the error message "INVALID CHANNEL NUMBER" is generated, which will always be the case if the extended hostmode is not yet supported by the used firmware. 4.4. Previous Versions Since v1.00 the following alterations have been implemented. v1.01 - Pointer about unread information by means of the flashing square if not in hostmode (can be switched off by -NB) - Baseaddress of the modem-ports can set explicitly now - TxD-line on the modem-port (power supply to modem) kept fixed to +12V and switched off when unloading - Default TFPCX interrupt now 0xFD (previously 0xFE) - Version information via TFPCX interrupt (AH = 0xFE) v1.10 - Transition to TheFirmware v2.3b DAMA (previously TF v2.1c) - Soft-DCD (Configure with command @C) - Send-/receive indicator in hostmode (can be switched off by -NC) - Delay of disk-access during send/receive as intermediate solution in case of problems (-ND) build in - Automatic increase of the SSID with connect if the same station is already connected - Internal connects possible - Setting of Frack in 1s- or 10ms-units (command F) - Unattended mode can be switched on without CTEXT, Error report 'NO MESSAGE AVAILABLE' removed (Command U) - 600 Buffer (previously 400) - Bug cleared, which makes unloading impossible with 486's v1.11 - Command Z available again (XON/XOFF for TERM) - LPT-Pins DATA1-6 switched to 5V for modem powersupply v1.11b (unofficial) - Function for Send-handshake in the terminal mode via TFPCX- interrupt for TERM (AH = 0xFD) v2.00 - Support for BayCom-USCC card and a maximum of 2 modems (maximum 6 ports, internal 8 ports) - Options -PUSCC and -B extended for USCC-cards and more ports - Option -NC removed, the DCD-Indicator can be switched on by -C[xx] (optional screen attribute xx) - Now 20 channels (previously 10) - Emulation of the DRSI-TNCTSR-driver, additional software- interface (-DR) - With option -DM DRSI-compatible reports, but via old software- interface - Output of port numbers in reports - Parameter B, O, P, T, W, X, @C, @D, @T2, @T4 and @TA are separated for each port (specification :) - Command QRES resets TFPCX to terminal mode - Linklist for crossband-digipeating (command @L) - Statistic-Framecounter (command @ST) - Adjustable TXTAIL-parameter (Command @TA) - Command P with parameter 0-7 compatible with DRSI parameter request (no parameter setting) - Command Z removed again - 'dynamic' MAXFRAME removed (command O) - Error report during modem-operation under Microsoft-Windows (386 Enhanced Mode) - Functions for the retrieval of the numbero of ports/channels (AH = 0xFB) and of the send-/receive status (AH = 0xFC) via the software-interrupt - Bugs solved, which lead to buffer overflows during background use and from time to time to reduntant transmissions. v2.01 - USCC-Sendproblems solved, through output of the transmit data via control-port (timing-problems on the data port on a few USCC-Cards) - Option -BU[nnnn] for the setting of the buffer size (minimum 400, default 600), -BU without parameters will allocate the maximum number of buffers. - The number of connect-channels selectable with option -CHnn (4-40 channels, default 10) - Command E (Echo) back again (default 1, echo on) - Command @M for #BIN#-Receive, @M=0 Conversion of control-characters (Standard), @M=1 transport-mode (for TERM) - Init-File (Option -F) may contain empty lines and comments (by using '#' or ';'), ESC automatically created ('^' will be ignored), conversion of TABs to a space character. - Remote-Command '//Q' (when U=1 and JHOST=0) - Frames will be monitored, if more than 256 Buffers are Free (previously 64 Buffers) - Error reports on an attempt to operate a modem under OS/2 2.0 - DRSI-Function 1 (character output) returns AH=0 (for compatibility with the TNCTSR-Driver, which reports in AH, whether characters are pending for input) v2.10 - KISS-Mode (incl. SMACK) supported (option -PKISS, max. 4 ports) - Support for PA0HZP-OptoPcScc-Card (option -POSCC), clock Type 4 (PA0HZP-Port with external Clock) and 5 (PA0HZP-Timer for 75 Hz timing-reference) - Baycom-9K6-USCC-card support (2nd SCC-Controller not activated, if not equipped) - IRQs for SCC and KISS: 2-5/7, for AT additionally: 9-12/14-15 (2=9) - Reports (monitor and CONNECT REQUEST) changed for the DRSI-Interface (Option -DR) (incompatibilities with the TNCTSR-driver eliminated), new option -DX for previous modified reports. - Command @PO for selective port allocation (channel can be connected only from the allocated port, default-port for outgoing connects). - Internal connects (loopback) can be switched off (option -NL) - TXTAIL (@TA) for modem and SCC set to optimal value depending on the baud rate and timer-accuracy (@TA=4 with 300 Baud, @TA=1 otherwise), max. value for @TA is 6000 (255 for KISS) - 0 Ports, if -P not specified (No default-port anymore) - Option -D is applicable to the previous supplied option -P - With DAMA before polling also wait for expire of T1 (as TF 2.6) - Extended Host-Mode (DG3DBI) supported - Remote-Command '//Q' only with U=2 (Default) - @ST also clears the ERR-Counter - NET/ROM-Monitor removed - Default-Parameters F, N, P, R, T, U, @A3, @I, @T2, @T3, @T4 and @TA changed. v2.21 - BayCom-PAR96 modem support added - KISS now also supports RMNC-CRC-KISS - BayCom-Digi-SCC card support added (only ports 0 to 3). - The firmware-command K (Timestamp) can be used now. You have to supply the -ST option at startup to use it - The monitor will now show FlexNet frames with header compression. Command M +/- can be used. - When using KISS, BayCom-PAR96 and PA0HZP-OptoPcScc card the internal realtime clock is used for internal timers, this will result in a more exact time measurement (not under Windows) - The option -ND is removed. v2.70 - Other author of the software, taken over from Rene. - Replacement of TF23b with TF27b. This will give: - Improved DAMA handling: TFPCX can now be used on DAMA connections again. - Framesammler support. - TNC commands in line with TF27b, some commands are not available anymore like '@A3', 'B' and '@M' for example. - When connected to a DAMA master the DCD is now ignored like in TFX and TheFirmware 2.7b based TNCs (with the latest TF2.7b). - When using the -ST option on the commandline the DOS-Time will be used to intitaly set the clock in the TNC. This will give the real time to the timestamps (K command) - Everything I broke. This TFPCX just contains a small portion of the original TFPCX, I had to put all the enhancements into the TF27b code and may have overlooked something. - Changed licence condition. Due to use of TF27b code from NORD>