4 Nov
2013
4 Nov
'13
12:21 p.m.
On Nov 4, 2013, at 13:39, Al Kossow <aek at bitsavers.org> wrote:
Probably. Since what you're dumping is low-level formatted,
it's not like it'll be a straight file system dump that you could
e.g. easily use with an emulator. You could do that too, if
you wanted, but then you're adding the support of a specific
low-level format on top of a specific bit-level coding scheme,
which means another multiplication of the number of configs
needed to support.
On 11/4/13 9:57 AM, Chuck Guzis wrote:
It would seem entirely reasonable to have firmware for a machine-specific hard drive.
Is this just to reduce the storage requirements to just the sector payload? The tradeoff then is the software and hardware
resources for synthesis and recovery of the
various fields of a sector as opposed to just treating the whole thing as a bitstream
sitting
in what looks like a recirculating shift register.
The problem with the shift register approach is when do you save it? After every
assertion and
negation of the write gate? Every time the cylinder/head changes?
The latter is what I'd do, plus a timeout-based writeback
so that the last track written to doesn't get lost when you
power off. A reasonably fast SD card should be more than able
to store a track's worth of data in a reasonably short "seek
time".
Think of it in terms of cache eviction, even if it's a one-entry
cache. It probably makes sense to do all the tracks in one
cylinder at a time, though; lots of operating systems used
that interleaving to good effect, and you'll sacrifice some
performance if you don't. You can mark a track "dirty" in
the cache when it's written to, and then you only have to
write the dirty tracks when you flush the cylinder cache.
- Dave