hddriver 11.12, HATARI and the GEMODS drive

[1ST1]

Hello, I am currently trying to make an exact virtual copy of my original ST using HATARI. The original has harddisk partitions from C: to J:, so in total 8. So I created an empty image of 3 GB, partitioned that with HDDRIVER in the same sizes like the original and started to transfer my files in there through the HATARI GEMDOS drive function to access a host directory.

The problem is, that this GEMDOS drive is set to G: instead of K: I can see the G: drive inside the disk image when using standard (fast) mode for G: in Kobold, and if I switch Kobold to GEMDOS mode for G: I see the HATARI GEMDOS drive.

HATRI confiig:

current version of Hatari
HDDRIVER 11.12
TOS 2.06
Standard ST type of computer (68000, 4 Meg, monochrome resolution)

I would expect that HATARI makes the GEMDOS drive visible behind the last logic partition, but instead it is placed after the fourth logical partition managed by HDDRIVER. I am not sure if this is HDDRIVER problem or HATARI problem, but in the english ATARI forum they can not reproduce the issue using different harddisk driver or using EmuTOS (with integrated driver) instead. See more details here, with screenshots: https://www.atari-forum.com/viewtopic.php?t=42300

Note, that initially I tryed to set up that virtual ST to use C to J all like HATARI GEMDOS drive as this config is more easy to do than creating real virtual harddisk, but that failed by other problems (as they are only GEMDOS drives), see in the beginning of that thread, later I moved the C..J drive folder to a subfolder to use them just to restore all files from the GEMDOS drive to the virtual disk. So the here related problem only appears later in the thread.

[uweseimet]

When HDDRIVER is booted from a drive image it sets the respective _drvbits bits for all drive IDs it allocates. Hatari (when using the option to add GEMDOS drives after ACSI/SCSI/IDE partitions) should use _drvbits in order to decide which drive IDs are already in use. (This is what HDDRIVER does if you turn on HDDRIVER's option to preserve existing partitions.)
I just tested this and it looks to me as if the Hatari option does not have any effect. Hatari always replaces the partitions managed by HDDRIVER by GEMDOS drives. The same happens when you use AHDI instead of HDDRIVER: AHDI detects its boot drive, but drive C: is not a partition managed by AHDI but a GEMDOS drive. The partition AHDI was booted from is gone (replaced by GEMDOS drive C:).

All in all, this looks like a bug in Hatari to me, not just affecting systems with HDDRIVER but also others. I suggest that you verify my result in your environment by installing AHDI.

[uweseimet]

Thinking more about this, it may not be a bug at all, at least not in my case: My GEMDOS drives are sub-folders C, D, E etc. If I tell Hatari that I want these folders to be C, D, E this is just what Hatari does, and this may explain why the Hatari option has no effect. I don't know, though, in which scenario this option would have any effect at all. Maybe it only works when there is exactly one GEMDOS drive and not several in a folder.

[1ST1]

I have moved the drive folder in a subfolder, like ....\gemdosroot\platte\c, .....\gemdosroot\platte\d and so on and pointed HATARI to gemdosroot. So it shows folder "platte" on G:, and the drive folders c, d, e, f... are inside that folder platte. So this is like expected, but not expected is that it's on G:

As you told, looks like HATARI does not look correctly for _drvbits. But how can it do? Can it look inside of the running TOS environement to read such system variables/cookies?

I would already be happy if I could set the GEMDOS drive by default to Z:, that would be enough.

[uweseimet]

As I already said in my second posting, what I found is probably just expected behavior. I don't know how and when Hatari checks system variables. As HDDRIVER makes use of _drvbits just like AHDI does when creating drive IDs for the partitions it finds, I expect that there is no dependency on the hard disk driver.