Edwin Blink wrote: > what's with the track header length? The overall file has a 14 byte header. After that there must be at sides*tracks track headers (each 7 bytes) following the file header, and following each track header are sector headers (each 7 bytes) for each sector in the track. The actual sector data follows all the track+sector information, with offsets in the headers used to locate it.
> If you can have null tracks and sectors then the smallest > diskimage of a singlesided diskimage that contains 1 directory > entry (0,0) a single file of less then 502 bytes (4,1) could be > 14+2*(7+(1*(7+512)) a little over 1K(1066 bytes) ? The disk would still need to be defined with 5 tracks, with a track header for each, but could be single-sided. Only tracks 0 and 4 would need any sectors, so I think that'd make it: 14 + 5*7 + (2*(7+512)) = 1087 bytes. Of course, attempting to write anything else to the disk would result in errors, as the rest of the disk is unformatted. It'd make more sense to have the disk as 2 sides with 83 tracks, initially either entirely unformatted or with the first 80 tracks pre-formatted in a normal 1 sector skewed format. That would still be bigger than the minimal disk though. > But a full standard diskimage will have a overhead of more > then 12K which makes it less interesting Still what's 12K though? 3 clusters on a typical filesystem? Perhaps even 1 cluster when the file is normally zipped/gzipped? I wonder whether it's actually worth creating a new format to save space, particularly since the only real benefit would be to reduce the data transferred over a serial link. Wouldn't the transfer program itself be better to handle empty-sector optimisations, skipping unused sectors, error checking/correction, compression, etc. as part of the protcol between the PC and SAM? That way you'd transfer a DSK almost as well as anything else, by simply by unpacking and examining the source disk before sending it. > I'm seriously about a new disk format. So any one having > thoughts shout ! I'll certainly go with the flow, but I'm a little worried that we'd be going down the new format route for the wrong reasons. I'm not saying FDI is perfect for the job, but it's an existing supported format it can represent 99% of SAM disks I've seen so far, so it seemed like a fair choice. I'll continue to add support for it, even if we end up going with something else for the SAM archive. Si
