Need a bit of help w/ F7Plus

[snhirsch]

Hi, All. Just received my F7 Plus and have started working with it. The first thing I thought I'd try was reading a plain old PC 360k DSDD diskette to SCP and converting to a sector image. The F7 is connected to a 1.2M Teac drive. What I've done:

• gw read --track c=0-39:step=2 test.scp

This cheerfully ticks through all 40 tracks and generates the SCP file. Then:

• disk-analyse -s 0 -e 39 test.scp test.img

Unfortunately, disk-analyse reports:

Side 0: T0-39: Unformatted* Side 1: T0-39: Unformatted ** WARNING: 40 tracks are damaged or unidentified!
Certainly I'm missing something critical here, but what?

[keirf]

Specify --format=ibm_mfm_dd to disk-analyse. You may also need --rpm=360:300 (iirc).

[snhirsch]

Turns out this diskette is SS, so I sent it 'gw pin 2 L' followed by:

gw read --track c=0-39:h=0:step=2 --revs=5 test.scp

test.scp.gz

Then:
disk-analyse -r 360:300 -S -s 0 -e 39 --format=ibm_mfm_dd test.scp test.img
T0.0-9.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T10.0: IBM-MFM DD (8 512-byte sectors, 4096 bytes)
T11.0-22.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T23.0: IBM-MFM DD (8 512-byte sectors, 4096 bytes)
T24.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T25.0: IBM-MFM DD (8 512-byte sectors, 4096 bytes)
T26.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T27.0-28.0: IBM-MFM DD (8 512-byte sectors, 4096 bytes)
T29.0-39.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)

I get a sector image that's kinda, sorta the right size and appears to have at some of the data decoded. No problem reading this disk on a PC, so not sure where to go from here.

[keirf]

Cross-checked by loading into HxC, it also sees some bad sectors on this disk. There are less than half dozen bad sectors, hence this disk is only 1-2% bad and would mostly work in a PC.

Some more magic parameters do a slightly better job:

viper:Downloads$ disk-analyse -r 360:300 -S -s 0 -e 39 --format=ibm_mfm_dd -p 1 -P 50 test.scp test.img
T0.0-9.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T10.0: IBM-MFM DD (8 512-byte sectors, 4096 bytes)
T11.0-24.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T25.0: IBM-MFM DD (8 512-byte sectors, 4096 bytes)
T26.0-27.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)
T28.0: IBM-MFM DD (8 512-byte sectors, 4096 bytes)
T29.0-39.0: IBM-MFM DD (9 512-byte sectors, 4608 bytes)

The pP parameters are arcane, but you can have a play around with them and sometimes extract marginal sectors.

[keirf]

Here is a flux map of track 28.0. x axis is elapsed time, y axis is time between adjacent fluxes. You can see the five revolutions (red ticks are the index pulses). You can see the usual "bit bands" at roughly 3.2us, 5us, 6.8s, but there's a blurred section with no defined banding. No fancy bit extraction algorithm is going to be able to handle that area.

EDIT: python3 Greaseweazle/scripts/misc/scp_info.py --plot test.scp 56

[snhirsch]

Interesting. To be sure I understand the flux map, the 'blurred section' is represented by the five vertical blue "smears"? I appreciate your taking the time to explain matters!

[keirf]

Yes, the five vertical smears that go fairly solidly top to bottom.You need white space between the horizontal bands, so that bit timings can be distinguished: 3.2us means bits 01, 5us means 001, 6.8us means 0001. These bitcodes are concatenated together according to successive flux timings, and that forms the full MFM-encoded data stream as recorded on the track.

[snhirsch]

Just wanted to follow up on this. I switched to a 360k DSDD drive and all the problems disappeared. I was able to make clean images of every diskette in the set! I think the lesson here is that a read head the full width of the track does a much better job of snagging bits from old media. I was hoping to have a single setup that could handle DD and HD, but clearly that has its drawbacks.