Vaughan Wesson, February 1998

Some of this I looked at when the SRC first started using modems on Kelunjis (i.e. 8 or 10 years ago) so it is a bit hazy. All these comments relate to a Kelunji Classic and not necessarily to a Kelunji D series.

1. Always set the Kelunji port speed faster than the modem line speed if possible. e.g. when using 9600 or 14.4K baud modems, set the Kelunji port speed to (at least) 19200 and when using 28.8K modems set the Kelunji port speed to 38400. The reason for this is that most modems have the option of providing some type of compression and can get more bits/second end to end than the line speed would indicate.
2. Always set the Mac port speed to some fairly high speed for the same reasons as in (1).
3. Set the modems up to use NO handshaking. Let the Kelunji and ZTerm/Mac340 perform their own end-to-end handshaking.
4. The Kelunji Classic does not perform any hardware handshaking, so only the basic three wires are absolutely required. The others may be required for the modem or so that the Kelunji Modem LED operates as expected.
5. The cable from the Mac to a modem should include the hardware handshaking lines for talking to other things, but they are NOT required when talking to a Kelunji.
6. File transfer speeds are limited to about 2,000 bytes/second (20,000 bits/second) by the Kelunji Classic. This obviously requires you to be running the Kelunji serial port at 38,400 baud.
7. Guria V4.11A significantly improved the speed of file transfers. This is covered in Tech Note TN199606A.

In general, a modem should have no problem displaying any of the Kelunji screens when using serial ports at higher speeds than the modem link speed. Some screens which output data as fast as possible such as the Inspect:Analog:Raw Data may cause some problems but you, as an intelligent human, usually ignore this :-)

However, a problem could arise when using the XMODEM protocol to transfer data. This is a very simple protocol which requires a transparent end-to-end link. This means that what you send from one end must arrive, in the same order, at the other end, no more and no less. Software handshaking using XON/XOFF is NOT a transparent link, additional XON and XOFF characters may be received by either end.

XMODEM transfers information in blocks. A block is sent from the Kelunji to the computer along with a block counter and either a checksum or a CRC. Once the computer receives the block it sends an acknowledgement. This "send a block" then "wait for acknowledgement" is the (only) handshaking used by XMODEM.

The XMODEM protocol defines two different block sizes: either 128 bytes or 1024 bytes. It also defines two different error checking methods: checksum or CRC. The 128 byte blocks may only use the checksum method while the 1024 byte blocks may use either. The implementation in the Kelunji only supports two combinations: 128 byte block with checksum; or 1024 byte block with CRC.

Most modern modems seem able to cope with buffering a complete 1024 byte block and sending this through to the other end correctly. These modems support file transfers using XMODEM protocol with either block size. Some older modems are not able to buffer a complete 1024 byte block and will only correctly transfer files using 128 byte blocks.

A Kelunji can be forced to use 128 byte blocks by a setting in your terminal emulator. For ZTerm, select the Settings:Transfer Options... menu item. Change the "X/YModem error checking:" setting from "Try CRC, fallback to Checksum" to "Use Checksum only".

Clear as mud.