I'm troubleshooting a file transfer issue with sending files via XMODEM from a Linux system to a Z80-MBC2[1] CP/M system. The Z80-MBC2 is a great 8 MHz Z80 homebrew computer kit that can boot a number of operating systems, including CP/M 2.2 and CP/M 3.0.

On the Z80-MBC2, under CP/M 3.0 I execute the command XMODEM TEST.TXT /R. Then, on the Linux side, from a Minicom session I initiate a file transfer and select the TEST.TXT file. Minicom shows these status messages, nothing happens, and the file is not
transferred:

Xmodem sectors/kbytes sent: 0/ 0k
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
Retry 0: Timeout on sector ACK
...

However, I can successfully transfer to the board very short files, e.g. a few tens of bytes. Transferring files from the board to Linux works fine.

XMODEM TEST.TXT /X0 /R doesn't help, as well as changing Minicom's XMODEM send command to sx -B 128 -vv.

Although the Z80-MBC2 requires a recent firmware version to make XMODEM transfers to the Z80 board work[2], I have the right version and the issue may be unrelated. I'm also reasonably sure it's not something hardware related, as I got a professionally
assembled and tested Z80-MBC2 unit.

Any insight, advice, or troubleshooting steps to suggest?

Some more details on my setup. The Z80-MBC2 is connected via serial USB (115200 bps, 8N1, no hardware flow control; only 115200 bps supported) to an i7 ASUS Chromebox 3. I control the Z80 from the Minicom terminal emulator under Crostini, which is the
Linux container of chromeOS.


[1] https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer [2] https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer/log/160375-new-ios-for-xmodem-support

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

However, I can successfully transfer to the board very short files, e.g.
a few tens of bytes. Transferring files from the board to Linux works
fine.

You describe and illustrate a download to the MBC failing. Can you
describe the successful short file transfer that does work?

You might try the /C or /Q options, assuming this is MFE's XMODEM tool.

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Paolo Amoroso <paolo.amoroso@gmail.com> writes:

Minicom shows these status messages, nothing happens, and the file is
not transferred: [...] The Z80-MBC2 is connected via serial USB

Is it the same problem that's described here? https://www.mattkeeter.com/blog/2022-05-31-xmodem/

In that case, the author was using an FTDI USB-to-serial adaptor, and by default the driver batches up characters over a 16ms period to avoid
doing lots of short USB transfers -- which interacts badly with XMODEM's
use of single-character acknowledgements...

--
Adam Sampson <ats@offog.org> <http://offog.org/>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/21/22 11:15 AM, Paolo Amoroso wrote:

I'm troubleshooting a file transfer issue with sending files via XMODEM from a Linux system to a Z80-MBC2[1] CP/M system. The Z80-MBC2 is a great 8 MHz Z80 homebrew computer kit that can boot a number of operating systems, including CP/M 2.2 and CP/M 3.

0.

On the Z80-MBC2, under CP/M 3.0 I execute the command XMODEM TEST.TXT /R. Then, on the Linux side, from a Minicom session I initiate a file transfer and select the TEST.TXT file. Minicom shows these status messages, nothing happens, and the file is not

transferred:


It has been a long time since I used xmodem but I think you have this
sequence backwards. Or at least the example in the sz documentation
(used by minicom to do the transfer) does it this way:

XMODEM File Transfer (Unix to Crosstalk)
% sx -a foo.c
ESC
rx foo.c

The send side gets started before the receiver.


ZMODEM would probably work better over a USB to serial converter. I am
pretty sure I wouldn't try such a high baud rate to start with. Even on
a fast Z80.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks Dennis, Adam, and David for the feedback, much appreciated. I'll reply to each of you.

Dennis, I can no longer reproduce a successfull transfer, even for a file that worked earlier.

The XMODEM tool that comes with the Z80-MBC2 does support the /C and /Q options, but they don't help as I get the same timeout.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David, I may have the sequence backwards.

I start the receive side first because I don't know how to get back to the terminal prompt in Minicom to start the receive side on CP/M after starting the send. Pressing ESC does nothing, I still get Minicom's send dialog in the foreground with no way of
getting to the prompt other than pressing Ctrl+C, which interrupts the transfer. If I change Minicom's settings to run the sx program full screen, there's no way of getting to the terminal prompt either.

As for the baud rate, the board's developer says he can reliably transfer large files from Windows. Among the Z80-MBC2 users, the reported XMODEM issues seem mostly related to the old firmware version, which is not my case as I have the version that
supports full XMODEM transfers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dennis, I can no longer reproduce a successfull transfer, even for a
file that worked earlier.

Is this file text or binary?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It has been a long time since I used xmodem but I think you have this sequence backwards. Or at least the example in the sz documentation
(used by minicom to do the transfer) does it this way:

For transfers down to the board, this is backwards. Once you've
started the send on the local end, you have no further way to talk
to the board to start the receiver there.

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, June 22, 2022 at 4:17:38 PM UTC+2, Dennis Boone wrote:

Dennis, I can no longer reproduce a successfull transfer, even for a
file that worked earlier.

Is this file text or binary?

It's a 104 bytes text file, specifically an Intel HEX file.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, June 22, 2022 at 9:22:17 AM UTC-5, paolo....@gmail.com wrote:

On Wednesday, June 22, 2022 at 4:17:38 PM UTC+2, Dennis Boone wrote:

Dennis, I can no longer reproduce a successful transfer, even for a
file that worked earlier.

Is this file text or binary?

It's a 104 bytes text file, specifically an Intel HEX file.

When it's small text files being sent to CPM it is easiest to open ED with the desired file name then send the ascii file then save it in ED.

Randy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Thanks for the tip Randy. However, I'm seeking a solution that works with arbitrary size files.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I tried also turning on software flow control in Minicom and jumping to a shell from Minicom to execute sx -a test.txt, but still no joy with file transfers.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It's a 104 bytes text file, specifically an Intel HEX file.

If you add "-vv" to the sz command in minicom, do you get a log file
called /tmp/szlog (or maybe sxlog) after an attempted transfer?

You might also try calculating the checksum of the first block of the
file by hand to see what the checksum byte should be. Does it come out
to be 0x13?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, June 22, 2022 at 9:15:14 PM UTC+2, Dennis Boone wrote:

If you add "-vv" to the sz command in minicom, do you get a log file
called /tmp/szlog (or maybe sxlog) after an attempted transfer?

Yes, Minicom creates the minicom.log file in the current directory. Here's the entry of a successful transfer of the 104 bytes file greet.hex:

20220617 21:33:24 sx -vv greet.hex
20220617 21:33:24 Sending greet.hex, 0 blocks: Give your local XMODEM receive command now.
20220617 21:33:29 Bytes Sent: 128 BPS:27

Here's instead the entry of a failed transfer:

20220619 19:55:19 sx -vv te.hex
20220619 19:55:19 Sending te.hex, 353 blocks: Give your local XMODEM receive command now.

You might also try calculating the checksum of the first block of the
file by hand to see what the checksum byte should be. Does it come out
to be 0x13?

I'm not sure how to calculate the checksum. Is it one of the algorithms this CRC calculator provides? https://crccalc.com

Anyway, here's greet.hex in full, i.e. the successfully transferred 104 bytes file (by the way, it's an 8080 hello world demo in Intel HEX format):

:200100000E09110901CD0500C94772656574696E67732066726F6D205375697465383038CC :02012000302489
:00000001FF

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I was hoping the log could be made to show actual serial port traffic. Otherwise we're weighing stars through telescopes. Ah well.

I'm not sure how to calculate the checksum. Is it one of the algorithms this CRC calculator provides? https://crccalc.com

I believe it's a simple sum modulo 256.

Anyway, here's greet.hex in full, i.e. the successfully transferred 104 bytes file (by the way, it's an 8080 hello world demo in Intel HEX
format):

Any chance you're free to post the first couple hundred bytes worth
of the te file?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 23, 2022 at 3:46:12 AM UTC+2, Dennis Boone wrote:

I was hoping the log could be made to show actual serial port traffic.

Minicom runs sx -vv by default. I tried -vvvv but the only additional info it logs is pretty much only the file size.

Any chance you're free to post the first couple hundred bytes worth
of the te file?

te.hex is the HEX version of the te text editor by Miguel López. Here's the beginning of the file:

:200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA :200120000E09112B01CD0500C3000052756E74696D65204572726F72202D204E6F20737497 :2001400061636B24218100119501017F00EDB03A800006004F219501093600111702219402 :2001600001010100237EB72818FE2028F77D127C1312130C237EB72808FE2020F73600184D :20018000E3211502C5E5CDDB36000000C300000000000000000000000000000000000000F9 :2001A00000000000000000000000000000000000000000000000000000000000000000003F :2001C00000000000000000000000000000000000000000000000000000000000000000001F :2001E0000000000000000000000000000000000000000000000000000000000000000000FF :2002000000000000000000000000000000000000000000000049024902490249024902491E :2002200002490249024902490249024902490249024902490249024902490249024902490E :2002400002490249024902490200CD9C021803CDAD026E2600C9CD9C021803CDAD027E6F22 :20026000079F67C9CD9C021803CDAD027E23666FC9CD99021803CDAA02ED5B970273EBC963 :20028000CD99021803CDAA02ED5B9702732372EBC97D12137C12C90000229702D1E14E23EE :2002A0004623E5D52104000939C9229702D1E106004E23E5D52104000939C97DB36F7CB250 :2002C00067C97DAB6F7CAA67C97DA36F7CA267C97CB5B2B36FC97CB5C87AB3C0C31604B7DC

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Minicom runs sx -vv by default. I tried -vvvv but the only additional
info it logs is pretty much only the file size.

