Bug Reports

[Happybobjr]

I don't think that is a bug.
I might be wrong, but i think that is to tell you the size and location or something.

[Darl181]

{VAR-2}r is the size.
Without the +12, it was copying data that wasn't in the archived program that the file pointed to.

Edit: see edit on other post previous page

[BlakPilar]

I'm not 100% sure if this is all Axe's fault, but whenever my friend goes to compile a program that gets a pointer to an AppVar, the program itself runs fine, but then it closes saying it can't get the AppVar, and whenever he goes to press PRGM afterwards, his calculator freezes and he needs to pull a battery. His OS is 2.53MP and his bootcode is 1.02, if that helps.

[Builderboy]

You would have to post the code, as that sounds like a very general problem that would probably have happened to somebody if it was a recurring bug.  Does he have any other hooks installed from other programs?  How was the appvar created?

[BlakPilar]

I don't think he has any other hooks installed, but I do know that after I sent him zStart and Axe, MirageOS's displaying was messed up really bad, he uninstalled zStart, nothing happened, then the next day it fixed itself.

The code for the program though, was just this:
PROGRAM:A
.B
GetCalc("appvLOL",1)->P


We weren't going to use the appvar, I was just teaching him pointers.

[calc84maniac]

That was definitely the appv token and not the individual letters, right?

[BlakPilar]

Yes, I made sure to check that it was that.

[calcdude84se]

The variable-less version of For( doesn't have its opening parenthesis closed by a newline.
As a result, this simple test program fails to compile:

Code: Select All | Copy To Clipboard

1 2	For(10 End

[Runer112]

Here's a very minor bug that nobody has noticed for a long time. It's a bug with an optimization I suggested that's so insignificant, nobody (including myself) even realized that the optimization was implemented in Axe 1.0.1, until now.

The optimization was that operations on big-endian values read from a constant address, like +{°A}^rr, have an optimized load in the form of ld bc,(pointer) \ ld e,b \ ld d,c. The bug is that the value of the pointer is not included, so any such operations compile to ld bc,(0) \ ld e,b \ ld d,c.

And on a side thought, now that A^r syntax exists for one-byte variable reads, perhaps A^rr syntax should exist for big-endian reads?

[Keoni29]

getKey(41)
(the on key)is broken. It worked fine in previous versions

[Runer112]

getKey(41)
(the on key)is broken. It worked fine in previous versions

getKey(41) appears to work fine for me. Can you show us the section of code in which it is located and not working?

[Keoni29]

Or number "1" is messing up everything, but that's less likely Lemme just pop it in sourcecoder

[thepenguin77]

I don't know if you know this, but the old universal unlock exploit actually corrupts the OS.

So use this one:

Spoiler for Hidden:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

UnlockFlash: ;Unlocks Flash protection. ;Destroys: pagedCount                        ;          pagedGetPtr ;          arcInfo ;          iMathPtr5 ;          pagedBuf ;          ramCode         di         in      a, (06)         push    af         ld      hl, returnPoint+$8214-$81E3         ld      de, $8214         ld      a, e         ld      (arcInfo), a            ;should be 08-15         ld      (pagedCount), a         ;just has to be over 2         ld      bc, $8214-$8167         lddr         ld      (iMathPtr5), de         ;must be 8167         ld      iy, 0056h-25h           ;permanent flags                 jp      $81E3+continuePoint-returnPoint continuePoint:         add     a, e         ld      (pagedBuf), a           ;needs to be large, but under 80         call    $81E3+translatePage-returnPoint         ld      hl, ($5092)         ld      a, ($5094)         call    $81E3+translatePage-returnPoint         ld      a, $CC         cpir         dec     hl         jp      (hl) returnPoint:         ld      hl, $0018         ld      (hl), $C3               ;dummy write flashWait:         ld      iy, flags         djnz    flashWait               ;wait for write to finish         add     hl, sp         ld      sp, hl         pop     af translatePage:         bcall(_NZIf83Plus)         jr      z, not83         and     1Fh not83:         out     (06), a         ret

This version is specifically designed for apps btw.

[Hayleia]

Is there a problem with the pt-Get Command ?
Before displaying a sprite on the buffer, I use pt-Get to save what is on the screen then I display the sprite, use DispGraph then erase the sprite with the pt-Get thing but I have to add an offset to erase the sprite at the right place

Like:
pt-Get(X,Y,L6,L1)
Pt-Off(X,Y,Str0)
DispGraph
Pt-Off(X+8,Y-1,L1)

[Runer112]

That actually isn't a bug with pt-Get(), that's an issue with the sprite drawing commands:

Is axe 1.1.1 known to be buggy with arbitrary buffers?

If you mean drawing sprites to arbitrary buffers, this should work fine in Axe 1.1.1. There is currently a bug in drawing sprites to arbitrary buffers in Axe 1.1.2, but it shouldn't have existed before this. However, you should be able to get around this bug in Axe 1.1.2 by adding 11 to the buffer argument in sprite drawing commands.