Re: [MiNT] What's wrong with QED?

[Paul Wratt <paul.wratt@gmail.com>]

2011/8/16 Vincent Rivière <vincent.riviere@freesbee.fr>:
> Bernd Mueller wrote:
>>
>> since a few days i have some serious trouble with aranym, easymint (
>> with latest 1.18 kernel ) and xaaes ( all from cvs ). From time to time
>> i get a bus error when i start qed. when it starts without a bus error
>> qed looks busy. I only see the busy bee and the system is locked.
>
> The first thing to do when you encounter such trouble is to increase your
> executable stack. Something like:
> stack -S 128K qed.prg
> And IIRC, QED needs that.
>
> Also, there is a design bug in the original GEM USERDEFs. They are called in
> supervisor mode with a very small stack. This can easily cause an AES stack
> overflow, even when the executable has a huge user stack. XaAES does not
> seem to have this problem. But plain TOS and EmuTOS are affected.
> This problems affects the CFLib, which is used by QED. Some functions in
> modern GemLib (text blits ?) use huge arrays on the stack, they immediately
> cause a stack overflow when used in USERDEFs.
> I proposed a big hack for the CFLib some monthes ago to solve that, it
> worked perfectly for me, but had poor success here.
>
> I would like to include the CFLib in my cross tools distribution, but it
> bothers me to do that while it is not able to compile a working QED for
> TOS...
>
> --
> Vincent Rivière
>
does this allow QED to run on TOS?

what were the other problems mentioned, or does that refer to "hack"
being adopted?

If the hack allows TOS programs to run correctly, then it should be
adopted and then a more permanent solution should be looked into..

Paul