If you're familiar with the strace tool, it might be useful for getting
a look at the serial port traffic without getting into more involved
hardware setups. The recipe looks like this:

strace -s9999 -o /tmp/minicom.strace -eread,write,ioctl minicom

Attempt a failing transfer, then exit minicom. Now you should have a
file /tmp/minicom.strace full of a list of all of the syscalls that
minicom made while it was running. The beginning of the file will have
a large amount of activity done by image run-up, but toward then end we
ought to be able to find read and write calls on the serial port, and
the -s9999 part should mean we get all of the data that it attempted to
send, or did actually receive.

te.hex is the HEX version of the te text editor by Miguel López. Here's the beginning of the file:

I can't get a checksum of the presumed first packet of either of these
hex files to look like a problem, but perhaps I'm not doing it right.

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 23, 2022 at 8:45:58 PM UTC+2, Paolo Amoroso wrote:

I run the following command, where I added the Minicon configuration file with the Z80-MBC2 connection settings:

strace -s9999 -o /tmp/minicom.strace -eread,write,ioctl minicom z80mbc2

Actually, Minicom doesn't do the file transfer itself but runs the external program sx. So I changed Minicom's settings to execute the following command for sending files via XMODEM, omitting the -vv verbose option because it'd clutter the strace output
and wouldn't be of much help anyway:

strace -s9999 -o /tmp/sx.strace -eread,write,ioctl sx

Here's the file sx.strace in full:

