Re: image to disk ?-- ways to transfer

[Rubywand <rubywand@swbell.net>]

Simon Biber writes ...
> 
> At 300 baud, each char takes 0.0267 s. At 1200 baud each char takes 0.0067
> s. What length char delays would you use? If you're setting char delays at
> 1200 baud, then unless they are less than 20 ms you are ending up slower
> than 300 bps anyway.
 ....

     Things are not quite that bad; but, yes, you can not just assume that
you'll get the full x4 speed boost at 1200 baud. The main limiting factor is
the time it takes to update the Apple II screen for a linefeed which occurs on
the bottom line.

     Given a Text dump which is not optimized for sending to the Apple II, you
must allow for the fact that nearly any character sent may be one which forces
a linefeed. Since a linefeed on the bottom line moves everything on the display
up one line, the entire display must be updated.

     On a 1MHz Apple II, the display update takes about 18ms. Allowing a small
margin for extra tasks (e.g. sticking the char in the input buffer), you can
probably figure that total 'character time' needs to be about 20ms. That is:
Send Time + Char Delay >= 20ms.

     Your times for char sends at 300 and 1200 baud seem to be based upon 8 bit
cells per char. Aren't the start and stop bits supposed to be included? This
would give 10 bits/char: 30 chars/sec (33.3ms/char) at 300 baud; and 120
chars/sec (8.33ms/char) at 1200 baud.

     If we take 6.7ms as the time per character, the char delay would need to
be about 14ms. This gives a total char time at 1200 baud of at least 20.7ms.
You would get about 48 chars/sec. If char time is 8.33ms, the total time would
be 22.33ms for about 45 chars/sec.

     Since we have allowed time for a full display update in each char send,
the delay setting for an actual end-of-line-- i.e. end of a "line" of entries--
does not need to be very large. (Aside from a screen update, the Apple II needs
to convert and move the contents of the input buffer to memory. This is a
fairly speedy operation.)  Something like 20ms should be plenty for the Line
Delay.

     So, you may get only 44 chars/sec at 1200 baud using Hyperterm to set char
and line delays; but, that is notably better than 30 chars/sec at 300 baud.

     The improvement is somewhat better for a faster Apple II. For instance, a
IIgs on the "Fast" setting takes 8.8ms to update the Text display. A char delay
of 3ms (and line delay of 10ms) gives something close to 88 chars/sec.

     On the other hand, doing a send at 300 baud with no delays involves less
hassle; and, not that many files need to be sent as Text dumps. Once you have
DOS 3.3 and ADT (or maybe, a telecom terminal program) on your Apple II, you
can (usually) reliably transfer files at 9600 baud or better and forget about
low speed Text dumps.



Rubywand