File Transfer doesn't work

[Michael Kühn]

Hi, I got my rc2014 up and running. But I'm not able to transfer files to the rc2014. I convert the desired file (e.g. MBASIC.COM) with the "Binary to CPM Package" program. Then I paste the content on the CP/M command line. But it seems, that the transfer doesn't start. I only could see the pasted content and a blinking cursor. But not "......" or "OK" appears. I tried different files with the same result. I'm using PuTTY as the terminal program. Any hint what to do or check?

[Spencer Owen]

Hi Michael,

There is minimal flow control, which means that larger file transfers might fail. This is easily fixed by adding a 1ms character delay in the terminal program. I don't think PuTTY supports adding a character delay, but depending what operating system you're using, there are plenty which do. On Windows I use TeraTerm and on LInux I use GtkTerm.

However, even if you have issues with larger files, you should at least see the start of the transfer type in A:DOWNLOAD. That should be the first line in the text file that the CP/M packaging program creates.  For a bit more information, see https://rc2014.co.uk/troubleshooting/simple-guide-to-getting-cp-m-running-on-rc2014/

Hope that helps

Spencer

On Mon, 29 Mar 2021, 17:38 Michael Kühn, <nurmi...@gmx.net> wrote:

Hi, I got my rc2014 up and running. But I'm not able to transfer files to the rc2014. I convert the desired file (e.g. MBASIC.COM) with the "Binary to CPM Package" program. Then I paste the content on the CP/M command line. But it seems, that the transfer doesn't start. I only could see the pasted content and a blinking cursor. But not "......" or "OK" appears. I tried different files with the same result. I'm using PuTTY as the terminal program. Any hint what to do or check?

--
You received this message because you are subscribed to the Google Groups "RC2014-Z80" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rc2014-z80+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rc2014-z80/00038691-940d-437c-a455-e9e4012eae2fn%40googlegroups.com.

[Michael Kühn]

Hi Spencer,

your tipp with the terminal program did the trick. Using TeraTerm with a delay of 1 ms/char allowed me do transfer the programs. But every now and then, the transfer stopps and hangs. After a reset, in most cases, the transfer was successful, but not in every case.

And sometimes I have the problem, that an error is popping up saying "File Length Error".

Regards

Michael

[rla...@gmail.com]

I always found pasting the "packaged" files into the terminal to be unreliable.  Two of my RC2014s have SIO/2 cards.  So I use the second serial port and Kermit to transfer my files.

[Phillip Stevens]

Michael wrote:

Hi Spencer,

your tip with the terminal program did the trick. Using TeraTerm with a delay of 1 ms/char allowed me do transfer the programs. But every now and then, the transfer stops and hangs. After a reset, in most cases, the transfer was successful, but not in every case.

And sometimes I have the problem, that an error is popping up saying "File Length Error".

Some words as to why this is required. Specifically with the standard "Searle" CP/M serial implementation for the ACIA Module there are several issues that can crop up.

[Noted that Grant's initial CP/M implementation was by nature very simple, and hasn't been patched at all].

Firstly, the ACIA Rx is doubled buffered and does store two bytes before the receiver over-runs, but the second received byte is not handled by the Searle code (which only handles one received byte per interrupt). But if a second byte arrives before the interrupt from the first byte is handled,  or if a second byte arrives while the first byte interrupt is being handled, then a byte will be lost and the transmission will fail.

The correct way to handle this is to check for arrived bytes on completion of handling the first byte, and / or to read the ACIA error flags and raise an overrun / framing error to a higher layer.

Both RomWBW and CP/M-IDE interrupt routines do check repeatedly for (double) buffered received bytes, but neither checks for errors because there is no higher layer error handling in CP/M.

The second issue is that the Searle CP/M ACIA implementation only has a 15 byte receive buffer. This is too small to receive a full Kermit or XMODEM packet without over-run, if flow control is not properly respected. With Kermit the desired packet size can be negotiated. For XMODEM the standard packet size is 133 bytes.

