It seemed that every time the project neared completion, Mark would come up with another approach or another item of interest. The most recent item involves the final piece of information that can be gleaned from a hard sectored 40 track disk. It is the location of the disk index/sector holes with respect to bit patterns recovered by the whole-track read process.
In order to capture hole-detect information, the program would have to read the disk status byte each time a character was received from the controller. This appeared to be simple enough, in theory. Actual implementation, as often is the case, turned out to be non-trivial.
The basic approach to the data capture was to set a counter to 3200 to allow collection of 3200 bytes of data from the controller. A sub-routine would wait for the controller to say that a byte was ready and then read it and stuff it into memory. When the counter indicated 3200 bytes collected, the data was sent to the PC via the serial port. This is the process that was used to successfully capture and re-format the six tests disks as previously reported.
The code was modified to read the disk status byte (thus capturing the hole-detect bit) and stuff it into memory before the counter was updated. This resulted in 6400 bytes of data - a sector data byte and a hole detect data byte - for each of the counter updates. When the counter expired, 6400 bytes were transferred to the PC. This process was repeated until 40 tracks worth of captured data had been transferred. A utility on the PC then separated the sector data from the hole data. The sector data was then fed the bit-shift/re-formatting program.
Occasionally the output of the correction program was a good H8D image. Most often, however, the correction program reported data corruption. That is, the format of the input data did not contain information in the proper places to allow bit-shift correction. It looked like the serial transfer process was dropping bytes. Using experiments suggested by Chris and Mark, we determined that the serial transfer process was working reliably. The problem had to be in the original data capture from the H17.
Once the serial transfer process was validated, we all agreed to focus on the timing of the data retrieval from the disk. Using an approach developed by Mark involving some Z80 op codes, the critical loop timing issue was resolved. The program now reliably captures valid sector data and hole-detect data and transfers it to the PC.
The program fulltrk9.asm on the downloads page is the most recent version of the H17 data capture program. When it is used, a routine similar to the command line program split.c must be run on the PC to separate the sector data from the hole data. The resulting files can be re-formatted and/or analyzed in any fashion desired.