mirror of
https://github.com/davidgiven/fluxengine.git
synced 2025-10-31 11:17:01 -07:00
Update documentation.
This commit is contained in:
David Given
@@ -52,9 +52,8 @@ following friendly articles:
|
||||
- [Using a FluxEngine](doc/using.md) ∾ what to do with your new hardware ∾
|
||||
flux files and image files ∾ knowing what you're doing
|
||||
|
||||
- [Reading dubious disks](doc/problems.md) ∾ it's not an exact science ∾
|
||||
the sector map ∾ clock detection and the histogram ∾ tuning the clock ∾
|
||||
manual adjustment
|
||||
- [Troubleshooting dubious disks](doc/problems.md) ∾ it's not an exact science ∾
|
||||
the sector map ∾ clock detection and the histogram
|
||||
|
||||
Which?
|
||||
------
|
||||
|
||||
380
doc/problems.md
380
doc/problems.md
@@ -1,64 +1,146 @@
|
||||
My disk won't read properly!
|
||||
============================
|
||||
|
||||
So you're trying to read a disk and it's not working. Well, you're not the only one. Floppy disks are unreliable and awkward things. FluxEngine can help, but the tools aren't very user friendly.
|
||||
So you're trying to read a disk and it's not working. Well, you're not the
|
||||
only one. Floppy disks are unreliable and awkward things. FluxEngine can
|
||||
help, but the tools aren't very user friendly.
|
||||
|
||||
The good news is that as of 2019-04-30 the FluxEngine decoder algorithm has
|
||||
been written to be largely fire-and-forget and is mostly self-adjusting.
|
||||
However, there are still some things that can be tuned to produce better
|
||||
reads.
|
||||
|
||||
The sector map
|
||||
--------------
|
||||
|
||||
Every time I do a read, FluxEngine will give me a dump like this:
|
||||
Every time FluxEngine does a read, it produces a dump like this:
|
||||
|
||||
```
|
||||
H.SS Tracks --->
|
||||
0. 0 XBBXXXXXXXXXBXBBXBBXBBX..XXX.BXBBBXXX....BB...BB...........B.XXXX.X....BBBBBBXBB
|
||||
0. 1 X.BXXXXBBXXX.XBBXBXXBBB.XXXX.BBXBXXBX....BB...BX........BB.B.XXXX.X....BBBBBBXBX
|
||||
0. 2 X..XXXXXBXXX.XBBXXBXBBB.BXXB.BXBBBXXX...BXX.B.BB.........B.B.XXXX.X....BBBBBBXBX
|
||||
0. 3 X.BXXXXXXXXX.X.XXBBXBBX.XXXX.XXXXXXXX...BBX.X.XX......B....B.XXXB.X....BBBXBBXBX
|
||||
0. 4 X.BXXXXXXXXX.XBXXBXXBBB.XXXX.BXXXXXXX...BBB.X.BX......B....B.XXXX.X....BBBBBBXBX
|
||||
0. 5 X.BXXXXXXXXX.XBXXBBXBB.BXXXX.XXXXXXXX...XBB.X.XX.....B.....B.XXXX.B....BBBXBBXBX
|
||||
0. 6 X..XXXXBXXXX.X.XXBBXBBB.XXXB.XXBBBXXX..B.BB.B.XB.............XXXX.X....BBBXBBXBX
|
||||
0. 7 X..XXXXBXXXXBX.XXBBXBBB.BXXX.XXXBXXXX..BBXX.X.XX......B....B.XXXX.X....BBBXBBXBX
|
||||
0. 8 X.BXXXXBXXXXBX.XXBBXBBX.XXXX.XXXXXXXX..BXXX.X.XX......BB.B...XXXX.X....BBBBXBXBX
|
||||
0. 9 X.BXXXXXXXXXBX.XXBBXBBB.XXXX.XXXXXXXX..XXXX.X.XX......X......XXXX.X....BBBBBBXBX
|
||||
0.10 X..XXXXBXXXXBX.XXBBXXB..BXXXBBXXBXXXX..BBXB.B.BB.............XXXX.X....BBBBBXXBX
|
||||
0.11 X..XXXXXXXXXBX.XXBBXBBB.XXXX.BXXXXXXX..XXXX.X.BB....B........XXXX.X....BBBBBBBBB
|
||||
0.12 X.BXXXXXXXXXBX.XXBXXXXB.XXXX.XXXXXXXX..XXXX.X.XX.........B.B.BXXX.B....XXXXXXXXX
|
||||
0.13 X..XBXXXXXXXBX.XXBBXBBB.XXXX.XXXXXXXX..XXXX.X.XX....B.B.BB.BXXXXXXXXXXXXXXXXXXXX
|
||||
0.14 XB.XXXXXXXXXBX.XXBBXBBB.XXXB.XXBXXXXB..BBB..B.BBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.15 X..XXXXXXXXXBX.XXBBXBBB.XXXX.XXXXXXXX.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.16 X..XXBXXBXBXBBBXXBBXBBB.XXBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.17 XBBXXXXB.XXXBXBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.18 XBBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
Good sectors: 369/1520 (24%)
|
||||
Missing sectors: 847/1520 (55%)
|
||||
Bad sectors: 304/1520 (20%)
|
||||
0. 0 XXXBXX...X.XXXX......?...........X...X.........X................................
|
||||
0. 1 ..X..X.X..XB.B.B........X...........X.......X...................................
|
||||
0. 2 X.XXXX.XX....XB.................X.X..X..X......X................................
|
||||
0. 3 X.X..XXXX..?XXXX..................XX.X..........................................
|
||||
0. 4 X.X..X....X.X.XX....?....?........XXXX..X.....X.................................
|
||||
0. 5 XXXX...?..X.XBX...?......C......C?.X.X...?....X..........X......................
|
||||
0. 6 XXXB.XX.XX???XXX...............CX.XXXX........X.................................
|
||||
0. 7 XX..XX.XC..?.X......B.......X...X..XX...C.......................................
|
||||
0. 8 X?.B...XXX.?..XX........X........XCXXX..X..X..X.................................
|
||||
0. 9 BB.XX.X.X.X...BX.........C.......XXX...........X.....X..........................
|
||||
0.10 BX.XX.XX.X..XX.B...X.............XXX........................................C...
|
||||
0.11 .C.X.C..BXXBXBX?X................XX..X......X...................................
|
||||
0.12 BX.XXX....BX..X......C....X......XXX.......XX..........................XXXXXXXXX
|
||||
0.13 X..BXX..X?.XX.X....X..............XXXX.X....X...............XXXXXXXXXXXXXXXXXXXX
|
||||
0.14 X...XXB..X.X..X....X...X..C........X?...........XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.15 X.BX.XX.X.XXX.X...........X.....X..X..XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.16 XBXX...XX.X.X.XX........B..XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.17 XXB..X.B....XX..XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.18 XXCXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
Good sectors: 978/1520 (64%)
|
||||
Missing sectors: 503/1520 (33%)
|
||||
Bad sectors: 39/1520 (2%)
|
||||
80 tracks, 1 heads, 19 sectors, 512 bytes per sector, 760 kB total
|
||||
```
|
||||
|
||||
This is the **sector map**, and is showing me the status of every sector it
|
||||
found on the disk. (Tracks on the X-axis, sectors on the Y-axis.) This is a
|
||||
very bad read from a [Victor 9000](disk-victor9k.md) disk; good reads shouldn't
|
||||
look like this. A dot represents a good sector. A B is one where the CRC
|
||||
check failed; an X is one which couldn't be found at all.
|
||||
very bad read from a [Victor 9000](disk-victor9k.md) disk; good reads
|
||||
shouldn't look like this. A dot represents a good sector. A B is one where
|
||||
the CRC check failed; an X is one which couldn't be found at all; a ? is a
|
||||
sector which was found but contained no data.
|
||||
|
||||
At the very bottom there's a summary: 24% good sectors. Let me try and improve
|
||||
At the very bottom there's a summary: 64% good sectors. Let me try and improve
|
||||
that.
|
||||
|
||||
(You may notice the wedge of Xs in the bottom right. This is because the
|
||||
Victor 9000 uses a varying number of sectors per track; the short tracks in
|
||||
the middle of the disk store less. So, it's perfectly normal that those
|
||||
sectors are missing. This will affect the 'good sectors' score, so it's
|
||||
normal not to have 100% on this disk.)
|
||||
normal not to have 100% on this type of disk.)
|
||||
|
||||
Clock errors
|
||||
------------
|
||||
|
||||
When FluxEngine sees a track, it attempts to automatically guess the clock
|
||||
rate of the data in the track. It does this by looking for the magic bit
|
||||
pattern at the beginning of each sector record and measuring how long it
|
||||
takes. This is shown in the tracing FluxEngine produces as it runs. For
|
||||
example:
|
||||
|
||||
```
|
||||
70.0: 868 ms in 427936 bytes
|
||||
138 records, 69 sectors; 2.13us clock;
|
||||
logical track 70.0; 6656 bytes decoded.
|
||||
71.0: 890 ms in 387904 bytes
|
||||
130 records, 65 sectors; 2.32us clock;
|
||||
logical track 71.0; 6144 bytes decoded.
|
||||
```
|
||||
|
||||
Bits are then found by measuring the interval between pulses on the disk and
|
||||
comparing to this clock rate.
|
||||
|
||||
However, floppy disk drives are extremely analogue devices and not necessarily calibrated very well, and the disk may be warped, or the rubber band which makes the drive work may have lost its bandiness, and so the bits are not necessarily precisely aligned. Because of this, FluxEngine can tolerate a certain amount of error. This is controlled by the `--bit-error-threshold` parameter. Varying this can have magical effects. For example, adding `--bit-error-threshold=0.4` turns the decode into this:
|
||||
|
||||
```
|
||||
H.SS Tracks --->
|
||||
0. 0 ...B............................................................................
|
||||
0. 1 ...........B...B................................................................
|
||||
0. 2 ..............B.................................................................
|
||||
0. 3 ................................................................................
|
||||
0. 4 ................................................................................
|
||||
0. 5 ...B............................................................................
|
||||
0. 6 ...B.....B......................................................................
|
||||
0. 7 ...B...........B....B...........................................................
|
||||
0. 8 ................................................................................
|
||||
0. 9 .B............B.................................................................
|
||||
0.10 .B............BB................................................................
|
||||
0.11 B............B..................................................................
|
||||
0.12 ...B......B............................................................XXXXXXXXX
|
||||
0.13 ............B...............................................XXXXXXXXXXXXXXXXXXXX
|
||||
0.14 ...B......B.....................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.15 ..B.....BB..B.........................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.16 ..B.....B.B.............B..XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.17 ..B....B........XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.18 .B..XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
Good sectors: 1191/1520 (78%)
|
||||
Missing sectors: 296/1520 (19%)
|
||||
Bad sectors: 33/1520 (2%)
|
||||
80 tracks, 1 heads, 19 sectors, 512 bytes per sector, 760 kB total
|
||||
```
|
||||
|
||||
A drastic difference!
|
||||
|
||||
The value of the parameter is the fraction of a clock of error to accept. The
|
||||
value typically varies from 0.0 to 0.5; the default is 0.2. Larger values
|
||||
make FluxEngine more tolerant, so trying 0.4 is the first thing to do when
|
||||
faced with a dubious disk. However, in some situations, increasing the value
|
||||
can actually _increase_ the error rate --- which is why 0.4 isn't the default
|
||||
--- so you'll need to experiment.
|
||||
|
||||
That's the most common tuning parameter, but others are available:
|
||||
|
||||
`--pulse-debounce-threshold` controls whether FluxEngine ignores pairs of pulses in rapid succession. This is common on some disks (I've observed them on Brother word processor disks).
|
||||
|
||||
`--clock-interval-bias` adds a constant bias to the intervals between pulses
|
||||
before doing decodes. This is very occasionally necessary to get clean reads
|
||||
--- for example, if the machine which wrote the disk always writes pulses
|
||||
late. If you try this, use very small numbers (e.g. 0.02). Negative values
|
||||
are allowed.
|
||||
|
||||
Both these parameters take a fraction of a clock as a parameter, and you'll
|
||||
probably never need to touch them.
|
||||
|
||||
Clock detection
|
||||
---------------
|
||||
|
||||
When FluxEngine sees a track, it attempts to automatically guess the clock
|
||||
rate of the data in the track. It does this by computing a histogram of the
|
||||
spacing between pulses and attempting to detect the shortest peak. The
|
||||
histogram should look something like this.
|
||||
A very useful tool for examining problematic disks is `fe-inspect`. This will
|
||||
let you examine the raw flux on a disk (or flux file). It'll also guess the
|
||||
clock rate on the disk for you, using a simple statistical analysis of the
|
||||
pulse intervals on the disk. (Note that the tool only works on one track at a
|
||||
time.)
|
||||
|
||||
```
|
||||
$ fe-inspect -s good.flux:t=0:s=0
|
||||
Clock detection histogram:
|
||||
3.58 737 ▉
|
||||
3.67 3838 ████▊
|
||||
@@ -96,6 +178,7 @@ Signal level: 3170
|
||||
Peak start: 42 (3.50 us)
|
||||
Peak end: 52 (4.33 us)
|
||||
Median: 47 (3.92 us)
|
||||
3.92us clock detected.
|
||||
```
|
||||
|
||||
That's _not_ the histogram from the Victor disk; that's an Apple II disk, and
|
||||
@@ -109,190 +192,65 @@ So, what does my Victor 9000 histogram look like? Let's look at the
|
||||
histogram for a single track:
|
||||
|
||||
```
|
||||
$ fe-readvictor -s diskimage/:s=0:t=0 --show-clock-histogram
|
||||
Reading from: diskimage/:d=0:s=0:t=0
|
||||
0.0: 829 ms in 316193 bytes
|
||||
$ fe-inspect -s dubious.flux:t=0:s=0
|
||||
Clock detection histogram:
|
||||
1.25 447 ▌
|
||||
1.33 16283 ████████████████████▎
|
||||
1.42 22879 ████████████████████████████▌
|
||||
1.50 4564 █████▋
|
||||
1.58 1272 █▌
|
||||
1.67 19594 ████████████████████████▍
|
||||
1.75 32059 ████████████████████████████████████████
|
||||
1.83 18042 ██████████████████████▌
|
||||
1.92 2249 ██▊
|
||||
2.00 8825 ███████████
|
||||
2.08 16031 ████████████████████
|
||||
2.17 5080 ██████▎
|
||||
2.25 409 ▌
|
||||
2.33 7216 █████████
|
||||
2.42 6269 ███████▊
|
||||
2.50 514 ▋
|
||||
2.58 5176 ██████▍
|
||||
2.67 13080 ████████████████▎
|
||||
2.75 6774 ████████▍
|
||||
2.83 1916 ██▍
|
||||
2.92 10880 █████████████▌
|
||||
3.00 21277 ██████████████████████████▌
|
||||
3.08 11625 ██████████████▌
|
||||
3.17 1028 █▎
|
||||
1.33 1904 █▉
|
||||
1.42 21669 ██████████████████████▌
|
||||
1.50 2440 ██▌
|
||||
1.58 469 ▍
|
||||
1.67 7261 ███████▌
|
||||
1.75 6808 ███████
|
||||
1.83 3088 ███▏
|
||||
1.92 2836 ██▉
|
||||
2.00 8897 █████████▎
|
||||
2.08 6200 ██████▍
|
||||
...
|
||||
3.67 1910 ██▍
|
||||
3.75 19720 ████████████████████████▌
|
||||
3.83 12365 ███████████████▍
|
||||
3.92 814 █
|
||||
4.00 3144 ███▉
|
||||
4.08 5776 ███████▏
|
||||
4.17 3278 ████
|
||||
4.25 8487 ██████████▌
|
||||
4.33 15922 ███████████████████▊
|
||||
4.42 9656 ████████████
|
||||
4.50 1540 █▉
|
||||
2.25 531 ▌
|
||||
2.33 2802 ██▉
|
||||
2.42 2136 ██▏
|
||||
2.50 1886 █▉
|
||||
2.58 10110 ██████████▌
|
||||
2.67 8283 ████████▌
|
||||
2.75 7779 ████████
|
||||
2.83 2680 ██▊
|
||||
2.92 13908 ██████████████▍
|
||||
3.00 38431 ████████████████████████████████████████
|
||||
3.08 35708 █████████████████████████████████████▏
|
||||
3.17 5361 █████▌
|
||||
...
|
||||
Noise floor: 320
|
||||
Signal level: 3205
|
||||
Peak start: 14 (1.17 us)
|
||||
Peak end: 39 (3.25 us)
|
||||
Median: 23 (1.92 us)
|
||||
3.75 294 ▎
|
||||
3.83 389 ▍
|
||||
3.92 1224 █▎
|
||||
4.00 3067 ███▏
|
||||
4.08 4092 ████▎
|
||||
4.17 6916 ███████▏
|
||||
4.25 25639 ██████████████████████████▋
|
||||
4.33 31407 ████████████████████████████████▋
|
||||
4.42 10209 ██████████▋
|
||||
4.50 1159 █▏
|
||||
...
|
||||
Noise floor: 384
|
||||
Signal level: 1921
|
||||
Peak start: 15 (1.25 us)
|
||||
Peak end: 26 (2.17 us)
|
||||
Median: 20 (1.67 us)
|
||||
1.67 us clock detected.
|
||||
```
|
||||
|
||||
That's... not good. The disk is very noisy, and the intervals between pulses
|
||||
are horribly distributed. The detected clock is 1.92us, which is clearly
|
||||
wrong.
|
||||
are horribly distributed. The detected clock from the decode is 1.45us, which
|
||||
does correspond more-or-less to a peak. You'll also notice that the
|
||||
double-clock interval is at 3.00us, which is _not_ twice 1.45us. The guessed
|
||||
clock by `fe-inspect` is 1.67us, which is clearly wrong.
|
||||
|
||||
I can override the clock detection and specify the clock manually. 1.75us
|
||||
looks like a good candidate. Let's try that on track 0.
|
||||
This demonstrates that the statistical clock guessing isn't brilliant, which
|
||||
is why I've just rewritten the decoder not to use it; nevertheless, it's a
|
||||
useful tool for examining disks.
|
||||
|
||||
```
|
||||
$ fe-readvictor9k -s diskimage/:s=0:t=0 --manual-clock-rate-us=1.75
|
||||
...skipped...
|
||||
No sectors in output; skipping analysis
|
||||
0 tracks, 0 heads, 0 sectors, 0 bytes per sector, 0 kB total
|
||||
```
|
||||
`fe-inspect` will also dump the raw flux data in various formats, but that's
|
||||
mostly only useful to me. Try `--dump-bits` to see the raw bit pattern on the
|
||||
disk (using the guessed clock, or `--manual-clock-rate-us` to set it
|
||||
yourself); `--dump-flux` will show you discrete pulses and the intervals
|
||||
between them.
|
||||
|
||||
Nope, nothing --- FluxEngine was unable to find any valid data. How about
|
||||
1.42us, this time for the whole disk?
|
||||
|
||||
```
|
||||
$ fe-readvictor9k -s diskimage/:s=0:t=0 --manual-clock-rate-us=1.42
|
||||
...skipped...
|
||||
H.SS Tracks --->
|
||||
0. 0 .BBBBBBBBXBBBBBBXXXXXXXXXBB
|
||||
0. 1 B.BBBBBBBXXXXBBBXXXXXXXXXXX
|
||||
0. 2 B..BBBBBBBBBXBBBXXXXXXXXXXX
|
||||
0. 3 B.BBBBBBBXBB.BBBXXXXXXXXXXX
|
||||
0. 4 B.BBBBBBBXBB.BBBXBXXXXXXXBB
|
||||
0. 5 B.BBBBBBBBBB.BXBXXXXXXXXXBB
|
||||
0. 6 B..BBBBBBXBBXBXBXXXXXXXXXXX
|
||||
0. 7 B..BBBBBBBBBXB.XXXBBXXXBXBX
|
||||
0. 8 B.BBBBBBBBBBXB.BXBBXXXX.XXX
|
||||
0. 9 B.BBBBBBBXXXXX.BXXXXXXXXXXX
|
||||
0.10 B..BBBBBBBBBXB.BXXXXXXXXXXX
|
||||
0.11 B..BBBBBXXBXBB.BXXXXXXXXXXX
|
||||
0.12 B.BBBBBB.BXBBB.BXXXXXXXXXXX
|
||||
0.13 B..BBBBB.BBBBB.BXXBXXXXXXXX
|
||||
0.14 BB.BBBBBXBBBBB.BXBXXXXXXXXX
|
||||
0.15 B..BBBBB.XBBBB.BXXXXXXXXXXX
|
||||
0.16 B..BBBBBBXBBXBBBXBBXXXXXXXX
|
||||
0.17 BBBBBBBB.XBBXBBBXXXXXXXXXXX
|
||||
0.18 BBBBXXXXXXXXXXXXXXXXXXXXXXX
|
||||
Good sectors: 42/513 (8%)
|
||||
Missing sectors: 234/513 (45%)
|
||||
Bad sectors: 237/513 (46%)
|
||||
27 tracks, 1 heads, 19 sectors, 512 bytes per sector, 256 kB total
|
||||
```
|
||||
|
||||
It found something. The sectors in track 0 are now B rather than X, which
|
||||
means that FluxEngine at least found them, and look, one sector even passed
|
||||
its CRC!
|
||||
|
||||
But it turns out that the Victor 9000 actually uses a varying clock rate from
|
||||
track to track, so as to fit more data on the longer tracks on the outside of
|
||||
the disk. So, manually setting the clock rate to 1.42us has actually made
|
||||
things _worse_ at the other end of the disk. Our overall bad sector rate has
|
||||
gone up from 20% to 46%.
|
||||
|
||||
So, I look back at the histogram. I want to keep using the clock
|
||||
autodetection, but persuade it to detect the right clock. There _is_ a peak
|
||||
at 1.42us, but there's enough noise around it to confuse the peak detection
|
||||
algorithm. You can see from the summary at the end that it thinks the peak
|
||||
extends from 1.17us to 3.25us.
|
||||
|
||||
The way to correct this is to change the noise floor. This makes it ignore
|
||||
frequencies below a certain level. Raising this will make it much more
|
||||
conservative about what it considers a frequency peak. With good data, this
|
||||
actually makes frequency detection _less_ accurate, but with bad data it can
|
||||
help.
|
||||
|
||||
```
|
||||
$ fe-readvictor9k -s diskimage/:s=0:t=0 --show-clock-histogram --noise-floor-factor=0.25
|
||||
Reading from: diskimage/:d=0:s=0:t=0
|
||||
0.0: 829 ms in 316193 bytes
|
||||
Clock detection histogram:
|
||||
1.33 16283 ████████████████████▎
|
||||
1.42 22879 ████████████████████████████▌
|
||||
1.50 4564 █████▋
|
||||
...
|
||||
1.67 19594 ████████████████████████▍
|
||||
1.75 32059 ████████████████████████████████████████
|
||||
1.83 18042 ██████████████████████▌
|
||||
...
|
||||
2.00 8825 ███████████
|
||||
2.08 16031 ████████████████████
|
||||
2.17 5080 ██████▎
|
||||
...
|
||||
...skipped...
|
||||
Noise floor: 8014
|
||||
Signal level: 3205
|
||||
Peak start: 15 (1.25 us)
|
||||
Peak end: 18 (1.50 us)
|
||||
Median: 17 (1.42 us)
|
||||
...skipped...
|
||||
Good sectors: 1/19 (5%)
|
||||
Missing sectors: 0/19 (0%)
|
||||
Bad sectors: 18/19 (94%)
|
||||
1 tracks, 1 heads, 19 sectors, 512 bytes per sector, 9 kB total
|
||||
```
|
||||
|
||||
So, it's now found a peak from 1.25us to 1.50us, with a median of 1.42us ---
|
||||
exactly what I wanted. Let's try it on the whole disk:
|
||||
|
||||
```
|
||||
H.SS Tracks --->
|
||||
0. 0 .BBBBBBBBBBBBBBBB.BBB.B..BB.....................................................
|
||||
0. 1 B.BBBBBBBBXXX.BBB.BBB.X..BB..........B..........................................
|
||||
0. 2 B..BBBBBB.BBXBBBB.BBB.X..BB.......B.............................................
|
||||
0. 3 B.BBBBBBBBBB.B.BX.BBB.B..BB......B..............................................
|
||||
0. 4 B.BBBBBB.BBB.BBBB.BBB.B..BB.....B...............................................
|
||||
0. 5 B.BBBBBBBBBB.BBBB.BBB.XB.BB.....B.B.............................................
|
||||
0. 6 B..BBBBBBBBBXB.BX.BBB.X.XXB.....................................................
|
||||
0. 7 B..BBBBBBBBBXB.XB.BBB.X.BBB.....................................................
|
||||
0. 8 B.BBBBBBBBBBXB.BB.BBB.X.XXX.B...................................................
|
||||
0. 9 B.BBBBBBBBXXX..BX.BXB.X.XXXBB...................................................
|
||||
0.10 B..BBBBB.BBBXB.BB.BBB...BBB.B...................................................
|
||||
0.11 B..BBBBB.BBXBB.BB.BXB.B.BBB.B......B............................................
|
||||
0.12 B.BBBBBB.BXBBB.BB.BXX.X.XXX........B...................................XXXXXXXXX
|
||||
0.13 B..BBBBB.BBBBB.BX.BBB.X.BXB......BB.........................XXXXXXXXXXXXXXXXXXXX
|
||||
0.14 BB.BBBBB..BBBB.BB.BBB.B.XBB.B....BB.B...........XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.15 B..BBBBB.BBBBB.BB.BBB.X.XBB.B....B....XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.16 B..BBBBB.BBBXBBBB.BBB.X.BXBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.17 BBBBBBBB.BBBX.BBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
0.18 BBBBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|
||||
Good sectors: 834/1520 (54%)
|
||||
Missing sectors: 346/1520 (22%)
|
||||
Bad sectors: 340/1520 (22%)
|
||||
80 tracks, 1 heads, 19 sectors, 512 bytes per sector, 760 kB total
|
||||
```
|
||||
|
||||
54% good sectors --- much better! Most of the top half of the disk is reading
|
||||
flawlessly. The bottom half is still dreadful, but much better.
|
||||
|
||||
I picked this disk as a sample because it's essentially wrecked. It's the
|
||||
worst disk image I've ever seen. Luckily I didn't scan this myself, because
|
||||
chances are it's all mouldy and would wreck my disk heads. But its very
|
||||
badness makes it a good example.
|
||||
|
||||
(I am continually improving the clock detection and data extraction
|
||||
algorithms. I have actually seen someone get more data than I off this image,
|
||||
with a mostly-good read of track 0. I must find out their secrets...)
|
||||
The tool's subject to change without notice as I tinker with it.
|
||||
|
||||
20
doc/using.md
20
doc/using.md
@@ -194,16 +194,24 @@ Typically I do this:
|
||||
$ fe-readbrother -s :d=0 -o brother.img --write-flux=brother.flux
|
||||
```
|
||||
|
||||
This will read the disk in drive 0 and write out a filesystem image. It'll also copy the flux to brother.flux. If I then need to tweak the settings, I can rerun the decode without having to physically touch the disk like this:
|
||||
This will read the disk in drive 0 and write out a filesystem image. It'll
|
||||
also copy the flux to brother.flux. If I then need to tweak the settings, I
|
||||
can rerun the decode without having to physically touch the disk like this:
|
||||
|
||||
```
|
||||
$ fe-readbrother -s brother.flux -o brother.img
|
||||
```
|
||||
|
||||
If the disk is particularly fragile, you can force FluxEngine not to retry
|
||||
Apart from being drastically faster, this avoids touching the (potentially
|
||||
physically fragile) disk.
|
||||
|
||||
If the disk is particularly dodgy, you can force FluxEngine not to retry
|
||||
failed reads with `--retries=0`. This reduces head movement. **This is not
|
||||
recommended.** Floppy disks are inherently unreliable, and the occasional bit
|
||||
error is perfectly normal; the sector will read fine next time. If you
|
||||
prevent retries, then not only do you get bad sectors in the resulting image,
|
||||
but the flux file itself contains the bad read, so attempting a decode of it
|
||||
will just reproduce the same bad data.
|
||||
error is perfectly normal; FluxEngine will retry and the sector will read
|
||||
fine next time. If you prevent retries, then not only do you get bad sectors
|
||||
in the resulting image, but the flux file itself contains the bad read, so
|
||||
attempting a decode of it will just reproduce the same bad data.
|
||||
|
||||
See also the [troubleshooting page](problems.md) for more information about
|
||||
reading dubious disks.
|
||||
|
||||
Reference in New Issue
Block a user