I'm setting up Hatari 2 - STE, mono mode, an ICD-formatted drive image (5 partitions, booting from C, booted with ICDBOOT.SYS) and one GEMDOS drive, TOS 2.0.6. It's pretty much working great, so far.
However, when the emulated ST boots, the desktop is not reading the saved newdesk.inf file, so always comes up in the default config. When I manually select "Read INF File" and choose the newdesk.inf file in the root of C, the desktop is restored properly with all drive icons etc, so the file itself is ok.
Having read around, I read some comments about Hatari using it's own version of newdesk.inf, or something, but couldn't really find what's going on. Any clues as to how I can get the desktop restored to the saved state on booting up?
To find out what actually happens, you can use Hatari's "--trace os_base" option (or more verbosely "--conout 2 --trace gemdos"). Attach the output of that and I'll tell what happens.
Ok, I see, thanks for the explanation.Eero Tamminen wrote:If you use autostartup, Hatari generates the INF file from scratch that tells TOS to start the given program. In the Mercurial version of Hatari it will modify the existing INF file instead.
So, I'm seeing:Eero Tamminen wrote:To find out what actually happens, you can use Hatari's "--trace os_base" option (or more verbosely "--conout 2 --trace gemdos"). Attach the output of that and I'll tell what happens.
Code: Select all
"Resulting INF file TOS resolution: 0x03 -> 0x13. Virtual 'NEWDESK.INF' TOS resolution override file created."
Code: Select all
GEMDOS 0x3D Fopen("NEWDESK.INF", read-only) at PC=0xFA002A Virtual INF file 'NEWDESK.INF' matched. -> FD 64 (read-only -> read-only) GEMDOS 0x3F Fread(64, 4192, 0x7d12e) at PC 0xFA002A GEMDOS 0x3E Fclose(64) at PC 0xFA002A Virtual INF file removed.
I'm wondering if this is related to the extended GEM VDI resolution (which is enabled here). This has to be enabled for me, not just to give me a bigger desktop, but because if it's disabled, just running with the regular ST high resolution mode, the desktop never appears on boot - ie, I only get to the GEM desktop when the extended VDI mode is checked, at least with TOS 2.06 and 1.62 (however EmuOS is Ok on normal resolutions, and does get to the desktop.)
Edit: Ok, this was indeed the case. I've managed to get Hatari to boot to the desktop in non-extended VDI mode (I don't know how, it jut started working, whereas everytime I'd tried previously, it would hang before getting to the desktop), and in this case, the desktop *does* read the newdesk.inf file and correctly restores the desktop on boot.
So it is indeed the extended VDI resolutions that are completely overriding the newdesk.inf file (behaviour that seems less than ideal really, as you can no longer restore the saved desktop at startup - modifying the existing file (if it's there) sounds like a better solution).
Thanks for the pointer to help me figure out what was going on...
Here's the full output: [no longer necessary, removed]
However, the virtual INF file content can be based on your own version only if it's in place where Hatari can access it directly. Unless you boot from GEMDOS HD driver, Hatari cannot do that, and it needs to use builtin INF file content instead.
Does Hatari tell it's modifying existing INF file, or using a builtin one?
Ok. Yes, I'm using one of the latest versions of Hatari with OSX MIDI support and fixes.Eero Tamminen wrote:Ok, you're using the Mercurial version instead of Hatari 2.0 release. In Mercurial version, both VDI mode and Autostarting use virtual INF file overriding, and it works even if you're booting from somewhere else than GEMDOS HD.
For my needs, I'm not booting from the GEMDOS driver, I'm booting from an ACSI image (with ICD Pro driver) - I'm doing this as I'm recreating my old hard drive setup which uses Magic2 (I read this doesn't work very well with a GEMDOS drive setup, which is why I chose to do it this way.)Eero Tamminen wrote:However, the virtual INF file content can be based on your own version only if it's in place where Hatari can access it directly. Unless you boot from GEMDOS HD driver, Hatari cannot do that, and it needs to use builtin INF file content instead.
I haven't seen anything in the console output from memory that tells me that, but the behaviour I see suggests that it's using the builtin one, because if it was modifying an existing one, my drive icons etc from my own newdesk.inf would presumably be restored. And as I'm booting from an ACSI image, then from what you say, Hatari cannot access the file anyway.Eero Tamminen wrote:Does Hatari tell it's modifying existing INF file, or using a builtin one?
But this is all good to know - in the case of this image, it's not so much a problem anymore as I'm now booting into Magic2 and auto-running Gemini, so the TOS desktop issue doesn't matter. But at least I now understand what's going on!
For other drive setups, I use GEMDOS drives, and I've just tested that this works ok - the existing newdesk.inf *is* restored correctly with a GEMDOS setup - so I will set it up in this way for these instances.