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

From: Pete Turnbull <pete_at_dunnington.u-net.com>
Date: Thu Jan 6 14:19:20 2005

On Jan 6 2005, 9:30, Vintage Computer Festival wrote:
> On Thu, 6 Jan 2005, Dwight K. Elvey wrote:
>
> > >And the programmers were not smart enough to figure a way around
this
> > >because...why?
> >
> > It would have been trivial for them to adopt a simple
> > block transfer for serial binary at the begining. I suspect
> > that the reason they didn't do this was that they didn't
> > wan't people to transfer programs from machine to machine.

> Your theory would make sense in an alternate universe where the
floppy
> disk was never invented ;)

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
Received on Thu Jan 06 2005 - 14:19:20 GMT

This archive was generated by hypermail 2.3.0 : Fri Oct 10 2014 - 23:37:43 BST