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?

I don't use them, but I like to keep them on anyway (or assume that they are on) just in case any of the bcalls require them to stay on or toggle the interrupt state themselves.

I think I'll update late tonight.  In case anyone has noticed the pattern, updates ending in even numbers are generally less stable because I add the most drastic changes to them and then the odd number updates fix the bugs of the previous versions and then add only easy templated things.

Axe 0.4.2 is throwing ERR: LBL MISSING even though I searched the whole source file for subroutine calls, and they all exist. The program compiles correctly with Axe 0.4.1.

On a side note, scrolling to an error in Axe 0.4.2 and then, without closing the program editor, opening Axe again and going to the compile menu, causes graphical problems. The title is missing from the list of programs to compile, and when compiling a program, the whole interface is shifted down a line.

EDIT: On another side note, I cannot tell you what is causing this but every now and then during a compile, I'll get ERR:MEMORY and I'll have 0 RAM left.

EDIT 2: I just double and triple checked my source, line by line. I can't find a Goto or sub() anywhere that calls a nonexistent routine. I'm a little depressed, I waited like a week for 0.4.2 to come out with a fixed division routine so I could resume work on my contest entry, and now this. :'(

EDIT 3: More than one of my programs are affected by this problem, although not all of them. I wanted to see if the specific label names I used affects it, but it does not appear to be so. Replacing all the subroutine names with ones from programs that compile successfully did not remedy the problem. Next, I will see if rearranging subroutines changes anything.

EDIT 4: Rearranging the subroutines does not appear to help. At this point I don't know what else I can do.

EDIT 5: I tried to disable interrupts during compiling using wabbitemu's debugger because earlier you said that interrupts could potentially cause problems. No such luck, either the parser or the OS somehow re-enables interrupts during compiling.

@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.

@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.

Release 0.4.3 soon? Or maybe even just 0.4.2.5? I really want to get back to work on Link's Awakening. Or if you want to wait a while more to make the next release have a bit more in it, could you possibly just email me a copy of the fixed 0.4.2? If not that's ok, I guess I can wait like everyone else lol. But if so, thanks in advance.

Weird, axe 4.2 was completely black, exccept for the highlighted option, which was white, you might want to look into that (a ram clear didnt fix it )

That's a known bug. for now, just re-install the app.

Since you're talking about interrupts, by int(), I assume you actually mean fnInt()?

fnInt(1,2) would try to activate Lbl 1 as an interrupt, and I'm guessing you don't have a subroutine called "1" in your program, so getting the label missing error would make sense.

I can't be sure, but Axe seems to be pretty stable for now, so I would guess the RAM clears are being caused by your code itself, not a bug. You would need to post it so somebody could look at it and determine if it's a problem with your source code or if it is in fact a bug.

Actually, you may be onto something. I assumed 0.4.3 fixed the label errors, but apparently it didn't. The problem appears to be with the fnInt() command. As far as I can see, the problem is that, using whatever shortened character set Quigibo uses to store label name data (if I had to guess, 0-9 A-Z), the first character of the label name called is always misinterpreted. It seems that this character is stored with a value 10 less than what it should be. In one of my programs, I want to enable "INT" as an interrupt. When compiling, fnInt(INT,6) throws a missing label error, claiming that "8NT" is missing. fnInt(ZNT,6) throws an error, claiming that "PNT" is missing. In both of these names returned, the first character has a value 10 less than what it should be. fnInt(SNT,6), however, compiles correctly, as S is 10 letters ahead of I in the alphabet.

This error only appears to happen with fnInt(), not sub() or Goto.