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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,

Hatari 2.2.1 compiled with the sources from February 10th is working fine
with my Linux system, which I think I already mentioned some weeks ago.
(It still works fine and does not have the issue I reported, just checked it.)

How sad. I've been very satisfied with Hatari in the past, in particular
because of its very good compatibility to the original system, to both
hardware and software.
Your response sounds a bit too much like "you are using the wrong Linux
system and and the wrong (original!) TOS" to be motivating. Let's just
keep things as they are, maybe somebody else is going to stumble over a
similar issue and has a better setup.

Best regards

Uwe

> 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
> 
>