Requesting help in interpreting mfm_read output

[Alexander Huemer]

Hi!

I am in the process of getting my feet wet with the PCB and associated software.

My first quest is to image two MFM HDDs that are in my possession.

* Seagate ST-4096 60MB of unknown origin
  I have this drive on a shelf since approximately 30 years and cannot recall where I got it from or why I have it.

* Seagate ST-412 10MB out of a (special) IBM AT that I have acquired a few months ago.

While reading the ST-4096 I got a lot of 'Bad Sector' error messages. Perhaps it is faulty and that was the reason why it was decommissioned back then? I don't know. Anyways, I was able to read a partition table out of the image file and extract the defined partition with `dd` and actually mount the FAT filesystem! Most of the files have nonsensical names and contain junk though. I do not really care much about the content of this HDD, I was mostly curious. By the way, this HDD sounds relatively calm and is rather quiet for a device of that age.

The first attempt to read the ST-412 was accompanied by a significant amount of 'Ran out of data on sector index 17' error messages with varying advice regarding value I should try with "--begin_time".

I've extracted all these advice values and did some simple stats. The largest value was 237000, so I gave that a shot. Though I do not know if choosing the largest reported value is the right thing to do. Anyways, output of the second read run was way less noisy (and also faster).

Neither of the two produced image files contain a partition table that I could detect with linux tools, which I find strange.

The HDD actually does work. It boots the AT just fine. Out of uncertainty I tried again after the imaging attempts and sure enough, the AT comes up as expected.

I actually do care about the content of the ST-412. I would like to preserve it. If I cannot do it with the reader/emulator PCB, I can do it from the AT itself via the floppy drive or perhaps a gotek emulator, but I would like to understand what is happening here. Am I using the tools in an incorrect way? Is something auto-detected in error? Is the image file fine and I am just too dumb to read it?

I would highly appreciate assistance in interpreting the output of `mfm_read` and advice on next steps, if any. Also, it would be interesting to understand if, based on tool output, a statement can be made that any of those HDDs can be considered trustworthy.

All relevant data can be found at [1].

Thanks,

-Alex

[1] https://ahuemer.xx.vu/volatile/2024-12-30-RwZK2keEvPU/

[David Gesswein]

Took quick look.
For Seagate_ST-412_IBM_AT_begin_time_237000.octets.gz that is format
Xebec_104527_512B.

See in https://www.pdp8online.com/mfm/status.shtml
Amstrad 1512 section for explanation of issue.

Need to use --xebec_skew. May need to update to current software since that
was added recently.

Looks like you created an emulation file though not on the share. You can
use it to regenerate to extracted data file

mfm_util --emu /opt/mfm/emufile_a --extracted_data_file filename --analyze --xebec_skew

The begin_time normally has a reasonable range. I tend to pick median but
if the messages go away the value is fine.

The other image will need to wait until I have more time. Its suspicious
that most of the read errors are the sector headers. May be able to improve it.

> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/86074da1-77e0-45b7-82b3-e1736ff273f4n%40googlegroups.com.

[Phil Pemberton]

This is a bit of an academic point as you mentioned you don't care about the contents of the ST-4096 -- but a common failure on dedicated-servo MFM drives is that the head drifts slightly over time relative to the recorded tracks. This is one reason why they needed periodic low-level formatting.

The ST-4096 has a microstepping/recovery mode which might allow the data to be recovered:

https://bitsavers.trailing-edge.com/pdf/seagate/mfm/ST-4096/36014-001A_ST4096_OEM_Manual_198511.pdf 

PDF page 27 explains how the mode works

Page 22 has the jumper setting needed to enable it

Page 15 shows which pin to pull active on the control cable (pin 16) to enable recovery mode.

There's a page on the project page about doing this with an external stepper motor (https://www.pdp8online.com/mfm/microstep/index.shtml) but I don't know if the MFM reader supports the Seagate recovery mode directly.

Cheers

Phil

[Alexander Huemer]

David,

that worked perfectly after I've updated the software. I was able to access the filesystem now. Thanks!

Phil,

Good suggestion, thanks! I will look into this once I find the time.

-Alex

[David Gesswein]

mfm_read does support it. Didn't find it helped much with the drive I
tried it on.

--recovery -R

Enables microstep drive recovery mode. Some drives support this mode for error recovery if a jumper is installed. Some Seagate drives have this capability and others might also.

> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/6f6139de-0828-4369-916a-5495991f8ba9n%40googlegroups.com.

[David Gesswein]

If you want me to look at the read errors with the ST-4096 I would need
preferrably transitions file or emulator file.

> --
> You received this message because you are subscribed to the Google Groups "MFM Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to mfm-discuss...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/mfm-discuss/bd5b0f7e-d3ff-49e6-9aa3-c74058d9dc12n%40googlegroups.com.

[Alexander Huemer]

https://ahuemer.xx.vu/volatile/2024-12-31-QiHLXts1h90/

I've created both.

[Alexander Huemer]

