Hard sector format
-
- Posts: 9
- Joined: Sat May 19, 2018 6:04 pm
Re: Hard sector format
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.
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.
Re: Hard sector format
I have corrected my earlier posting. Both Heath and Northstar time sectors relative to the leading edge of index.
Re: Hard sector format
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.
-
- Posts: 9
- Joined: Sat May 19, 2018 6:04 pm
Re: Hard sector format
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:
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)
Re: Hard sector format
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 wrote: ↑Sat May 19, 2018 11:20 pmI 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:
-
- Posts: 9
- Joined: Sat May 19, 2018 6:04 pm
Re: Hard sector format
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:
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;
}
Re: Hard sector format
Some progresses : Now decoding the sectors (with checksum checking!):
Re: Hard sector format
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.
And, does a 'red' sector mean failing checksum? If so, there may be still an issue somewhere. The original diskette has no read errors.
Re: Hard sector format
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
http://torlus.com/floppy/forum/viewtopi ... =60#p18096
This is some unused sectors.
Re: Hard sector format
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:
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 .
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
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 .
Re: Hard sector format
ok perfect, what i think too is that you should redump the disk with drive used to format / write it.snhirsch wrote: ↑Sun May 20, 2018 4:38 pmOoof. 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:
This eliminates some variables and maybe that image can be emulated.
- 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
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 .
-
- Posts: 9
- Joined: Sat May 19, 2018 6:04 pm
Re: Hard sector format
You may want to try converting on of the .h17disk files, to see if you have better results with them.
Re: Hard sector format
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.
Re: Hard sector format
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.
Re: Hard sector format
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)
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)