10 Mar
2005
10 Mar
'05
3:33 p.m.
Just futzing around with this Manta board (SCSI floppy controller).
The docs I have say that pin 2 of the floppy connector is normally an
input to the controller from the drive, but that some drives expect pin
2 to be an output to the drive from the controller (e.g. for changing
rotation speed on a drive capable of 300 and 360rpm)
That sounds wrong to me; surely most drives either don't use pin 2 for
anything, or they expect it to be an output from the controller (to cope
with things like speed changes)
What drives use it as a signal driven by the drive, and what for?
I'm tempted to ignore the docs I have and configure it as an output from
the controller - I'd just rather not blow up a drive or controller
board :-)
cheers
Jules
10 Mar
10 Mar
5:29 p.m.
From: "Jules Richardson" <julesrichardsonuk at yahoo.co.uk>
Sent: Thursday, March 10, 2005 2:33 PM
Just futzing around with this Manta board (SCSI floppy
controller).
The docs I have say that pin 2 of the floppy connector is normally an
input to the controller from the drive, but that some drives expect pin
2 to be an output to the drive from the controller (e.g. for changing
rotation speed on a drive capable of 300 and 360rpm)
That sounds wrong to me; surely most drives either don't use pin 2 for
anything, or they expect it to be an output from the controller (to cope
with things like speed changes)
What drives use it as a signal driven by the drive, and what for?
I'm tempted to ignore the docs I have and configure it as an output from
the controller - I'd just rather not blow up a drive or controller
board :-)
cheers
Jules
I have a webpage describing disks and disk drives.
Pin 2 on a 34 pin floppy connector is a little used pin. It was used to
change the RPM on some 5.25" 1.2mb drives.
It changed the RPM from 360 RPM (pin 2 high) to 300 RPM (pin 2 low). This
was supposed to make it easier to read/write DD disks in a HD drive.
Only early AT controllers needed it, later controllers kept this pin high
and used an odd transfer rate.
Randy
www.s100-manuals.com
5:55 p.m.
On Thu, 2005-03-10 at 16:29 -0600, Randy McLaughlin wrote:
I have a webpage describing disks and disk drives.
Yep - most useful it is too! :-)
Pin 2 on a 34 pin floppy connector is a little used
pin. It was used to
change the RPM on some 5.25" 1.2mb drives.
It changed the RPM from 360 RPM (pin 2 high) to 300 RPM (pin 2 low). This
was supposed to make it easier to read/write DD disks in a HD drive.
Only early AT controllers needed it, later controllers kept this pin high
and used an odd transfer rate.
Interesting. I'd always assumed that 1.2MB drives always changed the
speed too.
I was pondering earlier how much memory it'd take to buffer a whole raw
track of data; presumably the maximum would be a 1Mbps rate at 300rpm
rotation? (and say sample at 16x, plus store some form of clock info. It
still doesn't work out that bad).
I'm sure it must be possible to build some gadget that'll hang off a PC
parallel port and buffer data to local (static) RAM, allowing slower-
speed transfer to/from the host machine. Hopefully without needing
microprocessor control (i.e. bunch of RAM, few counters or something :-)
Maybe there's some reason it can't be done - otherwise I'd expect
someone would have done so by now! :-)
cheers
Jules
8:18 p.m.
Jules,
I proposed doing exactly that (i.e. passing "raw" floppy data through a
parallel port) last year along with some simple math that showed it could be
done. The concept was "poo-poo'd" by some, but in the real world it has
been
done already to image the following; Amiga (".ADF"), Apple disk ][
(".DO"),
Atari ST (".ST"). Commodore 1541 (".D64"), PC (".IMG") and
single-density (".DSK"). The URL for the write-up and software is;
http://disk2fdi.joguin.com/D2FCABLE.htm
Very cool! Best regards, Steven C.
On Thu, 2005-03-10 at 16:29 -0600, Randy McLaughlin
wrote:
This
I have a webpage describing disks and disk
drives.
Yep - most useful it is too! :-)
> Pin 2 on a 34 pin floppy connector is a little used pin. It was used to
> change the RPM on some 5.25" 1.2mb drives.
>
> It changed the RPM from 360 RPM (pin 2 high) to 300 RPM (pin 2 low). > was supposed to make it easier to read/write DD
disks in a HD drive.
>
> Only early AT controllers needed it, later controllers kept this pin
high
and used an
odd transfer rate.
Interesting. I'd always assumed that 1.2MB drives always changed the
speed too.
I was pondering earlier how much memory it'd take to buffer a whole raw
track of data; presumably the maximum would be a 1Mbps rate at 300rpm
rotation? (and say sample at 16x, plus store some form of clock info. It
still doesn't work out that bad).
I'm sure it must be possible to build some gadget that'll hang off a PC
parallel port and buffer data to local (static) RAM, allowing slower-
speed transfer to/from the host machine. Hopefully without needing
microprocessor control (i.e. bunch of RAM, few counters or something :-)
Maybe there's some reason it can't be done - otherwise I'd expect
someone would have done so by now! :-)
cheers
Jules
11 Mar
11 Mar
7:26 a.m.
On Thu, 2005-03-10 at 17:18 -0800, Steven Canning wrote:
Jules,
I proposed doing exactly that (i.e. passing "raw" floppy data through a
parallel port) last year along with some simple math that showed it could be
done.
Yep, I hadn't forgotten :-) (I made sure I kept all the relevant
messages too)
Wasn't the problem that the parallel port just doesn't have the raw
speed for it to work for all disks though? At which point buffering
becomes necessary, which was also the point that everyone went quiet on
the subject :-)
With the cable you mention, how are you supposed to get the created disk
image back onto a disk again? (Personally I need to be able to restore
data from an image back to a floppy)
I need to do some reading up on what the floppy drive's write gate
signal does. If spitting data from an image down the 'write' signal wire
at the same speed as it was read is good enough (and 'write gate' is
actually a 'R/-W' signal) then maybe it isn't too complex. However if
write gate is actually dependant on the data stream too (needing it to
be understood) then it could be rather tricky.
Note that personally I *don't* need to understand the image on the host
machine (at this stage) - all I care about is backing up floppies to
modern hard disk and being able to recreate them again. Understanding
via software decoding might be nice one day, but in the shorter term my
concern's with all the thousands of disks we have at the museum with
data on that are likely decaying...
cheers
Jules
7069
days inactive
7070
days old
4 comments
3 participants
participants (3)
-
cannings＠earthlink.net -
cctalk＠randy482.com -
julesrichardsonuk＠yahoo.co.uk