Hatari 2.3.0 has been released

[npomarede]

Hello

Here's a new release after nearly 2 years !

You can get it from http://hatari.tuxfamily.org/ or directly in http://download.tuxfamily.org/hatari/2.3.0/

Sources are available, as well as prebuilt binaries for Windows (in 32 bit and 64 bit mode) and macOS (thanks to Troed).
(note that the Windows binaries don't include PortAudio/PortMidi libraries for now, only macOS version does)

See release-notes.txt for the full changelog http://hatari.tuxfamily.org/doc/release-notes.txt

This release also features a guest intro by Evil/DHS and spkr/SMFX, available here http://download.tuxfamily.org/hatari/demos/hatari_2.3 or here https://demozoo.org/productions/287696/
Thanks a lot to both of them for coding it !

Nicolas

[AnachronyX]

It's great. But there must be some changes in rendering code in fullscreen, because now it's a little blurry.

[dma]

there must be some changes in rendering code in fullscreen, because now it's a little blurry.

You can probably tweak the following options described in the release notes to change this:

- SDL2: "--zoom" option accepts any values between 1.0 - 8.0
- SDL2: "--zoom" option is changed to always enable low resolution
doubling before SDL framebuffer is scaled up (or down) by the zoom
factor. This way Hatari output window is approximately same sized
regardless of emulated Atari resolution, like on a real CRT monitor
- SDL2: scale quality is selected automatically; nearest pixel for sharp
output with integer scaling factors, and linear scaling to smooth out
issues with non-integer scaling and window resizes
- SDL2: Now redundant "nRenderScaleQuality" config option is
removed and "Linear scaling" option in GUI is replaced with
the "GPU scaling" option (=bUseSdlRenderer config option)

[AnachronyX]

Thanks, but I'm afraid it's some kind of a bug. Because when I change mode in "Atari screen" settings to Mono and back to RGB in fullscreen, everything looks sharp. But when I leave fullscreen and enable it again by pressing F11, screen looks blurry again.

[shoggoth]

It blows up on my Mac (Catalina) each time I try to switch to a different machine (e g TT->falcon). Also CPU emulation speed seems odd, it’s like it’s running at ST speed while in TT mode.

[shoggoth]

It blows up on my Mac (Catalina) each time I try to switch to a different machine (e g TT->falcon). Also CPU emulation speed seems odd, it’s like it’s running at ST speed while in TT mode.

EDIT: There's a remedy - delete your existing cfg file and it'll behave better. There's a minor GUI-glitch on the mac version though; in "dark mode", some of the GUI stuff is black on an almost black background, or white on a white background (dialog button). Besides that, things are looking good!

[Emphii]

I have strage behaviour with Windows 64-bit version.
If I start HAtari, load my Falcon config file and run, the program just quits when it should go to my boot program or to desktop. Same behaviour with emutos.

Then If I start HAtari, choose my TOS404.img -rom and run, the emulation starts fine to desktop. Then I can press F12 and load my Falcon config file and run and it starts as expected.

Any hints, how to trace the reason? It just looks like HAtari *has* to say, "==> Switching to Falcon mode now."

And, yes - I rebuilt the config file as shoggoth adviced.

[Emphii]

Also I noticed that in this version was improvement with screen size handling. If eg. demos change the resolution between 320/640, the screen size remains same size through the show and it's more pleasure to watch.

Probably this "- SDL2: "--zoom" option is changed to always enable low resolution doubling before SDL framebuffer is scaled up (or down) by the zoom factor. This way Hatari output window is approximately same sized regardless of emulated Atari resolution, like on a real CRT monitor"

Well - It works as long as you don't have borders - If settings are RGB and show borders, behaviour is like earlier. No matter if you use -z 2 or not as starting parameter (well, -z 2 hides the window title bar)

I forgot to mention Windows version earlier, it's W10 Home (2004).

And mention to earlier behaviour, I've started the HAtari several times now and every time same thing - First, choose tos image manually *nothing else* and run emulation. After that I can choose my regular settings and it runs nicely.

[Eero Tamminen]

Also I noticed that in this version was improvement with screen size handling. If eg. demos change the resolution between 320/640, the screen size remains same size through the show and it's more pleasure to watch.

Probably this "- SDL2: "--zoom" option is changed to always enable low resolution doubling before SDL framebuffer is scaled up (or down) by the zoom factor. This way Hatari output window is approximately same sized regardless of emulated Atari resolution, like on a real CRT monitor"

Well - It works as long as you don't have borders - If settings are RGB and show borders, behaviour is like earlier. No matter if you use -z 2 or not as starting parameter (well, -z 2 hides the window title bar)

I don't see that on Linux. Do you have something smaller than:

Code: Select all

nMaxHeight = 588
nMaxWidth = 832

In your Hatari config screen settings?

[Eero Tamminen]

Thanks, but I'm afraid it's some kind of a bug. Because when I change mode in "Atari screen" settings to Mono and back to RGB in fullscreen, everything looks sharp. But when I leave fullscreen and enable it again by pressing F11, screen looks blurry again.

What is your monitor resolution? Does using "--resizable off" option help?

(Maybe there's some weird interaction with code trying to find best integer scaling factor and what SDL reports as your monitor resolution. When *non-integer* scaling factor is used, bi-linear ("blurry") scaling) is used automatically as that looks much better with them than not doing "blurry" scaling.)

[Eero Tamminen]

I have strage behaviour with Windows 64-bit version.
If I start HAtari, load my Falcon config file and run, the program just quits when it should go to my boot program or to desktop. Same behaviour with emutos.

Then If I start HAtari, choose my TOS404.img -rom and run, the emulation starts fine to desktop. Then I can press F12 and load my Falcon config file and run and it starts as expected.

Any hints, how to trace the reason? It just looks like HAtari *has* to say, "==> Switching to Falcon mode now."

Could you attach the problematic config file? I can't reproduce that behavior with any recent config files I have myself.

[Zandig]

Thanks for the new version. Been using it for some hours now and everything is looking good.
Windows 10 - 64 bit - Version: 2OH2

* NOTE:
Still have to " Disable Fullscreen Optimizations " for Hatari in the WIndows Compatibility settings

[czietz]

Could you attach the problematic config file? I can't reproduce that behavior with any recent config files I have myself.

I can reproduce (the same / a related?) problem with the following steps using the Windows binary of Hatari 2.3.0:

1. Rename/move config files so that Hatari uses its default config.
2. Start Hatari. It boots in ST mode with EmuTOS.
3. F12 -> System. Change machine type to Falcon.
4. Confirm that Hatari must reset.
5. Hatari closes/crashes.

Windbg tells me this is an access violation somewhere ide.c. Unfortunately, I don't have time to debug it further. I wonder if IDE is being accessed (because the machine is detected as Falcon) but the IDE emulation has not been initialized.

[Emphii]

Could you attach the problematic config file? I can't reproduce that behavior with any recent config files I have myself.

Actually, you don't need any config file.

If you make as czietz suggested, remove config file, I even renamed tos.img to EMUtos.img, so it's not loaded in startup and I have possibility to choose desired config in start.
Then start HAtari, select System -> Falcon, select CPU -> 68030, select ROM -> tos404 romfile, select Reset machine and last select OK.

It starts selftest/memorytest and timeout and when it supposed to load GEM, HAtari quits.

I tested this on two Windows 10 64 bit machines, latest was W10 Pro, 2004.

The strange part is, if I choose ONLY rom file, HAtari says, "Switching to Falcon mode" and after that everything works nicely.

@czietz, can you confirm that "choose only rom" path?

[czietz]

@czietz, can you confirm that "choose only rom" path?

Sorry, I tested with EmuTOS, so I didn't have to choose a new ROM file at all.

[Emphii]

I don't see that on Linux. Do you have something smaller than:

Code: Select all

nMaxHeight = 588
nMaxWidth = 832

In your Hatari config screen settings?

Actually I had. I had nMaxHeight = 576 (that was taken from config file I use in 221), so I changed it to 588 and tried again - Works same way, screenwindow gets to lowres+borders resolution. I have no HiDPI / Retina displays.

[Anima]

Great news. Thanks to all people involved.

I have yet to try it though.

[Eero Tamminen]

Actually, you don't need any config file.

If you make as czietz suggested, remove config file, I even renamed tos.img to EMUtos.img, so it's not loaded in startup and I have possibility to choose desired config in start.
Then start HAtari, select System -> Falcon, select CPU -> 68030, select ROM -> tos404 romfile, select Reset machine and last select OK.

It starts selftest/memorytest and timeout and when it supposed to load GEM, HAtari quits.

I tested this on two Windows 10 64 bit machines, latest was W10 Pro, 2004.

The strange part is, if I choose ONLY rom file, HAtari says, "Switching to Falcon mode" and after that everything works nicely.

This is crash with Hatari IDE emulation.

(I hadn't realized that you meant Hatari crashing, I thought you meant that some emulated Atari program didn't work.)

There was a change in how IDE addresses are handled in Hatari quite close to release. IDE registers are available either if IDE disk or Falcon emulation is used. Because TOS IDE scanning can slow down TOS boot a lot unless user actually has IDE disk, IDE registers won't be enabled for Falcon when there's no IDE disk *if* user uses "--fast-boot on" option. There are also several ways how Falcon emulation could get enabled.

This turned out more complex / problematic than anticipated, and couple of ways to get segfaults with it have been already fixed with, one just before release, but apparently not all.

Unless you really need accurate TOS bootup memory detection emulation, I would suggest you to run Hatari with "--fast-boot on" option (by default Hatari uses most accurate emulation, but that is also slowest). That should work around the IDE crash on switching to Falcon emulation, at least when you don't specify any IDE disk.

[Eero Tamminen]

Still have to " Disable Fullscreen Optimizations " for Hatari in the WIndows Compatibility settings

Unfortunately I don't have any clue what that is (none of the Hatari developers have Windows). Why do you need to disable it, and what it's supposed to do?

(Most likely it's some libSDL2 Windows backend issue, but maybe Hatari could do something to work around it.)

[Emphii]

Unless you really need accurate TOS bootup memory detection emulation, I would suggest you to run Hatari with "--fast-boot on" option (by default Hatari uses most accurate emulation, but that is also slowest). That should work around the IDE crash on switching to Falcon emulation, at least when you don't specify any IDE disk.

Ok, I agree with this work around.

I'm glad that you have a clue, where the problem resides.

[solskogen]

Does the crash also happen with this http://antarctica.no/~hatari/latest/windows ?

[Eero Tamminen]

Does the crash also happen with this http://antarctica.no/~hatari/latest/windows ?

I don't see why it wouldn't. Using Christian's steps, I was able to crash Git head build of Hatari (on Linux).

[solskogen]

Ah, sorry. I was under the impression that the crash only happened on Windows.

[ThomasI]

Hi!
I just tested HATARI V2.3 with my Randomazer Standalone Pack.
It seems to work flawless and great!
I love the new scaling quality! Makes everything look much better! I dont mind the slight blur at all.

It is not updated on the Randomazer site yet, but for sure I will update the download within the next days.


All that said: I see no change in the gamepads that have missing axis (see my other thread). I hope to be able to meet with some Linux people soon, to verify if this is a windows related problem or a wider issue (COVID lockdown is delaying this this test)

[dma]

The new "zoom" option is excellent, thanks for this.