Linux -> CP/M XMODEM transfer timeout
1135 views
Skip to first unread message
Paolo Amoroso
Jun 21, 2022, 12:15:14 PM6/21/22
to
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
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
Jun 21, 2022, 5:59:54 PM6/21/22
to
> 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
> a few tens of bytes. Transferring files from the board to Linux works
> fine.
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
Jun 21, 2022, 6:45:04 PM6/21/22
to
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
> Minicom shows these status messages, nothing happens, and the file is
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
Jun 21, 2022, 9:19:36 PM6/21/22
to
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
> 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:
>
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
Jun 22, 2022, 6:32:11 AM6/22/22
to
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.
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
Jun 22, 2022, 6:32:35 AM6/22/22
to
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
[1] https://cdn.hackaday.io/files/1599736844284832/A040618%20BOM%20v2.ods
Paolo Amoroso
Jun 22, 2022, 6:33:46 AM6/22/22
to
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.
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
Jun 22, 2022, 10:16:48 AM6/22/22
to
> 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
> sequence backwards. Or at least the example in the sz documentation
> (used by minicom to do the transfer) does it this way:
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
Jun 22, 2022, 10:17:38 AM6/22/22
to
> Dennis, I can no longer reproduce a successfull transfer, even for a
> file that worked earlier.
Is this file text or binary?
> file that worked earlier.
De
Paolo Amoroso
Jun 22, 2022, 10:22:17 AM6/22/22
to
Randy McLaughlin
Jun 22, 2022, 10:37:18 AM6/22/22
to
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
> On Wednesday, June 22, 2022 at 4:17:38 PM UTC+2, Dennis Boone wrote:
> > > 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.
> > Is this file text or binary?
> It's a 104 bytes text file, specifically an Intel HEX file.
Randy
Paolo Amoroso
Jun 22, 2022, 10:50:49 AM6/22/22
to
Thanks for the tip Randy. However, I'm seeking a solution that works with arbitrary size files.
Paolo Amoroso
Jun 22, 2022, 1:50:52 PM6/22/22
to
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
Jun 22, 2022, 3:15:14 PM6/22/22
to
> 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
Jun 22, 2022, 4:05:06 PM6/22/22
to
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:
> 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?
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?
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
Jun 22, 2022, 9:46:12 PM6/22/22
to
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
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
> 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):
of the te file?
De
Paolo Amoroso
Jun 23, 2022, 4:04:00 AM6/23/22
to
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.
> I was hoping the log could be made to show actual serial port traffic.
> Any chance you're free to post the first couple hundred bytes worth
> of the te file?
:200100002A06002E00F9110002B7ED522B22910111774BED538F01B7ED52232293013024DA
:200120000E09112B01CD0500C3000052756E74696D65204572726F72202D204E6F20737497
:2001400061636B24218100119501017F00EDB03A800006004F219501093600111702219402
:2001600001010100237EB72818FE2028F77D127C1312130C237EB72808FE2020F73600184D
:20018000E3211502C5E5CDDB36000000C300000000000000000000000000000000000000F9
:2001A00000000000000000000000000000000000000000000000000000000000000000003F
:2001C00000000000000000000000000000000000000000000000000000000000000000001F
:2001E0000000000000000000000000000000000000000000000000000000000000000000FF
:2002000000000000000000000000000000000000000000000049024902490249024902491E
:2002200002490249024902490249024902490249024902490249024902490249024902490E
:2002400002490249024902490200CD9C021803CDAD026E2600C9CD9C021803CDAD027E6F22
:20026000079F67C9CD9C021803CDAD027E23666FC9CD99021803CDAA02ED5B970273EBC963
:20028000CD99021803CDAA02ED5B9702732372EBC97D12137C12C90000229702D1E14E23EE
:2002A0004623E5D52104000939C9229702D1E106004E23E5D52104000939C97DB36F7CB250
:2002C00067C97DAB6F7CAA67C97DA36F7CA267C97CB5B2B36FC97CB5C87AB3C0C31604B7DC
Dennis Boone
Jun 23, 2022, 11:06:14 AM6/23/22
to
> 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
> info it logs is pretty much only the file size.
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:
hex files to look like a problem, but perhaps I'm not doing it right.
De
Paolo Amoroso
Jun 23, 2022, 2:45:58 PM6/23/22
to
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
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
Jun 23, 2022, 3:06:50 PM6/23/22
to
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:
> 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
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
Jun 24, 2022, 12:29:34 PM6/24/22
to
> 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
> 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)
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
Jun 24, 2022, 2:12:02 PM6/24/22
to
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?
> 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
C xmodem sx -vv Y U N Y N
File created
Receiving via direct I/O with CRCs
ABORT: Sync fail
Empty file deleted
Dennis Boone
Jun 24, 2022, 10:36:21 PM6/24/22
to
> 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?
> a shell from Minicom to execute sx -a test.txt, but still no joy with
> file transfers.
De
Paolo Amoroso
Jun 25, 2022, 6:17:47 AM6/25/22
to
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:
> What version of MFE's XMODEM are you using?
=========================
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
Jun 25, 2022, 6:27:41 AM6/25/22
to
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:
> On CP/M 3.0 I'm using version 2.7 patched by J4F, the Z80-MBC2 developer:
; 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
Jun 25, 2022, 9:58:58 AM6/25/22
to
> 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
Jun 25, 2022, 12:42:40 PM6/25/22
to
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:
> 1. Anything clueful in dmesg?
[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?
> 3. Have you tried the /Q option to XMODEM?
> 4. Do you have a different usb serial device to try?
Paolo Amoroso
Jun 27, 2022, 3:23:46 PM6/27/22
to
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.
The workaround lets me send HEX files for transferring CP/M programs, uuencoded (or similar) files for other binary, non-excutable files.
David Schultz
Jun 27, 2022, 4:23:26 PM6/27/22
to
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
> 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.
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
Jun 27, 2022, 4:43:29 PM6/27/22
to
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.
> 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.
Dennis Boone
Jun 27, 2022, 11:07:19 PM6/27/22
to
> 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
> 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.
related to keeping up, it ought to move at least one packet before
timing out.
De
Paolo Amoroso
Jun 28, 2022, 2:17:05 PM6/28/22
to
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
Jun 28, 2022, 3:14:41 PM6/28/22
to