Dealing with a high-bitrate hard-sectored drive

[ccollange]

Hi,
I am building an interface between the Greaseweazle and a Diablo Model 44B 14" cartridge hard drive. This cartridge has 2 sides, 408 tracks, with 24 hard sectors of 256 bytes each. It spins at 2400 RPM and data is encoded in FM at 2.5Mbit/s data rate.
The interface works and I am able to move the drive head and read flux back. I am using a Greaseweazle 4.1 with an AT32F403A.

The main issue is that USB Full-Speed is too slow to stream flux data back at this rate. Thanks to buffering, it can read a little more than 1 revolution at a time without buffer overflow, but it is not enough for hard-sector decoding. I get the error "Not enough revolutions of flux data to cue at index. Try dumping more revolutions (larger --revs value)."

I could switch to F7 Lightning Plus to avoid the USB bandwidth problem altogether, but in the meantime, is there a way to decode hard-sectored data from a single revolution plus some overlap?

[keirf]

This thing actually has 24 sector holes and an index hole, requiring full hard-sector decoding?

[ccollange]

Yes, that's correct. Here is how one track read looks like in hcx2001FloppyEmulator's stream view:

[keirf]

There are a few options. Probably the best is to fix this in host tools by allowing you to specify the number of hard sectors via --hard-sectors=N option. Then the tools could index-cue by splicing the end of one revolution onto the start of the next, at a hard-sector mark.

Maybe you already had to do this? As the --hard-sectors option to gw read will try to read 500ms of flux and that would already overflow?

[ccollange]

Thank you for the suggestion! I'll give it a try. Yes, the --hard-sector option to gw read caused a buffer overflow, so I just used regular read with --revs=30.

Disabling hard sectoring pulses altogether and then recovering the sector structure in software also works somehow, but the last sector still ends up truncated

[keirf]

Is the sector structure known/standard, or did you have to implement your own decoder?

[ccollange]

It is an unknown format. The Diablo drive is compatible with IBM 5440, but this particular drive was formatted for use with a CII Mitra minicomputer, and uses a completely different format. Fortunately, it seems quite simple. I am writing my own decoder and discovering it as I go.

I did some more experiments and found that I could sometimes reach --revs=70 without buffer overflow, but some other times I cannot exceed --revs=40. It does not seem to correlate with flux density. Any idea what could cause this variability?

[ccollange]

I implemented splicing at a hard-sector mark and I was able to read and decode data! I can make a pull request once I clean up and test my code a little more.

I've run into another issue: when I gw read multiple tracks at flux level, I get the data of the first track repeated over and over for every track, as if a data transfer fails silently and we keep reading data from a stale buffer. For now, I just read one track at a time as a workaround.