When trying to compile DROD8x into a nostub assembly program after having added a tiny piece of debugging code (a single "Text(" command) as the only change in code since the last compile, Axe parser reported "ERR: PIC MISSING" at 5% in the second pass. Pressing PRGM caused it to point at the line which imports "Pic1" to "Pic1T" as a tile map: [Pic1^r]->Pic1T
The picture is present in RAM, and commenting out the "Text(" command I added seemed to solve the problem. However, I need it to debug a certain problem which I'm having with the object buffer, but it won't let me compile with that line of code being there.

Any ideas why this is happening?

Can you post what you were trying to do with the Text command?  Most likely something to do with Pic1T, correct?

Thanks for your replies, but I just found the solution to the problem myself: I simply had to add more code in other places to make it work again. I'm not exactly sure why this happened. I couldn't remove the ^r anyway because I need it to read the pic as a tilemap/spritemap, not a regular picture. The Text( command was not related to Pic1T either, it simply printed the result of an expression on the screen: Text(2,48,{L1+123}-(I+1)*2>Dec)
I guess it's a bug related to code size then.

EDIT: The [Pic1^r] command is actually the first real command, it's in one of the header programs. The Text( is in the main loop of the game.

Thanks for your replies, but I just found the solution to the problem myself: I simply had to add more code in other places to make it work again. I'm not exactly sure why this happened.

Glad it works, but if you still don't know why it happened you should post your code because it might be an Axe bug. Make sure posting your code doesn't break the contest rules though (if it's for the contest).

That's interesting it happened when the picture was in RAM because I first thought it might be a page boundary issue.  I'll double check the code for tilemap importing.

EDIT: Found it!  Funny bug... the picture tokens are 2 bytes each so it has to call an extra "read byte" routine after the first byte has already been added to the file name buffer.  That's fine, but there's a 1/256 chance that the parser needs to display the current progress (which it checks for during every "read byte").  It just so happens that TI's routine uses the same buffer to display numbers so the filename being built up will get corrupted and you get a "pic missing".  This will be fixed next version, in the mean time, adding/removing a comment before the [Pic] command should get rid of it.