read(4, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@n\2\0\0\0\0\0@\0\0\0\0\0\0\0p\2\34\0\0\0\0\0\0\0\0\0@\08\0\f\0@\0A\0@\0\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0\240\2\0\0\0\0\0\0\240\2\0\0\0\0\0\0\10\0\0\0\0\0\0\0\3\0\0\0\4\0\
0\0 ?\31\0\0\0\0\0 ?\31\0\0\0\0\0 ?\31\0\0\0\0\0\34\0\0\0\0\0\0\0\34\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\200I\2\0\0\0\0\0\200I\2\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\5\0\0\0\0P\2\0\0\0\0\0\0P\2\0\0\
0\0\0\0P\2\0\0\0\0\0\254\245\24\0\0\0\0\0\254\245\24\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\4\0\0\0\0\0\27\0\0\0\0\0\0\0\27\0\0\0\0\0\0\0\27\0\0\0\0\0\363\237\4\0\0\0\0\0\363\237\4\0\0\0\0\0\0\20\0\0\0\0\0\0\1\0\0\0\6\0\0\0\340\245\33\0\0\0\0\0\340\265\33\0\
0\0\0\0\340\265\33\0\0\0\0\0000P\0\0\0\0\0\0(\217\0\0\0\0\0\0\0\20\0\0\0\0\0\0\2\0\0\0\6\0\0\0\200\313\33\0\0\0\0\0\200\333\33\0\0\0\0\0\200\333\33\0\0\0\0\0\340\1\0\0\0\0\0\0\340\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\340\2\0\0\0\0\0\0\340\2\0\0\
0\0\0\0\340\2\0\0\0\0\0\0D\0\0\0\0\0\0\0D\0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0\340\245\33\0\0\0\0\0\340\265\33\0\0\0\0\0\340\265\33\0\0\0\0\0\20\0\0\0\0\0\0\0\220\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0<?\31\0\0\0\0\0<?\31\0\0\0\0\0<?\31\0\
0\0\0\0\264a\0\0\0\0\0\0\264a\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0R\345td\4\0\0\0\340\245\33\0\0\0\0\0\340\265\33\0\0\0\0\0\340\265\33\0\0\0\0\0 *\0\0\
0\0\0\0 *\0\0\0\0\0\0\1\0\0\0\0\0\0\0\4\0\0\0\24\0\0\0\3\0\0\0GNU\0.Z\274\356\224\363\274\276\327\273\240\224\363A\7\n%\205\242\272\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\3\0\0\0\2\0\0\0\0\0\0\0\0\0\0\0\371\3\0\0B\t\0\0\363\1\0\0:\3\0\0\4\t\0\0<\4\0\0",
832) = 832
ioctl(0, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
read(5, "# Locale name alias data base.\n# Copyright (C) 1996-2020 Free Software Foundation, Inc.\n#\n# This program is free software; you can redistribute it and/or modify\n# it under the terms of the GNU General Public License as published by\n# the
Free Software Foundation; either version 2, or (at your option)\n# any later version.\n#\n# This program is distributed in the hope that it will be useful,\n# but WITHOUT ANY WARRANTY; without even the implied warranty of\n# MERCHANTABILITY or FITNESS
FOR A PARTICULAR PURPOSE. See the\n# GNU General Public License for more details.\n#\n# You should have received a copy of the GNU General Public License\n# along with this program; if not, see <https://www.gnu.org/licenses/>.\n\n# The format of this
file is the same as for the corresponding file of\n# the X Window System, which normally can be found in\n#\t/usr/lib/X11/locale/locale.alias\n# A single line contains two fields: an alias and a substitution value.\n# All entries are case independent.\n\
n# Note: This file is obsolete and is kept around for the time being for\n# backward compatibility. Nobody should rely on the names defined here.\n# Locales should always be specified by their full name.\n\n# Note: This file used to contain the
following lines:\n#\tbokmaal\t\tnb_NO.ISO-8859-1\n#\tfranc,ais\tfr_FR.ISO-8859-1\n# except that the \"aa\" was actually the byte '\\0xE5' (the Latin-1\n# encoding for U+00E5 LATIN SMALL LETTER A WITH RING ABOVE) and the\n# \"c,\" was actually the byte '\\
xE7' (the Latin-1 encoding for U+00E7\n# LATIN SMALL LETTER C WITH CEDILLA). These lines were removed\n# because they caused 'locale -a' to output text encoded in Latin-1,\n# which broke applications in UTF-8 locales. See:\n# https://sourceware.org/
bugzilla/show_bug.cgi?id=18412\n\nbokmal\t\tnb_NO.ISO-8859-1\ncatalan\t\tca_ES.ISO-8859-1\ncroatian\thr_HR.ISO-8859-2\nczech\t\tcs_CZ.ISO-8859-2\ndanish da_DK.ISO-8859-1\ndansk\t\tda_DK.ISO-8859-1\ndeutsch\t\tde_DE.ISO-8859-1\ndutch\t\tnl_NL.ISO-
8859-1\neesti\t\tet_EE.ISO-8859-15\nestonian\tet_EE.ISO-8859-15\nfinnish fi_FI.ISO-8859-1\nfrench\t\tfr_FR.ISO-8859-1\ngalego\t\tgl_ES.ISO-8859-1\ngalician\tgl_ES.ISO-8859-1\ngerman\t\tde_DE.ISO-8859-1\ngreek el_GR.ISO-8859-7\nhebrew
he_IL.ISO-8859-8\nhrvatski\thr_HR.ISO-8859-2\nhungarian hu_HU.ISO-8859-2\nicelandic is_IS.ISO-8859-1\nitalian it_IT.ISO-8859-1\njapanese\tja_JP.eucJP\njapanese.euc\tja_JP.eucJP\nja_JP\t\tja_JP.eucJP\nja_JP.ujis\tja_JP.eucJP\
njapanese.sjis\tja_JP.SJIS\nkorean\t\tko_KR.eucKR\nkorean.euc \tko_KR.eucKR\nko_KR\t\tko_KR.eucKR\nlithuanian lt_LT.ISO-8859-13\nno_NO\t\tnb_NO.ISO-8859-1\nno_NO.ISO-8859-1 nb_NO.ISO-8859-1\nnorwegian nb_NO.ISO-8859-1\nnynorsk\t\tnn_NO.ISO-
8859-1\npolish pl_PL.ISO-8859-2\nportuguese pt_PT.ISO-8859-1\nromanian ro_RO.ISO-8859-2\nrussian ru_RU.KOI8-R\nslovak sk_SK.ISO-8859-2\nslovene sl_SI.ISO-8859-2\nslovenian sl_SI.ISO-8859-2\nspanish
es_ES.ISO-8859-1\nswedish sv_SE.ISO-8859-1\nthai\t\tth_TH.TIS-620\nturkish tr_TR.ISO-8859-9\n", 4096) = 2996
read(5, "", 4096) = 0
write(2, "Sending te.hex, 353 blocks: ", 28) = 28
write(2, "Give your local XMODEM receive command now.", 43) = 43
write(2, "\r\n", 2) = 2
read(0, 0x5bd9939fec60, 128) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
read(4, ":200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA\n:200120000E09112B01CD0500C3000052756E74696D652045727", 128) = 128
write(2, "\r", 1) = 1
write(2, "Xmodem sectors/kbytes sent: 0/ 0k", 35) = 35
write(1, "\1\1\376:200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA\n:200120000E09112B01CD0500C3000052756E74696D652045727\267", 132) = 132
read(0, 0x5bd9939fec60, 128) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
write(2, "Retry 0: ", 9) = 9
write(2, "Timeout on sector ACK", 21) = 21
write(2, "\n", 1) = 1
write(1, "\1\1\376:200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA\n:200120000E09112B01CD0500C3000052756E74696D652045727\267", 132) = 132
read(0, 0x5bd9939fec60, 128) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

On Thursday, June 23, 2022 at 5:06:14 PM UTC+2, Dennis Boone wrote:

strace -s9999 -o /tmp/minicom.strace -eread,write,ioctl minicom

I run the following command, where I added the Minicon configuration file with the Z80-MBC2 connection settings:

strace -s9999 -o /tmp/minicom.strace -eread,write,ioctl minicom z80mbc2

Here's the relevant part of minicom.strace when attempting to transfger the file te.hex:

write(1, "\33[2;1H\33[0m\33(B \33[3;1H
\33[4;1HZ80-MBC2 CPMLDR BIOS - S180918 \33[5;1H
\33[6;1HCP/M V3.0 Loader \33[7;1HCopyright
(C) 1982, Digital Research \33[8;1H \3
3[9;1H BNKBIOS3 SPR F600 0600 \33[10;1H BNKBIOS3 SPR 5300 2D00
\33[11;1H RESBDOS3 SPR F000 0600 \33[12;1H BNKBDOS3 SPR 2500 2E00
\33[13;1H \33[14;1H 60K TPA
\33[15;1H \33[16;1HZ80-MBC2 1
28KB (Banked) CP/M V3.0 \33[17;1HZ80-MBC2 BIOS Modules: S200918, S210918-R170319, S220918-R180319, S290918, \
33[18;1H S170319 \33[19;1H
\33[20;1HA>b: \33[21;1HB>a:xmodem te.hex /r
\33[23;3H", 1726) = 1726
write(1, "\33[?12l\33[?25h", 12) = 12
write(1, "\rFile created \33[24;32H", 88) = 88
write(4, "20220623 20:18:32 sx -vv te.hex\n", 32) = 32
write(1, "\33[5;5H+----------------------------------------------------------------------+\33[6;5H|
|\33[7;5H| |\33[8;5H|
|\33[9;5H| |\33[10;5H|
|\33[11;5H| |\33[12;5H|
|\33[13;5H+----------------------------------------------------------------------+\33[6;6H\33[?12l\33[?25h", 724) = 724
write(1, "\33[5;22H[xmodem upload - Press CTRL-C to quit]\33[6;6H", 51) = 51 ioctl(3, TCFLSH, TCIOFLUSH) = 0
ioctl(0, TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 opost isig icanon echo ...}) = 0 ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 -opost isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B38400 -opost isig -icanon -echo ...}) = 0
read(4, "Sending te.hex, 353 blocks: Give your local XMODEM receive command now.\r\n", 159) = 73
write(1, "Sending te.hex, 353 blocks: Give your local XMODEM receive command now\33[7;6H.\10\33[8;6H", 84) = 84
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
write(5, "20220623 20:18:32 Sending te.hex, 353 blocks: Give your local XMODEM receive command now.\n", 90) = 90
read(4, "\rXmodem sectors/kbytes sent: 0/ 0k", 159) = 36
write(1, "Xmodem sectors/kbytes sent: 0/ 0k", 35) = 35
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
read(4, "Retry 0: Timeout on sector ACK\n", 159) = 31
write(1, "Retry 0: Timeout on sector ACK\33[9;6H", 36) = 36
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
read(4, "Retry 0: Timeout on sector ACK\n", 159) = 31
write(1, "Retry 0: Timeout on sector ACK\33[10;6H", 37) = 37
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
read(4, 0x7ffdd0acb650, 159) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGINT {si_signo=SIGINT, si_code=SI_KERNEL} ---
read(4, "", 159) = 0
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=946, si_uid=1000, si_status=SIGKILL, si_utime=0, si_stime=0} ---
ioctl(0, TCGETS, {B38400 -opost isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B38400 -opost isig -icanon -echo ...}) = 0
ioctl(0, SNDCTL_TMR_STOP or TCSETSW, {B38400 -opost -isig -icanon -echo ...}) = 0
ioctl(0, TCGETS, {B38400 -opost -isig -icanon -echo ...}) = 0
write(5, " 944\n", 11) = 11
ioctl(3, TCFLSH, TCIOFLUSH) = 0
ioctl(3, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, TIOCMSET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3

write(1, "\1\1\376:200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA\n:200120000E09112B01CD0500C3000052756E74696D652045727\267", 132) = 132
read(0, 0x5bd9939fec60, 128) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
write(2, "Retry 0: ", 9) = 9
write(2, "Timeout on sector ACK", 21) = 21
write(2, "\n", 1) = 1
write(1, "\1\1\376:200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA\n:200120000E09112B01CD0500C3000052756E74696D652045727\267", 132) = 132
read(0, 0x5bd9939fec60, 128) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
write(2, "Retry 0: ", 9) = 9
write(2, "Timeout on sector ACK", 21) = 21
write(2, "\n", 1) = 1
write(1, "\1\1\376:200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA\n:200120000E09112B01CD0500C3000052756E74696D652045727\267", 132) = 132
read(0, 0x5bd9939fec60, 128) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)

So it never actually gets _anything_ back from the serial port. Wonder
if we're chasing something about how the file units are getting mapped,
rather than a transfer issue.

Does your Minicom setup for xmodem look like this (other than having
added the strace stuff to the command)?

C xmodem sx -vv Y U N Y N

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, June 24, 2022 at 6:29:34 PM UTC+2, Dennis Boone wrote:

So it never actually gets _anything_ back from the serial port. Wonder
if we're chasing something about how the file units are getting mapped, rather than a transfer issue.

That's interesting. Shouldn't this interfere also with CP/M -> Linux transfers, which instead work fine?

Does your Minicom setup for xmodem look like this (other than having
added the strace stuff to the command)?

C xmodem sx -vv Y U N Y N

Yes, this is the relevant entry of the Minicom settings:

C xmodem sx -vv Y U N Y N


I tried a couple more things. Given that I want to transfer text files, I run sx -a -vv but it still led to timeouts. Also, running XMODEM FILENAME.TXT /X2 /R on C/PM aborts like this:

File created
Receiving via direct I/O with CRCs
ABORT: Sync fail
Empty file deleted

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I tried also turning on software flow control in Minicom and jumping to
a shell from Minicom to execute sx -a test.txt, but still no joy with
file transfers.

What version of MFE's XMODEM are you using?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, June 25, 2022 at 12:17:47 PM UTC+2, Paolo Amoroso wrote:

On CP/M 3.0 I'm using version 2.7 patched by J4F, the Z80-MBC2 developer:

Here are the patches J4F applied to the XMODEM Assembly source:

; Z80-MBC2 patch by J4F
; Can run only with CP/M 3!!!
;
; (Search the string 'Z80-MBC2' to find changes)
; ...
CONSTMD equ 5ah ;Set CONST mode to 8 bit (Z80-MBC2 CP/M 3)
; ...
;---------------------------------------------------
;Set default CPU speed to 4MHZ if a Z80 is detected.
;(The user can later change this with /Z option) ;---------------------------------------------------
INIT:
; -----------------------------------
; Set the 8 bit CONST mode (Z80-MBC2)
; -----------------------------------
push psw
mvi a,CONSTMD
call GOBIOS
pop psw
;
; -----------------------------------
;
sub a ;test for 8080 or Z80
jpe IS8080
mvi a,4 ;Assume Z80s run 4 MHz
sta CPUMHZ
IS8080:
; ...
HLPEXT: call CILPRT ;print this message

; 123456789012345678901234567890123456789012345678901234567890123
db '=========================',CR,LF
db 'XMODEM '
db ((VERSION AND 0F00h)/256)+'0','.',(VERSION AND 0Fh) +'0'
db ' By M. Eberhard',CR,LF
db '=========================',CR,LF ; Z80-MBC2
db 'Z80-MBC2 (CP/M 3 only)',CR,LF
db 'patched ver. by J4F',CR,LF
; ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, June 25, 2022 at 4:36:21 AM UTC+2, Dennis Boone wrote:

What version of MFE's XMODEM are you using?

On CP/M 3.0 I'm using version 2.7 patched by J4F, the Z80-MBC2 developer:

=========================
XMODEM 2.7 By M. Eberhard
=========================
Z80-MBC2 (CP/M 3 only)
patched ver. by J4F
=========================

Since the Z80-MBC2 runs at 8 MHz I tried running XMODEM with option /Z8, but the maximum argument it accepts is 6 (no improvement though, still timeout):

a:xmodem te.hex /r /z8

Bad value in command line

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On CP/M 3.0 I'm using version 2.7 patched by J4F, the Z80-MBC2 developer:

Well, I don't see anything in the 2.9 change log comments that suggests
it would help here. A few other thoughts:

1. Anything clueful in dmesg?

2. Have you tried running the MBC2 at 4 MHz? Maybe with /Z4?

3. Have you tried the /Q option to XMODEM?

4. Do you have a different usb serial device to try?

I haven't had time to dig out my MBC2 yet, or I might be a bit more
useful here.

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, June 25, 2022 at 3:58:58 PM UTC+2, Dennis Boone wrote:

1. Anything clueful in dmesg?

No useful clues, just these basic entries:

[22559.559045] usb 1-1: new full-speed USB device number 3 using xhci_hcd [22559.758833] cp210x 1-1:1.0: cp210x converter detected
[22559.770263] usb 1-1: cp210x converter now attached to ttyUSB0

2. Have you tried running the MBC2 at 4 MHz? Maybe with /Z4?

I switched the board to 4 MHz via firmware and also run transfers with /Z4, same timeouts.

3. Have you tried the /Q option to XMODEM?

Running XMODEM with the /Q and /C options still causes timeouts.

4. Do you have a different usb serial device to try?

I don't have other USB serial devices. I plugged the board to a different USB port of the Chromebox and it wasn't even recognized. But that port is a bit tight and I tried only a few times, as I didn't want to damage the board's connector.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

So far I have no fix for the issue, but I've figured and tested an effective workaround: pasting a text file from Minicom to an ED session on CP/M, i.e. sending the contents of the file as if it would be typed in, then saving the file from ED. This
requires setting at least a 5 ms character transmit delay in Minicom's terminal settings (^A T F). It's slower than XMODEM, but still acceptable and sufficiently practical.

The workaround lets me send HEX files for transferring CP/M programs, uuencoded (or similar) files for other binary, non-excutable files.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, June 27, 2022 at 10:23:26 PM UTC+2, David Schultz wrote:

So a lower bit rate would be the first thing to try.

As far as I know the Z80-MBC2 supports only 115200 bps. When I tried 9600 bps I got garbage in Minicom, but it's worth trying again.

Looking at the link to the blog which talks about XMODEM support this
would seem to fit into that category of can't receive. It also mentions
that besides getting the new version of software you need to follow a special procedure to increase the receive buffer to 128 bytes.

My understanding is that special procedure is part of rebuilding the firmware and no further action is required. The board's developed assured me my unit has the latest, fixed XMODEM setup as confirmed by the boot message "IOS: Found extended serial Rx
buffer".

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/27/22 2:23 PM, Paolo Amoroso wrote:

So far I have no fix for the issue, but I've figured and tested an effective workaround: pasting a text file from Minicom to an ED session on CP/M, i.e. sending the contents of the file as if it would be typed in, then saving the file from ED. This

requires setting at least a 5 ms character transmit delay in Minicom's terminal settings (^A T F). It's slower than XMODEM, but still acceptable and sufficiently practical.

The workaround lets me send HEX files for transferring CP/M programs, uuencoded (or similar) files for other binary, non-excutable files.

Since you can successfully send a very short file with XMODEM but not a
longer one makes me suspect an inability to keep up with incoming data.
So a lower bit rate would be the first thing to try.

Looking at the link to the blog which talks about XMODEM support this
would seem to fit into that category of can't receive. It also mentions
that besides getting the new version of software you need to follow a
special procedure to increase the receive buffer to 128 bytes.

I suspect even that would fail if the XMODEM-1K variant were used.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Since you can successfully send a very short file with XMODEM but not a longer one makes me suspect an inability to keep up with incoming data.
So a lower bit rate would be the first thing to try.

Except that it seems not even the first packet gets through. If it was
related to keeping up, it ought to move at least one packet before
timing out.

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/27/22 10:07 PM, Dennis Boone wrote:

> Since you can successfully send a very short file with XMODEM but not a
> longer one makes me suspect an inability to keep up with incoming data.
> So a lower bit rate would be the first thing to try.

Except that it seems not even the first packet gets through. If it was related to keeping up, it ought to move at least one packet before
timing out.

De

No. With the XMODEM protocol, the transmitter waits for an ACK/NACK
after each packet. So any failure to keep up with incoming data will
manifest itself within a packet.


I dug up some version of the firmware which has comments about a fix to
allow XMODEM to work. This makes it mostly clear what is going on.

The ATMEGA is receiving the serial data and buffering it using the basic
code from the Arduino library. I hope that uses interrupts because if it doesn't there is no hope.

The main loop is just the ATMEGA fielding I/O requests from the Z80. It
appears to have the ability to stop the Z80 while that happens. So if
the serial receive isn't interrupt driven, it could drop characters
while this is going on.

With at least 128 bytes allocated for the serial buffer there should be
no problems with XMODEM. Assuming the Arduino firmware can walk and chew
gum.

Another complication would be on the XMODEM receive side. It is critical
that this code perform any disk I/O after it validates an incoming
packet but before it sends an ACK. Reverse that order and the sender
begins sending the next packet while the disk I/O is going on. Since
that is also simulated using the ATMEGA, that would cause trouble.
Arduino code isn't exactly real time friendly.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, June 27, 2022 at 10:23:26 PM UTC+2, David Schultz wrote:

So a lower bit rate would be the first thing to try.

I checked the board's documentation and did a few tests. My Z80-MBC2 unit, which runs the IOS firmware, works only at 115200 bps. Any other bit rate generates garbage in the terminal and the firmware has no settings or other ways of changing the bit rate.
Another build of the firmware, IOS Lite, is designed for Z80-MBC2 boards without the optional components (e.g. a microSD card reader) and supports 9600 bps.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Concerning the ability of the Z80-MBC2 to keep up with file transfers, the developer noted he can reliably transfer large files to CP/M via XMODEM, for example sending 200-500 Kb from Linux and Windows.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Except that it seems not even the first packet gets through. If it was related to keeping up, it ought to move at least one packet before
timing out.

No. With the XMODEM protocol, the transmitter waits for an ACK/NACK
after each packet. So any failure to keep up with incoming data will manifest itself within a packet.

Paolo has been able to move small files, and the board is known to
be able do large file transfers successfully. There's something else
going on here. Data-dependent weirdness? Something about Paolo's
USB serial dongle or Chromebook environment?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Call me crazy but at this point I would be working on repacking what to transfer into packets that work as is.

A lot of work into what sounds like a minor problem.

USB to serial adapters can be bought for just a few bucks from Amazon/ePay etc. Try a couple different adapters, I would also consider finding a different communication package that will work.

Try package from Chromebook to PC and PC to CPM so you have a general idea where the problem is.


Randy

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 30, 2022 at 4:03:52 PM UTC+2, Dennis Boone wrote:

Paolo has been able to move small files, and the board is known to
be able do large file transfers successfully. There's something else
going on here. Data-dependent weirdness? Something about Paolo's
USB serial dongle or Chromebook environment?

It's quite possible the issue is at the chromeOS/Crostini end, for example local buffering problems.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 30, 2022 at 5:06:19 PM UTC+2, Randy McLaughlin wrote:

USB to serial adapters can be bought for just a few bucks from Amazon/ePay etc. Try a couple different adapters, I would also consider finding a different communication package that will work.

Good idea, thanks.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/30/22 9:03 AM, Dennis Boone wrote:

> > Except that it seems not even the first packet gets through. If it was
> > related to keeping up, it ought to move at least one packet before
> > timing out.

> No. With the XMODEM protocol, the transmitter waits for an ACK/NACK
> after each packet. So any failure to keep up with incoming data will
> manifest itself within a packet.

Paolo has been able to move small files, and the board is known to
be able do large file transfers successfully. There's something else
going on here. Data-dependent weirdness? Something about Paolo's
USB serial dongle or Chromebook environment?

De

I looked at the source code for sz to find out that the default timeout
period used is 60 seconds. So there should be no problem at all with it
waiting long enough for a reply from the target.

So the problem would appear to be within the target. Somehow it is
getting confused and not responding. The simplest way for that to happen
is for it to drop characters.

Hopefully the channel is 8 bit clean or close enough to it. sz escapes
some characters including problematic things like XON and XOFF. Options
are provided to do more of course. "-e" escapes all control characters.

The command "sz -TT" is supposed to send all 256 8 bit codes as an aid
in figuring out which ones aren't making it through.



--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 30, 2022 at 5:06:19 PM UTC+2, Randy McLaughlin wrote:

USB to serial adapters can be bought for just a few bucks from Amazon/ePay etc. Try a couple different adapters, I would also consider finding a different communication package that will work.

I tried another terminal emulator, Picocom, but sending files still times out. However, both Minicom and Picocom run the external sx program for file transfers, so I should get a different XMODEM implementation.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 30, 2022 at 6:27:20 PM UTC+2, David Schultz wrote:

Hopefully the channel is 8 bit clean or close enough to it. sz escapes
some characters including problematic things like XON and XOFF. Options
are provided to do more of course. "-e" escapes all control characters.

The command "sz -TT" is supposed to send all 256 8 bit codes as an aid
in figuring out which ones aren't making it through.

I tried running sx with the options -e and -TT, still timeouts.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/30/22 1:07 PM, Paolo Amoroso wrote:

On Thursday, June 30, 2022 at 5:06:19 PM UTC+2, Randy McLaughlin wrote:

USB to serial adapters can be bought for just a few bucks from Amazon/ePay etc. Try a couple different adapters, I would also consider finding a different communication package that will work.

I tried another terminal emulator, Picocom, but sending files still times out. However, both Minicom and Picocom run the external sx program for file transfers, so I should get a different XMODEM implementation.

It is unlikely to be the XMODEM implementation on the sending side. What
have you done to check the receiver?

Since the sender is timing out waiting for an ACK, using a very long
timer, something is preventing the receiver from even sending a NACK.
What is that?


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday, June 30, 2022 at 10:40:44 PM UTC+2, David Schultz wrote:

It is unlikely to be the XMODEM implementation on the sending side. What
have you done to check the receiver?

On CP/M I'm using version 2.7 of Martin Eberhard's XMODEM implementation patched[1] for the Z80-MBC2. I'll try the unpatched version 2.9, which also comes with a program for testing the serial link.


[1] https://groups.google.com/g/comp.os.cpm/c/oFsZ6PcsCkM/m/egABUI4-AgAJ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, July 1, 2022 at 9:06:16 AM UTC+2, Paolo Amoroso wrote:

On CP/M I'm using version 2.7 of Martin Eberhard's XMODEM implementation patched[1] for the Z80-MBC2. I'll try the unpatched version 2.9, which also comes with a program for testing the serial link.

I tried both programs and XMODEM timed out. The first time I run the serial link testing program XMTERM, some interesting log messages whizzed by but I was unable to capture them. Subsequent runs displayed less useful and partly garbled messages such as:

xmterm greet.hex /r

========================
XMTERM 1.1 By M.Eberhard
========================

/In 8080 codet^G6##w######rI

Or like these:

xmterm greet.hex /r

========================
XMTERM 1.1 By M.Eberhard
========================

/H

Back to the drawing board, I'll run the program again and see what I come up with.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/1/22 1:59 PM, Paolo Amoroso wrote:

On Friday, July 1, 2022 at 9:06:16 AM UTC+2, Paolo Amoroso wrote:

On CP/M I'm using version 2.7 of Martin Eberhard's XMODEM implementation patched[1] for the Z80-MBC2. I'll try the unpatched version 2.9, which also comes with a program for testing the serial link.

I tried both programs and XMODEM timed out. The first time I run the serial link testing program XMTERM, some interesting log messages whizzed by but I was unable to capture them. Subsequent runs displayed less useful and partly garbled messages such

as:

xmterm greet.hex /r

========================
XMTERM 1.1 By M.Eberhard
========================

/In 8080 codet^G6##w######rI

I looked at the source for XMTERM and that is part of a usage message
printed just before exit. So it didn't like something. Perhaps in your configuration file.

Or maybe that you provided a file name that is useless to this program.
Which just echos characters. Which is going to be less than useful when
the XMODEM port is the same as the console.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I run XMTERM with various options but didn't get much output, for example:

xmterm test.hex /x1 /e /r

========================
XMTERM 1.1 By M.Eberhard
========================

But I got something interesting when running XMODEM like this on CP/M with greet.hex sent from Linux (I named it test.hex on CP/M):

xmodem test.hex /r

After the usual timeouts, in the Minicom file transfer dialog I got several lines of quickly scrolling messages and managed to capture only the last few ones:

+----------------[xmodem upload - Press CTRL-C to quit]----------------+
|Retry 0: Got 32 for sector ACK |
|Retry 0: NAK on sector |
|Retry 0: Retry Count Exceeded |
| |
|Transfer incomplete |
| |
| READY: press any key to continue...

I pressed a key and got this in the terminal window, which is likely leftover garbage:

743C13901011075637D560? B>0901CD0500C94772656574696E67732066726F6D205375697465383038CC 0901CD0500C94772656574696E67732066726F6D205375697465383038CC?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/2/22 8:29 AM, Paolo Amoroso wrote:

I run XMTERM with various options but didn't get much output, for example:

And you never will unless you use different serial ports for the console
and xmodem. The xmterm output is going back to sz. Which eats it looking
for a NAK or ACK. That and I am not sure it sends the XMODEM start
character that sz is waiting for. But I am not diving back into the
source code to find out.

I see that there is an add on serial card which you probably need to
get. The alternative is to write a special purpose xmodem receive
program that logs all of its messages somewhere besides the console
port. A disk file perhaps or maybe RAM.

As near as I can tell the xmodem program you are using is optimized for
space (as little as possible) and speed. It uses all of the TPA it can
for a buffer to minimize disk accesses. Useful for floppy drives, less
so for hard drives, and not at all for anything that doesn't have long
start up or seek times.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, July 2, 2022 at 5:26:33 PM UTC+2, David Schultz wrote:

And you never will unless you use different serial ports for the console
and xmodem. The xmterm output is going back to sz. Which eats it looking

Isn't the /X1 option I run XMTERM with supposed to take care of this?

I see that there is an add on serial card which you probably need to
get. The alternative is to write a special purpose xmodem receive

Do you mean the uCom[1] board? I'd probably also need some way of connecting the RS-232 port to the USB port of my Chromebox, but this would complicate the simplicity of the Z80-MBC2 setup and there may not be any guarantee XMODEM would work. If I can't
fix XMODEM, the workaround I described is acceptable for me and doesn't need additional hardware.


[1] https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer/log/164037-ucom-is-out

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/2/22 8:29 AM, Paolo Amoroso wrote:

I run XMTERM with various options but didn't get much output, for example:

XMTERM ignores a lot of options that make sense for XMODEM but it does
parse your XMODEM configuration file. Instead of trying to use sz to
send stuff to XMTERM, where sz will just eat the reply without you ever
seeing it, just use minicom.

As in start XMTERM (no options!) and then type stuff into minicom and
see what XMTERM echoes. Sending the termination character when you are done.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 7/2/22 11:53 AM, Paolo Amoroso wrote:

On Saturday, July 2, 2022 at 5:26:33 PM UTC+2, David Schultz wrote:

And you never will unless you use different serial ports for the console
and xmodem. The xmterm output is going back to sz. Which eats it looking

Isn't the /X1 option I run XMTERM with supposed to take care of this?

You still have just the one serial port and sz is on the other end.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 6/30/22 1:08 PM, Paolo Amoroso wrote:

I tried running sx with the options -e and -TT, still timeouts.

Have you ever used the quiet mode xmodem option? (/Q)

This prevents it from printing a progress character to the console and
looking for a ^C.

Not a good thing to mix in with the xmodem traffic.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

T24gU2F0dXJkYXksIEp1bHkgMiwgMjAyMiBhdCA2OjUyOjQwIFBNIFVUQysyLCBEYXZpZCBTY2h1 bHR6IHdyb3RlOgo+IEFzIGluIHN0YXJ0IFhNVEVSTSAobm8gb3B0aW9ucyEpIGFuZCB0aGVuIHR5 cGUgc3R1ZmYgaW50byBtaW5pY29tIGFuZCAKPiBzZWUgd2hhdCBYTVRFUk0gZWNob2VzLiBTZW5k aW5nIHRoZSB0ZXJtaW5hdGlvbiBjaGFyYWN0ZXIgd2hlbiB5b3UgYXJlIGRvbmUuCgpUaGFua3Ms IGl0IGxvb2tzIGxpa2UgSSBtaXN1bmRlcnN0b29kIGhvdyBYTVRFUk0gd29ya3MuIEkgdGhvdWdo dCBpdCB3YXMgYW4gaW5zdHJ1bWVudGVkIHZlcnNpb24gb2YgWE1PREVNIHRoYXQgZG9lcyBmaWxl IHRyYW5zZmVycyBhbmQgZGlzcGxheXMgYWRkaXRpb25hbCBkaWFnbm9zdGljIGluZm8uIEluc3Rl YWQsIEkgc2VlbSB0byB1bmRlcnN0YW5kIGl0J3MgYSB0ZXJtaW5hbC1saWtlIHByb2dyYW0gdGhh dCBlc3NlbnRpYWxseSBlY2hvZXMgdGhlIGlucHV0IHR5cGVkIGludGVyYWN0aXZlbHkuCgpSdW5u aW5nIFhNVEVSTSBvbiBDUC9NIHdpdGggbm8gYXJndW1lbnRzIGFuZCBubyBYTU9ERU0uQ0ZHIGRp c3BsYXlzIG9ubHkgdGhlIHNpZ25vbiBtZXNzYWdlOgoKPT09PT09PT09PT09PT09PT09PT09PT09 ClhNVEVSTSAxLjEgQnkgTS5FYmVyaGFyZAo9PT09PT09PT09PT09PT09PT09PT09PT0KCldoZW4g SSB0eXBlLCBub3RoaW5nIGhhcHBlbnMuIFByZXNzaW5nIF5aIG9yIF5DIGRvZXNuJ3QgZG8gYW55 dGhpbmcgZWl0aGVyLiBXaXRoIFhNT0RFTS5DRkcgY29udGFpbmluZyAvWDEgL0UgL1EsIHJ1bm5p bmcgWE1URVJNIHByb2R1Y2VzIG11bHRpcGxlIGNvcGllcyBvZiB0aGUgc2lnbm9uIG1lc3NhZ2Ug YW5kLCBhZ2FpbiwgdHlwaW5nIG9yIHByZXNzaW5nIF5aL15DIGRvZXMgbm90aGluZzoKCj09PT09 PT09PT09PT09PT09PT09PT09PQpYTVRFUk0gMS4xIEJ5IE0uRWJlcmhhcmQKPT09PT09PT09PT09 PT09PT09PT09PT09Cgo9PT09PT09PT09PT09PT09PT09PT09PT0KWE1URVJNIDEuMSBCeSBNLkVi ZXJoYXJkCj09PT09PT09PT09PT09PT09PT09PT09PQoKPT09PT09PT09PT09PT09PT09PT09PT09 ClhNVEVSTSAxLjEgQnkgTS5FYmVyaGFyZAo9PT09PT09PT09PT09PT09PT09PT09PT0KCj09PT09 PT09PT09PT09PT09PT09PT09PQpYTVRFUk0gMS4xIEJ5IE0uRWJlcmhhcmQKPT09PT09PT09PT09 PT09PT09PT09PT09Cgo9PT09PT09PT09PT09PT09PT09PT09PT0KWE1URVJNIDEuMSBCeSBNLkVi ZXJoYXJkCj09PT09PT09PT09PT09PT09PT09PT09PQoKPT09PT09PT09PT09PT09PT09PT09PT09 ClhNVEVSTSAxLjEgQnkgTS5FYmVyaGFyZAo9PT09PT09PT09PT09PT09PT09PT09PT0KCkluIGFu b3RoZXIgcG9zdCB5b3UgbWVudGlvbmVkIHF1aWV0IG1vZGUuIEkgdHJpZWQgaXQgYXQgYm90aCBl bmRzIG9mIGEgZmlsZSB0cmFuc2ZlciwgWE1PREVNIC9YMSAvUSAvUiBvbiBDUC9NIGFuZCBzeCAt cSBvbiBMaW51eCwgYnV0IHN0aWxsIGdvdCBhIHRpbWVvdXQu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I continued experimenting with the Z80-MBC2 and XMODEM.

In addition to Crostini Linux, recent versions of chromeOS support accessing USB serial devices also from Android apps[1], but file transfers freeze like on Linux with the only such terminal emulator that supports XMODEM. On chromeOS it's now possible to
control serial USB devices also from web apps[2], but I haven't found any web terminal emulators with an XMODEM transfer feature.

Interestingly, the direct upload to the Z80-MBC2 of executable files in Intel HEX format does work, but requires tweaking the communication parameters[3].


[1] https://journal.paoloamoroso.com/controlling-the-z80-mbc2-from-android-on-chromeos
[2] https://journal.paoloamoroso.com/controlling-the-z80-mbc2-from-the-web
[3] https://journal.paoloamoroso.com/testing-hex-file-upload-to-the-z80-mbc2

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hard to do xmodem file transfer at 115200 with 8MHz Z80 without hardware handshake. So do you have hardware handshake enabled?
Bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bill, the Z80-MBC2 developer recommends not enabling hardware handshake as the board presumably doesn't support it, but it's worth giving it a shot.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bare minimal CP/M BIOS is needed to support XMODEM at 115200 without handshake with 8MHz Z80 so I was curious how Z80-MBC2 does it. According to this post in Hackaday, it is done with bigger receive buffer in Arduino MightyCore. So I don't think the
problem is in CP/M XMODEM software, but in the ATMega serial emulation. https://hackaday.io/project/159973-z80-mbc2-a-4-ics-homebrew-z80-computer/log/160375-new-ios-for-xmodem-support

Bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/5/22 7:25 PM, Bill Shen wrote:

Hard to do xmodem file transfer at 115200 with 8MHz Z80 without hardware handshake. So do you have hardware handshake enabled?
Bill

That board uses an ATMEGA part to do a lot of things including emulating hardware devices like the serial port. It has a buffer for received data
and its size can be selected at compile time. I don't think it even
tries for flow control in its firmware.


It has been a while since this thread was active but as I recall the
buffer size for this particular version is large enough to hold an
XMODEM packet. The data, not any overhead like escaped characters. (128
bytes) Assuming it can dribble out data to the Z80 (over a parallel
interface) while receiving it, that shouldn't be a problem.

If it can manage that, there should be no more data arriving until the
receiver sends an ACK.

But there is that little detail of using a single serial link for both
control and data.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, September 6, 2022 at 2:25:14 AM UTC+2, Bill Shen wrote:

Hard to do xmodem file transfer at 115200 with 8MHz Z80 without hardware handshake. So do you have hardware handshake enabled?

Enabling hardware handshake hangs the terminal session and software handshake changes nothing in XMODEM transfers. The Z80-MBC2 developer recommends no handshake because, as he notes, the board's Arduino-derived chipset doesn't support hardware flow
control.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, September 11, 2022 at 9:18:39 AM UTC-4, paolo....@gmail.com wrote:

On Tuesday, September 6, 2022 at 2:25:14 AM UTC+2, Bill Shen wrote:

Hard to do xmodem file transfer at 115200 with 8MHz Z80 without hardware handshake. So do you have hardware handshake enabled?

Enabling hardware handshake hangs the terminal session and software handshake changes nothing in XMODEM transfers. The Z80-MBC2 developer recommends no handshake because, as he notes, the board's Arduino-derived chipset doesn't support hardware flow

control.

I'm having a similar problem on a different target. XModem/CRC works great from Windows using TeraTerm but fails immediately with sx on linux. An interesting thing that may point in the right direction is that at 9600bps, the transfer proceeds although
very slowly due to a retry between each packet (Retry 0: NAK on sector)...however the file does transfer. As you note, minicom and most other linux serial comms programs just call sx to do the transfer. Unfortunately, it looks like sx (lrzsz) is broken
for xmodem and has been for a very long time. Oddly there doesn't seem to be a replacement...it might be worth writing one.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Saturday, January 14, 2023 at 6:03:09 AM UTC+1, David Albert wrote:

I'm having a similar problem on a different target. XModem/CRC works great from Windows using TeraTerm but fails immediately with sx on linux. An interesting thing that may point in the right direction is that at 9600bps, the transfer proceeds although

very slowly due to a retry between each packet (Retry 0: NAK on sector)...however the file does transfer. As you note, minicom and most other linux serial comms programs just call sx to do the transfer. Unfortunately, it looks like sx (lrzsz) is broken
for xmodem and has been for a very long time. Oddly there doesn't seem to be a replacement...it might be worth writing one.

What device are you trying to transfer files to? A Z80-MBC2?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/13/23 11:03 PM, David Albert wrote:

Unfortunately, it
looks like sx (lrzsz) is broken for xmodem and has been for a very
long time. Oddly there doesn't seem to be a replacement...it might
be worth writing one.

From what I can see it hasn't been updated for a very long time yet
there is still a package for Fedora.

Before writing a replacement, it might be a better idea to figure out
what is wrong with the current version and fix it. I dug up something resembling the Linux source (https://github.com/UweOhse/lrzsz).
Comparing that to an ancient version I found on my old CP/M-68K disks
shows a lot has remained the same:

#define VERSION "sz 1.22 01-01-87"
#define PUBDIR "/usr/spool/uucppublic"

/*% cc -O -K -i -DCRCTABLE -DREADCHECK sz.c -lx -o sz; size sz

* sz.c By Chuck Forsberg
*
* cc -O sz.c -o sz USG (SYS III/V) Unix
* cc -O -DSVR2 sz.c -o sz Sys V Release 2 with
non-blocking input
* Define to allow reverse channel checking
* cc -O -DV7 sz.c -o sz Unix Version 7, 2.8 - 4.3 BSD
*

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday, January 13, 2023 at 9:03:09 PM UTC-8, David Albert wrote: .....<snip>.....

As you note, minicom and most other linux serial comms programs just call sx to do the transfer.
Unfortunately, it looks like sx (lrzsz) is broken for xmodem and has been for a very long time.
Oddly there doesn't seem to be a replacement...it might be worth writing one.

Hmmmm.... Interesting. I use the xmodem transfer protocol in minicom all the time, and it works very well.

I'm running (primarily) SuSE Linux, but also use Slackware. Never had any problems with it.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/13/23 11:03 PM, David Albert wrote:

I'm having a similar problem on a different target. XModem/CRC works great from Windows using TeraTerm but fails immediately with sx on linux. An interesting thing that may point in the right direction is that at 9600bps, the transfer proceeds

although very slowly due to a retry between each packet (Retry 0: NAK on sector)

Reading that old lrzsz code is frustrating. I hate it when code is
poorly commented. Or almost not at all.

The XMODEM protocol mostly resides in the function wcputsec(). (Why that
name?) Dead simple and nothing that can go wrong. It sends data and
waits for an ACK.

But it was written when serial ports were serial ports. So makes some assumptions. One of which is that the target is not echoing what it
receives. If a special character (ACK, NAK, CAN, etc.) appears in the
data, it will upset things. This is where TeraTerm could differ. But
given all the buffering that goes on (kernel, USB to serial, etc.) I can
think of no easy way to compensate for a target that echoes everything
it receives.

A CP/M target can be a problem if the data passes through the BDOS
console I/O routines.

The precise reason why the target sent a NAK would be helpful. Timeout?
bad checksum/CRC?

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sunday, 15 January 2023 at 15:39:33 UTC, David Schultz wrote:

On 1/13/23 11:03 PM, David Albert wrote:

I'm having a similar problem on a different target. XModem/CRC works great from Windows using TeraTerm but fails immediately with sx on linux. An interesting thing that may point in the right direction is that at 9600bps, the transfer proceeds

although very slowly due to a retry between each packet (Retry 0: NAK on sector)

Reading that old lrzsz code is frustrating. I hate it when code is
poorly commented. Or almost not at all.

The XMODEM protocol mostly resides in the function wcputsec(). (Why that name?) Dead simple and nothing that can go wrong. It sends data and
waits for an ACK.

But it was written when serial ports were serial ports. So makes some assumptions. One of which is that the target is not echoing what it receives. If a special character (ACK, NAK, CAN, etc.) appears in the
data, it will upset things. This is where TeraTerm could differ. But
given all the buffering that goes on (kernel, USB to serial, etc.) I can think of no easy way to compensate for a target that echoes everything
it receives.

A CP/M target can be a problem if the data passes through the BDOS
console I/O routines.

The precise reason why the target sent a NAK would be helpful. Timeout?
bad checksum/CRC?
--
http://davesrocketworks.com
David Schultz

David
Have you tried the python implementation of XMODEM rather than lrzsz? https://pypi.org/project/xmodem/ has links to the documentation and download files.
Mark Ogden

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 17 January 2023 at 11:44:25 UTC, Mark Ogden wrote:

On Sunday, 15 January 2023 at 15:39:33 UTC, David Schultz wrote:

On 1/13/23 11:03 PM, David Albert wrote:

I'm having a similar problem on a different target. XModem/CRC works great from Windows using TeraTerm but fails immediately with sx on linux. An interesting thing that may point in the right direction is that at 9600bps, the transfer proceeds

although very slowly due to a retry between each packet (Retry 0: NAK on sector)

Reading that old lrzsz code is frustrating. I hate it when code is
poorly commented. Or almost not at all.

The XMODEM protocol mostly resides in the function wcputsec(). (Why that name?) Dead simple and nothing that can go wrong. It sends data and
waits for an ACK.

But it was written when serial ports were serial ports. So makes some assumptions. One of which is that the target is not echoing what it receives. If a special character (ACK, NAK, CAN, etc.) appears in the data, it will upset things. This is where TeraTerm could differ. But
given all the buffering that goes on (kernel, USB to serial, etc.) I can think of no easy way to compensate for a target that echoes everything
it receives.

A CP/M target can be a problem if the data passes through the BDOS
console I/O routines.

The precise reason why the target sent a NAK would be helpful. Timeout? bad checksum/CRC?
--
http://davesrocketworks.com
David Schultz

David
Have you tried the python implementation of XMODEM rather than lrzsz? https://pypi.org/project/xmodem/ has links to the documentation and download files.
Mark Ogden

David
There is also the newer rzsz at https://github.com/coderfordev/rzsz
Mark

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/17/23 5:44 AM, Mark Ogden wrote:

David
Have you tried the python implementation of XMODEM rather than lrzsz? https://pypi.org/project/xmodem/ has links to the documentation and download files.
Mark Ogden

Actually, I haven't used XMODEM in a very long time.

I got to looking and I do see a problem with its use with minicom.

The way XMODEM worked is that you dialed into a BBS or some such, told
it to send you a file, and then started your XMODEM receive program.
That sent a NAK to tell the sender it was ready.

Using it with minicom to send a file to a SBC is a problem. You tell
minicom to start XMODEM, then it tells you to give the command to start receiving. Except you can't since XMODEM is now using that serial link.

So you have to start the XMODEM receive program before telling minicom
to start sending. This is a problem. (Of course with a short hardwired connection like this, XMODEM isn't needed at all.)

The receive program sends a NAK to tell the sending program it is ready.
But since lrzsz hasn't started yet, nothing is listening. After a
timeout the receive program sends another NAK.

So when sz starts, more than one NAK can be buffered up waiting for it.
It consumes the first and sends the first packet. It then looks for an
ACK but finds one of those leftover NAKs.

I think that you could make lsz a little more tolerant of this. When it
reads data it uses a read() call and buffers extra characters. The code includes a function to purge that buffer but it is never called. Adding
a call to readline_purge() at an appropriate point (after getting that
initial NAK would be good) would dump that extra data.

Calling it just before starting to send each packet might be excessive.
But there shouldn't be anything to purge.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I used minicom/lrzsz a lot with the z80pack machines. The virtual SIO's won't overrun like a real one
and buffers all and everything, but I have not seen this problem.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, January 17, 2023 at 1:16:47 PM UTC-5, David Schultz wrote:

On 1/17/23 5:44 AM, Mark Ogden wrote:

David
Have you tried the python implementation of XMODEM rather than lrzsz? https://pypi.org/project/xmodem/ has links to the documentation and download files.
Mark Ogden

Actually, I haven't used XMODEM in a very long time.

I got to looking and I do see a problem with its use with minicom.

The way XMODEM worked is that you dialed into a BBS or some such, told
it to send you a file, and then started your XMODEM receive program.
That sent a NAK to tell the sender it was ready.

Using it with minicom to send a file to a SBC is a problem. You tell
minicom to start XMODEM, then it tells you to give the command to start receiving. Except you can't since XMODEM is now using that serial link.

So you have to start the XMODEM receive program before telling minicom
to start sending. This is a problem. (Of course with a short hardwired connection like this, XMODEM isn't needed at all.)

The receive program sends a NAK to tell the sending program it is ready.
But since lrzsz hasn't started yet, nothing is listening. After a
timeout the receive program sends another NAK.

So when sz starts, more than one NAK can be buffered up waiting for it.
It consumes the first and sends the first packet. It then looks for an
ACK but finds one of those leftover NAKs.

I think that you could make lsz a little more tolerant of this. When it
reads data it uses a read() call and buffers extra characters. The code includes a function to purge that buffer but it is never called. Adding
a call to readline_purge() at an appropriate point (after getting that initial NAK would be good) would dump that extra data.

Calling it just before starting to send each packet might be excessive.
But there shouldn't be anything to purge.
--
http://davesrocketworks.com
David Schultz

Um... lrz.c line 762 and 645... should not be a problem. Call is to purgeline() which first does readline_purge() and then actually purges... via ioctl() or lseek()

so, I think, good to go. Never been a problem for me, anyway -- I do not think there is
bug in THOSE particular hills.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Forgot, if you start the receiver from the terminal you will see the NAK the receiver sends,
so this one is eaten up by the terminal.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Schultz schrieb am Dienstag, 17. Januar 2023 um 23:32:50 UTC+1:

It isn't a bug so much as it is using the tool in a way it wasn't
designed for. You are supposed to start the receiver after the sender is running.

There are lots of devices where one can update firmware using xmodem protocol. These all have one in common, you connect with a terminal to the device and start
the receiver, and then on the PC you start the sender with the firmware file. Always works.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/17/23 1:36 PM, Udo Munk wrote:

I used minicom/lrzsz a lot with the z80pack machines. The virtual SIO's won't overrun like a real one
and buffers all and everything, but I have not seen this problem.

The virtual SIO isn't the problem.

You start up the XMODEM receive program on the target and it sends a
NAK. But you haven't started the send side yet so the character doesn't
make it to lsz. Most likely minicom sees it and it vanishes.

Minicom eventually (the menu system is a bit clunky) starts up lsz which
looks for a NAK. Depending on how long of a delay there was between
starting the receiver, its timeout behaviour, and buffering of the
serial input on the Linux side, there could be more than one NAK sitting
in the queue. Is minicom looking at the serial port while you are in the
menu system trying to start lsz? Doubtful.

Of course if you take too long starting up lsz the receive program will
reach its retry limit and give up.


--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/17/23 2:07 PM, fridtjof.ma...@gmail.com wrote:

Um... lrz.c line 762 and 645... should not be a problem. Call is to purgeline()
which first does readline_purge() and then actually purges... via ioctl() or lseek()

Which effects lsz.c not at all.

There are calls to purgeline() in lsz.c but as near as I can tell, only
in code active for ZMODEM.

so, I think, good to go. Never been a problem for me, anyway -- I do not think there is
bug in THOSE particular hills.

It isn't a bug so much as it is using the tool in a way it wasn't
designed for. You are supposed to start the receiver after the sender is running.

--
http://davesrocketworks.com
David Schultz

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/17/23 18:03, Udo Munk wrote:

Forgot, if you start the receiver from the terminal you will see the NAK the receiver sends,
so this one is eaten up by the terminal.

I stopped having an of these problems when Kermit showed up. :-)

bill

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It isn't a bug so much as it is using the tool in a way it wasn't
designed for. You are supposed to start the receiver after the sender is running.

You _can't_ start the receiver after starting the sender in an upload.

Seems like sx should flush the buffer either immediately at start, or
at least after receiving a NAK.

But it's still an open question whether this is the problem experience
when talking to a MyZ80, I believe.

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bill Gunshannon schrieb am Mittwoch, 18. Januar 2023 um 00:54:36 UTC+1:

I stopped having an of these problems when Kermit showed up. :-)

It isn't really a problem, is normal that the terminal shows a bit garbage when you start
a xmodem transmission. Whatever, of course you can start the receiver first and then the
sender to get the transmission going, doesn't matter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Had some time to try this stuff again, on CP/M I'm using Martin Eberhardt's xmodem.
You really have to start transceiver first with minicom/lrzsz, if you first start xmodem on
the CP/M side the transfer will not start and times out after a while.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, January 18, 2023 at 1:48:23 PM UTC+1, Udo Munk wrote:

Had some time to try this stuff again, on CP/M I'm using Martin Eberhardt's xmodem.
You really have to start transceiver first with minicom/lrzsz, if you first start xmodem on
the CP/M side the transfer will not start and times out after a while.

If you have to send a file from Minicom to CP/M, how do you start the transceiver first with Minicom/lrzsz?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

paolo....@gmail.com schrieb am Mittwoch, 18. Januar 2023 um 13:55:11 UTC+1:

If you have to send a file from Minicom to CP/M, how do you start the transceiver first with Minicom/lrzsz?

You use the auxiliary serial for the transfer and the console port for the terminal.
You can't if you try to use one serial port for both.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, January 18, 2023 at 5:36:23 AM UTC-8, Udo Munk wrote:

You use the auxiliary serial for the transfer and the console port for the terminal.
You can't if you try to use one serial port for both.

Exactly, Udo. I've always been under the impression that you have to have 2 serial ports to use xmodem successfully, one (the console) for commands and the other for the actual transfer. It has always worked perfectly for me with that configuration.
Is that wrong?

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, January 18, 2023 at 7:48:23 AM UTC-5, Udo Munk wrote:

Had some time to try this stuff again, on CP/M I'm using Martin Eberhardt's xmodem.
You really have to start transceiver first with minicom/lrzsz, if you first start xmodem on
the CP/M side the transfer will not start and times out after a while.

Udo

I use (in general) PCPUT and PCGET with lrzsz (with picocom, not minicom, but it shouldn't
really matter). When I get cycles, I'll try XMODEM. Now, with that, its receive first, then sx,
and send first, then rx. On the rx I may get one or two NAKs, then everything settles.

This also works with the Settings xmodem send/receive in the Altair-Duino configuration
(which runs native on the Due).

Note that a related problem is capturing paper tape punches! I set picocom to capture
(using log option), then, just before punching the tape from the Altair-Duino, I do 'cp /dev/null log'
to clear the log, punch, then 'cp log capture' -- I may then edit the "paper tape" with ghex.
This is all because picoterm does NOT send a CR or something on file capture begin
(nor does minicom)!

PS. I use picocom because it attempts no "terminal emulation". Except a single trigger
character.

I could use my la36 terminal emulator to solve this...that is a bit overkill... but that
also supports ASR mode (^Q/^A ^R/^T) per Teletype ASR-33.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The other day I updated fimware in my G90 radio. This of course has only one serial port and is not operated from a terminal. The serial port is used for CAT control and xmodem firmware updates. For this I need to bring the radio into update mode,
connect to the serial with some terminal program and answer the usual question, do you really want that etc. Then xmodem receive kicks in, I see the NAK in the terminal. Then I go into the menu, send file, xmodem, filename and the transfer immediatly
starts. So no, xmodem does not always need 2 serial ports to function.

Must have to do something with the xmodem implementation on the CP/M side, try some other program maybe.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, January 18, 2023 at 1:14:45 PM UTC-5, fridtjof.ma...@gmail.com wrote:

On Wednesday, January 18, 2023 at 7:48:23 AM UTC-5, Udo Munk wrote:

Had some time to try this stuff again, on CP/M I'm using Martin Eberhardt's xmodem.
You really have to start transceiver first with minicom/lrzsz, if you first start xmodem on
the CP/M side the transfer will not start and times out after a while.

Udo

I use (in general) PCPUT and PCGET with lrzsz (with picocom, not minicom, but it shouldn't
really matter). When I get cycles, I'll try XMODEM. Now, with that, its receive first, then sx,
and send first, then rx. On the rx I may get one or two NAKs, then everything settles.

This also works with the Settings xmodem send/receive in the Altair-Duino configuration
(which runs native on the Due).

Note that a related problem is capturing paper tape punches! I set picocom to capture
(using log option), then, just before punching the tape from the Altair-Duino, I do 'cp /dev/null log'
to clear the log, punch, then 'cp log capture' -- I may then edit the "paper tape" with ghex.
This is all because picoterm does NOT send a CR or something on file capture begin
(nor does minicom)!

PS. I use picocom because it attempts no "terminal emulation". Except a single trigger
character.

I could use my la36 terminal emulator to solve this...that is a bit overkill... but that
also supports ASR mode (^Q/^A ^R/^T) per Teletype ASR-33.

As to terminals... I use XTERM -- sending hex FF is the same a sending a space! Is this true of VT52 and VT100?
But... because of that, I patch IMSAI 8K BASIC to produce 5xNUL (00) on CRLF, not 5xFF. But... on SAVE,
I change 00 back to FF to get paper tapes the same as the original! Not a huge deal, but I wonder if anyone
has tried FF (not formfeed, but hex FF) on a real VT52 or VT100? Is XTERM wrong?!? If so, should be reported. If not... its just a variance.
My approach of using 00 or FF as needed works (00 is "nothing" on XTERM and, as far as I know ASR and KSR 33
as well). Can someone verify that TTY 33 ignores 00 as well as FF (and 7F)? Thanks in advance.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday, January 18, 2023 at 2:12:25 PM UTC-5, Udo Munk wrote:

The other day I updated fimware in my G90 radio. This of course has only one serial port and is not operated from a terminal. The serial port is used for CAT control and xmodem firmware updates. For this I need to bring the radio into update mode,

connect to the serial with some terminal program and answer the usual question, do you really want that etc. Then xmodem receive kicks in, I see the NAK in the terminal. Then I go into the menu, send file, xmodem, filename and the transfer immediatly
starts. So no, xmodem does not always need 2 serial ports to function.

Must have to do something with the xmodem implementation on the CP/M side, try some other program maybe.

Udo

I agree completely -- will play with Martin's XMODEM as soon as I have cycles.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

The other day I updated fimware in my G90 radio.

You're a ham, Udo?

De

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

During my military service I have been to Shilo and for a while I was your friendly radio operator
in the base there :)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Dennis Boone schrieb am Mittwoch, 18. Januar 2023 um 22:13:42 UTC+1:

The other day I updated fimware in my G90 radio.

You're a ham, Udo?

De

I play arround with radios since I was a kid. I had such an electronics experimentation kit that allowed
to build receivers up to superheterodyne ones. After I got it runnig I showed it to my parents and my
dad said interesting, if you have everythig to build a receiver you also could build a sender, but he refused
to tell me how ;-) So I went to my local library and got some books, and in no time I was "on air".
As you can imagine my parents were not amused and something had to be done.

Most of my military service I did in radio communications, installed the systems in cars and tanks,
build up and tuned the antenna systems, repairs and so on.

I also worked 10 years for a company producing telco systems, also radio based ones used on ships
or places that could not be wire connected. Interesting stuff, the installation on Queen Elisbeth 2 was
done by us.

And yes, I still own a few radios to play with sometimes in my spare time.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/18/23 16:13, Dennis Boone wrote:

> The other day I updated fimware in my G90 radio.

You're a ham, Udo?

I suspect many of the people who still share an interest in ancient
computers and OSes are hams.

bill
KB3YV (ex N2APY, ex DA1WO)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bill Gunshannon <bill.gunshannon@gmail.com> writes:

I suspect many of the people who still share an interest in ancient
computers and OSes are hams.

bill
KB3YV (ex N2APY, ex DA1WO)

And some us got our interest in computers as a follow on from our interest
in electronics generally which originally came from our interest in radio.

When I was a teenager in the early sixties, I had a friend Rainer whose dad
was an electonics repair guy who had immigrated from Germany in the 1950s.
We had a one-valve experimental transmitter rig on about 300 MHz which we
were allowed to play with - standing waves on a transmission line, etc - but not allowed to actually transmit 'on the air',

IIRC, the circuit seemed very close to that of a one-valve receiver. My
memory tells me it was simply down to the value of a bias resistor on either the grid or the cathode: low values would allow the valve to oscillate.

But I wouldn't stake my life on that after 60-odd years.

Regards,

Jack
--
My wife says I have two faults:
I don't listen and something else.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.01.23 22:43, Jack Strangio wrote:

Bill Gunshannon <bill.gunshannon@gmail.com> writes:

I suspect many of the people who still share an interest in ancient
computers and OSes are hams.

bill
KB3YV (ex N2APY, ex DA1WO)

And some us got our interest in computers as a follow on from our interest
in electronics generally which originally came from our interest in radio.

Me, I'm a 66 year old retired (8'22) software developer/maintainer, last employer was one of the big Linux distributors.

My interest in "ancient computers" comes from the fact that one can
thoroughly understand these old boxs. You don't have only a small
handful of big black thingies that do everything but you can point at
any DIL package and know what it does. Also, it's way easier to hook
something up a Z80 bus than up a PCI-whatever bus.
Yes, ucontrollers come close, but nothing beats a full
addres/data/control bus.

My 2cts,

Josef
PS My "ancient computer" is an SB180FX.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 11 Jan 2024 03:52:59 -0800 (PST)
Ivan Ilyichev <ilyichev.ivan@gmail.com> wrote:

Hi! If the problem still exists. I wrote special version of XModem
software for PC (both for Linux and Windows, might be compiled via
Lazarus 3.0) than impements an adjustable delay after each byte, sent
to remote CP/M computer. It lets CP/M with fast UART chip like

Thanks, I'll definitely check it out.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, 11 Jan 2024 03:52:59 -0800 (PST)
Ivan Ilyichev <ilyichev.ivan@gmail.com> wrote:

work ok. The repo is here: https://github.com/ivang78/xmodem .

The supplied Linux binary requires glibc 2.34 while my Linux
system based on Debian Bullseye provides version 2.31.

So I guess I need to build XMODEM from source with Free Pascal, right?
Do I need the full Lazarus or is Free Pascal enough?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)