Okay, I did my research.  This is what appears to be happening.  I believe that there is a very short voltage spike between changing contrast from a very low value to a very high value and vise versa.  You don't see the screen turn blue normally becasue its so fast that you can't even see it.  However, if you alternate the screen very rapidly, the voltage spike appears often enough that it becomes very noticeable.  So this is a faulty hardware problem and there is nothing I can do about it.  I'll just have to trust that you're all being safe about using it.

Here were some clues that led me to my hypothesis:

• You can't get the calculator to stay in a blue state unless the contrast is constantly changing
• The degree of blueness is continuous.  There is not a single shade of blue.
• The degree of blueness is directly proportional to the difference of the values you alternate between
• The degree of blueness is inversely proportional to the amount of pause you have

All of these suggest that the calculator is NOT in test mode.  So this blue is actually less voltage on average than test mode, but that still doesn't mean its remotely safe.  It probably won't fry your calculator right away like the real test mode, but it can certainly damage it over a longer period.  I absolutely do not recommend exploiting this effect.

When 0.3.0 is released tonight (hopefully), I think the grayscale will look a lot better since I improved both of the routines.  Not only does it look better on real hardware, but also it seems to finally be in sync with wabbit settings.  Much thanks again to calc84maniac.

Oh wow!  That's really cool!  I totally forgot about the "ld a,i" instruction, I was about to ask if it was possible to preserve interrupt state.  This seems to be a good way to do it.  Its 6 more bytes I think, but it will surely come in handy when I add custom interrupt support; Just in case someone decides to draw to the screen in their interrupt routine.

I think you might just have your data in the wrong format.

Hmmm... I tested it and it works for me.  Are you sure Str2 is exactly 10 characters?  Maybe you mistyped it.

Try this:
1->L
"vSpLvl00"->Str0
L+'0'->{Str0+7}

Should load levels from 00-09.  If you need more, you have to replace the first digit also.

I really do want to add wav support eventually.  I'm really not that knowledgeable with sound though, so I'd either have to learn how waveforms of sound are converted to digital audio or I'd have to have someone explain it to me.

This was done on a z80 cpu by the way with the most minimal of sound chip:


This and the ProjectM sound (from what I've heard) make be believe that it will eventually be possible.  When I support reading from archive, you'll be able to play some pretty large files.

I think that might be a little confusing.  And also, that is currently valid syntax since empty arguments are filled with the last expression.  That is, your first example is parsed as Line(X1,Y,X2,X2) and the second one becomes Line(X,Y1,Y1,Y2) it can actually be a useful optimization occasionally.  This goes for all multi-argument commands.

I'm probably just going to use the horizontal/vertical tokens for fast lines with the syntax: "Horizontal X1,X2" since I can use the number of arguments to determine if its the line routine or the scroll routine.