XaAES crashes with memory protection without NVDI

[mikrosk]

IIRC, in the b/w mode XaAES works fine as is. However in >=4 (?) colours it requires NVDI/fVDI to run. I think it shouldn't be too hard to detect this situation and warn the user appropriately.

[skaftetryne]

XaAES is working fine on my Milan without NVDI or fVDI in 8- and 16-bit modes. It is also working fine (but slow!) on my Mega ST with VOFA graphics card without NVDI or fVDI in 8-bit mode.

[mikrosk]

Interesting. Maybe it causes trouble only in EmuTOS?

[skaftetryne]

I'm sure I've had problems with XaAES on my standard Falcon with 4.04 and no graphics card. So there is a problem, just not sure exactly what.

[mikrosk]

Come to think about it, maybe the planar modes are the problem? I'll do some testing when I find time.

[skaftetryne]

Dug out my stock Falcon last night for a little bit of testing.

• XaAES works fine with the TOS VDI in mono.
• In colour accessories are loaded, but there's a bus error when apps (like the desktop) is loaded. Could not see any graphical/visual glitches.

On my STE with 8Mb alt-RAM and ET4000 graphics card:

• Works fine in both mono and colour on the graphics card with just Nova VDI.
• Works fine in mono on the shifter (could not test colour as I don't have a colour monitor at hand now), but only if alt-RAM is disabled. If alt-RAM is enabled and NVDI is not running, XaAES will crash upon launch. That is probably caused by blitting to/from alt-RAM.

I don't think it's an XaAES-bug. I can reproduce it in aranym-mmu in 8 bit video. Applications crash in v_opnvwk (PC: 00E33BDA). Sometimes, sometimes not. I can also reproduce it with TOS 3.06 on the TT with the TOS-VDI but haven't traced it there. Maybe the (Emu)TOS-VDI makes assumptions about the (Emu)TOS-AES opening the physical workstation or maybe it's just a stack-overflow.

[vinriviere]

I vaguely remember that long ago, XaAES crashed with EmuTOS VDI. This was because it calls AES appl_init() from supervisor mode. While this is generally considered as a bad thing, it should actually work fine. But this leaded to a stack overflow, and we finally added a workaround. I don't remember well, maybe the stack overflow problem appears again?

It's the clients that crash, not XaAES and removing the apll_init does not change it.

[czietz]

@zabruder : I did also encounter crashes in v_opnvwk and came to the conclusion that the root cause was the 68030's memory protection or rather the VDI's lack of handling it correctly.

See, v_opnvwk in EmuTOS as well as in Atari TOS allocates memory in the context of the calling process, using its default protection settings -- so the memory may very well end up being "private". These memory blocks are organized as a linked list. So when the next process calls v_opnvwk, the VDI will try to walk this linked list of virtual workstations and will inevitably access the private memory from the other process, triggering the crash.
A quick and dirty workaround might be to disable memory protection altogether. As for EmuTOS one can consider fixing this by making the VDI's memory allocation "global".

[mikrosk]

Great find, @czietz. I'm wondering whether there's a hope for us, TOS users on real hardware. If I could count the number of questions about XaAES crashing due to lack of NVDI.. it gets asked quite often. Now thanks to @skaftetryne 's work on VanillaMiNT people are more or less aware of the NVDI dependency but generally speaking it sucks because a potential MiNT distro creator has basically two options: a) distribute NVDI (illegally) b) warn about it in the docs and answer 1000+1 questions why it doesn't work.

[czietz]

As for EmuTOS, the snapshot as of today contains a fix so that EmuTOS's VDI can be used with XaAES and memory protection enabled without crashing during v_opnvwk.
Since those of us who didn't buy NVDI when it was still available are now effectively stuck without it, I think this was a worthwhile effort.

[mikrosk]

Fixed by EmuTOS 0.9.9 released a couple of days ago. By design in TOS VDI.