No, see my edit above:
"(and searching for the area still isn't a proper solution. You never know when the OS decides to move things around in that area, for example inside GetKey, other keyboard reading routine, or through a system timer)"

That is a good point. I have the firmware loaded in IDA pro I want to get to the bottom of this. I just started disassembling it and I am still new to disassembling so it may be a little while. I already extracted the firmware and such. If anyone already knows at what offset the syscall handler is for firmware 2.00 please do tell. The offset we use is virtually mapped using the MMU.

So the way addins were writing to VRAM might have been what broke my PRIZM?

I don't think that was the reason. I have been running my programs which did write to what was at the time though of at the time as what was used by the save/load vram functions. I used the search solution in my open jazz jackrabbit port and it fixed crashing.

I mean not to bump such an old thread but I believe it is important to get the attention of people who may have taken my previous advice of searching for the secondary VRAM address. This is not needed, instead use the syscall I recently found http://prizm.cemetech.net/index.php/GetSecondaryVramAddress.

Doing so will reduce binary size and increase performance. Also please do not use a hard-coded address in your program. That will cause instability. This syscall puts an end to the confusion.

Thanks for finding that, although a bit too late for addins I released (I have poked around in the past for such a syscall). The asymmetric engine-powered addins (Only public one right now is PJumpingCube) scans the RAM for this and caches the pointer and OS version information to a file in main memory (and proceeds to use this cached value unless it is removed or the OS is changed).

That's a great news ! Good job !
I think I had some old projects which weren't very stable I could give a look again.

May I just ask you how did you managed to find this syscall. Using OS disassembly ? I'm just curious about the research process.

Yes I used a disassembly. What I did was look at the code for either SaveVRAM_1 or LoadVRAM_1 (it does not matter which one is used) and then saw that it was a very simple function that only loads the VRAM address and another hardcoded one and calls a function that I had already identified as memcpy but is not a accessible as a syscall. I then looked at xrefs to the address (where else the address is used) and then saw a function that only returns the address.

Thanks, ProgrammerNerd, for finding and documenting it. Good to know that new things are discovered for Prizm thanks to people here.