The image I am using is BBB-mfm-emu-v4.20-OS-11.8-r74.img

Downloaded yesterday.

$ /opt/mfm/mfm/mfm_util --xebec_skew
/opt/mfm/mfm/mfm_util: unrecognized option '--xebec_skew'

What am I doing wrong?

-Alex

[d...@pdp8online.com]

The one message got stuck in a spam queue. Looks like you figured it out.

On the image Phil was right, its heads have shifted out of position. The head stack seems to distort with time on many drives so some heads will be aligned and others off. I have seen heads off an entire cylinder.

Head   Tracks with read errors

0 -2     0

3         2

4        323

5        33

Original decode arguments: --format WD_1006 --sectors 17,1 --heads 6 --cylinders 1023 --header_crc 0xffff,0x1021,16,0 --data_crc  0xffffffff,0x140a0445,32,6 --sector_length 512 --retries 50,4 --drive 1

Online it says ST4096 is 9 heads not the 6 analyze found. The read errors may be confusing it.

This message is somewhat strange. Its saying when it selected head 8 it found sector headers for head 0. Drive should have head 8. My numbering starts at 0 so that is the 9th head. This may indicate problem with 34 pin cable pin 2 head select 8.

Selected head 8 found 0, last good head found 5

The wrong number of heads is why most of the directories are junk since heads 7-9 aren't in the file.

You can force a read with the right number of heads (add options for output files)

mfm_read --format WD_1006 --sectors 17,1 --heads 9 --cylinders 1023 --header_crc 0xffff,0x1021,16,0 --data_crc  0xffffffff,0x140a0445,32,6 --sector_length 512 --retries 50,4 --drive 1

If it spends too much time retrying you can reduce retries with --retries 1,1

This may give you enough directories to see if worth any more trouble. If so try the recovery method previously discussed. Since schematics aren't online the method I used to pull the head servo will be difficult. If no other problems drive likely to be usable with low level format at least for a while.

There is a debug dump of a histogram you can turn on to see data quality in analyze.c

#define GENERATE_HISTOGRAM 1

For cyl 7 head 0 we get good peaks with low counts between them

0, 0
1, 0
2, 0
3, 0
4, 0
5, 0
6, 0
7, 0
8, 0
9, 0
10, 0
11, 0
12, 0
13, 0
14, 0
15, 0
16, 0
17, 0
18, 0
19, 1
20, 0
21, 0
22, 2
23, 0
24, 0
25, 1
26, 3
27, 2
28, 1
29, 3
30, 0
31, 1
32, 4
33, 4
34, 5
35, 6
36, 3
37, 4
38, 301
39, 12131
40, 19992
41, 11276
42, 2137
43, 98
44, 2
45, 2
46, 0
47, 3
48, 1
49, 2
50, 4
51, 0
52, 3
53, 1
54, 3
55, 2
56, 3
57, 155
58, 1171
59, 3300
60, 4160
61, 3134
62, 540
63, 23
64, 1
65, 1
66, 1
67, 1
68, 0
69, 1
70, 1
71, 0
72, 2
73, 0
74, 0
75, 0
76, 0
77, 99
78, 920
79, 2603
80, 3002
81, 2082
82, 569
83, 22
84, 0
85, 3
86, 0
87, 0
88, 0
89, 0
90, 1
91, 1
92, 0
93, 1
94, 0
95, 1
96, 1
97, 0
98, 0
99, 0

On your drive this track had lots of errors Bad sectors on cylinder 7 head 4: 1H 3H 6H 7H 9H 10H 11H 13H 14H 15H 16H 17H

You can see the data is now smeared. This is what I see with heads out of alignment.

0, 0
1, 0
2, 0
3, 0
4, 0
5, 0
6, 0
7, 0
8, 0
9, 0
10, 0
11, 0
12, 0
13, 0
14, 0
15, 0
16, 0
17, 0
18, 0
19, 0
20, 0
21, 0
22, 1
23, 0
24, 2
25, 0
26, 1
27, 3
28, 2
29, 3
30, 5
31, 9
32, 21
33, 18
34, 72
35, 299
36, 881
37, 1875
38, 1889
39, 8572
40, 11563
41, 7894
42, 4671
43, 2931
44, 1813
45, 900
46, 247
47, 168
48, 55
49, 6
50, 5
51, 21
52, 159
53, 387
54, 501
55, 781
56, 1314
57, 1721
58, 2194
59, 3439
60, 3791
61, 2546
62, 1302
63, 806
64, 673
65, 426
66, 222
67, 112
68, 50
69, 31
70, 34
71, 34
72, 94
73, 161
74, 218
75, 263
76, 358
77, 359
78, 442
79, 519
80, 429
81, 266
82, 194
83, 249
84, 257
85, 224
86, 116
87, 52
88, 28
89, 7
90, 3
91, 2
92, 1
93, 2
94, 1
95, 0
96, 1
97, 1
98, 0
99, 0

The pattern that marks the start of the sector header is decoding wrong so most of the sectors aren't found on that track.