Hard sector format

[snhirsch]

Here's what I see on both an ancient belt-drive Perkin-Elmer and a newer direct-drive ALPS:

Inter-Pulse Jitter = Extremely low. Perhaps 20-50 usec. worst case.

Index Pulse Width = 3.66 - 3.70 msec. (All pulses, despite diagram above)

The drives use a Schmidt trigger to clean up index pulses. They are razor sharp in both cases. Inter-sector pulses are spaced at the predicted 20 msec. with rotational pulse centered exactly at 10 msec. from preceding sector pulse.

[Dutchacorn]

The diagram appears to claim 5 msec. duration for inter-sector pulses and 1 msec. for the rotational pulse. However, since the holes on all hard-sector media I've seen are the same diameter I am skeptical of those numbers. Later today or tomorrow I will measure index pulses from a drive and settle the issue.

Actually I believe that’s S and I (sector and index), not 5 and 1. But I thought it read 5.25 ms from the sector pulse to the index pulse. As the time between the index pulses is 12.5 ms in this diagram 2 ms is left for the pulse duration (12.5 -2x5.25). But today I found a better scan of this manual and it simply says 6.25 ms, not 5.25 ms. So no info on pulse duration.

Back to your actual measurements.

[snhirsch]

Just for fun, I looked at the index and rd-data signals with a logic analyzer. There were no glaring differences, but the HxC index pulse timing was consistently a bit tighter, averaging about 19.9 msec. and pulse width was wider, at 5 msec. Bit cell timing was right on the nose: 6 usec and 4 usec spacings.

[MarkGarlanger]

For my Heath emulator, I used a pulse width of 4mS. Since the FC5025 can't capture the hole status for each byte of data, I have it default to the hole being set for the first 64 bytes of each sector, which is 4mS.

If you would like to look at some other heath disk images besides the KyroFlux, you could look at some of the h17disk images, I've captured with the Device Side FC5025. The file format is described in detail in the h17disk-draft.pdf document on this page: http://heathkit.garlanger.com/diskformats/ The format can contain both the decoded data and the actual raw reads from the FC5025. The sector data, overlap so there should be no gaps and enough overlap, to recreate the entire track.
On that page, there is a link to the source code on github, which creates the H17DIsk format. The code provides a helper app, that will display detailed information h17disk images.

Heath CP/M distribution disks, in H17Disk format can be found here: http://heathkit.garlanger.com/software/ ... Heath/CPM/
The emulator that uses this format can be found on github: https://github.com/mgarlanger/VirtualH89

[snhirsch]

Hi, Mark! I thought the sector data wasn't supposed to start until some time after the trailing edge of the hole (rising edge from drive). Are you saying the timing starts from the leading edge of the hole (falling edge of pulse)?

[MarkGarlanger]

I believe so, here is the code in my emulator to determine hole status:

Code: Select all

    // check for a sector hole
    if ((pos % 320) < 64)
    {
        debugss_nts(ssFloppyDisk, ALL, "sector hole\n");
        return true;
    }

    // check for index hole
    if ((pos > 3040) && (pos < 3104))
    {
        debugss_nts(ssFloppyDisk, ALL, "index hole\n");
        return true;
    }

    debugss_nts(ssFloppyDisk, ALL, "no hole\n");

    return false;

And I was mistaken, I don't have the H17disk format supported in my C++ emulator, it currently is just in my javascript emulator. I was planning to figure out how to have one project dependent on another project in github, so there would need to be duplicate code between the project, but never got to that.

[snhirsch]

Ok, so that's a critical difference between Heath and Northstar formats. N* sector start is relative to the trailing edge of sector hole (rising edge of pulse). Heath is relative to leading edge of hole (falling edge of pulse).

Jeff: You are aware that Heath data encoding is FM, not MFM, correct? The Northstar formats you have are MFM, but Heath never supported that to my knowledge.

[snhirsch]

When I emulate a Heath diskette with the Gotek (using most recent HFE file), I'm seeing about 450 usec. between start of index hole (falling edge) and the initial stream of ~ 18 zero bytes. That would certainly explain why it cannot be read.

[snhirsch]

For comparison, the factory produced CP/M master for H17 has streams of zeroes across the leading edge of every sector pulse, which is what I'd expect to see. With Gotek emulation I'm seeing active data across almost all falling edges. So sectors appear to be shifted late.

[Jeff]

Ok, so that's a critical difference between Heath and Northstar formats. N* sector start is relative to the trailing edge of sector hole (rising edge of pulse). Heath is relative to leading edge of hole (falling edge of pulse).

