Hello, * On Mon, Jan 27, 2014 at 02:49:14PM -0500 Ethan Dicks wrote: > On Mon, Jan 27, 2014 at 2:42 PM, Spiro Trikaliotis > <ml-cbmhackers@trikaliotis.net> wrote: [...] > > 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. Indeed. Anyway, while people recognise d64 and d71, as these are rather common, chances are that people will not recognise a .d96 or .d99, as these will be used very seldom. Thus, giving a hint on what this is by giving the number of the device might give a clue. > 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, A 1541/4040 image is a .d64, a 1581 image is a .d81, a 1571 image is a .d71, and so on. It is just a binary dump of the disk contents; there is no additional metadata to tell the system what is actually in the file with that extension. Thus, by renaming a .d71 to .d64, you can generate a single-sided version of your disk. (Although, btw, some tools will report problems, as they test the length of the file to match the extension). > or is it worth evaluating a different way to > handle the dozen-or-so filesystem variations that are likely to crop > up? I think a good metadata specification might help here, yes. Now, I wait for the first person to mention XML... ;) Regards, Spiro. -- Spiro R. Trikaliotis http://www.trikaliotis.net/ Message was sent through the cbm-hackers mailing listReceived on 2014-01-27 21:00:03
Archive generated by hypermail 2.2.0.