Hatari 2.1.0 has been released

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

Moderators: simonsunnyboy, thothy, Moderator Team

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

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Sat Nov 24, 2018 12:22 am

Faucon2001 wrote:Emulated system : STE 4MB TOS 1.62, ACSI HDD image and host filesystem
1 - boot this setup in extended VDI mode @ 1280x960 mono. Boot is ok, screen is ok, no issue
2 - From Hatari config menu, load a new configuration without VDI extended mode. Ex: STE low res RGB and reset the emulator
The old screen is not wiped out properly (See picture)


I'm still not able to reproduce this, either with Mercurial tip WinUAE build, or Hatari v2.1 OldUAE build. Whenever config change includes disabling VDI, emulation will be rebooted, and because STE non-VDI screen is different size than the VDI one, SDL framebuffer & window are re-created at the new size.

Could you send both of your config files so that I try with exactly same config as what you have? Maybe there's some option that we're overlooking...

Faucon2001
Atari Super Hero
Atari Super Hero
Posts: 747
Joined: Sat Oct 26, 2013 11:19 pm
Location: Brasil
Contact:

Re: Hatari 2.1.0 has been released

Postby Faucon2001 » Tue Nov 27, 2018 8:07 pm

Philippe

Firebee, Falcon, STE, Aranym Box, Hatari Pi Box.
My music http://www.philippeworld.net/
My photography http://phil-67.deviantart.com/
EasyAraMint, BeeKey and BeePi https://sites.google.com/site/beebox68k/

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

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Tue Nov 27, 2018 10:30 pm

Faucon2001 wrote:Here are my config files : http://www.philippeworld.net/ftp/Install/hatari-cfg.zip


Sorry, I still can't reproduce your problem (either with SDL v1.2.15 or SDL v2.0.5).

Which desktop / window manager / compositor do you use?

I'm myself using XFCE / Xfwm. Do you by any chance happen to use Gnome / Mutter? And if yes, could you try something else?

(Programs which get their window size at startup and don't allow their resizing afterwards, get wrong window sizes in fullscreen because Mutter first resizes them to non-fullscreen size, and too late to correct fullscreen size. This happens semi-randomly because it's timing dependent. I filed a bug about that last year to upstream & Ubuntu because I saw it in few 3D benchmarks, but that issue has been in Gnome / Mutter for years.)

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

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Tue Nov 27, 2018 11:14 pm

ThorstenOtto wrote:
Eero Tamminen wrote:
I didn't find good documentation about Falcon screen mode setup in NEWDESK.INF file, so only ST/TT resolutions are currently supported by --tos-res.


It's encoded in the 5th and 6th value of the #E line, in the same way you would pass it to VsetMode. Problem here is that those values don't even exist if the file was written by TOS < 4.x, and apparently the desktop has a bug parsing it, sometimes resulting in a call to VsetScreen with a mode argument of 0x2000.


Is the 8th bit (for interlace/double line mode) for the VsetMode mode word in 5th or 6th value:
http://toshyp.atari.org/en/Screen_funct ... l#Vsetmode

And is the 2nd value used for resolution setting with older TOS versions completely ignored, or does that need to be set e.g. in ST compatibility mode?

ThorstenOtto
Atari Super Hero
Atari Super Hero
Posts: 543
Joined: Sun Aug 03, 2014 5:54 pm

Re: Hatari 2.1.0 has been released

Postby ThorstenOtto » Wed Nov 28, 2018 5:53 am

Eero Tamminen wrote:Is the 8th bit (for interlace/double line mode) for the VsetMode mode word in 5th or 6th value:


It is in the 5th value. The parser just does a mode = (value[5] << 8 ) + value[6], then uses that as an argument to VsetScreen/VsetMode.

And is the 2nd value used for resolution setting with older TOS versions completely ignored, or does that need to be set e.g. in ST compatibility mode?


The above is only done when _VDO cookie == 0x30000, otherwise the 2nd value is used as before.

Faucon2001
Atari Super Hero
Atari Super Hero
Posts: 747
Joined: Sat Oct 26, 2013 11:19 pm
Location: Brasil
Contact:

Re: Hatari 2.1.0 has been released

Postby Faucon2001 » Thu Nov 29, 2018 8:18 pm

I use openbox without any desktop. It’s a minimal install and Hatari is started from the autostart script via startx.
This issue happens also when you change resolution in Falcon mode with Videl inside. If the new resolution is smaller or has a different aspect ratio, borders are not redrawn or filled with garbage. It’s not a major issue as I only do these resolution changes during setup stage, but it’s not nice. When Hatari is booted with the new resolution, the screen is ok, so it may be as suggested an issue with my window manager in full screen. Surprisingly Aranym doesn’t show this behavior.
Philippe

Firebee, Falcon, STE, Aranym Box, Hatari Pi Box.
My music http://www.philippeworld.net/
My photography http://phil-67.deviantart.com/
EasyAraMint, BeeKey and BeePi https://sites.google.com/site/beebox68k/

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

Re: Hatari 2.1.0 has been released

Postby Eero Tamminen » Thu Nov 29, 2018 10:16 pm

Faucon2001 wrote:I use openbox without any desktop. It’s a minimal install and Hatari is started from the autostart script via startx.
This issue happens also when you change resolution in Falcon mode with Videl inside. If the new resolution is smaller or has a different aspect ratio, borders are not redrawn or filled with garbage. It’s not a major issue as I only do these resolution changes during setup stage, but it’s not nice. When Hatari is booted with the new resolution, the screen is ok, so it may be as suggested an issue with my window manager in full screen. Surprisingly Aranym doesn’t show this behavior.


Because you have "keep desktop resolution" option enabled, resulting fullscreen SDL window should always cover the whole screen. With SDL2, its own autoscaling is used, with SDL1, Hatari would do integer scaling and leave borders.

Because Hatari re-creates the SDL surface [1] when user changes resolution, I don't think it can be a Hatari problem. It could be SDL problem, SDL problem caused by the window manager, or X backend (DDX) problem.

We have slightly different desktop and SDL versions, which _might_ explain me not being able to reproduce your issue. What about X backend and GL driver, which ones you're using? Modesetting & Mesa Intel i965?

Does the issue look same if you build Hatari with SDL1 instead of SDL2, or is it SDL2 specific?

[1] in SDL2 case, that re-creation can be disabling by setting bUseSdlRenderer = FALSE in config, but you have it in the default TRUE value.


Social Media

     

Return to “Hatari”

Who is online

Users browsing this forum: No registered users and 1 guest