Machine Independent Storage Idea...
julesrichardsonuk at yahoo.co.uk
Thu Dec 7 15:45:10 CST 2006
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.
>> 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
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
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)
(all 'theorised out' today! :)
More information about the cctalk