TOS 2.0.6 not reading NEWDESK.INF on boot [solved]

A forum about the Hatari ST/STE emulator - the current version is v2.0.0

Moderators: simonsunnyboy, thothy, Moderator Team

User avatar
cb170
Atariator
Atariator
Posts: 23
Joined: Wed Oct 11, 2017 11:04 pm

TOS 2.0.6 not reading NEWDESK.INF on boot [solved]

Postby cb170 » Fri Oct 13, 2017 1:44 pm

Hey guys,

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

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?

Thanks...
Last edited by cb170 on Mon Oct 16, 2017 10:18 am, edited 2 times in total.

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1560
Joined: Sun Jul 31, 2011 1:11 pm

Re: TOS 2.0.6 not reading NEWDSK.INF on boot

Postby Eero Tamminen » Sat Oct 14, 2017 9:48 pm

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.

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.

User avatar
cb170
Atariator
Atariator
Posts: 23
Joined: Wed Oct 11, 2017 11:04 pm

Re: TOS 2.0.6 not reading NEWDSK.INF on boot

Postby cb170 » Sun Oct 15, 2017 12:44 am

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.


Ok, I see, thanks for the explanation.

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.


So, I'm seeing:

Code: Select all

"Resulting INF file TOS resolution: 0x03 -> 0x13.
Virtual 'NEWDESK.INF' TOS resolution override file created."


And further down:

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.


So the built in newdesk.inf is indeed being overridden by Hatari.

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

Here's the full output: [no longer necessary, removed]

User avatar
Eero Tamminen
Atari God
Atari God
Posts: 1560
Joined: Sun Jul 31, 2011 1:11 pm

Re: TOS 2.0.6 not reading NEWDESK.INF on boot

Postby Eero Tamminen » Sun Oct 15, 2017 10:34 pm

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.

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?

User avatar
cb170
Atariator
Atariator
Posts: 23
Joined: Wed Oct 11, 2017 11:04 pm

Re: TOS 2.0.6 not reading NEWDESK.INF on boot

Postby cb170 » Sun Oct 15, 2017 11:28 pm

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.


Ok. Yes, I'm using one of the latest versions of Hatari with OSX MIDI support and fixes.

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.


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:Does Hatari tell it's modifying existing INF file, or using a builtin one?


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.

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.

Thanks! :thumbs:


Social Media

     

Return to “Hatari”

Who is online

Users browsing this forum: No registered users and 1 guest