[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FOUND: code causing crashes under AES4.1 in colour
I have found what causes AES 4.1 to crash when running MinT 1.12 (including
h2, h3 and freemint) in 16 or more colour mode. The culprit is in proc.c
starting at line 636:
#ifndef MULTITOS
#ifdef FASTTEXT
if (!hardscroll)
*((void **)0x44eL) = curproc->logbase;
#endif
#endif
This is in function sleep.
If I make a MiNT compiled with -DMULTITOS, it doesn't crash.
If I make a MiNT compiled with -DMULTITOS but with this line and FASTTEXT
enabled, it crashes.
If I make a MiNT compiled without -DMULTITOS it crashes.
If I make a MiNT compiled without -DMULTITOS but with the whole of the if
statement commented out, it doesn't crash.
I don't use MiNT in textual mode, so I can't say how the absence of the above
statement affects it's operation in that mode. Can somebody please check this,
so we can decide what to do?
Notes: according to my copy of Atari ST Internals, 0x44e is _logbase. It would
appear that AES 4.1 is more sensitive to things messing with it's logbase than
AES 4.0. AES 4.0 has no problems running in color without -DMULTITOS.
Before the crash, I have noticed that the LED display shown by LEDPANEL 3.0
shows halfway down the screen (but in the same X position) several seconds
before the crash. Could it be that AES 4.1 keeps an additional copy of
_logbase, and can only keep them in sync if the _logbase is changed thorugh a
proper system call? However, everything works in monochrome.
(And no, the crash is not connected with LEDpannel 3.0 or any other TSR or ACC.
It occurs even if the only things loaded are MiNT and AES 4.1)
Matija
--------------------------------------------------------------------------------
"My name is Not Important. Not to friends. But you can call me mister Important"
- Not J. Important
Matija.Grabnar@ijs.si A Slovenian and an Atarian
Josef Stefan Inst. Ljubljana Stefan's law: the highest power in the Universe
I speak for no one but myself.