XBIOS 5

[tobe]

Hi,

I'm trying to code a shell to switch to low res, run a software and when it quit return to the desktop res.
quite usefull for degas, sidsound, ...

when i call xbios(5) to switch resolution, it works nice, but the gem seems to work in the old mode.

is there a workaround ? how the desktop switch resolution ?

[Klapauzius]

when i call xbios(5) to switch resolution, it works nice, but the gem seems to work in the old mode.
is there a workaround ? how the desktop switch resolution ?

This is a very tricky thing to do, because once GEM has been initialised it will keep it's internal settings for screen width, maximum mouse positions, etc...

So allthough it's easy to (user)switch res in GEM environment, nothing is likely to work properly afterwards

AFAIK you would have to play around with undocumented GEM variables and those would have different locations with every TOS version ...

Reinitialising (i.e. restarting) AES would probably be the solution, but I don't know if anyone has managed to get this working ok yet...

Cheers

Klaz

[ijor]

As Klaz said this is not an easy task at all. There is no “official” documented way to do it. Well, at least not in older TOS version. Don’t know if TT/Falcon TOS added this functionality. The Xbios call will change the resolution at the hardware and at the lower OS levels, but not at the AES level. Even using and undocumented hack won’t be easy, you would probably break resident desk accessories.

Note that the Desktop does NOT actually change resolution. Instead it triggers a partial reset of the system. And Atari did not document even how to do this, although I think there were some third party articles about this.

[tobe]

Grrrr... Stupid AES, i'm go back to POKE POKE POKE

[tobe]

After 15 years using it, i just noticed that the GFA basic editor, when launched from low res, switch from medium to low res quite easily !

[ijor]

After 15 years using it, i just noticed that the GFA basic editor, when launched from low res, switch from medium to low res quite easily !

Yes, BUT the GFA editor doesn't use the AES. Again, there is no problem in switching resolution. The problem is the AES.

[Maverick[RAM]]

After 15 years using it, i just noticed that the GFA basic editor, when launched from low res, switch from medium to low res quite easily !

Yes, BUT the GFA editor doesn't use the AES. Again, there is no problem in switching resolution. The problem is the AES.

Sorry guys, I am curious, What is AES?

Best Regards

[unseenmenace]

Application Environment Services. Part of GEM, responsible for drawing the windows, menus mouse pointer etc.

[Gunstick]

Hi, I'm digging this up again. So there is nothing documented how GEM/TOS switches resolution when you click in the desktop dialog box to go from low to medium? It just jumps somewhere to restart AES. Now that's odd. 12 years later now: is there still nothing new on this? Do I need to find the jump address for every TOS version out there and hardcode all that?
For my simple demo program, I would like to write a PRG which I can run from GEM, which does the same than clicking in the resolution switch dialog.

[OL]

Hi, I'm digging this up again. So there is nothing documented how GEM/TOS switches resolution when you click in the desktop dialog box to go from low to medium? It just jumps somewhere to restart AES. Now that's odd. 12 years later now: is there still nothing new on this? Do I need to find the jump address for every TOS version out there and hardcode all that?
For my simple demo program, I would like to write a PRG which I can run from GEM, which does the same than clicking in the resolution switch dialog.

Under modern AES you should use shel_write(5,....)

http://toshyp.atari.org/en/008012.html#shel_write

OL

[AtariZoll]

Hi, I'm digging this up again. So there is nothing documented how GEM/TOS switches resolution when you click in the desktop dialog box to go from low to medium? It just jumps somewhere to restart AES. Now that's odd. 12 years later now: is there still nothing new on this? Do I need to find the jump address for every TOS version out there and hardcode all that?
For my simple demo program, I would like to write a PRG which I can run from GEM, which does the same than clicking in the resolution switch dialog.

Restart of AES means rewriting plenty of variables. I don't think that it is possible to solve this with some jump to res. switch point - because it is not subrutine, and will at the end lead to Desktop start.
Actually, you can switch res. in GEM APP, but some things, mouse will not work properly. If can somehow change VDI variables it maybe will work so-so, good enough for your demo.

[ThorstenOtto]

Restart of AES means rewriting plenty of variables. I don't think that it is possible to solve this with some jump to res. switch point - because it is not subrutine, and will at the end lead to Desktop start.

Thats true, there is no subroutine you could call to switch resolution in old TOS versions. When you do that from the dialog in the desktop, the desktop process is *terminated* (including all ACCs), and returns to the AES main loop. Its the AES that actually switches resolution (by closing the physical VDI workstation and opening a new one), then spawns a new desktop.

Actually, you can switch res. in GEM APP, but some things, mouse will not work properly. If can somehow change VDI variables it maybe will work so-so, good enough for your demo.

There would be way too many problems with this. Not only that the variables that you need to patch are internal to AES/VDI (and thus depend on the TOS version), it would also not work with different VDI, the ACCs might still work with the informations they got from opening a virtual workstation, it won't work with EmuTOS etc.

In GFA this only works because the editor itself does not use AES. If i'm not wrong, the unpatched version does not even use VDI, one of the main reasons why it does not work very well on non-standard screen resolutions.

[Mikefulton]

Patient: Doctor, It hurts when I do this!

Doctor: Don't do that!


The solutions discussed here all fit into the general concept of trying to pound a square peg into a round hole. Well, I got news for you... there ain't a hammer big enough to do that.

The closest thing to a real solution to this problem that I can think of would be for the shell to manipulate the DESKTOP.INF file and then generate a reset. The machine boots into the desired resolution, the DESKTOP.INF configuration would launch the shell and do whatever needed to be done in that screen mode, then upon exit it rewrites the DESKTOP.INF and reboots again.

This would work on all flavors of GEM.

[lp]

The old GFA editor initializes the AES at startup and it does use. If you click Load or Save, etc, it calls fsel_input() but you will notice the file selector is shifted to the left. The AES is unaware of the mode change. If you click Quit it calls form_alert(), also shifted to the left. It doesn't do any trickery or custom forms, it just manages to get away with it. If you click the atari logo in the top left corner to access desk accessories, it goes back to the original mode, presents a menu_bar() to allow them to work right. When you exit the menu with "Editor" it goes back to medium resolution. The text rendering however is custom assembler, no VDI involved. Just an explanation of what the GFA editor is doing.

[AdamK]

IIRC, TOS 2.06+ works well with XBIOS 5.

[AtariZoll]

Just another thread when person who asked some thing disappears. I mean, more details about concrete SW idea would make much easier to figure out how it can be solved in best way. Actually, we have no clue why it must be AES program - he said that want to run it from GEM ...

[Gunstick]

Hi,

thread hijacker here.

I don't want to put round things into square holes.
I would like to do exactly what GEM does. i.e. close the VDI workstation and ask AES to make a new one, including loading ACC etc. The whole gimicky thingy.
I don't want to keep my running programs and just change resolution like one does on modern OS. That's not the aim.

The final aim is to support a future coming monitor adapter. And that there should be a programmatic way to change from lo/mid/high to any other resolution and it works as expected: GEM restarts into the new resolution.

So for the moment I want to rewrite the lo/mid switching code to be able to do the exact same thing what the dialog does.
When that works, I will attack the special case of high rez.

[troed]

Gunstick is working on the nice version.

I've been working on the hack-it-til-you-make-it version.

I'll just leave this here:

[distantminds]

oooooooh!!

[Gunstick]

Gunstick is working on the nice version.

Shortly after that, I scrapped the project. TOS has no hooks or anything to make it easy to have a medium-high toggle as easy as you have a medium-low toggle. It a big mess and each TOS version has the important parts on other adresses, so it would be dirty to implement.