Importing binary files without removable storage nor non-bundledsoftware (was: TKermitFTP

On Sun, 9 Jan 2005, John Allain wrote: Since DEBUG can load Intel hex files, and copying text files through the com port is relatively easy, htat's one solution. * On the "donor" machine, convert KERMIT.COM (or .EXE) to hex. YOu might have to go to (the current logical equivelant of) tucows to find a program that does it, but it should not be hard. * On each machine (donor and target) use "MODE" to set some bit rate, eg 9600, no parity, 8 bits. * On the target, start "COPY COM1 KERMIT.HEX". * Then, on the donor, start "COPY KERMIT.HEX COM1". * If all went well (caveats, below) you now have a hex, text copy of Kermit on the target machine. * DEBUG KERMIT.HEX. Kermit shoudl run! Immaterial I say -- this is something you are going to do ONCE, who cares how long the text file transfer takes? 10 seconds? 90 seconds? 15 minutes? BFD. What matters is that it be RELIABLE. CAVEATS: Since nothing is buffered, the target machine might drop characters inputting if it has to write to disk. This would screw up the transfer, and most likely debug will give an error when you try to load the hex file. Solutions: split the KERMIT.HEX file into multiple pieces on the donor machine; transfer each with COPY. Say you named them KERMIT.1H, KERMIT.2H, ... On the target machine, after they're all transferred, do: copy/a kermit.1h+kermit.2h+kermit.Nh kermit.hex And proceed. ALso consider transferring the hex file TWICE or more, and use COMP to check that they are the same; it's unlikely it will drop precisely the same byte each time, and errors will be visible. Drop to 300 baud for the transfer; this will raise the time you get to do disk writes, especially if the target has a 16550 UART. Again, I suggest not even thinking about the transfer speed if it's less than an hour or two.