Re: [hatari-devel] Problem with changes in drive ID handling

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On sunnuntai 05 lokakuu 2014, Uwe Seimet wrote:
> > > Up to now my drives C:-I: were mapped to folders in the file system,
> > > and the partitions of the IDE master and slave images started with
> > > drive J:. This mapping does not work anymore.
> > 
> > That's how it already worked for ACSI, I just made IDE behave the same.
> 
> That's strange because with an ACSI hard disk image, TOS 3.06, and Hatari
> 1.8.0 my GEMDOS drives are mapped to C:-I: even though my image has two
> partitions. Shouldn't this have been different already for ACSI?

Code for skipping of partitions counted by ACSI code has been there
at least 5 years, I just extended it.  However, earlier that counting
supported only (specific) Atari style primary partition table.  If your
ACSI images have some other kind of partition table, Hatari's internal
ACSI partition count might have been wrong (zero).  I've now added
initial support also for DOS MBR / partition table, which could've
changed the situation for you.

The partition count was & so far is used only for GEMDOS HD emulation
drive skipping.


> > > Is there any way to configure the
> > > old behavior, so that GEMDOS drives are assigned first?
> > 
> > Not with current code.  I think having GEMDOS drive after the other
> > drives is more compatible, so it should be default.
>
> Which incompatibilities does it address?

Atari HD driver not skipping drives already set in drive bitmap.


> Is this really more compatible?

That's my assumption, but I naturally would be interested
about facts on how different HD drivers and their versions
handle this.


NOTE: The main use-case for having both images and GEMDOS emulation
is copying files between the two.  The point of skipping is that user
doesn't need to specify drive for GEMDOS HD when he uses ACSI or IDE
images, Hatari makes sure that GEMDOS HD is mapped to a free drive
which is not overridden by Atari HD driver.

(There are user complaints about this which I was trying to address
with this change.)


> I find the new behavior rather inconvenient, because now the available
> GEMDOS drive IDs depend on the number of partitions found on the drive
> images. If there are two drive images with a different of partitions, the
> ID of the first GEMDOS drive changes depending on the drive image I use.
> Or if I use sometimes one and sometimes two drive images I can now not
> rely on fixed drive IDs for my GEMDOS drives anymore, because some of
> them are ignored.

In multidir GEMDOS HD emulation setup, drives which overlap with image
partitions, are ignored (I didn't change that), but you could map them
to high enough drive letter(s) that all ACSI/IDE drives would always
get mapped before them.

However, I noticed that at older TOS versions don't handle "holes"
in drive bitmap very well...


> If somebody uses software that remembers the path of a
> GEMDOS drive (a lot of appliations do) this can even become dangerous,
> because the information about saved paths is not reliable anymore but
> depends on the drive images.

Only if one changes his HD setup.  Same problem happens also on real Atari,
doesn't it? :-)


> By the way, how do you handle DOS-compatible partitions, TOS/Windows-
> compatible partitions,

How these differ?

> and byteswapped partitions? Usually the hard disk
> drivers know how to handle this, and especially for TOS/Windows-
> compatibility there are different approaches.

While some of that is currently missing, I don't expect support for
that to be too much code.

Btw. Extended partitions seems to have many different formats, and
they're IMHO rare enough use-case that I don't think it worth taking
into account for this feature.  But they were the main reason why
I was considering command line option for specifying GEMDOS drive.
:-)


> > Is there some specific use-case for mapping GEMDOS drive first?
> 
> Yes, plenty, at least in my case ;-). My AUTO folder is on GEMDOS drive
> C:. Now, as soon as I use a drive image, I am forced to boot the AUTO
> folder from this image because some of my GEMDOS partitions are not
> mapped anymore:

Having AUTO/-programs on C: GEMDOS drive is quite compelling use-case.


> Mounting IDE hard drive image /home/us/hatari/master.img
> Mounting IDE hard drive image /home/us/hatari/slave.img
> Drive Letter C is already mapped to HDD image (cannot map GEMDOS drive to
> /home/us/TT/C). Drive Letter D is already mapped to HDD image (cannot
> map GEMDOS drive to /home/us/TT/D). Drive Letter E is already mapped to
> HDD image (cannot map GEMDOS drive to /home/us/TT/E). Drive Letter F is
> already mapped to HDD image (cannot map GEMDOS drive to /home/us/TT/F).
> GEMDOS HDD emulation, G: <-> /home/us/TT/G.
> GEMDOS HDD emulation, H: <-> /home/us/TT/H.
> GEMDOS HDD emulation, I: <-> /home/us/TT/I.

What's the use-case for having this many GEMDOS HD partitions?


> So effectively I lose access to my GEMDOS drives C:-F:, and when I only
> use one IDE image the situation is different again. Up to know I could
> rely on the GEMDOS drives always being there, now some of them are
> missing.
> 
> > Alternatives for implementing this could be:
> > - not skipping IDE/ACSI partitions when using GEMDOS
> >   multipartition setup
> > 
> > - commandline/config option to set (first) GEMDOS
> >   emulation drive.
> 
> There may be alternatives, but I wonder if compared to how it was before
> things are probably becoming much less transparent. Even with an option
> that sets the first GEMDOS drive one does not get a reliable drive order
> because everything depends on the number of drive images and the number
> of partitions on them. Just re-partitioning an image results in
> unexpected changes.
> 
> All in all you have probably noticed that I think the new behavior is
> highly problematic ;-).

If it indeed is more problematic, it's not enough to revert it,
the old ASCI partition counting & skipping code would need to
be removed too.


> By the way, when changing my image drive settings (removing the IDE
> images) in the UI the Hatari development version crashes.

I'll look into that, but could you provide exact steps?


	- Eero