Modified TOS to remove resolutions limitation

[Smonson]

I can only assume if you set up a software register, that tos is checking for that as a physical register, as in hardware, not software ?

I just had it tied in so that when you select "high" in the desktop preferences, it immediately executes the same code. Working with assembler's a bit fiddly, I probably made some kind of mistake in there.

[exxos]

I just had it tied in so that when you select "high" in the desktop preferences, it immediately executes the same code. Working with assembler's a bit fiddly, I probably made some kind of mistake in there.

Yeah I know what you mean with asm... Though running the same code might not work because the actual physical signal would just run again immediately afterwards unless you held it in software in a fixed state ?

[Cyprian]

Since TOS does all the work anyway when it detects the mono pin, might you recode that routine so instead of TOS checking the mono pin, it checks the selection in the desktop menu ?

nice and simple idea

I tried it, but I always see a bus error (2 bombs) and an infinite reset loop if I set it up that way. I don't know why.

the Desktop works in User mode, in order to read/write OS variables or hardware registers you have to swith to SuperVisor mode.

[thorsten.otto]

the Desktop works in User mode, in order to read/write OS variables or hardware registers you have to swith to SuperVisor mode.

No, it doesn't. In TOS, it is in Supervisor-mode all the time.

[Cyprian]

the Desktop works in User mode, in order to read/write OS variables or hardware registers you have to swith to SuperVisor mode.

No, it doesn't. In TOS, it is in Supervisor-mode all the time.

You're right. I've just checked under emulator and actually the Destkop 1.62 works in SuperVisor mode. I was sure it doesn't

[Smonson]

No solution yet but after adding a bit of logging, I can see two anomalies in how TOS is calling FindDevice at bootup.

First, here are the values of the current resolution and new resolution (in the variable "intin[0]") at the time FindDevice is called when it's called after switching resolution. These seem fine:

When switching from...	existing res from GetRez()	new res from intin[0] variable
Low to medium	0	3
Low to high *	0	4
Medium to low	1	2
Medium to high *	1	4
High to low *	2	2
High to medium *	2	3

(* = not available with unmodified TOS 1.4)

FindDevice is also called once at boot (presumably during the initialisation of VDI?) , with the following values:

When booting up in...	existing res from GetRez()	new res from intin[0] variable	return value from unmodified FindDevice()
Low resolution	0	4	1
Medium resolution	0	3	2
High resolution	2	2	3

That 4 in the table causes the problem. When booting in low res, it asks to switch to high res, but if FindDevice allows it, the machine reboots. Therefore, I am working on finding the reason why it asks for that in the first place so I can change it to a 2. During high-res bootup it asks for low res (2) as well, but returning 1 there doesn't appear to be a problem. It kinda looks like the 2 and 4 have been accidentally switched, but nobody noticed because it made no difference :shrug:

Investigations continue!

[tzok]

low = 0 (0x0000)
med = 1 (0x0001)
hi = 2 (0x0010)

req low = 2 (0x0010)
req med = 3 (0x0011)
req hi = 4 (0x0100)

...requests would have much more sense if they were 3, 4, and 5 :/

The resolution switching/saving was all screwed up upon various TOS versions, so I wouldn't be surprised, if they mixed up these requests on boot up.

[Smonson]

...requests would have much more sense if they were 3, 4, and 5 :/

It really is all over the place isn't it... In addition to the above two schemes there's also the return values from FindDevice() which are 1=low, 2=med, and 3=high. A dog's breakfast.

[thorsten.otto]

It's even worse: in TOS 3.06, the return code from FindDevice() is again the value you would get from Getrez(). In 4.04, it is a pointer to a structure that describes the device.

nice and simple idea

No, that's a bad idea. First off, the check is done by the BIOS, and that should not mess with the desktop. Secondly, the item in the desktop dialog will only be selected if you opened it at least once; that's way too late, since the detection is activated quite early during boot. And last but not least: nobody guarantees that the builtin desktop is actually run at all. You may be booting into command.prg, or into some cartridge application, or have set up a different desktop in desktop.inf.

[Smonson]

Nothing tangible to show for it yet, but I have at least identified the reason for the weird values in the table above.

The resolution requested on boot is just the saved res from DESKTOP.INF. I'm not exactly sure why, but the crash I was seeing just... went away on its own. Probably an error in my debug build that got resolved when I rebased the branch back to the tos-identical build. Anyway, that's good.

In my debug build I can switch arbitrarily between the resolutions and they don't crash in Hatari. In colour, if I go to high-res I just see a white 71Hz screen, I think Hatari just can't display it. In mono, if I switch to low or high it reconfigures the desktop OK (or looks like it does - similar to the original animated GIF). Problem is that the shifter's mode isn't currently being changed properly.

In Steem, it crashes constantly and my debug code paths aren't being executed at all. I suspect that Steem doesn't actually emulate TOS completely, but fakes it. One good thing is that if I switch from how to high, I see a working TOS desktop as it would look if a mono screen was displayed in 4-planar mode 0. So that's promising, although the emulated machine still thinks it's in mode 0. Not sure yet if a real machine would also do that.

I haven't made a lot of changes since last post, but I spent a bunch of time documenting the call tree and who changes what, and disassembling the involved functions.

• gem_entry()
• gem_main()
• gsx_init()
• gsx_wsopen()
• av_opnwk()
• vdi_call()
• gsx_acode()
• gsx2()
• trap2_handler()
• gsx_entry()
• screen()
• v_opnwk()
• FindDevice()

Progress continues.