I'm pretty sure its just the DispGraph commands at the moment but please report if you find any more that do that!

Nope, I still can't figure it out

That looks nice, I love the car too!  Someone should make robot unicorn for the calc!

Happybob, I would appreciate it if you could spend a little more time forming your sentences with correct punctuation and grammar because it becomes difficult to read and especially for a bug report, clarity is really important.

For your first point, the back buffer used to draw grayscale is the same back buffer used in the Recalpic and Storepic commands. If you want to back up a grayscale screen, you have to create 2 additional buffers with Zeros(768) and then back up both the front and back buffers to each one using the Copy() command.

Your second point, the OS getkey command does not work with interrupts.  You will have to use direct keys instead like getkey(15) for instance.

Third, you mentioned to me in your PM that your AXEGUESS example program was not correctly returning random numbers and was the same number every time you played the game.  Has anyone else had a problem with this, especially if you use the modified OS by BrandonW.

DJ, that just reminded me, I made a new player that automatically adjusts the timing based on the number of chords of each beat.  However, quality begins to suffer when there are chords greater than 3 notes at once.  However, its much more on beat and than the previous player.  Also, I threw in a cool visualization

All the routines are almost exactly the same speed since they are limited by the LCD speed rather than the CPU speed.  Even if I were to write an 8 level grayscale routine, odds are, it would be just as fast as the 4 level or the 3 level or the monochrome.  The only speed you would be gaining from monochrome is that you don't have to update the LCD as often.

In case you want a more technical explanation why you can't use bcalls that use data in the app, here it is.  The entire readable memory is divided into 4 sectors each 16KB in size.  There are many pages, but they have to swapped around and replace an existing page to be used in that sector.  Apps execute in the sector which is from $4000 to $7FFF as I'm sure you are aware.  It is write protected, but permits reading and executing.  The 1st sector is OS stuff and the last 2 are ram, programs, and the sp stack in normal circumstances.

Now here is where it gets interesting.  The operating system is much larger than just that one page, so when you make a call to something like _PutS or _DispImage the calculator has to swap in the page of the OS that has that routine in it.  And guess which sector it uses?  Its the one at $4000 where the app is.  That means your page is swapped out so the OS can call it's routine.  Now when it tries to read the data you passed to it, its just going to be some random junk on that page and not the actual data you intended since your page isn't at that location anymore!  That's why you either copy the data to ram or write your own routines to use it.

Its nowhere near done and it won't be released until after 0.4.0 comes out.  Currently, the files are exactly 8 times smaller than the original wave file, but that is with no compression, I will add compression later.  I'm still trying to figure out how to convert the 8 bit signal to a single bit one, this is the best I've got so far but I know I can do a lot better.  If anyone knows the algorithm or where I can find it, that would be really helpful!  Especially if you know how the RealSound algorithm works or similar player.

Here is a sample executable, it doesn't sound good, but at least you can hear it on wabbitemu.  Its awful on a real calculator though, so test it on the emulator.