On 27/02/2013 12:02, Helmut Karlowski wrote:
I tried to boot TOS4.04+MiNT with GEM=ROM on aranym but TOS always
crashes when it comes to the desktop ("set the super-flag"). So I
cannot test TOS4.04.
In order to demonstrate that calling appl_init() from supervisor mode crashes, I tested appl.zip on plain TOS. Probably Hatari + TOS 4.04, or Steem with TOS 1.x, both with GEMDOS hard disk emulation. I don't remember precisely.
Did you try my suggestion to leave out appl_init in XaAES?
I didn't try, but that's a good solution, since the whole point is to not call the AES from supervisor mode.
XaAES runs from EmuTOS but then EmuTOS crashes when XaaES exits. It's not the appl_exit later I think.
EmuTOS may have additional bugs when closing the VDI workstation, etc. Anyway, calling appl_exit() from supervisor mode is forbidden, too.
Your patch was actually detecting the presence of FreeMiNT, thenNo. It avoided to set the clipboard to u:/clipbrd which is nonsense anyway.
I fixed the u:/clipbrd nonsense by fixing FreeMiNT to run GEM= using the boot drive as default drive. It prevented the AES to find the accessories, anyway (both TOS and EmuTOS).
In EmuTOS, it crashes when calling scrp_write() from appl_init() in supervisor mode, whatever the path exists or not. It is not supposed to work from supervisor mode, anyway.
I'm in the mood of adding an explicit panic message in EmuTOS if someone tries to call the AES from supervisor mode (after the 0.9.0 release).
BTW: The whole point is to determine if the VDI physical workstation must be opened or not at XaAES startup, we should focus on that.
-- Vincent Rivière