----- Original Message -----
From: Pete Turnbull <pete_at_dunnington.u-net.com>
To: <classiccmp_at_classiccmp.org>
Sent: Monday, March 27, 2000 5:30 PM
Subject: Re: Parallel port hard drives?
> On Mar 27, 19:57, Tony Duell wrote:
>
> > There is some wonderful confusion in this thread :-)....
>
> Yes :-)
>
> > The first is the standard density 48tpi drive. This is what PC owners
> > would call a '360K drive'.
> [...]
> > The second is the standard density 96tpi drive.
> [...]
> > The third is the high density drive, known to PC users as the 1.2Mbyte
> > drive.
> [...]
> > From this, it seems to me that a 1.2Mbyte drive will _not_ reliably
> > read/write a 360K format on HD disks. It will use the wrong (too low)
> > write current. HD disks should be used for 1.2Mbyte formats only.
> >
> > Of course when a 1.2Mbyte drive is set to use 'standard' disks, it in
> > fact behaves like the second type above -- a 98tpi (80 cylinder) drive
> > and not a 360K (40 cylinder) one.
>
Surely you mean 96 tpi . . . right? I'm curious ... How do you "set" a
1.2MB drive to behave as a 720-K drive, i.e. use that type of medium? It
seems to me that, at a minimum, the controller would have to be seriously
involved as well.
>
> Tony has put this very well. It's exactly what I was getting at.
> Furthermore, the media used in 96 tpi standard density disks is, in my
> experience, the same as that used in 48 tpi standard density disks. It
> even says so in my CDC drive manuals. However, as we all (ought to) know,
> the media for HD disks is very different.
>
The fact remains that there are diskettes specifically designated as being
96TPI-certified, "QD" presumably for quad density, since you get twice as
many tracks as with a double density diskette, which were, originally sold
at a higher price than the "360K"
>
> > According to all the data I can find (which is not much), the centre
> lines
> > of the 48tpi tracks and the centre lines of alternate 96tpi tracks
> > coincide. This means (amongst other things) that you can use the same
> > alignment disk for both types of drive.
>
This would follow but for the technique used for writing radial alignment
tracks.
>
> > It
also means that a 96tpi drive
> > can reliably read a disk formatted and written on a 48tpi drive (only).
> > When the 96 tpi drive's head is on a suitable track it is reading along
> > the middle of the track. It's going to read good data. That's why
there's
> > no problem reading disks that have been formatted/written in 360K drives
> > using 1.2Mbyte drives.
>
No dispute here!
>
> > Now lets consider going the other way.
>
> Tony and I are in very close agreement here as well. The only point I'd
> add, is this:
>
> Disks which have been written in 48 tpi drives, and not subsequently been
> bulk erased, may be read in a 96 tpi drive; and if then overwritten by a
96
> tpi drive, they will still be readable perfectly reliably by the 96 tpi
> drive, but often not by the 48 tpi drive. Just as Tony (and others) have
> said (and as I've been telling people for nearly 20 years). However,
there
> is a good reason that the process is sometimes observed to work to some
> extent, and that has to do with the way the tracks are written/erased.
> When the track is written, data is only written into the centre portion
> (about 50% of the nominal track width).
>
That's the typical straddle erase. The field of the erase coils nearly
overlaps in the center of the track. It does not generally erase a path as
wide as a 48 TPI drive's write path, however. Some 8" drives used tunnel
erase heads instead. These had a single erase coil in front of the
read/write head to erase the same region of the diskette that was being
written. If you ever happen to switch boards between drives with different
head types, things will behave quite mysteriously, as the timing is quite
different owning to the fact the erase operation has to be timed in advance
of the write, and stopped before the write head is turned off so there's no
dead spot on the diskette.
>
>
Either side of that, the erase
> coils in the head write a narrow guard band, which occupies most of the
> remaining track width. It may happen that the guard bands written by a 96
> tpi drive are wide enough to erase a large proportion of the signal
written
> by a 48 tpi drive, and a 48 tpi drive might just manage to separate the
new
> signal from the relatively low level of the residual old signal.
>
> I'm *not* advocating this as an excuse to write 40-track (or 35-track)
> disks in an 80-track drive without prior bulk erasure. But it explains
why
> some people have found it works for them (even before manufacturers
> streamlined the range of heads they made), though probably only with
> limited permutations of drives, and limited (at best) reliability.
>
> I'm well aware of the problems in switching between 48 tpi and 96 tpi. In
> the early '80s, I made and sold a little addon for micros that might need
> to read 40-track disks in 80-track drives. Because I was well aware of
the
> problem, I arranged it so that it could not only switch on double-step for
> one drive, but could separately switch one of the drive selects between
the
> normal connector and an extra one. The device was normally used on BBC
> Micros with twin 80-track floppies, and the extra connector was to connect
> a third, genuine 48 tpi, drive.
>
Quite a few early-'80's CP/M systems were shipped with a software-patchable
dummy disk parameter block in their BIOS to permit a 96TPI drive to READ 48
TPI diskettes. Naturally, they didn't normally disable the write function
on that same dummy drive, but most of them recommended against trying to
swap the diskette types indiscriminately, though many people tried it. The
results I had and observed in others' lack of success certainly support the
belief that the media were not the same. I normally avoided this by using a
96TPI drive for general read/write use and the 48TPI mode for reading only.
This worked very well, given that one had a hard disk. That way there was a
place to which to save a 48TPI diskette's contents before transferring them
to a 96TPI diskette.
> --
>
> Pete Peter Turnbull
> Dept. of Computer Science
> University of York
Received on Mon Mar 27 2000 - 19:44:43 BST