Thank you for finding the problem!  Yeah, the interrupt command functions differently than the labels.  I didn't think to look at that, but now I know where it is, thanks.

Mainly that you get the whole 16KB space for execution instead of the roughly 8KB execution limit with regular programs.  It also allows you to allocate much more ram since the program itself is not running from the ram.  There is a possibility of allowing apps to be 2 pages in the future with a second page of data only, but I don't know how feasible that is so I can't say for sure.  There are disadvantages though, so unless memory is an issue, I would just stick with programs.

@Runer, most of those bugs have been fixed in 0.4.3 already.

@Builderboy, that's no bug!  Apps need about 120 extra bytes for the header, about 67 bytes for the dummy signature, and they have larger routines for displaying text.

Its all related to that same bug.  I still haven't exactly found the source of the error, but I found much more information on it.  It is somehow based on timing because transferring exactly the same program on a fresh emulation and following exactly the same steps yields different errors.  Sometimes it happens on the first compile, sometimes I go through 20 compiles and don't have a problem.  And if there is a problem, it's completely different every time.

So since its timing based, I figure that interrupts are probably enabled somewhere where they're not supposed to be.  My initial though was on a routine that uses page swapping since the interrupt expects certain pages to be in place, but all of those routines properly disabled interrupts.  Just to test it, I removed all interrupt enabling instructions from the entire program except for the menu selection where I need it for the getkey.  Since then I haven't gotten the error, so I am suspecting that I indeed found the source of the problem.

But I still can't pin down the actual location of the bug.  Since it only started happening recently, it must be something I added in 0.4.2 but that still doesn't narrow it down much.  What other routines are dangerous to run with interrupts on other than page swapping?

Glad you like it!

1) The first one stores the value 5 into the A variable.  The second one stores a value 5 somewhere in ram at the address A.  You can think of memory as a bunch of boxes, so if A were 1000, you'd be putting a 5 into the 1000th box.  But there are only a few boxes you can use (the free ram) since the operating system uses so many of them.  So don't actually try storing anything to {1000} because that's OS territory.  Overwriting OS stuff is a common cause of ram clears.

2) Real Numbers are stored in the most bizarre format so its extremely hard to read them, I will be adding a converter command eventually.  The first byte is some kind of bit field that also controls the negative sign, the next byte holds the exponent and then the next 7 bytes after that holds the number, but in BCD format (binary coded decimal) so you can't just read it off like a number.

Right, that's because the bit command e is for 8 bit numbers.  ee will be for 16 bit numbers, also counting from the left, I just didn't have time to add that yet.  Also, I will add the auto-opts next version to extract specific bits.

Another reason for counting from the left is because its much more optimized using the add hl,hl instruction (for 16 bit numbers) than trying to shift the number to the right or adding overhead to negate the bit number, so its a more optimized routine.

Okay, I was able to duplicate the error.  It appears to only affect very large source code and it is totally random and not dependent on pass.  I seemed to only get the error when the source was archived or auto-backups were turned off but I'm not sure what the problem is yet.  It shouldn't be too hard to track down though since at least i can replicate it after about 5 compiles.

I updated the doc to include more information about the backups and the new library header if you're curious about those.

I fixed my auto-backups now and much faster than I expected so I decided to use the extra time to see if I could easily implement the external library feature that everybody wants.  And that also was surprisingly not too difficult, but the only catch is that you can't nest libraries because each nested library needs 19 bytes of ram and I don't have enough space to have a big array for that.

A cool thing about the libraries is that those of you who hate having to scroll through all that data at the beginning of your program now have a solution!  You can create a separate file that contains nothing but your data in a separate file and then include it as a library as the first line of code in your main program.  The libraries work as direct insertions so its as if the same data were inserted right at that spot.  You can also keep these files archived so that you have even more free ram left to create the rest of your program.

There are a ton of other uses for this as well.   If you want to make a universal library like a physics engine for example, you can make the first line of the library file a jump to the last line so that it can be inserted once anywhere in the code and then the client has access to all the subroutines included in the library file.  Due to the expansion of available names in labels to 3 characters, you can be fairly sure that your label name isn't already taken with some clever prefixes.

And I didn't even start talking about the backups yet.   They are very strait forward so you can probably figure them out without needing any tutorial.  Selecting a backup restores it, pressing "del" deletes it, and pressing "B" on the source creates it.  In the options, there is a new mode to do it automatically.  That's about it, but its extremely useful.  Anyway, enjoy!