19 Oct
2006
19 Oct
'06
1:28 p.m.
Chuck Guzis wrote:
Possibly, depending on cost. I'd hope that something could typically be lashed
together (parts cost only) for about 20 bucks, though using a combination of
purchased bits and things from the parts bin [1]. Beyond that and it's sort of
into catweasel territory (albeit with the convenience of an external device).
[1] 8 bit CPUs, SRAM from old PC motherboards, SIO chips, RS232 connectors,
cables, old SIMMs, old DIMMs etc. are all easily available for free. For a
design based around one of the common old 8-bit CPUs (say Z80 or 6502) the
main parts cost is probably the PCB itself.
On 19 Oct 2006 at 14:16, Jules Richardson wrote:
I don't see what it would gain you, though. You've still got the same amount
of data to transfer between host and device - and I bet someone can come up
with a situation where they'd want to just read or write a single track rather
than an entire image, which makes transferring an entire image wasteful
(particularly at RS232 speeds!)
Maybe someone can think of a situation where you *need* more than one track in
memory at once, though. (Note I'm not thinking at all about storage formats
which aren't track-based though)
I don't think you necessarily need anything
like that much; I remember Dave
Dunfield and I discussing this a while back and it worked out at something
like a couple of hundred KB I'm sure.
If you're going track-by-track, probably a couple hundred K is more
than enough. But holding a complete 8" DSHD image runs to something
like 6MB if you hang onto the whole histogram.
I think you'd definitely want to have enough storage to hold a
complete image--it'd make copying much simpler, no? Besides, a few megabytes of RAM is nothing nowadays.
DRAM, no. In that sort of situation providing a SIMM / DIMM socket would seem
the best bet and people can populate it with whatever memory they have to
hand. There is the refresh issue then, though.
I don't
know, what's a couple of hundred KB of memory, a CPU (say a Z80 for
sake of argument), a bit of ROM, and a serial interface chip, plus a bit of
glue logic?
Probably use something a bit more common, say an ARM? Not that I have anything against a Z80 (or Z180, or
EZ80). Just that extra
horsepower can be very nice, even if you don't need it right away.
Actually, a sister project (in a way) would be to oversample the raw data
stream from the drive heads in an attempt to read disks that otherwise
appeared dead, with software then doing the analysis of the waveform. I know
Dave has more than a few thoughts on that subject - and that does need a lot
more RAM and CPU horsepower to do.
For a 'simple' track-based design though I'd think that CPU choice comes
pretty much down to cost only, plus concerns about the average user's ability
to program the system with the necessary code after construction. (For
example, I can burn EPROMs. I could probably figure out how to program a PIC.
I would have absolutely no idea what to do with an FPGA, let alone be able to
contribute anything to the design :)
From the point of view of the host machine, the set of operations needed
isn't complex - something like 'assign parameters', 'read track',
'write
track', 'get error information', 'format track', 'seek', and
possibly
something like 'download firmware'. It shouldn't actually be a complex device
- but it is best left to someone who has experience of building SBC-like
devices :-)
Transfer speed is a huge headache - 200KB or whatever at RS232 speeds is
painful. Repeat for 160 tracks and it becomes rather annoying! (It suggests
that some sort of simple compression scheme is needed)
cheers
Jules