On 7 Mar 2012 at 14:53, Dave McGuire wrote: Please do give me feedback on how this works and any particular glitches or gotchas that you encounter. This is the first time I've posted the ImageDisk one, but I've been using variations of this disk internally for a while (I've made a CD with about a dozen really useful bootable floppy images to pick from when it boots). Dave -- dave12 (at) Dave Dunfield dunfield Firmware development services & tools: www.dunfield.com (dot) com Classic computers: http://www.classiccmp.org/dunfield/

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/

On Thu, Mar 8, 2012 at 12:57 PM, Dave Dunfield <dave12 at dunfield.com> wrote: Ah yes, that does seem a better idea :) Not directly, but the size code in the format command determines the physical size written on the track for each sector, independent of the size values in the ID data. So you can create a format template from smaller sector sizes to position the sector headers, then write to the data fields of the real sectors to complete the track. In cases where the header size is larger than the template sector size, the extra headers will be overwritten by the data fields. The only control you have is the format size and gap3 value, but it's enough to achieve the mixed sector size combinations I've seen so far. One popular format is 5x1024 + 1x512, to squeeze a bit more on to a 250Kbps MFM track. For that you could use a template of 17x256 with gap3 around 48. Each 1K sector spans 3x256 sectors, plus the accumulated gaps, with the final sector spanning two. The ID header values for the dummy sectors aren't important, as long as they don't match one of the real sectors. Calculating the unit and gap sizes to use for a general case is a bit more work than normal, but I'd imagine you could have a fixed list for known formats (as is done for some gap values). In other words, this is an optional extension to the .IMD file That's good enough for me to include it -- thanks!