Quigibo, do you mind explaining the floating-point format to us?
nemo, the main problem is that floating-point numbers use a very different format than two-byte integers.

Also, bug I meant to report earlier. I have to pass 7 as the size argument to GetCalc( for real variables else I get memory leaks (too high) or crashes (too low). I guess this isn't a bug, but you should document it

Yeah, I'm looking into it.  I'm working on the masked sprite routine right now so at least I can add something new to 0.4.1 instead of just a bunch of bug fixes.  Hopefully I will find and fix them all so I can update late tonight or tomorrow.

I couldn't find a pattern in Runner's corrupted data, it seemed to be completely random, but always a high order nibble indicating to me that it's most likely an error in reading the hexadecimal number since if one character gets accidentally read as a zero, that could cause it.  My solution to this was to disable interrupts during all of the routines which swap pages (which is all the reading routines) because I fear that could be interfering.  I have no idea if that solves the problem or not since I can't replicate it myself, I'll need some confirmation.

In DJ's case the corrupted app he sent me randomly had a zero written to exactly every 256th address, that is all addresses of the form $xxCE, and this isn't the data part of the code I'm talking about, this is the entire application and so some commands got screwed up due to having random zeros written over them.  I'm not sure what this implies, but I think its possible that its a problem with the rom chip since the errors are so regular and the app itself compiled completely normally otherwise.

I'm having some problems with division... I was trying to debug the problem in my program with this:

Text(0,52,C^213*256▸Dec)
Text(0,58,C^213*256/213▸Dec)
The only difference between these two lines is that one has a /213 at the end. When I run the program, the output is (almost always) incorrect.

I attached a sample program I quickly whipped up to further demonstrate the problem. Almost every division is incorrect, although a few are correct. The divisions always seem to result, in order of commonness: 0s, powers of 2, 18 times powers of 2, 66 times powers of 2, 68 times powers of 2, and if and only if C^213 equals 114, the correct answer of 137.

Haha wow, the OS division routine doesn't work properly? How have I been the only one to discover this?

Ah, so its really 16-bit / 7-bit then.  In that case, the name is really deceiving, maybe I should mention this in the WikiTi for that bcall.  I might just change the auto-opt to use this optimization only if the constant is smaller than 128 and just use my normal 16 bit division routine otherwise.

Hmm... but that routine is faster for 8-bit numbers.  I wonder if it wouldn't be too much overhead to have single routine for both 8-bit and 16-bit divisions that checks if the input is 16-bit or 8-bit at the start and then branches to the correct routine.  I feel this might be a large enough speed increase to justify the extra size since i think a majority of divisions are with numbers smaller than 256 which will all be sped up almost double, both when using constants and variables.  It would be about 20 extra bytes to the subroutine and only 1 extra byte when calling the routine with a constants smaller than 128 (unless otherwise optimized).  This would also increase the speed of signed division.  Can I get some opinions on this?