• Please review our updated Terms and Rules here

Do Mac 400/800kB drives have weird alignment?

H

hjalfi

Experienced Member
Joined
Feb 11, 2017
Messages
265
Location
Zürich, Switzerland
Context: I'm reading floppy disks via flux sampling (see http://cowlark.com/fluxengine).

I've spent some time slaving over a hot logic analyser trying to sort out problems reading Mac disks. I originally thought that my sampler was dropping pulses, but it turns out it's absolutely fine, and the drive itself is dropping them --- I managed to catch some coming off the drive itself with the logic analyser and correlated them to the errors.

Weirdly, these only affect Mac disks, and the middle tracks suffer way more than the outer tracks. Here's the cleanest example I've seen (sent in by a user. I have users! That's terrifying!):

Code: 
H.SS Tracks --->
0. 0 CC..............................................BBBBBBBBBBBBBBBB................
0. 1 CC..............................................BBBBBBBBBBBBBBBB................
0. 2 CC..............................................BBBBBBBBBBBBBBBB................
0. 3 CC..............................................BBBBBBBBBBBBBBBB................
0. 4 CC..............................................BBBBBBBBBBBBBBBB................
0. 5 C...............................................BBBBBBBBBBBBBBBB................
0. 6 C...............................................BBBBBBBBBBBBBBBB...............C
0. 7 C...............................................BBBBBBBBBBBBBBBB................
0. 8 C................................................BB.BBBBBBBBBBBBXXXXXXXXXXXXXXXX
0. 9 C...............................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 C...............................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.11 C...............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Tracks are horizontal, sectors are vertical. B represents a bad sector. C represents a conflict; ignore these, it's because they imaged both sides of a single-sided disk. The Xs are missing sectors. They're normal because Mac disks have different numbers of sectors per track. My drive produces much the same pattern, although much noisier.

So, Mac disks use different rotational velocities per zone. I'm using a standard PC drive which spins at 300rpm, so I see that as different bitrates per zone, and whatever's happening is primarily affecting the 284kHz and 252kHz zones. However, I've got some Brother disks at 255kHz which read just fine, and I'm getting clean reads from loads of other formats, so it's not solely dependent on bitrate.

Hunting around reveals lots of Kryoflux users seeing exactly the same problem, so it's not just me. The recommended solution is to just try another drive.

My hypothesis here is: at certain rotational speeds, the head alignment of Mac disks goes a bit awry rendering the signal out of spec for a normal drive. This is not usually a problem because Mac disks are supposed to only be used in Mac drives, but I'm using a PC drive. Some drives work and some don't because of the different alignment tolerances. This would also explain the problems people reported in using the later SuperDrives with old Mac disks.

Does any of this seem even slightly plausible, or am I barking up the wrong tree? Is there anything I can do about it (I'm guessing not)?
 
So did you try a different drive? :)

From what I have seen so far, my guess was something at the analog level that causes some mac disks to have problems. But I really have very little idea.

What I do know is that using a kryoflux, most PC drives will either fail to properly read either the innermost or outermost tracks. That has something to do with the drive's signal filtering. I have one 3.5" drive that lets me override the density detection by setting the density line (usually ignored by most 3.5" drives), and in one mode it only reads inner tracks right, while in the other it only reads outer tracks.

Teac floppy drives seem to get the best results, typically reading all tracks right. Still, I have encountered some disks that test perfectly on my PowerMac 7100 but makes the Teac/Kryoflux barf, across most all of the tracks.

If you think it is head alignment, it shouldn't be too hard to check for if you don't mind messing up the alignment on a drive.

I was under the impression Apple had to use the same head alignment as other 3.5" drives, as the first were just Sony drives with custom logic. But then again, they have done stranger things.
 
I have one (1) working drive (of each kind). So my ability to test is limited. I do know someone with 16 who's agreed to do a set of comprehensive tests, though, for which I shall owe them beer. My 3.5" drive is the ubiquitous Sony MPF-920, but there do seem to have been many submodels of this.

I don't want to fiddle with my drive because, well, it's my only drive, and also it reads all the other disks absolutely fine. I don't have any other CLV 3.5" disks, though. I don't even know if there were any.

My thought about the alignment is that because Mac drives rotate at variable rates, the sideways force on the head will be different to that in a CRV drive. Admittedly, since posting I now realise that in a CRV drive the sideways force will vary depending on track position (the inside is moving more slowly than the outside), while in a zoned CLV drive like the Mac ones the force will vary much less, but it's still at least a little bit plausible.

I suppose I'd better acquire a sacrificial drive and then break the head alignment on it...
 
The head alignment is completely standard, otherwise the catweasel couldn't read 400/800k disks. You are having some other problem.
 
Yup. I believe that the Deluxe option board documents discuss which drives work and which have problems. You'd think that any 2D drive could handle them, but it's not so.
 
I am fascinated that it can matter to a drive whether the format is MFM or GCR. Is this a noise filter or AGC type problem?
 
(Belatedly; thanks, phpbb's super reliable notification system!) Thanks for the document --- I'll update my Mac disk documentation. This is really disappointing, it was working so well up until now... and, if particular bit patterns are being dropped, that would explain the strangely reliable errors.

I wonder whether there are few enough occurrances of these that I can spot likely-looking holes in the pulse stream and try patching them until the sector CRC matches? Do you have any more pointers to specifically what's happening?

I'm curious to know why reading Mac disks fails but reading Brother disks works. The Brother disks use the same clock as the affected areas of the Mac disks. It's a different GCR scheme, true, but all GCR schemes use approximately the same pulse density as they're trying to maximise the bandwidth.

Attached for interest value is a analysis screenshot --- top image is the FluxEngine output, showing two consecutive reads, where you can see the missing pulses; below is the logic analyser captures of the raw data for the two reads (proving it's not the FluxEngine's fault). Each row of the triplet is reading a different part of the decode pipeline. If anyone wants the raw data it's here: https://github.com/davidgiven/fluxengine/issues/75

61155952-8a3ff900-a4f2-11e9-8ad7-b928b086fa9a.jpg

(Edit: phpbb is only showing a tiny thumbnail. Here's the full sized one: https://user-images.githubusercontent.com/100638/61155952-8a3ff900-a4f2-11e9-8ad7-b928b086fa9a.png)
 
You must log in or register to reply here.
Back
Top