Re: D9090 back to life !

From: Ethan Dicks <>
Date: Mon, 27 Jan 2014 14:49:14 -0500
Message-ID: <>
On Mon, Jan 27, 2014 at 2:42 PM, Spiro Trikaliotis
<> 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


       Message was sent through the cbm-hackers mailing list
Received on 2014-01-27 20:05:50

Archive generated by hypermail 2.2.0.