Handling a ST-506 hard (Xebec 1410 controller)

[Gotcha TL]

Hello,

I’m a new user to the MFM reader/emulator board and I’ve got many questions. I'll start with the first few. I have experience with floppy disk imaging and data extraction, but this is the first time I try on hard disks.

Currently, I'm trying to read and decode a ST-506 hard disk that is controlled by a Xebec 1410 in the computer. The computer can support multiple OS like CPM and Prologue and I’m trying to figure out what is on this disk (access fails from the computer).

Apparently, this disk has many issues and the automatic analysis doesn’t work.

My understanding is that in this situation, the approach is to :

• Get a raw image of the disk (transition) with mfm_read
• Perform some analysis offline with mfm_utils
• Then reread and try to decode with found parameters
  

I first did a raw read (I have previously calibrated the hard disk to 3600 RPM) :
mfm_read --drive 1  --transitions_file transitions-micral9050

Since the automatic analysis was failing, I did try the analysis on specific sectors and I finally got a working sector (cylinder 2 and head 2):
$ mfm_util --tran transitions-micral9050 --ana=0,2

Original decode arguments: --heads 4 --cylinders 153 --sector_length 512 --retries 50,4 --drive 1
Primary transition period 210 ns, should be around 200
Found matching format Xebec_104527_C0_256B: good count difference -7
First logical sector 31
Number of heads 4 number of sectors 32 first sector 0
Interleave (not checked): 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31

The found Xebec_104527_C0_256B  is consistent with the actual controller.

First questions:

• Is the reported interleave the actual one that the analysis found on this specific track ? The 'not checked' message is a bit confusing for me.
•  How many rotations does mfm_read stores in the transition files  by default ? On floppy disks, I usually store 3 rotations. But here, it's not clear to me if we store more than 1 rotation and if we can choose the number of rotation.
•  is there a document that specifies the format of the transition file ?

[David Gesswein]

On Tue, Jul 02, 2024 at 05:33:34AM -0700, Gotcha TL wrote:
> Hello,

>
> My understanding is that in this situation, the approach is to :
>

> - Get a raw image of the disk (transition) with *mfm_read*
> - Perform some analysis offline with *mfm_utils*
> - Then reread and try to decode with found parameters
>
Yes

It should have printed out command line to read disk when you got a
sucessful analyze.

If you want to check how MFM timing is on track that have errors or can't be
decoded you can turn on histogram generation by editing analyze.c
#define GENERATE_HISTOGRAM 1
make and then when you analyze it will print a histogram. You want < 10
counts betweeen the peaks at 40, 60, and 80. Common problem is some heads
are out of alignment and you will see that in the histogram of tracks that
read well and ones that don't.

This method can recover the drive if heads are out of position.
http://www.pdp8online.com/mfm/microstep/index.shtml
The ST-508 has a half step jumper that if you set it to half step mode may
allow recovery. See page 29 of PDF.
http://www.bitsavers.org/pdf/seagate/mfm/ST-506/ST506_Preliminary_OEM_Manual_Apr81.pdf

> *Original decode arguments: --heads 4 --cylinders 153 --sector_length 512

> --retries 50,4 --drive 1 Primary transition period 210 ns, should be around
> 200 Found matching format Xebec_104527_C0_256B: good count difference -7
> First logical sector 31 Number of heads 4 number of sectors 32 first sector
> 0 Interleave (not checked): 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 1 3

> 5 7 9 11 13 15 17 19 21 23 25 27 29 31*The found Xebec_104527_C0_256B is

> consistent with the actual controller.
>
> First questions:
>

> - Is the reported interleave the actual one that the analysis found on

> this specific track ? The 'not checked' message is a bit confusing for me.
>

Yes its what it found on that track. Not checked is the emulator doesn't
do any further verification of the interleave. If other track are different
it may not report that.

> - How many rotations does *mfm_read *stores in the transition files by

> default ? On floppy disks, I usually store 3 rotations. But here, it's not
> clear to me if we store more than 1 rotation and if we can choose the
> number of rotation.

One

> - is there a document that specifies the format of the transition file ?
>
In comments at the top of the code that reads/write the file.
https://github.com/dgesswein/mfm/blob/master/mfm/emu_tran_file.c

[Gotcha TL]

Thanks David for this information. I'm going to investigate the half step mode.

I did try to reread the disk with the right parameters. Strangely, for this Xebec format, mfm_read forces me to still use the analyze mode.
What is the reason for this ?

Fortunately, now that I found a good track, I could tell mfm_read to look at this track.
sudo /opt/mfm/mfm/mfm_read --analyze=0,2 --retries 50,4 --drive 1 --format Xebec_104527_C0_256B --sectors 32,0 --heads 4 --cylinders 153 --header_crc 0x0,0xa00805,32,2 --data_crc  0x0,0xa00805,32,2 --sector_length 256 --tran transitions-micral9050 --extracted_data_file micral9050.img |& tee micral9050.txt

