----------
Category 5,  Topic 17
Message 16        Thu Mar 27, 1986
PFOUNTZ                      at 19:56 EST

About the problems with a 1571 when writing sequential files on the second
side of the disk.....
It has already been discussed that things get real slow, but nothing was ever
mentioned about how it is possible to modify your programs to completely
eleminate this slow down.  Here is what I have noticed....
When PRINTING into a seq or prg file, if that file is on the second side of
the 1571 drive, the drive has to seek to the center of the disk between
writing to each sector.  I suspect it is refreshing either the upper or lower
bam, exactly what is doing is not important, just that things get annoyingly
slow (and somewhat unreliable).  This slow down is not evident when SAVING a
program onto the second side of the 1571 disk, just when PRINTING to it.  It
does not matter if you are using BASIC or ML, or if you are in slow mode or
fast mode.  So the question is, WHY??  The following is what I have
learned.....
If when opening a write file, if you use a secondary address of 1 (same as the
save routine uses), then the slow down is eleminated.  Using a secondary
address of 1, FORCES this file to be a write file, and it defaults to program
file type but you can override that by appending a ,s for sequential filetype
if desired.  One more consideration, is that you must always open the write
file last.  That is, if you are going to have a read file open and a write
file open, make sure you open the read file first, then open the write file.
I have used this technique to modify Joe O'hare's VT 100 term for the 128 and
when writing my new 128 version of Library Utility and have not experienced
any adverse side effects.  When creating a library, it was not possible to
open the write file last, so it will still slow down there, but dissolving
files or using VT100 to download Xmodem or dumping my buffer to disk now works
at full speed, no matter how full the disk is.
I hope this information is helpful to some of you programmer types on here.
And if anyone has any more to add, please share it with us.
Greg Pfountz