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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On maanantai 06 lokakuu 2014, Uwe Seimet wrote:
> > 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.

Is there any documentation on the primary partition table
with 8 partitions?


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

Last HDDRIVER version I tested (I think it was demo version),
didn't have skipping enabled by default.


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

Ok, I guess I need to add config option for that.


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

I'm not completely sure which version of TOS had this issue.
Maybe v1.04?


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

OK.


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

OK.


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

I guess the new config option needs to default to assigning
GEMDOS HD to C:...


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

Thanks!  I haven't had yet time to look into this.


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

Does this happen both with ACSI & IDE or just one of them?

Are you sure this was because of my change and not some other change?
I don't think I changed anything that would affect the actual disk
accesses...


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


	- Eero