What is strange is that the --retries option seems to operate only for track 0. There doesn't seem to be any retry for other tracks.
I get errors for other tracks and it goes very fast, errors like this:
Bad sectors on cylinder 147 head 3: 0H 1H 2H 3H 4H 5H 6H 7H 8H 9H 10H 11H 12H 13H 14H 15H 16H 17H 18H 19H 20H 21H 22H 23H 24H 25H 26H 27H 28H 29H 30H 31H
Retries failed cyl 148 head 0

For example, if I set --retry 500,4 the process is slow on track 0 but still goes very fast for the rest of the hard disk (like when I just request the transition file)
Am I missing something ?

At the end, I get this report:
Found cyl 0 to 53, head 0 to 3, sector 0 to 31
Expected cyls 153 doesn't match cyls found 54
Expected 19584 sectors got 69 good sectors, 19427 bad header, 88 bad data
0 sectors marked bad or spare
99 sectors corrected with ECC. Max bits in burst corrected 2
Track read time in ms min 24.069375 max 1106.281833 avg 65.199323

What does it mean that it found 54 cylinders ?

[David Gesswein]

On Tue, Jul 02, 2024 at 10:30:43AM -0700, Gotcha TL wrote:
> I did try to reread the disk with the right parameters. Strangely, for this

> Xebec format, *mfm_read* forces me to still use the analyze mode.

> What is the reason for this ?
>

Because the data is shifted one sector from the head. It needs to know what
the previous sector is which analyze determines.

> Fortunately, now that I found a good track, I could tell *mfm_read* to look
> at this track.
> *sudo /opt/mfm/mfm/mfm_read --analyze=0,2 --retries 50,4 --drive 1 --format

> Xebec_104527_C0_256B --sectors 32,0 --heads 4 --cylinders 153 --header_crc
> 0x0,0xa00805,32,2 --data_crc 0x0,0xa00805,32,2 --sector_length 256 --tran
> transitions-micral9050 --extracted_data_file micral9050.img |& tee

> micral9050.txt*
>
>
> What is strange is that the * --retries* option seems to operate only for

> track 0. There doesn't seem to be any retry for other tracks.
> I get errors for other tracks and it goes very fast, errors like this:
>

I haven't seen it not do retries on errors. You can add code to print out
the retries to verify. In drive_read.c loop is
} while (sect_err && err_cnt++ < retries);

> At the end, I get this report:
>

> *Found cyl 0 to 53, head 0 to 3, sector 0 to 31 Expected cyls 153 doesn't

> match cyls found 54 Expected 19584 sectors got 69 good sectors, 19427 bad
> header, 88 bad data 0 sectors marked bad or spare 99 sectors corrected with
> ECC. Max bits in burst corrected 2 Track read time in ms min 24.069375 max

> 1106.281833 avg 65.199323*

> What does it mean that it found 54 cylinders ?
>

Thats all the cylinders it saw data from.

[William Stillwell]

I had one time had troubles with an Xebec Controller with ST-506, I think if you dig through the archive, some of my posts w/David may help.

William Stillwell

On Tue, Jul 2, 2024 at 1:26 PM Gotcha TL <gotcha...@gmail.com> wrote:

Thanks David for this information. I'm going to investigate the half step mode.

I did try to reread the disk with the right parameters. Strangely, for this Xebec format, mfm_read forces me to still use the analyse mode.

What is the reason for this ?

Fortunately, now that I found a good track, I could tell mfm_read to look at this track.

sudo /opt/mfm/mfm/mfm_read --analyze=0,2 --retries 50,4 --drive 1 --format Xebec_104527_C0_256B --sectors 32,0 --heads 4 --cylinders 153 --header_crc 0x0,0xa00805,32,2 --data_crc  0x0,0xa00805,32,2 --sector_length 256 --tran transitions-micral9050 --extracted_data_file micral9050.img |& tee micral9050.txt

What is strange is that the --retries option seems to operate only for track 0. There doesn't seem to be any retry for other tracks.

I get errors for other tracks and it goes very fast, errors like this:

Bad sectors on cylinder 147 head 3: 0H 1H 2H 3H 4H 5H 6H 7H 8H 9H 10H 11H 12H 13H 14H 15H 16H 17H 18H 19H 20H 21H 22H 23H 24H 25H 26H 27H 28H 29H 30H 31H
Retries failed cyl 148 head 0

For example, if I set --retry 500,4 the process is slow on track 0 but still goes very fast for the rest of the hard disk (like with I just request the transition file)

Am I missing something ?

At the end, I get this report:

Found cyl 0 to 53, head 0 to 3, sector 0 to 31
Expected cyls 153 doesn't match cyls found 54
Expected 19584 sectors got 69 good sectors, 19427 bad header, 88 bad data
0 sectors marked bad or spare
99 sectors corrected with ECC. Max bits in burst corrected 2
Track read time in ms min 24.069375 max 1106.281833 avg 65.199323

What does it mean that it found 54 cylinders ?

--
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 on the web visit https://groups.google.com/d/msgid/mfm-discuss/0f13a21b-b3e2-4306-99c9-ff4d55437727n%40googlegroups.com.