For accurate trig functions you'll pretty much have to turn to a LUT. The only reason sine and cosine routines exist is because they have a limited range and can be somewhat accurately approximated by a quadratic function. And by somewhat accurate, I mean errors reaching 10%. Trying to model just about any other trigonometric function with a simple model would probably result in wild amounts of error, and trying to model them with a more complex model would probably end up being larger than a LUT-based solution anyway. Unless you need a variable argument for your scale factor, it's best to just use a custom pre-computed LUT.

Not easily/efficiently in Axe code. I believe this would do it though. This can also be easily modified to work with buffers besides L₆ if you need that.

.Example call
63sub(SRL)

.Shift Row Left
Lbl SRL
Asm(140140937DE6C0B4C02C7D87856F292909060C2BCB1610FBC9)

.Shift Row Right
Lbl SRR
Asm(140140937DE6C0B4C07D87856F292909060C2BCB1E10FBC9)


Alright, that makes sense. Thanks.

For the past week or so, I worked on an Axiom that includes a lot of commands for interfacing with the LCD driver. I think I've finished adding just about everything I wanted to and hopefully it has no bugs, so I'll release it. Here are its features:

• Turn the LCD on or off    ? This one's cool
• Get the on/off status of the LCD
• Set the contrast (I just realized as I'm writing this that Axe could already do this, but this command is safer)
• Get the contrast set by the OS (useful for setting the screen contrast back to normal)    ? Pretty useful
• Set the screen's z-address (internally shifts the rows of the screen up/down)    ? This one's really cool
• Apply screen flipping effects (on newer calculators with compatible drivers)
• Read and write individual bytes/words to and from LCD memory
• Copy a stream of bytes to or from LCD memory

That's a lot of information to throw at you about what it can do. To give you some ideas of how you could use some of these commands, here would be some useful applications of this Axiom:

• Turn the screen off for a teacher key or to save power in a waiting state
• Make contrast effects based around the active (OS-defined) contrast value and then return the contrast to the proper value when done
• Use z-addressing to apply an earthquake effect without having to worry about shifting the buffer image (or make crazy tunnel games)

Anyway, without further ado I will attach a zip file containing the LCDKit Axiom, its source code (sorry if it's tabbed oddly, I designed it in wabbitcode), a readme, and a command list. The Axiom appvar is fairly small for a library with 31 routines, weighing in at 651 bytes. Note that Axe will NOT add the whole thing to your program, only the routines that you actually use, so don't worry about any unnecessary code bloating.

---

Changelog

• 1.0.1 (Mar 28 2011):   Fixed a bug that slipped by, breaking the ?imag() commands
• 1.0.0 (Mar 28 2011):   Initial release

MAKE SURE YOU DOWNLOAD THE LATEST VERSION, CURRENTLY: LCDKit_1.0.1.zip

I think he wants conversion the other way around.

Quigibo, I noticed that you implemented a bunch of my optimizations/bug fixes, which is awesome. Having left a few out is fine, but I'm stuck wondering why you left out a specific few of my suggestions in particular that I thought would be useful. Did you just miss some of these, or did you purposely leave them out?

• An optimized Exch() routine
• Turning p_DispStrApp and p_TextStrApp into subroutines
• Adjusted GetCalc() routines; I see you included one of the three adjusted routines (p_GetArc) probably because it's smaller than the original routine, but this routine includes the adjustment made in the other two routines I suggested and it seems incongruous for only the archived GetCalc() routine to have this fix implemented

And on an unrelated note, could you extend the DispGraph change to DispGraphClrDraw as well? And because I know a bunch of people may not like DispGraph no longer working in 15MHz mode, could you perhaps include a routine like DispGraphNormal that saves the CPU speed setting, puts the CPU in 6MHz mode, calls the normal DispGraph routine, and then restores the CPU speed? Something like this:

p_FastCopy6MHz:
.db __FastCopy6MHzEnd-1-$
in a,($02)
rla
in a,($20)
push af
xor a
out ($20),a
call sub_FastCpy
pop af
ret c
out ($20),a
ret
__FastCopy6MHzEnd:


The DispGraphClrDraw routine was unchanged. Although it probably should have been changed, so I'm going to bug Quigibo about that and a few other things.

Anyway, here's why you need to make sure you're not running at full speed. These are the results of a simple program that fills L₆ to be entirely black and then calls DispGraph. These images aren't actually from wabbitemu because it doesn't account for LCD delay and so this problem isn't present.

6MHz		15MHz
Before		Before
After		After

I know, I meant the radians symbol as a suffix to the command and have it execute a different routine

Yes. The fifth byte of every Axiom command header details specifics about how the routine is called. Here is what AxiomSDK.txt says about this byte of the header:

;____FIELD 4____
;Description:     Command type
;Size:            1 byte
;Bits:            bit 0 ==> Subroutine instead of inline routine
;                 bit 1 ==> Command requires the r modifier
;                 bit 2 ==> Command requires the rr modifier
;                 bit 3 ==> Additional argument comes before a store token

So if bit 1 of this byte was set, your routine would require one ^r modifier.