Yes this is an huge difference ! If the sector data start is relative to the rising edge of the index signal then this is a problem because as far i know the kryoflux sample the index at the falling edge. So since we don't know from the dump the index length , we can't place its end properly...

Are you confirming this fact about the ns format ?

Jeff: You are aware that Heath data encoding is FM, not MFM, correct? The Northstar formats you have are MFM, but Heath never supported that to my knowledge.

Yes i am. And this is right now "don't care" because the hxc analyser support both encoding.

[Jeff]

When I emulate a Heath diskette with the Gotek (using most recent HFE file), I'm seeing about 450 usec. between start of index hole (falling edge) and the initial stream of ~ 18 zero bytes. That would certainly explain why it cannot be read.

Yes i confirm. You can see this shift into the track viewer. As i said i need to check if the bad index position come from the dump or the analysis.

[MarkGarlanger]

The other critical difference, is the sync byte, on Heath it is 0xFD vs NS's 0xFB.

So the DeviceSide FC5025, triggers reads from the rising side of the hole:

Read delay - Microseconds to delay after sector hole leading edge
before reading.

In my disk imager, I set this delay to 0, to immediately start reading. From the dumps I'm looking at, it looks like the sector header block starts after 5-10 zeros, then there is about another 16 zeros before the actual sector data block starts.

Code: Select all

  Aligned Data: 
        000: 0000000000fd0006 021c000000000000        |........  ........|
        016: 0000000000000000 000000fd47e17cb5        |........  ....G.|.|
        032: c2dd0578c9e5eb21 3221011700cdaa18        |...x...!  2!......|
        048: 2a43212229212a42 21af67222721e1c9        |*C!")!*B  !.g"'!..|
        064: cdd8051f3e0bc9e5 cd1121e1d8a73e04        |....>...  ..!...>.|
        080: 37c0cdb905cd5b06 d8226700cdc605d8        |7.....[.  ."g.....|
        096: cd1508d82123217e e6017ec83a3221a7        |....!#!~  ..~.:2!.|
        112: 3e0737c87ea7c9e5 212f21010300cdaa        |>.7.~...  !/!.....|
        128: 18010300213a21cd aa18e1cdb809cdaf        |....!:!.  ........|
        144: 090600fe2eca8606 fe41dad406fe5bd2        |........  .A....[.|
        160: d406cdfb06daf706 fe3ac2a906233e03        |........  .:...#>.|
        176: b9daf706010300e5 212f21cdaa18e1cd        |........  !/!.....|
        192: fb06daf706010800 e5213221cdaa18e1        |........  .!2!....|
        208: 7efe2ec2d20623cd fb06daf7063e03b9        |~.....#.  .....>..|
        224: daf706010300e521 3a21cdaa18e10601        |.......!  :!......|
        240: 4dcdb8097995a77e cc5509d878a7c83a        |M...y..~  .U..x..:|
        256: 3221fe00c8fe41da f706fe5bd2f7063e        |2!....A.  ...[...>|
        272: 01a7c93e0737c911 32070e099f000000        |...>.7..  2.......|
        288: 0000000000000000 0000000000000000        |........  ........|
        304: 0000000000000000 0000000000000000        |........  ........|
        320: 0000000000fd0006 031e000000000040        |........  .......@|
        336: 0000000000000000 000000000000            |........  ......  |

[snhirsch]

Ok, so that's a critical difference between Heath and Northstar formats. N* sector start is relative to the trailing edge of sector hole (rising edge of pulse). Heath is relative to leading edge of hole (falling edge of pulse).

Yes this is an huge difference ! If the sector data start is relative to the rising edge of the index signal then this is a problem because as far i know the kryoflux sample the index at the falling edge. So since we don't know from the dump the index length , we can't place its end properly...

Are you confirming this fact about the ns format ?

Update: I am the victim of my own poor proofreading.. I had written up the Northstar format incorrectly in an earlier document and never bothered to check my facts. As the manual shows, they do indeed reference the leading edge of the sector pulse. I am very sorry for my mis-statement to the contrary.

To be clear: Both northstar and heath care about the leading (falling) edge of the index pulse.

[MarkGarlanger]

Confused about you equating leading with falling and trailing with rising. At the leading edge of the hole, the hole status bit will be going from 0 to 1. and at the trailing edge of the hole, the hole status bit will be going from 1 to 0. I would think it should be leading/rising and trailing/falling. Or am I missing something?

[snhirsch]

I am talking about the electrical signal at the INDEX\ connection to the drive. It is inverted in sense such that logic low = 1, logic high = 0. On an analyzer or scope, the index appears as a negative-going pulse. Leading edge falling, trailing edge rising.