New H17 Hard-sectored Disk Image
1 1.0 Overview 2 This document proposes a new format for Heathkit H17 Hard-sectored Disk Images. The main goal is 3 to add header data to the disk format, currently H8D stores the data blocks on a hard-sectored disk but 4 does not store the 5 byte header for each sector. This information is critical to transparently supporting 5 different OS (HDOS vs. CP/M) disks in an emulator.
6 1.1 ASCII Section 7 ------Beginning of Part 1 ------8 H8D - Heathkit H17 Hard-Sectored Disk Image
17 1.2 Binary Data 18 The binary data MUST start immediately following the EOF character in the ASCII Section. It will 19 always include the 3 byte file tag and 3 byte version number at the start of the section. At offset 0x06, 20 blocks as defined below will be stored with the IDs in numerical order. Table 1: Current Layout Binary Data Offset Name Size Required Description (bytes) 0x00 Signature 3 Yes ASCII “H8D” to confirm file type. 0x03 Version 3 Yes The file format version. 0x06 Disk Format 11 Yes General information about the disk Block such as Heads, tracks, sectors. 0x11 Flag Block 6 Yes Flags for the disk 0x17 Data Block Variable Yes The actual data from the disk Variable Sector Variable No A Mapping of status code for the Status reading of each sector on the disk. Variable Reserved Variable Yes/No Any other blocks that will be added to the future.
21 2.0 Brief Description
22 2.1 Part 1 23 Part 1 is similar to the ASCII header included in the .IMD file format created by Dave Dunfield. 24 This information is to help someone viewing the file via 'TYPE' (DOS), 'cat', or 'more' (UNIX) or some 25 other command. Although this information SHOULD be included all files, all decoder applications 26 MUST be able to handle files if the only portion of part 1 is the
29 2.2 Part 2 30 The second part of the file contains the binary data describing the structure of the disk and the actual 31 data bytes.
32 2.2.1 Header 33 The header starts with the 3 bytes: 'H8D'. This signature allows programs to quickly verify that the file 34 is in the correct format. 35 The version number is the next field and is 3 bytes long. This field is contains the version of the 36 software that created the disk image.
37 2.2.2 Block Format Table 2: Block Format Position Description 1 Block ID type and flags 2-[3 or 5] Length [4 or 6] Block Data - Dependent on Block ID type ... [4 or 6] + Length 38 39 The final portion of the file consists of 3 mandatory blocks and zero or more optional blocks. 40 Each block contains a 3 or 5 byte header, followed by the data associated with the block. 41 The first byte of the header consists of 3 fields, a one bite Mandatory flag, a one bit length flag, and a 6 42 bit ID field. The next 2 or 4 bytes of the block (dependent on the length flag) is the Data Block Length. 43 The actual Data Block follows the 'Data Block Length' bytes. The format of this data is dependent on 44 the Block ID type. Table 3: Block ID Type Layout (First Byte of the Header) Bit 7 6 5 4 3 2 1 0 Description M L Block ID 45 46 The Mandatory bit (M), Bit 7 (0x80), signifies if decoding and processing the block is mandatory to 47 properly decode the file. This allows new blocks to be added and flagged as optional if it doesn't impact 48 the readability of the core part of the file. A 0 value means this block can be ignored by older decoders, 49 or even current decoders that do not care about the information. A value of 1 means the the decoder 50 should generate an error and not process the file any further if the ID number is unknown by the 51 decoder. 52 The Length bit (L), Bit 6 (0x40), signifies whether the length field is 2 or 4 bytes long. A 0 value means 53 the Length field is 2 bytes, a value of 1 means the length field is 4 bytes.
54 2.2.3 Block ID Values Table 4: Block ID Type Values Value Name Required Description (lower 6 bits) 0x01 Disk Format Yes General information about the disk such as Heads, tracks, sectors. 0x02 Flags No Flags for the disk 0x20 Data Block Yes The actual data from the disk 0x21 Sector Status No A Mapping of status code for the reading of each sector on the disk. All other Reserved Undefined. Any new IDs need to be reserved value to avoid potential conflict. 55
56 2.2.3.1 Disk Format Block ID 57 The Disk Format Block describes the general layout of the disk. This includes one byte for the Format 58 Type (values to be determined). Next, it includes the number heads. Valid values are 1 or 2. Next is the 59 Number of tracks. Valid values are 40 or 80. Next is number of sectors, for hard-sectored disks, this 60 will always be 10. Next is the sector size, this is only for the data portion of the block. It will always be 61 set to 256. Finally, is the sector size stored on in the file, to include the header portion of the sector plus 62 the sync and checksum of the data block, the value of this field will be 263. The “Data Block Offset” 63 specifies where the data from the sector starts. Since this format will include the 5 byte header plus the 64 sync byte for the data portion of the sector, the offset to the data portion of the sector is 6. [[ There 65 needs to be a better way to specify this so that it allows the “Stored Sector Size” to increase to include 66 the zero pads... ]] Table 5: Disk Format Block Description Size (bytes) Allowed Values Format Block ID 1 0x80 (0x00 + 0x80) Block Length 2 0x00 0x08 Format Type 1 TBD Heads 1 1 or 2 Tracks 1 40 or 80 Sectors 1 10 Data Sector Size 2 256 Stored Sector Size 2 263 Data Block Offset 2 6 67
68 2.2.3.2 Flags Block ID 69 The flag block currently has 3 fields. The values may be boolean or values. A bool only use the bit 0. A 70 value flag uses bits 0-6. For both types, bit 7 is defined to be the Mandatory flag. If the value is 1, the 71 decoder must understand and decode the value. A value of 0, implies that the image can be correctly 72 decoded without the decoder understanding the flag. None of the current flags are mandatory. 73 Write-Protected (W/P) Flag (boolean) - This signifies if the disk is write protected. If the value is 1, the 74 disk is write protected. If 0, writes are allowed. 75 Distribution Disk(value) - This flag signifies if the image was created from an original distribution 76 disk. The value of 2, means that it was created from an original distribution disk. A value of 1, means 77 status unknown. A value of 0, means it was not an original distribution disk. 78 Source of Header data(value) - This flag determines if the headers for the image were save from the 79 actual disk or if it was auto-created by a utility. A value of 1 means that the header data (plus data block 80 sync and checksum) was captured from the actual disk. A value of 0 means that it was generate by a 81 conversion utility. A value of 2 means that it was created by a program ran under an emulator. [[Could 82 there be other values for this? ]] Table 6: Flag Block Description Size (bytes) Allowed Values Format Block ID 1 0x80 (0x00 + 0x80) Block Length 2 0x00 0x03 W/P Flag 1 0x00 or 0x01 Distribution Disk 1 nn Source of Header data 1 nn 83
84 2.2.3.3 Data Block ID 85 The data block section is similar to the existing H8D format. Instead of each sector using 256 bytes, 86 each sector contains 263 bytes. The first 5 bytes are the header bytes. The length of this block is 87 determined by calculating the following:
89 Sync Byte - the Sync Byte is defined to be 0xFD in the H17 ROM. 90 Volume Number - the Volume number on track 0 is always 0, to allow booting on mounting of disks 91 before the volume number has been determined. For Heath's CP/M volume number is also 0 for all the 92 remaining tracks. Under HDOS, the volume number can be any 8-bit value. The disk's volume number 93 is store in the first byte of sector 9 on track 0. All tracks, after track 0, should be this value. 94 Track Number - Ranges between 0-39 on a standard H-17-1 drive and 0-79 on a H-17-4 or H-17-5 95 drive. 96 Sector Number - Ranges between 0-9. 97 Checksum - Checksum for the header is calculated over bytes 2-4, by initially setting the value to 0. 98 For each byte, the value is XORed with the current checksum, then shifted left by 1. On writes, the 99 final checksum value is written to disk. On reads, the value is calculated the same way, and the value is 100 compared to the byte read from the disk. 101 The remaining 258 bytes make up the data portion, it contains a sync byte, 256 data bytes, and a 102 checksum byte. Table 9: Data Position Description 6 Sync Byte 7 to 262 Sector Data (256 bytes) 263 Checksum 103 104 Sync Byte - Same as for the Header - 0xFD. 105 Sector Data - The 256 data bytes of the sector that the operating system makes available to user-level 106 applications. 107 Checksum - The checksum for the the data block is calculated the same as the header block, it is 108 calculated on bytes 7 to 262 in the block.
109 2.2.3.4 Sector Status ID 110 The sector status block is used to signify if any read errors were detected ,when imaging the disk. This 111 is an optional block. There are two valid sizes for this block, 0 and [heads]*[tracks]*[sectors]. If the 112 imaging program detected no problems reading the disk, it should set the length to 0. If the imaging 113 program detected problems reading any sector, it SHOULD include the block with the status for each 114 sector. Sparse encoding is not supported. [Question: Should it be? ] If a conversion utility converts an 115 old style H8D file, which does not include this information, this block MUST not be included. This 116 allows decoding program to detect this condition and know that nothing can be inferred about the 117 integrity of the disk. Table 10: Sector Status Values Value Description 0x00 No error 0x01 No Sync detected for the Header block 0x02 Invalid Checksum for the Header block 0x03 No Sync detected for the Data block 0x04 Invalid Checksum for the Data block [[I'm sure I'm missing a lot of other error conditions, if anyone has more ideas or they will be added as we develop the H89 and Windows Clients]] - Sector not found ?
118 3.0 Possible future features 119 One of the goals for the new format is to make it easy for people to add new features without breaking 120 backward compatibility. I haven't spent much time thinking of new ideas, but one of the features I 121 would like to add (once the core format has been defined and implemented) is a way for the emulator to 122 keep multiple versions of a disk encoded in one file.
123 3.1 Multiple disk version 124 When using disk images, even though it's possible to copy the images and use the copies, it would be 125 nice to have some internal versioning so that the user has the flexibility to roll-back the disk image to 126 an early state. By keeping the latest version in the standard Data Block, older programs will still work 127 with these files. The older versions of changed sectors will be stored in a non-mandatory newly defined 128 block. New programs/utilities that want to take advantage of the versioning information will be able to 129 read this new block and merge this data with the data from the Data Block to recreate older versions of 130 the disk. A tool can be created to allow the user to manipulate the versioning information. Some 131 possible commands for this tool would be to roll back to a specific version, delete specific versions, 132 and delete all old versions.
133 3.2 Other ideas 134 [[ Any other ideas for future features that are not required by the core format?? ]]