Update:

I have reading and writing to ALL external variables working right now, I just need to find a clever way to create and delete them.  I might be getting rid of the delvar command used in labels and make that the delete os var useage like how it works in BASIC.

Also I got direct link port I/O working and I was experimenting with the possibility of a "WaveToAxe" converter.  Right now, at 6MHz, I can just barely make out the "It's a-me Maaario!" clip that came with realsound which is what I'm using as a reference goal.  I will update on my progress later and possibly release it if I can get some decent quality, and it seems very possible.  This is NOT an assembly routine, this is in pure Axe code with the direct port commands in 0.4.0.  Unlike realsound however, the clip is much more compressed.  The realsound clip generates a 2 page app whereas the appvar created with my converter is less than 2KB.  Hopefully I can keep it that low as I start finding ways to increase the quality.

Instead of {GDB1}+A you want {GDB1+A}.  Also, you're using way too many parenthesis, they actually do add to the code size usually.  The getkey's don't need the extra pair, A*8 doesn't, and the thing after it has a lot.  Axe reads strictly left to right for its order of operations so most of those parenthesis are unnecessary.

The only time the screen changes is when you use "DispGraph".  The buffer itself is not the screen, its just a place in memory like a program or a variable.  Since the majority of commands draw things to this buffer location instead of the screen nothing actually happens to the LCD screen at all.  It just stays the way it is (no flickering).  The only time the display physically changes is when you use the DispGraph command which looks at the buffer and copies whatever's there to the screen.  It copies the data so fast in fact, that it appears the entire screen was updated instantly.  Once the screen has been updated with the DispGraph command, it will stay that way until the next DispGraph command so you are free to do whatever you want to the buffer in the mean time including clearing it and redrawing all the sprites.

Okay, here it is.  I tried to include a variety of samples for your listening pleasure.  The new format is really compact, its nearly a kilobyte per minute depending on the speed of the song.  It supports all types of midi, up to 8 note chords, 16 simultaneous tracks, and the full 11 midi octaves.  The program works the same as last time, just drag the midi file over the program and it will convert your song into 2 different formats.  One is an appvar, the other is the hex code (no text version this time).  The player is set up right now for appvar playing and I took out the rotating happy face to lighten it up as much as possible, songs play immediately when you run the file.  If you want to create visualizations, be my guest.

There is one setting you might want to adjust which is what I call the "note density".  Its the time argument of the freq() command.  Right now I have it set to what I have found to be a good medium time of 3200 but you might want to make it lower for songs with a lot of chords or higher for those that are mostly single notes.  If songs play too slow or fast, then this is what you should adjust.

Also, for best results, I would remove any drum tracks from the midi files.  Other types of bass tracks should convert fine.

I'm so glad I learned linked lists in my data structures class.  I had to design my own custom linked lists to get this working. 

Oh I forgot to update with my progress.  I have it working now where 99% of midis from the internet can simply be dragged over the application and they will convert really nicely without any extra editing.  However, I am going to redesign the music player so it plays appvars instead of inline code because sometimes 15kb of note data source is really hard to import into the editor but as a precompiled appvar, its only 7.5kb and can be read from archive (soon).  So I think that will be the direction I take the player, but it will output in both formats anyway for small tracks.  I also have to add a look-up table for the note frequencies in order to reduce the size of the files.

I will post the new version as soon as I finish it.  I actually made cave story as one of my demos, but I guess I can't use that anymore... so here it is if you want to compare.  This is the full song I think.  Starts right away.

Ok, I think I'll just stick to the compact masking routine and not the others.  The second one is easy to make with the Axe language itself and the third is probably unnecessary.  But I did think of ANOTHER Dispgraph routine I might add.  I have too many ^r modifiers so it might be an ^o modifier but it would use the extra clock cycles, which are normally wasted, to clear the buffer at the same time as drawing to the screen so you never need a ClrDraw.  It would speed up programs using that a lot probably because ClrDraw is a slow OS routine.

Linking can work 2 ways.  You can either do manual linking; setting the individual lines high and low and writing the link routine yourself, or automatic linking; using my own assembly routines.  So I assume you are asking about my built in routine.  The way it works is that it is mostly controlled by the sender.  It is up to the receiver to check the linkport constantly to see if a byte is trying to be sent, if no byte is being sent, the linker proceeds as normal and does not wait.  The sender however will wait for the receiver to confirm that it got the message that it needs to receive the byte.  You will specify a timeout for the Send() routine so that the calculator doesn't freeze if you disconnect the other calculator.  The sending command will return a 1 or 0 depending on whether it was able to send the byte.  The receiver will return a -1 if no bytes were sent or the byte itself if one was.  I will explain it better when I actually have the commands added.

Is there something weirder going on than just the freeze?  Has anyone else had problems with app compiling on a regular 83+?

EDIT: Interesting... I'm not exactly sure what's going on, it sounds like it could be an issue with the regular 83+.

Looks awesome!   Did you get the custom font working or is that just a picture?  Also, try "Game Gray" 4 if you're using wabbitemu, I think it will produce a nicer screenshot