8 Dec
2006
8 Dec
'06
9:04 a.m.
On 8 Dec 2006 at 9:06, joseph c lang wrote:
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.
I guess I AM showing my age. My first impulse would have been to use
a 555--and the same for synthesizing a READY* signal if the drive
had no jumper to provide one.
Although using an AVR or PIC is also a great idea--just never thought
of using an MCU for such a simple job. Geezer's disease, I guess.
Cheers,
Chuck
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! :)