Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.sys.tandy    |    Life is dandy cuz you're gettin a Tandy!    |    5,684 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 5,001 of 5,684    |
|    Frank Durda IV to All    |
|    Looking for binary file xfer from TRSDOS    |
|    21 Jan 09 23:02:41    |
   
   From: uhclemLOSE.feb09@nemesis.lonestar.org   
      
   I am looking for a way to move a substantial number of binary   
   files from real Model 4/4D/4P systems and media to something   
   modern, be it MS-DOS, FreeBSD or some other UNIX variant, or   
   even Windows. (From any of these I can get the files to the   
   desired destination.)   
      
   In the past I have used Supercross to place files on   
   diskettes compatible with MS-DOS, but I have files that are too large   
   to move on a single diskette and there are a lot of them.   
   (That would be the case even if the files were compressed first.)   
      
   I tried using Kermit to move these via the serial port, but found it   
   was unreliable for text files, with five consecutive transfer attempts   
   typically yielding three copies of a given file that matched one   
   another, despite kermit saying all five transfers were successful.   
   Plus, the three that did agree didn't always match the original back on   
   the Model 4. This was the case even when the kermit transfer claimed   
   0 errors/retries.   
      
   When it came to binary files, I have been unable to make kermit   
   not trash any binary file attempted in some way. Even when multiple   
   transferred files matched one another, they NEVER match the original.   
   Now, I have not used kermit in 25 years so I may be missing   
   something you didn't have to do back then, but I got the latest available   
   versions, and setting binary and believe I set everything possible   
   to force it to not screw up an otherwise clear 8-bit no parity   
   connection (far more than the "Oh just type 'send filename' and it   
   works" stuff that is claimed in the documentation), but it is still   
   adding a percent or so to the size of each binary file attempted.   
      
   If someone knows the way to get kermit to pass the binary data verbatim   
   and actually detect and recover from transmission errors, let me know   
   what settings you are using. The Model 4 kermit used above was:   
    TRS-80 Model 4(p) TRSDOS 6.2 - KERMIT - Version 5.2   
   and the destination (FreeBSD) kermit was:   
    C-Kermit 8.0.211, 10 Apr 2004, for FreeBSD 4.0 Numeric: 800211   
   I also note the Model 4 kermit has a memory leak and can only   
   transfer so many files before it starts returning "Illegal drive number"   
   and other nonsense errors.   
      
      
   So assuming Kermit isn't going to work, I recalled that someone had done   
   a dumb version of Z-modem or maybe it was X-modem , but I have not   
   located either. Iras web site vaguely hints that one exists, but   
   of course doesn't provide any hint as to where it might be obtained.   
      
   I could do this project with ALTRAN as it does reliable binary   
   transfers, but I don't want to get a Model II TRSDOS system as   
   yet-another step in the transfer process. I would have to move the   
   files to a Model II TRSDOS/TRSDOS-II, then transfer them to floppy again   
   (size limit), or on a dual-boot system transfer them into XENIX,   
   then uucp them off the XENIX system. That is way too much work and   
   too high a risk of trashing a file at one of the many steps.   
      
   I don't need speed (although being able to run unattended is important   
   if it is going to be very slow), but I need the destination to get   
   exactly the same bytes that were in the files on the Model 4/4D/4P.   
   The biggest files are 6Megabytes or so, but most are the 300-800K range.   
   The method of transfer can be via serial, by breaking large binary files   
   up into smaller ones that will fit on many floppies and that can then   
   can be seamlessly reassembled at the destination ('tar' for the   
   Model 4/4D/4P perhaps?), use handshake lines on the serial or printer   
   port, you name it. Almost any medium is okay, it just has to be reliable   
   and do binary transfers perfectly.   
      
   So, what do you use for moving binary files larger than a floppy   
   off of a REAL - not an emulation - Model 4/4D/4P?   
      
   If there are no workable suggestions, I guess I will have to write   
   something to do this, but I'd rather use something that already   
   works. Suggestions appreciated.   
      
      
   Frank Durda IV - send mail to this address and remove the "LOSE":   
   
|
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca