7 Dec
2006
7 Dec
'06
4:02 a.m.
Fred Cisin wrote:
Ah, we've been here before.
Several times :-)
Is it better to store undecoded data streams (like a
Catweasel) or
the decoded data? My inclination is to deal with raw track data
without attempting to interpret it. Requires quite a bit more memory
to store data, but has fewer limitations.
Yeah I guess one way is the
"embedded systems" approach and the other
is a desktop approach. For archival purpose I think your idea is
better. For daily use (the SVD is a "peripheral" that travels between
machines) I think the decoded data is probably better. For a "universal disk storage" device or
format, you need to have the
capability of three different levels
1) files
2) sectors
3) flux transition
+ software to convert both ways between all three
The latter point's the important bit, I suppose. If you merely want a
replacement for failing floppy disks, then surely flux transition storage /
playback is sufficient?
I'd imagine that such data probably compresses reasonably well (say for
archival purposes), too.
But (as you say) to actually *do* anything more constructive with the data at
the sector level (such as convert to other disk image formats) you need to be
able to decode the flux transitions based on knowledge of what low-level
encoding scheme was used for a particular image.
Similarly at the file level (such as viewing / copying files to other
filesystems) you need tools that can both decode the flux transitions based on
encoding scheme, and decode the filesystem based upon whatever system the
image is for.
Personally I'd be inclined to go for a device that just handles raw flux
transitions at the moment and worry about manipulation tools further down the
line; the priority right now is likely for something that can replace floppy
disks on vintage hardware, not for some bells and whistles tool that comes
with a big software suite for data manipulation.
Having said that, as a test does anyone have the tools available to record a
disk image at the flux transition level with suitable oversampling? It'd be
interesting to see how difficult it is in software to engineer that back to
sector-level data (filesystem-level we know isn't a problem!).
#3, flux transition ideally calls for the device to
have an SA800/SA400
interface, and would not require any additional software on the machine.
My gut feeling is that's the sensible way to start, with other interface types
being supported further down the line. Just keep in mind when designing the
hardware and firmware that an SA800/400 interface isn't the only type that we
may want to support in the future.
Of course if there are people with non-SA800/400 drives on board and with
suitable technical knowledge then there's nothing to stop them being supported
from day 1 - but I suspect that most people will be
more familiar with the
SAxxx drives.
Since conversion between USB interface and memory
cards is readily
available, either would do. But, howzbout RS232 and/or "centronics"
parallel?
I do think that a comms mechanism between device and more modern machine would
be nice, purely to save swapping 'local storage' (CF, USB stick, whatever)
around so much. However, I wouldn't think it vital for an initial release (or
any kind of proof of concept).
Note that I am hoping that a CF card (or USB stick) has fast enough data
transfer rates so that the gadget doesn't actually *need* a big pile of local
memory - it can just operate to/from the card/stick direct. In other words,
the card/stick isn't just a means of getting data to the device - it *is* the
device's local working storage too.
That's perhaps not in keeping with what others are thinking - but personally
I'd prefer the lower complexity / cost / parts count / development time if it
can be shown that there's no actual need for local memory (other than the
obvious few bytes of operating RAM - which with something like a PIC is quite
possibly all on-board anyway)
cheers
Jules