7 May
2007
7 May
'07
8:45 p.m.
On 8 May 2007 at 1:41, Philip Pemberton wrote:
Jules Richardson wrote:
I don't think there's anything that can't be handled with a DC-37
connector--and that's with 4 drive selects. You don't need the
separated data from 8" drives, so let's look at what signals you do
need:
DS0
DS1
DS2
DS3
MOTOR ON or HEAD LOAD*
SIDE SELECT
INDEX
TRACK 0
STEP
DIRECTION
READ DATA (RAW)
WRITE DATA
WRITE GATE
WRITE PROTECTED
SECTOR (if you want to use the 8" signal)
TG43
*Saying that both HDLD and MTRON are the same signal simplifies
accommodating 8" drives and doesn't hurt a thing.
16 signal lines + return = 32 pins. Some NEC 3.5" floppies have some
very strange "extra" signals, but they're the only ones I'm aware of.
Similarly, some early 8" drives wanted 3-phase stepping signals, but
I haven't seen a specimen in the last 20 years. Similarly, there are
drives with door locks and auto-ejects that can be ignored.
SImilarly, if you've got INDEX, you can derive READY yourself and you
probably don't care and don't want to deal with DISK CHANGED signals.
There's no point to using the 8" drive on-board FM data separator.
Why complicate things? Two DC-37 connectors will allow you to
control 8 drives and yet keep the cabling simple.
What OS are you going to end up driving this
from?
I dunno. If I have a lapse in sanity I'll write it in Java (which means it'll
run veeery slooowly on just about anything), otherwise I'll use it as an
excuse to learn wxWidgets (which means it'll run on Windows, Linux, OS X and
BSD, which covers about 95% of the market).
In any case, I want it to run on Linux as a bare minimum.
(It is on a PCI card
isn't it, rather than a USB interface?)
PCI?! PCI?! Why the hell would I do something as monumentally STUPID as that?
After all, the PCI-SIG's licence fees are 'just a bit' steep IMO :)
My plan is to do a USB version that's small enough to shove into a laptop bag
with a wall-wart and a 3.5" drive so that you can handle the "Joe Bloggs has
the discs, will let someone image them, but won't let the Royal Mail handle
them" type situations quite easily, while also being able to hook up adapter
cables to use other drive types (e.g. 8"). ST-506 is coming in Version 2 :)
Regarding earlier question about bringing some
address lines out to the
I/O connector... the logical choices I suppose are a 40 pin header or a
50 pin header.
Maybe. IDC headers are pretty cheap. I don't have many in stock ATM though -
just a couple of 34-way box headers and a few PC floppy cables.
> 40 doesn't seem like enough though assuming you keep odd pins as ground
> still; it's only another 3 pins, and won't you need one of those for the
> write precomp line for 8" drives? Speaking of precompensation, does anyone know anything
about the innards of
the 'write precompensation' (early/late/normal) stuff that's generally a part
of most modern floppy controllers? I'm curious to find out what that actually
does, and if I need to do it on my controller.
Generally write precompensation isn't used in FM mode. However, in
MFM, it comes into play on the inner tracks when domain edges get
"fuzzier", mostly as a result of the medium. To keep things as
distinct as possible, a clever kludge is used to either advance or
retard the start of a bit cell depending on current the bit being
written and the last two bits just written and the next bit to be
written:
Here are some common patterns and their precompensation (display this
with a monospaced font):
Bits just written Current bit Next bit Action
----------------- ----------- -------- ------
X1 1 0 Advance (early)
X0 1 1 Retard (late)
00 0 1 Advance
10 0 0 Retard
XX X X Nominal timing
The amount of precompensation on an 8" floppy is usually about 200
nsec. The logic for this becomes more apparent if you sketch out the
bit cells.
The usual way that precomp is determined in a controller is to run
the data stream through a shift register and use come combinatorial
logic to determine what should be done.
Typically, the data stream from most floppies is a bit "noisy"
(you'll see what I mean from some CW histograms). So you should have
the capability of rejecting a pulse that follows too soon after the
previous one. Better data separators can even fill in a missing
pulse if necessary.
Hope this helps!
Cheers,
Chuck