From Newsgroup: comp.os.cpm

Hi all,

Posting this for a friend:

I'm turning to you people as I am at a loss with
regards to the following issue:

On rc2014bbs I use KMD to provide xmodem transfer
over the serial line (and, eventually via #wifimodem
over the internet).

This works as long as you either connect with another
rc2014 using #qterm or #imp or if you use a
Commodore64 using ccgms

But when you try to perform xmodem transfer from a
modern machine (PC, Mac - it doesn't matter) using a
modern terminal program (Syncterm, Qodem, TeraTerm,
lrzsz etc. - it doesn't matter) the transfer begins,
sending a few blocks and then gets into a NAK loop
and aborts due to the error count reaching max.

So, my question to the wise, collective fedimind is:
what can be the cause for such a behaviour? Timing
issues?! Old xmodem implementation within KMD?!
Some interference from the #Zimodem firmware?!

Any suggestions, comments etc. are welcome!

(from https://friends.chasmcity.net/display/54bda6fa-3e5a032788c0e74f-1e4f119d)

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

On 5/21/26 4:29 AM, Koen Martens wrote:

Hi all,

Posting this for a friend:

I'm turning to you people as I am at a loss with
regards to the following issue:

On rc2014bbs I use KMD to provide xmodem transfer
over the serial line (and, eventually via #wifimodem
over the internet).

This works as long as you either connect with another
rc2014 using #qterm or #imp or if you use a
Commodore64 using ccgms

But when you try to perform xmodem transfer from a
modern machine (PC, Mac - it doesn't matter) using a
modern terminal program (Syncterm, Qodem, TeraTerm,
lrzsz etc. - it doesn't matter) the transfer begins,
sending a few blocks and then gets into a NAK loop
and aborts due to the error count reaching max.

So, my question to the wise, collective fedimind is:
what can be the cause for such a behaviour? Timing
issues?! Old xmodem implementation within KMD?!
Some interference from the #Zimodem firmware?!

Any suggestions, comments etc. are welcome!

(from https://friends.chasmcity.net/display/54bda6fa-3e5a032788c0e74f-1e4f119d)

Cheers,

Koen

I don't think it's a modern/old thing.
I just transferred a file with KMD on an IMSAI 8080 to TerraTerm on a
Windows PC.

Note that TerraTerm has several options for type of transfer. I used
XMODEM in checksum mode. The other modes (CRC, 1K, etc.) don't work
with KMD (or at least the version I'm running).
-J
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

gmc@metro.cx (Koen Martens) wrote:

Hi all,

Posting this for a friend:

I'm turning to you people as I am at a loss with
regards to the following issue:

On rc2014bbs I use KMD to provide xmodem transfer
over the serial line (and, eventually via #wifimodem
over the internet).

This works as long as you either connect with another
rc2014 using #qterm or #imp or if you use a
Commodore64 using ccgms

But when you try to perform xmodem transfer from a
modern machine (PC, Mac - it doesn't matter) using a
modern terminal program (Syncterm, Qodem, TeraTerm,
lrzsz etc. - it doesn't matter) the transfer begins,
sending a few blocks and then gets into a NAK loop
and aborts due to the error count reaching max.

So, my question to the wise, collective fedimind is:
what can be the cause for such a behaviour? Timing
issues?! Old xmodem implementation within KMD?!
Some interference from the #Zimodem firmware?!

My guess would be that some buffer on the receiving end is getting
filled when using 1k blocks rather than 128-byte ones, and modern
terminal programs might generally be defaulting to using the newest XMODEM-related protocol the receiver supports, exposing the problem.
I'm not really familiar with KMD but it looks like "kmd rc foo" forces
XMODEM checksum mode from that end, which I think should also force
128-byte blocks. So that might be worth trying.

(What I like about this idea is the implication that, in a sense, the
XMODEM implementation in KMD is actually too *new*. :-))

-Rus.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.os.cpm

Russell Marks <zgedneil@spam^h^h^h^hgmail.com> wrote:

My guess would be that some buffer on the receiving end is getting
filled when using 1k blocks rather than 128-byte ones, and modern
terminal programs might generally be defaulting to using the newest XMODEM-related protocol the receiver supports, exposing the problem.
I'm not really familiar with KMD but it looks like "kmd rc foo" forces
XMODEM checksum mode from that end, which I think should also force
128-byte blocks. So that might be worth trying.

(What I like about this idea is the implication that, in a sense, the
XMODEM implementation in KMD is actually too *new*. :-))

Too bad, it had nothing to do with either the KMD program on the CP/M
system nor with the terminal program. Turned out that there was an
issue with buffering in zimodem, the firmware that the BBS used to
make an ESP8266 pretend it is a Hayes AT compatible modem.

Thanks all for your suggestions!

Cheers,

Koen
--
Software architecture & engineering: https://www.sonologic.se/
Sci-fi: https://www.koenmartens.nl/
Retrocomputing videos: https://retroscandinavian.eu/

--- Synchronet 3.22a-Linux NewsLink 1.2