Linux -> CP/M XMODEM transfer timeout

[Paolo Amoroso]

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

[Dennis Boone]

> 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

[Adam Sampson]

Paolo Amoroso <paolo....@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 <a...@offog.org> <http://offog.org/>

[David Schultz]

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

[Paolo Amoroso]

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.

[Paolo Amoroso]

Adam, it could be the same problem. I only know the board has a serial adapter based on the CP2102 serial chip, but the kit's bill of materials[1] is available.


[1] https://cdn.hackaday.io/files/1599736844284832/A040618%20BOM%20v2.ods

[Paolo Amoroso]

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.

[Dennis Boone]

> 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

[Dennis Boone]

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

Is this file text or binary?

De

[Paolo Amoroso]

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

[Randy McLaughlin]

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

[Paolo Amoroso]

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

[Paolo Amoroso]

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.

[Dennis Boone]

> 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

[Paolo Amoroso]

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

[Dennis Boone]

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

[Paolo Amoroso]

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

[Dennis Boone]

> 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

[Paolo Amoroso]

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, 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, TIOCGRS485, 0x7ffdd0acb480) = -1 ENOTTY (Inappropriate ioctl for device)
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(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
write(1, "\33[?12l\33[?25h", 12) = 12
write(1, "\33[5;1H \33[6;1HCP/M V3.0 Loader \33[7;1HCopyright (C) 1982, Digital Research \33[8;1H \33[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 2E
00 \33[13;1H \33[24;32H", 750) = 750
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(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
read(0, "\31", 32) = 1
read(0, "x", 32) = 1
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, TCFLSH, TCIOFLUSH) = 0
write(1, "\33[8;30H\33[?25l+----------------------+\33[9;30H| Leave Minicom? |\33[10;30H| No |\33[11;30H+----------------------+\33[10;51H\33[?25l", 146) = 146
write(1, "\33[10;33H\33[0m\33(B\33[7m Yes ", 27) = 27
read(0, "\r", 32) = 1
write(1, "\33[?12l\33[?25h", 12) = 12
write(1, "\33[8;1H\33[0m\33(B \33[9;1H BNKBIOS3 SPR F600 0600 \33[10;1H BNKBIOS3 SPR 5300 2D00 \33[11;1H RESBDOS3 SPR F000 0600 \33[24;32H", 253) = 253
ioctl(3, TCGETS, {B115200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B9600 opost isig icanon echo ...}) = 0
ioctl(3, TCGETS, {B9600 opost isig icanon echo ...}) = 0
ioctl(3, TIOCMSET, [TIOCM_DTR|TIOCM_RTS]) = 0
write(1, "\33[?12l\33[?25h", 12) = 12
write(1, "\33[?12l\33[?25h", 12) = 12
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(1, "\33[H\33[2J", 7) = 7
write(1, "\33[?12l\33[?25h", 12) = 12
write(1, "\33[?1l\33>\33[!p\33[?3;4l\33[4l\33>", 24) = 24
+++ exited with 0 +++

[Paolo Amoroso]

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)
--- 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)

[Dennis Boone]

> 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

[Paolo Amoroso]

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

[Dennis Boone]

> 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

[Paolo Amoroso]

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):

B>a:xmodem te.hex /r /z8

Bad value in command line

[Paolo Amoroso]

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
; ...

[Dennis Boone]

> 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

[Paolo Amoroso]

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.

[Paolo Amoroso]

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.

[David Schultz]

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.

[Paolo Amoroso]

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".

[Dennis Boone]

> 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

[Paolo Amoroso]

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.

[David Schultz]

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.

[Paolo Amoroso]

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.

[Dennis Boone]

> > 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

[Paolo Amoroso]

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.

[Randy McLaughlin]

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

[Paolo Amoroso]

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.

[David Schultz]

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.

[Paolo Amoroso]

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.

[Paolo Amoroso]

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.

[David Schultz]

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?

[Paolo Amoroso]

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

[Paolo Amoroso]

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:

B>xmterm greet.hex /r

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

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

Or like these:

B>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.

[David Schultz]

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:
>
> B>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.

[Paolo Amoroso]

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

B>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):

B>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?

[David Schultz]

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.

[David Schultz]

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.

[Paolo Amoroso]

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