5 Dec
2008
5 Dec
'08
4:43 p.m.
Philip Pemberton wrote:
Yeah. I think your calculations were right, anyhow...
No; the raw data file size is manageable I think - it's just the buffer size
that needs to be reasonably big.
Yeah, but that's for complete data, is it not? I'm not sure what happens if
given a damaged drive - given that ST506/412 is dumb, presumably it just
blindly spits out what it finds on the disk surface? It'd be nice to be able
to capture whatever the drive throws at this device, in the hope of making
some sense out of (or 'beyond') damaged sections in software later. If the
track data has 'holes' then the device needs to be able to record the length
of those holes in order to portray what's on the disk accurately.
I'll look at those later - it's too noisy to concentrate round here right now :-)
Yeah, I came to that conclusion way back when, too.
Uh huh. There's not necessarily a guarantee on that for a damaged drive, I
fear (and few STxxx drives seem to exist without at least a few defects)
I can't remember if my 9 bits per sample (including flag bit) was just for
MFM, or if I figured it'd work for RLL, too (or ten bits if recording with
each sample whether there's an index pulse or not - I think I'd dreamed up a
way of doing that separately so as to not encroach on buffer size (but it's
more complex to do so).
Yeah. I think what needs to happen is that you sample a drive, essentially
turn it back into data bytes in software on a host machine, bung some sector
header voodoo around it, and *then* spit it back to the destination drive
using this device...
For now, I'm more worried about ailing STxxx drives and getting data off them
(and making sense of it) - writing back is more of a secondary issue (but is
probably an extra 10% logic on this device to support writes, I suspect).
Aside: I'm not sure if it's beneficial having a number of buffers and
reading/writing multiple head data in parallel? I worry about running STxxx
drives for longer than necessary :-) Probably not viable just from a RAM cost
point of view, though...
cheers
Jules
Jules Richardson wrote:
OK, so you can probably throw something in there to switch heads via software,
presumably?
Well, extra lines isn't a big deal I suppose
- heck, you could even do
that bit 'manually' and read platters one at a time, flipping a switch
between each pass.
True, though the hardware I'm actually thinking of using is my USB
hack-and-bodge floppy reader. FPGA, PICmicro, and a few buffers/level
translators. Well, run some
figures as a sanity-check... say 256*8 bits per sector,
32 sectors/track on a formatted ST506 - 32 x 256 x 8 = 64Kb of actual
data per track.
83.35 seems sensible as some kind of theoretical maximum, given
storage of sector headers and the like.
And MFM is basically one flux transition per (data) bit guaranteed,
meaning 83.35kbps isn't actually that strange a figure. 101353.6 Kb is
approx 98Mb, or approx 12MB - so that seems not
unreasonable.
However, remember that's *sample count*, not total storage.
True. An FDI file containing the sample data isn't likely to be /that/
much bigger though. But it'll take a bloody age transferring that much
data over USB2 Full
Speed (1.2Mbps peak).
I think I did once put in a request for a SCSI version ;)
So, what's
an upper boundary on bits per sample? I suppose you could
have an entire track with just one sample on it right at the end, so
your upper boundary is the 16.67ms figure.
MFM is a (1,3)RLL code. That means you can have a minimum of 1 and a
maximum of 3 empty bit cells between flux transitions. More typically
though samples are going to occur *far* more frequently
- so to cope with all possible situations you (in theory) need a very
large sample length (which in 99.9999% of cases is going to contain a
lot of 0s in the upper bits!)
[lots of numbers] 1) Just have
an absolutely colossal buffer with a large number of bits
per sample
SRAM is relatively expensive though. SDRAM isn't, but then you have to
deal with refreshing and other "fun" things like that. Hmm, use the top 2 bits to specify the timing
resolution, and the rest
as a timing value. Drop between 0 and 3 bits depending on how far over
14 bits your count has gone...
That's going on my "try this" list.
It should work, I think, subject to not throwing too much away.
For some
reason when I looked at this I think I believed I could get
away with 9 bits per sample including a flag bit dictating two
different sample resolutions (i.e. somewhere around 1Mb of buffer) -
unfortunately all my notes on this are stuck in storage right now
though (plus ideally I'd go for a microcontroller approach with a
variable sample length I think)
Ultimately it depends on what you're sampling. A 3.5" DSDD floppy,
sampled at 7.08MHz ends up with few samples above ~64 counts (IIRC, my
density graphs are on the laptop, which is switched off). Based on that,
7 bits would probably be fine up to 14MHz, 8 bits up to 28MHz.
Assuming, of course, that the disc is "perfectly" formatted. As in, the
entire track is MFM. Recreating the
data onto another drive is a different matter, of
course - but I've always been more interested in salvaging existing
data onto more modern media for analysis.
Half the problem is that the timing is going to get progressively worse
the further down the line you go. Kinda like what happens when you dub
an audio tape. By the time you've gotten to the point of having a 3rd-
or 4th-generation copy, the audio is almost completely masked by the
background hiss.