home *** CD-ROM | disk | FTP | other *** search
- v9.00
-
- Changed the method we're using for registered versions of
- Tmodem. To many people did not understand how the DOS
- environoment worked and they were having trouble setting up
- the tmodem.key. The concept was a good one, but not suited to
- the casual computer user. It did make updates, getting
- registered versions, etc. easy but good ideas don't always
- pan out when you put them into real life situations.
-
- And the interrupts we had to take over to prevent debugs and
- stack tracers from decoding the keys were not always
- compatible with every set-up, about 5 percent of the systems
- could not run the DEMO.
-
- The method we're going to have to use is a bit limited, but
- much simplier for the end user. You'll get a cusomized
- Tmodem.exe with your name and serial number engrave in the
- program. You don't have to do anything extra to use it, just
- replace the demo tmodem with your copy.
-
- The limiting part is; You'll have to pay a 5 dollar upgrade
- fee if you want to get a newer version of Tmodem, unless the
- upgrade is a bug fix and our fault. If it is OUR fault, then
- the upgrade will be free.
-
- This means you'll need to examine what the new version has to
- offer and determine if you'll benefit from the upgrade.
-
- Outside of the changes listed above, there is no difference
- between 9.00 and 8.00.
-
- v8.00
-
- Added a small routine to switch to a different set of
- interrupts if the original interrupts are unstable, in a
- partially restore status, or for what ever reason, can not be
- successfully attached.
-
- A couple of programs, one is a semi-popular BBS program, does
- this on a couple of systems that use Tmodem.
-
- Because it only does it on a couple of systems while others
- using the same software experience no problems, it would seem
- that there is something else used in conjunction with those
- programs that may be causing the conflict.
-
- The key is loaded and attached to several interrupts so that
- it can be accessed via bios calls. If the interrupt is
- unstable or the key can not be attached, the program cannot
- function.
-
- One method you might used to tell if interrupts are being
- interfered with; Tmodem runs OK without the key, but can't
- run with the key. This is not the ONLY reason, wrong decoding
- password, environment full, and/or missing Tmodem.key can
- also cause the same thing so check those items if v8.00 does
- not function properly.
-
- This is about the best we can do in an attempt to fix that
- type of problem. To do anything else we would have to have
- the computer here and that isn't likely to happen.
-
- v8.00 should produce faster transfer, at 2400 baud, on noisy
- lines.
-
- v7.20
-
- Fixed a long standing bug in the file name compression
- routine. We don't know how long it has been there, but
- basically this is what it does.
-
- We compress the filename, something like that you might do
- with pkzip or arj. However, if a full 12 character filename
- was used, the 12th character would not ALWAYS decompress
- correctly, which is why it took so long to find.
-
- Since fixing the bug means changing the header block
- compression and decompression routines, you will not be able
- to transfer files with versions of Tmodem prior to 7.20.
-
- Backwards compatibility could not be maintained because the
- header contains the remote callers version number and it is
- compressed, catch-22.
-
- Addition
-
- Tmodem will automatically engage RTS flow control if your
- connect rate is higher than 2400 baud and you get an error
- while receiving a file. If it has to engage RTS, you will get
- a window in the screen informing you of the problem. You
- should add /F to the command line.
-
- The window does say it is not possible to get an error with
- an REL connect. This isn't ALWAYS true but it is close enough
- to make an educated guess that your attempting to run
- highspeeds without a 16550 or you have something hogging
- interrupt time; DV, Network, etc.
-
- The fix is to add /F to the command line until you can add a
- 16550, if you don't have one, and if that is the problem.
-
- We added this for one reason, people were not reading the
- documentation, which DOES explains all of this.
-
- v7.10
-
- Added some more debug information on the last line of the
- screen and an additional command line switch.
-
- Command Line Switch: /Lxxxxxx.
-
- /L is the serial LOCK rate and xxxxxx is the speed you are
- locking the serial port at. This was added so those having
- problems setting the COMx= can use an alternate method of
- passing the lock rate.
-
- E.g., /L38400 (Locked at 38400 baud)
-
- Debug Info . . .
-
- At the bottom of the screen, you'll find 4 windows; Uart
- Rate, Connect Rate, Serial Port, and Flow Control.
-
- Uart Rate:
-
- This reflects the speed of the Uart or Serial port. This is
- based on what YOU tell Tmodem the speed is with COMx=, /L, or
- /B switch(es).
-
- If you have a standard modem; 300, 1200, 2400 baud, the Uart
- Rate should be the same as the connect rate. If it isn't, you
- are not passing the correct parameters.
-
- If you have a locked serial port, the Uart Rate should EQUAL
- the lock rate. If it doesn't, then you are not passing the
- correct parameters.
-
- The Connect rate is what you pass in the /B parameter and if
- you have a 300, 1200, or 2400 baud modem, the connect rate
- SHOULD match the Uart rate. If it doesn't, you are not
- passing the correct parameters.
-
- If you have a locked serial port, the connect rate should
- NEVER be the same as the Uart rate and it should never be
- higher than 9600 baud, the closest valid serial rate that any
- modem, to date, runs at. Keeping in mind that 12000 and 14400
- are not valid serial rates and can not be used in the /B
- parameter.
-
- If you have a locked serial port and connect with a 2400 baud
- system and your Connect rate shows 9600 or higher, you're not
- passing the correct connect rates and your transfers may not
- take place and if they do, they may be slowed down by phase
- shifting.
-
- Flow Control . . .
-
- This shows you the TYPE of flow control Tmodem is using. By
- default, it uses CTS (Hardware flow control).
-
- Under Tmodem, Xon/Xoff just isn't fast enough to handle the
- data flow.
-
- If you do not have a 16550 Uart and you are locked at 19200
- or 38400, you WILL be required to use the /F (RTS) command
- line switch. This slows down the transfer, a bit, but this is
- better than getting Uart RX overrun.
-