Another disk imaging project

[Jules Richardson]

On Wed, 2005-08-03 at 12:50 -0500, Doc Shipley wrote:
> Dave Dunfield wrote:
> > 
> > lots of other arguments snipped.
> > 
> > Ok - I don't need to get dumped on anymore. Consider the idea dropped...
> 
>    Umm, please no.  I've been staying out of this because I don't have 
> the hardware skills or the knowledge of formats to contribute, but I do 
> have an opinion, or at least I see some factors that make your idea 
> desirable.
> 
> 1)  The first point is something Dave already touched on - there is no 
> One True Solution here.  I rad Dave's proposal and I envision a *group* 
> of products, all based on the same basic framework and each supporting 
> more-or-less similar formats and media.
> 
>    It might theoretically be _possible_ to create a device that will 
> read every floppy format ever devised, but why on earth would that be 
> _desirable_?  Such a logical behemoth is bound to be extremely complex 
> and expensive, and most of its features and formats will be useless to 
> most of its users.

picking up on that one... presumably the hardware copes with a huge
majority of formats out there if it can handle hard and soft sectored
floppies by buffering raw data at the track level? It's the software
which then dictates how many formats can actually be interpreted, but as
far as the hardware's concerned doesn't it just need to be able to shunt
data around between disk / buffer / host with no interpretation of what
the data actually is (OK so there's a bit of extra logic there to do the
right thing for hard sectored floppies)

In other words, would it actually be a logical behemoth? 

> 2)  *Any* hardware solution for archiving/migrating/transcribing media 
> is going to be, financially, a negative-sum project.  I think that's a 
> given.  As interested parties, we need to expect it to be Not Cheap, at 
> least initially.  I'm speaking in terms of time as much as money.

Agreed. I couldn't care less about the time aspect (providing it gets
done before all floppies on the planet have rotted :)  but I'd rather
something that didn't require expensive ICs or programming tools (for
the hardware controller side)

> 5)  (Go ahead and shoot me now.)  I see absolutely no reason to base an 
> SBC archival tool on Z80, 8008, or any other classic platform, unless 
> that directly facilitates its function.  This is a tool, and should be 
> built from the most efficient and available components.

My only reason for saying that was really cost / complexity grounds. Eg.
most of us who can throw a few bits of electronics together and see the
need to archive things will have access to an EPROM programmer. That's
probably less true of PIC programmers or other more modern devices. Old
8 bit CPUs are easily obtainable free in scrap equipment (and easily
understandable and well documented); the latest whizzy all-in-one IC
might well be expensive and a nightmare to program for anyone not
familiar with it.

*but* at the end of the day complexity's important too. An old 8 bitter
won't be fast enough without support hardware to read/write between
floppy and buffer memory, nor will it address the whole buffer in one
go. That may well dictate the use of a more modern 16 bit chip running
at several tens of MHz... but it depends how complex surrounding
hardware would be otherwise.

> 6)  There's not a chance that everybody is going to get everything they 
> need from the first iteration of this project.  Anybody remember The 
> Search For The Perfect Archival Format?

Well, once we have the hardware in place it can flourish :-)

cheers

Jules