I have a feature request.

I was thinking it would be cool if I could  modify the certificate page to remove the trial restriction on the compiled apps so they don't delete themselves after 16 runs.  Yes, I am well aware that this can be extremely dangerous if not coded properly which is why I want to make sure everyone is comfortable with it.  I would of course do extensive private testing before releasing it to the public.  The thing is, I don't know where to find the (un)documentation to do this, I checked WikiTI but couldn't find anything about how the OS operates that page.  So I will probably need a lot of help with this.

^ Yes.

Since someone brought up shells recently, it really got me thinking... what if I created another compile option for an "Axe Shell" that calls all the built-in subroutines from the parser itself instead of copying them into the program?  I'd estimate this would save about a kilobyte in an 8kb program, ~12% decrease in size, while having the speed remain the same.  In fact, I could optimize some routines more for speed instead of size since the size wouldn't matter, so some routines like multiplication and division could be significantly faster.  Yes, this would mean you need the Axe application to run the program if you compile for that option, but for people struggling with the 8kb limit or 3D math speed, it could be a life saver.

But then I realized this would basically involve me writing an entire shell or else you wouldn't have a way to actually run the programs.  Either that, or I'd have to have a home screen parser hook like DCS has.  This is possible, but difficult I think since so many other programs use it and I don't want to cause too many conflicts with the hook chaining.

So that gave me another idea.  Since I 'd like to avoid making a shell from scratch, what if I could get these features built into an already existing popular shell?  So I'm thinking of talking to Kerm about it, I'm not sure how much space is left in DCS so I can't say for sure if this is possible, I think all the axe subroutines combined are under 3KB together.  But anyway, is this something you guys thing I should invest time in, regardless of if it ends up in a new Axe Shell or DCS?  It could makes shells more useful than just the extra header.

Also, besides using square waves from Freq, you can send your own custom signal with the Port command which also allows you to take advantage of both sound channels.

Actually, my favorite color is teal   I don't know how red got into the color scheme of Axe, I think it was mostly from to the images I used in the documentation, and I tried to design a color scheme around them.

The Str, Pic, and GDB tokens are NOT variables.  They are static pointers so they can only be assigned to once and keep their value forever.  If you do need to change the value, simply use a variable instead.  Anywhere you can use "Str1" you can also use "A" or any other variable.

The main thing I'm concerned about with new pixel buffer commands is what I'm supposed to do about pxl-Test() which is half the reason you would use the command in the first place.  It looks too funky to have pxl-Test(X,Y)->P->A mean reading a pixel on buffer P into value A.  I guess I could have an optional 3rd argument instead so it looks like pxl-Test(X,Y,P)->A but this is inconsistent with the sprite drawing to buffers.  I would like consistency so I would rather change Pt-On(X,Y,S)->P into Pt-On(X,Y,S,P) as well if I did that, but that involves a compatibility issue.  I guess this is something to resolve before 1.0.0 because I don't want to make changes like this after.  Unless anyone is really against the change, I will probably change to the new syntax.  I never really liked the original storing syntax anyway, its not really any more intuitive than an extra argument, I don't remember why I did that in the first place.

Oops, I've fixed all of those now.  Although how can you say that //0 is incorrect?  It's undefined, it can be any number I want   On that subject though, the entire signed division routine rounds the wrong way and is inconsistent with the auto optimizations, that is, A//256 can return a slightly different value than A//(256), but I don't know how to fix that without bloating the code and its hardly noticeable.

I guess these bugs mean that 1.0.0 has to come out sooner than I though...

That works.  It will automatically make the high byte zero so you'll get the range you're looking for (0 to 255).  That is, unless that's a signed byte, then you can use sign{byte}->VAR to get the -128 to 127 range.