Several sources describe the H17 data format as a 5-byte header record followed by a 258-byte data record. Here is a little more detail.
Heathkit did the hobbiest a great service when it published the commented source code for its HDOS 2.0 operating system. Among the documentation is the code for the H17 disk access ROM routines and the code for INIT.ABS, a program for initial formating of an H17 floppy disk.
The following description is derived, initally from the ROM code and INIT.ABS for HDOS. This description is conceptual in nature and does not delve into precise timing requirement nor the methods of handling directory entries, sector allocation nor bad sector management.
Data on the H17 disk is laid out on 40 tracks each having 10 sectors yielding 400 sectors. Each "sector area" contains, among other things, 256 bytes of user data.
Each sector of user data is introduced by a pre-defined synchronization byte of 0xFD (hex) and is followed by a checksum byte calculated by the writing software/firmware. Thus each block of user data actually contains 258 bytes. Just before each 258-byte data block is a 5-byte header that consists of a sync-byte (0xFD), three bytes containing, in order, volume number, track number and sector number, and finally a checksum byte.
This layout conceptually occupies 263 bytes for each sector of user data. In reality, there are gaps between the header and sector blocks as well as gaps after sector blocks before the next header block. More on this later.
The sector holes punched in the rotating medium assist the drive controller board with synchronization. When the software/firmware detects a sector hole, it instructs the controller to begin looking for the 0xFD sync-byte of the header. Upon detecting the sync-byte within a specified time frame, it then reads the next four bytes to obtain volume, track and sector numbers and a checksum byte. It uses the checksum as an indicator of a valid read and then checks the other bytes to determine if the desired track and sector have been located. If so, it continues reading, checking for the 0xFD sync-byte of the sector block. When found within a calculated time frame, it continues reading until it has captured the 256 data bytes and the checksum byte.
If either of the predetermined time frames expire before header or sector sync-bytes are detected, if checksums are not correct or if the header containing the desired track and sector number cannot be located, the system signals an error.
The 5-byte header blocks are only written to the disk during formatting or initialization. (Remember INIT.ABS?) Thereafter the header blocks are only used to locate the physical space on a disk where user data is to be written.
When user data is to be written, the directory management routines determine which sector is to be used. The disk controller then seeks the header block with that track/sector number pair. When it finds the desired header, it writes a string of 10 zero bytes, then the sync-byte followed by the user data and a checksum. This write is followed by 10 bytes of zero or nulls. This padding ensures that there is a "no data" space before and after the live data so that subsequent reads do not detect old data or stray bytes not associated with the desired, newly written data. This method helps to prevent errors due to small rational speed variations and improves reliability of reading a disk on a drive other than the one on which it was written.
Using the above description, a number of experiments were crafted in which custom software was used to locate the sector hole for sector zero and then read 3200 bytes without regard to sync-bytes or null bytes or additional sector hole detection. In a perfect world, a full track of our chosen medium would contain 10 header and sector pairs with null padding between them. If there are 10 null bytes before each header and sector and 10 null bytes following each sector, there would be 2930 bytes of something per track. That is, for each sector there would be:
Sector Hole 10 nulls 5 header bytes 10 nulls 258 data bytes 10 nulls Sector Hole |
or 293 bytes per user sector. For 10 sectors per track this give 2930 bytes.
The experiments showed that there are frequently more than 10 null bytes in the null-padding areas as well as some bytes in the padding areas with values other than zero. This departure from the "perfect world" comes about because the system is doing exactly what it was designed to do - account for positional offsets on the rotating medium. This means that, because a write of 10 null bytes doesn't start exactly in the same place as a previous one, there can be more than 10 nulls in the inter-record gap. In addition, the activation/deactivation of the write gate may cause stray bits to occur when overwriting a previoius gap area. To account for these occurrences without returning to the sync-byte detection process, the custom software uses the empirically determined number of 3200 bytes to "capture everything" while not capturing a large overlap.
Again, the the value of 3200 was chosen based on a number of experiments with full-track reads.
The result of this analysis is that there are bytes on an H17 disk in addition to the conceptual header and data blocks. An actual description might be:
Sector Hole Padding nulls - At least 10 Header Bytes - 5 (sync, volume, track, sector, checksum) Padding nulls - At least 10 Sector Sync - 0xFD User Data - 256 bytes User Checksum - 1 byte Padding nulls - At least 10 Next Sector Hole |
For software relying on H17 ROM routines or similar assistance, this is all academic. For custom software attempting to capture all bytes on a disk, the padding area, of varying length and often stray 1-bits, and the header and sector content are important.
The link at the bottom right of this page will take you to a detailed description of the development of the full-track reading/image capture project, including more details on the process for handling the null padding and stray 1-bits that occur in the padding area.
- -
Dan Emrick
May 3, 2011