On 17/04/02 at 23:50 Phoebus Dokos wrote:

[Floppy connectors]

> Hmm so two drives can work simultaneously (theoretically?)

Surprisingly, yes! In fact, the NEC 765 controller (the same core is used
on many PC based controller chips, including ones used on GC/SGC) can do
parallel head positioning by using multiple selection (for instance, if
drive 1 has to move 40 tracks and drive 2 60 tracks, both drives are
selected at the same time for 40 tracks and both move 40 tracks, then drive
2 is selected for the remaining 20) but AFAIK this was never used and does
not appear in later incarnations of the same FDC core, especially within
highly integrated IO chips.

> Wouldn't that affect the data transmission?... IIRC there's no way to
> distinguish where the data is coming from on the Shugart I/F

Correct. Data would be logically OR-ed (looking at the signals one would
expect AND-ed because they are active low, and if any data out is low, then
the controller sees low since all data outs on all drives are in parallel
and open collector), but the data is actually inverted. For all intents and
purposes, data would be corrupt. However, you CAN write data in parallel.
In theory, you could do the write portion of format for both (or more)
drives at the same time.

IIRC newer versions of the 765 controller have encoded select bits in the
registers (two, to decode to 4 drives), but the chip itself most certainly
has 4 separate outputs. Now, depending on the chip itself, these can be
used in different ways (some can even have the usage selected based on
control reghisters in the chip). On the chip used on GC/SGC, they can be
set independently so any combination is possible in theory. On a more
recent IO chip with many functions built-in, due to the limitation on
number of pins, usually PC speciffic DS1, DS2 and MOTOR1 MOTOR2 are
present, and they can only be set in speciffic patterns.

> So theoretically with the right twist you can access the drives even if 
> they are prejumpered for DS1 right? (which brings me back to these IBM ED

> drives we talked about a while ago).

Correct. But it's a bit more complex than that. Some drives detect density
and signal to the controller and their own internal circuits, some expect
the controller to select density for them (using mode pins) and (maybe)
pass the density encoding to the controller. Also, there is the disk change
signal, which again may or may not be generated by the drive or expected by
the controller. This all used to be set using jumpers. Of course, where
there were jumpers, you had the problem of figuring out which ones do what,
so a lot of trial and error may have been needed to make it work. Now that
there are none, the problem is worse because you have no idea what it's set
to, and no way to change it on the drive, you can only manipulate signals
on the cable.

BTW density and/or mode pins (don't remember off the top of my head) are
quite non-standradly set to odd pin numbers, which are by the standard, all
ground, so using a drive that expects control on them on the QL will always
result in whatever density is set by those pins being tied to ground,
unless appropriate lines on the cable are cut. AFAIK QL controllers do not
have density pins (they expect the drive to take care of itself) and
density detect is by trial and error (ditto maximum head positioning speed,
hence things like FLP_JIGGLE).

Also, some combinations of density as generated by the controller and as
expected by the drive based on what it finds from the holes on the disk,
will not work. In general HD drives often, and ED drives always require the
detect holes on the disk to match the density the controller is trying to
use. This is important when formatting disks to a lower density or in a
higher density drive. Normally, formatting SD in a DD drive will work just
fine because it's just the encoding of data that changes - the data rate
does not. Formatting DD in a HD drive without plugging the HD detect hole
on the disk may be just luck - for HD the data rate and some other
parameters are different. In this case the 'DD' disk (HD formatted to DD)
can be read in a HD drive, but is unreliable or completely unreadable in a
real DD drive. HD disks formatted to DD need to have the HD detect hole on
the disk plugged up to work right. Formatting ED drives as anything but ED
without appropriately manipulating the holes on the disk will make them
unreadable for sure on non-ED drives, and unreliable on ED drives. This is
because ED uses a mechanically different method of recording, so the
magnetic patterns on the disk end up being different, although the
electrical encoding may be as intended for a lower density.

Asside: Phoebus, I would sure like to get the ED drives working because
they were made while Christ was still walking this earth so the quality is
still there, unlike today's drives made out of recycled chinese metal
children's toys...

>BTW: Nasta as it getting a little late and I am kinda lazy (what else is 
>new?) I am telling you here, that when you fix the QubIDE, send it
>directly to Dave so he can have it for his testing until he finishes the
>project. Unless you and Dave already covered that aspect.

This is the first word about it that I've heared but that's OK. I will do
as you ask.

Nasta

Reply via email to