Good news Freyaday, I found your bug. I always had a lingering feeling that the forward djnz I used in to optimize the 4-level grayscale entry was too good to be true. And it was. It works great 99.9% of the time, which is why nobody saw a problem until now. But the issue is, if (flags+asm_flag2) holds a vaue other than -2, -1, or 0 when the grayscale routine is first called, the grayscale mask isn't rotated for anywhere from 1-253 calls.

This is fixed easily enough to restoring the grayscale mask initialization code for p_Disp4Lvl to what it was in Axe 0.5.3, and changing the mask initialization code for p_Disp4Clr in a similar way.

Well, lookit that.
Also, I just downloaded 1.0.4 and the first thing I did was to try compiling LVEDIT

COMPILING...
1st pass 58%
ERROR:
UNKNOWN ERROR
Code: A429992

LVEDIT was archived, so I don't know what it erred on.

EDIT: I UnArchived it, and it compiled fine.

Got the same error at 5% with Minedit. Say, is this 1.0.4's version of BAD FLASH?

Also, MINER is experiencing a really bad bug that, as far as I can tell (which is not very far) seems to result from {Q+L1} erroneously returning a 1 instead of a zero, which is really odd, because if that is indeed what is happening, then it's only doing so in one loop, and not doing so in a later loop.

Also, holy crap! Quigibo, what did you do? Horizontal is waaay faster now!

I'm using Horizontal to move the screen off to the right in an animation.

The source for MINEDIT is attached.

Fryaday, I have two!! 


Axe 1.0.4:    THE SAME ONE WHICH FRIADAY ALREADY HAD
compiling an AD´SM-progrsam (noshell), that already exists:
compiling 4%
Unknown Error
A429992

Backing-up after compiling an app:
unknown error
A429958


I don't think that's what it should do...  

Good news everybody! After a bit of examination of Axe's string parsing code, I've pinned down the exact cause of random characters in strings being replaced with 'r'. I even found two other bugs in the process!

The errors lie in this routine, found at $66FC in Axe 1.0.4:

GetTokString:
or a
ret z
ld hl,OP1
ld (hl),a
cp tVarEqu
jr z,GetTokString_uvw
cp tProg
ld a,ProgObj
ret z
ld a,(hl)
B_CALL(_IsA2ByteTok)
call z,ReadAByte
GetTokString_Cont:
ld (OP1+1),a
ld hl,OP1
B_CALL(_Get_Tok_Strng)
ld a,(OP3)
ret
GetTokString_uvw:
call ReadAByte
ld b,a
cp tvn
ld a,AppVarObj
ret z
ld a,b
cp twn
jr nz,GetTokString_Cont
ld a,GroupObj
ret

First, the 'r' bug. When parsing a 2-byte token in a string, a second byte has to be read from the source file. This raises a (1-in-256?) chance of Axe updating the progress counter in the middle of the routine, and B_CALL(_DispHL) places the string representation of HL in OP1. So whenever the progress counter is updated in the middle of reading a 2-byte token in a string, the first byte of the token (which was stored at OP1) is destroyed and replaced with the character code for a space, $20. This is then passed as input into B_CALL(_Get_Tok_Strng), and token $20 is "randM(" which results in the phantom 'r'.

This leads into the next bug, the presence of which probably made diagnosing the first bug more challenging. The length of the token string as reported by B_CALL(_Get_Tok_Strng) (returned in a and bc) is disregarded by Axe, resulting in every token in a source string corresponding to only one character in the compiled string.

The final bug is regarding a token of special meaning to Axe. Although this routine correctly checks if the token is the "appv" or "grp" token, it doesn't check if it's the "var" token.

I see what you mean about the 'var' token now. But I still think that tokens that correspond to strings larger than 1 character should be represented in their full form. If someone entered "sin(" into an Axe string, I'm pretty sure they actually want to see "sin(". If they wanted to see "s", they probably would have entered "s". This would especially make more sense to less experienced Axe coders who are familiar with being able to include tokens in strings in TI-BASIC. One way or another, you're probably going to need to address the string parsing code again. Because right now, a 2-byte token in a string = instant crash.

EDIT: Whoops, I meant a multi-character token.

Hi i just downloaded Axe 1.0.4 and wanted to compile a code i made with 1.0.2 into an app.
After backupping an unknown error appears :
A429958

If you close it the app still works normally