This is a follow up to comments prepared on Sept. 30 "Full Track Reads from an H17 Drive."
In cooperation with Mark Garlanger and Chris Elmquist we now have a process that transfers 40 track images of H17 disks to the PC, corrects for the bit shift that is inherent in the full track read process and converts the corrected images to H8D format. The process has been tested with six different disks so far: 3 distribution w/write protect (never written locally) and 3 locally generated and frequently written work disks. Currently this work is limited to hard sectored disks in an H17 drive. A similar process for soft sectored disks and 96 TPI drives is planned for the future.
While the original program worked, that is, it sent full tracks to the PC, it did not start each track on sector zero but rather on a semi-randomly selected sector. The improved version starts each track read on sector zero. This required finding the right combination of hole detection and interrupt enable/disable sequences. It works as desired.
Originally, once a raw 40 track image was transferred to the PC, the program scanned that image looking for the first non-null byte. If it was not a sync byte, it did a bit shift routine in an effort to create a sync byte and adjust the rest of the header or sector. A problem arose when non-nulls appeared that were not shifted sync bytes but rather what appeared to be random "one" bits in the inter record gaps.
From analyzing full track images on the PC, it appeared that the area of "null padding" between header and sector and between sector and following header usually includes stray "one" bits instead of just nulls. Presumably this happens in the physical area of the disk surface where a trailing null pattern of one write stops and a subsequent leading null pattern starts, possibly where the write gate turns off after a write operation or on before a write operation on the following sector. This physical phenomenon is probably why the ROM routines use the sync pattern write process and the sync detect read process. In any case, after looking at numerous inter-record gaps it seemed that there were one bit strays, i.e., the bytes were (in hex) 01, 02, 04 08, etc. It appears that this may well be the case for distribution disks that were INITed and then written only once, which would explain an earlier success with imaging a distribution disk.
In keeping with the trend of finding new surprises in old technology, processing of locally created work disks revealed that there were numerous stray patterns in the area where nulls were expected. The non-null bytes had more than one bit true and there were often two non-null bytes in a row in this inter-record gap. Up to this point the program just rejected a non-null followed by a null because a bit shift correction would not produce a valid sync byte. Clearly this process had to be changed. To overcome this problem the revised program checks non-null bytes in pairs to see if they constitute a pattern that, if properly shifted, would result in a sync byte. Anytime this check failed, the program moves on the next byte pair. This process may need some refinement, but it has worked on six different source disks so far. Experimentation showed that as many as 60 bytes need to be checked for header sync, i.e, the inter record gap before a header can be as much as 60 bytes long. Fewer bytes need to be checked for the gap between header and sector. Finally, a full track read of 3200 bytes seems to be sufficient, although tracks on disks that produce errors may need to be read multiple times and additional adjustment/corrections techniques applied.
At this point the process uses three programs on the PC and one on the H89. The H89 program reads a full track at a time and sends it to the PC. The first PC program is the serial communications routine that accepts the data sent by the H89 and saves it to a disk file. The second PC program reads the raw file (.raw) and shifts the bit patterns, if necessary, to restore the bytes to the proper patterns. It also creates an intermediate file (.sft) in the following format:
| sync, volume number, track number, sector number, checksum | <-header record |
| sync, <256 bytes of sector data>, checksum | <-sector record |
for a block length of 263 bytes per block (a block consists of a header record and a sector record) with 400 blocks per image. All null padding in the raw image is removed. The third PC program takes this intermediate 263 byte-per-sector file and converts it to H8D format. While it is no longer necessary, the routine can massage the data so that the sector order runs from zero to nine on each track. In the future this program would be changed to produce the image in Mark's "New Disk Format" proposal. An intermediate goal will be to combine the PC routines into one program with options. The H89 code is included with this document. The PC programs are written using the Qt-4.5.2 IDE on a PC running Slackware Linux, version 12.2 and are not included at this time.
Research indicates that for reading and writing of soft-sectored formats the disk controller does the most of the work. It generates address marks and other things that we usually never see. The Percom soft-sectored controller on the development system uses a 1791B chip. According to the data sheet and the application notes, the 1791B has a read-track command. While this looks like it should make life easy, there will probably be some surprises once serious work begins on soft-sectored media.
Please offer your questions, comments and suggestions to dsemrick@gmail.net or Mark or Chris via the SEBHC group.
- -
Dan Emrick
November 14, 2009