[comp.sys.cbm] 1571 writes slowly on side 2

rferguso@gn.ecn.purdue.edu (Robert S. Ferguson) (03/28/91)

I have noticed that my 1571 writes more slowly on side 2 of a disk.  
After each sector is written, I can hear the head move, then move back into
place.  The disks were formated with that same drive, and it seems to occur
only when writing to side 2 of a disk.  What I want to know is, is this a
problem with all 1571's, or just older ones? or is it just mine?  Can it 
be fixed? 

<boB<
-- 
 Where's the KA-BOOM?                           | Robert Ferguson
 There was supposed to be an enormous,          | rferguso@ecn.purdue.edu (or)
 Earth-shattering KA-BOOM!  -- Marvin Martian   | rferguso@gn.ecn.purdue.edu
 r-znvy-zr-vs-lbh-pna-ernq-guvf-naq-lbh-ner-n-grrantr-zhgnag-avawn-ghegyrf-sna

cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (03/28/91)

In article <1991Mar28.024743.16062@gn.ecn.purdue.edu> rferguso@gn.ecn.purdue.edu (Robert S. Ferguson) writes:
>I have noticed that my 1571 writes more slowly on side 2 of a disk.  
>After each sector is written, I can hear the head move, then move back into
>place.  The disks were formated with that same drive, and it seems to occur
>only when writing to side 2 of a disk.  What I want to know is, is this a
>problem with all 1571's, or just older ones? or is it just mine?  Can it 
>be fixed? 

This is a stupid bug in the original 1571 ROMs.  What's happening is
that every time a file allocates a new sector, the BAM block on side 1
of the disk is being read in, updated, and written out again.  This is
horribly slow.  The drive is supposed to simply keep a copy in RAM and
update after the file is closed, but it does not.

The solution is to upgrade your ROM.  You can get the upgrade from
Commodore (I think, no details here), or if you buy a replacement ROM
such as JiffyDOS, it will have the latest upgrades in place.

The upgrade will also fix (finally!) the save-replace bug.

-- 
David DeSimone, aka "Fuzzy Fox" on some networks.          /!/!
INET:    an207@cleveland.freenet.edu                      /  ..
Q-Link:  Fuzzy Fox                                        /   --*
Quote:   "Foxes are people too!  And vice versa."         /  ---

rferguso@gn.ecn.purdue.edu (Robert S. Ferguson) (03/28/91)

OK, so now I know the problem is due to old ROMs in my drive.  How do
I go about replacing it?  Does anybody have the part no., price, address
of where I can get a new one?  I don't have the $$$ for JiffyDos, at least
not yet. :-(  

<boB<
-- 
 Where's the KA-BOOM?                           | Robert Ferguson
 There was supposed to be an enormous,          | rferguso@ecn.purdue.edu (or)
 Earth-shattering KA-BOOM!  -- Marvin Martian   | rferguso@gn.ecn.purdue.edu
 r-znvy-zr-vs-lbh-pna-ernq-guvf-naq-lbh-ner-n-grrantr-zhgnag-avawn-ghegyrf-sna

andy@ccwf.cc.utexas.edu (Andrew Hackard) (03/30/91)

If I remember correctly, the problem is that many of the tracks on side 2 are
allocated by the BAM on side 1; when the 1571 writes a sector on side 2, it has
to go back to side 1 to mark the block as used.  I don't know why that would
make things so much slower, and I may be misremembering, so someone who is a bit
more familiar with the hardware probably can give you a more detailed answer.

--Andrew

cs4344af@evax.arl.utexas.edu (Fuzzy Fox) (03/30/91)

In article <46392@ut-emx.uucp> andy@ccwf.cc.utexas.edu (Andrew Hackard) writes:
>If I remember correctly, the problem is that many of the tracks on side 2 are
>allocated by the BAM on side 1; when the 1571 writes a sector on side 2, it has
>to go back to side 1 to mark the block as used.  I don't know why that would
>make things so much slower...

You've got it right.  The problem is that there is only room in the 1571
RAM to stores one of the two BAM blocks.  Also, some of the info is
stored in BAM block 1 (side 1), and some in block 2 (side 2).  The fact
that they are on the same track, but different sides, helps a bit, but
the main problem is that the head must seek to track 18 over and over,
which really slows things down.

The newer ROMs simply cache the BAM changes in RAM (as is normally done
when side 1 is being allocated), so the seek to track 18 is not needed
until the file is closed.

-- 
David DeSimone, aka "Fuzzy Fox" on some networks.          /!/!
INET:    an207@cleveland.freenet.edu                      /  ..
Q-Link:  Fuzzy Fox                                        /   --*
Quote:   "Foxes are people too!  And vice versa."         /  ---