8 May
2007
8 May
'07
2:12 a.m.
Philip Pemberton wrote:
:-) You know I'd assumed that there was some sort of "testing/hobbyist"
scenario where you could just do what you wanted without fear of stomping all
over commercial cards...
Scavenging from scrap I/O cards works well.
That's going from hazy memory of discussions on here... I'm rather new to the
8" drive game. I gather there's an interface line which gets toggled on at
least some 8" drives and tells the drive to do write precomp; I think this
line was replaced with another signal when things moved to 5.25" drives
though, so it's not available separately on the standard 34-way header.
:-)
Not really, but if you have 7 extra lines to play with it makes sense to set
aside a few of them for addressing.
Hook up an 8", 5.25" DD, 5.25" HD, 3.5" HD and 3" drive, and you
already need
three lines for addressing - that's before worrying about other oddball stuff.
Better safe than sorry...
[Out of interest, I wonder if this gadget will be able to drive one of those
floppy tape units? I've got no idea how their protocol works...]
Absolutely... hence the need for having lots of drives connected at once via
an addressing scheme. It just feels a bit 'cleaner' to have one drive per
cable and have termination set on all drives, somehow. But never mind, as the
way you're doing it, it should still work in that configuration anyway :)
Jules Richardson wrote:
It shouldn't be too bad to be honest - there's going to be a fair bit of
"wait
for user input" and "wait for device" in there, and Java tends to be
reasonable when processing raw data if there's not lots of thread
synchronisation and object creation in the way.
It might be let down by availability of bit-level operations, but then most
languages are...
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).
I was thinking GTK+ :-) But yeah, doesn't matter... a goal of portability's
the main thing to my mind. I'm not sure what device access is like under
Windows (particularly from Java) - from Linux / Mac it's probably just as
simple as opening an I/O stream and reading/writing.
(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
USB?! USB?! :-) Urgh... SCSI, please...
But seriously, yes an external device is probably more useful than an internal
card I think. And an external card can always be mounted internally anyway :-)
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"
Very good point.
ST-506 is coming in Version 2 :)
Hmmm. I'm not sure if the current implementation's quick enough though... you
probably need to be sampling at around 50MHz for ST506. But I assume there are
faster chips out there you can use?
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?
Argh, I'm going to have to read through those Shugart manuals again! 50 would give
you an extra 8 pins to play with[1] though. If one of
those is reserved for a write precomp line, that still leaves seven
unused. Say reserve four for addressing, and the other three for the
uses which we haven't thought of yet? ;-)
You're after sixteen addressable drives then. Ooookay... [1] Assuming
the ability to have two drives on the same cable as per
the PC standard... if you don't do that I suppose it frees up a couple
of pins of the 'standard' connector.
I'm keeping that in. I want to be able to hook up a 5.25" FDD and a 3.5"
FDD at the same time. Remember - I'm building this thing as a
combination analyser/imager (hence the name - Data Analysis and Recovery
Toolkit) with the primary goal being to be able to image 'odd' floppy
formats that a PC controller just can't touch. - Full decode support for Commodore GCR, Apple GCR,
PC MFM, PC FM, and
whatever other formats I can get hold of formatting specs for.
I saw some nice documentation about how M2FM worked *somewhere*. I'll shout if
I remember where it was now.
If/when I
release the hardware (I might do a small production run if anyone's
interested)
I'd have one in preference to a Catweasel board...
FWIW, by "decode support", I mean "take
the raw bitstream and turn it
into bytes, then decode those into sectors". I'm not doing filesystem
decoding, that can wait until later.
Definitely a separate project!
cheers
Jules
--
"What progress. It's almost as good as taping it... on tapes which self
destruct in seven days."
- Bill Bailey on the BBC's "watch again" service