Helmut Karlowski wrote:
I tried a simple prog to simulate this, but I have no libc16, and the normal one had even pointers.
First, if I read again your first post, the main problem is that you discovered the stack variables are on odd addresses. If this is really true, it is a very bad thing, and may be the cause of your other problems.
Several remarks:1) The vs_color() disassembly has been proof-readed by several programmers, and it seems to be good.
2) You put traces using BLOG. If I'm not wrong, BLOG is actually bootlog() and uses vsprintf(). Since you don't have a libc16, where does your vsprintf() come from ? Beware to never mix mshort/mlong libraries... Link using "-Wl,-t" to see where what you link come from.
3) I have just learned that the 68020+ allow word and long access on odd addresses. Can the stack be on an odd address, too ? If it is the case, the stack may have been on an odd address for a long time... You should trace the addresses of some local variable in the caller of vs_color(), and its caller... until you find where the stack becomes odd.
4) Be sure your gemlib has the latest patches for the clobber lists. A register not cleanly backuped can certainly cause this kind of problem.
5) The values of your pointers are at more than 62 MB from the start of the FastRAM, does this look good ? Could we face an out of memory ?
6) Do we face a stack overflow ? It can produce this kind of problem.7) Beware of a6... It is that damn frame pointer (when used as is). If it gets corrupted (by some gem call ?) the stack value will be corrupted, too.
8) If a local variable overflows (array out of bouts, etc), it can alter a backuped stack value, and produce an odd stack.
Well, a lot of questions... But I'm pretty sure the real problem is not at the top of vs_color().
-- Vincent Rivière