Machine Independent Storage Idea...

Jules Richardson julesrichardsonuk at
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 
> 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 
    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 mailing list