C. Sullivan wrote:
8"
is left as a bit more of an engineering exercise for the reader :-)
For my money, 8" compatibility would be VERY nice
Oh, absolutely. I merely meant that building a suitable mounting bracket
would be done on a per-case basis (were there ever companies officially
selling 5.25" to 8" drive brackets? I've never come across such a thing)
It is my understanding that there isn't much
difference between
5 1/4" and 8" electrically, so it might be a moot point.
Certainly it seems that driving a 8" drive using an 5.25" disk controller
isn't too difficult in a lot of cases. I don't know if the reverse is true
though, i.e. how easy it is to make the interface found on a typical 5.25"
drive work with a system that's expecting 8" disks.
I have a pair of teac fd55gfr (5.25 DSDD) drives running on a Monolithic
systems Z80 multibus board. I built a small board to handle the connector
difference. I used an AVR to generate the missing motor on signal.
It looks at the drive select signals and asserts motor on if any drive is
selected. It deasserts motor on after 15 seconds of no drive selected.
So i guess the short answer is it's not hard. I did it.
None of this is an issue for a storage dongle... It doesn't have a motor ;-)
To be
honest, I'd like it if the device did have a direct-link
capability to the outside world (whether it be RS232, USB, Ethernet,
parallel, SCSI, or whatever). But I'm not *that* bothered if it
doesn't; it's not that difficult to sneakernet a CF card back and
forth between the device and a modern system (except that I blew my
card reader up a couple of months back :)
My view was that the "1.0" version would have USB or similar.
Maybe; but it's not vital to operation as the intention would be for the
primary storage to be something like a CF card or a USB stick. Although
that is interesting; the primary store is a USB stick then it's presumably
easy to code the firmware so that the device can be plugged in via a cable
to a system running suitable host software as an alternative (providing the
device holds sufficient local memory to buffer a track and USB data
transfer to the host is fast enough to not upset whatever the floppy
emulator's plugged in to).
Of course I suspect that most of us on here (and in the context of vintage
hardware in general) are more comfortable with something like RS232...
Personally if I were building it I'd put an expansion bus connector on the
board and forget about any kind of host interface for the the initial
release; people can add daughtercards (and updated firmware) for their
favourite comms interface at a later date...
...
Understood. My intention was to make it work well as a drop-in drive
replacement, and add the other stuff as 'enhanced' features for a 2.0
(or later) device.
Complete agreement. Keep it simple for an initial release; just keep it in
mind what direction it *might* take in future, I suppose. Key for an
initial release would be getting it to act like a floppy drive *reliably*
and working with some form of local storage (personally I like CF, but then
I do tend to be a bit anti-USB :-)
If I knew
anything about PIC design* I'd get to doing some messing
around with it right now... :-)
A fast PIC could do it. I was leaning more towards something a little
more sophisticated (not that a PIC can't be), if for no other reason to
support the creeping features I pointed out above. Also, the floppy
timings on GCR formats can get a bit weird. FM/MFM should be fairly
easy.
That's interesting; personally I hadn't thought about GCR at all really.
The sort of thing I have stuck in my head right now has three small boards
to it:
1) A 'core' board containing CPU, a bit of addressing logic, some local
memory (whether a whole track buffer or not I don't know), LCD / switch
logic, ROM, and a header for future expansion.
2) A 'local storage interface' board, such as one holding a Compact
Flash connector and any control logic (I'd hope that most work could be
done in software)
3) An 'emulation' board containing the floppy side of things -
connector, buffers, and simple control logic (again I'd hope software could
do the necessary line twiddling.
The interface between the boards would just be an expansion bus;
essentially just CPU lines and a bit of selection logic. The key is that
such an approach allows someone to make the floppy-side 'emulation' board
totally different in future (along with a firmware change) to support some
completely different floppy electrical specification, or even make it look
to a vintage machine like some totally different low-speed data device.
Similarly, the 'local storage' side of things could be swapped for
something else; but the core elements of the device would be that it does
have some form of local storage (even if a remote host is connected via
some other comms interface), some form of interface board to a vintage
system, and that the 'core' board stays the same (with the exception of
firmware changes).
But, I'm not a hardware designer, so all of that is probably wrong. :-)
Hard-sector formats might even be easier, or
harder. Again, I
don't know enough about the signals to really know.
I suspect it's easy enough (but I don't know for sure). It can't be *that*
complex, but whether it needs a change in hardware, I don't know. But see
above - worst-case it's just a different emulation board.
I do a lot of microcontroller crap. I'm in
the middle of a move right
now (from Portland, OR to Billings, MT), so I don't have a way of
testing any theories right now.. but would definately be interested in
pursuing this as a project early in the new year once I'm settled here.
Anybody interested in starting up a mailing list specifically to start
napkin-drawing this thing? I have a listserv...
I just said that in a private email to Chuck a few hours ago, too :) I'm
all for it - personally what I wouldn't want to see happening is people
wanting millions of features from day one, though (that's what kills a lot
of theoretical discussions on here! :)
But a simple device that looks like an SA400/SA800 type floppy drive and
uses some form of 'portable' local storage, and has some reasonable
expansion options / future-proofing - yeah, I think that's probably
doable. It's not exactly Warren's dream of a 'portable to every system'
type device, but it's a still a darn useful thing to have and I suspect
would solve a lot of problems for a lot of people (particularly
longer-term).
Plus it should be reasonably trivial to provide 'floppy to simulator'
copying in the future without a physical vintage machine, which means that
for not much effort we get the ability to archive possibly-damaged disks
from vintage systems onto modern media. (I think Chuck was seeing that as a
feature of the simulator, whereas I was seeing it more as a simple box of
tricks which sat between the simulator and a physical drive to handle the
necessary signalling)
cheers
Jules
(all 'theorised out' today! :)