1571 DOS issues

[bill.mann]

There are a couple of curious bugs in the 1571 disk drive DOS:

1. If the drive is in the 1541 mode, it can read any file wholly contained on
the first side of a diskette formatted in 1571 mode - it can also write a file
if there is room for it on the first side.  However, doing a "validate"
operation (v0 command), which updates the BAM, also screws up the "single/
double" side flag and makes the diskette appear to be in 1541 format (i.e.
attempting to access the second side in 1571 mode will fail).  Of course, now
that you know this, and if it happens by accident, you can always use a
disk sector editor to go fix up Track 18, sector 0 so the flag will again
indicate double sided.  Doing a "validate" in 1571 mode works ok, so I suspect
this is less of a bug and more of a necessity for 1541 compatibility.

2. If the drive is in 1571 mode (double sided), attempting to write a new
file using any channel other than 0 or 1 causes the drive to write much more
slowly once it is writing on the second side of the diskette (ie. the disk is
more than half full); the head constantly bounces back and forth between the
track being written and track 18.  It appears that the BAM is being updated
once for every sector written instead of once for each track written as it is
on the front side or if channel 1 is used.  The file seems to still be written
correctly, just *very* slowly.  This is evident with many word processors
(those which do not use PRG files), since they do not use channel 1 (having
been warned not to in the 1541 manual).  You can demonstrate this for
yourself using the following BASIC program (remember, if you are using a C64
or the 128 in C64 mode, do an OPEN 15,8,15,"U0>M1":CLOSE15 first and make
sure you have a 1571 formatted diskette in the drive)

        10 open 2,8,2,"file1,s,w"
        20 a$="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
        30 a$=a$+a$: a$=a$+a$
        40 for i=1to800
        50 print#2,a$;
        55 print i;
        60 next
        70 close 2

Now run this once on an empty diskette and you should get about a 400 block
file on the front side of the diskette.  Change the file name to "file2,s,w"
and run it again.  This time, after it writes about 250 blocks and fills up
the front side, it will lapse into super slow mode.  If you scratch both
files or reformat the diskette, then repeat this exercise with statement
10 changed to open 2,8,1,"file1,s,w" (i.e. use channel 1, the write only
channel), it will work without the slowdown when it writes the second file.

3. It is reported that the undocumented command "U0>H1", when issued to the
1571 when it is in 1541 mode, will cause subsequent 1541 operations to access
the second side of the diskette as if it were a single sided 1541 diskette.
While this may be true, if the diskette in the drive at the time has nothing
written on the second side (i.e. it is either brand new or has only been for-
matted by a 1541 in the past), the drive, upon getting this command, goes into
a self destruct mode with much gnashing of internal moving parts and a lot
of horrible sounding noise!  If you must use this wierd mode, it would probably
be best to only try it on a diskette that had been formatted on both sides,
preferrably by the 1571 itself in 1571 mode.  But formatting each side in
1541 format in this way yields a very strang diskette indeed: the second side
cannot be read on a 1541 at all, and only on the 1571 by using 1541 mode and
giving this strange command.  So, you're probably better off not doing this,
but just using 1571 double sided mode all the time you don't care about 1541
compatibility.  Note that to get into 1571 mode from a C64, you *must* issue
the "U0>M1" command to the command channel.

4. When the 1571 (in 1571 mode) tries to read a 1541 formatted diskette with
nothing recorded on the second side, it acts like it is getting read errors
for about 5-10 seconds before successfully reading (e.g. the directory).  There
is nothing wrong with this, I suppose, but it makes commercial software for the
128 (distributed on single sided disks for 1541 compatibility) take a bit
long to load.

[Stephane Richard]

Very informative stuff here.   Now to see if these were also reproduced in WinVice hmmm would that be good or bad? ;-)

[6502Dude]

Very interesting info!

Are these problems present in 2nd version of 1571 DOS?

[Blacklord]

Very interesting info!

Are these problems present in 2nd version of 1571 DOS?

I believe this issue was fixed in the second release - memory prompts that the problem was rectified.

I've got both versions of the drive - might do some testing here at some stage.

cheers,

Lance

[RobertB]

Are these problems present in 2nd version of 1571 DOS?

Yes, the upgrade ROM corrects those problems.  In fact, JiffyDOS corrects two or three more problems that the upgrade ROM does not address.

Truly,
Robert Bernardo
Fresno Commodore User Group
http://videocam.net.au/fcug

[Blacklord]

Hi Robert,

Are these problems present in 2nd version of 1571 DOS?

Yes, the upgrade ROM corrects those problems.  In fact, JiffyDOS corrects two or three more problems that the upgrade ROM does not address.

Yep, my own tests show that the problems don't exist in the later ROMs - can't say for JiffyDOS though - don't have it & it's pretty well impossible to get here in Oz

cheers

Lance

[Edwing]

There's another advantage of JiffyDOS 1571 concerning double sided disks: It always reads the second side even when in 1541 mode, so disks that have been "wrongly validated" by 1541's or 1571 with an early ROM cannot pose a problem. :cool:

By the way, concerning "U0>Hx": I once read of a program which will (by means of low-level GCR controlling) format and access a disk "backwards" after switching into the H1 mode which, combined with the "naturally backwards" structure of it means writing it "in the normal direction" again.

For some reason related to hardware the inner three tracks cannot be accessed but apart from that, it is actually possible with this to access both sides of a 1541 flip disk in a 1571 drive without turning the disk over!

What a pity that "flip disk emulation" wasn't incorporated into hardware (i.e. the DOS) so 1571 users could have used the same 1541-formatted flip disks without having to ever turn the disk! (Well, flip disks never were designed that way officially, I know. If it hadn't been for GCR not using the Index hole, it wouldn't even have been possible... Ever saw an MFM, e.g. CP/M, flip disk? I guess you never will. )

Greetings,
George