Re: [MiNT] XaAES and appl_init()

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Vincent Rivière, 27.02.2013 11:40:52:

> On 27/02/2013 08:07, Helmut Karlowski wrote:
> > Why does it work on real hardware and real TOS then?
>
> When you reported that issue on the EmuTOS mailing list, I wrote a  
> testcase calling appl_init() from supervisor mode, and it failed equally  
> on Hatari (or ARAnyM?) with EmuTOS and TOS 4.04.

That's no real hardware like a TT is. I'll test it tonight again there.

> And the testcase appl.zip:

I saved it but did not find the time to look at it. 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.

> IMHO, since calling appl_init() from supervisor mode is illegal, it  
> might randomly crash or not, depending on data present on USP or  
> somewhere else. It worked in EmuTOS 0.8.7 by chance, but now it crashes.

Did you try my suggestion to leave out appl_init in XaAES?

That's how it is now on my disk (k_main.c#1742):

  {
  short x;
  //if( mt_appl_init(my_global_aes) != -1 )
  {
    C.P_handle = mt_graf_handle( &x, &x, &x, &x, my_global_aes );
  }
  //else mt_appl_exit(my_global_aes);
  }

XaAES runs from EmuTOS but then EmuTOS crashes when XaaES exits. It's not  
the appl_exit later I think.

> Your patch was actually detecting the presence of FreeMiNT, then

No. It avoided to set the clipboard to u:/clipbrd which is nonsense anyway.

> avoiding the call scrp_write() to artificially avoid the crash. While it  
> was a good workaround, it can't be a clean solution.

The clean solution is far away.

--
Helmut Karlowski