Re: [hatari-devel] TT emulation crashes when there is no ACSI drive

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 8/5/19 9:49 PM, Uwe Seimet wrote:
> > Btw. Please don't disable compatible CPU option (prefetch)
> > unless your PC is so slow that Hatari doesn't work otherwise,
> > it breaks more things than just disabling cache emulation
> > (which is only about cycle exactness required for things
> > like DSP sync).
>
> Wouldn't it be better to remove this option, if using it is that
> dangerous?

It's not "dangerous", it just makes emulation less compatible,
but faster.  There are several other similar options in the UI,
with different speed / compatibility compromises [1].

When reporting bugs, in general one should try using defaults
for everything that made emulation less compatible.

[1] GEMDOS HD, cycle exact, fast FDC, boot faster, patch Timer-D,
    HW FP, dummy DSP.  Compatibility document has info on which
    programs we know to be affected by these.


> > Please try also EmuTOS.  As it happens only from AUTO, it could be
> > something TOS version related.
>
> I'm afraid I don't have enough time to play around with all kind of
> options and TOS replacements.

NF SCSIDEV is your feature, so you should be prepared to spend
a bit of time debugging issues around it, as others don't have
a setup for that.

(If feature is reported to be buggy and there's nobody who's going
to be fixing it, we need to consider disabling and eventually
removing it, if it remains in that state for multiple releases.)


> All in all, things should work with regular TOS.

Nowadays I consider EmuTOS a regular TOS, it's even shipped
with Hatari binaries. :-)

You can download latest release from here:
https://sourceforge.net/projects/emutos/files/emutos/0.9.11/emutos-512k-0.9.11.zip/download


> I have to admit that it disappoints me a bit that issues I stumbled upon
> more than once in the past pop up again, especially Hatari crashing when
> I change settings in the UI.

Assert you reported is a problem in your Linux setup, not in Hatari.
It would happen also with other programs using SDL / ALSA.

(Apparently when you provide pulseaudio plugin for ALSA, ALSA works
properly only if you're running pulseaudio.  Otherwise ALSA asserts when
e.g. SDL re-initializes it.  Either remove your ALSA pulseaudio plugin,
run pulseaudio daemon, or coerce ALSA upstream to fix the plugin to
work when there's no pulseaudio.)


> I may be wrong, but from my experience there tend to be more regressions
> than there were in the past.

Possibly.  Hatari has nowadays more features, but Hatari developers
(at least Laurent, Thomas, me) have less time for Hatari nowadays
(= less testing with random programs between/before releases).

Note that some of the regressions found in recent releases are quite
old though.  E.g. the VDI regression I bisected to have happened
before v1.0.


	- Eero