Re: [hatari-devel] Handling of _drvbits

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi,

On 6.7.2025 23.54, Uwe Seimet wrote:
I assume what I am asking for cannot be changed, but I thought I would at
least ask: Is it possible that Hatari sets the bits for the GEMDOS drives in
_drvbits earlier, before TOS bootstraps the hard disk driver?

Hatari GEMDOS HD drive bits are ORed to _drvbits initially in STMemory_SetDefaultConfig() along with Hatari memory config values etc, so it should be before that.

And second time they're ORed to it in OpCode_SysInit() "called at system init by the cartridge routine (after gemdos init, before booting floppies)", in case TOS just overrides value set by Hatari.


Usually I launch HDDRIVER.PRG from a GEMDOS drive. I have HDDRIVER's
"Preserve existing drive IDs" option enabled, so that the IDs assigned by
the driver do not replace the GEMDOS drive IDs. This is convenient because
regardless of the drive images present the GEMDOS drive ID assignments are
always the same.

When I boot HDDRIVER.SYS from a drive image, this option does not work, i.e.
HDDRIVER assigns IDs starting with C:, so that the GEMDOS drives are replaced.
I guess this is because at boot time _drvbits is still empty. Can you confirm
this, and can this be changed?

I think your TOS overwrites those value (see above).

Which TOS version you're using? I would expect EmuTOS to respect Hatari settings (if not, you can mail emutos-devel)...


	- Eero




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/