Minor ImageDisk update has been posted

On 8 Mar 2012 at 11:27, Simon Owen wrote: The reason I didn't use another bit in the heads field is: 1) Unlike the cylinder and head maps where the "master" cylinder and head fields still contain useful data (the physical cylinder and head) - once you have supplied a map of sector sizes, the "master" sector size value becomes meaningless - so why not use it and save the bit in the Head field for future expansions. 2) By changing the track sector-size field to a formerly invalid value, the existing tools will report "Bad sector size" instead of "getting lost" with the unexpected extra data in the track and generating random errors. The map is the same "style" as the others - except that it is 16-bit entries instead of 8-bit entries. This was requested to accomodate the ability to represent arbitrary sector sizes, and given the rarity of mixed-sector-size disks, it seemed reasonable to spend the extra bytes to make the extension provide for both mixed sector sizes and/or non-standard sector sizes. I haven't actually tried, but my read on the NEC 765 controller manual suggests that the PC controller can't format mixed- sector sized disks. It says: "The particular format which will be written is controlled by the values programmed into N (number of bytes/sector), SC (sectors/cylinder), GPL (gap length) and D (data pattern) which are supplied by the processor during the command phase. The ID field for each sector is supplied by the processor, that is, four data requests per sector are made by the FDC for C (cylinder number), H (head number), R (sector number), and N (number of bytes/sector). This allows the disk to be formatted with non-sequencial sector numbers if desired". Note that N,SC,GPL and D are sent only once in the format-track command. C,H,R,N are sent per sector. My interpretation on this is that the 'N' sent during the command controls the physical sector size, and the 'N' sent during the data phase controls only the ID field value. Given that the PC can't recreate mixed-sector sized disks, and their rarity in classic systems (seems to be used more for DOS copy protection schemes), I have not put a high priority on implementing this in ImageDisk itself - I may one day give it the ability to read mixed-sector-sized disks - but it has not been requested and is not a priority at this point. In other words, this is an optional extension to the .IMD file format specification - My tools probably won't implement it any time soon. I added it specifically so that others who needed this capability could support it in a consistant way. As I have just released this update, and as far as I know only one other person is using it so far - it is probably not too late if you have a reason that it should be done differently - please provide feedback. Dave -- dave12 (at) Dave Dunfield dunfield Firmware development services & tools: www.dunfield.com (dot) com Classic computers: http://www.classiccmp.org/dunfield/