Importing binary files without removable storage nor non-bund led software (was: TKermitFTP

This is the exact same method that's used to initiate the install of ADT, the Apple Disk Transfer utility that's used to get Apple II disk images over a serial link to a PC for archiving and use with emulators. I believe that DOS has something similar which redirects the CTTY device to COM1: (CTTY=COM1: or something like that). CTTY is the DOS shorthand for the console terminal (screen and keyboard). Obviously this works only in text-only DOS. -----Original Message----- From: cctalk-bounces(a)classiccmp.org [mailto:cctalk-bounces@classiccmp.org]On Behalf Of Pete Turnbull Sent: Thursday, January 06, 2005 3:19 PM To: General Discussion: On-Topic and Off-Topic Posts Subject: Re: Importing binary files without removable storage nor non-bundled software (was: TKermitFTP On Jan 6 2005, 9:30, Vintage Computer Festival wrote: this floppy I think the reason is simpler than Dwight implies, and more along the lines of John's comment. Microsoft were in a hurry to make DOS work for IBM, and there was simply no perceived need to add the functionality. If you look at CP/M-related and Apple ][ systems, you see they had (er, have) the same problem: no out-of-band way to signal end of file. Several versions of kermit for Z80 machines and Apple ][s therefore come with a little program to talk from a remote machine to the serial port, start debug or equivalent, and stuff an ASCII-converted copy of kermit over which debug then saves in executable format. I've still got the ASCII HEX files for an Apple ][. As far as I remmeber there are two ways to get Kermit-65 onto an Apple. The first way is to type "IN#2" to set he serial card as the input, and then on the remote machine give the command to send the main file. It starts with "CALL -151" to jump into the monitor, and then follows that with a series of lines like "E00:38 A5"... which cause those bytes to be stored in memory; then it calls the code it's just stuffed in, and that in turn loads a huge number of much more compact (no addresses, no spaces) lines, before finally issuing a "3D0G" to get back to BASIC. Ditto for the serial card driver's HEX file. Finally you type "PR#6" so output goes to the disk, and you EXEC the two HEX files to create the actual binary as a disk file. Easy ;-) The other way is superficially simpler; you type IN#2, transmit a small file which creates a BASIC program and runs it; that program receives and saves the two HEX files, and then tells you what to do with them. Seems slightly simpler, but actually takes a lot longer, as I recall. -- Pete Peter Turnbull Network Manager University of York