Re: D9090 back to life !

From: Spiro Trikaliotis <ml-cbmhackers_at_trikaliotis.net>
Date: Mon, 27 Jan 2014 21:21:42 +0100
Message-ID: <20140127202142.GI26812@hermes.local.trikaliotis.net>
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 list
Received on 2014-01-27 21:00:03

Archive generated by hypermail 2.2.0.