[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] libgem16: vs_color



Helmut Karlowski wrote:
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.

This was directly from XaAES, where no libc16 is required, as you might
know.

My question is still valid.
Where does the linker find the implementation of vsprintf() ?

But the 000-version also seems not to work (not 100% sure yet).

It is not about the 000 version of XaAES... but the CPU on which you run it. ARAnyM emulates a 68040. If it would be possible to run XaAES on 68000, it would crash with 3 bombs when some some variable appears at an odd address.

The inlined code isn't used - at least for VDI, and XaAES doesn't do any
AES-traps AFAIK.
The code that's used does only backup one reg, I think.

Why is the code not used ?
I saw several versions, inline and not... I don't know how what happens in XaAES. Anyway, the registers must be backuped correctly, in any case.

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 ?

Where do you know the 62MB? And the same runs on a TT with 24MB or similar.

The FastRAM starts at 0x01000000.
vdi_intin is at 0x04EB850B.

(0x04EB850B - 0x01000000) / 1024 / 1024 = 62.72

Well, It may not be wrong, maybe XaAES puts the stack very high in the FastRAM... I don't know the MiNT memory layout, but this is surprising.

--
Vincent Rivière