On Mon, Jan 27, 2014 at 2:42 PM, Spiro Trikaliotis <ml-cbmhackers@trikaliotis.net> wrote: > Hello, > > * On Mon, Jan 27, 2014 at 07:21:49AM -0500 Steve Gray wrote: >> Perhaps D96 and D99 ;-) > > Why not something like *sigh* .d9060 and .d9090? I mean, how many people > will want to handle such things on a DOS machine, anyway? It's not like 3-letter extensions are mandatory, but folks are accustomed to them. That said, as was pointed out, the only real difference is the number of sectors per track (because of 4 heads vs 6 heads). The fact that it's a DOS 3.0 filesystem (with differences in BAM location, starting track number, etc) is the part that is different from DOS 2.6, etc, so one _should_ make it easy to tell those apart. There are a _few_ examples of people that have hacked the D90x0 ROMs to support drive geometries other than the TM602S and TM603S, but the internal track and sector pointers would be consistent, so _reading_ one of those shouldn't cause well-behaved utilities any problems, but I can imagine that to allocate new tracks, format "blank" files, etc, those utilities would have to permit the user to override the default geometry. At the very least, those utilities would have to know how to handle a 5MB image file vs a 7.5MB image file, by length, by extension, or by command-line parameters. I would say that if today's tools can handle a 2040 image vs a 1541/4040 image vs a 1581 image, then there's a way to extend that mechanism to the D9060 and D9090. That said, how is it done now and are people happy with it, or is it worth evaluating a different way to handle the dozen-or-so filesystem variations that are likely to crop up? -ethan Message was sent through the cbm-hackers mailing listReceived on 2014-01-27 20:05:50
Archive generated by hypermail 2.2.0.