Digitized and extended by Igor Biletski, 2025.
Like so many computer manufacturers before it, Heath has withheld a great deal of information from its users concerning how HDOS handles disk file space.
Such lack of information is a major obstacle to recovering from diskette crashes, when it is often necessary to reconstruct files on a diskette by hand. Rebuilding files sector by sector requires intimate knowledge of the diskette structure, and until now few outside of Benton Harbor have had this knowledge.
In this article, I will try to reveal much of this formerly unavailable wisdom. Armed thus, you should in the future be able to salvage most of the data on a crashed diskette in some usable form.
Review
Data is recorded on the diskette surface in concentric circles called tracks. The number of tracks is dependent upon the material used, the recording head and the reliability required. Originally, due to problems reading the inner tracks, floppy-disk drives contained a maximum of 35 tracks; these days we can use 40 tracks with very high reliability, as HDOS does.
Each track is further subdivided into ten sectors (Fig. 1). In our case these are hard sectors, each of which has an individual hole cut into the diskette, one per sector, to mark its position within the track. Sector 0 has an additional hole between the other two, which yields a total of 11 holes around the inner rim of the diskette.
Fig. 1. Sector division of a track.
An LED and phototransistor within the floppy-disk drive uses these holes to produce sector pulses, which then can be monitored by the operating system to locate the start of a sector.
The HDOS Sector Header
HDOS could locate any sector on the diskette by first positioning the head on the correct track and then counting the number of sector pulses from the sector 0 mark generated by the drive. There is an inherent problem in such a scheme, however, in that the system could become lost by reading the wrong number of track or sector pulses.
Fortunately, HDOS does not subscribe to such a simple scheme.
During the initialization process, HDOS writes a dummy sector within each physical sector. This dummy sector consists of two parts: sector header and data area.
The leading nulls in the header give the system some "slop" in head positioning since they will be ignored (as will anything before the sync byte). The sync byte (0FD hex) tells the floppy-disk controller electronics exactly when a sector header is under the drive head.
As you can see, the volume, track and sector bytes uniquely identify each sector on the diskette, and the header checksum identifies any errors that occur in reading this header.
If an incorrect volume byte or header checksum is read a number of times in succession, HDOS will call the sector bad. An incorrect track or sector byte will cause a new sector search to begin (with the associated nightmarish sounds from the drive stepper motor).
Using a sector header such as this, HDOS needs merely to read one sector to determine precisely where on a diskette the head is currently positioned. There is no chance of getting lost, as with the more primitive method. Additionally, we gain a speed increase in sector searches, since HDOS does not need to spend a lot of time just in locating the desired sector. The advantages far outweigh the small amount of overhead we pay in creating and detecting the sector headers.
Notice that each sector contains the volume number of the diskette. This is done so that no read or write operation will succeed to any diskette not correctly mounted by HDOS. Diskettes formatted on the Heath-Lifeboat CP/M system all normally have volume numbers of 0.
| Position | Contents |
|---|---|
| Initial bytes | Nulls |
| First byte | Sync (0FD hex) |
| Second byte | Volume number |
| Third byte | Track number |
| Fourth byte | Sector number |
| Fifth byte | Header checksum |
The Sector Data Area
Immediately following the sector header and completely within the same physical sector is the data area.
Within the data area the nulls, sync bytes (also 0FD hex) and checksum perform the same basic functions as they do within the sector header.
The remainder of the data area consists of the actual 256 bytes in which we are really interested. During normal operations the sector formatting (header, sync bytes and checksums) is completely invisible to the operator.
| Position | Contents |
|---|---|
| Initial bytes | Nulls |
| First byte | Sync (0FD hex) |
| Next 256 bytes | Data bytes |
| Last byte | Checksum |
Special Areas
Once INIT has written dummy sectors throughout the entire diskette, it next creates five special areas necessary for the HDOS file-handling techniques.
Bootstrap area. The bootstrap area on the diskette contains the loader module for the operating system. When the HDOS system is cold-booted (i.e., brought up from scratch), the first four sectors (track 0, sectors 1 through 4) are loaded into memory and executed. These sectors provide the basic information necessary to locate—and load—the first part of HDOS (HDOS.SYS) into memory.
Label identification sector. The next reserved diskette area (track 0, sector 10) is used by HDOS to store some very basic facts about the diskette in question. Most importantly, this sector tells HDOS where to locate the start of the diskette directory and the GRT (group reservation table) sector. These two areas are the pointers to all the remaining files on the diskette.
HDOS has the ability to read files in small groups of sectors called clusters. Since these cluster sizes can apparently be varied from diskette to diskette, HDOS stores the current cluster size here also.
The remaining information within this sector is doubtless more familiar to you. This sector is also where the volume identification number and title are stored.
Reserved group table (RGT). The next sector we come upon (track 1, sector 1) contains the diskette RGT map. This sector allows HDOS to lock out bad clusters on the diskette with INIT.
Byte values within the RGT show the current status of the individual clusters in the same relative diskette positions. Usable clusters are marked with a 01 byte. Zero or any negative value locks sectors out.
When INIT formats a new diskette and prepares to write a blank directory, it first looks for a large enough number of good sectors in which to write it. Any bad sector returns will cause HDOS to lock out their clusters within the RGT. This is the only circumstance I know of that can cause a directory to be repositioned from its normal location (track 22, sector 2) on the diskette.
Track 0 is always locked out, since it is intended to be available for system use only.
| Area | Location | Purpose |
|---|---|---|
| Bootstrap area | Sectors 1 to 4 | Loader for HDOS.SYS |
| Label identification sector | Sector 10 | Diskette identification |
Reserved group table (RGT.SYS) | Sector 11 | Sector lock-out map |
Directory (DIRECT.SYS) | Usually starts at sector 222 | File entries |
Group reservation table (GRT.SYS) | Usually sector 238 | Cluster linkages |
Locations above retain the 1981 article's numbering. The tenth sector is logical sector 9 when counting from zero. Directory and GRT locations can vary; use the pointers in the label sector.
Label Identification Sector: On-Disk Structure
This sector stores the directory start, the group-reservation table location, and the cluster factor as described above; it also carries the volume number and the human-readable volume title. The fields below are laid out as they appear on disk.
| Offset (hex) | Bytes | Field and meaning |
|---|---|---|
00 | 1 | Volume serial number; used as the volume number in sector headers. |
01 | 2 | Initialization date. |
03 | 2 | First directory sector; start of DIRECT.SYS. |
05 | 2 | GRT sector; location of the group reservation table. |
07 | 1 | Sectors per group; the allocation cluster factor. |
08 | 1 | Volume type: 0 = data, 1 = system, 2 = no directory. |
09 | 1 | Version of the formatter that initialized the disk. |
0A | 2 | RGT sector; location of the reserved group table. |
0C | 2 | Volume size, in units of 256 bytes. |
0E | 2 | Physical sector size, in bytes. |
10 | 1 | Volume flags; device characteristics such as sides, track density, and fixed media. |
11 | 60 | Printable volume label. |
4D | 2 | Reserved zero bytes. |
4F | 1 | Sectors per track; start of the auxiliary area. |
50 | 2 | Long volume number (HDOS 3.x). |
Editor's addition, checked against the HDOS 3.02 Reference Manual, Appendix 13-E, pp. 13-129–130. This includes fields added after the original 1981 article. Label length (60) and auxiliary length (3) are assembler constants, not extra bytes stored on disk. The reserved expression before the label allocates zero bytes in this layout.
| Value (hex) | Meaning |
|---|---|
00 | Cluster locked out: bad or reserved. |
01 | Cluster usable for allocation. |
80 to FF | Negative byte values also lock out the cluster. |
| Value or entry | Meaning |
|---|---|
00 hex | End of chain: the current cluster is the last one. |
| Next cluster number | The byte at the current cluster's position points to the next cluster in the chain. |
| Entry for cluster 0 | Start of the free chain, which links unused clusters. |
| Directory entry | Gives the first and last group numbers. Follow the GRT from the first group until reaching the end marker. |
HDOS Directories
The directory ordinarily contains nine clusters of 22 entries each for a total of 198 possible entries.
| Offset (hex) | Bytes | Contents |
|---|---|---|
000 | 506 | File entries 1 through 22, each 23 bytes long. |
1FA | 1 | Zero byte: end of entries in this block. |
1FB | 1 | Length of each directory entry (23). |
1FC | 2 | Block number of this directory block. |
1FE | 2 | Block number of the next directory block; zero for the last block. |
Each directory file entry consists of the same 23-byte format as shown.
| Offset (hex) | Bytes | Contents |
|---|---|---|
00 | 8 | File name |
08 | 3 | Extension |
0B | 1 | Project |
0C | 1 | Version |
0D | 1 | Cluster factor |
0E | 1 | Flags: S = 200Q, L = 100Q, W = 40Q, C = 20Q |
0F | 1 | Reserved |
10 | 1 | First group number (FGN) |
11 | 1 | Last group number (LGN) |
12 | 1 | Last sector index (LSI) |
13 | 2 | Creation date |
15 | 2 | Last alteration date |
Q denotes octal. Later HDOS versions reuse some of these byte positions; see Table 5b.
| Bit | Mask (hex) | Meaning |
|---|---|---|
| 7 | 80 | System file |
| 6 | 40 | Flags locked against changes |
| 5 | 20 | Write protected |
| 4 | 10 | Contiguous file |
| 3 | 08 | Archive attribute |
| 2 | 04 | File is damaged |
| 1 | 02 | Locked against deletion |
| 0 | 01 | User defined |
Editor's addition from the HDOS 3.02 Reference Manual, p. 13-128. The original article lists the upper four flags.
| Offset (hex) | Bytes | Contents |
|---|---|---|
0B | 1 | Creation hour, BCD 00–23. |
0C | 1 | Creation minute, BCD 00–59. |
0D | 1 | Access count. |
0F | 1 | User area mask. |
15 | 2 | Last access date. |
Editor's addition from the HDOS 3.02 Reference Manual, p. 13-128. These fields replace the corresponding positions in Table 5; the entry remains 23 bytes long.
| Bits (article numbering) | Contents |
|---|---|
| 1 through 5 | Day (1–31) |
| 6 through 9 | Month (1–12) |
| 10 through 15 | Year minus 1970 |
| 16 | Zero |
The article numbers bits from 1 at the least significant bit. In zero-based notation the same fields occupy bits 0–4, 5–8, 9–14, and 15.
Group Reservation Table (GRT)
HDOS locates file clusters on a diskette dynamically. If a file uses cluster 36, for example, the next cluster within the file is not necessarily cluster 37. It is possible to link any two clusters not otherwise in use together within a file.
This is done to make maximum usage of the empty disk area. Imagine that (as under older systems) an operating system were always to write a new file into the largest blank space available at the time. The system would work very well until it reached a point where it had a large file to write into a number of smaller empty spaces. The system could not then use the smaller spaces until they could be squeezed together into at least one space large enough to contain the current file.
This is the advantage of a dynamic file scheme. The system makes use of all the available blank space without concerning itself with whether or not it is in one large group or fragmented.
All over the disk, HDOS really gives the ability to do both (remember the C switch), although it normally uses the dynamic mode.
For this reason, the directory only points to the beginning and end of a file. The actual cluster linkage is stored within the GRT.
Groups of clusters are strung together within the GRT to form what HDOS calls chains. Even unused clusters are linked into a free chain.
When HDOS begins reading a file, it starts at the cluster specified by the directory entry. The next cluster read will be pointed to by the byte in the first cluster's relative position within the GRT. This process continues until the entire file has been read. The byte in the last cluster's position contains zero—which verifies that the file entry within the directory is correct, since the last group numbers should match.
In this manner, if the last cluster we read was 26, byte 26 in the GRT contains the next cluster number we should read (or 0 if we are finished).
The free chain is linked to cluster 0. This we can do since cluster 0 is part of the system area and is locked out by the RGT.
Corrupt Diskette Structures
One problem with such a complex dynamic file scheme is that it can lead to a rather spectacular diskette demise.
If the RGT, GRT or directory are overwritten, or written incorrectly, our file linkage chains may no longer match the directory entries or usable sector map.
Perhaps two directory entries reference the same diskette cluster or a file attempts to link to a lock-out sector. Such situations indicate corruption of the diskette file structure.
When HDOS tries to mount a diskette, these linkages are tested (and in some cases updated). If any contradictions are found you will get that wonderful "Disk Structure Is Corrupt" message and an instruction to contact the Heath technical assistance department. This is because Heath is trying to protect us from further damaging the file structure by preventing further diskette write operations.
A better way of handling this situation might have been to make the diskette mount as read-only. Currently the corrupted diskettes can only be read using absolute track and sector utilities (such as the ABSDUMP utility available from HUG).
Summary
HDOS is an amazingly sophisticated system as microcomputers go. A number of file-handling features are incorporated which are not available on many similarly priced systems.
It is appropriate indeed that Heath Company is beginning to free up a great deal of information to its users. Certainly this article would never have been possible had this not been the case. Heath has always been more responsive to its users than its competitors have been, and just recently this has also become true of its response to its computer hobbyist customers.
I am sure that, as more and more information such as this becomes apparent, we Heath users will see an explosion of very powerful utilities coming our way.
Perhaps the H8/H-89 will finally take its rightful place among the giants of the industry.