As long as we're talking about it; here are a few more ideas to
consider.
1. The Catweasel uses a selectable clock rate to obtain a clock
count that will fit in 7 bits. My gripe with this is that I have to
read a track or two (if different densities on the same disk) to
determine the correct clock rate. There's little worse than finding
out that you've guessed wrongly and your image is worthless.
If we're going to employ a dedicated MPU/MCU to handle this stuff,
why not go with a 10- or 11-bit clock rate and get rid of the rate
selection? One of the spare bits could be used for index detection
on hard-sectored disks.
2. Some drive diagnostics should be incorporated. Particularly with
5.25" drives, old sticky floppies can really drag the rotational
speed down. I'd really like to know that it's happening.
3. I can envision this device as a small box, powered by a wall wart
with an RJ-45 ethernet connector and on or two DC-37 female
connectors for drives. Given that this thing's going to be used for
all manner of drives, there's no compelling reason to provide drive
power as part of it.
4. DHCP is a nice feature, but not all vintage networks support it.
The option of a fixed IP address (192.168.x.x) would be a plus.
5. Should the box also supply the drive for older 8" drive 3-phase
steppers? How about the head-load signal?
That's it for now--I'm sure I'll think of something else!
Cheers,
Chuck
Show replies by date
I'm collating all thoughts in to some form of 'pre-design' document at the
moment, which is at least a step further than we normally get with these
discussions :-)
Some questions that it's thrown up:
What values of data transfer rates do we need to support?
What drive rotational speeds do we support (although this is presumably
largely irrelevant, as a by-product of transfer speed and density select?)
Do we want to support 'extra features' like motorised eject? What about head
load/unload? Such things mean extra configuration and extra hardware (in that
some lines need to be able to work as either inputs or outputs depending on
config)
What configuration exists for a drive (sides, tracks, motor on/off delay etc.)
that needs to be stored?
How many drives do we want to support? Is it desirable for each drive to have
it's own connection to the device (rather than the typical 2 or 4 drives per
cable setup)? Do we even want to do something clever and modular so that each
drive has its own interface with unique I/O address and you just essentially
stack them up on the device's CPU address / data bus as needed?
cheers
Jules