Looking for HDOS diskette layout -- FOUND IT!

I FOUND IT! :-) I knew this info was on line, but it didn't Google. But I did have it printed and buried in a binder, dated January 2002. I went to the site and found that the author, David Shaw, has made some updates since. This might be one of the few pages Google does not seem to have indexed. Typing distinct phrases directly from the text into Google produces no match, although other pages from the same site can be found. Nonetheless, it's here: http://home.comcast.net/~davidwallace2000/h8/project8080_archive/design_h17. html The information is specific to the 5-1/4" hard sector subsystem used with the H-8 and H/Z-88/89/90. The CliffsNotes version: General form is 256 byte sectors, 10 per track, 40 or 80 tracks, single or double-sided (the distribution standard was 40 tracks single-sided). Filesystem structures allow other geometries. Dwight is correct that the system tries to keep the directory in the "center" of the diskette--beginning at track 13 (from zero) for one-sided disks, 26 for double-sided). That space is also mapped to a file called DIRECT.SYS. The directory contains entries each 23 bytes in length, and entry layout is eerily like MS-DOS... 8.3 filenames stored in 11 bytes, the 8-byte name part and 3-byte extension part each zero-filled as needed. Allocation is done in groups of 2, 4, or 8 sectors each. The group reservation table, mapped to a file in the directory called GRT.SYS, again foreshadows MS-DOS: it's an 8-bit FAT. Byte entries in this table correspond to groups on the diskette. The byte value in each entry contains the number of the next group allocated to the file, or 00 if the current group is the last group in the file. Each directory entry points to the first group allocated to a file. The GRT then provides the links from that first group to the next through end of file. The free group list is also stored here, beginning at entry 0. So far so good. Now let's take simple and confuse it a little. There's also a reserved group table, mapped to a file called RGT.SYS (more distinct names would have been nice). Each byte in this map also corresponds to a group. Permanently reserved groups, like the disk label and known-bad blocks, are marked 0xFF. When a disk is mounted, all non-FF entries are zeroed, then the system follows the allocation chain of EVERY file in the directory, incrementing the RGT entry for each reserved group in the GRT. When a group in the RGT has a value >1, a block is allocated to more than one file and a "corrupt disk" message results. The free group list is also rebuilt/rewritten at mount time by this process. Ahhh, no wonder it takes a moment to mount these disks. :-) Free blocks are found by traversing the linked list in the GRT, not scanning for zeroes in the RGT, so the RGT's primary use seems to be that mount check, and it's otherwise little-used. Anyway, there it is, and thanks to David Shaw for providing it. There's information on the physical format as well, which may be more relevant to the poster's purpose based on what I saw of the link posted to his project (a diskette emulator--hmmm, gotta get me one of these when he's done). There were also other controllers with different physical formats, like Magnolia and Heath's own Z-89-37 and -67, as Fred pointed out, and I'm sure CP/M was more commonly used with those controllers than HDOS, but it could/should have worked nonetheless. Patrick P.S. HDOS author Gordon Letwin became an early employee of Microsoft after leaving Heath (1979)--go to the dark side, did he. It stands to reason that he was involved with the creation of MS-DOS, and thus the similarities in underlying structures, although it's also not unreasonable to imagine that Tim Patterson had already examined and borrowed from Gordon's work before Tim brought QDOS to Microsoft. Does anyone know which, or other?