writing mac.800 img files on DSHD-used-as-DSDD disks always fails starting track #48 or #60

[yv2149]

Hi,

with gw 1.18 and fw 1.5, I can read a DSDD mac.800 disk just fine: gw read test.img --format mac.800

but I cannot write one using a DSHD-used-as-DSDD-with-some-tape-on-the-HD-hole. Depending on the drive and disks, it either fails starting track 48 (Sony MFP 920) or track 60 (EPSON SMD-300):

T60.0: Writing Track (Flux: 200.0ms period, 219.9 ms total, Terminate at index)
T60.0: Writing Track (Verify Failure: Retry #1)
T60.0: Writing Track (Verify Failure: Retry #2)
T60.0: Writing Track (Verify Failure: Retry #3)
** FATAL ERROR:
Failed to verify Track 60.0

I understand those failures happen when switching to a new set of 16 tracks (change of rpm in mac drive). As a side note, when writing to a DSDD floppy disk, it works, verify passed.

Is the difference between DSHD-as-DSDD disks vs real-DSDD disks supposed to be this sensitive when it comes to writing mac.800 floppy disks?

Thanks for any reply!

[keirf]

Actually the rate changes are at tracks 48 and 64. So failure at track 60 is a bit odd. Still I suppose these drives don't like Mac bit timings. You could try adding precomp from say track 40. Something like --precomp=type=gcr:40=250

[keirf]

If it still fails write with --no-verify then do a raw dump to SCP (no format specified on the read) and share for inspection.

[yv2149]

Hi @keirf

thanks for your prompt reply. Unfortunately adding --precomp=type=gcr:40=250 didn't solve the problem, it even got worse at track 48 with the precomp on some DSHD floppy disks.

I tried on several other DSHD disks, the best I can get is track 64 where it always fails, whatever precomp value.

I created a scp dump (gw read x.scp) after doing gw write x.img --format mac.800 -- --no-verify. It is available here until 07/25: https://we.tl/t-Y17uMAI8f7

I appreciate you could take a look. If you can share some methodology on examining / deducting what's wrong on this scp file, I may better understand what's happening and maybe help myself troubleshooting it in order to spare your time.

Thanks!

[keirf]

The sad truth is that it may just be that your drives are fussy about writing GCR data. PC drives can be hit and miss. I will download your dump and take a look however.

[keirf]

So I looked at your SCP dump in HxC software (https://hxc2001.com/download/floppy_drive_emulator/HxCFloppyEmulator_soft_beta.zip).

Open the SCP file, and use the Track Analyzer button. Select View mode: Stream view. This shows you the raw flux, time is horizontal, flux time is vertical. You will see "bit bands" horizontally: This is good. Now scroll the track number upwards. When you reach track 60 you will see that random noise appears along with your bit bands. These are bit errors. Bad.

There probably is no solution other than to find a PC drive which doesn't do this. You're lucky that your drives at least read original disks okay! Writing is clearly beyond them.

[yv2149]

Thanks @keirf for your explanation on the problem and for the methodology to see what's happening.

The funny part is that those drives write mac.800 correctly with DSDD floppy disks! But they are less and less easy to come by. It could be that the DSHD substrate does not magnetize correctly with the GCR-specific timings. I will try with other drives.

By chance, would you know drive models that write mac.800 images correctly?

[keirf]

I'd glazed over the DSHD-with-hole-covered versus DSDD entirely. Actually this is the first time I've heard of or seen a difference in behaviour between the two. I'd suggest the drive was faulty (broken density-detection switch) except you see it in two different drives. It absolutely does look rather like DSHD treated as DSHD though....

[keirf]

See also https://github.com/davidgiven/fluxengine/blob/master/doc%2Fdriveresponse.md

This tool fluxengine supports Greaseweazle and also has a built-in driveresponse analyser. It will show how a drive and disk responds to various flux timings on a certain cylinder.

The doc above also shows that a 3.5-inch drive can have different response between DD and HD-with-hole-covered media. It could definitely affect Mac GCR. That's one for me to remember.

Perhaps you can run the fluxengine drive response analyser yourself (I haven't tried it myself to confirm that this specific test supports Greaseweazle hardware). I really should add such a test directly to the gw tool also.

[yv2149]

Hi @keirf,

I experimented extensively and as a result, I concur to the hypothesis you made. Bottom line: DD drives work best with mac.800, be it on DSDD or DSHD-as-DD floppy disks. Among HD drives from Alps, Sony and Epson, only Epson (painfully) manages to write mac.800 on DSHD-as-DD floppy disks. As for driveresponse tests, my graphs are less contrasted than those in the documentation you mentioned. Yet the mac.800 64+ track zone requires >12us flux gaps and I can clearly see in the driveresponse console log that the incapable HD drives are actually writing 8-10us gaps instead.

Thanks a lot @keirf for all your quick and much advised help on this particularly corner-case topic.

[keirf]

Thanks for the update. My greatest surprise was that, for a given drive, DSDD and DSHD-as-DD disks could really have different behaviour. Though they do have a different coating so it shouldn't be so much of a surprise I guess.

That DD drives work better than HD drives is less surprising to me. For a start they tend to be less "smart" and thus less tuned to expectation of MFM timings (2/3/4us HD; 4/6/8us DD).

[wohali]

@keirf I think you're right. My experience when this tech was new was that writing a DSHD diskette as DD, natively, would result in unreliable reads, even when read back from the same drive. The longer I waited after writing to reading, the higher the chances were that the disk wouldn't read properly. This was especially true if the HD diskette had ever been written with HD formatting.

Bulk erasing the diskette (with a degausser or with heat or both) produced better results, but I never did trust using that media.

Here's some good research on the topic: https://www.retrotechnology.com/herbs_stuff/guzis.html

[keirf]

@wohali That's interesting reading! I've generally had good results with 3.5-inch HD-as-DD keeping to DD MFM timings. Maybe this is more drive specific than I realised however!