I've just released version 2.9 of my Xmodem file transfer program for CP/M. This is a minor tweak on version 2.8: the receiver is now flushed of any garbage characters before receiving a file. (Previous versions would get hung up due to leftovercharacters in the UART's buffers if you had aborted a file transfer before trying to transfer a new file.)
characters in the UART's buffers if you had aborted a file transfer before trying to transfer a new file.)I've just released version 2.9 of my Xmodem file transfer program for CP/M. This is a minor tweak on version 2.8: the receiver is now flushed of any garbage characters before receiving a file. (Previous versions would get hung up due to leftover
I assemble it with DRI MAC, and load with MLOAD. Very simple build. Works great.M much more often than the 2.7 version. The actual throughput is quite a bit lower.
Because my CP/M BIOS serial handling doesn't touch BC or DE, I've removed that protection from GOBIOS (which takes quite a few cycles out of the transmit and receive loops). What I'm finding is that the 2.9 version pauses and waits while sending to CP/
There are some notes in your 2.8 release related to this, and I wonder if by "speeding up" the GOBIOS routine I've in-fact broken the carefully choreographed timing of buffer read and write? Would that be the case?
Previously (2.7) the CP/M receive direction would fill RAM (approx 54kB) without showing a NAK and then write to disk and repeat, but now (2.9) it only does a few kB before showing repeated NAKs and is very choppy and slow. I replicate this on the samemachine receiving the same file, so the only change is xmodem.
Any thoughts on what has changed which might cause this different behaviour?
same machine receiving the same file, so the only change is xmodem.Phillip wrote:
Previously (2.7) the CP/M receive direction would fill RAM (approx 54kB) without showing a NAK and then write to disk and repeat, but now (2.9) it only does a few kB before showing repeated NAKs and is very choppy and slow. I replicate this on the
setting /K that allows you to select this. I put /K20 in my XMODEM.CFG file to limit it to 20Kbytes on my problematic system.Any thoughts on what has changed which might cause this different behaviour?
Tony Nicholson wrote:
I found that XMODEM sometimes does a NAK if the CP/M file writing takes too long (the timeout settings are hard to get right on faster Z80/Z280 systems). The workaround for me was to reduce the amount of in-memory buffering. Version 2.9 as a new
Phillip Stevens wrote:CRC to fail (or something). The sender then repeats the block but the receiver then goes into a long time out, before the receiver sends NAK again. At this point the sender then repeats the block a second time the receiver ACKs it, and things continue
I've also spent some time with the logic analyser and traces. The failing process begins when is a block is received and rather than being ACKed(0x06) it is NAKed (0x15). Perhaps noise, but I doubt that. It will be something programmatic causing the
So, I'm thinking to try to reduce the timeout before sending that second NAK, to speed up reinitialisation of transmission. But that is a work around. What I need to do is to find out what is causing the block errors in the first place (given thetriage above).
Interesting problem...
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 301 |
Nodes: | 16 (2 / 14) |
Uptime: | 214:48:28 |
Calls: | 6,744 |
Calls today: | 4 |
Files: | 12,272 |
Messages: | 5,369,009 |