Helmut Karlowski wrote:
So if fvdi changes d0-d1/a0, there should never be a problem from this if called from C,
Yes. With my first fix, if the vdi changes only d0-d1/a0, there will be no problem. With the second fix, if some VDI implementation change d2/a1/d2, it will be OK, too.
Beware: as I signaled in the other thread, my first gemlib patch has broken "make install". The file libc16.a is not correctly installed. If you want to make tests now, please copy it manually in /usr/lib.
and the bus-error I get on v_clswk must come from somewhere else.
Probably. But it should be examined with a debugger.About debuggers, I was really comfortable on ST, with Devpac 2's MonST for normal programs, and amonst.prg the resident version for other programs.
But MonST2 does not work on ARAnyM. I use GDB on ARAnyM, but only for normal programs. I don't know how to debug the AES. I remember that Hatari might have some debugging facilities, but I never tried those.
a0. At the beginning of graf_handle(), GCC put important data into a0. Then it calls the trap #2. And after that, it uses a0 at the end ofWhat AES - that one from EMUTOS?
I have tested with the AES from TOS 1.62, and I confirm that a trap #2 for calling graf_handle modifies the a0 register.
We discovered the problem on FireTOS, which is a heavily patched TOS 4.04, but those parts of the AES are unmodified. Same problem with a0.
-- Vincent Rivière