Ideally you want to have this receive buffer at least as large as the Kermit or XMODEM packet size, so that (in the absence of working RTS/CTS signalling as is the case with many of today's USB serial adaptors) the higher layer packet acknowledgement process is sufficient to ensure there is no overrun. This is the reason that the z88dk RC2014 ACIA default and therefore also CP/M-IDE supports 255 bytes in its receive buffer.

Hope this is useful.

Cheers, Phillip

[Michael Kühn]

Thanks Philip for the extensive response. But I suspect, that this is not the whole truth. I tried to do the same file transfer using the secondary port with my Linux machine. There I'm using "moserial" as the serial terminal. And what should I say. The transfer works like a charm. Seems, that the error is a result of using the same primary port

for both the display/keyboard input together with the file transfer?!

[Phillip Stevens]

Michael wrote:

Thanks Philip for the extensive response. But I suspect, that this is not the whole truth. I tried to do the same file transfer using the secondary port with my Linux machine.

And that is where it became clear that I was totally on the wrong page. I forgot the Searle CP/M is based on the SIO/2 serial device not the ACIA (as is his MS Basic code).

There I'm using "moserial" as the serial terminal. And what should I say. The transfer works like a charm. Seems, that the error is a result of using the same primary port

for both the display/keyboard input together with the file transfer?!

Phillip wrote:

Some words as to why this is required. Specifically with the standard "Searle" CP/M serial implementation for the ACIA Module there are several issues that can crop up.

[Noted that Grant's initial CP/M implementation was by nature very simple, and hasn't been patched at all].

Firstly, the ACIA Rx is doubled buffered and does store two bytes before the receiver over-runs, but the second received byte is not handled by the Searle code (which only handles one received byte per interrupt). But if a second byte arrives before the interrupt from the first byte is handled,  or if a second byte arrives while the first byte interrupt is being handled, then a byte will be lost and the transmission will fail.

The correct way to handle this is to check for arrived bytes on completion of handling the first byte, and / or to read the ACIA error flags and raise an overrun / framing error to a higher layer.

Both RomWBW and CP/M-IDE interrupt routines do check repeatedly for (double) buffered received bytes, but neither checks for errors because there is no higher layer error handling in CP/M.

But this same issue applies. The SIO/2 is quad hardware buffered, and the interrupt driver needs to drain the hardware buffer before returning, or otherwise potentially lose bytes. The Searle cbios128.asm code doesn’t do this either, so it exhibits the same flaw as the ACIA code. 

 

The SIO/2 interrupt driver has a much larger 60 byte buffer, but this can be quickly overrun if the RTS is not respected, as there is no packet acknowledgment designed in the very simple download.com protocol.

So that is why the 1ms between characters is still needed, if RTS is not respected properly.

Sorry for the misinformation.

Phillip

--

Sent from a Mobile Device. Replies may appear terse.

[Tony Nicholson]

In addition to the flow-control issues (which others have addressed), the Ward Christensen

protocol (as used by XMODEM) detects a timeout when no response is received.

XMODEM tries to maximise throughput by buffering each received "sector" into the available

memory before writing it to the disk device.  Small files which fit within the buffer can be

received fine, but the larger ones can fail when the time it takes to write out the buffer

exceeds the XMODEM timeout.  Usually this results in sending a NAK character to get

the other end to re-send the last sector - when it should send an ACK after writing the

buffer to the disk file.

You could play with setting a longer time-out (by adjusting it with XMODEM's CPU speed

option /Zn) - but I have been able to make a non-working large file transfer succeed by

reducing the buffer space used by XMODEM (which makes the write to disk flushing

work quicker).

For XMODEM V2.7 the bufferspace is between the end of the program and the BDOS.

As a quick fix you can find where the BDOSA+1 is referenced in the source-code (there

are two places) and either hard-code an upper limit or (as I have done) halve the value.

e.g.

where the test for end of buffer uses -

        lda     BDOSA+1         ;high byte of BDOS

        cmp     h                  ;full buffer?

replace this with

        lda     BDOSA+1

        ora a                      ; Clear carry and shift to divide by 2

        rar

        cmp       h

and again later in the FILBF1 routine

replace

        lda     BDOSA+1         ;High byte of BDOS address

        cmp     d

with

        lda     BDOSA+1

        ora a

        rar

        cmp     d

then rebuild a new XMODEM.

This fixed my issue with a slow SPI connected Arduino microSD file system that

would take more than 15 seconds to write out 50 Kbytes of buffer.  It now takes

about 8 seconds to write 25 Kbytes - well within the timeout margin.

Tony