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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

> 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.

I was using a standard partition table. Anyway, what happens if the
primary partition table has 8 partitions? This is a format created by
old versions of the ICD and CBHD software, and it is also supported (but
not created) by HDDRIVER. So which partitions are actually available
depends on the hard disk driver being used. I don't think that Hatari
can cover situations like this because Hatari has to make the decision
before the hard disk driver is loaded.

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

As far as HDDRIVER is concerned whether existing IDs shall be skipped or
not is configurable.

> 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.

Well, that's a shortcoming of AHDI, but I don't think this is a behavior
that should be hard-coded. It should be configurable, as it can be a
problem (or actually not necessary) with other hard disk drivers.

> > 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...

Can you please elaborate? I don't remember any TOS versions that had
problems with this.

> > 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? :-)

This only happens if you add a device with a device ID (ACSI, SCSI, IDE)
*lower than* the existing IDs. In practice you don't do this, but for
additional devices they use higher IDs, as this avoids all these
problems. Hatari now does more or less the opposite.
Actually, in order to avoid problems like this with removable media
drives Atari ensured that AHDI always uses a fixed minimum number of drive
IDs on these media. The default setting is 4, but this is configurable, even
with AHDI. So regardless of how many partitions your removable media
drive (or memory card) may have, AHDI and all AHDI compatible drivers
can be configured to ensure that drive IDs are not shifted somehow when
the number of partitions on a cartridge (or memory card) changes due to
a media change.

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

As far as I know they in particular differ with Pera Putnik's driver,
but it's better to ask him about it.

> > 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.

And in case there should ever be a change in the handling of these
partitions you will change the code again?

> > 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?

I'm afraid I don't understand the question. I've always had this many
GEMDOS partitions. When I started using Hatari I just created a GEMDOS
drive for all of the partitions I had on my TT (and also Falcon) hard
disk drive at that time. Now I regularly synchronize these partitions
with my real Ataris. I just copy them to a memory card and then transfer
them to my Ataris or vice-versa.
On some of these partitions there are data (my C and assembler sources)
managed by git or svn, by the way. I would not be able to do this with
images, but I need GEMDOS drives for this. Since .git and .svn folders
are ignored by Hatari I can have my Atari data managed by these VCS
without interfering with TOS in any way. That's very convenient.

> 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.

Well, at least for me it does not seem to work anyway. Fortunately it
doesn't, otherwise I would not have been able to use Hatari the way I
did until now.

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

I just ejected my two IDE images, added an ACSI image and then rebooted.

By the way, before your change I noticed that when changing settings in
HDDRUTIL, HDDRUTIL now reports that the write operation failed. This
worked fine with Hatari 1.8.0 and earlier. You should be able to
reproduce this. (You can either use the HDDRUTIL you already have or
just upgrade to HDDRIVER 9 on http://hddriver.seimet.de/en/prices.html.)

Take care

Uwe