 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : MMB4L: XModem questions
| Author | Message | ||||
thwill Guru  Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Hi folks, Work proceeds on serial support for MMB4L, I've got it working sufficiently so that I have been able to write an MMBasic program "Gonzo" that runs on MMB4L and allows me to communicate with a tethered CMM2 or PicoMite: Welcome to gonzo v2.0.0-a1 Connecting to /dev/ttyS0: 115200 ... Connected to Colour Maximite 2 G2 gonzo$ help Commands are: break send a Ctrl-C to the remote connect connect to remote device report type of connected device exit exit the gonzo shell help display help text log show (or clear) receive log rchdir change remote directory rcopy copy a remote file rdelete remove a remote file or (empty) directory receive receive a file from the remote using AUTOSAVE rfiles list remote directory contents rmkdir make a directory on the remote rpwd display current remote directory rrename rename a remote file or directory rsize display size of a remote file rtype list remote file contents send send a file to the remote using AUTOSAVE term open serial terminal version display current gonzo version xreceive receive a file from the remote using XMODEM xsend send a file from to the remote using XMODEM gonzo$ But I have a couple of questions about XModem (using code borrowed from the CMM2 originally by Georges Menie): 1. Is it expected to be so damn slow ? about 7 times slower than transferring using AUTOSAVE; though more flexible since AUTOSAVE expects only ASCII. 2. Is there anything the SENDer can do to cleanup the padding appended to a file sent via XMODEM or do I need to do any cleanup on the RECEIVEr ? Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
Geoffg Guru Joined: 06/06/2011 Location: AustraliaPosts: 3292 |
1. From my experience XMODEM should run at about the same speed as AUTOSAVE. 2. The convention was that the padding char should be EOF (CTRL Z). The old DOS software would use that as an end of file marker. So it is the receiver that has to cleanup. Geoff Edited 2021-12-13 00:29 by Geoffg Geoff Graham - http://geoffg.net |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
generally the sender will pad the file being sent to a multiple of 128 bytes with chr$(0)'s. the receiver can then strip out any chr$(0)'s that it finds. it works extremely quickly for me, and is surprisingly simple to use (well, with GFXterm at least). it should operate at about the same speed as AUTOSAVE, as the data transferred is 99% just the text of the original ascii file with a header (3 byte) and footer (1 byte checksum) attached. i've not tried using XMODEM for anything other than text, am not really sure the original designer ever though about this. with binary data you'd not really be able to determine how many of the chr$(0)'s at the end were padding. feel free to have a look at the GFXterm source code for a very simple XMODEM implementation. have been hacking the code a bit, so see attached for the latest version: xmodem.pas.zip cheers, rob :-) addendum: SNAP! you were writing at the same time as me, geoff. i think ctrl-Z was the original, but later on chr$(0) was used. i had thought the MX170 used chr$(0). Edited 2021-12-13 00:47 by robert.rozee |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Thanks for the input. At the moment using LIST/AUTOSAVE definitely seems faster, though with a sufficiently large file only ~twice as fast as XMODEM. I'm guessing that the 'mite XMODEM code is doing more processing than the LIST/AUTOSAVE route or I've got some sort of buffering issue. The implementation of XMODEM on the 'mites appears to use the NUL character for padding but can handle receiving Ctrl-Z, it just translates it to NUL ... except for the CMM2  .Yes, I think it will be necessary for Gonzo to send the file-size separately. Thanks but there is no particular reason not to use the standard C 'mite implementation. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2442 |
certainly wouldn't be changing the 'mite code, but the GFXterm code may provide you with some pointers on how the whole XMODEM protocol works. it took me quite a while to get the finer details figured out, although i may have just been looking in the wrong places! cheers, rob :-) |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Which (at least when the remote is a CMM2 with a file-system) proved very easy. After an XMODEM SEND, "Gonzo" now sends a small program "Rizzo" to the remote that strips off the padding - I will probably be debugging this until "kingdom come". Best wishes, Tom Edited 2021-12-13 03:07 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
XMODEM can be padded with either zero or ^Z. Either is considered acceptable. Unless the receiver knows the true length of the file, there is no way it can strip off the superfluous characters. Just trimming of the ending ^Z (or zeros) is OK for text but can be disastrous for any other file type. Most image formats etc seem to handle the extra characters without any pain. If a user writes a program that accepts files that might have been XMODEMed, the user has to make allowances. While it would be nice if the extras were trimmed, users need to accept that they might be there. YMODEM solved these issues. Jim VK7JH MMedit |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Thanks Jim. Like I say I've resolved the problem for remote 'mites with file-systems by having "Gonzo" transmit a small utility program "Rizzo" that knows the size and can thus remove the padding. As far as possible, and with the exception of "Rizzo" I'm trying to write "Gonzo" so it uses the serial console to drive standard 'mite features on the remote and doesn't require any additional programs to be installed. I guess this is exactly how MMEdit must be working ? Best wishes, Tom Edited 2021-12-13 07:48 by thwill MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
MMEdit's file manager knows the file size so receiving files can be truncated (optionally) but sending to the 'mite is "user beware" Jim VK7JH MMedit |
||||
| thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4311 |
Right, same for "Gonzo" when receiving, and "Rizzo" solves the problem when sending, provided the remote 'mite has a file-system. Best wishes, Tom MMBasic for Linux, Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
phil99 Guru Joined: 11/02/2018 Location: AustraliaPosts: 2640 |
"Most image formats etc seem to handle the extra characters without any pain." For .BMP at least, file size is in the header so the viewer app ignores anything after that is reached. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
