Hard sector format

[MarkGarlanger]

Oh, ok, that makes sense.. Haven't really done much with electrical engineering since college.

Are you sure NS does the opposite of Heath? Based on the clip from the FC5025 docs, it's timing is off leading edge, and I know the FC5025 supports the NS, and it was the NS code that I based the heath imaging code on. I just looked at the the only difference is that they used 347 uSec for the delay. If I have my calculation correct, that is only about 5.5 bytes. Actually, that would be for FM, since they are using MFM, I guess that is about 10 bytes.

[snhirsch]

I have corrected my earlier posting. Both Heath and Northstar time sectors relative to the leading edge of index.

[snhirsch]

Mark, here is my corrected rendition of the Northstar MFM layout. Please see if this makes sense to you?

Code: Select all

Northstar DD floppy format

10-sectors per track x 35 tracks per side
MFM encoding

Single and double-sided formats are supported

---

Data Layout

[Leading (falling) edge of sector index]
[96 us delay]
[Preamble = 33 Bytes of 0]
[Sync 0xFB 1-byte]
[Track-Sector 1-byte (see below)]
[Data 512-bytes]
[Checksum 1-byte (see below)]

There is no formal padding at the end of the sector. In a hard-sector
format the diskette controller is expected to re-sync on the next
index hole.

---

Track-Sector Byte Detail

  Bits 0-3 = Sector (0..9)

  Physical Order from rotational index: 0 2 4 6 8 1 3 5 7 9

  Bits 4-7 are related to the track.

On side 0 of a diskette, the value in bits 4-7 cycles through the
sequence: 0x0 0x4 0x8 0xC as track advances. In other words,
tracks 0, 4, 8, 12, 16, 20, 24, 28, 32 have a value of '0x0' in the
upper four bits.  Tracks 1, 5, 9, 13, 17, 21, 25, 29, 33 have a value
of 0x4 in the upper bits, etc.

On side 1 of a double-sided diskette, the value in bits 4-7 cycles
through the sequence: 0x1, 0x5, 0x9, 0xD as we advance inward from the
outermost track. This amounts to the same pattern shown above, but
with bit 4 set to denote the second side of the diskette.

---

Checksum Byte Detail

The checksum algorithm works as follows:

// Sector data
unsigned char data[512];

unsigned char csum = 0;
for (int i=0; i<512; i++) {
  csum = csum ^ data[i];
  csum = (csum << 1)|(csum >> 7);
}

// Resulting value is written to diskette as the checksum byte.

---

Logical data organization on double-sided diskette

Data is written in a serpentine order:

Side 0:  Track 0..34
Side 1:  Track 34..0

---

NOTE:

The Northstar technical documentation has a discrepancy between
figures and text.  Figures 3-4 and 3-5 show the layout for DD MFM
diskettes with 512-byte sectors.  The text references an older SD FM
format with 256-byte sectors.

The document you are reading now is intended to cover the DD MFM
512-byte format.

[MarkGarlanger]

I don't know much about NS disks, but seems to match what I saw in the FC5025 source code.

Just to make sure there is no confusion, I would use "sector hole" instead of "index hole", like the FC5025 docs mention:

Code: Select all

Sector hole
                1 = First sector hole after index hole
                2−99 = N’th sector hole after index hole
                254 = Index hole (hard sectored disks)
                255 = Index hole (soft sectored disks)

[snhirsch]

I don't know much about NS disks, but seems to match what I saw in the FC5025 source code.

Just to make sure there is no confusion, I would use "sector hole" instead of "index hole", like the FC5025 docs mention:

Ok, glad to know I'm not entirely out to lunch here . It turns out that the FC5025 ignores the track/sector byte. I had to code in a simple diagnostic print out to figure out how it was formed.

[MarkGarlanger]

Saving all the side information about track #, sector #, checksums, etc. was the motivating force, for creating the new h17disk format, to save all this information. This allows my emulator to know nothing about sectors, header format, checksum calculation, etc.

BTW, I looked at the checksum calculation for heath, and it appears to be identical to the NS algorithm:

Code: Select all

BYTE updateChecksum(BYTE checksum, BYTE val)
{
    // First XOR it.
    checksum ^= val;

    // Now rotate left
    checksum = (checksum >> 7) | (checksum << 1);

    return checksum;
}

[Jeff]

Some progresses : Now decoding the sectors (with checksum checking!):

ns_trk.jpg (220.6 KiB) Viewed 7831 times

ns_trk2.jpg (159.92 KiB) Viewed 7831 times

[snhirsch]

Great work, Jeff! Any ideas about why emulation is failing to work?

And, does a 'red' sector mean failing checksum? If so, there may be still an issue somewhere. The original diskette has no read errors.

[Jeff]

Great work, Jeff! Any ideas about why emulation is failing to work?

yes :

index jitter + shifted in the dump.
You can even see this in the screen capture above. the write splices (red lines) should be aligned to the index signal, but as you can see they are not.
Now we have you to find the root cause : the hxc software ?, the kryoflux, the drive you have used to dump the disk ? all the three in the same time

https://hxc2001.com/floppy/forum/viewtopi ... =60#p18096

And, does a 'red' sector mean failing checksum? If so, there may be still an issue somewhere. The original diskette has no read errors.

This is some unused sectors.

[snhirsch]

Ooof. Well, the drive I used to dump the diskette was the same one I measured yesterday and jitter is extremely small (as I reported). I would tend to suspect the original drive that wrote the diskette before the Kryoflux or HxC.

Today I will:

• Start with bulk-erased diskette
• Format and write using that direct-drive ALPS mechanism (I trust it)
• Image w/ Kryoflux on same drive
• Send you that RAW file

This eliminates some variables and maybe that image can be emulated.

Let's start with Northstar and if we make progress I'll do the same for Heath. Eventually we'll need to deal with some degree of jitter, but need to start somewhere .

[Jeff]

Ooof. Well, the drive I used to dump the diskette was the same one I measured yesterday and jitter is extremely small (as I reported). I would tend to suspect the original drive that wrote the diskette before the Kryoflux or HxC.

Today I will:

• Start with bulk-erased diskette
• Format and write using that direct-drive ALPS mechanism (I trust it)
• Image w/ Kryoflux on same drive
• Send you that RAW file

This eliminates some variables and maybe that image can be emulated.

Let's start with Northstar and if we make progress I'll do the same for Heath. Eventually we'll need to deal with some degree of jitter, but need to start somewhere .

ok perfect, what i think too is that you should redump the disk with drive used to format / write it.

[MarkGarlanger]

You may want to try converting on of the .h17disk files, to see if you have better results with them.

[snhirsch]

Ok, Jeff. After an extended battle getting the KF to work on my Windows 7 box, I have the raw dump. It's been uploaded to your FTP in box.

[Jeff]

Ok, Jeff. After an extended battle getting the KF to work on my Windows 7 box, I have the raw dump. It's been uploaded to your FTP in box.

Thanks. Same issue, so i think that there is something else...

But anyway try this image :

https://hxc2001.com/vrac/HS/northstar_nst.hfe

This one was regenerated from a raw file, so jitter and no index position problem.

[snhirsch]

Some success! I can list the directory on that disk, but surface read verification fails at sector 342. That's an interesting number. Sector 0-349 are on side 0, so 342 is right at the beginning of side 1 (Track 34, sector 2, since arrangement is serpentine).

When I try to copy files from it, I hit read errors immediately. But, this is definitely progress . Nice work.

(Error on Side 1 is "no index pulse" and "seek error" - latter suggests the track nibble isn't as expected - see my doc on the track sector byte)