Omnimaga

Calculator Community => Major Community Projects => The Axe Parser Project => Topic started by: Quigibo on February 05, 2010, 03:25:34 am

Title: Bug Reports
Post by: Quigibo on February 05, 2010, 03:25:34 am
I thought I'd start this in case anyone is finding any bugs.  Its important I find them now before I start hard coding everything.  There is only so much I can do with testing, so I need your help!

Verified
* Custom interrupt label names are not processed correctly . [Fixed]
* Interrupts get disabled randomly with DispGraph commands when enabled previously [Solution Unknown]
* Error scrolling corrupts program data when programs are extremely large [Problem Unknown]

Unconfirmed
* Compiler freezes regularly when compiling applications on some calculators
* The AXEGUESS example program is always winning with the number "4"

Please confirm any unreproducible errors so I can make more sense of them with your calculator model, factory letter, operating system version, and other hook based programs on your calculator if applicable.  Thank you!
Title: Re: Bug Reports
Post by: Builderboy on February 05, 2010, 07:02:51 pm
It seems that OR does not work :( I have this program
Code: [Select]
0->A
1->B

If A=0 or B=0
Output(0,0,"HI
End

And when i compile and run, nothing is displayed.
Title: Re: Bug Reports
Post by: Quigibo on February 05, 2010, 07:18:19 pm
That's because I haven't implemented order of operations yet  ;)  It just goes left to right.

These are equivalent:
Code: [Select]
If A=0 or B=0
If ((A=0) or B)=0

Instead, try this:
Code: [Select]
If A=0 or (B=0)
Once I get to order of operations, this shouldn't be a problem anymore.
Title: Re: Bug Reports
Post by: Builderboy on February 05, 2010, 08:28:58 pm
Ah i see.  Thanks for the info :)
Title: Re: Bug Reports
Post by: Iambian on February 05, 2010, 10:47:53 pm
If anything, I'd suggest creating something of a "test suite" to help you out when you're adding in new functions. Sometimes, the addition or changing of something breaks old code and you'd never really know it.

Makes me wish I spent the time on such when I was going through decking out Celtic III with all them functions. I know it's a bit of work, but it should be well worth it.
Title: Re: Bug Reports
Post by: Builderboy on February 07, 2010, 02:11:59 am
Ok i found another weird bug.  When compiling one of my programs, the compiler stops while compiling and a blinking cursor appears beneath the Compiling message.  No matter what button i press, the cursor just keeps blinking.  So i am forced to pull my batteries, but although i quit back to homescreen, there is no RAM clear O.O

I'll try to get the program uploaded in a sec...
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 07, 2010, 02:20:35 am
wow it exited quite abruptly x.x

Usually, the calc gets unstable afterward, tho
Title: Re: Bug Reports
Post by: Eeems on February 07, 2010, 02:32:37 am
I would clear your ram just to be safe builderboy.
Title: Re: Bug Reports
Post by: Builderboy on February 07, 2010, 02:33:12 am
Good idea

* Builderboy rushes off to clear Ram and save lives *

And here is that program, I don't think i was doing anything wrong O.O
Code: [Select]
:DiagnosticOff
:
:0→A
:0→B
:0→K
:
:While K≠15
:getKey→K
:
:Output(A,B,"
:If (K=3) and (A≠15
:A+1→A
:End
:If (K=2) and (A≠0
:A-1→A
:End
:If (K=1) and (B≠8
:B+1→B
:End
:If (K=4) and (B≠0
:B-1→B
:End
:Output(A,B,"O
:
:End
:
:Return

And the 8xp file in a zip for ya
Title: Re: Bug Reports
Post by: Quigibo on February 07, 2010, 03:40:49 am
Thanks for the report.

When apps exit, they need special exit code so that what you're describing doesn't happen.  It sounds like there was a memory leak somewhere causing the app to exit early.  That's why it didn't reset the ram, because it wasn't actually frozen.  I'll let you know when I find the leak.  Thanks again.

EDIT: Okay found it.  Wow, that was a stupid mistake on my part.  To get around the error temporarily until the next version, don't use parenthesis in any place where they are not needed; if the order of operations is naturally going left to right anyway.  The compiler is supposed to ignore the parenthesis when you do this, but instead it exits early...

:If (K=4) and (B≠0
Change to this:
:If K=4 and (B≠0
Since K=4 is evaluated first anyway.

If you ever get this error again, just turn off your calculator and turn it back on and the problem will go away.  Nothing in memory should be affected.  Oh actually, maybe ram clear anyway since the "LOL" file will be corrupt.
Title: Re: Bug Reports
Post by: Builderboy on February 07, 2010, 12:23:06 pm
Alright thanks ^^

I also have some bugs (well not quite bugs) with the output function.  When displaying a character/number on the bottom row, the rest of the screen is shifted up.  This would be nice if it could be turned off for output, as the scrolling migt disrupt other graphics.

My second gripe is that when displaying a single digit number at a certain location, the number doesn't actualy appear where the coordinates you specify are.  For this reason I don't think it's possible to display numbers in the left few colloms?

Just two things with output that I think might need to be changed :)
Title: Re: Bug Reports
Post by: Quigibo on February 07, 2010, 06:56:18 pm
I'll work on that.  Both of those are fixable, but I'm not sure if there's any built-in OS calls for that.  I can write my own routine, but I'm trying to make sure these programs don't use too much memory.  Luckily, the subroutine support can really cut down on size of the overall program.  Even the most basic things like this save memory:


:If 2sub(1)
:'code here'
:End
:If 3sub(1)
:'code here'
:End
:Lbl 1:<A:Return


The routine above saves 5 more bytes than if you were to use the strait forward way below.


:If 2<A
:'code here'
:End
:If 3<A
:'code here'
:End

Title: Re: Bug Reports
Post by: Eeems on February 14, 2010, 12:57:41 pm
When this code is run a first time it works fine, the second time doesn't though, it's probably due to the missing declaration on K at the beginning.
Code: [Select]
While K=/=9
getkey->K
Disp K
Disp i
End
Title: Re: Bug Reports
Post by: Quigibo on February 14, 2010, 03:04:38 pm
You are correct, the variables start uninitialized.  Assume random garbage, not 0 or something predictable.  They will be preserved between consecutive runs of the program, but running pretty much any other assembly program or app will scramble most or all of the values.  So if you embed 2 different Axe programs into a Basic program, they can pass arguments to each other via preserved variables.  But you cannot use the variables as any sort of long term storage.

In you example, the first time it runs, K was probably something random but upon exiting the program, it became 9.  So when you run the program a second time, K is already 9 so the while loop is skipped.
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 14, 2010, 11:33:58 pm
in BASIC, what I did with getkey is do 0getkey before the loop kicks in. That way if you pressed a key before the loop started, it was unregistered before loop starts, to prevent stuff such as menu option being selected automatically or cursor/character moving around by itself
Title: Re: Bug Reports
Post by: Builderboy on February 15, 2010, 01:48:37 am
Yeah that can be especially annoying when you run programs from MirageOS since it doesn't zero out the getKey, so the very first getKey call in a MirageOS basic pgoram is always [2ND] or ENTER.  This can be exploited though to detect whether or not your Basic game is being run is Mirage ;)
Title: Re: Bug Reports
Post by: Eeems on February 15, 2010, 03:10:06 pm
I tried to do this and it didn't work, is there something wrong with it?
Code: [Select]
getkey->K
X+(K=2)-(K=3)->X
Title: Re: Bug Reports
Post by: Quigibo on February 15, 2010, 03:15:53 pm
It works perfectly in 0.0.4 when I try that code.

Not sure if this might be the problem, but do realize that this:
X+(K=2)-(K=3)->X
Is not the same as this:
X+(K=2)-(K=3->X

The later will parse like this:
X+(K=2)-(K=3->X)
since store can be used inline.
Title: Re: Bug Reports
Post by: Eeems on February 15, 2010, 03:18:50 pm
hmm, strange...must have been 0.0.3 that had a problem
yeah, I tried both though...
hmm, actually I like being able to do that :P
Title: Re: Bug Reports
Post by: Builderboy on February 15, 2010, 06:35:56 pm
Hmmm it seems that Axe computes 16*16*16 as Zero :(

EDIT: It seems the multiplication system in itself breaks under certain conditions, try running this program:

Code: [Select]
0->F
While getKey!=15
Output(0,0,2*F
Output(0,1,F+F
F+2->F
Pause 100
End

Unfortunately those two expressions are not equal for all legal values of F :(
Title: Re: Bug Reports
Post by: calc84maniac on February 15, 2010, 07:08:13 pm
Hmmm it seems that Axe computes 16*16*16 as Zero :(

Its not above the maximum value right?  Maximum for real numbers is 2^16 665536 if i remember correctly...
Yeah, that should come out to 4096 (which is less than 65536).
By the way, Quigibo, do you (or are you planning to) simplify expressions that use constants like that?
Title: Re: Bug Reports
Post by: Eeems on February 15, 2010, 07:52:24 pm
Hmm, addressing the screen shifting problem with output(), are you using a bcall? If you are, I think _putMAP fixes the screenshifting problem.
Title: Re: Bug Reports
Post by: Quigibo on February 15, 2010, 09:19:20 pm
My bad!  The multiplication algorithm was incorrect, I had to change a z flag to an nz flag.  Sorry!  Until I update with the fix, you will not be able to multiply if either argument is larger than 255.

I am planning on optimizing the multiplication/division/modulo for constants as well as for equalities, bit operations, and other things.  I was still a little busy today though so I just wanted to get the update released on time so I'll do that later.

_putMAP would work, but that's how Text( will operate, so there wouldn't be a purose to having two commands that do the same thing.
Title: Re: Bug Reports
Post by: Eeems on February 15, 2010, 09:23:40 pm
Yay!

Ah..well...no text will be _VPutMap right?
Title: Re: Bug Reports
Post by: Quigibo on February 16, 2010, 01:06:47 pm
Oh I'm sorry, I forgot about the differences.  I meant _VPutMap will be for Text().

I think there is a flag I can set to not auto-scroll the screen for the Output() command.  I'll have to do more testing.
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 16, 2010, 02:09:07 pm
In TI-BASIC, Output( command woN't scroll the screen, even if the string is longer than 128 characters. Only Disp does, when you display something on the 8th row.
Title: Re: Bug Reports
Post by: ztrumpet on February 16, 2010, 04:20:42 pm
TextScrolled(2) TextFlags(5)  - Text display caused screen to scroll

Would this be the right flag?
Title: Re: Bug Reports
Post by: Eeems on February 16, 2010, 04:21:27 pm
yeah, well _PutMap will do the homescreen, and it will not scroll.
Title: Re: Bug Reports
Post by: calc84maniac on February 16, 2010, 06:01:55 pm
yeah, well _PutMap will do the homescreen, and it will not scroll.
The problem with this is that you can only output one character that way.
Title: Re: Bug Reports
Post by: Eeems on February 16, 2010, 06:10:56 pm
really? :/ that sucks...
Title: Re: Bug Reports
Post by: Eeems on February 19, 2010, 12:37:48 am
I have encountered what I think is an improper handling of the text shadow on clrHome
Code: [Select]
output(2,2,"hi
clrHome
run that then open a menu and close it again. When you close it 'hi' will show up again...
Title: Re: Bug Reports
Post by: Builderboy on February 19, 2010, 02:29:25 am
Code: [Select]
#^rand->A
throws a BAD SYMBOL error on compilation :(
Title: Re: Bug Reports
Post by: Quigibo on February 19, 2010, 02:12:15 pm
The text shadow is not cleared when you do ClrHome.  I was thinking of adding that to the routine, maybe I will next time.

I'll look into the problem with ^rand.
Title: Re: Bug Reports
Post by: Eeems on February 19, 2010, 04:15:55 pm
Ah ok I thought so...the text showing up again is kind of getting annoying. how much bigger would the routine be if you added that? you could add a routine for clearing the text shadow, and one for displaying it or something...that would be kind of interesting being able to play around with the text shadow and the graph buffer....
Title: Re: Bug Reports
Post by: ztrumpet on February 19, 2010, 10:08:12 pm
Ah ok I thought so...the text showing up again is kind of getting annoying. how much bigger would the routine be if you added that? you could add a routine for clearing the text shadow, and one for displaying it or something...that would be kind of interesting being able to play around with the text shadow and the graph buffer....
That sounds really cool!  I want a ClrTxtShad command now... ;D
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 19, 2010, 11:03:54 pm
It would obviously be another command, tho :P, I am curious which in TI-BASIC...
Title: Re: Bug Reports
Post by: Quigibo on February 20, 2010, 12:37:42 am
No, I think I'll just add it to ClrHome.  Its only 3 additional bytes I think.  That would bring the total size of the ClrHome command to 12 bytes each call.  This is over my limit of 10 bytes for an inline command, so I will optimize it to be a subroutine so it will actually be 18 bytes the first time its called, but only 3 bytes every additional time you call it.

There isn't really much interesting you can do with the text shadow.
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 20, 2010, 12:44:30 am
Aaaaah ok I see, I guess it should be fine. 3 bytes seems a bit big though for ClrHome o.O, considering in TI-BASIC it's one single byte :O

Unless you mean 3 byte before compiling?
Title: Re: Bug Reports
Post by: Eeems on February 20, 2010, 12:56:22 am
No he means the routine to call it due to how it has to call the spot (call location). ASM does not have the luxury of one byte per instruction unfortunatly...
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 20, 2010, 01:40:13 am
aaah ok x.x
Title: Re: Bug Reports
Post by: Quigibo on February 20, 2010, 03:03:50 am
False.  In BASIC, its actually 2 bytes since you have to include the [Enter] character or the colon to get to the next instruction (I think only DelVar doesn't require this).  This type of next line character isn't needed in assembly, so its only a 1 byte difference.
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 20, 2010, 04:12:14 am
Oh wait I forgot about the linebreak/: char, and didn,t realise in ASM it wasn't needed. I guess I should, considering an ASM program in hex code doesn't appear to have linebreaks, sorry x.x
Title: Re: Bug Reports
Post by: Eeems on February 22, 2010, 09:24:15 pm
Found an error with v0.0.5a's output command.
When I try to output the value of B in my alien game it gives me garbage.
This did not happen with v0.0.4a.
Did you change the command?
Title: Re: Bug Reports
Post by: ztrumpet on February 22, 2010, 09:28:03 pm
Eeems, instead of
:Disp B
You must write
:Disp B>Dec  ([Math] [2])
It make the code smaller and faster, so it's a great (but conflicting) change. :)

*Ztrumpet ninjas Quigibo... ;D
Title: Re: Bug Reports
Post by: Quigibo on February 22, 2010, 09:29:16 pm
Yes I did.  You have to add >Dec when displaying numbers in base 10.  Otherwise, it things you are displaying the string at the location of B.  I really couldn't think of any other way to have the same command be able to display in 2 different formats since it doesn't know which one you're talking about.

Edit: ninjad'
Title: Re: Bug Reports
Post by: Eeems on February 22, 2010, 10:39:24 pm
Ah ok XP
Title: Re: Bug Reports
Post by: Eeems on February 23, 2010, 06:16:54 pm
ok, so this isn't really a bug, but it's a warning...if you run this code:
Code: [Select]
[0011223344556677]->pic1
7->D
For(C,0,50)
D+1->D
If D=8
0->D
End
For(A,0,12)
For(B,0,7)
pt-on(A*8[+D],A*8+D,pic1
End
End
DispGraph
End
(note: [+D] is optional (take out the [] ))
you will with the extra +D on the completion of the program if you go to a menu and then back to homescreen your cursor will change to a insert-2nd one, and then your calc will crash and ram clear, if you exclude the extra +D then you will brick your calc...the same thing happens but instead of a insert-2nd cursor it is a lowercase-alpha cursor. and your calc will not crash but stay on that screen, and I tried pulling the batteries (all of the AAA's) out to no avail.
I was able to fix it though by linking a classmate's 84+ to mine and sending an empty L1 to my 83+, and upon the 84+ erroring because there was nothing receiving, my 83+ on the other-hand unfroze and I was able to do things with it, although the alpha cursor was stuck on lowercase... when I didn't try to clear the ram right away it froze again, and I had to send L1 again. the second time I immediately cleared my RAM and my calc is now fixed.

tl-dr;
don't display sprites off of the screen on the bottom, or to the right by 8 and then quit out of the program, bad things happen...
Title: Re: Bug Reports
Post by: Quigibo on February 23, 2010, 07:05:52 pm
Right, I haven't clipped the sprites yet, so that means it actually draws the sprite into the memory immediately after the buffer which contains a lot of important information the calc needs...  so it will corrupt that data and do a RAM clear most likely.  Might be fixed in the next version.
Title: Re: Bug Reports
Post by: Eeems on February 23, 2010, 07:13:47 pm
yeah, I figured that out...and wow that was some bad corruption x.x
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 23, 2010, 07:16:04 pm
sprite clipping is something I would like to have personally. It makes it easier to code certain engines. Make sure clipping also does all 4 screen sides. xLIB used to not do the upper side and instead gave RAM Clears x.x
Title: Re: Bug Reports
Post by: Builderboy on February 23, 2010, 07:40:09 pm
Most definetaly, as of now in the program i'm writing i needed to take super special extra care that the object didn't go one pixel off the screen, and there are going to be cases where you are going to want that anyway, like for smoothscrolling maps and such :/
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 23, 2010, 07:50:25 pm
I think i lost Metroid II progress 4 times due to accidentally displaying stuff outside of the screen x.x
Title: Re: Bug Reports
Post by: ztrumpet on February 23, 2010, 09:38:05 pm
Wow. 
So far I've cleared my ram twice (infinite loops, pulled battery) and corrupted a group with Axe (but I have no idea how).  :P

I'm liking Axe, but not the annoying glitches.  Axe is still awesome! ;D
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 23, 2010, 09:40:31 pm
glitches are inevitable really, with most apps. To say it's even possible to crash a calculator without any ASM...
Title: Re: Bug Reports
Post by: Quigibo on February 23, 2010, 10:17:38 pm
You guys all complain about "RAM clears" and "corrupted memory".  Have you ever tried to program in assembly?  There are so many leaks and corruptions that happen, not to mention all the frustration of trying to find logical errors in the code, that almost all ASM programmers run their works in progress on emulators just in case and to speed up the process.  I can guarantee that if you tried to make the same program in assembly (unless you're highly experienced with it), you would have had at least an order of magnitude more problems with the code.

Remember, me giving you the freedom to run lower level assembly code and commands is a trade-off with the safety of running it.

Now, if you get an unexpected error either at compile time or at run time, I really need to know about that so I can fix it.  I currently am aware of 2 mysterious bugs.  One is that the compiler sometimes gives a random error if the program was just modified but parsing a second time always works.  I have no idea what is causing that.  Another error mysteriously vanished when I added some code unrelated to the error, so it will probably come back to haunt me sometime.  I think it had something to do with automatic parenthesis in math operations.
Title: Re: Bug Reports
Post by: Builderboy on February 23, 2010, 10:29:47 pm
Mmmmmm i think i had that happen to me once.  I got an Error Block on one of my programs after transferring to wabbit, but then it went away after trying it again.  I wonder if changes are being made to the app or program?  Seems unlikely, must be something else, and i don't pretend to be an expert in the ways of Asm

And thats a good point about the RAM clears ;D Us Basic programmers are used to other things, so you'll just have to put up with our complaints for the time being :P Plus its still an alpha release, and an untested one at that. 
Title: Re: Bug Reports
Post by: Eeems on February 23, 2010, 11:17:45 pm
Ug...tell me about it...I had some of the worst memory leaks on hunt, and it took me forever to fix them x.x
the random error tat isn't an error usually comes up with me if prgmLOL is exsisting, so deleting it before compiling will usually keep it from happening, but sometimes it won't.
Hmm, how hard would it be to add something that when it errors it tells you what line it's on?
Title: Re: Bug Reports
Post by: Builderboy on February 23, 2010, 11:31:57 pm
Hmm, how hard would it be to add something that when it errors it tells you what line it's on?

Ah, yes that would be very useful!  Many a times i have gone editing to try to find out what was causing the problem.
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 23, 2010, 11:34:50 pm
You guys all complain about "RAM clears" and "corrupted memory".  Have you ever tried to program in assembly?  There are so many leaks and corruptions that happen, not to mention all the frustration of trying to find logical errors in the code, that almost all ASM programmers run their works in progress on emulators just in case and to speed up the process.  I can guarantee that if you tried to make the same program in assembly (unless you're highly experienced with it), you would have had at least an order of magnitude more problems with the code.

Remember, me giving you the freedom to run lower level assembly code and commands is a trade-off with the safety of running it.
Oh I do know in ASM it is worse. I did not code it, but I do know in ASM you have direct access to the calc memory, thus easier to break stuff. It is even possible to delete the calc OS sending certificate IIRC, causing it to no longer be able to receive a new OS anymore, so if your OS gets deleted, your calc is bricked for good. However we still have a right to complain as lib-enhanced BASIC/other languages programmers because in our case, we program directly on the machine the program is gonna be tested on, meaning that unlike you, if our program crashes, we lose everything we didn't backup. It may be much easier for us to debug these errors, but at least on your side you don't have to backup your progress everytime they happen. In BASIC we also have to cope with rare TI-OS bugs that causes some BASIC programs to behave weirdly for absurd reasons (such as lone If statements inside a For( loop that doesn't have its closing parhentesis or when storing a very large set of concatened strings in one STO command). Fortunately, in pure-BASIC we no longer have to deal with extremly bad OS bugs that can cause RAM Clears such as when having a large PRGM list on OS 1.13 and the Equ>String glitch.
Title: Re: Bug Reports
Post by: ztrumpet on February 24, 2010, 04:31:06 pm
Since it's such an early release then I'm fine with lots of errors now.  However, when you come out with a full version I think it should be close to error free because some people will get a RAM Clear and never us Axe again.

I've gotten a lot of Err:Blocks randomly, so I just would open the source, look for a glitch, change something irrelevant, and recompile. :P

Could you add a "Where is this glitch" feature? :)
Oh, and can you add the Axe Header to all source files so we don't have to comb through our huge lists?  Thanks! :D (This is a big one for me, as I have to hold down for about 45 seconds before I get to my programs in RAM.) ;D
Title: Re: Bug Reports
Post by: Builderboy on February 24, 2010, 05:38:40 pm
Yeah I know what you mean, especialy since newer programs tend to be at the bottom of the list XD
Title: Re: Bug Reports
Post by: Galandros on February 24, 2010, 05:58:05 pm
Even with a stable release with no bugs, some bad coding leads to bad errors in the assembly code created. Some may not be easy to spot by BASIC programmers...

We should do some documentation to BASIC programmers in order to avoid most errors and advice to backup more times to other calc or pc.
Assembly knowledge is advantageous in programming Axe Parser... A in-depth documentation of the Axe Parser conversion to assembly can benefit who knows assembly to better code in Axe.

Quigibo, why not start to code Axe Parser compiler with some Axe Parser? :D How do they compile compilers, eh?

 Have you ever though about it?
Title: Re: Bug Reports
Post by: Quigibo on February 24, 2010, 06:25:27 pm
Yeah, I could, but it would be so inefficient.  That would be like a BASIC programmer trying to make a compiler for assembly language programs, which I have seen done before, but its very slow.  However, I could just cheat and the whole program would just be asm([hex code of entire program]) That would work ;)

Safety features will come in due time.  I'm kind of in that awkward phase where the next version about to come out has enough features to compile nearly any type of game you can think of, yet I still don't have a GUI (even the list of programs is awful because of the scrolling and such), no safety features like archiving the ram before testing the program, or a compiler options menu for things like 15MHz mode options.  And there are still hundreds of commands I still have to add!

I promise.  After the next release, Axe Parser will become 0.1.x and make more of those changes instead of new commands and such.
Title: Re: Bug Reports
Post by: ztrumpet on February 24, 2010, 09:13:16 pm
Awesome!  This sounds really nice.  You've done a great job already.  :D

(I'm fine with however you want to code it, weather you work on the GUI or the commands.  I'm happy as long as you're working on this. ;D )
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 24, 2010, 11:55:46 pm
Suggestions for safety features: it might be nice that if you plan to have some added inside the compiled programs so if they contain errors that are undetectable during compiling that you allow the programmer to decide if he wants such error checks added or not in his program, because this might slow the program down and once the entire game is finished, such error checks may no longer be needed
Title: Re: Bug Reports
Post by: Builderboy on February 28, 2010, 10:46:43 pm
Ok i'm getting this weird thing happening during compilation.  about 80% the way through each pass the message changes from '1st Pass' to '65534ass' and i have to press a key to make the counter advance O.o.  It does seem to compile fine though after it finishes.  Should i upload the source that was making it act weird?
Title: Re: Bug Reports
Post by: Eeems on February 28, 2010, 11:00:49 pm
Is it like that with only one thing or all of the programs you try to compile?
Title: Re: Bug Reports
Post by: Builderboy on February 28, 2010, 11:07:54 pm
Only that program and I cant find out whats so unique about it...

Here I'll post it in a sec...

EDIT: Here it is, my work in progress for a tilemapper
Code: [Select]
:For(F,0,383
:¦ rand^3→{L1+F}
:End
:[FFFFFFFFFFFFFFFFFF818181818181FF0000000000000000]→Pic11
:
:0→X
:0→Y
:0→K
:While K≠15
:¦ getKey→K
:¦ X+1→X

:¦ ClrDraw
:¦ For(A,0,11
:¦ ¦ For(B,0,7
:¦ ¦ ¦ 24*(Y/8+B)+(X/8+A)→N
:¦ ¦ ¦ Pt-On(8*A-(X^8),8*B-(Y^8),8*{L1+N}+Pic11
:¦ ¦ End
:¦ End
:¦ DispGraph
:
:End
Title: Re: Bug Reports
Post by: Eeems on February 28, 2010, 11:39:56 pm
Could it be calling the L1 pointer?
Try making something that calls it and see if it works or not. He might have left something in the code that he shouldn't have.
Title: Re: Bug Reports
Post by: Builderboy on February 28, 2010, 11:51:17 pm
Ok found the problem code, its when you multiply a value by data read from RAM

Code: [Select]
0->{L1}
8*{L1}->A

Gives a very weird happening.
Title: Re: Bug Reports
Post by: calc84maniac on February 28, 2010, 11:52:40 pm
Ok found the problem code, its when you multiply a value by data read from RAM

Code: [Select]
0->{L1}
8*{L1}->A

Gives a very weird happening.
What happens if you put parentheses around the braces?
Title: Re: Bug Reports
Post by: Builderboy on February 28, 2010, 11:58:44 pm
Yay it fixed, didn't think of that :P Its interesting that it doest pose a runtime problem, but a compiling problem.
Title: Re: Bug Reports
Post by: calc84maniac on March 01, 2010, 12:07:31 am
Yay it fixed, didn't think of that :P Its interesting that it doest pose a runtime problem, but a compiling problem.
Well, {L1}*8 would be more optimized anyway :)
Title: Re: Bug Reports
Post by: Builderboy on March 01, 2010, 12:35:42 am
Haha, i guess so, although i don't understand why.  You asm-erz and your weird optimizations :P
Title: Re: Bug Reports
Post by: calc84maniac on March 01, 2010, 12:52:18 am
Quigibo, >Frac doesn't work properly. You are trying to pass HL as the argument to _putc instead of A. I suppose you got lucky with your example program because the value loaded from memory was already in A or something.
Title: Re: Bug Reports
Post by: Quigibo on March 01, 2010, 01:56:05 pm
Oops!  I forgot about that.  Its really weird it worked for all the examples I tried it on... fixed it now.

Also, I noticed an error when you try to use a subroutine in an if statement it causes the program to freeze sometimes.  Let me know if anyone else gets this error, I'm trying to fix it.
Title: Re: Bug Reports
Post by: Quigibo on March 06, 2010, 02:12:46 pm
I found the annoying mysterious bug!

Apparently, as the assembly executable is being written and expanded, the other programs in the VAT start moving around to make room for it.  Sometimes, the source file is one of those files which means that the location it was reading from suddenly switches to some other program or random garbage.  I tried to make it use the symbol table to keep track of the pointer instead, but it turns out even the symbol table rearranges itself.  So I have no idea how to fix this.  I remember there was a bcall called "EditProg" or something that was supposed to allocate the program so that things don't switch around, but I was never able to get it to work.  Do any of you assembly programmers know how it works or another way around this?
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 06, 2010, 02:33:26 pm
ouch I hope there is a solution x.x
Title: Re: Bug Reports
Post by: ztrumpet on March 06, 2010, 05:34:54 pm
Nice find!

There is a solution, (There has to be one) and good luck finding it! ;)
Title: Re: Bug Reports
Post by: Builderboy on March 06, 2010, 06:42:38 pm
Wow the TiOS is annoying D:

So even while the App is running the TiOS is still taking care of all the VAT structure and things?  Or are you calling OS routines to write the program? O.o
Title: Re: Bug Reports
Post by: Quigibo on March 06, 2010, 06:49:26 pm
I'm calling routines that use the VAT to expand the memory, that's why.  But I don't really know enough about how the OS structure works to write those routines myself so I have to use them.
Title: Re: Bug Reports
Post by: Quigibo on March 09, 2010, 12:04:02 pm
FINALLY!  I fixed it!  I've learned that there are 3 types of lies: Lies, Damn Lies, and the TI Developer's Guide.  It clearly stated that I was not supposed to update the program size because its done for you with CloseProg but this was exactly the opposite of the case.

And I also noticed that 95% of the time spent parsing was actually going into displaying the progress.  So now, it only displays the progress 1/256th of the time so it can parse about 5000 bytes of source per second on SE/84+.  The example programs can almost instantly be compiled now.
Title: Re: Bug Reports
Post by: ztrumpet on March 09, 2010, 12:16:09 pm
Awesome!  I will really enjoy the speed gain! ;D

Did you know that if you send prgmLOL to another calc and then send it again you can't rename prgmLOL.  Try it. (This also works for ungrouping)

Can you fix that?  Even when we can name the programs in Axe, it would still be nice to be able to rename them without re compiling them. :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 09, 2010, 03:55:05 pm
FINALLY!  I fixed it!  I've learned that there are 3 types of lies: Lies, Damn Lies, and the TI Developer's Guide.  It clearly stated that I was not supposed to update the program size because its done for you with CloseProg but this was exactly the opposite of the case.
lol nice one :P

But yeah it's TI x.x so I guess this can be expected sometimes, knowing them more, now x.x


Also glad to hear about the progress speed. I noticed it was a bit slow but thought it was cuz of the calc. Glad you fixed the bugs :D
Title: Re: Bug Reports
Post by: Eeems on March 09, 2010, 04:10:18 pm
YAY! can't wait for the next release now :P
Title: Re: Bug Reports
Post by: _player1537 on March 10, 2010, 12:07:00 am
on my calculator (a ti 84+SE) the newest version of axe (v.1) doesn't show any programs.  I ran it on an emulator and they showed up.  I did a ram reset and they still didn't show up either.

Also, I love this program, excellent job :)

-player
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 10, 2010, 12:34:45 am
Wow first time I hear about this issue x.x, I wonder if it could be a hardware issue?

Else did you try resetting your calc memory (RAM and archive) and reinstalling the OS?

@everyone: this is not an extra RAM page issue btw cuz his calc ends with the letter F.
Title: Re: Bug Reports
Post by: Builderboy on March 10, 2010, 12:58:02 am
And I also noticed that 95% of the time spent parsing was actually going into displaying the progress.  So now, it only displays the progress 1/256th of the time so it can parse about 5000 bytes of source per second on SE/84+.

Wow!  Any chance of a mid-week release? :D That sure would be useful for compiling Portal, it takes a fair ammount of time right now, about 35-45 seconds, not counting when the random errors occur.
Title: Re: Bug Reports
Post by: Quigibo on March 10, 2010, 01:52:01 pm
Yeah, I'm thinking about it.  Maybe tonight I'll have an early release ready, but then I won't have much to add on Sunday.  By the way, I also have support for parsing archived programs working now without having to unarchive them, giving you the entire free ram to build programs.

@_player1537
That sounds really weird.  Is it only specific to v0.1.0 or did it not work in v0.0.6 either?  If it works on neither of them, then I would recommend you back up all your files onto the computer and reset your archive as well as your ram.  I will need more information to figure out why it doesn't work.  Are you using an external app for file management with folders?  Are the programs in archive or ram and are they hidden or protected?
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 10, 2010, 02:42:17 pm
Wow that's nice. Does it write directly to the archive? I heard this was one challenging thing to do in ASM (to write directly to archive). I guess you could have a release tomorrow then wait for the 21th for next one :P

Also, idk if it was in your plans, but some people on IRC, including even a Ticalc.org file archiver, are recommending that you upload a build on ticalc.org soon, because of the growing interest toward Axe and the fact it might interest/attract a lot of users from there. The reason being mostly due to everything Axe Parser can do so far.

IIRC _player tried both 0.06 and 0.1, according to IRC logs. However, he has yet to attempt a full memory reset (and an OS reinstall if it fails).
Title: Re: Bug Reports
Post by: calc84maniac on March 10, 2010, 03:12:24 pm
I think he meant that you can archive your source file so there is more RAM free to compile programs.
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 10, 2010, 03:35:06 pm
Oh wait yeah, I understand now. I guess that would help a lot, though, because right now, assuming a Axe compiled game is 2x larger than the source, this means your games cannot be larger than 8 KB in source form (8 KB for source plus 16 KB for compiled version would fill the entire RAM)
Title: Re: Bug Reports
Post by: Quigibo on March 10, 2010, 05:53:39 pm
That's right.  Maybe I will have an early version up on ticalc when it gets a little more cleaned up (like naming files).  The 0.2.0 build I'll for sure add to the archives since after that point I'll mostly just be adding commands rather than integral features.
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 10, 2010, 11:57:00 pm
Sounds like a good deal. I might add it on Omni download section, too, but since there is alerady a topic full of releases, I will probably also link to your topic from my file description so people can get new versions easier.

Either way, can't wait for new versions ^^
Title: Re: Bug Reports
Post by: Builderboy on March 10, 2010, 11:58:55 pm
Did you get the new version?  He just released version 0.1.1 early and tis awesome ^^
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 11, 2010, 01:31:25 am
Lol yeah I just saw this after posting this, didn't expect it to be this soon ^^

I only didn't edit my post because there were so many new posts :P
Title: Re: Bug Reports
Post by: calc84maniac on March 14, 2010, 02:52:23 pm
The optimization guide has some errors... any expressions with VAR should be one more byte than the expressions with CONST, because ld de,(xxxx) is a 4-byte opcode.
Title: Re: Bug Reports
Post by: Quigibo on March 14, 2010, 05:15:40 pm
Oh yeah, I keep forgetting about that... I'll update it thanks.
Title: Re: Bug Reports
Post by: Builderboy on March 14, 2010, 05:26:35 pm
I actually got an interesting 1 time bug when i first downloaded 0.1.1. It said BAD HEX when i tried to compile Portal, but then after i unarchived it it started working, and has worked ever since, even when archived O.o
Title: Re: Bug Reports
Post by: calc84maniac on March 14, 2010, 07:26:59 pm
I actually got an interesting 1 time bug when i first downloaded 0.1.1. It said BAD HEX when i tried to compile Portal, but then after i unarchived it it started working, and has worked ever since, even when archived O.o
Maybe it was one of those errors where the VAT entry starts in one flash page and the data is in the next page, but it wasn't properly handled. This causes programs to stop showing up in MirageOS sometimes, and some other programs might act strangely when this happens as well.
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 14, 2010, 07:29:37 pm
by strangely do you mean like on those 8x calcs with crappy LCD AKA wavy game screen?
Title: Re: Bug Reports
Post by: calc84maniac on March 14, 2010, 07:31:18 pm
by strangely do you mean like on those 8x calcs with crappy LCD AKA wavy game screen?
Nah, I just mean errors when trying to read the file from archive.

Edit:
Here's an example: http://www.revsoft.org/phpBB2/viewtopic.php?p=11994#11994 (http://www.revsoft.org/phpBB2/viewtopic.php?p=11994#11994)
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 14, 2010, 07:48:56 pm
aaah ok I see. I hope this cannot last too long sometimes, like requires 100 tries x.x
Title: Re: Bug Reports
Post by: cooliojazz on March 15, 2010, 11:00:29 pm
Ok i'm getting this weird thing happening during compilation.  about 80% the way through each pass the message changes from '1st Pass' to '65534ass' and i have to press a key to make the counter advance O.o.  It does seem to compile fine though after it finishes.  Should i upload the source that was making it act weird?

I was getting the same thing with one of my programs that I tried to assemble, though it happened right at the start, and the first time i pressed a key to go on, the other few times it wouldn't do anything except turn off upon which, turning on the calculator, it had 0 RAM, as in NADA :P also, interesting but irrelevant info, I'm using 2.53 and the little "Press F1-F4 to access quick menu" thing popped up in all large font, therefore going off the screen...
Anyways, I deleted some of the lines which i had a hunch were causing it, and walla, it compiled!  I then retyped most of them differently, and it worked.  It was something like changing ...,{X*3+L1+1}+15,... to ...,{L1+(X*3)+1}+15,...  So,  I would like to know, is this a bug, or am I  just being stupid and breaking some axe rule?
Title: Re: Bug Reports
Post by: Quigibo on March 15, 2010, 11:20:27 pm
Uh oh.  That's my error trapper.  It automatically quits when the stack was not left where it was supposed to be, that means I have a leak.  I will look into it, but it would help if you could provide the source that gave the error.  Send me a PM or email if you don't want to show the source publicly (if its part of a secret project or something).
Title: Re: Bug Reports
Post by: cooliojazz on March 16, 2010, 09:13:56 pm
Lol, nothing secret, just an attempt to learn axe parser :P  The only thing I changed that made it compile, though, was these lines:
Code: [Select]
If {L1+(X*3)}=1
Pt-Off({L1+(X*3)+1},{L1+(X*3)+2},Pic1
End
and I don't have the original, cause i deleted those lines, but i'm 95% sure it was just like this instead:
Code: [Select]
If {X*3+L1}=1
Pt-Off({X*3+L1+1},{X*3+L1+2},Pic1
End
Title: Re: Bug Reports
Post by: _player1537 on March 17, 2010, 11:11:06 pm
Does anyone know why "X>0" makes an endless loop?
Title: Re: Bug Reports
Post by: Eeems on March 17, 2010, 11:54:25 pm
Can we have some context?
Title: Re: Bug Reports
Post by: _player1537 on March 18, 2010, 12:04:03 am
sure, I was writing a falldown game and I needed to check if Y was greater than 0, if it was greater I would subtract one from it.  So basicly
Code: [Select]
repeat F
If Y>0
Y-1-->Y
end
end
except that F is set by something and there's a couple more conditions, but they are kinda irrelevant
Title: Re: Bug Reports
Post by: cooliojazz on March 18, 2010, 12:07:05 am
umm, what sets f, i would'nt qualisfy as irrelevant, since f creates the loop...  How about you just post your whole code?
Title: Re: Bug Reports
Post by: _player1537 on March 18, 2010, 12:16:25 am
I'm sorry, I would if I could but I just lost conectivity with TI-connect, and I can't find the cd for the drivers.  I'm still trying to get that fixed.
Title: Re: Bug Reports
Post by: DJ Omnimaga on March 18, 2010, 01:44:44 am
I hate when TI connect does that x.x

Sometimes, the other day it works fine, for some reasons
Title: Re: Bug Reports
Post by: Quigibo on April 04, 2010, 04:17:06 am
The bug described here (http://ourl.ca/4050/82737) goes a little deeper than I thought.  I still haven't found it yet, but I'm almost certain what's happening is that the 2 passes the parser makes are getting out of sync.  Normally, the 2nd pass has to follow the code exactly identically to the first pass but without actually writing anything so that static pointers can be replaced with their correct locations.  When they get out of sync, the 2nd pass starts writing those pointers over the wrong locations, in this case, over a subroutine call causing the program to call some random location in memory which causes the freeze.

I haven't added many new features yet because I need to get this resolved first, just in case it would force me to change any new code.  Hopefully I will locate the exact problem tomorrow and have added enough new features for a Sunday night update.  I'll keep you all posted. Just wanted to let everyone know whats been going on.

Title: Re: Bug Reports
Post by: DJ Omnimaga on April 04, 2010, 01:54:52 pm
Mhmm, I sure hope you don't have too much issues fixing it. Some bugs can be pretty rough to fix and I know it, altough I can't imagine how much harder it must be in z80 assembly than in BASIC/RPG Maker/VB. I hope it won,t force you to get rid of features or ever rewrite the entire Axe Parser :/

Anyway good luck!
Title: Re: Bug Reports
Post by: Quigibo on April 04, 2010, 10:34:40 pm
You have no idea... I spent about 5 straight hours searching today... I couldn't find the error... and then finally... I found it, and it took 30 seconds to fix.  *face palm*  That's the worst thing about bugs.  Once you know whats wrong, its easy to fix but actually finding that bug is a nightmare, especially in a parser where you have switch statements with hundreds of arguments and tons of subroutines that are intertwined with each other so much, that a tiny change in one affects everything else.

Anyway, the resolution is a bit too complicated to explain, but the issue is resolved now.  I'll post an update late tonight.  This has been the hardest bug yet!

EDIT.
Title: Re: Bug Reports
Post by: meishe91 on April 04, 2010, 10:38:53 pm
Well I'm glad to hear it got fixed :) So Coolio's title screen should work now?
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 04, 2010, 10:44:52 pm
You have no idea... I spent about 5 strait hours searching today... I couldn't find the error... and then finally... I found it, and it took 30 seconds to fix.  *face palm*  That's the worst thing about bugs.  Once you know whats wrong, its easy to fix but actually finding that bug is a nightmare, especially in a parser where you have switch statements with hundreds of arguments and tons of subroutines that are intertwined with each other so much, that a tiny change in one affects everything else.
Yup. Sometimes it takes even longer to fix. In a school VB project I spent 10-12 hours on a bug once  and I heard people spend even more. Finally, the bug was just a little inverted < boolean logic symbol x.x. In some cases, I invert two variable storage. x.x

In assembly it must be even worse because you code on the PC then have to load everything on an emulator all the time and test programs. Good job and I hope you don't encounter too many of those bugs x.x

Another annoying bug is the kind of bug that is hard to recreate and happens randomly. It's hectic because to fix it you have to know what exactly causes it x.x. In the Reign Of Legends 3, when riding the airship on the overworld map, in some cases, when riding it on next map, you get an ERR:DOMAIN error, but it only ever happened twice to me in a matter of 4 years. Because of this I never bothered fixing it cuz I was unable to figure out x.x
Title: Re: Bug Reports
Post by: cooliojazz on April 04, 2010, 10:48:10 pm
Hopefully so :)  And Quigibo, did you ever find this (http://ourl.ca/4072/79587)?
Title: Re: Bug Reports
Post by: Raylin on April 04, 2010, 10:48:39 pm
Raylin is pleased to hear about an Axe update.
Raylin understands your plight about bugs.
Raylin remembers a time where he wrote a 3000+ line program and had to find the bug in it. It was a missing semicolon.

Raylin is talking in third person for some odd reason.
Title: Re: Bug Reports
Post by: Quigibo on April 04, 2010, 11:55:37 pm
Hopefully so :)  And Quigibo, did you ever find this (http://ourl.ca/4072/79587)?
I was never able to replicate that one unfortunately.  I assumed it was a fluke in the calculator.  If you find yourself getting that error again, I'll take a look at the source file.  I know it would be hard in this circumstance since it could freeze the parser and/or clear the ram, but you can try archiving it before parsing it so a reset doesn't delete it.

EDIT: 256th post! All my posts can be counted by a single byte!
Title: Re: Bug Reports
Post by: cooliojazz on April 05, 2010, 12:17:39 am
Well, I ran into it again with this:
Code: [Select]
For(A,0,2*{L1+X})     //Does not work
For(A,0,{L1+X}*2)     //Does work
I also ran into it in another program, gut I could never actually completely fix that one...
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 05, 2010, 01:02:00 am
strange x.x

I hope quigibo can find out about the issue
and

@him congrats on post 256 :P (btw on the old board, I think post counts were 3 bytes unsigned integers. The max post count someone could have is 8388607 and the lowest -8388608. On the new board, it's 0 minimum and 16777215 maximum, meaning 3 bytes unsigned integers
Title: Re: Bug Reports
Post by: Quigibo on April 05, 2010, 02:46:10 pm
Okay, I found it.  This one was pretty obvious.  The math subroutine replacement was being calling from a 2nd level stack and a 3rd level stack in two different places, but the routine sometimes exited specifically on the 2nd level.  Now they both call on the second level so everything is even.

A way around it until next week is to use extra parenthesis.  Like if you need to do 3*int(5) instead you can either do 3*(int(5)) or int(5)*3.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 05, 2010, 02:58:36 pm
glad to hear :)
Title: Re: Bug Reports
Post by: Builderboy on April 07, 2010, 10:22:54 am
When an error occurs during compilations, the percent complete is not always there, or its at random values that change compile to compile. 
Title: Re: Bug Reports
Post by: SirCmpwn on April 07, 2010, 10:30:37 am
^Yes.
I have noticed this, but I have just been too lazy to post about it.  Sorry.
I find that I can change a very small change in the source code fixes this.  Seriously, I could add a single, one character comment anywhere in the source code to fix this.  This solution also applies to another bug:
Sometimes, after compilation, a perfectly good bit of source code runs, then exits, without doing anything.  It can also be fixed by slightly modifying the source code.
Title: Re: Bug Reports
Post by: Quigibo on April 07, 2010, 01:56:13 pm
It only updates the % done every 255th character it reads.  When it starts counting is a random value, so yes, definitely it would change from compile to compile.  It will jump to the error in the future so you never need to rely on the percent anyway.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 07, 2010, 03:12:11 pm
By jumping to error, do you mean it will actually let you go inside the code like when selecting Goto in BASIC programs? (if it's the case, it would be nice if it used instant Goto, not scrolling from top of program to the error during 75 minutes)
Title: Re: Bug Reports
Post by: ACagliano on April 07, 2010, 03:17:12 pm
And, in your later version, to give a custom name, I open with

.ZPOKEMON
program here

And get Err. Bad Symbol
Title: Re: Bug Reports
Post by: Silver Shadow on April 07, 2010, 03:23:14 pm
The bad symbol is somewhere in your code, not in the header.
Title: Re: Bug Reports
Post by: ACagliano on April 07, 2010, 03:25:24 pm
The bad symbol is somewhere in your code, not in the header.

Ok. Your right.
Title: Re: Bug Reports
Post by: Quigibo on April 07, 2010, 08:30:21 pm
By the way, some commands currently don't like to be the very last command of the program.  I know that >Dec has a problem if its the last character in the code.  You can just add an extra [Enter] to fix it though.  If anyone finds another one of these please alert me, I am trying to fix them all.
Title: Re: Bug Reports
Post by: Raylin on April 08, 2010, 07:24:18 pm
*looks at the above post

I just ran into that problem.
Like, a few seconds ago.

O.o

I was about to blame the AppVar commands. :P
Title: Re: Bug Reports
Post by: Builderboy on April 12, 2010, 06:35:22 pm
Is this intentional?

5->{L1}->A

Now A does not hold 5, but rather the address of L1.  This just caused me a horrible debugging session until i figured it out :P
Title: Re: Bug Reports
Post by: SirCmpwn on April 12, 2010, 06:36:36 pm
I got the exact same problem before, I just forgot to mention it.
Title: Re: Bug Reports
Post by: calc84maniac on April 12, 2010, 06:37:21 pm
Is this intentional?

5->{L1}->A

Now A does not hold 5, but rather the address of L1.  This just caused me a horrible debugging session until i figured it out :P
Yeah, I asked about that earlier so I could know if I could use that for optimizations (it can be useful for post-incrementing pointers)
Title: Re: Bug Reports
Post by: Quigibo on April 12, 2010, 10:30:42 pm
Originally, it was unintentional, but it produces the smallest code.  It could return the answer, but then it adds an extra byte or 2 every time you store to a pointer.  Both ways have advantages in optimization.

You can optimize this:

A->{L1}
B->{L1+1}
C->{L1+2}

like this:

C->{B->{A->{L1}+1}+1}

So don't think that its a bad thing it returns the pointer, there are some good things you can do with it.
Title: Re: Bug Reports
Post by: calc84maniac on April 12, 2010, 10:32:00 pm
Originally, it was unintentional, but it produces the smallest code.  It could return the answer, but then it adds an extra byte or 2 every time you store to a pointer.  Both ways have advantages in optimization.

You can optimize this:

A->{L1}
B->{L1+1}
C->{L1+2}

like this:

C->{B->{A->{L1}+1}+1}

So don't think that its a bad thing it returns the pointer, there are some good things you can do with it.
I especially like being able to do things like Fill(0->{L1},15)

Edit:
Oh, and anyone who wants to use these optimizations, please note that ->{}r will return the address plus one.
Title: Re: Bug Reports
Post by: Quigibo on April 13, 2010, 02:49:43 am
Uuugggg....

I just noticed that the grayscale command is not working.  It worked fine on wabbit, but it fails on actually hardware.  Its too fast for the LCD drivers, and on Full speed mode its even worse.  I thought becasue it was grayscale that extra code would give it that time delay it needs, but damn that LCD driver is slow!  I have one of the newer 84s by the way with the slower driver.  I think the only reason Pyoro worked in gray was that I had a triple buffer, which was just slow enough for the delay.

I'll have it fixed next version.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 13, 2010, 03:40:23 am
ouch sorry to hear :(

I hope you find a solution. I guess this is a major issue when it comes to calcs without memory-mapped LCD x.x
Title: Re: Bug Reports
Post by: Raylin on April 13, 2010, 06:58:06 am
I have sympathy for you. :(

That sucks...

I also hope you find a solution.
Title: Re: Bug Reports
Post by: SirCmpwn on April 13, 2010, 05:10:24 pm
Found a bug:
You cannot divide negitive numbers.  So, this does not work:
Code: [Select]
-2→A
A/2→A

A temporary workaround is this:
Code: [Select]
-2→A
-(-A/2→A
Title: Re: Bug Reports
Post by: Quigibo on April 13, 2010, 05:15:20 pm
Wait, what do you mean "by zero"?  Anytime you divide by zero the calculator is supposed to explode! (or return -1)

I'm already aware of that the current division routine is unsigned, and purposely so.  The signed division will come soon.  You can do signed division with the "//" operator in the future.
Title: Re: Bug Reports
Post by: SirCmpwn on April 13, 2010, 05:18:44 pm
Oops, divide by anything.
My bad.  Edit now.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 13, 2010, 05:41:47 pm
Wait, what do you mean "by zero"?  Anytime you divide by zero the calculator is supposed to explode! (or return -1)

I'm already aware of that the current division routine is unsigned, and purposely so.  The signed division will come soon.  You can do signed division with the "//" operator in the future.
I thought division by zero results with Axe were >9000? :P
Title: Re: Bug Reports
Post by: Quigibo on April 14, 2010, 02:56:39 am
Okay, I've got headers working now for all shells :D

But I found a problem.  When text is displayed past the last line, scrolling the rest of the text upwards, the Mirage OS version freaks out and starts displaying the text diagonally o_O  I'm guessing that MOS is either using some other ram like the text shadow or its setting some type of weird flag before running the programs.  This makes me worried that some other commands might not work either due to this issue.

I should probably get a list of ram locations used by other shells so I can mention where NOT to write to in the documentation.  I made a screenshot of what's happening.  Does anyone know what's causing this?
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 14, 2010, 03:15:14 am
o.o

Wow,

it acts exactly like when I tried to run Galaxian in No-stub mode on OS 1.14 :O

I guess it conflicts with Mirage or something x.x, but I'm not sure. I can't help since I don't know ASM.

EDIT:

Quote
[03:10:10] <+Buckeye> DJ_Omni
[03:10:27] <+Buckeye> you should have quigibo check out appautoscroll flag
[03:10:46] <+Buckeye> mirage might unset that
[03:10:59] <+Buckeye> although im not sure if it would cause diagonal text
Title: Re: Bug Reports
Post by: Quigibo on April 14, 2010, 03:27:29 am
Yup, that was it.  I guess I'll just have to add an extra 4 bytes to shell programs to set the flag.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 14, 2010, 03:49:29 am
X.x

oh well glad it is fixable ^^
Title: Re: Bug Reports
Post by: SirCmpwn on April 14, 2010, 10:47:37 am
Could you change the sprite routine to use IonPutSprite if you are running from a shell?  Save on size?
Title: Re: Bug Reports
Post by: calc84maniac on April 14, 2010, 10:49:07 am
Could you change the sprite routine to use IonPutSprite if you are running from a shell?  Save on size?
That wouldn't be a good idea, because it would only work for XOR-logic sprites and it wouldn't have sprite clipping.
Title: Re: Bug Reports
Post by: SirCmpwn on April 14, 2010, 10:50:05 am
Ah, true.  Well, at least modify it to use the shell features whenever possible.
Title: Re: Bug Reports
Post by: Quigibo on April 14, 2010, 11:01:04 am
I think the only ion shell call I can safely use is ionRandom, but it only saves a couple bytes.  The other shells have more though.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 26, 2010, 01:49:17 pm
Not really an Axe bug I think, but you might want to update Starship to work with Axe 0.2.1 ;D
Title: Re: Bug Reports
Post by: Quigibo on April 26, 2010, 01:57:19 pm
Uh oh. :( That's really weird.  I'll go fix that, I must have changed something by mistake...
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 26, 2010, 01:59:08 pm
Wow I opened this topic, no one else was viewing it then i immediately went on board index and you alerady posted :P

Do you think it is due to a command change mistake? Or could it be a change made by mistake right inside this program?

Btw all other examples appeared to work fine
Title: Re: Bug Reports
Post by: Quigibo on April 26, 2010, 02:10:50 pm
I just tested the old version before I made some changes to the source and they both are doing the same thing, so it must be something with either a command or the way the parser compiles the code.  The only command I changed was the pixel drawing which isn't used anywhere except for drawing the stars, but I can't rule that out as a possibility.  I'll have to do some disassembly to figure out what the problem is.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 26, 2010, 02:18:10 pm
D: sorry to hear, I hope it's not a bug that's too bad x.x
Title: Re: Bug Reports
Post by: Quigibo on April 26, 2010, 10:37:24 pm
ZOMG!  That was such a lame mistake.  I forgot to update the fact that the "L1" free RAM is now 2 addresses down.  So {L1} and {L1+1} were actually pointing to the random number seed lol!  That made it randomly change the explosion byte for the first ship to think that its exploding.

Strangely, I just so happened to notice another bug that sometimes doesn't let you parse comments when there are user variables in the comment.  Fixed that too.

I'll edit the update shortly to correct these.  Thanks so much for pointing this out!
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 26, 2010, 10:48:55 pm
Lol nice, sometimes we do some strange mistakes ;D nice you fixed it tho.

I assume this will be 0.2.1b?
Title: Re: Bug Reports
Post by: Builderboy on April 26, 2010, 10:55:49 pm
Lol, so where can we find this random number seed?  Does that mean that we can seed our random numbers? O.O
Title: Re: Bug Reports
Post by: Quigibo on April 26, 2010, 11:00:33 pm
No, the random number generator uses 3 levels of random.  First it uses a seed.  Then it reads a whatever memory location that seed points to and integrates that into the number, then it checks the "r" register which is kind of like a timer and adds that to the mix.  So seeding is rather pointless.

But yes, you can retrieve the last random number generated like this: {L1-2}r
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 26, 2010, 11:06:44 pm
oh that's nice to know ^^
Title: Re: Bug Reports
Post by: Builderboy on April 26, 2010, 11:08:40 pm
Oooh thats nice to know, that way you dont have to store random values, you can just call the random function and then use {L1-2}r
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 27, 2010, 12:49:28 am
I think I found a bug:

Repeat Z=54 or Z=15
Getkey->Z
End

For reference, 54=2nd and 15=CLEAR. With this code, pressing 2nd will do nothing, but with CLEAR it will work fine.

I got stuck in an endless loop once earlier due to this, altough I group every 30 second :P
Title: Re: Bug Reports
Post by: Builderboy on April 27, 2010, 12:51:56 am
Its because the expression isn't evaluated the way you think it is, right now it is this

((Z=54) Or Z) = 15

because expressions are evaluated left to right.  Try adding a single ( right here

Z=54 or (Z=15
Title: Re: Bug Reports
Post by: Quigibo on April 27, 2010, 12:53:24 am
I think you're just missing the parenthesis.  You need them for logic operators, at least on all the arguments after the first one.

Z=54 or (Z=15)

Edit: Ninja'd!  Unrelated: Why isn't there a delete post button?  I usually see them on other boards if your post is the last one in a topic.
Title: Re: Bug Reports
Post by: Eeems on April 27, 2010, 01:08:37 am
Hmm, strange...I have a delete button, but then again I have one for every post. It mggt be a problem with this board's settings.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 27, 2010, 02:46:32 am
I think you're just missing the parenthesis.  You need them for logic operators, at least on all the arguments after the first one.

Z=54 or (Z=15)

Edit: Ninja'd!  Unrelated: Why isn't there a delete post button?  I usually see them on other boards if your post is the last one in a topic.
oh thanks I forgot about parhentesises for that x.x

As for delete button I should look into that later. I think only staff can do it atm.
Title: Re: Bug Reports
Post by: Quigibo on April 27, 2010, 11:19:08 pm
Just noticed that the signed routines are not working for any command where the unsigned version is auto-optimized.  Right now, its only //2, //128 and //256 I think.  I forgot that they need slightly different auto-optimizations.  Just wanted to report that in case anyone is having problems with this.
Title: Re: Bug Reports
Post by: DJ Omnimaga on April 27, 2010, 11:40:31 pm
Oooh ok, thanks for pointing out ^^
Title: Re: Bug Reports
Post by: Quigibo on May 04, 2010, 12:40:14 pm
I just noticed a really stupid mistake on my part.  I accidentally was checking for a right bracket "]" instead of a brace "}" for the pointers.  I just updated with the fixed file, so if you downloaded 0.2.2 before this post, you'll want to re-download it.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 02:13:23 pm
hehe that happens x.x

I did not download it, though, I'Ll do it now and recompile my tunnel game. I wonder what'll be the size difference. I might re-check my code for more optimizations too.
Title: Re: Bug Reports
Post by: Raylin on May 04, 2010, 02:21:10 pm
Also...

AXECOUNT no longer compiles. (ERR: BAD SYMBOL).
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 03:14:14 pm
Same for my Axe Tunnel clone :/

ERR:BAD SYMBOL at random percentages (examples, first attempt 34%, 2nd 43, 3rd 67, etc. It's never the same everytime)

Program compiled perfectly under 0.2.1 and 0.2.1b:
Quote from: BASIC Code
:.DJTUNNEL Axe Parser Tunnel clone
:"vDJTUNNHS"→GDB1
:UnarchiveGDB1
:[80C0E0F0E0C08000→Pic1
:"AXE TUNNEL"→Str2
:"2010, by DJ Omnimaga"→Str3
:"SPEED:"→Str4
:0→D→P+1→S+1→Q→K
:5→J
:8→C+1→R
:29→I+1→A
:40→W→T
:Full
:DiagnosticOff
:ClrHome
:ClrDraw
:For(Z,9,21
:Line(0,Z,95,Z
:End
:Line(0,56,95,56
:StorePic
:ClrDraw
:For(Z,8,22
:Line(0,Z,95,Z
:End
:For(Z,56,63
:Line(0,Z,95,Z
:End
:DrawInv
:Fix 5
:Fix 1
:Text(20,12,Str2
:Fix 0
:Text(14,57,Str3
:Fix 3
:Text(5,35,Str4
:Repeat Z=54
:DS<(K,12)
:DispGraphr
:End
:DS<(J,11-(S*2))
:Pt-Change(I,35,Pic1)
:I+1→I
:If I=86
:29→I
:End
:End
:getKey→Z
:If Z=15
:1→S
:Goto GO
:End
:Z=3-(Z=2)+S→S
:If S=6
:5→S
:End
:!If S
:1→S
:End
:End
:ClrHome
:ClrDraw
:For(Z,10,50
:Line(0,Z,95,Z)
:End
:Repeat W=6 or getKey(15)
:P+S→P
:DS<(C,8)
:rand^2*2-1→D
:End
:R+D→R
:!If R
:1→R
:End
:If 62-W<R
:62-W→R
:End
:A-getKey(4)+getKey(1)→A
:Pt-Change(0,A,Pic1)
:Line(95,R,95,R+W)
:DS<(Q,S)
:DispGraph
:If pxl-Test(0,A) or pxl-Test(0,A+6)
:Goto GO
:End
:End
:Pt-Change(0,A,Pic1
:Horizontal-
:DS<(T,99)
:W-1→W
:End
:End
:Lbl GO
:getKey
:Fix 4
:Fix 2
:ClrHome
:If P
:Output(0,0,"Score:",P►Dec
:End
:GetCalc(GDB1)→M
:If M
:If P>{S*2+M-2}r
:P→{S*2+M-2}r
:End
:Else
:GetCalc(GDB1,10
:GetCalc(GDB1)→M
:P→{S*2+M-2}r
:End
:Output(0,1,"SPEED HIGHSCORE
:For(S,1,5
:Output(0,S+1,S►Dec,"     ",{S*2+M-2}r►Dec
:End
:Output(0,0
Generated by SourceCoder (http://www.cemetech.net/projects/basicelite/sourcecoder.php), © 2005 Cemetech (http://www.cemetech.net)
Title: Re: Bug Reports
Post by: Raylin on May 04, 2010, 05:49:54 pm
Is the BAD SYMBOL random? Is there a remedy for this kind of thing or am I too stupid to see the obvious?
I even redownloaded the AXECOUNT program and tried to recompile it.
It still failed.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 05:53:33 pm
it's random. It happens every compiling attempt, just not at the same %
Title: Re: Bug Reports
Post by: Quigibo on May 04, 2010, 06:17:32 pm
Hmm... I'll look into this.
Title: Re: Bug Reports
Post by: Raylin on May 04, 2010, 06:24:22 pm
Quigibo, on a scale of 1 to 10, how solid is this engine?

10 being a hole-free engine and no spaghetti code. (Optimized doesn't matter.)
Title: Re: Bug Reports
Post by: Quigibo on May 04, 2010, 06:27:47 pm
I'd say maybe 6.  There are a few places I pull some messy tricks, and not everything is templated yet, but its much better than before for sure.

LOL! The bug was exactly the same as last time!  I found another place I was checking for a bracket instead of a brace.  I have to memorize which one is which x.x.  I'm re-uploading right now.  You'll have to re-download it again.  I'm sorry guys!

EDIT: Okay, try it now.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 06:41:49 pm
Do you write down some notes while coding? Sometimes it's a good practice to do so, even if on paper. It can help a lot when your code gets very huge, along with the comments inside the code.
Title: Re: Bug Reports
Post by: Quigibo on May 04, 2010, 06:45:57 pm
Yeah, every single subroutine I have I list the input, output, flag states, and sometimes a description of what should happen.  It wasn't like that before this update though becasue before, I had only done this to about 50% of the subroutines.  Now its about 90%.  Does the new version compile your code alright?
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 06:48:00 pm
post

EDIT: Nvm the 0.2.2 post was edited. I am used to new post every update XD

I'll put new version on my calc later

EDIT 2: UPDATE! It worked! My program also shrunk by 1 byte :P
Title: Re: Bug Reports
Post by: Builderboy on May 04, 2010, 11:00:29 pm
It might be worthy to note that writing to L2 while in MirageOS crashes your calc :( Maybe it should throw an error when compiling for Mirage?
Title: Re: Bug Reports
Post by: Quigibo on May 04, 2010, 11:14:24 pm
I'll put a note in the readme, that's a good idea.  But I won't block its usage because it might be useful for programs that need to change MOS variables as part of the program.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 11:19:08 pm
It might be good to put a warning about Mirage using that, but again I'm not sure. What would be the right code to use to prevent such crash from happening upon exiting the game?
Title: Re: Bug Reports
Post by: Builderboy on May 04, 2010, 11:22:39 pm
For me the crash happened immediately, not just when exiting the program, which is weird o.O what is Mirage doing during execution? And why is it that Mirage can run any asm program that fits in RAM but the TiOS can only run up to 8126 bytes?
Title: Re: Bug Reports
Post by: Quigibo on May 04, 2010, 11:31:15 pm
Mirage sets up an interrupt table with it's own interrupt routine.  So if you happen to write over that, bad code can execute in the middle of your program whenever an interrupt is called.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 11:35:14 pm
Ouch x.x

bad, then. And I used L2 sometimes x.x

Are others safe in Mirage, though?
Title: Re: Bug Reports
Post by: Quigibo on May 04, 2010, 11:37:37 pm
Yeah, all other areas are safe from mirage, but may not be safe for other things.  All of those specifics are documented in the commands list.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 04, 2010, 11:47:11 pm
Yeah I know about those. I try to be careful to which one I choose before storing stuff. If I don't need the buffer, I might go use L6 sometimes, for example. I just need to clear the buffer afterward.

I love how Axe lets you manipulate some memory stuff like you would do in ASM but without having to learn about the whole ASM syntax and register stuff. In other words, you can do some stuff as easily as TI-BASIC, and for the more advanced stuff, it's still easier than ASM, and you end up with speed as fast (or close) as ASM for a lot of stuff.

Btw:

[23:50:08] <+calc84> Asm(ED56) should fix that
[23:50:14] <@DJ_Omni> aaah ok
[23:50:15] <+calc84> at the beginning of your program

[23:50:35] <@DJ_Omni> calc84 do we need to do something special when exiting?
[23:50:39] <+calc84> it disable's Mirage's interrupt and just uses the TI-OS one
[23:50:42] <+calc84> I don't think so

Quoted from IRC.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 10, 2010, 03:02:34 am
This is not an Axe internal bug, but it is impossible to send the app from a calculator to the computer using TI-Connect. What I think is that the five spaces in the app name causes issues. You might want to name your app so it's
Code: [Select]
"Axe" instead of
Code: [Select]
"Axe     "
Title: Re: Bug Reports
Post by: Quigibo on May 10, 2010, 03:09:50 am
That's impossible becasue the name has to be exactly 8 characters.  I could replace those spaces with null characters instead, maybe that will fix it.  Tell me if it works in the next version.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 10, 2010, 03:12:56 am
I thought it was possible? Weird x.x

But it's the first time this happens to me with an app
Title: Re: Bug Reports
Post by: Stephan on May 10, 2010, 12:14:11 pm
I agree with DJ Omnimaga, I have begun to insert notes and comments on everything I do. It helps for troubleshooting. It seems like you error seems like a code-side thing, maybe a typo????
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 10, 2010, 01:01:29 pm
Which error do you mean?
Title: Re: Bug Reports
Post by: Tribal on May 13, 2010, 05:27:50 pm
Found a small bug while messing around with Axe this morning, if you have: A/sin(cos(A)) or A/cos(sin(A)) it causes Axe to crash, where 'A' is any variable. Anybody have any ideas to why?
Title: Re: Bug Reports
Post by: Quigibo on May 13, 2010, 06:38:29 pm
Oops, I see what the problem is.  I'll have that fixed.  Right now, just do divisions with an extra parenthesis like A/((sin(cos(A)))
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 14, 2010, 08:56:04 pm
as reminder in case you forget:

the >Frac bug is still present as for version 0.2.3 :P

Meaning for programmers: you still need the additional linebreak after using it
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 16, 2010, 06:25:08 pm
Not really a bug but the new Axe 0.2.4 still says 0.2.3 on calc :P

Also, in the doc it says the GS commands won't work in 15 MHz, but I ran my tunnel game and they still worked. Do you just mean they're automatically set to 6 MHz?
Title: Re: Bug Reports
Post by: Quigibo on May 16, 2010, 07:07:21 pm
oh yeah I for got about that lol.
Title: Re: Bug Reports
Post by: Builderboy on May 16, 2010, 11:32:14 pm
I mentioned this on the Editor thread, but i just wanted to post it here.  The GetCalc(Name,size) command seems to be unable to create programs :O
Title: Re: Bug Reports
Post by: Raylin on May 16, 2010, 11:49:47 pm
I don't think he added that feature yet.
Title: Re: Bug Reports
Post by: Builderboy on May 16, 2010, 11:51:54 pm
Hmmmmm whats the difference between creating Appvars and programs i wonder?
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 16, 2010, 11:52:26 pm
I don't think he added that feature yet.
It's available actually because he mentions it in the doc
Title: Re: Bug Reports
Post by: Quigibo on May 17, 2010, 12:42:34 am
The doc only mentions appvars, programs not supported yet.

The calculator uses a separate call for creating appvars, programs, lists, etc.  I can easily add support for those, but I'd have to change the routine so it calls the correct bcall depending on the variable type.  The only problem is that it kind of bloats the size of the command.  If I split it into separate commands, or with modifiers, there would be too many possibilities and it would be confusing and hard to memorize.  I'll figure out something soon though.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 17, 2010, 12:44:46 am
Weird, I swear I saw program support. let me check

EDIT: Nvm, it's just reading from them so far. Quoted from readme:

Quote
Notice we also have to make sure the appvar exists before we can use it. That's what
the “If P” is for. It just makes sure P is non-zero. If it were zero, it couldn't be accessed
for whatever reason. Also, programs can be accessed the same way but by using the
prefix “prgm” instead.
Title: Re: Bug Reports
Post by: Builderboy on May 17, 2010, 12:47:22 am
Perhaps the command could be modified so that instead of using a pointer for the program name, it could use a String instead, or just put the name directly into it, so durring compile it would be able to figure out which BCALLs to put into the program?
Title: Re: Bug Reports
Post by: Builderboy on May 21, 2010, 06:44:58 pm
Okay so i think the conj()r command does not function properly.  it adds in weird data and doesn't shift properly. I know this is a bad time, so dont worry about getting to it right away, you can update it later if you need
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 21, 2010, 06:52:03 pm
x.x weird. I also wonder if getcalc or conj itself is bugged, because I did exactly what Quigibo and yourself told me to do in my prog and it still wouldn't work properly.

Also I think someone needs to write an in-depth tutorial on how to use GetCalc(). It,s too confusing and complicated as it is now. Just adding highscores in a game was a major hassle :/
Title: Re: Bug Reports
Post by: Quigibo on May 22, 2010, 12:47:43 am
Okay so i think the conj()r command does not function properly.  it adds in weird data and doesn't shift properly. I know this is a bad time, so dont worry about getting to it right away, you can update it later if you need

I double checked and it seems to be working fine, I even used it in one of the starship example program.  Are you sure you know the correct use for it?  It copies a byte from {Ptr1} to {Ptr2} then {Ptr1-1} to {Ptr2-1} then {Ptr1-2} to {Ptr2-2} etc.

Quote
Also I think someone needs to write an in-depth tutorial on how to use GetCalc(). It,s too confusing and complicated as it is now. Just adding highscores in a game was a major hassle :/

I know it can be confusing.  That's why I specifically wrote a small tutorial for it in the user's guide.  Plus there is the "counter" example program (hehe counterexample) which demonstrates how to tell if the variable exists, is archived, and has enough ram to be created.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 22, 2010, 12:50:30 am
yeah I chedked the tutorial and the counter program, but it was still too confusing. It would be nice if it was explained in further details.

Not now, though, because it looks like it may be an hard task to rewrite or explain better how it works. I am starting to think for external data management, I will have to rely on pre-made routines from other people or get someone to write them for me, because it is extremly low level. In my highscore routine in the Axe Tunnel I almost just copied your example and never really figured out how it really works. On the other hand, I am starting to fear that the reason I can't understand it at all is more related to something else not programming/calc related because I had this happen with some other things in the past weeks or so.

EDIT: Not really a bug report, but the keys map that came in Axe 2.4 zip file is missing from the newest Axe zip file.
Title: Re: Bug Reports
Post by: Raylin on May 23, 2010, 10:31:18 am
Quote from: Raylin
So, you wanna save some scores, huh? Well, break it down like this. Say you wanted to store 5 scores. Scores need some space to store themselves. GetCalc() does that for those scores. It basically makes a place to store those scores. But, wait! There's no place to put the scores in... yet. All houses need an address. "vMYVAR"->Str1 [The 'v' is necessary to prefix to the name. This tells Axe what variable it is editing.] is, in essence, an address. Because that string is stored in a pointer, by typing in GetCalc(Str1), you can tell Axe that "Hey! Make an appvar called MYVAR."

But, we're not done! Houses need rooms. So, if we have 5 scores, we'll give the house 5 rooms.

Final command:
GetCalc(Str1,5)

Now, if you store that command into a variable, you will always be able to reference it in-program.

I was telling my friend the exact same thing the other day in MSN. :P
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 23, 2010, 05:59:30 pm
lol nice and thanks.

Btw does your friend program for calcs a lot? I wonder if he would be interested in joining? (if he didn't already)
Title: Re: Bug Reports
Post by: Builderboy on May 23, 2010, 06:10:48 pm
I double checked and it seems to be working fine, I even used it in one of the starship example program.  Are you sure you know the correct use for it?  It copies a byte from {Ptr1} to {Ptr2} then {Ptr1-1} to {Ptr2-1} then {Ptr1-2} to {Ptr2-2} etc.

Ahhhhhh i see, i didnt get that it copied backwards from the point you give it, I thought it copied the same chunk of memory as conj() only in a different way.  Thanks :)
Title: Re: Bug Reports
Post by: Raylin on May 24, 2010, 10:15:02 am
@DJ: Yes, he does. But, he want to walk into the community with a project already done. (So, that it doesn't die.)

[ontopic]When I press [PRGM] after an error, sometimes the program throws me into a giant jumble of jibberish. (Undoubtedly appearing because of the program being compiled.) Or is it something else...?
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 24, 2010, 12:49:08 pm
Aaaah ok, I hope he finish his project, altough if he announces it before completion (as long as it has signifiant progress already) he might get more feedback and be able to either make it better or get more motivation. I guess it's up to him tho

On-topic: weird x.x, no clue why it might be happening. It sounds pretty bad, though. I am worried compiling might overwrite the program with stuff x.x
Title: Re: Bug Reports
Post by: Quigibo on May 25, 2010, 01:34:39 am
When I press [PRGM] after an error, sometimes the program throws me into a giant jumble of jibberish. (Undoubtedly appearing because of the program being compiled.) Or is it something else...?

I can't seem to replicate this.  Can you give me an example of when this happens?  And on what type of error?
Title: Re: Bug Reports
Post by: Raylin on May 25, 2010, 07:26:16 am
I went inside of my ARMY program and deleted an entire command [GetCalc()].
Axe threw a BAD SYMBOL and when I pressed [PRGM], it gave me gibberish.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 25, 2010, 12:55:43 pm
Just when you pressed PRGM or when you selected EDIT then a program?

Never had that happen before either, btw, and I got many errors. I think a bad Axe program might have caused some side effects (which means back up should be done asap)
Title: Re: Bug Reports
Post by: Quigibo on May 25, 2010, 02:14:47 pm
He's talking about the new error scrolling feature, not something wrong with the calculator.

It sounds like what's happening is that the program pointer is changing to a different location so its scrolling through garbage to the location of the error instead of the actual program.  I'll look around for something that might cause that, but I guess this feature is just temporary anyway until I have the real thing working.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 25, 2010, 02:20:00 pm
oh ok, I was a bit confused about what he meant. Can this cause potential crashes, though?

Also in the future, will the scrolling be completly removed so we don't need to wait almost one minute before it finishes scrolling (if the error is completly at the end of a 18 KB program with lots of data)?
Title: Re: Bug Reports
Post by: guy6020665 on May 26, 2010, 08:24:33 pm
He's talking about the new error scrolling feature, not something wrong with the calculator.

It sounds like what's happening is that the program pointer is changing to a different location so its scrolling through garbage to the location of the error instead of the actual program.  I'll look around for something that might cause that, but I guess this feature is just temporary anyway until I have the real thing working.

I've found that if a program is archived and you use the error scroll, it will give gibberish
Personally if the soruce is unarchived it works fine
Title: Re: Bug Reports
Post by: Raylin on May 26, 2010, 08:28:37 pm
Cool.
Thanks for that.

I was using CalcUtil.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 26, 2010, 08:32:25 pm
i only had gibberish happen once, but I totally forgot if the prog was archived or not
Title: Re: Bug Reports
Post by: Quigibo on May 27, 2010, 02:19:14 am
Oh yeah, you're right, I forgot to check if its archived  :-X  Thanks for helping me find that problem!
Title: Re: Bug Reports
Post by: guy6020665 on May 27, 2010, 05:31:23 pm
Oh yeah, you're right, I forgot to check if its archived  :-X  Thanks for helping me find that problem!

Happy to help! ;D
Title: Re: Bug Reports
Post by: Runer112 on May 27, 2010, 09:14:52 pm
Looks like your look-ahead parsing still has room for improvement ;) I hadn't recompiled a program using a version newer than 0.2.2 until now, and I've run into a slight annoyance. Your parser threw an error I hadn't seen before, that a static pointer I used was undefined. This is because, to make program editing on my calculator easier, I moved all the sprite data to the bottom of the program and just call it as a subroutine at the start of the program. However, because the program is parsed from top to bottom, it ran into a reference to sprite data in the body of the program "before" the sprite was defined, throwing the error. Any chance this could be fixed? Or an option to disable this part of error checking?

EDIT: So as not to double post, here's another problem I think I may have found, although this may just be inherent in the way text printing works: when large font is enabled, Text() will not display for X=90.
Title: Re: Bug Reports
Post by: Snake X on May 28, 2010, 04:13:40 pm
well, after making a new pic1 for the liquid simulator, and re-compiling it, I got an err: memory error when I tried to go into axe the second time.. So, I tried to archive, delete stuff that I didn't need.. plenty of memory left.. yet another err: memory. Also, it changed the source code to all the programs I wrote in Ti-Basic - including one that took me a month to make. :(

note: I also went into the memory management menu, scrolled down and when I saw the *Axe Data, it said err: memory and it didn't list how big it was. I just pressed quit and I went on through the list.
Title: Re: Bug Reports
Post by: Quigibo on May 28, 2010, 08:18:46 pm
It sounds like you accidentally corrupted your symbol table.  Archive everything you can and reset your ram, that should fix it I think.  The Axe Data file should be really small, I think its like 17 bytes or something.  If it has a ridiculous size, you'll definitely need to delete it.  It doesn't contain any important information, just your compile settings.
Title: Re: Bug Reports
Post by: Snake X on May 28, 2010, 09:15:42 pm
yeah, I just had to resort to resetting everything and clearing everything
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 29, 2010, 12:42:15 am
Also, guys, if you have a bug in your program when testing and strange things happens, sometimes it's best to archive everything then do a RAM clear before debugging, because then you may continue getting errors or weird stuff happening. You may think it's the program being buggy again, but sometimes it's just the calc being messed up by your previous test.
Title: Re: Bug Reports
Post by: Galandros on May 29, 2010, 06:47:35 am
Also, guys, if you have a bug in your program when testing and strange things happens, sometimes it's best to archive everything then do a RAM clear before debugging, because then you may continue getting errors or weird stuff happening. You may think it's the program being buggy again, but sometimes it's just the calc being messed up by your previous test.
For these kind of testing an emulator is better suited. This sounds like assembly debug procedures. xD
Title: Re: Bug Reports
Post by: Snake X on May 29, 2010, 01:29:37 pm
alright. Err: Undefined
Tribal said this compiled correctly in 2.4... I used 2.5
Code: [Select]
.SCREEN
DiagnosticOff
[FFFFFFFFFDFDFDFD]->Pic1
ClrDraw
DrawInv
While getkey (doesn't equal symbol here) 15
pause 100
DispGraph
Vertical +
For(A,0,95
Pt-Off(A,0,pic1
end
Pt-On(rand^96,A,Pic1
end
Title: Re: Bug Reports
Post by: Raylin on May 29, 2010, 01:40:23 pm
Double-tap?

(Compile it again?)
Title: Re: Bug Reports
Post by: Snake X on May 29, 2010, 01:41:30 pm
I tried that a lot of times... its error'd on pass2
pass1:  100%
pass2:  69%
err: Undefined
Title: Re: Bug Reports
Post by: Runer112 on May 29, 2010, 04:21:15 pm
alright. Err: Undefined
Tribal said this compiled correctly in 2.4... I used 2.5
Code: [Select]
.SCREEN
DiagnosticOff
[FFFFFFFFFDFDFDFD]->Pic1
ClrDraw
DrawInv
While getkey (doesn't equal symbol here) 15
pause 100
DispGraph
Vertical +
For(A,0,95
Pt-Off(A,0,pic1
end
Pt-On(rand^96,A,Pic1
end

Is "pic1" not being capitalized in "Pt-Off(A,0,pic1" just a typo in your message?
Title: Re: Bug Reports
Post by: Snake X on May 29, 2010, 04:23:06 pm
right.. because it doesn't differentiate on the calculator
Title: Re: Bug Reports
Post by: Runer112 on May 30, 2010, 12:20:59 am
I think this is a bug. If not just tell me. The following fails to compile:

Code: [Select]
91-sub(CS)
But this successfully compiles:

Code: [Select]
91-(sub(CS))
Title: Re: Bug Reports
Post by: Quigibo on May 30, 2010, 01:00:46 am
I think this is a bug. If not just tell me. The following fails to compile:

Code: [Select]
91-sub(CS)
But this successfully compiles:

Code: [Select]
91-(sub(CS))

Not really a bug... more like a lack of feature.  I haven't made subroutines usable in expressions yet although they seem to work anyway for some cases.

@Snake X
I haven't tested that yet, but are you sure you typed it all correctly?  There is nothing wrong with that code.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 30, 2010, 01:24:41 am
what would sub-routine usage in expression do?
Title: Re: Bug Reports
Post by: Runer112 on May 30, 2010, 01:35:00 am
what would sub-routine usage in expression do?

In my example:
Code: [Select]
91-(sub(CS))
I have:
Code: [Select]
Lbl CS
S=8*2
Return

This allows me to return a calculation I use in many places throughout the program without having to retype the expression everywhere it is needed, thereby reducing program size.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 30, 2010, 01:48:32 am
aaaah ok I see. Sounds like a cool idea :)
Title: Re: Bug Reports
Post by: Snake X on May 30, 2010, 08:37:22 am
Right. That is exactly how I did it on the calculator. Token for token, hex for hex, and number for number

edit: Ok, I added the same [xxxxxxxxx]->pic1 right after pause 100, and it worked... I guess it forgot that pic1 was stored?  :o
edit: I put the diagnostic off after the sprite, and it worked. I think thats what did it
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 30, 2010, 01:58:04 pm
strange I didn't realise the order would make much of a difference. It's always a habit for me to put the entire data at the very top of the program, below the header, though, so I never really encountered this.
Title: Re: Bug Reports
Post by: Runer112 on May 30, 2010, 04:29:29 pm
I don't think that retrieving and storing two-byte expressions work correctly. Both of the following examples would be affected:

Code: [Select]
{V+2}r→T
T→{L1+2}r

I believe this is because, although the r modifier is supposed to simply signify two bytes in this case, it signifies both two bytes and it swaps the bytes. Taking the first line as an example, if {V+2}=01 and {V+3}=F0, T becomes F001, although one would think that it should become 01F0. The second example acts even more oddly, the incorrect behavior of which I am spending a lot of time trying to counteract.


EDIT: This really needs looking into. I've spend the last hour just trying to get a few two-byte values to work correctly. And I haven't even been successful yet.

ANOTHER EDIT: I finally got it to work, but the code that makes it work took a lot of trial and error and doesn't logically make sense. This is still a problem that needs to be checked.


jk
Title: Re: Bug Reports
Post by: Builderboy on May 30, 2010, 06:10:00 pm
So if i understand you correctly, you are saying that storing 2 byte numbers works incorrectly because it stores the bytes in backwards order?
Title: Re: Bug Reports
Post by: Runer112 on May 30, 2010, 06:12:26 pm
So if i understand you correctly, you are saying that storing 2 byte numbers works incorrectly because it stores the bytes in backwards order?

I'm really not sure anymore. I just spent over an hour trying to get two-byte data manipulations to work in my program. What works in one case doesn't work in another case. I can't explain what is wrong anymore, it doesn't even seem to be a constant flaw.

jk again
Title: Re: Bug Reports
Post by: Builderboy on May 30, 2010, 06:14:05 pm
Do you understand how if i store a 2 byte number into {L1+0}, the first byte gets stored into {L1+1} and the second byte into {L1+0}?  This is what is known as Little-Endian format (since the little end goes in first)
Title: Re: Bug Reports
Post by: Runer112 on May 30, 2010, 06:18:35 pm
Do you understand how if i store a 2 byte number into {L1+0}, the first byte gets stored into {L1+1} and the second byte into {L1+0}?  This is what is known as Little-Endian format (since the little end goes in first)

Ok wait, I'm confused now. If I stored 1025 (0401) into {L1+2}r, I would get {L1+2}=01 and {L1+3}=04? Then what would I get if I evaluated {L1+2}r?

EDIT: Shit fail, now it all makes sense... :-[ *facepalm, goes to strike out other posts*
Title: Re: Bug Reports
Post by: Builderboy on May 30, 2010, 06:28:49 pm
That is correct, and then when you evaluated {L1+2}r it would evaluate right back to 1025
Title: Re: Bug Reports
Post by: Quigibo on May 30, 2010, 07:17:41 pm
Right. That is exactly how I did it on the calculator. Token for token, hex for hex, and number for number

edit: Ok, I added the same [xxxxxxxxx]->pic1 right after pause 100, and it worked... I guess it forgot that pic1 was stored?  :o
edit: I put the diagnostic off after the sprite, and it worked. I think thats what did it
That shouldn't be happening, I'll look into it.

I hate little endian!  It was so confusing when I was learning assembly and caused all sorts of errors.  But you kinda grow to like it eventually because it makes some things simpler.  Fortunately you never have to deal with that directly in Axe unless you actually go to look at the data you wrote in some non-conventional way.
Title: Re: Bug Reports
Post by: Snake X on May 30, 2010, 07:22:16 pm
allrighty then. Yeah, I hated little-endian too.
Title: Re: Bug Reports
Post by: DJ Omnimaga on May 31, 2010, 12:08:59 am
I always wondered what was little-endian before. Glad people summed it up now, because the Wikipedia article seemed to be TL;DR x.x
Title: Re: Bug Reports
Post by: calcdude84se on June 01, 2010, 05:21:02 pm
Yeah, it can definitely be annoying at first, though, as the wikipedia article states, there are advantages to it, namely that different-length parts of the data can all be accessed at the same address and extending a number is pretty easy (just add 0's), though the second point is a bit less important for z80 programming.
Title: Re: Bug Reports
Post by: Happybobjr on June 01, 2010, 06:42:45 pm
quick bug.

err. unknown

if you fail to compile  a prog.  ( err. block )
leave to go to the bathroom to make a number 2 for a while. ( lol a number 2 | math lol )
oh well when i got back the screen had gone dark.  i pressed on.
the compiler now said

err. block
err. unknown
Title: Re: Bug Reports
Post by: Raylin on June 01, 2010, 06:52:09 pm
Uhm.
Spam?
I think the number 2 part of it has nothing to do with the Axe error.

However, the time delay may pose an issue.

Investigation please?
Title: Re: Bug Reports
Post by: ztrumpet on June 01, 2010, 08:02:03 pm
That's not good.  I have no idea what could have happened.  Quigibo?
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 01, 2010, 08:07:54 pm
You mean if you get an ERR: message, but won't exit the compiling screen and leave it on for an extended amount of time?
Title: Re: Bug Reports
Post by: ztrumpet on June 01, 2010, 08:13:26 pm
I think he just left it running, but if he wanted to he could have quit. :)
Title: Re: Bug Reports
Post by: cooliojazz on June 01, 2010, 08:21:01 pm
Ok, so a random bug, sometimes when I complie, i get a bad symbol error or a hexadecimal one, or I think i've gotten an unknown one as well.  Anyways, I can try compling any amount of times, unless I change something, anything (ie [00000000]->Pic1 to [10000000]->Pic1) after which it will compile.  Might want to look into this...
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 01, 2010, 08:23:50 pm
Random BAD SYMBOL errors are back? D:
Title: Re: Bug Reports
Post by: calcdude84se on June 01, 2010, 08:36:19 pm
If it's only with long sequences of 00's, couldn't you just use det( ?
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 01, 2010, 10:01:04 pm
It was probably just an example
Title: Re: Bug Reports
Post by: cooliojazz on June 01, 2010, 10:33:52 pm
Yeah, I was just showing that changing something that shouldn't make a difference, did.
Title: Re: Bug Reports
Post by: Builderboy on June 01, 2010, 10:52:11 pm
It would seem that the lowercase option is not saved?  I turn lowercase on, exit, ram clear, go back, and it is changed back to normal :O isnt the appvar archived?
Title: Re: Bug Reports
Post by: Happybobjr on June 01, 2010, 10:57:05 pm
quick bug.

err. unknown

if you fail to compile  a prog.  ( err. block )
leave to go to the bathroom to make a number 2 for a while. ( lol a number 2 | math lol )
oh well when i got back the screen had gone dark.  i pressed on.
the compiler now said

err. block
err. unknown



i did have to clear ram to get out of the given screen the 1st time i tried
the 2nd time it was fine
3rd ( haven't tried again yet )
Title: Re: Bug Reports
Post by: Quigibo on June 01, 2010, 10:57:41 pm
I've fixed a lot of bugs so far, but I didn't find anything that sounded like either of the two mentioned.  Its possible it was a side effect of another bug, but tell me how it works with the new version when I release it in a few hours.

By the way, everyone is using the newest version when reporting bugs right?  Just a reminder becasue that's really important for this thread.

EDIT:
happybobjr, can you attach the file that's causing problems here so I can see what's wrong?  Or you can email it to me if you need to keep it secret.
Title: Re: Bug Reports
Post by: ztrumpet on June 02, 2010, 08:15:06 am
It would seem that the lowercase option is not saved?  I turn lowercase on, exit, ram clear, go back, and it is changed back to normal :O isnt the appvar archived?
Because it's changing a flag in the OS, a RAM Clear will reset this flag so it equals 0. :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 02, 2010, 12:51:06 pm
True, it's like MirageOs. If you reset your RAM, lowercase will get disabled until you run MirageOs again. Just entering the APP will automatically change the lowercase flag value to what is saved in the APPVAR.
Title: Re: Bug Reports
Post by: LordConiupiter on June 03, 2010, 04:31:02 pm
I have a problem with the kinda jump-to-error feature: The first few times I used it, there were the characters if the source code, but after some time it showed just only question marks. Could this be fixed?
Title: Re: Bug Reports
Post by: yoman82 on June 03, 2010, 04:57:47 pm
That's odd, it's not happening with me... What characters is it happening on?
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 03, 2010, 05:33:24 pm
Were your source files archived?
Title: Re: Bug Reports
Post by: Builderboy on June 03, 2010, 05:53:43 pm
Thats what im talking about, if i reset ram and go back into axe, the lowercase option is reset back to normal
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 03, 2010, 06:42:13 pm
@Builderboy is it in reply to the 3 posts above? O.o

I fail to understand the relation between Lord's problem and the lowercase settings being reset on RAM clear x.x
Title: Re: Bug Reports
Post by: FinaleTI on June 03, 2010, 06:57:10 pm
After I had a certain number of source programs, when I scrolled through them in Axe, sometimes my calc would crash. I deleted a few and it then worked fine. I don't know if this has to do with the number of source programs or total programs on calc. I'm using Axe v0.2.6 btw.
Title: Re: Bug Reports
Post by: Builderboy on June 03, 2010, 09:04:44 pm
Oh whoops, didnt see that there was another page, sorry about that :P I havent had anyproblems witht eh scroll feature so far but i'll holler if i encounter any!
Title: Re: Bug Reports
Post by: LordConiupiter on June 04, 2010, 12:36:50 pm
Well, it was with version 0.2.5, with an archived sourcefile. Right now it seems to be working again for me.
Title: Re: Bug Reports
Post by: Quigibo on June 04, 2010, 01:18:43 pm
Yeah, it should be able to read archived source files now.  But it definitely shouldn't crash the calc.  I don't know why it would do that... but again, this is a temporary feature.
Title: Re: Bug Reports
Post by: FinaleTI on June 04, 2010, 01:21:17 pm
What crashed my calc was scrolling through the list of source files to pick the one to compile, not jumping to an error in a source file.
Title: Re: Bug Reports
Post by: Quigibo on June 04, 2010, 01:26:25 pm
Oh, that's even worse!  :-[

Are you positive it wasn't the result of a buggy program accidentally messing up the symbol table prior to using the app?  It doesn't still error after archiving everything and doing a ram clear does it?  I kind of doubt an error like this could have gone unnoticed for so long.

Title: Re: Bug Reports
Post by: FinaleTI on June 04, 2010, 02:08:50 pm
I think it may have had something to do with the number of source files, because after I deleted a few it would work, but before that, I would make one, go to try and compile and whenever I moved the cursor upward, my calc would crash. After several crashes, I deleted some source files I didn't need on hand and made another source file then scrolled through the list it worked just fine.
Title: Re: Bug Reports
Post by: calcdude84se on June 04, 2010, 02:11:03 pm
I think someone else complained of this. Maybe the routine that finds what programs are valid Axe source-files and sorts them can only handle so many files?
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 04, 2010, 05:28:18 pm
How many did you have when it crashed, approximately? I would like to know so I keep them to a minimum on my calc (I usually keep a lot of small source code in archived programs in case I need it in other programs)
Title: Re: Bug Reports
Post by: FinaleTI on June 04, 2010, 06:37:12 pm
Currently, I have 28 and it hasn't crashed. Let's see... I deleted about 4 or 5 and since then I've made about 1 or 2, so I'm gonna estimate I had around 33-34 source programs, but this is just a guess. I forgot to count how many I had when it crashed, so this is an estimated guess.
Title: Re: Bug Reports
Post by: calcdude84se on June 04, 2010, 07:35:12 pm
That's not a lot... Could it be the sort routine's fault? (I'm assuming there's a sort routine)
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 04, 2010, 07:36:46 pm
I am certain it has to do with the sorting routine. It really sounds like the OS 1.13 glitch back in the days x.x
Title: Re: Bug Reports
Post by: squidgetx on June 06, 2010, 10:48:32 am
Reporting a bug~~
Well, I've grown used to the random RAM clears that happen while using Axe, but this particular one caught me off guard:
The parser told me that at 86% on the 2nd pass, there was a duplicate error. I hit prgm, to scroll to (it was weird, since I'm pretty sure there WASN'T any duplicate error-causing code, and the calc shut off. ofc, ram clear. I don't have the source since it was lost in the crash (I know you can compile from archive, but I usually don't because stuff like that never happens :P)
Title: Re: Bug Reports
Post by: Deep Toaster on June 06, 2010, 03:00:09 pm
Another really weird bug: After compiling a few programs, I went into Mem Mgmt/Del... to clear some unnecessary variables/programs. To my surprise, it listed Y1, X1T, and Y1T, which I was sure I hadn't used since I last cleared out the variables. Even more strange was that Y1 had a size of something like thirteen hundred bytes, which is definitely wrong. I rashly tried to delete it, and the calculator ended up freezing in the deletion process. I had to take out a battery to fix it, which resulted, of course, in a RAM clear.
Title: Re: Bug Reports
Post by: nemo on June 06, 2010, 03:15:43 pm
not sure if this will help, but about deep thought's bug, i had the same thing happen to me when i tried to romdump my calculator about 3 months ago using TiLP. so if you tried to romdump recently it may have been that rather than axe parser.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 06, 2010, 04:30:10 pm
Do you know exactly how to recreate the bug? Did you run axe programs before this happens? A buggy program can cause bad stuff in long term (until next RAM clear)
Title: Re: Bug Reports
Post by: Quigibo on June 06, 2010, 04:32:57 pm
I after reading the these reports, I would recommend to NOT use the error scrolling features until I figure out what the bug is.
Title: Re: Bug Reports
Post by: squidgetx on June 06, 2010, 05:06:04 pm
@DeepThought

Yeah, that's actually happened to me several times throughout my calc's history (even before Axe), but I've never romdumped it (nemo) It's been occurring a lot recently though. Once I remember (before 2.53MP, when Omnicalc still worked) I was playing around with the outrageoulsy-sized graphing vars recreating them after each crash with RestoreMem( and once i actually managed to delete it once. Mine were around 128k in size O.o and so then I had around 152k RAM. It was cool for all of about 5 seconds when the calc crashed again lol

Another bug I found with Axe is that once (again, I don't have the source, sorry) after running a compiled program, after exiting MOS (with the On+Mode interrupt, maybe this is an issue?) my cursor in the homescreen, instead of being in the normal position, was 2 rows down and 2 characters across, and it was blinking over the 3x3pixel box character. I wasn't able to type any numbers/letters etc, and upon going into the mem menu to clear RAM, once I hit "Enter" on Mem Mgmt/Delete, the calc acted like I had quit the menu: the cursor (and the 3x3 box char) reappeared, only the menu didn't go away. So i had a blinking cursor in the middle of a menu~ Eventually I had to pull a battery, which cleared the RAM. After compiling and running the exact same file, the bug did not reappear
Title: Re: Bug Reports
Post by: Deep Toaster on June 06, 2010, 06:22:01 pm
I after reading the these reports, I would recommend to NOT use the error scrolling features until I figure out what the bug is.

I haven't even used the error scrolling yet (ever).

not sure if this will help, but about deep thought's bug, i had the same thing happen to me when i tried to romdump my calculator about 3 months ago using TiLP. so if you tried to romdump recently it may have been that rather than axe parser.

I have never done a ROM dump either (though I plan to do it in a few days for WabbitEmu).

Do you know exactly how to recreate the bug? Did you run axe programs before this happens? A buggy program can cause bad stuff in long term (until next RAM clear)

Buggy programs aren't that big of a problem for me, since I clear my RAM about once (possibly more) every day anyway. (Excessive RAM clears doesn't hurt the calculator in the long run, does it? :-\) Anyway, here's how I got the bug (simplified):

1. Made Axe source code. It didn't do anything at all except create a label with some code for a sprite. Nothing else; the program was a test and was functionally useless.
2. Compiled Axe program. No errors; worked fine.
3. Ran program from MirageOS. As expected, the program did nothing at all.
4. Decided that my PRGM list was a bit cluttered. So I went into Mem Mgmt/Del... to get rid of some stuff.
5. Deleted a couple of RAM variables. Found a 1263-byte Y1 and two parametric equations that obviously didn't belong. Made a very stupid decision to try deleting Y1. Calculator froze; even the run indicator was stuck in place.

Before I did all this, I purposely cleared my RAM to get rid of unused variables (because I'm too lazy to delete them one by one), so the only applications that could have caused the error are Axe and MirageOS. Since I've never seen MirageOS with a bug like this, and since Axe is still a beta, I figured that it very likely was caused by Axe.

On a slightly related topic, I tried renaming a BASIC program from ICON16 to ICON8. I expected the filesize to shrink one byte, but this didn't happen. Anyone how this happened?
Title: Re: Bug Reports
Post by: Happybobjr on June 07, 2010, 07:50:34 am
Reporting a bug~~
Well, I've grown used to the random RAM clears that happen while using Axe, but this particular one caught me off guard:
The parser told me that at 86% on the 2nd pass, there was a duplicate error. I hit prgm, to scroll to (it was weird, since I'm pretty sure there WASN'T any duplicate error-causing code, and the calc shut off. ofc, ram clear. I don't have the source since it was lost in the crash (I know you can compile from archive, but I usually don't because stuff like that never happens :P)


i believe i do know whats wrong with this.  for me with conjunction of things like mirage os or just the calculator in general, programs randomly disappear.
my guess is that you had a "missing" program" and when you tried to scroll there the calc did not know what to do.
to fix this , probably, garbagecollect your calculator before compiling programs, it works for me
Title: Re: Bug Reports
Post by: Deep Toaster on June 08, 2010, 06:33:50 pm
I don't know if this is because of Axe Parser at all, but seeing as it's only started after I downloaded it, I felt I should post it here.

I've been noticing that certain actions on my calculator have gotten slower and slower. Before, I could archive and unarchive variables under 1 KB almost instantaneously, but recently, it's become really slow. I just tried to archive a mere 68-byte program, and it took four whole seconds. Same goes for exiting Axe: when I first downloaded the app, it exited in less than a second, but now it also takes something like four seconds. Anyone have any idea what's happening? I've already tried RAM clears (dozens of them since I first downloaded Axe -- don't worry, most of them were intentional), and it hasn't helped. I really hope this isn't anything permanent.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 08, 2010, 06:34:33 pm
Bug report with Text command (or boolean logic):

Text(4+4(B>9)+4(B>99)+4(B>999)+4(B>9999),0,A▶Dec

Regardless of the results in B, A content will always be displaying at X coordinate 0 instead of at its respective location, like it would in TI-BASIC (with the command "Text(0,4+4(B>9)+4(B>99)+4(B>999)+4(B>9999),A")
Title: Re: Bug Reports
Post by: calc84maniac on June 08, 2010, 06:39:59 pm
Bug report with Text command (or boolean logic):

Text(4+4(B>9)+4(B>99)+4(B>999)+4(B>9999),0,A▶Dec

Regardless of the results in B, A content will always be displaying at X coordinate 0 instead of at its respective location, like it would in TI-BASIC (with the command "Text(0,4+4(B>9)+4(B>99)+4(B>999)+4(B>9999),A")
It's because Axe doesn't do implicit multiplication. You need to do "4*(" instead of "4(". Actually, this would probably be more optimized overall:

Text((B>9)+(B>99)+(B>999)+(B>9999)+1*4,0,A▶Dec
Title: Re: Bug Reports
Post by: calcdude84se on June 08, 2010, 06:41:53 pm
Do you need multiplication signs between the 4 and the (B>9)? (and all the others).
Edit: ninja'd
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 08, 2010, 06:45:37 pm
oh darn I forgot about the lack of implicit multiplication support x.x

THanks guys, and that was an epic ninja: by two members with similar nicknames
Title: Re: Bug Reports
Post by: Quigibo on June 08, 2010, 07:26:33 pm
I don't know if this is because of Axe Parser at all, but seeing as it's only started after I downloaded it, I felt I should post it here.

I've been noticing that certain actions on my calculator have gotten slower and slower. Before, I could archive and unarchive variables under 1 KB almost instantaneously, but recently, it's become really slow. I just tried to archive a mere 68-byte program, and it took four whole seconds. Same goes for exiting Axe: when I first downloaded the app, it exited in less than a second, but now it also takes something like four seconds. Anyone have any idea what's happening? I've already tried RAM clears (dozens of them since I first downloaded Axe -- don't worry, most of them were intentional), and it hasn't helped. I really hope this isn't anything permanent.
You need to garbage collect.  I could have Axe ask you periodically, but I think it would get annoying.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 08, 2010, 07:28:30 pm
I don,t think getting Axe to do so would be necessary, since the calc can let you do so if you desire.
Title: Re: Bug Reports
Post by: Deep Toaster on June 08, 2010, 07:34:20 pm
Another bug.
I compiled a 1-KB program with Axe, and suddenly the source (not the executable) became 200 bytes, which means it somehow leaked 800 bytes. I tried to edit the source to check, and it stopped after a statement containing getKey( (yes, it stopped right after the opening parenthesis). I tried to compile it again for no reason, and it gave me an ERR: UNKNOWN ERR. According to your documentation, an ERR: UNKNOWN (that should get updated, by the way :)) means that "Something is wrong with the parser. Report bug immediately!" So here it is.

By the way, did anyone figure out what went wrong with my previous bug (http://ourl.ca/4072/93988)?

EDIT: Whoops, didn't see your post there, Quigibo. Sorry.

EDIT2: Oh, wow, that was surprisingly simple. It works now, thanks.

EDIT3: I'm talking about the first bug, not the ERR: UNKNOWN ERR.
Title: Re: Bug Reports
Post by: SirCmpwn on June 08, 2010, 07:36:58 pm
Hi Deep Thought, I don't believe we've meet.
I think you have a problem with your ROM.  I have seen similar problems before.  The first place to start is with a GarbageCollect.  If that doesn't work, do a defrag.  You can kick off a defrag by deleting an app.  Finally, if you still have problems, back up your stuff and do a full reset, RAM and ROM.
Title: Re: Bug Reports
Post by: Magic Banana on June 09, 2010, 12:29:44 am
not sure if this will help, but about deep thought's bug, i had the same thing happen to me when i tried to romdump my calculator about 3 months ago using TiLP. so if you tried to romdump recently it may have been that rather than axe parser.

Axe doesn't seem to cause any problems for me when I did a romdump. I actually did one for my 83+SE today for wabbitemu using rom8x and everything worked perfectly fine. I even left MirageOS, Omnicalc, and CalcUtil installed along with Axe parser, and no problems occurred.
Title: Re: Bug Reports
Post by: Quigibo on June 09, 2010, 01:08:21 am
@Deep Thought, that sounds too strange to be an internal error.  Something must have gotten overridden.  I think a ram clear would be a sufficient fix but I don't know.

I'd like to request that from now on, please give your calculator type and OS version when reporting any major bugs.  This is becasue I am adding a lot of calculator specific stuff next version.  Also but from 0.3.0 on, when you receive an unexpected error "ERR: UNKNOWN" it will also give a 7 digit code that I can use to find where and when the error occurred.
Title: Re: Bug Reports
Post by: Happybobjr on June 09, 2010, 06:09:37 pm
HUGE  (at least for me)

ok this has really been  bugging me.
ok i make a prog, it works.
i am unhappy and get rid of an if statement and the corresponding end command. ( yes the correct one )
i try to compile it again.
it says err. block.
i go and check the code 100 times. *(later on another bug... listed at bottom)*
there is no problem with it..
i finally find out that garbage collect temporary corrects this. ( i think it is only with the newest version of Axe. )


*now other bug*
ok lets go back to earlier
i go and check the code 100 times
i accidentally press enter while at home screen. ( last prog run before failed compile was the successful compiled prog )
screen goes blank
screen comes back on
on the top left corner it displays "program"  (no parenthesis)
them a few seconds later my ram is cleared
Title: Re: Bug Reports
Post by: ztrumpet on June 09, 2010, 06:51:28 pm
I'd like to request that from now on, please give your calculator type and OS version when reporting any major bugs.  This is becasue I am adding a lot of calculator specific stuff next version.  Also but from 0.3.0 on, when you receive an unexpected error "ERR: UNKNOWN" it will also give a 7 digit code that I can use to find where and when the error occurred.
Yay, that sounds good, but the massive quantities of errors is a little alarming.  Does Axe have any history of corrupting ROM?  If it doesn't, then I guess everything's fixable with a RAM Clear, GC, or Defrag. :)
Title: Re: Bug Reports
Post by: TIfanx1999 on June 09, 2010, 09:15:10 pm
I'd like to mention that since AXE is still in developmental stages, it might not be a bad idea to test things out on emulator before running them on a actual calculator. Also, I know this has been said over 9000 times, but backup progress often!!!
Title: Re: Bug Reports
Post by: Quigibo on June 09, 2010, 10:28:52 pm
i accidentally press enter while at home screen. ( last prog run before failed compile was the successful compiled prog )

Whoa, whoa hold up!  Something already sounds really wrong with that.  When Axe fails to compile a program and there were errors, the original program is supposed to be deleted even if it existed before.  Is it not getting deleted then?  That could be a clue as to what the problem might be, let me know.  Also, could you tell me the type of calculator you're using and maybe some other info like archive free, OS, other apps, etc.
Title: Re: Bug Reports
Post by: Happybobjr on June 10, 2010, 10:56:45 am
Ti-84 plus silver edition
OS: 2.52 MP
Axe: 0.2.6
letter on back: M     (for things like ti-boy se)  ( can't use )

i do have marage os  but i don't compile for it
Title: Re: Bug Reports
Post by: calcdude84se on June 10, 2010, 11:31:10 am
2.53, I take it. And that sounds bad... But then again, it's 2.53...
Title: Re: Bug Reports
Post by: Runer112 on June 10, 2010, 12:29:38 pm
Is there any reason why you can successfully compile and run Ion programs of large sizes, but when compiling no shell programs that pass about 8200 bytes in (executable) size, trying to run the program returns ERR:INVALID?

EDIT: Also, I guess the whole thing about not running programs larger than 8811 bytes in size (using the Ion-compiled version, as the no shell couldn't run the program, currently at OVER 9000 BYTES!!!!!1!!) may be right though, because I'm currently editing the 4-level grayscale "sprites" of random sections of RAM.
Title: Re: Bug Reports
Post by: Happybobjr on June 10, 2010, 03:45:04 pm
2.53, I take it. And that sounds bad... But then again, it's 2.53...
correct it is 2.53
thanks
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 10, 2010, 05:51:01 pm
Is there any reason why you can successfully compile and run Ion programs of large sizes, but when compiling no shell programs that pass about 8200 bytes in (executable) size, trying to run the program returns ERR:INVALID?

EDIT: Also, I guess the whole thing about not running programs larger than 8811 bytes in size (using the Ion-compiled version, as the no shell couldn't run the program, currently at OVER 9000 BYTES!!!!!1!!) may be right though, because I'm currently editing the 4-level grayscale "sprites" of random sections of RAM.
Keep in mind that the 8811 limit excludes data, though (example [45892894FCBE8272]->Str1). You could have like 8 KB of code, but then you can still have as much data as you want as long as you have enough RAM to both fit/run the executable.
Title: Re: Bug Reports
Post by: ztrumpet on June 10, 2010, 06:25:55 pm
Builderboy knew the problem:
Its a TI OS thingy, it restricts programs to around 8100 bytes, even though the maximum possible is around 8800 bytes.  Thats why you get the extra 600 bytes in Mirage and Ion, because they aren't stupid like TI :P
Title: Re: Bug Reports
Post by: nemo on June 10, 2010, 07:04:42 pm
in axe 2.6, you can modulus by 0. i'm not sure if this is a bug or if it should be a bug, i'm just going to say that getting the remainder after dividing by zero defies all logic in my brain. the program compiles and works. X^0 in axe is always true apparently.
Title: Re: Bug Reports
Post by: ztrumpet on June 10, 2010, 08:00:14 pm
Huh, so in Axe:
X/0 = 65535
X^0 = X
That's fun to know. ;D
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 10, 2010, 08:02:14 pm
yeah I remember seeing this. That was weird and it's (http://avatar.identi.ca/5499-96-20091104165453.jpeg)
Title: Re: Bug Reports
Post by: squidgetx on June 10, 2010, 08:46:44 pm
well probs b/c the calc doesn't know errors, and instead is like KTHX SOMETIN ^0= INFINITY and then says goshdarngolly we can only process 65535. kind of like how in pokemon red having a lvl 1 mew gain less than 54 xp lvls it to 100 (because at lvl 1, it has -54 xp, but it's not really 54, it's like 2^64-54 or something) so the processor assumes it has enough xp for lvl 255 and forces it to 100</offtopic>

anyway, after compiling and running an axe prog, i was scrolling through my mem menu, when all of a sudden an ERR: MEMORY popped up. upon hitting 2:Goto, it showed the mem menu and L2, but w/o a size for L2 or the little arrow cursor. Upon using the STAT editor to look at L2's contents.... (see screenie)
Title: Re: Bug Reports
Post by: ztrumpet on June 10, 2010, 10:24:47 pm
Do you mind uploading the exact program you tried to compile?  That'll help Quigibo debug.  If you don't want everyone to see your program (like if it's a contest entry), then you could email it to Quigibo.  Also, have you ran any other Asm programs recently that aren't 100% stable?  Anyway, that's a wild glitch.  I hope it's an easy error to find. :)
Title: Re: Bug Reports
Post by: squidgetx on June 11, 2010, 02:36:13 pm
Yeah, i guess reporting a bug isn't very helpful w/o the source :P, but, as you guessed, it's a contest entry. However, I think I've figured out what causes it: using the Mirage interrupts, like On+Mode to quit to the homescreen. The program itself didn't seem to cause this bug every time I ran it; it occurred to me that the glitchy lists appeared when I would exit the program with On+Mode
Title: Re: Bug Reports
Post by: Runer112 on June 11, 2010, 03:43:06 pm
ERR: UNKNOWN ERR

Code: [Select]
:.TANGENT
:Lbl T
:  sin(→A)*256//cos(A)
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 11, 2010, 07:19:32 pm
Mhmm it seems like 0.2.6 is getting a record amount of errors, or maybe it's due to more people using Axe. Could something have accidentally been screwed up in the Axe Parser code that cause everything else to glitch? x.x I hope it's nothing too bad.
Title: Re: Bug Reports
Post by: Builderboy on June 11, 2010, 07:37:08 pm
Thats why im still ata round 0.2.4, im waiting for a stable release, either that or some sort of new feature that i cant live without.
Title: Re: Bug Reports
Post by: calc84maniac on June 11, 2010, 09:05:55 pm
You said you recently added support for Asm( in expressions, right? Well, apparently now it's wanting me to close the parentheses, even if it's on its own in a line.
Title: Re: Bug Reports
Post by: Quigibo on June 11, 2010, 09:31:24 pm
ERR: UNKNOWN ERR
Code: [Select]
:.TANGENT
:Lbl T
:  sin(→A)*256//cos(A)

Thank you very much.  That was a very easy error to fix.  I forgot to add signed division to the list of commands to perform as a stack operator (operates on parenthesis).  I hope more people will provide snippets of code that fail so I can see what it is that's a problem.  So far, I haven't been able to replicate any of the other errors, and I'm using it a lot on real hardware too.  If you just archive your program before compiling, it will save even after a ram clear, so you'll be able to post the error.  You can always email me if the code needs to be private.

EDIT: calc84, I'm looking into that too.

EDIT2: Yup, forgot about that.  Now a close parenthesis, enter, colon, or eof will assume it.
Title: Re: Bug Reports
Post by: ztrumpet on June 11, 2010, 10:35:30 pm
I'm glad the bugs are being fixed. :)
I hope you'll be able to fix everything and we'll get a stable release soon. :D
Good luck Quigibo! ;D
Title: Re: Bug Reports
Post by: cooliojazz on June 11, 2010, 10:47:19 pm
Oh, and getKey() always requires close parentheses... is that on purpose?
Title: Re: Bug Reports
Post by: Ikkerens on June 12, 2010, 07:47:08 am
Drawing pixels in the back buffer doesn't seem to work, like this:

Pxl-On(X,Y)r gives a bad symbol error
Same is valid for Pxl-Off.

Had to work around this by creating a sprite with the top left on, and using Pt-off(X,Y)r
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 12, 2010, 01:11:16 pm
mhmm weird, it doesn't work for me either. It's almost like if Quigibo accidentally removed this feature totally in Axe 0.2.6 or something x.x. He will have to check this too I guess :S

Welcome here by the way
Title: Re: Bug Reports
Post by: Ikkerens on June 12, 2010, 01:19:20 pm
mhmm weird, it doesn't work for me either. It's almost like if Quigibo accidentally removed this feature totally in Axe 0.2.6 or something x.x. He will have to check this too I guess :S

Welcome here by the way

Thanks, have been around for a while here, only created my account today.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 12, 2010, 01:20:21 pm
Aaaah ok ^^

I hope you stay interested in programming those little machines for a while ^^
Title: Re: Bug Reports
Post by: Ikkerens on June 12, 2010, 01:31:20 pm
Aaaah ok ^^

I hope you stay interested in programming those little machines for a while ^^

I will most likely as long as im on high school :P
Title: Re: Bug Reports
Post by: Deep Toaster on June 12, 2010, 09:22:19 pm
@Deep Thought, that sounds too strange to be an internal error.  Something must have gotten overridden.  I think a ram clear would be a sufficient fix but I don't know.

I'd like to request that from now on, please give your calculator type and OS version when reporting any major bugs.  This is becasue I am adding a lot of calculator specific stuff next version.  Also but from 0.3.0 on, when you receive an unexpected error "ERR: UNKNOWN" it will also give a 7 digit code that I can use to find where and when the error occurred.

Here's another similarly weird error: I compile a 400-byte program, which worked pretty well before, but now, when I run it from MirageOS, it has some weird glitches. I look in the source to find why it led to those glitches, and I find that Axe somehow modified one token in the source from a 0 to some undisplayable character (designated by ?). This happened again a few compiles later, but this time it changed some token (I don't remember which one, but it might have been If into something like sin-1(. The second time happened after a (purposeful) RAM clear, so it wasn't a buggy program.

Thinking a GarbageCollect would do the trick, as it did in my previous error post (http://ourl.ca/4072/94005), I went into the Catalog, then selected Garbage Collect. After it copied it to the screen, I pressed ENTER to run it, as always. But this time, it didn't actually run. In fact, it didn't even display the Garbage Collect? message. The calculator just froze. It wasn't even a normal freeze, where the run indicator seems to be stuck in its spinning mode. This time, the run indicator seemed to be frozen in the Pause mode (with the alternating dots). The calculator was fixed when I removed a battery (resetting the RAM in the process, of course).
Title: Re: Bug Reports
Post by: Quigibo on June 12, 2010, 09:36:19 pm
Okay, I think I might know what the problem is.  Can those who had problems confirm this:

Were your executables archived prior to compiling a new build of the program?  I think becasue the app has to delete the archived programs so often it causes the OS to mess up the rom somehow which causes other problems.  I might have to have Axe automatically garbage collect or something to solve this.  That would also explain why most people who are getting this error are using shells, becasue you can run the programs when they're archived.
Title: Re: Bug Reports
Post by: Runer112 on June 12, 2010, 09:39:16 pm
I could've told you that before Quigibo :P I've always been compiling my programs from RAM because I noticed that they get random errors when compiling from Flash.
Title: Re: Bug Reports
Post by: calc84maniac on June 12, 2010, 09:40:47 pm
Okay, I think I might know what the problem is.  Can those who had problems confirm this:

Were your executables archived prior to compiling a new build of the program?  I think becasue the app has to delete the archived programs so often it causes the OS to mess up the rom somehow which causes other problems.  I might have to have Axe automatically garbage collect or something to solve this.  That would also explain why most people who are getting this error are using shells, becasue you can run the programs when they're archived.
No, that can't be the issue. The OS knows what it's doing when it messes with archive.
Title: Re: Bug Reports
Post by: Quigibo on June 12, 2010, 09:49:05 pm
I don't understand how that's possible.  I'm only using OS bcalls when writing to rom and as Deep Thought stated, its not an issue with any part of the RAM since it continues after a ram clear it has to be somewhere in rom.

@Runner12
You're getting errors with the source or previous executable in archive?  What errors and where would it scroll?
Title: Re: Bug Reports
Post by: Runer112 on June 12, 2010, 09:50:03 pm
Random.

For example, I loaded my sprite editor source (I assume it's some sort of reading problem, so a bigger source, in this case almost 15KB, probably means more probability for errors) into archive and compiled it five times, here are the results:

Title: Re: Bug Reports
Post by: Quigibo on June 12, 2010, 09:55:50 pm
Wait, is this replicate-able?  Can you post the source that does this?
Title: Re: Bug Reports
Post by: Runer112 on June 12, 2010, 09:57:35 pm
What do you mean? You can't really replicate it because it's random.
Title: Re: Bug Reports
Post by: calc84maniac on June 12, 2010, 09:59:59 pm
What do you mean? You can't really replicate it because it's random.
Failed 3 out of 5 times, sounds pretty replicate-able.
Title: Re: Bug Reports
Post by: Deep Toaster on June 12, 2010, 10:05:41 pm
Okay, I think I might know what the problem is.  Can those who had problems confirm this:

Were your executables archived prior to compiling a new build of the program?  I think becasue the app has to delete the archived programs so often it causes the OS to mess up the rom somehow which causes other problems.  I might have to have Axe automatically garbage collect or something to solve this.  That would also explain why most people who are getting this error are using shells, becasue you can run the programs when they're archived.

Thanks, I remember now. Those were two of the rare times I compiled out of Archive.

Do you know why it messes up archived programs, though? Would it be possible for a future version of Axe to fix the bug?
Title: Re: Bug Reports
Post by: Runer112 on June 12, 2010, 10:06:43 pm
http://ourl.ca/4832/94254
Title: Re: Bug Reports
Post by: Quigibo on June 12, 2010, 10:12:41 pm
I THINK I MIGHT HAVE FOUND IT!

I need some asm expert to answer this question:

The user ram is 24-ish KB right?  So it is possible to make a program over 16KB right?  You can archive this program right?  Wouldn't that imply that you can have a single program take up 2 pages of rom?  Does that also mean that a program less than 16kb can also take up 2 pages since none of the rom is actually wasted?  Because that would mean I have to switch pages at some point during compile time, something I'm currently not doing when reading from archive.  Of course if any of these assumptions are wrong, then it must be something else...

Title: Re: Bug Reports
Post by: calc84maniac on June 12, 2010, 10:24:57 pm
I THINK I MIGHT HAVE FOUND IT!

I need some asm expert to answer this question:

The user ram is 24-ish KB right?  So it is possible to make a program over 16KB right?  You can archive this program right?  Wouldn't that imply that you can have a single program take up 2 pages of rom?  Does that also mean that a program less than 16kb can also take up 2 pages since none of the rom is actually wasted?  Because that would mean I have to switch pages at some point during compile time, something I'm currently not doing when reading from archive.  Of course if any of these assumptions are wrong, then it must be something else...


Oh, you seriously haven't been checking for page switching? That could explain it. :P
Title: Re: Bug Reports
Post by: Deep Toaster on June 12, 2010, 10:36:00 pm
Funny, I could have sworn I read somewhere that flash apps are the only variables that can take up more than one page. But this explains why my calculator didn't crash on archiving a 20 KB program.

Do you think you're going to be able to add page switch checking in the next version of Axe?

And I've read your signature, but I'm still wondering: When do you think you will finish 0.3.0 (i.e., June, July, or August)?
Title: Re: Bug Reports
Post by: calc84maniac on June 12, 2010, 10:41:17 pm
Even a two-byte variable can span more than one page, if you archive it at just the right time :P
Title: Re: Bug Reports
Post by: Quigibo on June 12, 2010, 10:48:51 pm
Thanks, so that should finally stabilize it.  I'm adding page swapping now, it's fairly simple.  I just have to make sure that only my main routines are called when reading bytes and that I'm not using any exploits in the code anywhere.  0.3.0 will come in less than a week, but I won't have app compiling working yet unfortunately.  But there is another cool new feature that will come in handy ;)
Title: Re: Bug Reports
Post by: Deep Toaster on June 12, 2010, 11:14:43 pm
Darn. This means that I won't be able to update my version until September.

0.2.6 is good enough for all I use Axe for, anyway. Really like it.

Thats why im still ata round 0.2.4, im waiting for a stable release, either that or some sort of new feature that i cant live without.

Would you consider 0.2.5 more stable than 0.2.6?

This (http://ourl.ca/4072/94005) may have something to do with the archiving as well, since that's about when I started trying compiling from Archive. Just thought you'd like to know.

Just a tip:
Axe Parser 0.3.0
Finals coming, don't expect too much or an on-time release.
Your heads will explode.

instead of
Axe Parser 0.3.0
Finals coming, don't expect too much or an on-time release.
Your heads will explode.


Please disregard the "tip" above. Sorry, couldn't resist.

Just wondering: Since the 0.0s and 0.1s are called Alphas, and the 0.2s are called Betas, would 0.3.0 also count as a Beta?
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 12, 2010, 11:59:05 pm
Does it means program executables larger than 16 KB will not be possible at all? I was sure it could be done, considering Dying Eyes and Joltima RPGs are over 18
Title: Re: Bug Reports
Post by: Quigibo on June 13, 2010, 12:03:38 am
0.3.0 will be a gamma version.  Its basically the same thing as a beta version, but with a cooler name.  Stability is relative.  Since this problem only affects compiling from archive, you could argue that the version when you couldn't do that was more stable.  But really, you can do the same thing now, its just that with the addition of new features, its usually the new stuff that can get unstable.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 13, 2010, 12:04:56 am
Lol I doN,t remember hearing Gamma version before :D I guess it's good though ^^
Title: Re: Bug Reports
Post by: calcdude84se on June 13, 2010, 08:11:12 am
then the 0.4.x versions will be deltas, the 0.5.x versions will be epsilons... up to 0.24.x, which will be omegas... :P
Of course, we'll probably get 1.x.x before that. (maybe the 2.4.x versions will be omegas...)
Title: Re: Bug Reports
Post by: ztrumpet on June 13, 2010, 10:26:19 am
Yea!  I'm glad you found the problem.  I'm really glad it's fixed now.  Thanks Quigibo! ;D
Yay, 1-5 days before a Gamma release! :D
Title: Re: Bug Reports
Post by: calcdude84se on June 16, 2010, 04:47:22 pm
Apparently, this code
Code: [Select]
Repeat 1=2
If getKey=15
Goto E
End
-1→B
62→A
Repeat A>62
Shade(A)
A+B→A
If A<1
-B→B
End
End
End
Lbl E
Shade(47)
causes the BLOD's. I refuse to test this myself, so I cannot verify it. However, I am unsure why this would happen (I calculated the range at which Shade( should cause the BLOD's to be 92-95 (decimal)) Any clues?
Title: Re: Bug Reports
Post by: Quigibo on June 16, 2010, 04:58:00 pm
I don't know.  The command only allows values between $C0 and $FF so it is impossible to get into test mode.  Are you sure these are the blue lines of death and not just the normal blue from high contrast values?
Title: Re: Bug Reports
Post by: Ikkerens on June 16, 2010, 05:02:45 pm
You could see the person that posted everything at my topic with the wave effect.
Title: Re: Bug Reports
Post by: calcdude84se on June 16, 2010, 05:03:03 pm
I asked him, but he never answered and now he's gone...
Title: Re: Bug Reports
Post by: SirCmpwn on June 16, 2010, 05:07:12 pm
If the command only allows non-BLOD values, then it probably is fine.  I may have overreacted, but my usual strategy when hearing about BLOD-style effects is to instantly stop it from being promoted.
Title: Re: Bug Reports
Post by: squidgetx on June 16, 2010, 05:08:15 pm
I think it is the blue screen of death. Putting
Code: [Select]
DrawInv
Shade(63)
DispGraph
Repeat getKey
End
Shade(47)
before the suspect code lets you see the difference
I tested it on my calc lol (good decision? It hasn't exploded yet...)
Title: Re: Bug Reports
Post by: nemo on June 16, 2010, 05:09:11 pm
i just tried it on my ti 84 + SE with a 2.41 OS and yes, it BLOD's. i was pretty quick to pull out a battery so no harm done to my calc.
EDIT: maybe Axe is updating the contrast values so fast in the repeat loop, that the LCD can't update itself fast enough, so it BLOD's?
Title: Re: Bug Reports
Post by: calcdude84se on June 16, 2010, 05:10:57 pm
So weird... I'm getting my calc an viewing the disassembly in calcsys to see how this happened (I still refuse to execute it)
Title: Re: Bug Reports
Post by: squidgetx on June 16, 2010, 05:11:09 pm
i was pretty quick to pull out a battery so no harm done to my calc.
I just hit clear and it exited to Mirage like normal...

i guess maybe it's a side effect of rapidly changing contrast? I remember this actually happened to me before while I was experimenting with combining contrast levels and grayscale to produce 8 lvl gray in Axe (it worked, but there's barely any practical use, and you can only display like 6 of the 8 shades at once anyway)
Title: Re: Bug Reports
Post by: calcdude84se on June 16, 2010, 05:18:32 pm
Well, it doesn't happen in 0.2.3 (which I have, I'm waiting for 0.3.0 to upgrade), so I'm afraid I'm of no further use w/o the program generated by the most recent version
Title: Re: Bug Reports
Post by: Quigibo on June 16, 2010, 05:24:23 pm
I am going to talk to some experts in hardware and do some disassembly.  Can someone brave please test if adding a "Pause 2" after every contrast routine changes anything?  Also, is there any specific range of values that cause this?
Title: Re: Bug Reports
Post by: Quigibo on June 16, 2010, 07:27:50 pm
Okay, I did my research.  This is what appears to be happening.  I believe that there is a very short voltage spike between changing contrast from a very low value to a very high value and vise versa.  You don't see the screen turn blue normally becasue its so fast that you can't even see it.  However, if you alternate the screen very rapidly, the voltage spike appears often enough that it becomes very noticeable.  So this is a faulty hardware problem and there is nothing I can do about it.  I'll just have to trust that you're all being safe about using it.

Here were some clues that led me to my hypothesis:

All of these suggest that the calculator is NOT in test mode.  So this blue is actually less voltage on average than test mode, but that still doesn't mean its remotely safe.  It probably won't fry your calculator right away like the real test mode, but it can certainly damage it over a longer period.  I absolutely do not recommend exploiting this effect.
Title: Re: Bug Reports
Post by: calcdude84se on June 16, 2010, 08:05:58 pm
So it's not your fault. That's good to know. Is there any sense in adding a pause to the Shade( command, or is asking programmers to be considerate of this good enough?
Title: Re: Bug Reports
Post by: Happybobjr on June 16, 2010, 08:11:28 pm
lol i thought it was supposed to be blue!
i really did.
right when i started to learn axe i made a prog the displayed "hello world"
I had it go from 0 to the max contrast and back again. over and over again.
i don't think i need to mention it turned blue.
 thought that was supposed to do that.
Title: Re: Bug Reports
Post by: Quigibo on June 16, 2010, 09:04:24 pm
The pause would have to be fairly long, about 50-100μs and more if in 15MHz mode presumably (a little less than "Pause 2").  All it would do is slow down the command and increase the code size.  Since the normal use is not flashing the screen back and forth, its best left to the programmer to decide if they need the pause or not.
Title: Re: Bug Reports
Post by: ztrumpet on June 16, 2010, 09:29:35 pm
Wow, that's pretty odd.  Nice find Quigibo. :)
Title: Re: Bug Reports
Post by: nemo on June 16, 2010, 09:39:26 pm
my contest entry earned me a RAM clear today, i know i was simply trying to get the level loading system working, and i ran the program and instead of my title screen greeting me, i got a RAM clear so i know it was at the beginning of the code. the only additions i made to the beginning were the following:
Code: [Select]
0->L+3->J
deltaList(46,59->String0

(i think i can post that since 1) it isn't very much code and 2) it won't be in my final axe entry, seeing as how that portion and 1/4 of my program is gone)

oh, and it did something to omnicalc's restoremem() feature, since that doesn't work anymore (it had a 100% success rate till now)
i doubt you can find any bugs according to what i can give you, but i thought i should at least note this
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 17, 2010, 01:23:00 am
Okay, I did my research.  This is what appears to be happening.  I believe that there is a very short voltage spike between changing contrast from a very low value to a very high value and vise versa.  You don't see the screen turn blue normally becasue its so fast that you can't even see it.  However, if you alternate the screen very rapidly, the voltage spike appears often enough that it becomes very noticeable.  So this is a faulty hardware problem and there is nothing I can do about it.  I'll just have to trust that you're all being safe about using it.

Here were some clues that led me to my hypothesis:
  • You can't get the calculator to stay in a blue state unless the contrast is constantly changing
  • The degree of blueness is continuous.  There is not a single shade of blue.
  • The degree of blueness is directly proportional to the difference of the values you alternate between
  • The degree of blueness is inversely proportional to the amount of pause you have

All of these suggest that the calculator is NOT in test mode.  So this blue is actually less voltage on average than test mode, but that still doesn't mean its remotely safe.  It probably won't fry your calculator right away like the real test mode, but it can certainly damage it over a longer period.  I absolutely do not recommend exploiting this effect.
Wow exactly what I thought (well, I did not know what caused it but I had it happen on my 83+SE). When shutting down the calc from Mirage on 15 MHz calcs, notice how sometimes the screen quickly flashes to black then turns off. Same happens when reducing contrast to a low level quickly. Some xLIB games uses such method of alternating contrast quickly to create the blue effect. The way they were used is not dangerous, because it's not as bad as test mode, but if you leave the calc this way over a very long period, it could be.

Btw that trick doesn't work on the regular 83+ or emulators. It only works on real 83+SE, 84+ or 84+SE hardware.

Nice find Quigibo! I've been wondering since 2002 why my SE flashed quickly to black when turning it off most of the time
Title: Re: Bug Reports
Post by: Ikkerens on June 17, 2010, 02:41:29 am
The new GrayScale routine (4lv at least) causes some flickerish bars at the bottom-left of the screen.
Emulator doesn't give the same effect.

See screenshot (I created an arrow with my über-paint skillz :P)
Title: Re: Bug Reports
Post by: calc84maniac on June 17, 2010, 02:43:29 am
Hmm... failed to initialize the LCD row value?
Title: Re: Bug Reports
Post by: Ikkerens on June 17, 2010, 02:49:18 am
Here's the source, if it helps :)
Title: Re: Bug Reports
Post by: meishe91 on June 17, 2010, 03:18:18 am
I just typed your code into my calculator and I didn't get any lines at the bottom of the screen. Only thing I did differently was leave off the ending parenthesis but I don't think that'd change anything.
Title: Re: Bug Reports
Post by: Ikkerens on June 17, 2010, 03:30:39 am
I just typed your code into my calculator and I didn't get any lines at the bottom of the screen. Only thing I did differently was leave off the ending parenthesis but I don't think that'd change anything.

Are you using Axe 0.3.0?
And if so, what exactly did you leave away?
Title: Re: Bug Reports
Post by: Quigibo on June 17, 2010, 03:33:45 am
Sounds like there might not be enough delay.  That surprises me since it works on mine and I have the slow LCD driver.  What model calculator are you using and what letter on the back?
Title: Re: Bug Reports
Post by: Ikkerens on June 17, 2010, 03:45:16 am
I'm using an TI-84+
And which letter? Il just write down everything:
CES-003 Class B

2488017502   P-0208J

Copyright © TI 2004
One or more of the following U.S. patents apply
4823311 5377130 5532846 5870319 6118423
Made in china etc....
Backup battery
303 or SR446W

Hope its in there :P
Title: Re: Bug Reports
Post by: meishe91 on June 17, 2010, 03:49:42 am
I just typed your code into my calculator and I didn't get any lines at the bottom of the screen. Only thing I did differently was leave off the ending parenthesis but I don't think that'd change anything.

Are you using Axe 0.3.0?
And if so, what exactly did you leave away?

Ya, I'm using 0.3.0. I actually tried both and got the same results. The only things I left off though was the ending bracket ("]") and the ending parenthesis to the second and fourth Pt-On( command.

This was done on a TI-84+ running OS 2.43. Which letter on the back is it that you look for again? I can't remember.
Title: Re: Bug Reports
Post by: Ikkerens on June 17, 2010, 03:50:33 am
Might be a difference but im running 2.53MP (BrendanW edit)
Title: Re: Bug Reports
Post by: Quigibo on June 17, 2010, 03:57:06 am
Is it possible you were just running a different program previously that might have changed the LCD settings?  See if ALCDFIX (http://www.ticalc.org/archives/files/fileinfo/366/36608.html) makes it work again.
Title: Re: Bug Reports
Post by: Ikkerens on June 17, 2010, 04:00:28 am
Is it possible you were just running a different program previously that might have changed the LCD settings?  See if ALCDFIX (http://www.ticalc.org/archives/files/fileinfo/366/36608.html) makes it work again.

Yeh, that fixed it, another bug solved :)
Title: Re: Bug Reports
Post by: Happybobjr on June 17, 2010, 04:07:09 pm
^ yes it does.. for quick example, look at new rpg demo
Title: Re: Bug Reports
Post by: nemo on June 17, 2010, 04:42:09 pm
Axe doesn't detect whether the arguments for Fill() are in the correct order.
0->{L1}
Fill(200,L1
compiles, but if you run it it'll give you a ram clear.
Title: Re: Bug Reports
Post by: calcdude84se on June 17, 2010, 04:47:22 pm
That's because both the arguments to Fill( are 16-bit numbers, and such numbers can be construed as pointers.
What Fill(200,L1 does is fill L1 bytes starting after the 200th byte, which is something very undesirable.
Basically, there is no way to detect it, because the arguments are indistinguishable.
Title: Re: Bug Reports
Post by: nemo on June 17, 2010, 04:49:33 pm
that doesn't make much sense to me, but thanks. that may be what's been causing my problem for all this time too  :-\
Title: Re: Bug Reports
Post by: calcdude84se on June 17, 2010, 04:57:21 pm
I'll try again :P
A 16-bit number (two bytes) is the type of number generally used in Axe (one byte numbers are used, though with slightly less frequency)
Fill( takes two arguments. The first one is the address from which the fill starts. The second one is how many bytes to fill.
Both of these arguments are 16-bit numbers. The first one is a pointer, the second one just a number. However, despite their very different roles, they look exactly the same to the compiler. So a check is impossible. Also, the overhead necessary to check if you're doing something silly like trying to write to flash (anywhere from the first 16384 to 32768 bytes are flash) is too large and unwieldy.
Note that ASM, or Axe in this case, gives up safety checks for speed.
Title: Re: Bug Reports
Post by: cooliojazz on June 18, 2010, 08:54:11 pm
1st Pass: 28%
ERR: UNKNOWN ERR
Code 3022591
And it changed the first time to
1st Pass: 28%
ERR: UNKNOWN ERR
Code 302 57%
ERR: UNKNOWN ERR
Code 3022188
after I hit enter. I tried a couple more times, and it just quit after the first one the next few times.
Code: (Source) [Select]
.ASBC
While 1
ReturnIf getKey(15)
For(X,0,5)
getKey(X)->{L1+X}
End
For(X,0,5
If {L1+X}:SinReg 343/(440*(e^(X-69/12))),2000:End
End
End
Oh, and you might want to change the Freq( token so it doesn't have a (, since the original doesn't... unless the compiler allows a closing ) if you have the Axe tokens on?...
Title: Re: Bug Reports
Post by: calc84maniac on June 18, 2010, 10:40:14 pm
1st Pass: 28%
ERR: UNKNOWN ERR
Code 3022591
And it changed the first time to
1st Pass: 28%
ERR: UNKNOWN ERR
Code 302 57%
ERR: UNKNOWN ERR
Code 3022188
after I hit enter. I tried a couple more times, and it just quit after the first one the next few times.
Code: (Source) [Select]
.ASBC
While 1
ReturnIf getKey(15)
For(X,0,5)
getKey(X)->{L1+X}
End
For(X,0,5
If {L1+X}:SinReg 343/(440*(e^(X-69/12))),2000:End
End
End
Oh, and you might want to change the Freq( token so it doesn't have a (, since the original doesn't... unless the compiler allows a closing ) if you have the Axe tokens on?...
getKey() only supports constant values. getKey(X) is an invalid statement.
Title: Re: Bug Reports
Post by: Magic Banana on June 18, 2010, 11:18:13 pm
I've got a small bug to report. When trying to use Goto AB instead of Sub(AB):Return, the compiler will throw a Bad Symbol error if you use any parameters when trying to Goto.
Code: (works) [Select]
:Goto AB
Code: (works) [Select]
:Sub(AB,A,B
:Return
Code: (doesn't work) [Select]
:Goto AB,A,B
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 18, 2010, 11:19:24 pm
Is it valid syntax at all, though? I don't even remember if Goto can use arguments at all. Was it added to the new version?
Title: Re: Bug Reports
Post by: nemo on June 18, 2010, 11:20:43 pm
i don't think that's valid syntax. you can't supply arguments to Goto, only sub()
Title: Re: Bug Reports
Post by: Magic Banana on June 18, 2010, 11:29:42 pm
Oh, that probably explains why it didn't work. Maybe in the next version then?
Title: Re: Bug Reports
Post by: cooliojazz on June 19, 2010, 12:32:45 am
Oh, I didn't know that. well, regardless, it generated an unknown error, so...
Title: Re: Bug Reports
Post by: Quigibo on June 19, 2010, 01:30:46 am
Well... although it kind of doesn't make sense to have arguments with a "Goto" it would still lead to an optimization.  Maybe I will add it even if it seems kind of weird, don't know if it will be in the next version

For the getkey thing, yeah, I must have accidentally had it set to display the wrong error message.  That should be a bad symbol error since it was expecting a constant, but got a variable.  Thanks for pointing that out.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 19, 2010, 10:17:49 am
I wonder what would be the main use of variables in Getkey()? I am curious if it would be worth implementing. Would it cause  a big slow down/size increase? That said, I like how we can do A-getkey(2)+getkey(3)->A or stuff like that so it's already pretty good :P
Title: Re: Bug Reports
Post by: calcdude84se on June 19, 2010, 03:26:18 pm
Variables in getKey() would either require another set of keycodes, or conversion and a small slowdown (It's actually pretty straightforward, it just may be more efficient to force other keycodes). The reason variables aren't allowed is that you need different codes, and that conversion is normally done on compile-time.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 19, 2010, 03:47:04 pm
oh ok x.x

I guess it might be best to not bother, then. Personally I am fine even if they aren't implemented anyway.
Title: Re: Bug Reports
Post by: calcdude84se on June 19, 2010, 04:04:58 pm
Yeah, they're not necessary for most things. The best uses I can up with are ridiculous, absurd, or both. :P (Or they are for pointless utilities)
Title: Re: Bug Reports
Post by: Builderboy on June 20, 2010, 02:40:17 am
So with the new version and with the new Auto Token Switching, it updates if you change the period to a different token, but it does not if you merely delete the token.  And then it causes some interesting display issues when moving the cursor around sensitive tokens.

EDIT: Seems it also doesn't catch the update when you insert a period into the header instead of add it
Title: Re: Bug Reports
Post by: Quigibo on June 20, 2010, 02:52:15 am
Yeah, I know.  I purposely didn't do that in the screenshot.  The OS only decides to redraw the tokens when it thinks they might need changes unfortunately.  I don't want to have the new tokens update the display more often then it should becasue that might cause speed issues especially when scrolling.  Its okay though becasue normally you aren't going to be changing the header since its the first thing you write.
Title: Re: Bug Reports
Post by: Builderboy on June 20, 2010, 02:57:12 am
Ah i get it now, if you insert or delete, the OS detects if the line overflows, or flows back, and only refreshes the screen if it does.  When replacing a token, it must refresh the whole screen automatically?  Either way i just wanted to point it out :P Glad that it was already noted ^^
Title: Re: Bug Reports
Post by: nemo on June 21, 2010, 12:25:35 am
Unknown Err. code: 3A24553. Ti 84+SE 2.41 OS. the program was archived and got the error at 89% on the first pass. i unarchived the program and scrolled to the part of the source that was wrong. it turned out i had sub(r1+3,r2) instead of sub(C,r1+3,r2). i changed it and it compiled fine, but you may want a different error code than unknown err for missing sub arguments.. i thought there already was one?
Title: Re: Bug Reports
Post by: squidgetx on June 21, 2010, 12:41:20 pm
I hit "compile" on the main Axe menu and the calculator crashed....

I am not sure as to why..maybe I have too much stuff on my calc (omni, os 2.53, zStart, and mirage hooks)

Title: Re: Bug Reports
Post by: ztrumpet on June 21, 2010, 01:00:35 pm
I hit "compile" on the main Axe menu and the calculator crashed....

I am not sure as to why..maybe I have too much stuff on my calc (omni, os 2.53, zStart, and mirage hooks)


That happened once to me too (on 0.2.6).  I have no idea why. ;.;
Title: Re: Bug Reports
Post by: Magic Banana on June 21, 2010, 01:37:38 pm
Really? I always have Mirage, Omnicalc, and Calcutil hooks active and nothing horrible has happened to me (yet).
Title: Re: Bug Reports
Post by: Happybobjr on June 21, 2010, 01:40:40 pm
after i use axe for a while.  3.0 ,  then screw up with a normal calculator command that should give me syntax error,  it crashes/ ram cleared
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 21, 2010, 02:08:02 pm
I found another little bug, altough nothing that can be triggered unintentionally:

There are no checks if you try to create an AppVar of 0 bytes size. It messes up the memory menu after creating it

EDIT screenshot. Note, the program code was

.SSSS
"A"->Str1
Getcalc(Str1,0)
Title: Re: Bug Reports
Post by: ztrumpet on June 21, 2010, 02:15:49 pm
Yikes, that's crazy!  I didn't think the VAT could be corrupted that easily.  Wow. :D
Title: Re: Bug Reports
Post by: Quigibo on June 21, 2010, 02:17:30 pm
I forgot to mention, you should ram clear before installing Axe 0.3.1 if you upgraded from 0.3.0 becasue the hooks are different.  That might explain any one time freezing from unrelated events.

DJ, I don't add checks becasue its a waste of memory.  Its up to the programmer to add checks themselves before the actual appvar is created.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 21, 2010, 02:21:09 pm
Aah ok it's up to you really. I just wanted to point it out in case it's something you might have missed :P

Btw on my Nspire I forgot to RAM clear before using Axe 0.3.1 and on top of that I forgot my calc was messed up due to a bad program I ran a week ago, and forgot to RAM clear then, and when I opened Axe, Application was selected in the shell options, even if I don't have the private beta ;D

A RAM clear fixed it, though. It did not let me compile into APP anyway :P
Title: Re: Bug Reports
Post by: calc84maniac on June 22, 2010, 11:28:25 am
after i use axe for a while.  3.0 ,  then screw up with a normal calculator command that should give me syntax error,  it crashes/ ram cleared
That might not be Axe related. I have had that happen with MirageOS. It's a bug that occurs when you rename an archived program and then Garbage Collect. When you rename programs with MirageOS (and many other utilities, I'm sure), the name in RAM changes but the name in archive doesn't. When the OS is Garbage Collecting and it finds the name in archive, it expects it to be in RAM as well. If not... well, you get the error handler glitch.
Title: Re: Bug Reports
Post by: Builderboy on June 23, 2010, 01:08:20 am
So i am having a slight problem with the error stroller.  Specifically a piece of code like this

Code: [Select]
Pt-Off(2,2,1+1+1+1+Pic3
I added the 1+1 to make Pic3 go off to the next line.  When Pic3 is undefined, and the error is scrolled to, it does not place Pic3 on the correct line, and the text gets kinda mangled. I am using the 0.3.0Application Beta if that means anything.
Title: Re: Bug Reports
Post by: ztrumpet on June 23, 2010, 10:43:40 am
after i use axe for a while.  3.0 ,  then screw up with a normal calculator command that should give me syntax error,  it crashes/ ram cleared
That might not be Axe related. I have had that happen with MirageOS. It's a bug that occurs when you rename an archived program and then Garbage Collect. When you rename programs with MirageOS (and many other utilities, I'm sure), the name in RAM changes but the name in archive doesn't. When the OS is Garbage Collecting and it finds the name in archive, it expects it to be in RAM as well. If not... well, you get the error handler glitch.
This also happens if you hide archived programs. :)
Title: Re: Bug Reports
Post by: LordConiupiter on June 23, 2010, 04:22:12 pm
something strange going on here. It's not really a bug I thing, thoug it's some kinda error.
In one program I save 2 pics to an AppVar, and in another one I try to use them as Pics, which isn't really working for me.
here is my source:

the one:
Code: [Select]
:.PRGONE
:[Pic0]→Pic0
:[Pic1]→Pic1
:"vGNTPICS→Str1
:GetCalc(Str1,1536)→P
:Copy(Pic0,P,756
:Copy(Pic1,P+756,756

the another one:
Code: [Select]
:.PRGTWO
:"vGNTPICS→Str1
:GetCalc(Str1→P
:[Pic0]→Pic0
:[Pic1]→Pic1
:Copy(P,Pic0,756
:Copy(P+756,Pic1,756
:Copy(Pic0,{L6},756)
:Copy(Pic1,{L3},756)
:For(K,0,50
:DispGraph[sup]r[/sup]
:Pause 16
:End

Both Generated by SourceCoder (http://sc.cemetech.net)
© 2005-2010 Cemetech (http://www.cemetech.net)
Title: Re: Bug Reports
Post by: Darl181 on June 23, 2010, 04:28:38 pm
I tried making a porgram in which you can select an ascii character and store it in the Ans variable.  After the main loop, i put in
C►Char→Ans
The parser (0.3.1) gives me a 'bad symbol' thing then gives 'unknown err' 'code: 3A24553'.
Is there a table or document anywhere describing what the different error codes mean?
And why won't it compile?

My session's about to run out again. I'll be back tomorrow.
Title: Re: Bug Reports
Post by: calcdude84se on June 23, 2010, 04:32:28 pm
In program one, you're always using the pics that were there at compile time, and I don't know if that's what you want. (But there isn't currently a way to read things that aren't programs or appvars at compile time.)
Anyway, why are you storing to P+15? You want to store to the beginning of the appvar, so P is the correct destination. Those fifteen bytes that make up the program name, location, and size, are not included here.
Same for the second Copy(, it should just be P+768. (Actually, since there is no last row, the appvar size should be 1512 and the second copy destination P+756). In the second program, you don't need to reserve space in it, and should just copy directly to L3 and L6.
Edit: Fixed versions:
Code: [Select]
:.PRGONE
:[Pic0]→Pic0
:[Pic1]→Pic1
:"vGNTPICS→Str1
:GetCalc(Str1,1512)→P
:Copy(Pic0,P,756
:Copy(Pic1,P+756,756

Code: [Select]
:.PRGTWO
:"vGNTPICS→Str1
:GetCalc(Str1→P
:Copy(P,L6,756
:Copy(P+756,L3,756
:For(K,0,50
:DispGraph[sup]r[/sup]
:Pause 16
:End
Title: Re: Bug Reports
Post by: calc84maniac on June 23, 2010, 04:33:56 pm
something strange going on here. It's not really a bug I thing, thoug it's some kinda error.
In one program I save 2 pics to an AppVar, and in another one I try to use them as Pics, which isn't really working for me.
here is my source:

--snip--
Code: [Select]
:Copy(Pic0,{L6},756)
:Copy(Pic1,{L3},756)
should be
Code: [Select]
:Copy(Pic0,L6,756)
:Copy(Pic1,L3,756)
since you don't want to read the memory and pass that value as an argument to Copy().
Title: Re: Bug Reports
Post by: LordConiupiter on June 23, 2010, 04:41:44 pm
yes, I know that, and that's exactly what I did, but this is the way cemetech converts it, to show that it's a single token.
@calcdude: it looks more like it with your code, but the whole image is shown with the upper part down, and the lower part up.
In my case it is a mans head and upper body, so his head is shown at the bottom of the screen, and his body at the top.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 23, 2010, 04:59:13 pm
Does this happen everytime we use L3/L6 in SourceCoder? If so, then this seems like it should be reported to KermM. It could mess up some Axe programs and hinder people who use SC to create Axe programs (I sometimes do, for simple stuff, or for small edits)
Title: Re: Bug Reports
Post by: LordConiupiter on June 23, 2010, 05:00:30 pm
yes, it allways does.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 23, 2010, 05:13:12 pm
Reported on Cemetech.
Title: Re: Bug Reports
Post by: KermMartian on June 23, 2010, 05:22:18 pm
yes, it allways does.
You mean if you type {L3} into the editor and then export as .8xp, it's {L3} on the calculator, not L3? That's not right....

Edit: I couldn't replicate your issue.  I put this source into SourceCoder, and receive the following .8xp file (attached).  Also, please update me with a response in this Cemetech topic, since I don't visit here often:
http://www.cemetech.net/forum/viewtopic.php?p=100793#100793

Code: [Select]
:{3,2,1→{L3}
:{5,4,2→{L6}
Title: Re: Bug Reports
Post by: Quigibo on June 23, 2010, 05:33:25 pm
C►Char→Ans
The parser (0.3.1) gives me a 'bad symbol' thing then gives 'unknown err' 'code: 3A24553'.
Is there a table or document anywhere describing what the different error codes mean?
And why won't it compile?

You can't display something and then store it on the same line.  All the ►Something expressions must terminate there.  You need to have them on separate lines:
Code: [Select]
Disp C►Char
C→Ans

Thanks for catching the wrong error message by the way, I'll fix that.
Title: Re: Bug Reports
Post by: calc84maniac on June 23, 2010, 05:44:11 pm
yes, it allways does.
You mean if you type {L3} into the editor and then export as .8xp, it's {L3} on the calculator, not L3? That's not right....

Edit: I couldn't replicate your issue.  I put this source into SourceCoder, and receive the following .8xp file (attached).  Also, please update me with a response in this Cemetech topic, since I don't visit here often:
http://www.cemetech.net/forum/viewtopic.php?p=100793#100793

Code: [Select]
:{3,2,1→{L3}
:{5,4,2→{L6}
No, the problem is that L3 shows up as {L3} in Sourcecoder, which is a valid (and completely different) Axe statement.
Title: Getkey() issue
Post by: nemo on June 24, 2010, 11:56:14 am
the following code doesn't work:
Code: [Select]
.TEST
ClrDraw
ClrHome
DiagnosticOff
"Press 4-8->Str1
Disp Str1,i
0->S
Repeat S
If getKey(19)
6->S:End
If getKey(27)
5->S:End
If getKey(28)
8->S:End
If getKey(35)
4->S:End
If getKey(36)
7->S:End
End
Disp S>Dec,i
Pause1000
i've checked and re-checked the getKey codes, i'm sure they're all correct.
here the outputs for key pressed:

key pressed       output (S)
4                     4
5                     4
6                     5
7                     7
8                     8

rearranging the getKey() s changes the outputs*, so i figured this may be a parser problem.

*for example, if you put the If getKey(19):6->S:End at the end of the Repeat() loop, the output of pressing [4] gives the number 6.
Title: Re: Bug Reports
Post by: Darl181 on June 24, 2010, 03:17:08 pm
@quigibo
What I'm trying to do is store the character in the ans variable, not the value.
Is that even possible, or does Ans have to be a number?
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 24, 2010, 03:18:46 pm
It has to be a number from -32768 to 32767 (or maybe it was 0 to 65535)
Title: Re: Bug Reports
Post by: FinaleTI on June 24, 2010, 03:21:35 pm
I'm pretty sure it has to be a number right now, and the number outputted depends on whether or not the value pointed to in the program was signed (0-65535) or unsigned (-32768-32767).
Title: Re: Bug Reports
Post by: LordConiupiter on June 24, 2010, 03:26:14 pm
but what was now wrong in my code? It's still not working! Is it perhaps a bug in Copy from an AppVar? Or is it Copy to an AppVar that doesn't work the correct way?
Title: Re: Bug Reports
Post by: nemo on June 24, 2010, 03:51:39 pm
as far as i know you can't store the character into a variable. the ASCII character is represented by a number anyway. >Char just converts a number into something (a character) that a human could recognize.

Coniupiter: 2 things. 1) are you using [2nd][8] to describe your appvar or the lowercase 'v'? 2) just copying bytes to L3 won't display them to the buffer, i don't think. except L6? try this:
Code: [Select]
:.PRGTWO
:"vGNTPICS→Str1
:GetCalc(Str1→P
:conj(P,L6,756
:P+756→DispGraph
:Repeat getKey(0)
:DispGraph^r
:End
i don't think that my code will do exactly what you want it to but it might be close...
Title: Re: Bug Reports
Post by: FinaleTI on June 24, 2010, 04:02:38 pm
Actually, that would set the first image to the buffer, and just display the second, which would not work when DispGraphr is called, I'm pretty sure.
This might work better.

Code: [Select]
:.PRGTWO
:"vGNTPICS→Str1
:GetCalc(Str1→P
:conj(P,L6,756
:StorePic
:conj(P+756,L6,756
:Repeat getKey(0)
:DispGraph^r
:End
Title: Re: Bug Reports
Post by: LordConiupiter on June 24, 2010, 04:05:54 pm
L3 is working, and so is L6, but only when I copy the Pics straight into the Axe program, and then Copy them to L3 and L6.
But I want to load the Pics into an AppVar, and then load them from there into L3 and L6, which are the back and normal buffers
Title: Re: Bug Reports
Post by: nemo on June 24, 2010, 04:12:57 pm
so it's the appvar with the problem? well, as i said, are you using the lowercase v ( [alpha][alpha][6] if you have lowercase enabled) or are you using [2nd][8]?

edit: regarding my bug, i finally found a version that works. ordering the If statements like so gives the desired effect:
Code: [Select]
Repeat S
If getKey(19)
6->S:End
If getKey(36)
7->S:End
If getKey(35)
4->S:End
If getKey(28)
8->S:End
If getKey(27)
5->S:End
End
this specific sequence of If statements works but the fact that switching them around doesn't is my bug. took me an hour just to find the correct order  :-\
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 24, 2010, 05:00:26 pm
@Nemo, mhmm it seems a bit weird. Could this be an Axe bug? I think Quigibo mentionned to me once there might not be enough delay for direct keypresses so certain keys are not detected in extremly fast programs
Title: Re: Bug Reports
Post by: nemo on June 24, 2010, 05:05:04 pm
i'm not sure DJ, i tried putting a Pause 50 at the beginning of each If statement to no avail but that didn't work either. also, if you notice it's not that the keypresses aren't being detected, it's just either a) the wrong value is being stored into S or b) the wrong keypress is being detected. because that code always exits if you press one of the keys 4-8, meaning it IS registering the fact that a key has been pressed.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 24, 2010, 05:06:02 pm
Mhmm ok. Well I don't know then. Quigibo might want to look into this.
Title: Re: Bug Reports
Post by: calcdude84se on June 24, 2010, 05:07:42 pm
Also note that those keys form boxes, which can make the calc think other keys are being pressed. (The keyboard hardware is silly at times)
In addition, 36/35 and 27/26 are near each other (which corresponds to being in the same column and group), which probably helps with response times.
Edit: That pause doesn't help as the speed problem is w/in the getKey() itself. :(
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 24, 2010, 05:14:27 pm
I thought this box thing was only on Wabbitemu?

I am so glad the arrow keys won't do that as much at least. I only saw it happen with the left arrow when pressing several keys at once sometimes.
Title: Re: Bug Reports
Post by: calcdude84se on June 24, 2010, 05:18:00 pm
It is in Wabbit, courtesy of it being copied directly from the calc hardware :P
Yeah, luckily, the arrow keys are in their own group, otherwise things would be so much worse...
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 24, 2010, 05:21:11 pm
yeah but what I meant is does it happnens on the real calc too?
Title: Re: Bug Reports
Post by: nemo on June 24, 2010, 05:22:17 pm
yes. i know from experience.
Title: Re: Bug Reports
Post by: ztrumpet on June 24, 2010, 05:23:56 pm
yeah but what I meant is does it happnens on the real calc too?
Yeah, unfortunately it does. :(
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 24, 2010, 05:33:13 pm
Ouch :X

Well If I ever make a game that requires the usage of keys other than arrows, I'll need to be careful.
Title: Re: Bug Reports
Post by: Quigibo on June 24, 2010, 11:20:18 pm
Is your calc in Full speed mode?  That would make the delays too short and the key group would not be switched properly.  You have to take it out of full speed mode to use the getkey() command.  Maybe I'll triple the delay next version so that it works better in full.  It's 2-3 more bytes, but its a subroutine so 2-3 bytes total for the whole program.  Any added delay is negligible.  We're talking about 2 microseconds here.
Title: Re: Bug Reports
Post by: nemo on June 24, 2010, 11:22:09 pm
no, this is 6Mhz.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 24, 2010, 11:48:17 pm
2 microseconds doesn't seem too bad. I guess the only real impact would be on programs that uses all keys in one loop, but even then, the framerate drop would barely be noticeable.
Title: Re: Bug Reports
Post by: Builderboy on June 25, 2010, 01:26:06 am
So i am having a slight problem with the error stroller.  Specifically a piece of code like this

Code: [Select]
Pt-Off(2,2,1+1+1+1+Pic3
I added the 1+1 to make Pic3 go off to the next line.  When Pic3 is undefined, and the error is scrolled to, it does not place Pic3 on the correct line, and the text gets kinda mangled. I am using the 0.3.0Application Beta if that means anything.

o.O Did anybody see this?  I tested it with the most recent version and it still gets all messed up
Title: Re: Bug Reports
Post by: Quigibo on June 25, 2010, 04:41:56 am
I am aware of the error, and I already fixed it.  It had to do with displaying the error on the top of the screen instead of the bottom.
Title: Re: Bug Reports
Post by: Runer112 on July 01, 2010, 01:27:57 pm
I'm not sure if this is a bug or if this like this for a reason, but the following program:
Code: [Select]
.TEST
!If -1→A+1
Disp "HI"
Pause 5000
End
Compiles to 58 bytes, while the following program:
Code: [Select]
.TEST
If -1→A=-1
Disp "HI"
Pause 5000
End
Compiles to 70 bytes? The only logical conclusion from this is that the =-1 comparison consumes 13 bytes, although it's documented as only consuming 9.

And why don't comparisons like this work in the first manner anyways if it's smaller?

EDIT: Hold on, just realized I was using Axe 0.3.0, let me check that this happens in 0.3.1.

EDIT 2: Yes, this occurs with Axe 0.3.1 as well.
Title: Re: Bug Reports
Post by: Quigibo on July 01, 2010, 03:21:09 pm
You're right, the negative numbers do not appear to be auto-optimizing.  I'm fixing this now.
Title: Re: Bug Reports
Post by: Runer112 on July 01, 2010, 04:08:33 pm
And why is it that equalities like that aren't optimized into statements like the first example? It's always smaller and, unless I'm missing something, it works the same way.
Title: Re: Bug Reports
Post by: Quigibo on July 01, 2010, 04:12:16 pm
Because then you wouldn't be able to use it with logical operators.  Good luck trying to do A=5 xor (B=3)
Title: Re: Bug Reports
Post by: Runer112 on July 01, 2010, 04:17:19 pm
Because then you wouldn't be able to use it with logical operators.  Good luck trying to do A=5 xor (B=3)

This wouldn't work?
Code: [Select]
If A-5 xor (B-3)
Title: Re: Bug Reports
Post by: Quigibo on July 01, 2010, 04:23:46 pm
Nope.  Say A=6 and B=5 The answer should be 0 since neither condition is true.  But you end up with 1 xor 2 = 3 which is non-zero.
Title: Re: Bug Reports
Post by: nemo on July 01, 2010, 04:24:34 pm
runer, quigibo's example can be optimized to A-5 xor (B-3), but what about the following:
A=6 and (B=2)
A=2 or (B=3)

these don't work. i think you can only substitute equivalence with subtracting when it's a single statement, or you use xor.
Title: Re: Bug Reports
Post by: Quigibo on July 01, 2010, 04:35:08 pm
nemo, the only reason those don't work is becasue you're not using De Morgan's law, which is part of the reason I can't automatically optimize it.  The subtraction actually optimizes the not equal sign not the equal sign btw.

If A=6 and (B=2)

can become:

!If A-6 or (B-2)

However, that " or " has to be the 16-bit binary " or " (the plot style token) and so it reduces the effective optimization a little bit.  But it's still an optimization I'm sure.
Title: Re: Bug Reports
Post by: Runer112 on July 01, 2010, 04:35:51 pm
I'm confused, why does 1 xor 2 = 3
Title: Re: Bug Reports
Post by: Quigibo on July 01, 2010, 04:38:27 pm
In binary,

%00000001 = 1
%00000010 = 2
apply xor to each bit
%00000011 = 3
Title: Re: Bug Reports
Post by: Runer112 on July 01, 2010, 04:40:30 pm
Oh, xor is bitwise? Not like a TI-OS xor?
Title: Re: Bug Reports
Post by: nemo on July 01, 2010, 04:42:33 pm
look at the commands list. there's both a xor like in TI OS, and a bitwise xor ( it's a plot style token ).
bitwise:
1 xor 2 = 3
TI OS:
1 xor 2 = 0
Title: Re: Bug Reports
Post by: Runer112 on July 01, 2010, 04:47:38 pm
nemo, I believe both in Axe are bitwise. The plot-style ones are just 16-bit whereas the normal ones are 8-bit.
Title: Re: Bug Reports
Post by: LordConiupiter on July 01, 2010, 05:12:32 pm
In binary,

%00000001 = 1
%00000010 = 2
apply xor to each bit
%00000011 = 3

it's not the difference between 16 or 8 bit this time, but between all bits at once, or bit  by bit.
so not 1 xor 2, this will result 0
but 1 xor 0 results 1 at the least significant bit
and 0 xor 1 also results 1 at the second least significant bit
this results a 3
Title: Re: Bug Reports
Post by: ztrumpet on July 01, 2010, 05:13:04 pm
nemo, I believe both in Axe are bitwise. The plot-style ones are just 16-bit whereas the normal ones are 8-bit.
I'm pretty sure (but not 100%) that nemo's right.  Quigibo? :)

Edit:  He was wrong, and so was I...  almost 100% != correct... ;D
Title: Re: Bug Reports
Post by: nemo on July 01, 2010, 05:14:55 pm
i'm wrong. i tested it on-calc in axe, it must be bitwise since where A=6 and B=5, A-5 xor (B-3) results in true.
Title: Re: Bug Reports
Post by: Deep Toaster on July 01, 2010, 09:55:24 pm
Oh, so when we use logical operators, we actually have to think :D
Title: Re: Bug Reports
Post by: Builderboy on July 02, 2010, 04:24:15 am
Hmmm im having weird problems with interrupts.  Sometimes i've had them randomly turn themselves off.  Here is the exact code:

Code: [Select]
.AXE
ClrDraw
DiagnosticOff
FnOn
fnInt(IN,0)

9->C

Repeat getKey(15)
Pxl-On(C/2/2/2/2,0
DispGraph
End

LnReg
Return

Lbl IN
C+1->C

I use the pixel moving thing because displaying text messes with interrupts i also noticed.  Every one in a while when you run the program the pixels will stop advancing.  I have run some tests, and there is no crash, the rest of the program continues to run, but the interrupts have turned off.
Title: Re: Bug Reports
Post by: Quigibo on July 02, 2010, 06:28:05 am
Hmmm... I'm almost certain that the problem is with the DispGraph routine becasue it doesn't happen with just displaying C as a number.  Try adding an fnOn after each dispgraph.

Calc84maniac, are you sure the

ld a,i
push af
di

pop af
ret po
ei
ret

Will preserve interrupts even when these commands themselves are interrupted?
Title: Re: Bug Reports
Post by: jnesselr on July 02, 2010, 04:34:54 pm
The commands won't get interrupted, because you are doing di at the start of the code.  I don't know what ret po is, but I bet that would be your problem, which would cause it to not get to the ei line.
Title: Re: Bug Reports
Post by: calcdude84se on July 03, 2010, 09:29:41 am
Quigibo: I'm pretty sure that it would still preserve interrupt status, even when interrupted, because a properly done interrupt (such as the TI-OS one, and the one built into Axe) might as well not have executed as far as the other code is concerned (as long as you're not using the shadow regs, of course).
graphmastur: When you do "ld a,i" or "ld a,r" the current interrupt status (enabled, disabled) is stored in the parity flag. Set (pe) means interrupts are enabled, reset (po) means they were disabled.
So, if interrupts were disabled before, the "ret po" line will cause a return, skipping the re-enabling of interrupts.
Title: Re: Bug Reports
Post by: Quigibo on July 04, 2010, 04:18:39 pm
Most interrupts are currently not compatible with applications at the moment.  Any system call will not switch the correct page back to the application and cause crazy stuff to happen.  There is a fix I can do by making sure I swap the page before the interrupt quits which is what I'm going to have to do for applications.  So for now, DO NOT use interrupts with applications.
Title: Re: Bug Reports
Post by: Runer112 on July 05, 2010, 02:39:45 pm
I'm not entirely sure if this is a bug report or a feature request, but attempting to use a negative number in a Data() array returns a bad number error. (This occurs even if you use an r modifier)
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 05, 2010, 04:56:38 pm
I think when storing data this way, it needs to be unsigned, meaning without r it's 0 through 255, not -128 through 127, and with r, it's 0 through 65535, not -32768 through 32767.
Title: Re: Bug Reports
Post by: calc84maniac on July 05, 2010, 05:06:09 pm
Most interrupts are currently not compatible with applications at the moment.  Any system call will not switch the correct page back to the application and cause crazy stuff to happen.  There is a fix I can do by making sure I swap the page before the interrupt quits which is what I'm going to have to do for applications.  So for now, DO NOT use interrupts with applications.
I don't think that would be the problem. Bcalls always swap the previous page back in after completion. The real problem is when executing a bcall outside of an interrupt and the interrupt fires while the page is swapped. The solution to this would be to swap the page upon interrupt and restore it upon completion.
Title: Re: Bug Reports
Post by: Runer112 on July 05, 2010, 06:18:37 pm
This isn't a problem with the parser, just the Auto Opts file. Try to spot the (once seen, very gross) error:

Code: [Select]
SHORT means less than 256 bytes
CONST means any size
=/= is a "not equal sign"
>=  is a "greater than or equal sign"
<=  is a "less than or equal sign"
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 05, 2010, 06:56:27 pm
Do you mean SHORT being less than 256 bytes? Bytes shouldn't be there since short is one byte and it's the bit value that can range within 256 values
Title: Re: Bug Reports
Post by: ztrumpet on July 05, 2010, 09:32:22 pm
Oooh.  That's a nice find Runer.  Wow. :P
Title: Re: Bug Reports
Post by: Quigibo on July 06, 2010, 12:55:19 am
I'm not entirely sure if this is a bug report or a feature request, but attempting to use a negative number in a Data() array returns a bad number error. (This occurs even if you use an r modifier)
I will fix that thanks!

Also, I could have sworn I fixed the wording there becasue I do remember doing that, I guess it just didn't make it to the update hehe.
Title: Re: Bug Reports
Post by: Quigibo on July 08, 2010, 05:32:03 am
This isn't actually a bug report since the feature is not out yet, but I thought it was interesting enough to mention.  I finished writing the circle drawing routine, but I did not add checks for negative radii.  I figured it would see the number as an unsigned number and thus not draw anything because it would all be outside the screen.  Instead, I got this result, it appears to be some kind of anti-circle which actually looks awesome.  But I still think I'm going to get rid of it and just do the check for bad radii values so this won't happen accidentally.  But I still can't figure out why this happens, I'm just using a very standard midpoint algorithm, its so weird...
Title: Re: Bug Reports
Post by: Deep Toaster on July 08, 2010, 06:20:01 am
That looks awesome! Why not keep it? People can check for negative radii on their own, and this way they can also use that ... thing ... if they want.
Title: Re: Bug Reports
Post by: ztrumpet on July 08, 2010, 10:04:53 am
I think you should keep it!  It looks awesome!  It would just have to be a "unknown special feature". :D  It's really cool! ;D
Title: Re: Bug Reports
Post by: squidgetx on July 08, 2010, 10:48:12 am
That looks pretty cool

Anyway, here's another Unknown Err bug; it gives me a hex error. I press prgm, then it rages at me :x

Source is N (1), if anyone can get it to work, it's the first few minutes of MJ's Thriller in Quigi's music player (except i deleted the sprite and stuff to save space - press any key to start playing) :P
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 08, 2010, 12:31:33 pm
Wow Quigibo that looks cool ;D It could be useful for some animations I am sure :P

Also that circle routine seems so fast and looks MUCH better than the TI-BASIC ones.

Squidget, your source file is locked. It won't show in EDIT menu nor the Axe menus
Title: Re: Bug Reports
Post by: TIfanx1999 on July 08, 2010, 12:32:03 pm
@Quigibo: I think you should keep it in as well. That could make for some really interesting looking effects!
Title: Re: Bug Reports
Post by: Michael.3545 on July 08, 2010, 12:49:58 pm
Your anti-circle appears to be two hyperbolas, one on the x axis and one on the y.  I admit that it looks cool, but I don't really see how this could be helpful for game programming.  Unless someone can come up with an idea on how this could be useful, I agree with Quigibo that it should be removed.  This would just confuse new Axe programmers.   :-\
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 08, 2010, 12:51:34 pm
Your anti-circle appears to be two hyperbolas, one on the x axis and one on the y.  I admit that it looks cool, but I don't really see how this could be helpful for game programming.  Unless someone can come up with an idea on how this could be useful, I agree with Quigibo that it should be removed.  This would just confuse new Axe programmers.   :-\
RPG magic spells. For high end spells such as Holy, people will often use random fractals. It could be used for other kind of animations as well. That said if it confuses Axe coders too much I suggest to remove it, though.
Title: Re: Bug Reports
Post by: TIfanx1999 on July 08, 2010, 01:05:03 pm
RPG magic spells. For high end spells such as Holy, people will often use random fractals. It could be used for other kind of animations as well.
Exactly what I was thinking. :)
Title: Re: Bug Reports
Post by: Magic Banana on July 08, 2010, 01:06:34 pm
Your anti-circle appears to be two hyperbolas, one on the x axis and one on the y.  I admit that it looks cool, but I don't really see how this could be helpful for game programming.  Unless someone can come up with an idea on how this could be useful, I agree with Quigibo that it should be removed.  This would just confuse new Axe programmers.   :-\

There's always someone who can find a way to use it.  ;)

I think that it's a pretty cool feature. As long as it doesn't cause any problems and it's properly documented, I think that it would be fine as an extra feature.
Title: Re: Bug Reports
Post by: ztrumpet on July 08, 2010, 01:30:10 pm
I think it's fine, as someone will use it if it's there.  It's like Circle(x,y,r,{i in basic.  People add the {i because it's there and we've found a way to use it. :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 08, 2010, 02:32:12 pm
THat reminds me...

Could some sort of anti-aliasing be used for circles? Once the next Axe comes out, I would like to experiment with that...
Title: Re: Bug Reports
Post by: squidgetx on July 08, 2010, 02:33:19 pm
Woops, sourcecoder locked it.

Circles look nice; will probably help me in my contest entry...heh heh

and I don't think it's much of an issue; if people are testing their programs and they see this, they'll probably go back into their source and realize that they used a bad radii value :P
Title: Re: Bug Reports
Post by: Builderboy on July 08, 2010, 02:34:49 pm
what do you mean by that DJ?

And i would say keep the funny hyperbola glitch as long as it cant result in a crash ^^ Looking nice and fast and awesome :D
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 08, 2010, 02:54:43 pm
I would need to do it and show the code in action to explain what I mean. I could maybe attempt a TI-BASIC demo, though, or if someone post an Axe made circle routine I could use it to show you.
Title: Re: Bug Reports
Post by: Builderboy on July 08, 2010, 02:59:30 pm
Yeah sometimes its easier to explain things with images (most of the time actualy) hmmm Basic could work, what about a image program like paint?
Title: Re: Bug Reports
Post by: Quigibo on July 08, 2010, 03:52:46 pm
I know the circle can be used for cool effects, but what I'm thinking is that its far more useful for a circle to disappear with a small radii than it is for a random effect to occur.  The first would be used far more often, and using the min() command each time would be a hassle and increase the code size.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 08, 2010, 11:45:00 pm
Yeah I guess it's better to make the routine so it is as convenient as possible for the average user, not for the few people who may use it for unconventional purposes (like the magic animation)

Also someone could simply write his own circle routine and attempt at doing that animation manually anyway if he absolutely needs it
Title: Re: Bug Reports
Post by: cooliojazz on July 09, 2010, 12:11:45 am
Unknown Error: 3224869
I get this after I get a bad symbol error, and try to scroll to it.
This code is causing the error:
Code: [Select]
For(P,0,7)
For(O,0,15)
Output(O,P,{Str1+{O*4+(P*64)+(theta)+3}+({Str1+{O*4+(P*64)+(theta)+2}*2)+({Str1+{O*4+(P*64)+(theta)+1}*4)+({Str1+{O*4+(P*64)+(theta)}*8)}>Frac
End
End
Repeat getKey:End
Title: Re: Bug Reports
Post by: Quigibo on July 09, 2010, 02:33:04 am
Whoops!  What was supposed to happen was if the source is in archive and you try to scroll to the error it quits instead and if the source file is not found on the calculator at all... then something is terribly wrong so it gives an unknown error.  I accidentally switched these 2 conditions lol.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 09, 2010, 02:36:32 am
That happens ;D
Title: Re: Bug Reports
Post by: Builderboy on July 09, 2010, 02:38:09 am
It seems the line -{N}r isn't handled correctly, it gives me weird values and has been the source of much a headahe the last few days x.x
Title: Re: Bug Reports
Post by: Quigibo on July 09, 2010, 03:45:58 am
Not again ahhhh...  >:(

This is like the 5th time I've had to redo the negative numbers.  Is probably one of the most complicated parts about the parser since I not only have to parse it correctly, but also automatically optimize things like making a subtraction of a negative number an addition or ignoring double negatives for example.  Its extremely difficult for 2 reasons.  First of all, they don't behave like normal functions because they have no end parenthesis.  It would be a breeze to implement Neg() as a function or even X% where % is some kind of postscript symbol like the "squared" button.  But NO! I have to figure out where to put the closing parenthesis and its a lot harder than it sounds.  In builderboy's problem it was putting the parenthesis like this: -({R)} so making R negative instead of {R}.  The second reason negatives are annoying and confusing is that when the parser reaches a negative sign, it has no idea if the expression is a constant or variable because the 2 are handled very differently.  I have to use some look ahead parsing for that which just complicates things further.

Anyway, I've fixed the problem.  Hopefully I will find a better system for this soon.
Title: Re: Bug Reports
Post by: Builderboy on July 09, 2010, 04:11:02 am
Yikes that sounds like a whole lot of not fun :( imma just using -1* right now so it's all good
Title: Re: Bug Reports
Post by: Deep Toaster on July 09, 2010, 08:35:29 am
Sorry this is so late (I hate being in a different time zone (BST) from anyone else :(), but I if Axe were to add code that automatically checks whether the radius is negative, wouldn't it inflate the code? This would be a bigger problem than having the user do a min( as it would affect everyone's code, even if the radius never would go negative. Besides, the only plausible instance I can think of right now of a circle radius being negative (unless the author purposely hard-coded it that way for some reason) is where user input affects it (as in your example), so IMHO, it might not be worth it to add the extra code.
Title: Re: Bug Reports
Post by: nemo on July 09, 2010, 01:10:50 pm
i agree with deep thought. what if the programmer was debugging the code and tried to draw a circle with a negative radius, and then nothing happened? wouldn't it be much more useful to debug if some sporadic fractal appeared? this way they can easily post on omnimaga or somewhere else where someone can say "yep. that's what happens in axe when you try to draw a circle with a negative radius." also, the problem can easily be fixed with abs(radius) so that it never goes negative..
Title: Re: Bug Reports
Post by: Quigibo on July 09, 2010, 02:45:30 pm
Actually that problem has already resolved itself differently than I though.  First of all the reason it was so strange was the way it handles pixels because it makes a call to the built in pixel drawing command to save space.  That routine is modular with base 256 so pixels way off the screen in any direction loop back.  So it wasn't a problem with the circle radii at all.  You can just draw the circle far off the screen and get the same problem.  So I decided I just wouldn't add any more checks and just keep it the way it is.

And no, a check in assembly is 2 or 3 bytes for the entire code since I can use flags and its only a single byte number whereas the min and max commands are probably more like 9 bytes EVERY time you call the routine.  Huge difference.
Title: Re: Bug Reports
Post by: calc84maniac on July 09, 2010, 03:25:37 pm
The last time I checked (pretty recently, when I was writing my own circle routine in Axe code), pixel-plotting commands weren't clipped properly. I mean, I actually got a RAM clear once. Not good :(
Title: Re: Bug Reports
Post by: Quigibo on July 09, 2010, 03:53:14 pm
Yeah, I fixed that too.  I couldn't believe how dangerous it was before.  It required the high byte of both arguments to be zero but it never bothered setting them to zero because it assumed the input was already valid.  That really wasn't safe I completely forgot it was like that until I started the circle routine and noticed that.  Sometimes my optimizations compromise too much hehe.
Title: Re: Bug Reports
Post by: Magic Banana on July 09, 2010, 03:54:09 pm
I've got a bug to report.

Sometimes when I'm using tokens from the VARS menu (Str1, Pic1, etc) the program editor will append a comma to the end of it. I'm not really sure how this happens and my hands are nowhere near the comma button when I use VARS. I've only had it happen a few times, but it's still strange enough to report.
Title: Re: Bug Reports
Post by: Builderboy on July 09, 2010, 03:58:24 pm
I've had this happen to me as well, as well as some weird token behavior.  Tell me were you using omnicalc at the time?

Also why do applications delete themseles after a few runs?
Title: Re: Bug Reports
Post by: calcdude84se on July 09, 2010, 04:01:24 pm
It may be related to this post from cemetech:
Quote from: KermMartian
*bump*

Code: [Select]
[22:23:25] <+KermM> Buckeye, if you see this, I was wondering about the perennial emulator problem where apps randomly get deleted, some kind of certificate issue, I presume
[22:24:46] <+BrandonW> I can tell you exactly how to fix this.
[22:25:05] <+BrandonW> You need a dummy certificate with a series of zeroes starting at 1F18h.
[22:25:24] <+BrandonW> Without them (meaning all 0xFF's), the OS thinks it's a trial application, and they'll get deleted after 15 executions.
[22:25:27] <nikky> bawwwwwwwwwwww
[22:25:43] <+BrandonW> C+1F18h*
[22:26:04] <+BrandonW> I was planning to write a little 83+ program that did this.
[22:26:33] <+BrandonW> I said the technical details once in #ti but that was a while back.
[22:26:42] <+BrandonW> I'd have to do a little digging, and the offset is different on the 84+/SE.
[22:26:45] <+BrandonW> And 83+SE.
[22:27:08] <+BrandonW> The last app page minus the base page of your application times two plus the offset is the word you need to make a zero.
[22:27:21] <+BrandonW> On the active certificate sector.
[22:27:52] <+KermM> BrandonW, excellent
[22:27:57] <+KermM> I'll pass that along to Buckeye
You'll need to get Quigibo, probably w/Brandon's help, to fix this.
Title: Re: Bug Reports
Post by: Magic Banana on July 09, 2010, 04:10:54 pm
Yep, I always have Omnicalc and CalcUtil installed on my calc.

Also why do applications delete themseles after a few runs?
I've actually just had this happen to me. I guess the only thing we can do for now is just wait for that dummy certificate to be written onto the Apps.
Title: Re: Bug Reports
Post by: Builderboy on July 09, 2010, 04:20:23 pm
IM thinking it might have to do with Axe hooks interfering with Omnicalc hooks?  Mmm I just don't use omnicalc anymore
Title: Re: Bug Reports
Post by: Quigibo on July 09, 2010, 04:21:04 pm
Oh, is that what it is!  I couldn't figure out why that was happening in wabbit, it happens with the Axe Parser app too but that's just a wabbitemu problem.

I've confirmed that the dummy signatures are in fact causing the apps to delete after 15 runs, but when signed on the computer, they behave just like regular apps.  An app resigner will be included in the next release.  I will try to make the dummy signature more convincing so that the apps stay.  I'll have to talk to BrandonW about that because I feel like I'm missing another piece of information from that conversation. 
Title: Re: Bug Reports
Post by: FinaleTI on July 09, 2010, 04:39:39 pm
When I App compiled the interrupt based music player example Quigibo uploaded, it would crash whenever I ran it.
Would this just be because I didn't send it to my computer and recompile it? Or is this an Axe bug?
Title: Re: Bug Reports
Post by: calc84maniac on July 09, 2010, 04:46:42 pm
When I App compiled the interrupt based music player example Quigibo uploaded, it would crash whenever I ran it.
Would this just be because I didn't send it to my computer and recompile it? Or is this an Axe bug?
I thought interrupts weren't usable in Apps yet.
Title: Re: Bug Reports
Post by: FinaleTI on July 09, 2010, 04:49:12 pm
I wasn't sure as I hadn't been on the forums for a week, so I thought I would check.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 09, 2010, 08:38:30 pm
The last time I checked (pretty recently, when I was writing my own circle routine in Axe code), pixel-plotting commands weren't clipped properly. I mean, I actually got a RAM clear once. Not good :(
does pixel-plotting means pxl-on/off/chg?
Title: Re: Bug Reports
Post by: calc84maniac on July 09, 2010, 11:16:26 pm
The last time I checked (pretty recently, when I was writing my own circle routine in Axe code), pixel-plotting commands weren't clipped properly. I mean, I actually got a RAM clear once. Not good :(
does pixel-plotting means pxl-on/off/chg?
Yep. Though apparently it's fixed for the next version, so no worries :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 10, 2010, 12:14:12 am
Ah good. I never realized it had a bug, but I never tried displaying pixels out of the screen :P
Title: Re: Bug Reports
Post by: Builderboy on July 10, 2010, 12:20:19 am
Glad that's fixed, although it wasn't a problem for me either.  Good job with all the bug fixes!
Title: Re: Bug Reports
Post by: LordConiupiter on July 12, 2010, 01:26:08 pm
I had some bug-like things. When you do
Code: [Select]
Pause A/10
with A = 0, the calc freezes for a pretty long time.
There was another problem with zero, but I can't remember right now...
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 12, 2010, 01:27:41 pm
It's because when using Pause, for some reasons, it seems to substract 1 from the initial count. Pause 9000 will stop execution for 8999. What this means is that Pause 0 in fact equals 65535.
Title: Re: Bug Reports
Post by: calcdude84se on July 12, 2010, 04:42:31 pm
When I try to compile a program containing exactly:
Code: [Select]
.BUG
Circle(47,31,31
Dispgraph
The compiler pauses for a second or two then says "Error:Out of Mem" and pressing prgm takes me to the Dispgraph statement
Title: Re: Bug Reports
Post by: Quigibo on July 12, 2010, 04:47:11 pm
EDIT: calcdude, it appears to be another "end of line" bug.  Just make sure you add an extra enter to the end of the program and it should work fine.  I'm fixing that now.

Yeah, DJ is mostly right.  But a pause 9000 is still a pause 9000.  The thing is, it pauses a little first, then subtracts 1 before checking if its done pausing so a pause 0 is actually a pause 65536, which is even longer than a pause 65535.  This is only done for size optimization (obviously not speed since this is a pause command).
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 13, 2010, 11:35:36 pm
Btw, how long is APP writing supposed to take on a regular 83+? (I am running OS 1.18 btw)

I experimented with the feature and now it has been saying Writing App... for over 3 minutes
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2010, 12:54:41 am
It should only take a couple seconds.  I would do a ram clear, possibly a rom clear if problems persist.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 14, 2010, 01:05:52 am
I retried again, and no luck :(

I'll post a video of what happens now. I made the video after resetting the entire memory (and sending OS 1.19). I will post it on Youtube soon.EDIT: Uploaded as attachment.
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2010, 01:08:01 am
Is there something weirder going on than just the freeze?  Has anyone else had problems with app compiling on a regular 83+?

EDIT: Interesting... I'm not exactly sure what's going on, it sounds like it could be an issue with the regular 83+.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 14, 2010, 01:14:25 am
Now, what happens is usually no app being created, then Y= menu going "The Matrix", followed by a RAM clear. Sometimes the source code corrupts. Other times it will freeze again during creating. I even got a crash once, and an Unknown Error going at the very end of the program.

Anyway, I edited my post above. See the video attached to it. Btw for the errors at the end, a full mem clear was required to

So my guess is that

1) App compiling hates my game
2) App compiling doesn't work on the regular 83+, regardless of the OS installed.
or
3) App compiling doesn't work on every 83+ hardware (idk if there are any different ones, but my calc was bought in 2001 and is a 2000 model)

Btw, in case this help, here's the end of the serial on the back of my 83+:

N-0700A
Made in China
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2010, 01:22:06 am
Does it work on other games?  I tried it on my 83+ emulator OS 1.16 and it seems to work fine with my example programs and I even tried it with the older version of your game.  It's definitely possible its a hardware thing.

EDIT: Also, the error code is a really really bad sign because its being called from somewhere outside the app itself.  I don't even have that code. ???
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 14, 2010, 01:31:56 am
Well, I didn't try an example program, but I tried with a random program like

.A
Disp 22>Dec

And I still got the same issues.

Btw earlier on emulator, with 83+OS 1.16, I got similar results too, except the APP showed up in the list (it would either crash or do nothing when ran)

I sent you the 8xp source if you want to look at it (check your e-mail)
Title: Re: Bug Reports
Post by: yunhua98 on July 14, 2010, 02:23:44 pm
I have some issues with APPS to.  When I compiled my bomberman game as a program on 0.3.3, it works, but when I compile it as an APP, it freezes when I start the APP.  I'm using 84+ SE  Running 2.53MP with Mathprint off.

On the lesser note, whenever I use ClrDraw to end my Axe programs, my calc freezes and I have to pull a battery.

btw, I didn't need to compile my prog as an APP I was just testing the feature, so it's ok if you dont fix for a while.
Title: Re: Bug Reports
Post by: Builderboy on July 14, 2010, 02:25:39 pm
When i was compiling for App, it was deleting the app, and displaying the defragmentation message, and i got Ram clear :( It was a one time occurrence however, so it might have been something like a vat corruption or whatever.
Title: Re: Bug Reports
Post by: yunhua98 on July 14, 2010, 02:27:29 pm
Oh, I forgot to mention, that happens to me too, only it happens every time, so I have to manually delete the APP first.

Builderboy, do you get random symbols before the crash?
Title: Re: Bug Reports
Post by: Builderboy on July 14, 2010, 02:28:22 pm
No, the screen just went blank
Title: Re: Bug Reports
Post by: FinaleTI on July 14, 2010, 02:55:03 pm
The app compiling crashed for me too while it was deleting the app, but it only happened once, I think it happened shortly after I switched from 0.3.2 to 0.3.3, but it hasn't crashed since.
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2010, 05:16:24 pm
Oh, I forgot to mention, that happens to me too, only it happens every time, so I have to manually delete the APP first.
Anyone else using 2.53MP with this problem?

I couldn't simulate any of these in an emulator but I will try to download more OS versions to see if I can.  However, I did also have the defragmenting message freeze my real calc once as some other people have reported but it never happened again so I don't know what might have caused that.

I'm using a lot of very hackish code with the application stuff, some of it was written by BrandonW and some of it was ripped from the OS so I'm suspecting that there could be compatibility issues.
Title: Re: Bug Reports
Post by: yoman82 on July 15, 2010, 10:33:04 am
Nope, mine is stable on 2.53
Title: Re: Bug Reports
Post by: jnesselr on July 15, 2010, 11:07:48 am
I am not having that problem. I only had a weird out of flash error once.
Title: Re: Bug Reports
Post by: matthias1992 on July 15, 2010, 02:20:49 pm
Mine is stable too on 2.53

I do of course get the defragmenting message but no ram clears fortunately. I have no problems with axe. I have revision L (incompatible with Ti-BoySe) so actually my faulty hardware (as defined in the Ti-BoySE Readme) is great :p
Title: Re: Bug Reports
Post by: yunhua98 on July 16, 2010, 10:47:08 pm
Mine's an M.  I do have an older TI-84+ BE running on 2.40 that does great, with a revision G.  (Although it doesn't run TI-BOY SE either.  But that's for another thread...) ;)
Title: Re: Bug Reports
Post by: Happybobjr on July 18, 2010, 10:38:24 pm
major weird!!!!!!!
Might like  to check this out.
,ight give out source tomarow if i have time.
story:  making gray style for my etch-1-sketch.

problem 1:  Ok this is the weird one.  i have the screen with a couple of lines on it.  i press storepic.  nothing happens, good.  recall it good too.
not i try a couple of gray style lines.... i press store...  they all dissapear.

restart prof from fresh.  i do a couple of gray lines and do recall, they all turn black, aka no longer gray... :P
no i do inverse screen. black to white and hite to black.

all goes black but for where the lines were.  they are gray again?!?!?!!?...



problem 2:  when i have the innterpruts on i can't seem to get this to work at all ,  getkey->g

help would be appriciated
Title: Re: Bug Reports
Post by: jnesselr on July 18, 2010, 10:43:15 pm
please post your code.  I have no earthly idea exactly what you are doing.  It is much easier to help someone if we can actually see what's wrong.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 18, 2010, 10:45:23 pm
I'm not too sure if I understand either. You should probably post more details about what you want to happen. The code would help too, if you post it tomorrow.
Title: Re: Bug Reports
Post by: nemo on July 18, 2010, 10:51:22 pm
i think the code would really help... happybobjr, i'm assuming your etch-a-sketch draws 1 pixel at a time, right? in that case, you can always toggle gray on/off, and then have a flag variable to decide to draw a gray pixel or a black pixel.. you don't need to storepic or recallpic, i don't think.
Code: [Select]
0->G  . No gray
If getKey(54)  . If they press [2nd]
1->G  . Start drawing gray pixels
End
[your movement code here]
.when you draw the pixels to the screen:
If G
Pxl-On(X,Y)^r
Else
Pxl-On(X,Y
End
Title: Re: Bug Reports
Post by: Quigibo on July 19, 2010, 12:30:21 am
Happybob, I would appreciate it if you could spend a little more time forming your sentences with correct punctuation and grammar because it becomes difficult to read and especially for a bug report, clarity is really important.

For your first point, the back buffer used to draw grayscale is the same back buffer used in the Recalpic and Storepic commands. If you want to back up a grayscale screen, you have to create 2 additional buffers with Zeros(768) and then back up both the front and back buffers to each one using the Copy() command.

Your second point, the OS getkey command does not work with interrupts.  You will have to use direct keys instead like getkey(15) for instance.

Third, you mentioned to me in your PM that your AXEGUESS example program was not correctly returning random numbers and was the same number every time you played the game.  Has anyone else had a problem with this, especially if you use the modified OS by BrandonW.
Title: Re: Bug Reports
Post by: Happybobjr on July 19, 2010, 08:11:07 am
I am sorry about neatness, it has never been my strong suit.  It was also late when i did it :P

i think i understand what you said about creating the buffers, and i am glad to know that it is safe to use.

the getkey->G   was very inportant in my program because u would have it double check with getkey(...)
for example if i press left, down, and enter; it acts as if i were holding down +.

here is the source code.

it is AAA000   (theta theta theta)
Title: Re: Bug Reports
Post by: calcdude84se on July 19, 2010, 11:50:35 am
the getkey->G   was very inportant in my program because u would have it double check with getkey(...)
for example if i press left, down, and enter; it acts as if i were holding down +.
This is actually the keyboard hardware's fault, and is unfixable. Basically, whenever you press three keys that make the corners of a box in the table on http://wikiti.brandonw.net/index.php?title=83Plus:Ports:01 (http://wikiti.brandonw.net/index.php?title=83Plus:Ports:01), the fourth corner will be read as pressed. This is, as said above, unfixable, and if it's a problem, you'll need to use other keys that won't interfere with each other.
(Also, less important, be aware that you can have multiple boxes, and that the falsely read corners can still act as corners for another box)
Title: Re: Bug Reports
Post by: Happybobjr on July 19, 2010, 02:26:10 pm
thank you very much.
can you think of a good work around of that?
Title: Re: Bug Reports
Post by: imPersonator on July 19, 2010, 03:42:20 pm
When I compile any program that ends with DispGraph or ClrDraw, Axe begins the first pass, freezes, and after a few seconds displays "ERR: OUT OF MEM."  If I add a space after ClrDraw or DispGraph, it compiles fine.
Title: Re: Bug Reports
Post by: nemo on July 19, 2010, 03:45:16 pm
Quigibo already explained this a few pages back, imPersonator. it'll be fixed in v4.0
Title: Re: Bug Reports
Post by: calcdude84se on July 19, 2010, 03:45:23 pm
This was mentioned earlier, and it's a random bug that doesn't allow you to end programs with tokens that could have an "r" after them. IIRC, Quigibo has already fixed this for 0.4.0
Edit: ninja'd :P
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 19, 2010, 09:13:45 pm
It can be a bit hard to find out which bugs were posted about though, considering there are 37 pages x.x

It would be nice if Quigibo would update his first post in the topic with known bugs and if they are fixed or not, yet, so we can figure out which bugs were reported or not for the current Axe version.

Btw, APP compiling works perfectly under OS 2.54 MP (TI-Nspire). I can play APP format games fine, too.

As for bug reports, we ask that people gives enough details (if possible) when posting any. Source code helps a lot, as well as explaining in details. As for grammar, I'm not fond of grammar nazis, especially as someone who don't speak english as native language and forums not being an english class, plus the fact it can be rude towards new members, but we ask people to try doing an effort to at least make sure their posts are understandable. If the reply about grammar was done to a member with like 5 posts, I would have rated down the post, but given it was for a member who have been around for quite a while, I think Quigibo request is justified. I am certain this post I am writing has mistakes, but if a post is very hard to read, it takes considerably longer to understand it, thus, a lot of time lost for the person trying to make sure his APP is clean of bugs.
Title: Re: Bug Reports
Post by: Quigibo on July 19, 2010, 09:53:58 pm
That's a great idea DJ!  I will amend the first post of this topic to list all known bugs even the ones I discover and fix but don't report.  I will try to keep the list up to date as new versions come out.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 19, 2010, 10:08:40 pm
Cool ^^

On a unrelated note, I was wondering if the error scrolling was ever fixed? I did not get any trouble with it, except when an error was at the very end of the program, it scrolled a bit too far it seems, but I got no side effects of this. What I mean is like:

Code: [Select]
PRGM:HELLOWLD
:End
:PrintScreenClearEntriesLOLOLOL





Instead of like
Code: [Select]
PRGM:HELLOWLD
:
:
:A+2->A
:
:
:
:End
:PrintScreenClearEntriesLOLOLOL
In this example, my coding error is the last line, of course. The last time I had this happen was when I tried APP compiling, though (remember the crashes I got on the regular 83+?). I am not sure if it was fixed or not
Title: Re: Bug Reports
Post by: Quigibo on July 19, 2010, 10:22:48 pm
Its not really something high on my priority list to fix and its not really a bug.  The problem is that it requires a lot of extra code to figure out where to start printing from the top of the screen and its much simpler to go just start with the same line.  I think the DCS instant goto does this as well if I'm not mistaken.  The only easy way to have the scrolling end up looking like it does in TI-BASIC is well... to actually scroll, but I think the convenience of instant goto is more favorable than bottom line error highlighting.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 19, 2010, 10:27:20 pm
Ooh ok I see, well I guess you shouldn't worry about this for now. I did not have issues with it so far, it seems, too.
Title: Re: Bug Reports
Post by: Quigibo on July 20, 2010, 01:37:51 am
Good News:
AHA!  I think I've found the source of the mysterious DispGraph commands sometimes not re-enabling interrupts!!!

http://awurl.com/6nvjrb7L3 (http://awurl.com/6nvjrb7L3)

Probably Calc84Maniac was unaware of this and I think most z80 junkies also don't know about it.  It took me days just to find any relevant information on this.

Bad News:
There doesn't appear to be any way around it that I can see, but maybe someone knows more about this than me.  The interrupts might have to be manually re-enabled by the programmer at the end of the routine, but this is a major inconvenience.

Good News:
1000th Post!  :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 20, 2010, 01:51:08 am
Nice to hear you found it. Also interesting highlighting site you found there :P

I hope someone can figure out a way around it, though.

Congrats on your 1000th post :)
Title: Re: Bug Reports
Post by: calcdude84se on July 20, 2010, 11:17:45 am
That's a pain... I can't think of any easy way around it, if there even is a way.
Congrats on the 1000th post, though! :)
Title: Re: Bug Reports
Post by: Runer112 on July 23, 2010, 02:01:25 am
It appears that if the last line of a source file is storing a value to a constant pointer, a bad symbol error is thrown if a closing brace is used. The error isn't thrown if the closing brace is omitted.

Some examples that would throw an error:
Code: [Select]
.AXEPRGM
0→{L₁}
Code: [Select]
.AXEPRGM
[Pic0]→Pic0
A*2→{8*12+Pic0}

Some examples that would not throw an error:
Code: [Select]
.AXEPRGM
0→{L₁
Code: [Select]
.AXEPRGM
[Pic0]→Pic0
A*2→{8*12+Pic0}
Pause 5000
Code: [Select]
.AXEPRGM
0→{L₁}r
Code: [Select]
.AXEPRGM
Copy(L₃,L₆,{2+L₂}
Title: Re: Bug Reports
Post by: Quigibo on July 23, 2010, 03:43:59 am
Those are all related to a known bug which I have already fixed.  Since it ends with "}" that is a command that can use the r modifier which is currently causing an error when its done on the last line.
Title: Re: Bug Reports
Post by: ACagliano on July 24, 2010, 11:55:19 am
When i use:

Code: [Select]
getKey->G
Disp G

I get random binary code


so then I try:

Code: [Select]
getKey->G
bG->G
Disp G

I get "Err: Unknown Err" on line 2.

This is with an earlier version of the parser. I will update to the latest ASAP and report back if it still persists. I apologize if it has already been handled.
Title: Re: Bug Reports
Post by: Runer112 on July 24, 2010, 12:20:18 pm
"Disp G" would attempt to display a string starting at memory address G, which would be between 0 and 56, so it would display whatever data is stored there (I'm not sure what's stored there, maybe someone else could tell you) until it hits a zero byte (end of string marker).
What you want is "Disp G▸Dec". This displays the value of G as a 2-byte integer.
Title: Re: Bug Reports
Post by: Whirligig on July 24, 2010, 04:20:15 pm
I'm not sure if this has been said before, but it wasn't on the list on page 1. I'm making an app that was originally called AxeMaze, but after a while Axe started compiling it as "Ax." (The period is there for grammatical reasons.) So I switched to BallMaze, and that worked for a while, until Axe started calling it "B." To clarify, the compiled app is being misnamed; the source code is fine.

Also, my app is now giving be a RAM clear when it exits. I don't know why, and I tried changing the code back to how it was, but it didn't seem to help. The problem started when I added DiagnosticOff and Full to the code. I can post the source if necessary.

I'm using a TI-84+ SE and TI-OS 2.43.
Title: Re: Bug Reports
Post by: Raylin on July 24, 2010, 10:49:58 pm
I think this is occurring because of the forced replacement Axe is doing to the APPs and the flash.
Try deleting the old APP first before you compile a new APP.

Better yet, try compiling in program form first before making an APP.
Title: Re: Bug Reports
Post by: Runer112 on July 26, 2010, 01:57:02 am
When parsing large amounts of hexadecimal data, a few bytes are incorrectly parsed as zeros instead of whatever value the source dictated they should be. This error did not exist in earlier versions of Axe.
Title: Re: Bug Reports
Post by: nemo on July 26, 2010, 05:23:47 pm
has anyone successfully stored data into a list from an axe parser program? i can't seem to get it to work, and after running this program twice, i get a RAM clear:

Code: [Select]
.B
5->{L1}
GetCalc("L1",1)->A
{L1}->{A}

the program compiles fine, and after running the program once, i end up with the value 0 in the OS var L1. i run the program again, the calc freezes and i get a RAM clear.
Title: Re: Bug Reports
Post by: calcdude84se on July 26, 2010, 05:56:32 pm
Quigibo, do you mind explaining the floating-point format to us?
nemo, the main problem is that floating-point numbers use a very different format than two-byte integers.
Title: Re: Bug Reports
Post by: Quigibo on July 26, 2010, 06:52:58 pm
Lists and other floating point stuff is really complicated and I don't know it well myself.  You'll have to refer to the TI-Developer's guide to see how floats are formatted.  The only thing I know is that they're 9 bytes each and the last 7 bytes are the number itself in BCD.  Its way too complicated I think to work with them now in Axe, it will be easier when I get floating point conversions working.  For now, just stick with programs, appvars, pics, and strings is my advice.

Also, Runer112 I can't seem to simulate that problem and I don't see anything obvious in the parser that would cause that.  Would you mind emailing me an example that I can debug?
Title: Re: Bug Reports
Post by: calcdude84se on July 26, 2010, 06:58:27 pm
Also, bug I meant to report earlier. I have to pass 7 as the size argument to GetCalc( for real variables else I get memory leaks (too high) or crashes (too low). I guess this isn't a bug, but you should document it ;D
Title: Re: Bug Reports
Post by: Runer112 on July 26, 2010, 10:41:50 pm
So, any luck with my hexadecimal parsing problem Quigibo?
Title: Re: Bug Reports
Post by: Quigibo on July 26, 2010, 11:18:47 pm
Yeah, I'm looking into it.  I'm working on the masked sprite routine right now so at least I can add something new to 0.4.1 instead of just a bunch of bug fixes.  Hopefully I will find and fix them all so I can update late tonight or tomorrow.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 29, 2010, 03:43:42 am
Btw did you fix the whole APP issue in 0.4.1? (including on the regular 83+)

EDIT: Actually according to bug reports, the defragmenting issue seems fixed. I'll try on my Nspire later. Any luck figuring out the 83+ issue, though?
Title: Re: Bug Reports
Post by: Quigibo on July 29, 2010, 04:25:38 am
I couldn't find a pattern in Runner's corrupted data, it seemed to be completely random, but always a high order nibble indicating to me that it's most likely an error in reading the hexadecimal number since if one character gets accidentally read as a zero, that could cause it.  My solution to this was to disable interrupts during all of the routines which swap pages (which is all the reading routines) because I fear that could be interfering.  I have no idea if that solves the problem or not since I can't replicate it myself, I'll need some confirmation.

In DJ's case the corrupted app he sent me randomly had a zero written to exactly every 256th address, that is all addresses of the form $xxCE, and this isn't the data part of the code I'm talking about, this is the entire application and so some commands got screwed up due to having random zeros written over them.  I'm not sure what this implies, but I think its possible that its a problem with the rom chip since the errors are so regular and the app itself compiled completely normally otherwise.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 29, 2010, 04:31:19 am
Ouch x.x, so I guess this migth be my calc, then :/

I know I recently started having other errors, too, that happened, but I could not always reproduce them. For example, earlier, when running my ball game, nothing happened, it just exited the ASM program, not even a Done message. A RAM clear didn't fix it and I had to reset the archive, followed by the RAM.

One day, I'll attempt sending Illusiat 13 again on this calc and playing it, or maybe of of my game that archives/unarchives, just to see if problems will occur. This calc hasn't been used for BASIC programming for over a year, but a lot of archiving/unarchiving went on since then (mostly grouping progress on programs). I wonder if the flash chip isn't wearing out?
Title: Re: Bug Reports
Post by: Runer112 on July 29, 2010, 11:25:15 pm
I'm having some problems with division... I was trying to debug the problem in my program with this:

Code: [Select]
Text(0,52,C^213*256▸Dec)
Text(0,58,C^213*256/213▸Dec)

The only difference between these two lines is that one has a /213 at the end. When I run the program, the output is (almost always) incorrect.

I attached a sample program I quickly whipped up to further demonstrate the problem. Almost every division is incorrect, although a few are correct. The divisions always seem to result, in order of commonness: 0s, powers of 2, 18 times powers of 2, 66 times powers of 2, 68 times powers of 2, and if and only if C^213 equals 114, the correct answer of 137.
Title: Re: Bug Reports
Post by: Quigibo on July 29, 2010, 11:53:14 pm
That's bizarre... the routine isn't mine though it's TI's!  I'm using BCALL(_DivHLByA) and the disassembly is showing the executable is setting up the inputs correctly so it must be something wrong with their routine.  I'm going to investigate.

Most interesting!  With the following input:
Code: [Select]
ld hl,25600
ld a,213

I disassembled the exact routine the OS uses. Running the input through this exact routine:

Code: [Select]
push bc
ld c,a
sub a
ld b,16
loop:
add hl,hl
rla
cp c
jr c,skip
sub c
inc l
skip:
djnz loop
pop bc

Does indeed return the result "0" in HL instead of "120" like it should.  Am I misusing something here?  This is a 16-bit / 8-bit division right?  Why is it failing?
Title: Re: Bug Reports
Post by: Runer112 on July 30, 2010, 12:26:32 am
Haha wow, the OS division routine doesn't work properly? How have I been the only one to discover this?
Title: Re: Bug Reports
Post by: calc84maniac on July 30, 2010, 12:44:37 am
That's bizarre... the routine isn't mine though it's TI's!  I'm using BCALL(_DivHLByA) and the disassembly is showing the executable is setting up the inputs correctly so it must be something wrong with their routine.  I'm going to investigate.

Most interesting!  With the following input:
Code: [Select]
ld hl,25600
ld a,213

I disassembled the exact routine the OS uses. Running the input through this exact routine:

Code: [Select]
push bc
ld c,a
sub a
ld b,16
loop:
add hl,hl
rla
cp c
jr c,skip
sub c
inc l
skip:
djnz loop
pop bc

Does indeed return the result "0" in HL instead of "120" like it should.  Am I misusing something here?  This is a 16-bit / 8-bit division right?  Why is it failing?

Yeah, it makes sense that it can fail for divisors greater than 128 (and especially ones close to 256). Here's a modified one that should work:
Code: [Select]
ld c,a
xor a
ld b,16
loop:
add hl,hl
rla
jr c,overflow
cp c
jr c,skip
overflow:
sub c
inc l
skip:
djnz loop
Title: Re: Bug Reports
Post by: Quigibo on July 30, 2010, 01:33:09 am
Ah, so its really 16-bit / 7-bit then.  In that case, the name is really deceiving, maybe I should mention this in the WikiTi for that bcall.  I might just change the auto-opt to use this optimization only if the constant is smaller than 128 and just use my normal 16 bit division routine otherwise.

Hmm... but that routine is faster for 8-bit numbers.  I wonder if it wouldn't be too much overhead to have single routine for both 8-bit and 16-bit divisions that checks if the input is 16-bit or 8-bit at the start and then branches to the correct routine.  I feel this might be a large enough speed increase to justify the extra size since i think a majority of divisions are with numbers smaller than 256 which will all be sped up almost double, both when using constants and variables.  It would be about 20 extra bytes to the subroutine and only 1 extra byte when calling the routine with a constants smaller than 128 (unless otherwise optimized).  This would also increase the speed of signed division.  Can I get some opinions on this?
Title: Re: Bug Reports
Post by: calc84maniac on July 30, 2010, 01:36:06 am
Sounds good to me. Just simply not using a bcall will probably increase the speed of divisions considerably ;)
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 30, 2010, 03:05:07 am
Seems fine to me too. I think the size increase will be worth it for games that are rather complex in terms of maths.
Title: Re: Bug Reports
Post by: Runer112 on July 30, 2010, 03:18:50 am
The reason I was doing stuff with /213 is because I'm working on an animation driven by a timer variable being increased in an interrupt. To get the timing right, one of the parts of the animation involves sine and cosine that need to have periods of 213, so I use C^213*256/213 as a period modifier.
Title: Re: Bug Reports
Post by: Quigibo on July 30, 2010, 09:14:12 pm
Good news!  I've found the source of that error where the high nibble sometimes gets changed to a 0.  My byte reading routine was supposed to preserve certain registers and I forgot that I changed that routine by adding another subroutine to it that shows the current progress percentage and that subroutine did not preserve those registers when it updated the percentage to the screen (which happens very rarely).
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 31, 2010, 02:11:57 am
mhmm for which function is it? Glad to see a bug fixed, though :P
Title: Re: Bug Reports
Post by: Runer112 on July 31, 2010, 10:34:46 am
Good news!  I've found the source of that error where the high nibble sometimes gets changed to a 0.  My byte reading routine was supposed to preserve certain registers and I forgot that I changed that routine by adding another subroutine to it that shows the current progress percentage and that subroutine did not preserve those registers when it updated the percentage to the screen (which happens very rarely).

So this is the source of my hexadecimal parsing error? One thing I did notice is that the percentage counter updates while parsing hexadecimal data in 0.4.0 and above, and that's when the problem appeared. I was even thinking to myself, asking if that could be the cause of the problem, but I figured it probably wasn't and didn't think to mention it lol.

EDIT: Oh, and on the topic of the percent counter, there's another bug, although it has no adverse affects and will hardly ever show up: if the program you're compiling is absolutely massive (like both of the 2 ~48K uncompressed map data source files I have), the percent counter loops back around to 0 percent in the middle of compiling, I believe once ~32768 bytes have been processed.
Title: Re: Bug Reports
Post by: DJ Omnimaga on July 31, 2010, 05:01:32 pm
You can compile stuff this large??? O.o

Does Axe supports flash apps larger than 1 page or something, now?
Title: Re: Bug Reports
Post by: Runer112 on August 01, 2010, 12:57:44 am
Well these are pure hexadecimal source programs, so the size of the "executable" programs are less than half those of the source and fit individually RAM. Every two bytes of source hex become one byte of compiled hex, and the comments, line breaks, and brackets disappear, leaving only 20.5K each. What did you expect though, the entire overworld from Link's Awakening is pretty big. ;D But I've managed to compress the two 20.5K uncompressed tilemap data programs into one 19K appvar thankfully.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 01, 2010, 12:28:18 pm
Ah ok because I always thought Axe Parser only could create 1-page apps including data, which is why I am surprised it is above 16384 bytes compiled total.
Title: Re: Bug Reports
Post by: Quigibo on August 01, 2010, 02:44:32 pm
Programs can be larger than 16kb since they can take up all available ram, they just can't be executed.  Runer is using those programs as read only memory so he doesn't have that problem.  But I didn't know myself that programs could be larger that the available RAM!  I guess they would have to be archive only, made on the computer, and then transferred.
Title: Re: Bug Reports
Post by: Builderboy on August 01, 2010, 05:17:45 pm
Would compiling to archive be a viable possibility?  It might be interesting for like data and things.
Title: Re: Bug Reports
Post by: Raylin on August 01, 2010, 05:19:23 pm
THAT WOULD BE INSANE!
Title: Re: Bug Reports
Post by: Quigibo on August 01, 2010, 05:38:45 pm
That should probably go in the features wishlist, but to answer your question, its definitely possible, but I don't think I will because I'm already having enough issues with app compiling, it would be even more chaotic with yet another way to risk damaging archive space only this time, it would be more likely to corrupt actual programs and other variables rather than application pages.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 03, 2010, 04:27:28 am
Programs can be larger than 16kb since they can take up all available ram, they just can't be executed.  Runer is using those programs as read only memory so he doesn't have that problem.  But I didn't know myself that programs could be larger that the available RAM!  I guess they would have to be archive only, made on the computer, and then transferred.
Mhmm I am a bit confused by what read-only means. Do you mean the archive memory? I am curious how he actually run them
Title: Re: Bug Reports
Post by: Builderboy on August 03, 2010, 04:28:57 am
I think it just means he is using it as Level data, and since its data it doesnt matter if its in archive, ram, or if its less than the 8800 bytes limit.
Title: Re: Bug Reports
Post by: Hot_Dog on August 03, 2010, 10:21:35 am
I think it just means he is using it as Level data, and since its data it doesnt matter if its in archive, ram, or if its less than the 8800 bytes limit.

Incidentally, I could never understand why ASM programs must be 8 KB or less.  Can anyone explain?
Title: Re: Bug Reports
Post by: calc84maniac on August 03, 2010, 01:02:15 pm
I think it just means he is using it as Level data, and since its data it doesnt matter if its in archive, ram, or if its less than the 8800 bytes limit.

Incidentally, I could never understand why ASM programs must be 8 KB or less.  Can anyone explain?
It is because the RAM located at addresses $C000 to $FFFF cannot be executed, only read/written. So the limit on amount of executable code is $C000 minus $9d95.
Title: Re: Bug Reports
Post by: shmibs on August 03, 2010, 03:25:21 pm
um... this is supposed to happen, right?
(http://img.removedfromgame.com/imgs/1280863233-axedeath.gif)

ram clear is useless; the only fix is deletion and replacement
furthermore, this isnt the first time it's happened

TI-84 Plus Silver Edition
2.43
PROD#: 0A-3-02-2B

this is axe .4, but i've had the same thing happen on earlier versions as well
EDIT: and here's everything in my arch, if you think it might help
Code: [Select]
apps
Axe:Bubble:Calcsys:Celtic3:DAWG:DoorsCS7:Graph3:NoteFlio:Periodic:Pyoro

vars:
like 50 pictures(using celtic3):ALCDFIX:AMID83:ASTEROID:ATTACK:BEJEWELED:BUBBLE:CALCMOD:CAVE:CONWAY:COPYBG:DESOLATE(&desdata):DK5MOS:DODGE2M:EPHALONE:FDOWNX:FISH7:FPHOENIX:FRETRCK2:FROGGUTS:GALAXAN2:GEOWARS:GPHX5:GRAYMINE:GRAYTUNL:IGO:LOTUS(&lotusdat):MARIORUN&ED:MAZE3DII:MCROHRTZ:MIRBUTN:MIRDESC:MIRNAME:MOSOKO:OMEGA:ORBIT:ORZINOID(&editor):PUYOPUYO:QWERTY:REVERSI:RUSHOUR:SERPENT2:SKY:SN00D:SNAKE:TETRISM:TRAPPED:TRON:and 100 or so progs of my own making
Title: Re: Bug Reports
Post by: Raylin on August 03, 2010, 03:29:49 pm
That's not supposed to happen at all! o.o

What do you have archived?
Title: Re: Bug Reports
Post by: Hot_Dog on August 03, 2010, 03:32:12 pm
I've never seen THAT one before :O
Title: Re: Bug Reports
Post by: Quigibo on August 03, 2010, 05:37:13 pm
That was the problem I had with 0.4.0 and was fixed in 0.4.1.  There is a bug in the TI-OS that thinks that pages starting with $FF are set for deletion and so it deletes the second page of the Axe app during defragmenting which contains a lot of the important data (like the menu backgrounds which you can see were missing).  There is a patch to fix this, and I think that patch is required for TI-Boy to run for the same reason, but I just got around it by simply starting that page with a different byte instead.  This couldn't possibly have happened with versions prior to 0.4.x since Axe was a single page app then.
Title: Re: Bug Reports
Post by: shmibs on August 03, 2010, 05:47:15 pm
well thanks then =D

something wonky definitely did happen with the earlier versions, but it must have been only similar, then, in which case i havent seen it again and am going to assume that it's fixed
Title: Re: Bug Reports
Post by: ACagliano on August 04, 2010, 06:35:04 pm
for an unknown reason, my version of Axe Parser (0.3.3) is not error scrolling AT ALL. The source is unarchived and the only other thing installed on my calc that uses a hook is CalcUtil.
Title: Re: Bug Reports
Post by: TIfanx1999 on August 04, 2010, 08:10:31 pm
If I recall, some of the older versions of AXE didn't have error scrolling or it didn't work properly. I'd recommend updating to the current version of AXE.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 04, 2010, 08:37:14 pm
um... this is supposed to happen, right?
(http://img.removedfromgame.com/imgs/1280863233-axedeath.gif)

ram clear is useless; the only fix is deletion and replacement
furthermore, this isnt the first time it's happened

TI-84 Plus Silver Edition
2.43
PROD#: 0A-3-02-2B

this is axe .4, but i've had the same thing happen on earlier versions as well
EDIT: and here's everything in my arch, if you think it might help
Code: [Select]
apps
Axe:Bubble:Calcsys:Celtic3:DAWG:DoorsCS7:Graph3:NoteFlio:Periodic:Pyoro

vars:
like 50 pictures(using celtic3):ALCDFIX:AMID83:ASTEROID:ATTACK:BEJEWELED:BUBBLE:CALCMOD:CAVE:CONWAY:COPYBG:DESOLATE(&desdata):DK5MOS:DODGE2M:EPHALONE:FDOWNX:FISH7:FPHOENIX:FRETRCK2:FROGGUTS:GALAXAN2:GEOWARS:GPHX5:GRAYMINE:GRAYTUNL:IGO:LOTUS(&lotusdat):MARIORUN&ED:MAZE3DII:MCROHRTZ:MIRBUTN:MIRDESC:MIRNAME:MOSOKO:OMEGA:ORBIT:ORZINOID(&editor):PUYOPUYO:QWERTY:REVERSI:RUSHOUR:SERPENT2:SKY:SN00D:SNAKE:TETRISM:TRAPPED:TRON:and 100 or so progs of my own making
Did you try compiling an APP under a name that already exists? On my TI-Nspire I had the same problem happening. The workaround right now is to delete the old game APP copy then compile a new one, not overwrite. It's because Axe writes it to the wrong Flash pages, if your app already exists and it appears to overwrite one of the Axe Parser page. I believe this started when Axe became a 2 page application.
Title: Re: Bug Reports
Post by: Builderboy on August 08, 2010, 11:16:59 pm
Im having troubles with the new Axe App.  It has randomly crashed during compiling (this was after a full RAM clear) twice, and given me a BAD SYMBOL error on the second pass on this line

{L1+12}+8->G

At the number 8.  These errors are unfortunately infrequent, and im still trying to figure out what is actually causing them.



Also, another question, is the order in which subroutines are coded the order in which they are added into the code?  Or is it the order in which they are called? 
Title: Re: Bug Reports
Post by: Quigibo on August 09, 2010, 12:12:47 am
Hmm interesting, I haven't had any random crashing problems yet... I'll look into that.

Yes, the built-in subroutines are added to the Data section of the code in the order that they are first called and its mixed in around other data as well, even inline data.
Title: Re: Bug Reports
Post by: Builderboy on August 09, 2010, 12:16:29 am
Ah gotcha, thats a the source of a different problem i was having.  My executable is larger than 8800 bytes, so i put the currently unused subs at the bottom, but then calling other subs was causing crashes and crazy stuff.  I finally tracked down the error yay!

Title: Re: Bug Reports
Post by: Quigibo on August 09, 2010, 12:57:49 am
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.
Title: Re: Bug Reports
Post by: Builderboy on August 09, 2010, 12:59:35 am
I was able to get it with source code unarchived and autobackup turned on unfortunately D:

EDIT: Hey does that mean that when a sub isnt ever called, it isnt added into the program?
Title: Re: Bug Reports
Post by: Quigibo on August 09, 2010, 03:39:59 am
I think you're confusing user-made subroutines with built-in subroutines.  The user-made subroutines which are basically just labels are just like any other code and added inline whether they're used or not.  But the built-in subroutines like multiplication, Pt-On(), DispGraph, etc. are only added when they're needed, but not inline, they're added at the end of the program like the data to decrease the overall size of the program.
Title: Re: Bug Reports
Post by: tloz128 on August 09, 2010, 02:32:47 pm
I noticed two strange bugs in 0.4.2. One of them gave me an error when I included source code at the end of my program, but after putting an extra blank line of code onto the end of the program, it compiled just fine. Also- this happened to me twice- after compiling the calculator told me that I had no free ram left, though none of the OS vars were taking up nearly that much memory.
Title: Re: Bug Reports
Post by: Quigibo on August 09, 2010, 06:04:09 pm
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?
Title: Re: Bug Reports
Post by: Builderboy on August 09, 2010, 09:32:15 pm
The Axe App uses interrupts?  What for?
Title: Re: Bug Reports
Post by: Quigibo on August 09, 2010, 09:55:29 pm
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.
Title: Re: Bug Reports
Post by: Raylin on August 09, 2010, 10:08:59 pm
Any new features?

Also, was that 16-bit checking included?
Title: Re: Bug Reports
Post by: Runer112 on August 09, 2010, 10:55:04 pm
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.
Title: Re: Bug Reports
Post by: Builderboy on August 10, 2010, 12:22:57 am
Just some small nitpicking, or maybe a question.  When i compile for App, the size it says my program takes up is about 200 bytes larger than if i compile it for noShell.  Is this a bug or is there an extra 200 bytes needed for running Apps?
Title: Re: Bug Reports
Post by: Quigibo on August 10, 2010, 02:44:51 am
@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.
Title: Re: Bug Reports
Post by: Builderboy on August 10, 2010, 02:46:56 am
Ah i see, thats good to know :)
Title: Re: Bug Reports
Post by: Runer112 on August 10, 2010, 03:09:53 am
@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.
Title: Re: Bug Reports
Post by: qazz42 on August 10, 2010, 09:56:13 am
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 :/)
Title: Re: Bug Reports
Post by: jnesselr on August 10, 2010, 01:18:57 pm
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.
Title: Re: Bug Reports
Post by: Happybobjr on August 10, 2010, 01:34:50 pm
something screwing with interupts,

1. i have in my code "int(1,2)"
  I compile, says lbl missing.

2. I change my code and the point it points at to C

 Now i have "int(C,2)"
 i compile it, and works.
 I run program, and ram clear... can't upload source right now due to broken usb ports :P


EDIT:opps i was still on 4.2
Title: Re: Bug Reports
Post by: Runer112 on August 10, 2010, 03:22:02 pm
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.
Title: Re: Bug Reports
Post by: Happybobjr on August 10, 2010, 04:56:01 pm
that might be it,  i'll check with 4.3 though :D
Title: Re: Bug Reports
Post by: Quigibo on August 10, 2010, 05:30:46 pm
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.
Title: Re: Bug Reports
Post by: Happybobjr on August 10, 2010, 05:37:04 pm
so axe 0.4.4 will have it fixed?

*happybobjr goes to his time machine to find out...
Title: Re: Bug Reports
Post by: LordConiupiter on August 11, 2010, 01:49:53 pm
something strange happened to me during the second compilation: at 15% Axe parser stopped, and there appeared a cursor right after the 15% tokens on the screen. when I typed something, it did not appear, but I was enabled to open menu's, but even in the menu's the cursor was on the place it was since the last compiling. I archived everything succesfully, and cleared my RAM, after which everything worked as before: nothing strange happened anymore, though I hadn't changed my code or anything.
Title: Re: Bug Reports
Post by: Quigibo on August 11, 2010, 02:23:53 pm
That was the problem with 0.4.2, I was hoping I fixed that... are you sure you're using the latest version?
Title: Re: Bug Reports
Post by: LordConiupiter on August 11, 2010, 05:26:36 pm
ehm,
* LC goes to check it*

no, I'm sorry. I thought I had already updated, but apperently I haven't jet.
Title: Re: Bug Reports
Post by: ACagliano on August 11, 2010, 08:25:08 pm
When I attempted to compile my star trek game, on pass 1, it got to 98%, then said "Err: Out of Mem". I pressed [prgm] and it kept moving to about 2 or 3 lines away from the end of the code. Then, when I attempted to use [2nd] [quit] to exit the source code, the calc crashed. I am using 0.3.3, at the moment. Has this been fixed already?
Title: Re: Bug Reports
Post by: Raylin on August 11, 2010, 08:29:52 pm
Yes. Upgrade to 0.4.3.
It will save you so much time.
Title: Re: Bug Reports
Post by: ACagliano on August 11, 2010, 08:31:20 pm
Both of my computers are down (not working properly). If they weren't, I would've already.
Title: Re: Bug Reports
Post by: Raylin on August 11, 2010, 08:39:40 pm
Awh. :(
Okay then...
Title: Re: Bug Reports
Post by: LordConiupiter on August 12, 2010, 04:17:45 pm
sometimes I get an error "Pic missing" when I try to compile with an archived Pic, and when i try again it's working again. is this a bug? of an easter egg :P
Title: Re: Bug Reports
Post by: AngelFish on August 16, 2010, 07:20:00 pm
These are actually bugs in HEXPIC, not Axe. But, being as they're both part of the same package, I figured this would warrant:

There are several lines in HEXPIC that bring up various errors and prevent the program from running in the 0.4.3 version. The first bug I noticed was the line
Code: [Select]
pxl-Test(58-Z, X+1->P below the label conditionals. The line appears to reference a pixel outside of the screen and it brings up an error when I try to run it. Changing it to
Code: [Select]
pxl-Test(58-Z, X->P fixes the problem for me.

The second error occurs in Lbl F at the line coded
Code: [Select]
not(pxl-Test(50-Z/7,70+X/7->P70+X/7 is a decimal, so testing the pixel is impossible. This is also easily fixed with the simply addition of a round() command like
Code: [Select]
not(pxl-Test(50-Z/7,round(70+X/7,0->P
The third problem is the same as the second one and occurs just below it. Change the 70+X/7 to a round(70+X/7,0 and the problem is fixed.

Fixing those causes the program to run for me, although the cursor is a bit off. It's still usable though.

:)
Title: Re: Bug Reports
Post by: FinaleTI on August 16, 2010, 07:26:39 pm
HEXPIC isn't an Axe source file. It's just a BASIC program.
Title: Re: Bug Reports
Post by: AngelFish on August 16, 2010, 07:38:55 pm
I know. I only put it here because it's included in the Axe package. Well, that and I don't like making more threads than are necessary. It helps keep forums in some sort of order.
Title: Re: Bug Reports
Post by: FinaleTI on August 16, 2010, 07:45:10 pm
Sorry, I misunderstood.

I just tested HEXPIC from Axe 0.4.3 on Wabbit, and it worked perfectly though...
Title: Re: Bug Reports
Post by: AngelFish on August 16, 2010, 07:47:54 pm
It could just be my calculator then. That would make sense, as my computer and calculator are bitter rivals. I've only managed to get them to play nicely together without losing an OS very recently.
Title: Re: Bug Reports
Post by: Quigibo on August 17, 2010, 02:26:08 am
That's interesting Qwerty.55 I heard that the new Math Print feature can cause some incompatibility with Basic programs, I hope that isn't the case, but no one else has reported the problem before...

And lol, at first from reading your report I thought you actually converted the entire HEXPIC program to make it Axe compatible and got it to work, that would have been amazing. :D
Title: Re: Bug Reports
Post by: AngelFish on August 17, 2010, 02:47:44 am
That's next week ;D

Actually, I have the rest of the night, with nothing to do except a lot of paperwork for college tomorrow. Ah, the wonders of insomnia...

BTW: My calculator normally isn't in Mathprint mode, as I can't stand it, but with the RAM clears from learning Axe, it's been reset to that. So Mathprint may very well be the problem.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 17, 2010, 09:39:42 am
That's interesting Qwerty.55 I heard that the new Math Print feature can cause some incompatibility with Basic programs, I hope that isn't the case, but no one else has reported the problem before...

And lol, at first from reading your report I thought you actually converted the entire HEXPIC program to make it Axe compatible and got it to work, that would have been amazing. :D
Most issues involved inverted text on home screen. However, maybe there were other issues as well. I know it's much slower with MathPrint ON, too.
Title: Re: Bug Reports
Post by: AngelFish on August 17, 2010, 11:15:31 am
I think I figured out the problem: corrupted RAM.

While testing the Axe version of HEXPIC, I actually cleared the memory. Running HEXPIC again shows it working perfectly on my system without the offset that I had noticed yesterday. It's actually kind of creepy how much the program changed while I slept.
Title: Re: Bug Reports
Post by: ztrumpet on August 17, 2010, 11:25:17 am
BTW: My calculator normally isn't in Mathprint mode, as I can't stand it, but with the RAM clears from learning Axe, it's been reset to that. So Mathprint may very well be the problem.
You may want to look at this program: http://www.ticalc.org/archives/files/fileinfo/429/42907.html
If you want, you can turn Math Print off after a RAM Clear without touching the mode menu. It's wonderful. ;D
Title: Re: Bug Reports
Post by: Builderboy on August 17, 2010, 03:52:00 pm
So i am encountering a really weird bug in my game right now.  There is a section of code that is executed when a plasma ball reaches its goal, and only then.  Ive tested this with pauses and display, and confirmed that it only occurs when the plasma ball reaches its goal.  However, there is some code inside this block that is causing a RAM clear under certain conditions.

0->D
0->E

works fine, but

0->D->E

causes a RAM clear!  Whaaaaaaaat?  This bug isnt present when i compile as an application, and im convinced it has something to do with the program size, as adding a Pause 20 also makes the bug go away.  But, the program size is only 8460, which is underneath the 8810 execution limit :( I dont know whats going onn.  And either way, making the program *smaller* is whats causing the Ram clear, so that doesnt make sense...
Title: Re: Bug Reports
Post by: Quigibo on August 17, 2010, 04:21:20 pm
Actually, the limit is less than that.  The calculator won't load the program in ram properly if it's above around 8150-ish, I'm surprised you were able to execute it fine all this time.   I'm afraid I'm not sure exactly what the problem is either.
Title: Re: Bug Reports
Post by: Builderboy on August 17, 2010, 04:30:19 pm
Interesting, even if i am using MirageOS?
Title: Re: Bug Reports
Post by: Runer112 on August 17, 2010, 04:31:27 pm
I believe you can access the full 8811 bytes by compiling your program to Ion/MirageOS and running from a shell, right?
Title: Re: Bug Reports
Post by: Builderboy on August 17, 2010, 04:33:23 pm
Thats what i thought O.o
Title: Re: Bug Reports
Post by: FinaleTI on August 17, 2010, 04:58:00 pm
Is this supposed to happen?

Regardless of whether they draw to the screen or the bufffer, bitmaps glitch up in apps, even if they work flawlessly in programs. Is there any way around this, or do I need to reorganize my sprite data?
Title: Re: Bug Reports
Post by: calcdude84se on August 17, 2010, 05:12:24 pm
This is probably related to why text w/in an app can't be used w/o care (in regular ASM, not Axe)
Like he does for text, Quigibo will have to add support for bitmaps.
Until then, you need to copy the bitmap to RAM before using it.
Title: Re: Bug Reports
Post by: FinaleTI on August 17, 2010, 05:14:50 pm
Would I just copy it to a saferam area or appvar, and then use a pointer to that location in place of the static pointer you'd normally use?
Title: Re: Bug Reports
Post by: calcdude84se on August 17, 2010, 05:28:27 pm
Yeah. Obviously you'd use saferam before you used an appvar ;D
And, now that I think about it, I'm not sure there is a workaround for apps. For text, I'm convinced it does something to the effect of displaying one char at a time, but there's no simple equivalent for a bitmap...
You might have to stick with copying it to RAM, as above.
Title: Re: Bug Reports
Post by: Quigibo on August 17, 2010, 05:44:46 pm
Yes, the bitmap command is not compatible if used with picture data stored in the app.  It will work if the image is copied to saferam or an unarchived variable though.
Title: Re: Bug Reports
Post by: Deep Toaster on August 20, 2010, 01:54:51 pm
I have two very minor bugs, and they might not even apply anymore, since I'm still using Axe 0.2.6 :P But just to let you know, AND logic between 0 and -1 seems to be true. In other words:
Code: (Axe BASIC) [Select]
:If -1 and 0
:Disp "Hi!"
:End
will always display "Hi!". The other bug is that I left my calculator on the Axe Select Program screen for a few minutes (stupid of me :P). After it APD'd, I turned it on again, and it still worked, meaning I could still navigate around Axe, but when I quit, it RAM cleared. Probably not important, but just in case.

Also, I've been wondering: What should people call your language? ;D
Code: (Axe) [Select]
or
Code: (Axe BASIC) [Select]
?
Title: Re: Bug Reports
Post by: LordConiupiter on August 21, 2010, 02:53:48 pm
I would call it Axe, because there will be perhaps some BASIC ans ASM support later on, which I will call then Axe BASIC and Axe ASM ...
Title: Re: Bug Reports
Post by: jnesselr on August 21, 2010, 03:01:38 pm
I have two very minor bugs, and they might not even apply anymore, since I'm still using Axe 0.2.6 :P But just to let you know, AND logic between 0 and -1 seems to be true. In other words:
Code: (Axe BASIC) [Select]
:If -1 and 0
:Disp "Hi!"
:End
will always display "Hi!".
-1=signed version of 255 in 8 bit, or 65535 in 16 bit. So, technically, since it's not 0, it's a 1.  So, the problem seems to be with and itself. Try 255 and 65535 explicitly, and see what happens.
Title: Re: Bug Reports
Post by: calcdude84se on August 21, 2010, 03:47:47 pm
Oh, I know why it's happening.
" and " is an 8-bit AND only. It only AND's the LSB, putting the MSB of the first argument into the MSB of the answer.
So "-1 and 0" simplifies to "EFFFF and 0", which simplifies to "EFF00", since only the LSB is operated upon.
What you need to do is use the 16-bit version, which, for AND, is the statplot dot. (Looks like a raised single pixel, pretty much).
Title: Re: Bug Reports
Post by: Runer112 on August 21, 2010, 08:35:42 pm
No biggie, but the title of the new Commands.htm still says Axe 0.4.3. Make sure to keep that updated! :P
Title: Re: Bug Reports
Post by: patriotsfan on August 21, 2010, 08:43:32 pm
Not to be picky, but in the documentation on page 17 about the Pong game explanation, you forgot the r in "first". :P
Title: Re: Bug Reports
Post by: Happybobjr on August 21, 2010, 11:09:44 pm
so does anyone else on axe guess always (except for special exceptions) always get 4?
Title: Re: Bug Reports
Post by: Quigibo on August 22, 2010, 03:17:25 pm
Thanks for those, I'll get them fixed.  I have hardly been able to use the internet yet so I don't know how often I'll be able to post for the next few days.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 22, 2010, 03:28:01 pm
Yeah I saw on fb, I guessed you would most likely not get online for an extended period of time. Btw, will version 0.5.0 be the last version before final release?
Title: Re: Bug Reports
Post by: Deep Toaster on August 23, 2010, 01:38:22 pm
Oh, I know why it's happening.
" and " is an 8-bit AND only. It only AND's the LSB, putting the MSB of the first argument into the MSB of the answer.
So "-1 and 0" simplifies to "EFFFF and 0", which simplifies to "EFF00", since only the LSB is operated upon.
What you need to do is use the 16-bit version, which, for AND, is the statplot dot. (Looks like a raised single pixel, pretty much).

Oh, I get it. Thanks.
Title: Re: Bug Reports
Post by: Runer112 on August 23, 2010, 07:30:58 pm
I don't know which you intended, but the commands list says float{ is mapped to iPart(, while the actual application maps it to fPart(.
Title: Re: Bug Reports
Post by: Michael_Lee on August 23, 2010, 11:00:15 pm
I'm not sure if it's my calculator that's the problem, but lately, it's been running into several weird glitches.

For example, when I'm trying to compile a program, it'll occasionally give me an error.  It zooms down to the end of the program, and for some inexplicable reason, a whole bunch of nonsense symbols were tacked on to the end.  

Also, once, I kept trying to run my program (no shell), like this
Code: [Select]
asm(FALL1which kept returning this
Code: [Select]
asm(FALL1
            Done
without actually executing the code (which worked fine for the past several weeks)
But when I go back up to highlight it, it turns into a weird combination of symbols, like this
Code: [Select]
Sin(A????????rref((or something vaguely like that)
I had to reset my RAM, but it hasn't happened again.

I have OS 2.53 MP, and Axe 0.4.4.

I've attached my source, in case it's something I'm doing.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 23, 2010, 11:04:55 pm
Mhmm, I remember often getting the Asm(prgmFALL1 Done thing before. It wouldn't even bother executing anymore ASM program from the home screen. In one case, I fixed this with a RAM clear then re-compiling the program. I never got the Sin(A????????rref(, though (although maybe I did and I didn't notice). I'M not too sure if this is an Axe bug, as often it was the result of bad Axe code I created.

IN any case, make sure to backup frequently, in case!

By the way, are you the guy you did the Falldown clone with the cat on ticalc.org? I liked it. You should post about your new projects or release if you get any in the future :)
Title: Re: Bug Reports
Post by: Michael_Lee on August 23, 2010, 11:16:25 pm
Okay, that was quick.
I was still editing my post...
That was kind of scary... but in a good way ;D.

Ah, so it is probably my fault.
Still, it ran fine under Axe 0.4.3, and I added only minimal tweaks...
Hmm.

Yeah, that was me - I'm flattered that you like it.
Although, really, it didn't seem like a big enough project to be posting about - there are lots of Falldown clones available, and mine really isn't original.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 23, 2010, 11:20:06 pm
Yeah I happened to check new posts and opened this topic ;D

As for the error, this is something that Quigibo might check, then. I think he's slowing down updates, though, so the next update may take a long while until it comes out. Otherwise, someone could maybe check the code. I would help but I haven't used Axe much lately D:

And I see, well feel free to post about your other stuff if you feel like it later ^^
Title: Re: Bug Reports
Post by: ztrumpet on August 24, 2010, 09:12:22 am
For example, when I'm trying to compile a program, it'll occasionally give me an error.  It zooms down to the end of the program, and for some inexplicable reason, a whole bunch of nonsense symbols were tacked on to the end. 
...
But when I go back up to highlight it, it turns into a weird combination of symbols, like this
Code: [Select]
Sin(A????????rref((or something vaguely like that)
I had to reset my RAM, but it hasn't happened again.
These two sound like you ran a program that corrupted something.  I doubt if it's the Axe App itself. :)

Also, once, I kept trying to run my program (no shell), like this
Code: [Select]
asm(FALL1which kept returning this
Code: [Select]
asm(FALL1
            Done
This sounds like it was compiled for Mirage or Doors, as if you compile a program for either of these shells, it must begin with a Return (this is added by the parser), because they didn't want you running their programs from the homescreen (due to Mirage specific libraries).  Try compiling it for Ion or No Shell. :)

Your game's pretty fun!  I happened to notice it a while back, so... http://ourl.ca/6731/110927
Nice job!
Title: Re: Bug Reports
Post by: LordConiupiter on August 24, 2010, 11:29:42 am
when I tried to compile a program as an Application (which already existed) I got a "Defragmenting..."-screen. after a while I got a RAM clear. I saw the Application was gone, and tried another time: and now I succeeded!
when i tried it for the third time, everything went the way it should, except the 2nd Pass %-value was flickering very weirdly, and so it was the 4th time.
Title: Re: Bug Reports
Post by: Raylin on August 24, 2010, 12:50:04 pm
I am intrigued.

Observe the following specs.

TI-84+ Silver Edition (http://www.ticalc.org/basics/calculators/ti-84plus-se.html)
TI-83+ Silver Edition (http://www.ticalc.org/basics/calculators/ti-83plus-se.html)

Now, why doesn't the Full command work on the TI-83+ Silver Edition?
Title: Re: Bug Reports
Post by: calc84maniac on August 24, 2010, 12:59:23 pm
I am intrigued.

Observe the following specs.

TI-84+ Silver Edition (http://www.ticalc.org/basics/calculators/ti-84plus-se.html)
TI-83+ Silver Edition (http://www.ticalc.org/basics/calculators/ti-83plus-se.html)

Now, why doesn't the Full command work on the TI-83+ Silver Edition?

I wasn't aware that it doesn't?
Title: Re: Bug Reports
Post by: Raylin on August 24, 2010, 01:03:32 pm
@calc84maniac: That's aimed at Quigibo. :P Just wondering why it doesn't work.

EDIT: Derp. Quigibo pulled some sneaky programming and created a conditional If Full loop in the program I tested. Problem solved.
Title: Re: Bug Reports
Post by: calc84maniac on August 24, 2010, 01:13:35 pm
Btw, just found a bug. If you do a For( loop that loops to 65535, it never exits.
Title: Re: Bug Reports
Post by: Builderboy on August 24, 2010, 01:19:16 pm
Interesting o.O Under what circumstances did you encounter this? ;D just curious why you were looping like that :P
Title: Re: Bug Reports
Post by: calcdude84se on August 24, 2010, 01:19:31 pm
That's unfixable :)
The corresponding ASM is this, and it doesn't exit:
Code: [Select]
start = 9001
end = 65535
ld hl,start
loop:
;Loop code here
inc hl
ld de,end
push hl
sub hl,de
pop hl
jr z,loop
jr c,loop
Basically, 65535+1 is less then 65535 ;)
Edit: Okay, my ASM is messed up, but you get the point :P
Edit 2: Okay, I think it works now
Title: Re: Bug Reports
Post by: calc84maniac on August 24, 2010, 01:35:43 pm
Hmm, the asm code seems to be more like this (with For(A,0,65535)):
Code: [Select]
ld hl,0
 jr start_for
for_loop:
 ld hl,(var_a)
 inc hl
start_for:
 push hl
 ld (var_a),hl
 ld hl,65535
 pop de
 or a
 sbc hl,de
 jp c,end_for
 ;loop body here
 jp for_loop
end_for:

I propose the following modification be used:
Code: [Select]
ld hl,0
 dec hl ;This can be avoided if start value is a constant
 jr start_for
for_loop:
 ld hl,(var_a)
start_for:
 push hl
 inc hl
 ld (var_a),hl
 ld hl,65535
 pop de
 scf
 sbc hl,de
 jp c,end_for
 ;loop body here
 jp for_loop
end_for:
Edit:
Wait a second, that would exit the loop before the first iteration. meh
Title: Re: Bug Reports
Post by: calcdude84se on August 24, 2010, 01:36:46 pm
I was just giving a short piece of ASM that does the same thing :) Same basic problem, though
Title: Re: Bug Reports
Post by: calc84maniac on August 24, 2010, 01:40:43 pm
Okay well, at least here is a general optimization (that doesn't fix the problem, but reduces code size)
Code: [Select]
ld hl,start_val
for_loop:
 push hl
 ld (loop_var),hl
 ld hl,end_val
 pop de
 or a
 sbc hl,de
 jp c,end_for
 ;loop body here
 ld hl,(loop_var)
 inc hl
 jp for_loop
end_for:
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 24, 2010, 01:52:00 pm
I am intrigued.

Observe the following specs.

TI-84+ Silver Edition (http://www.ticalc.org/basics/calculators/ti-84plus-se.html)
TI-83+ Silver Edition (http://www.ticalc.org/basics/calculators/ti-83plus-se.html)

Now, why doesn't the Full command work on the TI-83+ Silver Edition?

I wasn't aware that it doesn't?
Wow I didn't notice that either. One thing I think is that a while ago, Quigibo wasn't aware a TI-83+SE existed. Some ppl aren't because this calc went on sale only for 3 years and was discontinued the day the 84+SE came out. Since it wears 83+ in its name, many people think it's a 6 MHz calc. Quigibo probably just check if the calc is a 84+/84+SE, otherwise Full is not enabled.

That makes it more cool to own a 83+SE ;D
Title: Re: Bug Reports
Post by: ztrumpet on August 24, 2010, 05:13:07 pm
That makes it more cool to own a 83+SE ;D
Yup! ;D

Although many of The Penguin's games make you press Graph to play them before "playing them". :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 24, 2010, 05:39:41 pm
Yeah true, although I had this happen on WabbitEmu too. (in 84 mode)
Title: Re: Bug Reports
Post by: guy6020665 on August 24, 2010, 05:55:14 pm
Weird bug that I can't seem to understand sometimes after running an Axe program random characters will appear on the screen, can't post a screen shot but it kind of looks like the following (I will use the & symbol for blank spaces)

Should be happening

XXXXXXXXXXXXXXXX
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
XXXXXXXXXXXXXXXX



What is happening is that after it displays the above and ends the program, on a random column, a random tile will be completely black and then a random character will appear under it and they will alternate until it gets to the bottom of the screen. No idea why, it has happened before when I was just messing around with code, but i don't remember my source from before.
Title: Re: Bug Reports
Post by: LordConiupiter on August 24, 2010, 06:40:58 pm
I got something like this also, with Axe 0.4.4. also after running a program that ended with a Disp command. when i modified some things, everything went all right again. ???
Title: Re: Bug Reports
Post by: ztrumpet on August 24, 2010, 07:50:25 pm
Weird bug that I can't seem to understand sometimes after running an Axe program random characters will appear on the screen, can't post a screen shot but it kind of looks like the following (I will use the & symbol for blank spaces)

Should be happening

XXXXXXXXXXXXXXXX
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
XXXXXXXXXXXXXXXX



What is happening is that after it displays the above and ends the program, on a random column, a random tile will be completely black and then a random character will appear under it and they will alternate until it gets to the bottom of the screen. No idea why, it has happened before when I was just messing around with code, but i don't remember my source from before.
This is leftover data in L6.  If you use L6 in your program, you should have a ClrHome near the end. :)
Title: Re: Bug Reports
Post by: guy6020665 on August 24, 2010, 07:53:53 pm
Weird bug that I can't seem to understand sometimes after running an Axe program random characters will appear on the screen, can't post a screen shot but it kind of looks like the following (I will use the & symbol for blank spaces)

Should be happening

XXXXXXXXXXXXXXXX
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
X&&&&&&&&&&&&&&X
XXXXXXXXXXXXXXXX



What is happening is that after it displays the above and ends the program, on a random column, a random tile will be completely black and then a random character will appear under it and they will alternate until it gets to the bottom of the screen. No idea why, it has happened before when I was just messing around with code, but i don't remember my source from before.
This is leftover data in L6.  If you use L6 in your program, you should have a ClrHome near the end. :)

I was using Runer's code for reading from matrices and i don't see the use of L6, but maybe something else uses it?
Title: Re: Bug Reports
Post by: ztrumpet on August 24, 2010, 07:55:45 pm
Hmm, then I don't know what's happening. =/  Good luck. :)
Title: Re: Bug Reports
Post by: calcdude84se on August 24, 2010, 08:01:17 pm
That is indeed something weird with the homescreen... I've seen that before (not in Axe), but never heard why.
Yeah, a ClrHome should fix it, though it is often a sign of something more serious x.x
(And btw, this should have nothing to do with L6 ;D)
Title: Re: Bug Reports
Post by: guy6020665 on August 24, 2010, 08:09:01 pm
That is indeed something weird with the homescreen... I've seen that before (not in Axe), but never heard why.
Yeah, a ClrHome should fix it, though it is often a sign of something more serious x.x
(And btw, this should have nothing to do with L6 ;D)

Ok I'm using this in a basic program, using a basic ClrHome at the end does fix it but I need it to be on the screen for the map. And if I exit using [ON] the problem persists, not a big deal anymore, but if someone exits using [ON] it might make them think I'm crashing their calc. (Edit: The people who are less invovled with programming and more involved with playing that is.)
Title: Re: Bug Reports
Post by: calc84maniac on August 24, 2010, 10:05:19 pm
It's because the cursor is off the bottom of the screen, I think. An Output(0) should set it to the upper left I believe.
Title: Re: Bug Reports
Post by: ztrumpet on August 25, 2010, 08:23:53 am
Boy am I dumb! D=

I said L6.  I meant L5.  Please forgive this pitiful error.  L5 is the text shadow, and that's where you can modify the contents of the homescreen. :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 25, 2010, 09:37:31 pm
Modify the content as in the chars displayed?
Title: Re: Bug Reports
Post by: LordConiupiter on August 27, 2010, 06:29:15 am
yes, since there are 128 char places on the screen, the length of L5 is 128 bytes. so you could write your own Disp or Output( routine :P
Title: Re: Bug Reports
Post by: calc84maniac on August 27, 2010, 12:12:49 pm
yes, since there are 128 char places on the screen, the length of L5 is 128 bytes. so you could write your own Disp or Output( routine :P
Though, writing to this memory doesn't actually update the screen. I think there's some OS routine that copies the 128-char buffer to the screen, but it's probably not accessible in Axe without using Asm()
Title: Re: Bug Reports
Post by: LordConiupiter on August 27, 2010, 12:37:47 pm
when the output command is performed, then the screen is also being redrawn, I thought. so when you call Output(0,0,"") after your routine (which would be pretty useless of course), your data will be drawn! but I'm not sure about that right now. Not anymore in any case...
Title: Re: Bug Reports
Post by: coolsnake on August 27, 2010, 12:48:52 pm
Full speed mode seems to be actived after running the input command.
I've found out by using it in conjunction with the pause commmand.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 27, 2010, 04:30:27 pm
Ohai coolsnake and welcome here :)

Thanks for the bug reports. I hope Quigibo isn't too busy when he starts college so he can still do some updates. I wonder if this error could have something to do with the TI-OS? I think Input command uses a BCall and those sometimes changes the settings people set in their ASM programs. I remember archiving/unarchiving using certain routines turned ON the busy indicator.
Title: Re: Bug Reports
Post by: coolsnake on August 29, 2010, 06:18:44 pm
Thank you :)

I also have no idea if this is intentional or not, but shouldn't the X and Y coordinates in the drawing/text commands be reversed?
e.g in TI-basic you have output(Y,X but in Axe it's output(X,Y. It's kindof confusing  :P

I kindof prefer The TI-basic syntax because it's handled like matrices are, first rows and then columns.
Title: Re: Bug Reports
Post by: Happybobjr on August 29, 2010, 07:31:06 pm
Thank you :)

I also have no idea if this is intentional or not, but shouldn't the X and Y coordinates in the drawing/text commands be reversed?
e.g in TI-basic you have output(Y,X but in Axe it's output(X,Y. It's kindof confusing  :P

I kindof prefer The TI-basic syntax because it's handled like matrices are, first rows and then columns.


Its that way on purpose.
most people that don't know much about ti-basic would find it to hard for pxlon(y,x)
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 30, 2010, 01:31:35 am
What Happybobjr said. IN most languages it's X,Y and in BASIC, some commands such as line() and pt-on() uses x,y too.
Title: Re: Bug Reports
Post by: Quigibo on August 30, 2010, 02:54:49 am
Yeah, it was done specifically for consistency so that you don't have to think to yourself "Did this command use (x,y) or (y,x)?"

That problem with the input function I can probably fix.  I need to find where the buffer is that holds the input string so I can clear it.
Title: Re: Bug Reports
Post by: LordConiupiter on September 02, 2010, 07:03:29 am
I have a pretty big problem. Is there also a maximum of includes? I added an include to my contest project and changed some vars like A, B, X, Y etc. to poiners like {L1+A}, and now the compiler craches around 40 % of the 1st Pass. is my contest project too big? what could be the problem?
Title: Re: Bug Reports
Post by: Builderboy on September 02, 2010, 10:53:08 am
Well what error is it telling you?  Or is it actualy crashing?
Title: Re: Bug Reports
Post by: LordConiupiter on September 02, 2010, 10:58:08 am
it's crashing and gives me a RAM clear, so it's nothing telling than just
Code: (screen) [Select]
Compiling
1st Pass   41%
Title: Re: Bug Reports
Post by: Builderboy on September 02, 2010, 11:25:35 am
Yikes, you are on the latest version right? 
Title: Re: Bug Reports
Post by: LordConiupiter on September 02, 2010, 12:16:21 pm
0.4.4 :(
Title: Re: Bug Reports
Post by: Ikkerens on September 02, 2010, 01:34:06 pm
Another bug, but only when compiling as app.
Performing the following won't do anything:
Code: [Select]
1->{Y*12+X+GDB1}

Works when compiling for mirage or no shell, but as an app, it looks like its simply ignoring this line.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 02, 2010, 01:42:24 pm
Ew, those seems like nasty bugs, especially ACagliano x.x

Were they introduced in new versions?

Either way good luck fixing them Quigibo. I hope they aren't too hard to fix x.x
Title: Re: Bug Reports
Post by: FinaleTI on September 02, 2010, 03:09:43 pm
Another bug, but only when compiling as app.
Performing the following won't do anything:
Code: [Select]
1->{Y*12+X+GDB1}

Works when compiling for mirage or no shell, but as an app, it looks like its simply ignoring this line.

Actually, I don't think that's a bug. That line is a form of self-modifying code that changes the pointed to value in program memory.
Apps don't support SMC, which is why this doesn't work.
Title: Re: Bug Reports
Post by: Ikkerens on September 02, 2010, 03:25:34 pm
Ah, I see.
Do you maybe know any alternative of doing this?
Cause I use SMC is every single program of mine.
Title: Re: Bug Reports
Post by: LordConiupiter on September 02, 2010, 03:57:27 pm
copy the data from GDB1 or whatever data into a freeRAM area, and then u can modify it as much as u want!
you could also decide to use AppVars for all the data, which could be Archived and UnArchived whenever u want.

got another bug: I can't do the following:
Code: [Select]
1->{L1}->{L5+4}
and I would really like to, because I am told that it is much more efficient this way.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 03, 2010, 01:24:28 am
Yeah the downside of Flash applications is that they do not support SMC.
Title: Re: Bug Reports
Post by: Builderboy on September 03, 2010, 01:26:09 am
interesting, that sounds like a bug to me!  Thats not supposed to happen, its supposed to return the value of what you put in.  (unless that has changed to something else??)
Title: Re: Bug Reports
Post by: LordConiupiter on September 03, 2010, 01:37:20 am
interesting, that sounds like a bug to me!  Thats not supposed to happen, its supposed to return the value of what you put in.  (unless that has changed to something else??)
what do you mean? It changed? I've no Interrupts enabled, and the only thing I know is that {L1} holds the right value, but {L5+4} doesn't...
Title: Re: Bug Reports
Post by: Builderboy on September 03, 2010, 01:40:09 am
I mean that the value returned should be the value put in.  So if you store 1 into {L1}, and then store that somewhere else, it should still be 1, but apparently its not anymore o.O

It used to be that it returned L1 instead of 1
Title: Re: Bug Reports
Post by: LordConiupiter on September 03, 2010, 01:46:06 am
well, perhaps that's still working that way right now then.
Title: Re: Bug Reports
Post by: Builderboy on September 03, 2010, 01:47:12 am
I tried your exact code though, and 49 ended up inside {L5+4} o.O Seemingly random number
Title: Re: Bug Reports
Post by: LordConiupiter on September 03, 2010, 01:48:31 am
did you take the 2 byte expression? or dit you only take {L5+4}? an adress is allways a 16 bit number, right?
Title: Re: Bug Reports
Post by: Builderboy on September 03, 2010, 01:49:06 am
Ah yes thats true, hmmmmm, let me check real quick

Weird, so its definetaly 49 and not an index, even using complete 2byte commands

Code: [Select]
1->{L1}r->{L5+4}r
Output(0,0,{L5+4}r>dec

gives me 49 O.O
Im going to run some more tests...

Oh, silly me its because im OUTPUTING to the screen and that messes with L5 :P Let me try with a different location...

Ok, im not getting any bugs at all with other locations, i think that might be the problem, were you outputing to the screen to view the contents?
Title: Re: Bug Reports
Post by: LordConiupiter on September 03, 2010, 02:15:17 am
NO, i wasn't, it was just an example. I did something like this:
Code: [Select]
.B
L1->Q
1->N+1->O
1->{Q+O}->{Q+N}
which gives me a 37 ???
Title: Re: Bug Reports
Post by: Builderboy on September 03, 2010, 02:23:04 am
Weird O.O That gives me a 38 though... Hmmm i guess quigibo will have to take a look at this, seems to be a bug
Title: Re: Bug Reports
Post by: Quigibo on September 03, 2010, 03:05:42 am
I think it's just the tricky double standard that was introduced when I added that optimization.

The routine to store a number to a constant address is different than the routine to store to a variable address.  Different enough in fact to have a different return value.  So doing 6->{8*4+L1} returns 6 and can be used in series with other storing since the address inside the brackets is a constant, definite number.  6->{A*4+L1} on the other hand returns the address (what's inside the brackets) instead of 6 since it has a variable address.

The technical reason is that if the expression inside has to be evaluated during run-time, then that expression will be the last thing evaluated and hence the thing returned after the store.  Constant addresses on the other hand are evaluated during compile-time and so the last real evaluation was the expression being stored so it can be chained with other stores.  Don't forget though, you can still do some optimizations with return addresses:

Code: [Select]
A->{P}
B->{P+1}
C->{P+2}

.Can be optimized to:

C->{B->{A->{P}+1}+1}

.This optimization only works with variable addresses
.Constant addresses are automatically optimized anyway

The only other weird thing is that when storing to a  variable address with a full 2 byte number (using the r modifier) then it actually returns the address plus 1.  That actually makes it compatible with the code example above since you would otherwise have to increment by 2 every time.

But there might be a bug treating some constants as variables instead, so I'll have to look into that.
Title: Re: Bug Reports
Post by: FinaleTI on September 03, 2010, 07:21:15 pm
I'm not exactly sure what happened, but today my Axe back-up of ABATTEST (my Nostalgia battle engine) was corrupted. The source was fine until you reached the casting animation sub, then between that and the enemy's damage sub was replaced with a copy of the data I had defined at the beginning of my program.

The only apps I have installed on my calc are Celtic III, CalcUtil and Axe (v0.4.4 with Auto-Backup on). I tried to compile ABATTEST after adding the magic damage sub-routine, but I received some ERR:LABEL's saying Lbl AHP (which was defined) didn't exist, so I uninstalled CalcUtil and unarchived ABATTEST. After I used the Instant Goto to jump to the error twice, both times the line was mostly replaced by random, commented out hex code. I rearchived ABATTEST, RAM Cleared, then reinstalled a 3 apps above. Upon trying to compile ABATTEST again, the first pass reached 100%, will the second pass reached 99% before erring. After that, I unarchived ABATTEST and uninstalled CalcUtil and used Instant Goto to jump to the source of the error. I was puzzled when I jumped to the enemy damage sub to see that it was the end of the program. I was even more confused to scroll up and see my data that I defined at the beginning of ABATTEST. I exited out and opened it up again, and I scrolled down from the top to see my data, then I began to see my normal code, then when I reached the casting animation, I noticed the commented line ".Aria Casting Animation" read something like ".Aria Casting AnimaList>matr(NOSBAT" after that was the copied data and the enemy damage sub.

I haven't had any problems with these apps before except that if CalcUtil is installed, when you use Instant Goto and exit the program, CalcUtil will crash after the save changes screen.

If it's within the contest rules, I can email or PM you the corrupted back-up.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 03, 2010, 07:39:45 pm
Yes, you can e-mail Quigibo the code, as he has access to the entries e-mail anyway
Title: Re: Bug Reports
Post by: FinaleTI on September 03, 2010, 07:54:02 pm
So I should send it to the contest e-mail?
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 03, 2010, 08:10:20 pm
Nah, e-mail Quigibo, preferably. I would prefer only entries to the contest e-mail.
Title: Re: Bug Reports
Post by: FinaleTI on September 03, 2010, 08:18:24 pm
OK. Will do.
Title: Re: Bug Reports
Post by: nemo on September 03, 2010, 09:30:33 pm
the following code doesn't work:
Code: [Select]
.AXEPARSE
[FFFFFFFFFFFFFFFF]->Pic1
fnInt(R,0)
Repeat getKey(15)
FnOff
DispGraph
FnOn
End
LnReg
Return
Lbl R
Pt-Change(0,0,Pic1

does not work. but changing Lbl R to Lbl H makes it work. i was talking to calcdude on IRC and he said it's an off-by-10 error, and that it was fixed awhile ago.

edit: oh, and i'm using axe 4.4

edit 2: erm, sorry. i forgot to transfer axe 4.4 to my calc i'm still using axe 4.3.... sorry about the post.
Title: Re: Bug Reports
Post by: FinaleTI on September 03, 2010, 09:35:36 pm
I just tested in in Axe 0.4.4 and it worked perfectly for me.
Title: Re: Bug Reports
Post by: calcdude84se on September 03, 2010, 09:35:37 pm
relevant post:
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.
Interesting that it's still in 0.4.4...

Edit: Nemo says he is in fact still using 0.4.3. Oops :P
Title: Re: Bug Reports
Post by: nemo on September 03, 2010, 09:38:08 pm
yeah, my bad guys   :-X just tested it on an emu using 4.4 and it worked fine.
Title: Re: Bug Reports
Post by: FinaleTI on September 03, 2010, 09:41:16 pm
No problem, we all make mistakes.
Title: Re: Bug Reports
Post by: Quigibo on September 03, 2010, 11:08:54 pm
FinaleTI, I am guessing that your error is probably due to the error scrolling issue on the first page of the bug reports.  For some reason unknown to me, when you attempt to scroll to errors in files ~7k or larger the calculator will sometimes corrupt some of the data in the file after scrolling.  Then, if you quit out of it and try compiling again with auto-backups on, then it will be making a backup of the newly corrupted file.

Since I don't know how to fix this, I would recommend splitting the file into smaller programs or avoid using error scrolling completely.  If this happened with a small file, that would be really bad and I have no clue what could cause that.
Title: Re: Bug Reports
Post by: FinaleTI on September 03, 2010, 11:18:31 pm
Ok. Yeah, I've been meaning to export most of the data in that program, so this is pretty good motivation to do so.
Title: Re: Bug Reports
Post by: Michael_Lee on September 04, 2010, 10:09:46 pm
I tried running this sample program:

Code: [Select]
.TEST
ClrHome
If 1=0
1->A
ElseIf2=2
2->A
If 0=1
1->B
ElseIf 1=1
2->B
End
End
Disp A->DEC,B->DEC,i             i for newline

Which I interpreted as this (the indents showing program flow)
Code: [Select]
.TEST
ClrHome
If 1=0
    1->A
ElseIf2=2
    2->A
    If 0=1
        1->B
    ElseIf 1=1
        2->B
    End
End
Disp A->DEC,B->DEC,i             i for newline

Compiling this returns a BLOCK error - it won't compile until I take off the last END, which is weird because you would think that two If statements would need two End statements.
This suggests to me that ElseIfs don't seem to like being inside other ElseIfs.
Have I misunderstood how ElseIfs work, or is this a bug?
Title: Re: Bug Reports
Post by: Quigibo on September 04, 2010, 10:13:06 pm
Interesting bug.  I haven't tried this yet, so I will do more testing to try and fix it.
Title: Re: Bug Reports
Post by: nemo on September 05, 2010, 10:02:23 pm
pressing [ON] while in the input routine causes the calculator to go into an infinite loop (i think. the run indicator kept going for about two minutes before i pulled a battery. also, i had DiagnosticOff at the beginning of the program).
Title: Re: Bug Reports
Post by: LordConiupiter on September 06, 2010, 11:41:40 am
I get pretty often the error: ERR:PIC MISSING, while my Pics are all in Archive. when I compile my prog right after it, the error seems to be solved, in other words: i don't get the error anymore. I haven't found any reason jet for the error, but it is possible this error only shows up when I just sent programs to my calc with TiLP.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 07, 2010, 02:44:06 am
Do you mean the first time you compile the errior show up and the second attempt it won't? Do you need to do something inbetween (such as Garbage Collecting, archiving/unarchiving)?
Title: Re: Bug Reports
Post by: LordConiupiter on September 07, 2010, 02:48:39 am
Do you mean the first time you compile the error show up and the second attempt it won't? Do you need to do something inbetween (such as Garbage Collecting, archiving/unarchiving)?
yes, that's exactly what I mean. I do nothing in between, and then it suddenly compiles without any errors.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 07, 2010, 02:58:14 am
Ah ok. Weird bug x.x.
Title: Re: Bug Reports
Post by: LordConiupiter on September 09, 2010, 10:56:11 am
when the calc is compiling, and laid away, and then an error occurs, and when I do nothing then, so APD is activated, and when I turn it on again, I get an
Code: [Select]
ERR: UNKNOWN ERR
Code: 4423816
and after this a RAM clear.

when I write an App that is very small (455 Bytes), the parser gives me another unknown error, Code: 4435555
Title: Re: Bug Reports
Post by: Quigibo on September 09, 2010, 02:42:01 pm
Yeah I should turn ADP off, I completely forgot about that.  As for that app error, that's really strange because that error code doesn't exist.  If you can replicate it, can you email me the source or upload it if its not for the contest?  Thanks.
Title: Re: Bug Reports
Post by: LordConiupiter on September 09, 2010, 05:06:10 pm
well, I got this error earlier, but right now it isn't happening. I'll try to replicate it, but I'm not sure if I will succeed before the contest ends :P
Title: Re: Bug Reports
Post by: ACagliano on September 14, 2010, 01:31:23 pm
Quigbo. I have something to report. I don't know if its just an issue with me, but here it is. The application CalcUtil seems to conflict with Axe's error scrolling. With CalcUtil installed, Axe scrolls to the error. I correct it, then go to [2nd] [QUIT], and it crashes. This does not happen when I uninstall CalcUtil, but always happens with it installed.
Title: Re: Bug Reports
Post by: FinaleTI on September 14, 2010, 01:32:37 pm
Quigbo. I have something to report. I don't know if its just an issue with me, but here it is. The application CalcUtil seems to conflict with Axe's error scrolling. With CalcUtil installed, Axe scrolls to the error. I correct it, then go to [2nd] [QUIT], and it crashes. This does not happen when I uninstall CalcUtil, but always happens with it installed.
This happens to me too.
Title: Re: Bug Reports
Post by: ACagliano on September 14, 2010, 01:40:14 pm
Quigbo. I have something to report. I don't know if its just an issue with me, but here it is. The application CalcUtil seems to conflict with Axe's error scrolling. With CalcUtil installed, Axe scrolls to the error. I correct it, then go to [2nd] [QUIT], and it crashes. This does not happen when I uninstall CalcUtil, but always happens with it installed.
This happens to me too.

Would that make it an conflict with CalcUtil?
Title: Re: Bug Reports
Post by: FinaleTI on September 14, 2010, 01:43:52 pm
Perhaps the error scrolling conflicts with CalcUtil's hooks?

What I usually end up doing is when I get an error is quitting Axe, uninstalling CalcUtil, recompiling and jumping to the error, then re-installing CalcUtil when that's done. It's annoying, but it prevents me from losing a lot of my work.
Title: Re: Bug Reports
Post by: ACagliano on September 14, 2010, 01:46:13 pm
I'll send Quigbo a direct message about this and direct him to this topic.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 14, 2010, 01:53:09 pm
Does that happens with Doors CS7 too?
Title: Re: Bug Reports
Post by: ACagliano on September 14, 2010, 02:00:15 pm
Doesn't seem to. And it doesn't happen with DCS and CalcUtil chaining either. It only happens in large files (seemingly over 1k) and with only CalcUtil by itself.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 14, 2010, 02:27:50 pm
Ah I see. I guess it's a conflict between both apps, then. Also try to not double-post :P.
Title: Re: Bug Reports
Post by: ACagliano on September 14, 2010, 02:50:10 pm
Ah I see. I guess it's a conflict between both apps, then. Also try to not double-post :P.

I actually meant to delete "I'll try", thus making it not a double post, but forgot. Its done now sooo....

What double post? I have no clue what you are talking about! lol
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 14, 2010, 02:55:37 pm
Until a few minutes ago, above my posts there were two replies within minutes of each others :P. It was deleted it seems, though. I see it in the Trash bin :P

I'll try it.
Title: Re: Bug Reports
Post by: ACagliano on September 14, 2010, 02:58:03 pm
Until a few minutes ago, above my posts there were two replies within minutes of each others :P. It was deleted it seems, though. I see it in the Trash bin :P

I'll try it.

Lol. I was giving you a hard time. I deleted it myself after realizing it was a double post.
Title: Re: Bug Reports
Post by: LordConiupiter on September 14, 2010, 03:14:33 pm
I got the same error as here (http://ourl.ca/4072/115984)! this is what my screen looks like:
Code: (screen) [Select]
COMPILING...
1st Pass:  100%
2nd Pass:  100%
Writing App...
15258 Byt   95%
ERR: UNKNOWN ERR
Code: 4435555


I tried it 4 times, and this screen showed up every time. I'll send the source to u after the contest ends, because this is with my contest project...

RAM clear :( got the APD-error after writing this post, and copying my screen data, for I waited too long for touching my calc...
but I have a back-up!!!

EDIT: I think I got it! my App compiled after a Garbage Collect! And the last time this error showed up, it was the same story. So I think you should do an automatic Garbage collect when this error occurs, though I'm not completely sure about that...
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 14, 2010, 03:28:35 pm
Well, as Quigibo is judge (I think he still is?) you can send him the entire source fine.

I also had issues compiling Ikkerens entry with 0.4.4. The text in-game is all garbled while on his calc (2.43) it's fine. I tried on both TI-Nspire OS 2.54 MP and a ROM for 84+ OS 2.41
Title: Re: Bug Reports
Post by: Builderboy on September 17, 2010, 03:29:04 am
Hey ive been meaning to ask this for a while now, why is it that when compiling for an App and after defragmenting, the compiling seems so slow?
Title: Re: Bug Reports
Post by: Deep Toaster on September 17, 2010, 07:16:46 pm
Maybe it's the smaller archive space? I had that problem after compiling too many prgms, and a GarbageCollect worked fine.
Title: Re: Bug Reports
Post by: Michael_Lee on September 18, 2010, 10:18:24 am
Yes - garbage collecting seems to work wonders.  I find that whenever I get a mysterious error that never happened before, garbage collecting usually clears things up.
Title: Re: Bug Reports
Post by: calcdude84se on September 19, 2010, 02:46:32 pm
Code: [Select]
input acts funnily...
prgmBASIC
[code=BASIC]Input "THE GAME: ",A
prgmAXE when compiled
Code: (Axe) [Select]
inputRunning these two programs in the order given, My screen will look like this:
prgmBASIC
THE GAME: 1337
            Done
Asm(prgmAXE
THE GAME:

In addition, pressing 2nd+Quit will quit the program, causing memory leaks, and it may be the same for 2nd+Off (haven't tried yet)[/code]
Edit: Weird formatting errors. Can't fix.
Title: Re: Bug Reports
Post by: Builderboy on September 19, 2010, 03:33:18 pm
I think this has been reported already?  Surely there has been many a but with the input command and stuff before it x.x seems like a common bug
Title: Re: Bug Reports
Post by: calcdude84se on September 19, 2010, 03:35:35 pm
I'm not sure, it might have been.
At any rate I'm bumping it ;D
Title: Re: Bug Reports
Post by: ztrumpet on September 19, 2010, 05:19:27 pm
The input bug seems pretty glitchy. =/
Title: Re: Bug Reports
Post by: Quigibo on September 19, 2010, 05:54:16 pm
Well apparently the buffer where the input string is stored is not a temporary variable so a bcall to _CleanAll doesn't clear it.  I will have to find the name of that string.  The buffer for the input is named "-" and I've seen a "#" and "$" so I'm guessing it's something similar to that.

There isn't a way to fix the memory leaks since this is an OS call.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 19, 2010, 11:54:42 pm
Are the mem leaks TI fault? It might be best to use a different input routine then if it can cause issues during game run time x.x (although I guess that might produce larger executables, rigth?). Good luck with the current input routine for now, though.
Title: Re: Bug Reports
Post by: Deep Toaster on September 20, 2010, 10:56:33 am
Quote from: Michael_Lee
Yes - garbage collecting seems to work wonders.  I find that whenever I get a mysterious error that never happened before, garbage collecting usually clears things up.

But even if it does work, you should probably report your "mysterious error." Might be a bug in Axe.
Title: Re: Bug Reports
Post by: kindermoumoute on September 20, 2010, 01:00:31 pm
And how to use axe input command? (i search, and always much crash)
Title: Re: Bug Reports
Post by: Michael_Lee on September 20, 2010, 01:57:54 pm
Quote from: Michael_Lee
Yes - garbage collecting seems to work wonders.  I find that whenever I get a mysterious error that never happened before, garbage collecting usually clears things up.

But even if it does work, you should probably report your "mysterious error." Might be a bug in Axe.

I doubt it.  The 'mysterious errors' usually only occur after I try running a normal, tested program after doing something incredibly stupid with my calculator.  (As in, I mess up with pointers and accidentally write a bunch of data to random places).  It's probably not Axe's fault.
Title: Re: Bug Reports
Post by: calcdude84se on September 20, 2010, 09:13:18 pm
Well apparently the buffer where the input string is stored is not a temporary variable so a bcall to _CleanAll doesn't clear it.  I will have to find the name of that string.  The buffer for the input is named "-" and I've seen a "#" and "$" so I'm guessing it's something similar to that.

There isn't a way to fix the memory leaks since this is an OS call.
As you are probably aware, there is a leak-free (or less so) version of _GetKey, undocumented and called _GetKeyRetOff ;D
I wonder if something similar exists for the input bcall...
Good luck making it work! :)
Title: Re: Bug Reports
Post by: Deep Toaster on September 21, 2010, 07:44:17 pm
Quote from: Michael_Lee
Yes - garbage collecting seems to work wonders.  I find that whenever I get a mysterious error that never happened before, garbage collecting usually clears things up.

But even if it does work, you should probably report your "mysterious error." Might be a bug in Axe.

I doubt it.  The 'mysterious errors' usually only occur after I try running a normal, tested program after doing something incredibly stupid with my calculator.  (As in, I mess up with pointers and accidentally write a bunch of data to random places).  It's probably not Axe's fault.

Ah. Yeah, I accidentally do that pretty often, giving me random tokens in the middle of my program :D
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 22, 2010, 12:07:39 pm
Well apparently the buffer where the input string is stored is not a temporary variable so a bcall to _CleanAll doesn't clear it.  I will have to find the name of that string.  The buffer for the input is named "-" and I've seen a "#" and "$" so I'm guessing it's something similar to that.

There isn't a way to fix the memory leaks since this is an OS call.
As you are probably aware, there is a leak-free (or less so) version of _GetKey, undocumented and called _GetKeyRetOff ;D
I wonder if something similar exists for the input bcall...
Good luck making it work! :)
If it's undocumented, does it means it won't work on the Nspire, though? I think Quigibo is aiming for full Nspire compatibility with the exception of the Full command.

Quote from: Michael_Lee
Yes - garbage collecting seems to work wonders.  I find that whenever I get a mysterious error that never happened before, garbage collecting usually clears things up.

But even if it does work, you should probably report your "mysterious error." Might be a bug in Axe.

I doubt it.  The 'mysterious errors' usually only occur after I try running a normal, tested program after doing something incredibly stupid with my calculator.  (As in, I mess up with pointers and accidentally write a bunch of data to random places).  It's probably not Axe's fault.

Ah. Yeah, I accidentally do that pretty often, giving me random tokens in the middle of my program :D
Yeah this is why it's better to reset every now and then x.x
Title: Re: Bug Reports
Post by: kindermoumoute on September 22, 2010, 12:33:51 pm
Please, how to use input command?
(I've so many crash, help me)
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 22, 2010, 12:42:05 pm
This is not the right topic to ask questions, you may want to ask in a separate one, since this one is for Axe Parser application bugs. You should also add some source code with your question..
Title: Re: Bug Reports
Post by: calc84maniac on September 22, 2010, 01:06:44 pm
Well apparently the buffer where the input string is stored is not a temporary variable so a bcall to _CleanAll doesn't clear it.  I will have to find the name of that string.  The buffer for the input is named "-" and I've seen a "#" and "$" so I'm guessing it's something similar to that.

There isn't a way to fix the memory leaks since this is an OS call.
As you are probably aware, there is a leak-free (or less so) version of _GetKey, undocumented and called _GetKeyRetOff ;D
I wonder if something similar exists for the input bcall...
Good luck making it work! :)
If it's undocumented, does it means it won't work on the Nspire, though? I think Quigibo is aiming for full Nspire compatibility with the exception of the Full command.
Nah, this is an undocumented OS call, which is different from an undocumented Z80 instruction. It should work just fine.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 25, 2010, 02:18:54 pm
Ah ok, I was a bit worried.

Also,

1000->X
Pause X

crashes Kindermoumoute's calc. Could this be a bug on certain calc models or could it be his calc that is defect?
Title: Re: Bug Reports
Post by: kindermoumoute on September 26, 2010, 05:52:36 am
Ah ok, I was a bit worried.

Also,

1000->X
Pause X

crashes Kindermoumoute's calc. Could this be a bug on certain calc models or could it be his calc that is defect?

Just crash when X=0 :/
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 26, 2010, 05:55:24 am
Oh ok, well in that case it's because 0= a pause of 65535, 1000=999, etc. Basically, to do a Pause that lasts nothing, you would need to do Pause 1. 65535 causes your calc to freeze for almost one minute, I think.
Title: Re: Bug Reports
Post by: ztrumpet on September 26, 2010, 08:44:03 am
Oh ok, well in that case it's because 0= a pause of 65535, 1000=999, etc. Basically, to do a Pause that lasts nothing, you would need to do Pause 1. 65535 causes your calc to freeze for almost one minute, I think.
This is correct. :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 26, 2010, 01:10:52 pm
Yeah the first time I was messing around with Pause, I thought I froze my calc and removed a battery ;D
Title: Re: Bug Reports
Post by: Deep Toaster on September 26, 2010, 02:02:33 pm
:D Me too, but I decided to wait. It turned out to be a good idea.
Title: Re: Bug Reports
Post by: calcdude84se on September 26, 2010, 02:43:31 pm
DJ, to be technically correct, 0 is a pause of 65536, 1000 is a pause of 1000, and so on ;)
Title: Re: Bug Reports
Post by: ztrumpet on September 26, 2010, 02:53:37 pm
DJ, to be technically correct, 0 is a pause of 65536, 1000 is a pause of 1000, and so on ;)
Whoops yeah, that's technically right as it decrements first and then checks, still allowing all numbers to be the same except 0.  :) 
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 26, 2010, 03:38:43 pm
Ah yeah, but since 65536 is beyond the 2 byte limits, I assume a Pause is the number after the command minus 1, right? Otherwise 65536 would loop back to 0. So Pause 1 produces a pause of 0, Pause 0 65535, Pause 65535 65534, etc
Title: Re: Bug Reports
Post by: calcdude84se on September 26, 2010, 04:01:39 pm
Hm... let me try elaborating on what ztrumpet said.
Code: (BASIC) [Select]
"This code acts like Axe 'Pause ', taking X for the amount. However, 15, not 65535, is the upper bound.
Lbl S
X-1+16not(X->X
If not(X
Goto S
So, if X starts as, say, 2, the first line after "Lbl S" will set X to 1. Since X is not 0, it will go back to that line, and decrement it to 0. Since it is now 0, it does not "Goto S", finishing the routine. Note that it ran the loop 2 times. (decrement to 1, decrement to 0)
However, if X starts as 0, the line "X-1+16not(X->X" will set X to 15. 15 is not 0, so it will "Goto S" and proceed to loop 15 more times for a total of 16. Put a counter C, initialized to 0, in the loop and see for yourself, like this:
Code: [Select]
0->C
Lbl S
X-1+16not(X->X
C+1->C
If not(X
Goto S
Disp C
Title: Re: Bug Reports
Post by: Deep Toaster on September 26, 2010, 04:07:48 pm
Oh, so it basically takes one less than the number after the Pause , but since it runs once before checking the loop, it's functionally adding the one back? So 0 would be 0-1+1=65535+1=65536 pauses.
Title: Re: Bug Reports
Post by: calcdude84se on September 26, 2010, 04:12:41 pm
If you want to look at it that way, then sure :). The main point is that it checks at the end of the loop, after it's already been decremented, and not at the beginning.
Title: Re: Bug Reports
Post by: DJ Omnimaga on September 26, 2010, 04:14:35 pm
Ah I see how it works now. Thanks for explaining :)
Title: Re: Bug Reports
Post by: ztrumpet on September 26, 2010, 04:15:16 pm
Um, here's a way to look at it in Ti-Basic:

Repeat not(X
X-1->X
If Ans=-1
65535->X
End
Title: Re: Bug Reports
Post by: calcdude84se on September 26, 2010, 04:24:48 pm
I thought it might be clearer with labels ;)
Probably better to use a separate If statement for clarification though, like you did.
Is the "65536->Ans" line a typo, though? It seems like it should be "65535->X"
Title: Re: Bug Reports
Post by: Deep Toaster on September 26, 2010, 04:26:29 pm
Why? -1+1 is technically 65536, so it should be 65536->X.
Title: Re: Bug Reports
Post by: ztrumpet on September 26, 2010, 04:26:41 pm
Is the "65536->Ans" line a typo, though? It seems like it should be "65535->X"
* ZTrumpet feeds himself to the lobster. :(
Title: Re: Bug Reports
Post by: calcdude84se on September 26, 2010, 04:29:29 pm
Why? -1+1 is technically 65536, so it should be 65536->X.
Well, if 0 is supposed to become 65535, then the lines "X-1->X:If X=-1:65536->X" set it to 65536, not the wanted 65535. Or am I misunderstanding you?
Title: Re: Bug Reports
Post by: Deep Toaster on September 26, 2010, 04:30:21 pm
Oh, wait, never mind :P

/me feeds himself to the lobster as well

EDIT: Netham's gonna be pretty full today...
Title: Re: Bug Reports
Post by: Ikkerens on October 02, 2010, 06:48:49 am
Just found a little keydetection bug.
(At least, on apps)
When you press a key, and you close the app, it remembers the key.
For example in splut, if you open the settings screen (by pressing MODE), it opens the mode menu (the TIOS one) upon closing Splut.
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 02, 2010, 10:10:21 am
Oh right I remember that. When exiting games with clear, the homescreen content is cleared almost in an instant.
Title: Re: Bug Reports
Post by: Runer112 on October 02, 2010, 12:30:45 pm
Oh right I remember that. When exiting games with clear, the homescreen content is cleared almost in an instant.

Couldn't you just put the following code at the end of the program, right before it exits? Or is this something different involving apps in particular.
Code: [Select]
While getKey(15)
End
Title: Re: Bug Reports
Post by: calc84maniac on October 02, 2010, 12:38:23 pm
I think the solution is to put a simple getKey before the program exits. That will read and clear out the recorded keypress.
Title: Re: Bug Reports
Post by: Deep Toaster on October 02, 2010, 08:10:48 pm
I think the solution is to put a simple getKey before the program exits. That will read and clear out the recorded keypress.

That works, but if you've been using getKey(#) all throughout your program, it would add another 50 bytes or so. Repeat getKey(0):End would work in that case.
Title: Re: Bug Reports
Post by: calc84maniac on October 02, 2010, 08:19:52 pm
I think the solution is to put a simple getKey before the program exits. That will read and clear out the recorded keypress.

That works, but if you've been using getKey(#) all throughout your program, it would add another 50 bytes or so. Repeat getKey(0):End would work in that case.
That doesn't work, because it doesn't clear out the key recorded by the OS. That said, each use of getKey takes up only 6 bytes anyway.
Title: Re: Bug Reports
Post by: Deep Toaster on October 02, 2010, 08:23:02 pm
Oh, wait, I meant While getKey(0). But yeah, I guess, but doesn't getKey require a subroutine? If the program never uses getKey, it might be better not to add it in at the end and add an extra 50-byte sub.
Title: Re: Bug Reports
Post by: calc84maniac on October 02, 2010, 08:49:46 pm
It's not a 50-byte sub, it's provided by the OS. So it's only 6 bytes total added to the program.
Title: Re: Bug Reports
Post by: Deep Toaster on October 02, 2010, 08:52:05 pm
Oh, I must have been thinking of a different routine.
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 03, 2010, 04:53:34 am
Oh right I remember that. When exiting games with clear, the homescreen content is cleared almost in an instant.

Couldn't you just put the following code at the end of the program, right before it exits? Or is this something different involving apps in particular.
Code: [Select]
While getKey(15)
End
That might work, actually.

For apps, the home screen is cleared when exiting, it seems, though...
Title: Re: Bug Reports
Post by: Runer112 on October 04, 2010, 04:02:18 pm
In the Commands.htm file, fPart() and iPart() are reversed. iPart() is the real token for the nib{} command and fPart() is the real token for the float{} command.


EDIT: Here's something completely unrelated, but I don't want to double post:

Dereferencing doesn't seem to be acting right to me... aren't the built-in variables at constant addresses, and loading constants takes 3 bytes? So why does loading a variable's address with the ° modifier (e.g. ) take 6 bytes? And why does it not combine properly with operations? (e.g. A°+1 takes 9 bytes)
Title: Re: Bug Reports
Post by: Quigibo on October 04, 2010, 04:55:35 pm
The syntax is °A not A°, is that the reason?
Title: Re: Bug Reports
Post by: Runer112 on October 04, 2010, 04:57:09 pm
Yeah, that would probably do it :-[ But why would even compile successfully for that matter?
Title: Re: Bug Reports
Post by: Deep Toaster on October 04, 2010, 08:20:01 pm
Hmm, agreed for a feature request: more syntax checking.
Title: Re: Bug Reports
Post by: Builderboy on October 04, 2010, 08:36:16 pm
Maybe more in depth syntax checking with a plethora of more detailed descriptions and errors?
Title: Re: Bug Reports
Post by: calcdude84se on October 04, 2010, 10:25:51 pm
I'm not sure if this is intentional, but I can't do oY1; I get an "improper use of file" error...
Title: Re: Bug Reports
Post by: Deep Toaster on October 04, 2010, 11:40:53 pm
Oh, yeah, and I have a question about that: What are files?
Title: Re: Bug Reports
Post by: calcdude84se on October 05, 2010, 07:56:26 am
They are a page-address pair used to access archived files.
Basic syntax:
Code: [Select]
GetCalc("appvARCHIVED",Y1
Copy(Y1,L6,768
DispGraph
You can use Copy( and { with them.
Any other use results in a file misuse error. (And they should except for use with the degree symbol.)
Title: Re: Bug Reports
Post by: Deep Toaster on October 05, 2010, 06:34:27 pm
Ohh, I see. So they're used exclusively to access archived files?
Title: Re: Bug Reports
Post by: calcdude84se on October 05, 2010, 06:46:11 pm
Yes, well, that's the intended use; with the ability to modify them directly, you can use the to read Flash at will. ;D
Example code: (assuming I can use get the address of Y1)
Code: [Select]
0->H
For(P,1,4
P->{°Y1
For(X,E4000,E7FFF
X->{°Y1+1
{X}+H->H
End
End
Yes, it's horribly inefficient (would be better done by reading a whole 16KB instead of one byte at a time), but it works. (It finds a 16-bit checksum of the first sector of flash.)
Of course, it would be better if there were built-in ways to access flash directly and not by a bcall, but something is better than nothing ;D
Edit: As a side note, you can use this code now, but you have to insert the address of Y1 rather than just use °Y1.
Title: Re: Bug Reports
Post by: Deep Toaster on October 05, 2010, 06:56:58 pm
Yes, well, that's the intended use; with the ability to modify them directly, you can use the to read Flash at will. ;D
Example code: (assuming I can use get the address of Y1)
Code: [Select]
0->H
For(P,1,4
P->{°Y1
For(X,E4000,E7FFF
X->{°Y1+1
{X}+H->H
End
End
Yes, it's horribly inefficient (would be better done by reading a whole 16KB instead of one byte at a time), but it works. (It finds a 16-bit checksum of the first sector of flash.)
Of course, it would be better if there were built-in ways to access flash directly and not by a bcall, but something is better than nothing ;D
Edit: As a side note, you can use this code now, but you have to insert the address of Y1 rather than just use °Y1.

Hmm, where are Y1-Y6 stored in RAM?
Title: Re: Bug Reports
Post by: calcdude84se on October 05, 2010, 06:59:35 pm
It's Y1-Y0 :)
I do not recall, actually. A quick look at the disassembly in calcsys should answer that.
* calcdude will get around to posting the answer later if Deep Thought doesn't figure it out himself.
Title: Re: Bug Reports
Post by: Deep Toaster on October 05, 2010, 07:00:56 pm
I wonder if dereferencing works on them...

/me starts testing...
Title: Re: Bug Reports
Post by: calcdude84se on October 05, 2010, 08:53:22 pm
I'm not sure if this is intentional, but I can't do oY1; I get an "improper use of file" error...
You can't, at least not until that bug is fixed :P
Title: Re: Bug Reports
Post by: Deep Toaster on October 05, 2010, 09:14:40 pm
Oh, forgot about that x.x
Title: Re: Bug Reports
Post by: Quigibo on October 05, 2010, 09:20:09 pm
Its not a bug, I just ran out of time and forgot to add it.  I *should* have it next version.
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 06, 2010, 01:10:17 am
Maybe more in depth syntax checking with a plethora of more detailed descriptions and errors?
As long as it doesn't slow down compiling way too much and woN't make the app extremly large I am fine.
Title: Re: Bug Reports
Post by: Deep Toaster on October 09, 2010, 06:28:17 pm
I noticed that Text( doesn't let me put text at the position that's one pixel away from the right border, even though I can do that in BASIC. Not sure if this is a limitation with the OS's b_call or if Axe accidentally checks one pixel too early...
Title: Re: Bug Reports
Post by: Runer112 on October 09, 2010, 06:29:27 pm
I noticed that Text( doesn't let me put text at the position that's one pixel away from the right border, even though I can do that in BASIC. Not sure if this is a limitation with the OS's b_call or if Axe accidentally checks one pixel too early...

Pretty sure you can't do that in BASIC.

EDIT: *Tests on calc* Yup, can't do it in BASIC either.
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 09, 2010, 06:37:06 pm
Yeah, it's a limitation with the TI-OS text routine. The only way to solve this is to write your own font routine using sprites :(
Title: Re: Bug Reports
Post by: Deep Toaster on October 09, 2010, 06:39:05 pm
I noticed that Text( doesn't let me put text at the position that's one pixel away from the right border, even though I can do that in BASIC. Not sure if this is a limitation with the OS's b_call or if Axe accidentally checks one pixel too early...

Pretty sure you can't do that in BASIC.

EDIT: *Tests on calc* Yup, can't do it in BASIC either.

Whoops, must have seen it wrong :P

Yeah, it's a limitation with the TI-OS text routine. The only way to solve this is to write your own font routine using sprites :(

Guess that's what I'm gonna have to do :(
Title: Re: Bug Reports
Post by: LordConiupiter on October 12, 2010, 11:41:28 am
or perhaps you just can do a 'Horizontal -', output your text, and then do a 'Horizontal +'...
Title: Re: Bug Reports
Post by: Builderboy on October 12, 2010, 11:48:34 am
That would erase the rightmost collumn though :(
Title: Re: Bug Reports
Post by: LordConiupiter on October 12, 2010, 11:53:07 am
yes, that's right... but you can save them to somewhere else on your calc, and then place them back when ure finished outputting your text. that would be less work than writing your own routine.

wait a minute! I have written a text output routine! I'm gonna post it in the routine topic when I've found it!
Title: Re: Bug Reports
Post by: Ikkerens on October 12, 2010, 12:16:19 pm
Just found 1 bug. It seems impossible to Copy( anything with the archive as destination (Y1 for example).
It gives the error file misuse.
Title: Re: Bug Reports
Post by: calc84maniac on October 12, 2010, 01:08:13 pm
Just found 1 bug. It seems impossible to Copy( anything with the archive as destination (Y1 for example).
It gives the error file misuse.
How is that a bug?
Title: Re: Bug Reports
Post by: LordConiupiter on October 12, 2010, 01:39:41 pm
yes, you can't write to the archive... you should unarchive anything you want to edit, and then archive it again, or copy it to RAM, edit it, and overwrite the existing filename, which will be handled by the OS.
Title: Re: Bug Reports
Post by: Ikkerens on October 12, 2010, 01:44:48 pm
yes, you can't write to the archive... you should unarchive anything you want to edit, and then archive it again, or copy it to RAM, edit it, and overwrite the existing filename, which will be handled by the OS.

Ah, ok, I see.
Thanks
Title: Re: Bug Reports
Post by: ACagliano on October 12, 2010, 02:22:28 pm
The token swap on u, v, and w that becomes appv, grp, and var is happening within text strings as well, causing garbled text to appear in displays.

Version 0.4.4
Title: Re: Bug Reports
Post by: Runer112 on October 12, 2010, 08:28:40 pm
The token swap on u, v, and w that becomes appv, grp, and var is happening within text strings as well, causing garbled text to appear in displays.

Version 0.4.4

You shouldn't be using the u, v, and w tokens in strings, that's what the lowercase alpha option is for :P . The u, v, and w tokens are different than the lowercase letters u, v, and w, and they aren't designed to be used in strings because they don't have ASCII character equivalences.
Title: Re: Bug Reports
Post by: ACagliano on October 13, 2010, 07:49:35 am
No. I realized what happened, actually. I used TI-Data Editor, which i think it doesnt have the u, v, and w characters separate from the tokens. So when I sent the file to calc, it switched them all.
Title: Re: Bug Reports
Post by: Deep Toaster on October 13, 2010, 11:15:48 am
Quote from: LordConiupiter
yes, that's right... but you can save them to somewhere else on your calc, and then place them back when ure finished outputting your text. that would be less work than writing your own routine.

wait a minute! I have written a text output routine! I'm gonna post it in the routine topic when I've found it!

Since I only needed to display three types of characters at the very right edge, I just converted them to sprites and used that :)

Thanks though, and the custom sprite routine might help someone else.

And a really weird bug report:

I've used lots of nested If -Else-End statements before, but for some reason, one particular combination gave me an error. Apparently, it didn't count the number of Else/Ends right, because I could either delete the nested Else or the nested End and it would compile with no errors (even though if I deleted the End, it would have a mismatched number of Ends).

I'll post the code when I find it.
Title: Re: Bug Reports
Post by: guy6020665 on October 19, 2010, 08:54:36 pm
Ummm. not sure if this has been mentioned yet, but are Axe programs supposed to disable MirageOS [ON] functions after a while?
Title: Re: Bug Reports
Post by: calcdude84se on October 20, 2010, 05:32:17 pm
If you use your own interrupt or turn them off, then the MirageOS interrupt will not work. If they're getting turned off and you're doing neither of these, it's because some instructions turn off interrupts. They can be re-enabled with FnOn after those instructions.
* calcdude asks Quigibo to document how instructions affect interrupts. (More specifically which ones turn them on/off)
Title: Re: Bug Reports
Post by: Deep Toaster on October 20, 2010, 09:41:58 pm
Ummm. not sure if this has been mentioned yet, but are Axe programs supposed to disable MirageOS [ON] functions after a while?

I don't think so, unless there's a specific FnOff in the prgm :P

Maybe it's a bug where a command disables interrupts and forgot to reenable them? Maybe you could post the code that did this.
Title: Re: Bug Reports
Post by: Quigibo on October 20, 2010, 10:34:48 pm
The dispgraph commands have an unfixable hardware bug that disables interrupts after a while when in im2.  You have to explicitly use an FnOn after dispgraph if you want custom interrupts to remain on.
Title: Re: Bug Reports
Post by: Deep Toaster on October 20, 2010, 10:36:43 pm
Oh. I'd assume it would disable MOS interrupts, then, right?

I tried looking through the exec for Simul for a DI (because I can't get very far without cheating :P), but I couldn't find one. Now I know why.

Did it do that before, though? It seemed to work in 0.2.6.
Title: Re: Bug Reports
Post by: Quigibo on October 20, 2010, 10:46:00 pm
Before it always reenabled them for you by default, but I took that off for the case where you might have a dispgraph inside of an interrupt routine.  If the interrupts were to turn on automatically when they weren't supposed to for even just one instruction (before you have a chance to add the fnOff at the end) then horrible things can happen.
Title: Re: Bug Reports
Post by: Deep Toaster on October 20, 2010, 11:23:09 pm
Oh, was that the old problem with DispGraph in interrupts? I get it now, though. Too bad Mirage interrupts won't be working by default anymore...
Title: Re: Bug Reports
Post by: guy6020665 on October 21, 2010, 07:13:06 pm
It seems to stop working after a while with just a simple display loop (with a counter going up of course.)
Title: Re: Bug Reports
Post by: Deep Toaster on October 21, 2010, 07:36:14 pm
What stops working? Mirage's ON interrupts? Yeah, they'd get disabled by DispGraph, as Quigibo said.
Title: Re: Bug Reports
Post by: guy6020665 on October 21, 2010, 07:37:57 pm
But I dont use dispgraph, I use output(
Code: [Select]
0->A
Repeat getkey(15)
output(0,0,A>Dec
A+1->A
End

And that sometimes disables after a while
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 21, 2010, 11:18:46 pm
Does Output stops working or do you just end up stuck in the loop?
Title: Re: Bug Reports
Post by: Deep Toaster on October 22, 2010, 02:25:20 pm
You mean Mirage's interrupts don't work anymore? If so,

* calcdude asks Quigibo to document how instructions affect interrupts. (More specifically which ones turn them on/off)

^ seconded.
Title: Re: Bug Reports
Post by: guy6020665 on October 22, 2010, 03:01:26 pm
I end up stuck in the loop, [on] refuses to do anything.
Title: Re: Bug Reports
Post by: Happybobjr on October 22, 2010, 03:04:52 pm
On doesn't do anything in assembly.. ^  pull a battery.

also   Input screws up fix 5.
Title: Re: Bug Reports
Post by: guy6020665 on October 22, 2010, 03:06:47 pm
I'm talking about MirageOS interrupts.
Title: Re: Bug Reports
Post by: Happybobjr on October 22, 2010, 03:07:12 pm
oh.... opps....
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 22, 2010, 07:00:01 pm
I end up stuck in the loop, [on] refuses to do anything.
I think direct input (getkey(number)) stops working after a while when interrupts are enabled. Also MirageOS ON function doesn't work in any Axe program I think.
Title: Re: Bug Reports
Post by: guy6020665 on October 22, 2010, 09:21:31 pm
Ok sorry correction, i can exit when i press [clear]. but sometimes when playing the axe pack i can freeze it with [on]
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 22, 2010, 10:01:20 pm
Ah ok. I'm not sure, then. I never messed with interrupts yet.
Title: Re: Bug Reports
Post by: Deep Toaster on October 23, 2010, 11:36:33 am
Just put a FnOn after every command that turns interrupts off and it should work. So Output( turns it off too?
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 23, 2010, 01:05:01 pm
Seems like so, but he mentions he gets stuck in the loop, which indicates that it's direct input that does.
Title: Re: Bug Reports
Post by: AngelFish on October 23, 2010, 07:10:24 pm
I've noticed that with Axe 0.4.5, sometimes compiling an archived program will throw Err:Bad Symbol. Unarchiving the program will fix the problem.
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 23, 2010, 07:14:16 pm
I actually had that happen sometimes too.
Title: Re: Bug Reports
Post by: calcdude84se on October 24, 2010, 11:13:26 am
I've noticed that with Axe 0.4.5, sometimes compiling an archived program will throw Err:Bad Symbol. Unarchiving the program will fix the problem.
This seems like a problem with reading from the archive. I thought this was fixed early on, but I guess Axe is still being thrown off at times...
Maybe it's something silly like improperly reading a two-byte token across a page/sector boundary?
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 24, 2010, 10:15:53 pm
Maybe it could be that. 2-byte tokens seems to be hassle sometimes. X.x
Title: Re: Bug Reports
Post by: Happybobjr on October 27, 2010, 05:49:17 pm
Axe is only back ups some of my programs.

The only ones it seems to be backing up for me are my sniper games.....


I ave deleted doors.  All of my app variables.  garbage collected then ram clear then garbage collected then ram clear then garbage collected then ram clear and still not working properly.   Any suggestions other than reinstalling an os?
Title: Re: Bug Reports
Post by: FinaleTI on October 27, 2010, 05:50:52 pm
Are the programs you're trying to back-up in the RAM? Because they won't be backed up if they are in the archive.
Title: Re: Bug Reports
Post by: squidgetx on October 27, 2010, 05:50:58 pm
Do you mean that when you tell it to back up a program, and it goes through that whole "backing up" screen, it still doesn't work?

Also, what FinaleTI said
Title: Re: Bug Reports
Post by: Happybobjr on October 27, 2010, 05:55:14 pm
humm... thats weird.. I think that is what it is....

It would back up either way for me on 4.3.....
Was that a freak cool accident kind of thing. Or did it do it on 4.3?
Title: Re: Bug Reports
Post by: Deep Toaster on October 27, 2010, 06:06:26 pm
Maybe you're out of archive? Just a thought.
Title: Re: Bug Reports
Post by: Happybobjr on October 27, 2010, 07:59:34 pm
calc clears Happybobjr's ram and runs a garbage collect trying to fix his human.
Title: Re: Bug Reports
Post by: ztrumpet on October 27, 2010, 08:01:29 pm
ScoutDavid has a problem running Ping on his Nspire.  Details here: http://ourl.ca/6586/133435

I think it's an Axe/Nspire Compatibility glitch somewhere. :(
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 28, 2010, 01:13:17 am
Is it due to the Input function? I think Input behaves differently from a calc to another.
Title: Re: Bug Reports
Post by: ztrumpet on October 28, 2010, 06:18:34 pm
No, Input's never used in the program. :(
Quigibo?
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 28, 2010, 09:14:34 pm
Strange. Quigibo must have used an undocumented instruction by mistake :/
Title: Re: Bug Reports
Post by: Runer112 on October 28, 2010, 10:37:42 pm
Perhaps the problem isn't on Quigibo/Axe's end, but is just specific to him? As far as I know, nobody else has noticed any such compatibility problems with Axe on the Nspire, and a quick scan of Commands.inc revealed no use of undocumented instructions.
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 29, 2010, 03:27:40 am
Maybe another error in his code or in Axe (even if just a small error that is hard to trigger) causes those undocumented instructions or something the Nspire doesn't support to be ran or something. In any case, we would need source code to know if it's really on Quigibo's end.
Title: Re: Bug Reports
Post by: Quigibo on October 29, 2010, 04:32:11 am
My guess is that it was probably another program that corrupted his compiled program or some other corrupted ram before running the program that caused one of the OS calls to freeze.  There definitely should not be undocumented instructions in any of the compiled programs.
Title: Re: Bug Reports
Post by: DJ Omnimaga on October 29, 2010, 08:47:39 am
Isn't the Nspire OS (or 84+ emulator) copied into RAM when the calc is booted? Maybe a bad program simply hit a part of the OS and caused a TI-Nspire-only crash?
Title: Re: Bug Reports
Post by: ztrumpet on October 29, 2010, 03:48:12 pm
we would need source code to know if it's really on Quigibo's end.
The source to Ping is attached to the post that is linked to . :)
Title: Re: Bug Reports
Post by: guy6020665 on November 01, 2010, 02:39:36 pm
After compiling this code for MirageOS, I try to run then it turns my calculator off, just off, doesn't clear RAM, so i try to run again, but then it does. I've searched the code but i dont see anything wrong with it.
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 01, 2010, 05:25:20 pm
For those who can't open the file for any reason or can't access SC2 here's Guy602665 code below:

Quote
:.TUN
:[FFFFFFFFFFFFFFFF→Pic1
:50→X
:55→Y
:40→A→B→D
:0→S
:ClrDraw
:Repeat getKey(15)
:S+1→S
:rand^5-2→C
:D+C→D
:Line(0,1,D,1
:Line(D+A,1,96,1
:Line(0,2,D,2
:Line(D+A,2,96,2
:If (D+A)>95
:95-A→D
:End
:If D≤2
:3→D
:End
:Pt-Change(X,Y,Pic1
:DispGraph
:Pt-Change(X,Y,Pic1
:Vertical +
:Vertical +
:If getKey(2)
:X-2→X
:End
:If getKey(3)
:X+2→X
:End
:If S>B
:B+40→B
:A-1→A
:End
:End
Generated by SourceCoder (http://sc.cemetech.net)
© 2005-2010 Cemetech (http://www.cemetech.net)
Title: Re: Bug Reports
Post by: squidgetx on November 01, 2010, 05:59:36 pm
idk how much this would do, but I think that putting an end bracket on FFFFFFFFFF->Pic1 might help. Otherwise I can't see anything wrong with it either :x
Title: Re: Bug Reports
Post by: guy6020665 on November 02, 2010, 02:13:36 pm
For those who can't open the file for any reason or can't access SC2 here's Guy602665 code below:

I could have used sourcecoder couldn't I? oops XP
Title: Re: Bug Reports
Post by: Kiligolo on November 02, 2010, 02:34:50 pm
ERR:DUPLICATE is not in the error list and I do not know this can mean. :(
Title: Re: Bug Reports
Post by: guy6020665 on November 02, 2010, 02:39:42 pm
ERR:DUPLICATE is not in the error list and I do not know this can mean. :(
ERR:DUPLICATE means that you tried to rewrite a static variable, static variables such as Pic1,Str1,GDB1 can't be rewritten.

On another note, after adding more code my program works, i didn't delete anything either, so I really don't understand the problem with my program.
Title: Re: Bug Reports
Post by: Kiligolo on November 02, 2010, 03:04:55 pm
Ok. :)
So it is not possible to create a string with letters? :(
Title: Re: Bug Reports
Post by: aeTIos on November 02, 2010, 03:06:49 pm
Ok. :)
So it is not possible to create a string with letters? :(
how do you mean? you can set letters in a string, but you cant create StrHEY or so
Title: Re: Bug Reports
Post by: Kiligolo on November 02, 2010, 03:11:38 pm
I would like to do something like that:
Code: [Select]
"MON TEXTE"→Str1
Title: Re: Bug Reports
Post by: aeTIos on November 02, 2010, 03:16:36 pm
I would like to do something like that:
Code: [Select]
"MON TEXTE"→Str1
that is possible. to display that, you should use:
Code: [Select]
"MON TEXTE"-> Str1
[00]
Text(Xpos,Ypos,Str1)
That should work
Title: Re: Bug Reports
Post by: nemo on November 02, 2010, 03:40:39 pm
the [00] is unnecessary. storing string data to a static pointer appends the null character at the end automatically.
Title: Re: Bug Reports
Post by: aeTIos on November 02, 2010, 03:41:41 pm
whoop yes I forgot. if you want to store multiple text in 1 string, you should do
Title: Re: Bug Reports
Post by: Kiligolo on November 02, 2010, 03:44:42 pm
thanks :)
Title: Re: Bug Reports
Post by: Aichi on November 05, 2010, 02:23:47 pm
It seems like DCS7 doesnt support descriptions when I compile an axe code to an Ion prog.
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 05, 2010, 07:15:40 pm
Hmm weird. Are you sure Doors supports Ion descriptions, though? You may need to try a random Ion game on ticalc.org to see, and if it doesn't, this might need to be reported to KermMartian.
Title: Re: Bug Reports
Post by: Deep Toaster on November 05, 2010, 07:17:24 pm
It seems like DCS7 doesnt support descriptions when I compile an axe code to an Ion prog.

Doors definitely supports Ion descriptions... Do you have another shell you could try it in?
Title: Re: Bug Reports
Post by: squidgetx on November 05, 2010, 07:43:45 pm
Not sure if this has been mentioned already, but if you overwrite an external variable that's been in archive, it just gets deleted and not overwritten.
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 05, 2010, 07:52:26 pm
It seems like DCS7 doesnt support descriptions when I compile an axe code to an Ion prog.

Doors definitely supports Ion descriptions... Do you have another shell you could try it in?
Ah I see. So this is definitively an issue on Axe's side.
Title: Re: Bug Reports
Post by: Aichi on November 06, 2010, 02:59:42 am
Here are 2 screenshots comparing an axe ion program description and a mimas ion program description.
    Mimas                                     Axe
(http://img5.imagebanana.com/img/iqtw36u0/MimasDesc.gif) (http://img5.imagebanana.com/img/zi5rcz9z/AxeDesc.gif)

Another Bug report:
When I use 'Pause ' (without argument) Axe is compiling the code without giving an error. If I execute the prog, the calc crashes. So it would be nice if Pause without an argument was an error.
Title: Re: Bug Reports
Post by: calc84maniac on November 06, 2010, 10:28:27 am
Using Pause without an argument likely uses the last answer as the argument. It may have "crashed" because you had a very large number there (or 0).
Title: Re: Bug Reports
Post by: Deep Toaster on November 07, 2010, 12:26:13 pm
Another Bug report:
When I use 'Pause ' (without argument) Axe is compiling the code without giving an error. If I execute the prog, the calc crashes. So it would be nice if Pause without an argument was an error.

That's actually useful in some cases, like pausing for a calculated amount of time such as for a game with multiple speeds. It saves at least three bytes compared to pausing for an amount of time stored in a var. The docu should warn against this stuff, though, so people don't do it by accident.
Title: Re: Bug Reports
Post by: calc84maniac on November 08, 2010, 01:35:02 pm
So, I think I have come up with a foolproof method for checking whether interrupts are enabled, even if an interrupt occurs at an inopportune moment:
Code: [Select]
;Push a zero byte to the stack and pop it
xor a
push af
pop af
ld a,i
jp pe,interrupts_on
;See if an interrupt triggered. If so, the byte on the stack will not be 0 anymore
;unless this code is executing from $0000-$00FF area, which would only happen if you are writing an OS
dec sp
dec sp
pop af
or a
jr z,interrupts_off
;If interrupts were on, set A to $FF so the increase will set parity even
ld a,$FF
interrupts_off:
;Set parity odd
inc a
interrupts_on:

Edit:
My code had a logical error, it should be fixed now
Title: Re: Bug Reports
Post by: kindermoumoute on November 08, 2010, 02:19:50 pm
I found a bug (I think) :
When I compile this code in Axe 0.4.4, it work :
Code: [Select]
:!If EXP1
:.Code
:ElseIf EXP2
:.Code
:End

But in 0.4.5, I'm obliged to do that :
Code: [Select]
:If EXP1=0
:.Code
:ElseIf EXP2
:.Code
:End

This is due to ERR:BLOCK when I compile.
???
Title: Re: Bug Reports
Post by: guy6020665 on November 08, 2010, 02:58:14 pm
Not sure if this has been mentioned already, but if you overwrite an external variable that's been in archive, it just gets deleted and not overwritten.

When I've done that it just becomes hidden and archived.
Title: Re: Bug Reports
Post by: Runer112 on November 08, 2010, 03:29:43 pm
I found a bug (I think) :
When I compile this code in Axe 0.4.4, it work :
Code: [Select]
:!If EXP1
:.Code
:ElseIf EXP2
:.Code
:End

But in 0.4.5, I'm obliged to do that :
Code: [Select]
:If EXP1=0
:.Code
:ElseIf EXP2
:.Code
:End

This is due to ERR:BLOCK when I compile.
???

I have noticed this too, this problem isn't just you.
Title: Re: Bug Reports
Post by: ztrumpet on November 08, 2010, 03:39:02 pm
So, I think I have come up with a foolproof method for checking whether interrupts are enabled, even if an interrupt occurs at an inopportune moment:
Awesome!  Is this any slower than the routine currently being used?
Title: Re: Bug Reports
Post by: calc84maniac on November 08, 2010, 04:44:01 pm
Yes, it's slower, but it actually works. Well, in theory. I made a stupid mistake in that last code, so it won't work. This one might work (and is more optimized):
Code: [Select]
xor a
push af
pop af
ld a,i
jp pe,interrupt_check_end
dec sp
dec sp
pop af
add a,a
jr z,interrupt_check_end
xor a
interrupt_check_end:
Title: Re: Bug Reports
Post by: Runer112 on November 10, 2010, 05:24:48 pm
The signed division auto optimizations are gone ???

EDIT: Also, sprite routines targeted to arbitrary buffers reverse the x and y arguments.

EDIT 2: Oh, and in the commands list you accidentally call EXP1**EXP2 signed multiplication instead of fixed point multiplication.
Title: Re: Bug Reports
Post by: calc84maniac on November 14, 2010, 10:53:23 pm
Apparently Axe does not like a !If / ElseIf / ... / End block, or !If / Else!If / ... / End. Basically, a !If cannot start an ElseIf chain. It gives ERR:BLOCK.
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 14, 2010, 11:10:40 pm
I think I saw this reported elsewhere by another person, but I forgot which thread. Seems like a bad bug X.x
Title: Re: Bug Reports
Post by: calc84maniac on November 14, 2010, 11:14:12 pm
EDIT 2: Oh, and in the commands list you accidentally call EXP1**EXP2 signed multiplication instead of fixed point multiplication.
It actually is a signed fixed-point multiplication. The list doesn't say "fixed-point" in so many words, though it does describe the type of number it is.
Title: Re: Bug Reports
Post by: Runer112 on November 15, 2010, 12:39:15 am
EDIT 2: Oh, and in the commands list you accidentally call EXP1**EXP2 signed multiplication instead of fixed point multiplication.
It actually is a signed fixed-point multiplication. The list doesn't say "fixed-point" in so many words, though it does describe the type of number it is.

You're right, there's definitely some signed stuff going on here. But it's a good thing you pointed this out, because now that I look into it more, it appears that the routine itself is buggy. For instance, ᴇ0400**ᴇ2000 evaluates to ᴇ8000, although I believe it should be ᴇ0000 signed. It seems to be a problem with signed overflows not carrying properly. As another example, ᴇ0410**ᴇ2000 evaluates to ᴇ7E00, although I believe it should be ᴇ0200.

Can someone please verify that this is a problem? Or tell me how I'm misunderstanding it and why it's not a problem?
Title: Re: Bug Reports
Post by: calc84maniac on November 15, 2010, 12:44:11 am
EDIT 2: Oh, and in the commands list you accidentally call EXP1**EXP2 signed multiplication instead of fixed point multiplication.
It actually is a signed fixed-point multiplication. The list doesn't say "fixed-point" in so many words, though it does describe the type of number it is.

You're right, there's definitely some signed stuff going on here. But it's a good thing you pointed this out, because now that I look into it more, it appears that the routine itself is buggy. For instance, ᴇ0400**ᴇ2000 evaluates to ᴇ8000, although, it should be ᴇ0000 signed. It seems to be a problem with signed overflows not carrying properly. As another example, ᴇ0410**ᴇ2000 evaluates to ᴇ7E00, although it should be ᴇ0200.

Although it may work perfectly and I'm just misunderstanding how it's supposed to work.
Signed overflows don't wrap around to 0, they wrap around to -128. I do think that the ᴇ7E00 should be ᴇ8200, though. But at any rate, you should be making sure it doesn't overflow anyway.
Title: Re: Bug Reports
Post by: Runer112 on November 15, 2010, 12:51:02 am
I realize that signed overflows wrap like that natively, but for this purpose it isn't the desired outcome. Multiplying two positive numbers and getting a negative number seems less practical than getting a clipped positive number.
Title: Re: Bug Reports
Post by: Deep Toaster on November 16, 2010, 11:43:28 am
Quote from: calc84maniac
Apparently Axe does not like a !If / ElseIf / ... / End block, or !If / Else!If / ... / End. Basically, a !If cannot start an ElseIf chain. It gives ERR:BLOCK.

Oh, that's how it happened! I got that ERR:BLOCK too, but I couldn't find what caused it.
Title: Re: Bug Reports
Post by: Runer112 on November 19, 2010, 11:49:27 am
Here's a fun one:

For extra fun, try to compile/backup/restore the empty entry! (Unfortunately no epic crashes, just an error message)
Title: Re: Bug Reports
Post by: squidgetx on November 19, 2010, 01:59:05 pm
^ Nothing happens when I try doing that (you're saying, press APPS while selecting the last item in the list which is a backup file, right?)
Title: Re: Bug Reports
Post by: Runer112 on November 19, 2010, 04:19:48 pm
Yeah, when selecting the last item in the last (#RANDSRC in this case), press B, and then press down. Trying to compile, backup, or restore the blank entry will all result in an error message.
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 19, 2010, 05:49:25 pm
Strange. X.x

At least it doesn't seem as bad as the bug involving the ! and # programs in MirageOS 1.1 (horrible stuff happened if you archived those, requring both RAM and archive to be reset)
Title: Re: Bug Reports
Post by: squidgetx on November 19, 2010, 06:15:55 pm
Oh my bad, I read "have at most 6 programs" as "have at least 6 programs." I think I have about 100 items in my Axe compile menu x.x

edit: woo, 22^2'd post
Title: Re: Bug Reports
Post by: Deep Toaster on November 21, 2010, 12:21:49 pm
Another bug report: I've never compiled an app before, so I tried it once with a 3 KB program (just to see what it's like). It compiled normally, but when it started writing to an app, Axe suddenly froze. I waited 3 minutes, because I really had no idea how long it usually took to make an app, but I figured it was probably frozen and pulled a battery. Pretty scary considering Axe was writing to flash at the time, but thankfully all I got was a RAM clear.

Info: I'm using a TI-83 Plus OS 1.19 with Axe 0.4.4 to compile a 3 KB (exec) program into an app. The source was split into 9 programs (one main program and 8 subs). I had 80 KB of free archive space, but since my last garbagecollect was several weeks ago (and the one I did right after the RAM clear took quite a while), I think my archive space was just about filled at the time. Should I try again now that I've garbagecollected to see how it works now?
Title: Re: Bug Reports
Post by: squidgetx on November 21, 2010, 12:23:14 pm
That happened to me before. Garbage collecting didn't work, but after I deleted some app and the calc defragg'd, it worked. Is defragmenting different from garbagecollecting ???

Also, I was using 84+SE 2.53MP 0.4.5 with a 9k program split into several parts
Title: Re: Bug Reports
Post by: Deep Toaster on November 21, 2010, 12:27:06 pm
That happened to me before. Garbage collecting didn't work, but after I deleted some app and the calc defragg'd, it worked. Is defragmenting different from garbagecollecting ???

Weird, what's the difference?

EDIT: Okay, just tried it again after garbagecollecting, and it ... worked. Huh ???
Title: Re: Bug Reports
Post by: Quigibo on November 21, 2010, 02:39:09 pm
Defragmenting and garbage collecting are the same thing, but in different regions in the ROM.  Garbage collecting happens in the general archive where you keep programs and stuff, but defragmenting happens on the app space and swaps entire pages at a time.

Right now, I only force a defragmentation when overwriting an existing app.  But now that I've got a few of these reports, it might be better to always defragment, just in case.  I know it takes a while sometimes, but writing to flash is scary so I'd rather be safe than sorry.
Title: Re: Bug Reports
Post by: Deep Toaster on November 21, 2010, 06:45:45 pm
Defragmenting and garbage collecting are the same thing, but in different regions in the ROM.  Garbage collecting happens in the general archive where you keep programs and stuff, but defragmenting happens on the app space and swaps entire pages at a time.

Right now, I only force a defragmentation when overwriting an existing app.  But now that I've got a few of these reports, it might be better to always defragment, just in case.  I know it takes a while sometimes, but writing to flash is scary so I'd rather be safe than sorry.

Agreed, and if possible could you add more updates while it's making the app? Like Defragmenting... when it's defragmenting and a % counter while it's actually writing the app.
Title: Re: Bug Reports
Post by: Quigibo on November 21, 2010, 07:06:49 pm
I could make a counter for the app writing if you don't mind it taking about 20% longer, but I can't for the defragmenting because that's done by the OS.
Title: Re: Bug Reports
Post by: Happybobjr on November 21, 2010, 07:16:02 pm
quick question.

Could you make a program preferably an app that will just defrag the calc?
I have had errors where i was forced to delete an app to cause a defragmentation to fix the problem.

Title: Re: Bug Reports
Post by: DJ Omnimaga on November 21, 2010, 07:19:56 pm
How long does it takes to compile an APP for a program that contains about 10 KB of code?
Title: Re: Bug Reports
Post by: squidgetx on November 21, 2010, 07:50:20 pm
  here
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 21, 2010, 08:09:29 pm
Ah nice, not too long then. I thought it would be like 2 minutes.
Title: Re: Bug Reports
Post by: Quigibo on November 21, 2010, 09:21:42 pm
By the way, I fixed the bug with the signed division auto-optimization.  It actually was doing the optimizations correctly, but it was still adding the signed division routine to the code anyway, even if it didn't use it.
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 21, 2010, 10:07:59 pm
Cool. Btw any luck on fixing random crashes with the backup feature? Some people reported that.
Title: Re: Bug Reports
Post by: calcdude84se on November 23, 2010, 07:38:51 pm
Ah nice, not too long then. I thought it would be like 2 minutes.
Why did you think that? The only reason it would be that slow is if you were signing it somehow ;D
Quigibo, nice to hear. As always, I'll say "keep up the good work!" :)
Title: Re: Bug Reports
Post by: DJ Omnimaga on November 24, 2010, 02:33:17 am
I thought it would be that long because a 500 bytes source took about 4 seconds. :P
Title: Re: Bug Reports
Post by: squidgetx on November 30, 2010, 06:09:23 pm
I have a (fairly large) bug report:

Try this code compiled to no-shell:
Code: [Select]
([01234567])*2→A
For(E,0,7)
Text(E*10,0,nib{A+E}>Dec)
End

It will do what it's supposed to, which is display 01234567 in a row.

Now try compiling it to an app.
It'll display some numbers that are *not* 01234567 :(

Title: Re: Bug Reports
Post by: Munchor on November 30, 2010, 06:11:23 pm
I have a (fairly large) bug report:

Try this code compiled to no-shell:
Code: [Select]
([01234567])*2→A
For(E,0,7)
Text(E*10,0,nib{A+E}>Dec)
End

It will do what it's supposed to, which is display 01234567 in a row.

Now try compiling it to an app.
It'll display some numbers that are *not* 01234567 :(



How do you compile somthing to an App? Can it be done? WOW


EDIT: I just noticed, is it a shell?
Title: Re: Bug Reports
Post by: Runer112 on November 30, 2010, 06:14:22 pm
It's not a bug. There are 65536 bytes in RAM, which can all be accessed with a 16-bit pointer, but there are twice as many nibbles. Because of this, you cannot access every nibble in RAM with a 16-bit argument, so it is split into two commands. nib{} will return a nibble from ᴇ8000-ᴇFFFF, and nib{}ʳ will return a nibble from ᴇ0000-ᴇ7FFF. Applications reside in RAM from ᴇ4000-ᴇ7FFF, so you need to use the nib{}ʳ command when compiling to applications.
Title: Re: Bug Reports
Post by: squidgetx on November 30, 2010, 06:15:07 pm
It's not a bug. There are 65536 bytes in RAM, which can all be accessed with a 16-bit pointer, but there are twice as many nibbles. Because of this, you cannot access every nibble in RAM with a 16-bit argument, so it is split into two commands. nib{} will return a nibble from ᴇ8000-ᴇFFFF, and nib{}ʳ will return a nibble from ᴇ0000-ᴇ7FFF.

Now I feel stupid :P

Thanks Runer! :)
Title: Re: Bug Reports
Post by: Happybobjr on November 30, 2010, 07:07:38 pm
BUG:  Don't Quote Me!

I show best by example.


Text(5,10,"HELLO"
Text(5,30,"WORLD!"


When compiled it will give an ERROR: BAD SYMBOL  at the 2nd Text(

I fiddled around with it for a while, and to make it work, you have to change it to this V

Text(5,10,"HELLO
Text(5,30,"WORLD!

What is that about?

also i tried this, and it compiled.
Text(5,5,"ERROR: YOU HAVE TOO MANY NOTES"POO
( i know but i use the word poo when testing things....

the only thing that showed up was that square symbol.. ???
Title: Re: Bug Reports
Post by: Deep Toaster on November 30, 2010, 07:40:20 pm
In Axe, try to close your parentheses/quotes whenver possible. It doesn't add any mem to the program.

It might be messed up thinking the newline and the Text(5,30, after the O in the first line was part of the string, so the " before the W would be closing the string. Then it would be executing WORLD!, where ! is an invalid symbol.

Maybe Axe should stop quotes at a newline? Is this bug only in the newest version?
Title: Re: Bug Reports
Post by: Happybobjr on November 30, 2010, 08:10:12 pm
yes it is only in the new version.
So i am not allowed to close quotes.
Title: Re: Bug Reports
Post by: Runer112 on November 30, 2010, 10:34:43 pm
BUG:  Don't Quote Me!

I show best by example.


Text(5,10,"HELLO"
Text(5,30,"WORLD!"


When compiled it will give an ERROR: BAD SYMBOL  at the 2nd Text(

I fiddled around with it for a while, and to make it work, you have to change it to this V

Text(5,10,"HELLO
Text(5,30,"WORLD!

What is that about?

also i tried this, and it compiled.
Text(5,5,"ERROR: YOU HAVE TOO MANY NOTES"POO
( i know but i use the word poo when testing things....

the only thing that showed up was that square symbol.. ???

A much more reliable way to avoid errors regarding closing quotes/parentheses/brackets is to simply close them all. You will never get an error this way.



Regarding this:
Text(5,5,"ERROR: YOU HAVE TOO MANY NOTES"POO

Once you closed the string, the parser resumes normal evaluation. This causes it to evaluate P, O, and O as variables, each one replacing the previous value. This results in the final value taking on the value of O, thus the code displays whatever garbage string is pointed to by O.

In case that's somewhat difficult to understand written out, here's pseudocode to represent how the parser interprets that line, instruction by instruction:
Code: [Select]
Load 5
Store last value into pen X
Load 5
(An instruction that's not important for this simplified pseudocode)
Store last value into pen Y
Load pointer to "ERROR: YOU HAVE TOO MANY NOTES"
Load value of P
Load value of O
Load value of O
Store last value into string pointer
Display string
Title: Re: Bug Reports
Post by: calc84maniac on November 30, 2010, 10:43:37 pm
But he said that the compiler errored when he did close the quotes, and worked when he left them open.
Title: Re: Bug Reports
Post by: Runer112 on November 30, 2010, 10:47:31 pm
I know, that's just an oddity resulting from the fact that the code is already poorly structured because he left the parentheses open. There would be no problem if he closed both the quotes and the parentheses.
Title: Re: Bug Reports
Post by: tehalynn on December 01, 2010, 12:17:14 am
I think X and Y are reversed when you try to use Pt-On with an arbitrary buffer.
Code: [Select]
[FFFFFFFFFFFFFFFF]->Pic1
.Pic2 is the buffer
Zeros(768)->Pic2

.Draw the sprite to Pic2
Pt-On(50,10,Pic1)->Pic2

.Copy Pic2 to the buffer
ClrDraw
Copy(Pic2, L6,768)
DispGraph

What I think should happen is it draws the sprite 50 pixels right and 10 pixels down. What actually happens is it draws the sprite 10 pixels right and 50 pixels down. Is this a bug, or am not doing this the right way?

I'm using Axe 0.4.6.
Title: Re: Bug Reports
Post by: Runer112 on December 01, 2010, 08:54:04 am
I think X and Y are reversed when you try to use Pt-On with an arbitrary buffer.
Code: [Select]
[FFFFFFFFFFFFFFFF]->Pic1
.Pic2 is the buffer
Zeros(768)->Pic2

.Draw the sprite to Pic2
Pt-On(50,10,Pic1)->Pic2

.Copy Pic2 to the buffer
ClrDraw
Copy(Pic2, L6,768)
DispGraph

What I think should happen is it draws the sprite 50 pixels right and 10 pixels down. What actually happens is it draws the sprite 10 pixels right and 50 pixels down. Is this a bug, or am not doing this the right way?

I'm using Axe 0.4.6.

Yeah, this quirk has existed since drawing sprites to arbitrary buffers first came out. I believe it's been mentioned in here a few times before, but maybe there's a reason Quigibo is leaving it like this.
Title: Re: Bug Reports
Post by: Happybobjr on December 01, 2010, 11:27:53 am
I know, that's just an oddity resulting from the fact that the code is already poorly structured because he left the parentheses open. There would be no problem if he closed both the quotes and the parentheses.

The code always errors when i have my perenthisies closed.
Title: Re: Bug Reports
Post by: Runer112 on December 01, 2010, 12:37:31 pm
The error occurs when the quotes are closed but the parentheses are not closed. It's completely understandable that you would have an error in this situation because you didn't close the parentheses. The fact that the code compiles correctly with both the quotes and the parentheses left open is just some odd quirk that probably should not be relied on.
Title: Re: Bug Reports
Post by: DJ Omnimaga on December 01, 2010, 02:50:12 pm
As he just said in the post above, he also had his parenthesizes closed, not just the code, and still got an error.  Just to clarify any confusion.

If the code is fine but it errors even when closing quotes and parenthesizes and even after he did a RAM clear before trying again, then maybe it's an Axe bug.
Title: Re: Bug Reports
Post by: Runer112 on December 01, 2010, 03:03:20 pm
BUG:  Don't Quote Me!

I show best by example.


Text(5,10,"HELLO"
Text(5,30,"WORLD!"


When compiled it will give an ERROR: BAD SYMBOL  at the 2nd Text(

The parentheses are not closed.
Title: Re: Bug Reports
Post by: DJ Omnimaga on December 01, 2010, 03:05:33 pm
I meant in his other post:

I know, that's just an oddity resulting from the fact that the code is already poorly structured because he left the parentheses open. There would be no problem if he closed both the quotes and the parentheses.

The code always errors when i have my perenthisies closed.
He says that with the code you just quoted now, he still gets errors even if he actually closes the parhentesises.
Title: Re: Bug Reports
Post by: Runer112 on December 01, 2010, 03:12:08 pm
I saw it DJ, and I'm assuming he misspoke. Please observe the attached GIF, in which it compiles correctly if both the quotes and parentheses are closed.
Title: Re: Bug Reports
Post by: DJ Omnimaga on December 01, 2010, 03:15:32 pm
Ah, ok, then I don't know. If he really tried it, then he should do a RAM clear, in case his calc is messed up, and maybe even a mem clear, because sometimes RAM clears won't fix things. If that still doesn't fix it, then it's definitively something Quigibo needs to look into. It could be an hardware-specific bug or an issue with his calc, like how my 83+ is not compatible with Axe APP compiling.
Title: Re: Bug Reports
Post by: Happybobjr on December 01, 2010, 06:10:00 pm
As he just said in the post above, he also had his parenthesizes closed, not just the code, and still got an error.  Just to clarify any confusion.

If the code is fine but it errors even when closing quotes and parenthesizes and even after he did a RAM clear before trying again, then maybe it's an Axe bug.

oh, shoot i said parentheses one time XX
sorry for all the confusion.


Ok, thanks.
Title: Re: Bug Reports
Post by: Deep Toaster on December 01, 2010, 06:22:18 pm
But he said that the compiler errored when he did close the quotes, and worked when he left them open.

Whoops, sorry. I got confused.

I think X and Y are reversed when you try to use Pt-On with an arbitrary buffer.
Code: [Select]
[FFFFFFFFFFFFFFFF]->Pic1
.Pic2 is the buffer
Zeros(768)->Pic2

.Draw the sprite to Pic2
Pt-On(50,10,Pic1)->Pic2

.Copy Pic2 to the buffer
ClrDraw
Copy(Pic2, L6,768)
DispGraph

What I think should happen is it draws the sprite 50 pixels right and 10 pixels down. What actually happens is it draws the sprite 10 pixels right and 50 pixels down. Is this a bug, or am not doing this the right way?

I'm using Axe 0.4.6.

Yeah, noticed that too. Is there a reason Quigibo left it that way?
Title: Re: Bug Reports
Post by: Quigibo on December 01, 2010, 08:18:07 pm
I wasn't aware of that bug actually I will fix all of these.  The open quote thing, I can understand an accidental bug there since I just changed the way the parser interprets static inline data, but the X,Y reversal thing must have been there for a while, I never noticed it.  I'll probably upload to ticalc later anyway though since the next release won't be for a couple weeks.
Title: Re: Bug Reports
Post by: jnesselr on December 02, 2010, 07:14:23 am
I wasn't aware of that bug actually I will fix all of these.  The open quote thing, I can understand an accidental bug there since I just changed the way the parser interprets static inline data, but the X,Y reversal thing must have been there for a while, I never noticed it.  I'll probably upload to ticalc later anyway though since the next release won't be for a couple weeks.
I noticed the progress bar went up to 60%, though.  It was at 50% forever.  Glad to see you can still do bug fixes and such.
Title: Re: Bug Reports
Post by: scottywz on December 02, 2010, 07:11:13 pm
Hi, I'm writing a program that deals a lot with TI-OS variables, and I'm having a problem.

Code: [Select]
DelVar [04720000]
If GetCalc([01720000],9)->V
 1->{V-2}r
 93->float{V}
End

Assume that Ans in TI-OS contains a string before running this.  In Axe 0.4.5, this code would delete Ans and make a new Ans that is a real-number list with one element.  Ans in TI-OS would actually be a real list.  In Axe 0.4.6, however, Ans is still a string, and the output is weird, but not crashing (as far as I've seen).
Title: Re: Bug Reports
Post by: Runer112 on December 04, 2010, 07:01:50 pm
BUG:  Don't Quote Me!

I show best by example.


Text(5,10,"HELLO"
Text(5,30,"WORLD!"


When compiled it will give an ERROR: BAD SYMBOL  at the 2nd Text(

I fiddled around with it for a while, and to make it work, you have to change it to this V

Text(5,10,"HELLO
Text(5,30,"WORLD!

What is that about?

At first, I had no problem with this bug because it stems from not closing parentheses, which is understandable. However, I just discovered a more problematic instance of this bug. The "Text " command (Non-Axe token: "DrawF ") actually has a hidden opening parenthesis. In similar fashion of closing quotes but not closing parentheses, the following line of code will produce errors:
Code: [Select]
Text "HELLO WORLD!"In this case, adding a closing parenthesis will resolve any errors again, but it doesn't logically make sense to do so based on the command not containing an opening parenthesis. Could you please either look into this issue or assign a new name to the "Text " command that contains an opening parenthesis?

EDIT: By random chance, briefly after posting this I discovered that this problem also exists when using inline data in square brackets as the argument. Also, "DelVar " has the same affliction.
Title: Re: Bug Reports
Post by: Builderboy on December 04, 2010, 07:05:39 pm
Wait, your text command doesn't have an opening parenthesis?
Title: Re: Bug Reports
Post by: Runer112 on December 04, 2010, 07:08:28 pm
Wait, your text command doesn't have an opening parenthesis?

I adjusted my post to clarify this.
Title: Re: Bug Reports
Post by: Builderboy on December 04, 2010, 07:11:08 pm
Aaah i see, gotcha
Title: Re: Bug Reports
Post by: Deep Toaster on December 05, 2010, 12:41:51 am
At first, I had no problem with this bug because it stems from not closing parentheses, which is understandable. However, I just discovered a more problematic instance of this bug. The "Text " command (Non-Axe token: "DrawF ") actually has a hidden opening parenthesis. In similar fashion of closing quotes but not closing parentheses, the following line of code will produce errors:
Code: [Select]
Text "HELLO WORLD!"In this case, adding a closing parenthesis will resolve any errors again, but it doesn't logically make sense to do so based on the command not containing an opening parenthesis. Could you please either look into this issue or assign a new name to the "Text " command that contains an opening parenthesis?

Yeah, I noticed that. Why doesn't it apply to Disp , though? Are they treated differently?
Title: Re: Bug Reports
Post by: Happybobjr on December 05, 2010, 01:30:01 pm
Port has disappeared from the commands.
Title: Re: Bug Reports
Post by: Runer112 on December 05, 2010, 01:49:48 pm
Port has disappeared from the commands.

It looks to me like it's right where it always was, as a token replacement for ClrTable.
Title: Re: Bug Reports
Post by: Happybobjr on December 05, 2010, 01:50:40 pm
It just shows clrTable instead of port on mine....
Ram clear and defraged.  Its correct now. sorry.
Title: Re: Bug Reports
Post by: Runer112 on December 05, 2010, 01:52:33 pm
Are you in the TI-OS program editor, editing an Axe program with an appropriate header? The token replacements only take effect under those circumstances. Also, try opening the Axe application once and then trying it again.

EDIT: It looks like the problem has been solved already.
Title: Re: Bug Reports
Post by: Happybobjr on December 05, 2010, 01:53:21 pm
Ya axe had been opened.  there was a proper header. ut was ti-os editor.

It just needed a ram clear....
Title: Re: Bug Reports
Post by: yunhua98 on December 05, 2010, 06:31:49 pm
is this supposed to happen, I keep getting bad symbol error.   :banghead:
Title: Re: Bug Reports
Post by: FinaleTI on December 05, 2010, 06:35:12 pm
is this supposed to happen, I keep getting bad symbol error.   :banghead:
Did you try closing all your parenthesis?
Title: Re: Bug Reports
Post by: Quigibo on December 05, 2010, 06:39:32 pm
You have a for loop without a variable as the first argument.  I haven't implemented external valued for loops yet.
Title: Re: Bug Reports
Post by: AngelFish on December 05, 2010, 06:45:42 pm
So if you just want a specific number of iterations, you can not include the variable argument and it will compile?
Title: Re: Bug Reports
Post by: DJ Omnimaga on December 05, 2010, 10:53:08 pm
(Note: Before submitting bug reports, it is advised to backup your progress, perform a RAM clear then try reproducing the bug again, in case the error migth have been caused by your calc being messed up by a previous mistake that you did. It is also recommended to submit some source code)
Title: Re: Bug Reports
Post by: AngelFish on December 06, 2010, 02:33:30 pm
I think I might have a bug, but I'm not willing to reproduce it for the health of my calculator. Quigibo, do any of the "normal" routines in the calculator use B_calls that can write to archive? I'm talking about things like I->{F*2+L1}. This happened in my code and I was only using the first 400 bytes of L1.

I'll work on re-writing the code so I can post it.

This is what happened with Powder, which is a particle physics simulator.

What happened was that the program generated the particles when I told it too, but the particles didn't detect the wall and fell below the screen. The program then generated a bunch of particles that I hadn't asked for and a few seconds later all of the diagnostics Text( changed to the large font. After few seconds of trying to fix it, I decided to quit the program since my loop was obviously running. Pressing the exit button didn't work, though. Instead, on the fourth try, it took me to the homescreen and displayed a bunch of random tokens at random locations on the screen. Pressing clear again quit the program.

I went back to check my source through Doors (because the source was Archived) and the TI-OS IDE started acting odd. Pressing 2nd would display the cursor somewhere in the code, not in the corner of the screen and the image would stick if I went farther into the code. It also refused to edit properly and deleted a token or two.

By that point, I had had enough and just reset everything. That got rid of all of the problems, but it also deleted my archived source. That might be explainable except for the fact that it was the ONLY program deleted.

But I backed up my progress just yesterday to give some code to Yunhua. I didn't lose much.
Title: Re: Bug Reports
Post by: Quigibo on December 06, 2010, 02:46:12 pm
When you say "write to archive" you mean write to ram that the OS uses right?  Because it is not possible to write to archive without some highly specialised and long inline assembly code.  Axe itself can write to archive, but only when compiling applications and should not touch the archive section of the calculator.

It is definitely possible to screw up some operating system variables which can result in weird glitches and random freezes.  Sometimes, these can go unnoticed for a while after you've already recompiled a new working version, so if you were experimenting with some memory code and it didn't work but didn't get a ram clear either, you might want to clear it yourself just in case.

EDIT: After reading your edit, this is definitely what happened.  Also, DCS unarchives the source when you edit it and then re-archives when you're done, so it is likely that it got messed up while it was unarchived.
Title: Re: Bug Reports
Post by: DJ Omnimaga on December 06, 2010, 02:47:06 pm
Could he have accidentally triggered some OS code that actually deals with archive? I can't seem to figure out how the OS can be messed up without touching the archive. ???
Title: Re: Bug Reports
Post by: AngelFish on December 06, 2010, 02:50:27 pm

EDIT: After reading your edit, this is definitely what happened.

That's good, but how would it have deleted the archived source?
Title: Re: Bug Reports
Post by: squidgetx on December 06, 2010, 06:24:14 pm
The archived source might be hidden. Do you have Calcsys? You might be able to find it in the VAT if it did get hidden somehow :P

also offtopic, but nice new avatar ;)
Title: Re: Bug Reports
Post by: AngelFish on December 06, 2010, 06:48:52 pm
I can't fit Calcsys onto my calc, but I did walk through the VAT. It's there!

So Axe didn't go into the archives. It's still freaky that it went into RAM and changed the one bit responsible for visibility, though...

BTW: I have to thank Runer for the Avatar.
Title: Re: Bug Reports
Post by: Runer112 on December 06, 2010, 07:10:10 pm
Simple bug: the *-1 auto-optimization is missing.


BTW: I have to thank Runer for the Avatar.

I remember making that! ;D
Title: Re: Bug Reports
Post by: AngelFish on December 06, 2010, 07:10:40 pm
It was awhile ago that you made it.  ;D
Title: Re: Bug Reports
Post by: Builderboy on December 06, 2010, 07:17:06 pm
BTW: I have to thank Runer for the Avatar.

Try this one on for size :) Can me modified in whatever way you want

 :'(

EDIT: Whaaat hey my cache was being stupid, i still saw the one made by me  O.O
Title: Re: Bug Reports
Post by: AngelFish on December 06, 2010, 07:18:32 pm
I'm photoshopping it with another image  :P
Title: Re: Bug Reports
Post by: Builderboy on December 06, 2010, 07:20:53 pm
Haha for some reason my computer hadn't refreshed your image and so i thought you still had mine :P
Title: Re: Bug Reports
Post by: AngelFish on December 06, 2010, 07:21:45 pm
Blame TI  ;)
Title: Re: Bug Reports
Post by: LordConiupiter on December 07, 2010, 02:58:04 pm
Or just use Chrome ;)
Title: Re: Bug Reports
Post by: Builderboy on December 07, 2010, 03:16:43 pm
I do :P
Title: Re: Bug Reports
Post by: LordConiupiter on December 08, 2010, 12:01:38 pm
wow strange?!?!?! I never have such problems...
Title: Re: Bug Reports
Post by: Munchor on December 08, 2010, 12:18:45 pm
Simple bug: the *-1 auto-optimization is missing.


BTW: I have to thank Runer for the Avatar.

I remember making that! ;D

Runner, do you have the source code of Axe? It seems like you do since you know what optimizations are in or not.
Title: Re: Bug Reports
Post by: Quigibo on December 08, 2010, 03:37:23 pm
The source code for all the commands is included with the download in the developers section.
Title: Re: Bug Reports
Post by: ztrumpet on December 08, 2010, 04:45:48 pm
If it's still in the VAT, you can use this program to get it back: http://www.ticalc.org/archives/files/fileinfo/411/41128.html
Title: Re: Bug Reports
Post by: Michael_Lee on December 23, 2010, 07:32:22 pm
I decided that I wanted to try using bitmaps, so I wrote this sample program using a simple 16x8 (or is it 8x16?  Hmm...) black bitmap.

Code: [Select]
[0810FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]->Pic1
10->X->Y

Repeat getKey(15)
getKey(3)-getKey(2)+X->X
getKey(1)-getKey(4)+Y->Y

Bitmap(X,Y,Pic1)
DispGraph
ClrDraw
End

It works fine so long as the bitmap is contained within the screen (there was some jaggedness when I was recording -- that's probably Wabbitemu), but if I try to move the bitmap below the bottom of the screen, it glitches and throws a RAM clear.

It looks worse oncalc and on Wabbitemu, but I don't think the full bizarreness was captured by Wabbitemu.

Is this supposed to happen?
Title: Re: Bug Reports
Post by: Quigibo on December 23, 2010, 07:35:35 pm
Yeah, that's supposed to happen.  Its TI's routine not mine, they don't do clipping like mine do.
Title: Re: Bug Reports
Post by: Michael_Lee on December 23, 2010, 07:37:22 pm
Blast and damn.

How come using Pt-On routines clip gracefully?  Is there a difference in routines?
Is there a way to make a bitmap act more like a sprite (in terms of briefly going off screen)?
Title: Re: Bug Reports
Post by: Quigibo on December 23, 2010, 07:43:04 pm
Yeah, TI is lazy so they don't want to write the extra code to do clipping so it will just start to glitch and ram clear if you go off screen instead.  The only way around it other than writing your own routine is to clip it yourself by adjusting the size bytes and the picture in ram.  That would allow you to clip up, down, and right.  Clipping on the left side would be very tricky though, I'm not sure there's an easy way to do that.

EDIT: Actually, thinking about it again, that wouldn't work for right or left.  But at least up and down are easy to clip.
Title: Re: Bug Reports
Post by: Deep Toaster on December 23, 2010, 07:43:30 pm
Blast and damn.

How come using Pt-On routines clip gracefully?  Is there a difference in routines?
Is there a way to make a bitmap act more like a sprite (in terms of briefly going off screen)?

You're going to have to write your own bitmap routine with Pt-On(, then :-\ That's pretty much how the OS's Bitmap( works, anyhow.
Title: Re: Bug Reports
Post by: LordConiupiter on December 25, 2010, 07:26:57 am
Blast and damn.

How come using Pt-On routines clip gracefully?  Is there a difference in routines?
Is there a way to make a bitmap act more like a sprite (in terms of briefly going off screen)?

You're going to have to write your own bitmap routine with Pt-On(, then :-\ That's pretty much how the OS's Bitmap( works, anyhow.
...or you should perhaps check whether your Bitmap is being drawn outside the screen area, or draw your bitmap at the coords (X^(64-BMPwidth),Y^(96-BMPheight))...

EDIT:
.. or you could copy the bitmap to a temp buffer, and change the data to the part of the sprite which should be drawn, using the coords.
Title: Re: Bug Reports
Post by: Quigibo on December 25, 2010, 06:25:10 pm
Speaking of bugs I FINALLY fixed the input command.  It took quite a bit of disassembly since its not documented anywhere.  Turned out the buffer that needed to be cleared was "ioPrompt" at $8D5F.  There is even a bcall to do that.
Title: Re: Bug Reports
Post by: AngelFish on December 25, 2010, 06:27:45 pm
Yay!
Title: Re: Bug Reports
Post by: Deep Toaster on December 26, 2010, 04:46:31 pm
Speaking of bugs I FINALLY fixed the input command.  It took quite a bit of disassembly since its not documented anywhere.  Turned out the buffer that needed to be cleared was "ioPrompt" at $8D5F.  There is even a bcall to do that.

Yay, just in time for the final version! :D
Title: Re: Bug Reports
Post by: JosJuice on December 26, 2010, 05:11:29 pm
Now we can all play WFRNG properly ;D
Title: Re: Bug Reports
Post by: jnesselr on December 26, 2010, 05:57:24 pm
Now we can all play WFRNG properly ;D
Yep! But we have an OS for it, though...
Title: Re: Bug Reports
Post by: squidgetx on December 27, 2010, 10:20:10 am
Using the new line command with any X argument over 95 cuts the line really short. For example drawing a line from 0,0 to 96,0 draws a line on screen from 0,0 to....somewhere around 32,0 I think
Title: Re: Bug Reports
Post by: Munchor on December 27, 2010, 10:26:22 am
Using the new line command with any X argument over 95 cuts the line short. For example drawing a line from 0,0 to 96,0 draws a line on screen from 0,0 to....somewhere around 32,0 I think

So, lines that correspond to instances off the screen are cut to be able to fit? That's bug.
Title: Re: Bug Reports
Post by: Quigibo on December 28, 2010, 10:15:44 pm
Its not a bug.  Any line drawing off-screen is undefined behavior so it's up to the programmer to clip the lines themselves.  It just happened to optimize better this way with the new routine.  And that may change again in the future, I am considering just exiting the routine and drawing nothing instead of the modular clipping I have now.
Title: Re: Bug Reports
Post by: squidgetx on December 29, 2010, 11:45:03 am
Oh ok, I see. I have a bad habit of using 96 as the x coordinate instead of 95 when I want to draw a line all the way across the screen :P
Title: Re: Bug Reports
Post by: kindermoumoute on December 31, 2010, 10:13:50 am
Code: [Select]
EXP→DispGraph :'( don't work in last update :
Quote
ERR: UNKNOW ERR
Code: 4726231
Title: Re: Bug Reports
Post by: c.sprinkle on December 31, 2010, 01:59:49 pm
I have exactly the same problem. Window Maze is un-compilable under 0.4.7.  >:(
Title: Re: Bug Reports
Post by: squidgetx on December 31, 2010, 02:00:28 pm
To get around this temporarily you can use
Copy(EXP,L6,768).
It should be the same size, too. I've always used that form of the command, because you can modify it to work with any buffer :P
Title: Re: Bug Reports
Post by: Builderboy on December 31, 2010, 02:40:57 pm
Squidgetx that is not the same thing, EXP->DispGraph copies EXP to the screen, not the screen buffer.  The whole point of the command is to not touch the screen buffer unfortunately
Title: Re: Bug Reports
Post by: Deep Toaster on December 31, 2010, 03:36:23 pm
App bug, not sure if anyone posted it already since I'm still using 0.4.4.

When I quit the app using PRGM after a compile error (instant goto to the error), the app leaves FracDrawLFont set, so small text in the TI-OS are left in 6x8. Nothing too serious, except maybe with 84+ calcs drawing text off screen for a RAM clear, but still a pretty big bug.
Title: Re: Bug Reports
Post by: squidgetx on December 31, 2010, 03:39:44 pm
Squidgetx that is not the same thing, EXP->DispGraph copies EXP to the screen, not the screen buffer.  The whole point of the command is to not touch the screen buffer unfortunately

Crap. Is the screen's memory accessible with a pointer?
Title: Re: Bug Reports
Post by: Deep Toaster on December 31, 2010, 03:41:23 pm
Squidgetx that is not the same thing, EXP->DispGraph copies EXP to the screen, not the screen buffer.  The whole point of the command is to not touch the screen buffer unfortunately

Crap. Is the screen's memory accessible with a pointer?

Nope, it's in the LCD driver's own RAM. You gotta access it with port instructions.

App bug, not sure if anyone posted it already since I'm still using 0.4.4.

When I quit the app using PRGM after a compile error (instant goto to the error), the app leaves FracDrawLFont set, so small text in the TI-OS are left in 6x8. Nothing too serious, except maybe with 84+ calcs drawing text off screen for a RAM clear, but still a pretty big bug.

(I know I'm quoting myself <_<)

Just checked, and the bug's still there in 0.4.7. Screenshot below:
Title: Re: Bug Reports
Post by: squidgetx on January 01, 2011, 06:00:39 pm
I am not sure exactly as to how or why this happens, but I suspect that .4.7 does not produce apps that can be sent to the computer. I tried multiple axe-generated apps compiled with .4.7 and they are all the same size on the computer (416 bytes) and untransferrable to wabbit. Downgrading to .4.6 and recompiling produced an app that could be sent to the computer. ???
Title: Re: Bug Reports
Post by: Quigibo on January 01, 2011, 08:39:17 pm
Thanks for all the reports.  I'm looking into all this stuff.  It's weird because most of this involves code I didn't touch since many versions ago.
Title: Re: Bug Reports
Post by: Runer112 on January 06, 2011, 12:46:52 am
It looks like any instance of getKey (the B_CALL) has a bit of a problem... the compiler doesn't seem to advance the parsing location upon reaching it, parsing it over and over again until the remainder of the free RAM is filled with copies of the getKey routine and you get a memory error. I would assume this has something to do with the addition of the variable-argument direct port input getKey.

EDIT: Huh, that's odd... I'm getting the same problem with Axe 0.4.6. Surely the problem hasn't existed for this long and gone without noticing?

EDIT 2: I think this problem must be somewhere on my side. But this error happens on both wabbitemu and my real calculator. I'm puzzled...

EDIT 3: Hmm I think I may have found the problem... it looks like the error only crops up when getKey is the very last token in the source. Can anybody else confirm this?
Title: Re: Bug Reports
Post by: Eeems on January 06, 2011, 01:09:18 am
Had the same thing happen with this code:
Code: [Select]
.B
getKey
Title: Re: Bug Reports
Post by: Runer112 on January 08, 2011, 02:42:18 pm
I remember encountering a problem a long time ago, but this is before my Axe and assembly skills were too adept and I figured I was just doing something wrong. However, just a few moments ago, SirCmpwn was having trouble getting the size of archived programs, so I looked into it to help out. In the process of testing the reading of archived programs with a randomly chosen program target (which happened to be a protected assembly program) and looking at Commands.inc, I realized that p_GetArc doesn't check for protected programs! :o
Title: Re: Bug Reports
Post by: Builderboy on January 08, 2011, 02:45:29 pm
Wait so how *are* you supposed to get the filesize of archived programs, protected or not? 
Title: Re: Bug Reports
Post by: Runer112 on January 08, 2011, 02:56:59 pm
The two bytes that specify the size of the variable should be the 2 bytes immediately preceding the pointer returned from GetCalc(), whether using the normal or archive method. This is easy for variables in RAM, because the variable's data starts with two bytes for its size, and the VAT pointer for the variable always points right to it. However, when variables with variable names (programs, lists, appvars, and groups) are archived, the variable's name (and possibly other data, I'm not sure) is appended to the file in front of the two bytes indicating size. To correct this, Quigibo's archive variable locating routine determines the length of the variable's name from the VAT and adds that to the pointer to skip this unwanted data and to be consistent with unarchived variables. However, he forgot to check if the variable's type is a protected program, so it thinks that any protected program doesn't have this and doesn't correct for the name length.
Title: Re: Bug Reports
Post by: SirCmpwn on January 08, 2011, 03:27:52 pm
The problem is that the error isn't consistent.  I can't just add 6 bytes or something and get the length.  Nor can I subtract some, add the value there, and get the length (as if it were in the middle of the name).  The location in ROM that Axe give me is seemingly random.
Title: Re: Bug Reports
Post by: Quigibo on January 08, 2011, 03:37:58 pm
Ok, I've fixed all the problems mentioned so far.
Title: Re: Bug Reports
Post by: SirCmpwn on January 08, 2011, 03:38:37 pm
Cool.  It would make my life quite a bit easier if you uploaded the patched version :D  I found a temporary fix, but it's complicated.
Title: Re: Bug Reports
Post by: Builderboy on January 08, 2011, 03:41:48 pm
Yeah, i've been trying to figure out what was happening, but crazy things were occuring in my program combiner, which was making it impossible for me to continue development on PortalX until the issue is fixed unfortunately, as I can no longer generate the executable.
Title: Re: Bug Reports
Post by: Quigibo on January 08, 2011, 03:56:58 pm
Yeah, maybe I'll upload a patched version since it might still be another week before the stable release.  Not much new, mostly just working on axioms.  They are much much more sophisticated now.  When it reads your assembly command, it knows each z80 instruction opcode in order to advance through it and make auto-replacements for absolute jumps, calls, and even loads under the right circumstances.
Title: Re: Bug Reports
Post by: SirCmpwn on January 08, 2011, 03:57:34 pm
Nice, I look forward to it!
Title: Re: Bug Reports
Post by: ztrumpet on January 08, 2011, 07:15:53 pm
Me too!  I can't wait! ;D
Title: Re: Bug Reports
Post by: DJ Omnimaga on January 08, 2011, 08:12:58 pm
Cool to hear the bugs were fixed ;D
Title: Re: Bug Reports
Post by: SirCmpwn on January 08, 2011, 09:30:03 pm
Found another bug:
The length field of apps is getting messed up again.  It is not the correct length.
Title: Re: Bug Reports
Post by: squidgetx on January 10, 2011, 06:28:56 pm
^ :(

Also, this is fairly random and unreproducible, but sometimes I will run into random BAD SYMBOL errors while compiling (usually an archived program). Sometimes when I unarchive it the compile goes smoothly and error free. More rarely, it will throw another BAD SYMBOL, and upon pressing prgm to goto, the entire program after a certain point seems to be corrupted (lots of random tokens, etc.) I remember that the goto-prgm thing used to be unstable with large programs. What constitutes a large program: one with lots of library files whose compiled code comes out to 16kb count? (The main program is 5 kb and the largest library is 3kb...and the corruption will usually happen to any of them, not just the main program)
Title: Re: Bug Reports
Post by: yunhua98 on January 10, 2011, 06:31:07 pm
that reminds me, one time I compiled a program it threw a Block error, and then when I pressed program, it showed the last lines of my code, which contained a for loop.  That loop was incomplete and everything after it was gone.  I had a backup though.  ;)
Title: Re: Bug Reports
Post by: Quigibo on January 10, 2011, 07:17:12 pm
The app length bug was fixed in 0.4.8

Also, this is fairly random and unreproducible, but sometimes I will run into random BAD SYMBOL errors while compiling (usually an archived program).

That bug was supposed to be fixed in 0.4.7  Have you had that problem in the later versions?

Quote
Sometimes when I unarchive it the compile goes smoothly and error free. More rarely, it will throw another BAD SYMBOL, and upon pressing prgm to goto, the entire program after a certain point seems to be corrupted (lots of random tokens, etc.) I remember that the goto-prgm thing used to be unstable with large programs. What constitutes a large program: one with lots of library files whose compiled code comes out to 16kb count? (The main program is 5 kb and the largest library is 3kb...and the corruption will usually happen to any of them, not just the main program)

This is a problem I still can't figure out.  The OS must be handling large files differently than small ones for some reason because I pass control to the OS before the actual scroll.  If anyone knows more information about the BASIC editor context variables, I could definitely use your help!
Title: Re: Bug Reports
Post by: Happybobjr on January 11, 2011, 10:00:02 am
The display is still a little glitchy on my calc.  It is completely usable and isn't really annoying.  I haven't encountered rotating screens or the like again with the newer version of axe
Title: Re: Bug Reports
Post by: DJ Omnimaga on January 11, 2011, 05:10:18 pm
Could you elaborate, Happybobjr?
Title: Re: Bug Reports
Post by: Happybobjr on January 11, 2011, 05:40:08 pm
I don't know if you can tell from the vid but...

Title: Re: Bug Reports
Post by: Quigibo on January 11, 2011, 08:04:19 pm
I assume you're talking about the 3 level grayscale right?

Okay, so it looks like the extra delay helped, but it might still need to be just slightly longer by 1 or 2 T-States.  I wish TI could just make their hardware more consistent :(
Title: Re: Bug Reports
Post by: Happybobjr on January 11, 2011, 08:50:57 pm
I know i can't speak for everyone but, I am completely fine with this occasional flutter in the screen.
Title: Re: Bug Reports
Post by: TIfanx1999 on January 11, 2011, 08:58:35 pm
I assume you're talking about the 3 level grayscale right?

Okay, so it looks like the extra delay helped, but it might still need to be just slightly longer by 1 or 2 T-States.  I wish TI could just make their hardware more consistent :(
Yep, this is one of my biggest complaints about TI. Their product's display quality is so inconsistent it isn't funny. That's why it's so hard to get decent looking grayscale. It might look great on one calculator but barely passable on another. D=
Title: Re: Bug Reports
Post by: willrandship on January 11, 2011, 09:02:34 pm
Would it be impossible to have it so you can customize the delay length?
Title: Re: Bug Reports
Post by: calc84maniac on January 11, 2011, 09:04:01 pm
Would it be impossible to have it so you can customize the delay length?
The 83+SE, 84+, 84+SE have hardware that can add a delay. This is how ALCDFIX works.
Title: Re: Bug Reports
Post by: Quigibo on January 11, 2011, 11:19:36 pm
That's true... happybobjr, have you ran ALCDFIX first?  There's also something like that built into DCS now that does the same thing.
Title: Re: Bug Reports
Post by: Happybobjr on January 12, 2011, 11:32:15 am
That's true... happybobjr, have you ran ALCDFIX first?  There's also something like that built into DCS now that does the same thing.

no, I haven't I shall try that when i get a chance, thanks.
Title: Re: Bug Reports
Post by: Compynerd255 on January 25, 2011, 10:35:46 am
It seems that there is a bug in the curly bracket command. I've noticed that when I do this,
Code: [Select]
If {L1+70
.do something
{L1+70}-1->{L1+70}
End
that something is always executed, rather than stopping when {L1+70} reaches zero. But when I do this:
Code: [Select]
If {L1+70
{L1+70}->I
.do something
I-1->{L1+70}
End
the code works correctly, no longer executing when {L1+70} hits zero. Do you know what's going on?

It also seems that in Axe 0.4.7, there is a bug in the compiler. Many times, when I write in a piece of code and compile it, the game crashes inexplicably when it is run, forcing me to do a battery pull and sometimes even hold down Clear while putting the battery back in. For example:
Code: [Select]
LnReg
fnInt(CLK, 2
.RUN GAME CODE
sub(GAM
LnReg
Return
This code works once, but every subsequent time I compile, it crashes. Then, when I remove the first LnReg, it works. I know that this is not an isolated problem, because it also crashed on several other examples, including a sprite definition! And I know I wrote it correctly. Was this bug fixed in 0.4.8? I have yet to try...
Title: Re: Bug Reports
Post by: Deep Toaster on January 25, 2011, 10:42:44 am
It seems that there is a bug in the curly bracket command. I've noticed that when I do this,
Code: [Select]
If {L1+70
.do something
{L1+70}-1->{L1+70}
End
that something is always executed, rather than stopping when {L1+70} reaches zero. But when I do this:
Code: [Select]
If {L1+70
{L1+70}->I
.do something
I-1->{L1+70}
End
the code works correctly, no longer executing when {L1+70} hits zero. Do you know what's going on?

Always close your braces. Try If {L1+70} and see if it works. It's not like in BASIC, where leaving the closing brace/bracket/parenthesis saves mem. In Axe, it's exactly the same or worse.
Title: Re: Bug Reports
Post by: Michael_Lee on January 28, 2011, 02:55:47 pm
Input issues:

I think that this is something that was intentionally added by TI, but pressing 2nd, quit while using input will kill the program and give a ram crash the next time I try to run an assembly program (or something). 

I suspect that input is a bcall or something which has a 'safety' 2nd-quit key combo built in by TI that returns to the homescreen, but incidentally happens to mess with the Axe program I want to make.

Or am I completely incorrect?

Solutions, please?

Also, what verb/gerund works best with 'RAM crash'?  Is it 'giving a RAM crash', or 'doing a RAM crash'?  'cuz both of those sound awkward.  </random>
Title: Re: Bug Reports
Post by: Deep Toaster on January 28, 2011, 07:01:38 pm
Also, what verb/gerund works best with 'RAM crash'?  Is it 'giving a RAM crash', or 'doing a RAM crash'?  'cuz both of those sound awkward.  </random>

Causing?
Title: Re: Bug Reports
Post by: calcdude84se on January 28, 2011, 07:35:55 pm
I just saying "clearing RAM" (I use "clear", not "crash", so "crashing RAM" in your case.)
Title: Re: Bug Reports
Post by: Quigibo on January 28, 2011, 07:41:22 pm
Nothing I can really do about that unfortunately unless someone wants to looking into the disassembly of the bcall.  It isn't documented.
Title: Re: Bug Reports
Post by: jnesselr on January 28, 2011, 07:45:10 pm
It's probably GetKey if that's what you are using Quigibo.
Title: Re: Bug Reports
Post by: Camdenmil on February 01, 2011, 07:57:39 pm
I don't know if I touched a section of memory I shouldn't have but every now and then when I compile a program the screen will turn off. When I turn it back on it will show that is crashed right after displaying the text that says compiling and then proceed to the ram cleared screen. I havn't figured out how to reproduce it though, it seems random.
Title: Re: Bug Reports
Post by: Deep Toaster on February 01, 2011, 08:06:25 pm
Maybe Axe got corrupted? Try redownloading it (make sure it's 0.4.8).
Title: Re: Bug Reports
Post by: ztrumpet on February 01, 2011, 08:41:44 pm
Nothing I can really do about that unfortunately unless someone wants to looking into the disassembly of the bcall.  It isn't documented.
I know Kerm took the [2nd] [Quit] away in DoorsCS7.  Maybe you could ask him how he did it. :)

Deep, [nobbc] is your friend!

Maybe Axe got corrupted? Try redownloading it (make sure it's 0.4.8).
Title: Re: Bug Reports
Post by: Deep Toaster on February 01, 2011, 10:26:34 pm
Didn't see that, whoops 8)
Title: Re: Bug Reports
Post by: Xeda112358 on February 01, 2011, 10:35:42 pm
If it is the b_call that allows for modifier keys (EF7249), pressing [2nd]+[ON] should shut the calc off and when you turn it back on, it should return to the homescreen. I have never had a problem with that and that is what I normally use when I am debugging (and I've messed with the stack).
Title: Re: Bug Reports
Post by: Deep Toaster on February 01, 2011, 11:08:18 pm
If it is the b_call that allows for modifier keys (EF7249), pressing [2nd]+[ON] should shut the calc off and when you turn it back on, it should return to the homescreen. I have never had a problem with that and that is what I normally use when I am debugging (and I've messed with the stack).

Doesn't it lose you a few bytes? I always thought it did.
Title: Re: Bug Reports
Post by: Xeda112358 on February 01, 2011, 11:14:52 pm
Yes! I never noticed that before... The number of bytes you lose is equal to how large the code is. So maybe that is the problem? It could just be messing with the RAM a little too much. I wonder how large the program is?
Title: Re: Bug Reports
Post by: Deep Toaster on February 01, 2011, 11:21:16 pm
Yes! I never noticed that before... The number of bytes you lose is equal to how large the code is. So maybe that is the problem? It could just be messing with the RAM a little too much. I wonder how large the program is?

I think it forces a return to the homescreen without cleaning up after the program, so a "ghost" copy is left in mem. Not sure, though.

In any case it's bad for anything but debugging. That's why I usually use GetKeyRetOff (EF0B50). Undocumented, though, which might have other problems.
Title: Re: Bug Reports
Post by: Xeda112358 on February 01, 2011, 11:29:54 pm
I think it forces a return to the homescreen without cleaning up after the program, so a "ghost" copy is left in mem. Not sure, though.
Yeah, I am fairly sure that is what happens. It is the same thing if you use that bcall that ends an app. I never knew about EF0B50... I'm going to check that out :D
Title: Re: Bug Reports
Post by: Deep Toaster on February 02, 2011, 09:16:44 am
It's basically GetKey (EF7249) but 2ND+[OFF] returns $3F instead of turning off the calc.
Title: Re: Bug Reports
Post by: Darl181 on February 03, 2011, 02:38:34 pm
Okay, IDK what's wrong with this.
Spoiler For code:
Code: [Select]
:.TIO Turn it off
:[F0F0F0F000000000]→Pic1
:DiagnosticOff
:ClrDraw
:0→C→M-1→D
:For(A,0,23
:A*4→X
:For(B,0,15
:D+1→D
:B*4→Y
:If rand^9^2
:Pt-On(X,Y,Pic1
:2→{L1+D}
:C+1→C
:Else
:1→{L1+D}
:End
:End
:End
:rand^23→X
:rand^15→Y
:Y*24+X→D
:Lbl 1
:!If C
:ClrHome
:Disp "WIN"
:Pause 1900
:Return
:End
:Repeat getKey(15)
:Repeat getKey(0)
:ReturnIf getKey(15)
:For(A,0,9
:Pt-Change(X*4,Y*4,Pic1
:DispGraph
:ReturnIf getKey(15)
:End
:If getKey(54)
:ClrHome
:Disp "C",C►Dec," D",D►Dec,i,"X",X►Dec," Y",Y►Dec,i,"L1+D",{L1+D}►Dec
:While getKey(54):Pause 10:End
:End
:End
:If getKey(2) and (X>0)
:While getKey(2):Pause 10:End
:D-1→D
:X-1→X
:sub(D)
:Goto 1
:End
:If getKey(3) and (X<23)
:While getKey(3):Pause 10:End
:D+1→D
:X+1→X
:sub(D)
:Goto 1
:End
:If getKey(1) and (Y<15)
:While getKey(1):Pause 10:End
:D+24→D
:Y+1→Y
:sub(D)
:Goto 1
:End
:If getKey(4) and (Y>0)
:While getKey(4):Pause 10:End
:D-24→D
:Y-1→Y
:sub(D)
:Goto 1
:End
:End
:Return
:
:
:Lbl D
:If {L1+D}=1
:2→{L1+D}
:C+1→C
:End
:If {L1+D}=2
:1→{L1+D}
:C-1→C
:End
:Pt-Change(X*4,Y*4,Pic1
.Return
Theoretically, C should change.  ++ every box every time a box turns black, -- for every box turned white.  Thing is, a good part of the time it doesn't.
C is the remaining number of black blocks to be turned off.  Clearly, it's not accurate.
I think there's a problem with it storing in L1.  but it's always worked fine before ???
If you hold 2nd, data comes up.  C is explained above, and the game ends when getkey(15) or C=0[zero].
D is the pointer's location.  The formula is Y*24+X→D.  ie if the selector is in the 9th row and the 3rd column, D is 3*24+9=81.  The xy coordinates are next.  (When drawn to the screen, they're inflated by 4.)
"L1+D" should be the status of the block beneath the selected square.  1 is off, 2 is on.
Hopefully somebody notices it here...I'm pretty sure it's an axe bug b/c pretty much the exact same thing worked before (in TWHG).  Ever since I've updated to Axe 0.4.8, I've been having one problem after another of this nature, also with some problems with RotC( and RotCC( which didn't work when I tried to use them.
So, I was wondering...what changed?  Because data storage to lists and external appvars wasn't failing like this before, and now it fails more often than it works. ???

This is kind of my last-ditch attempt to find out wtf is going wrong, after this I'm downgrading back to 0.4.5.  Can't seem to find another solution, unless I find this out.

EDIT: I'll apologize in advance if this sounds sort of rude or whatever, I'm in kind of a tense mood today  :(
Title: Re: Bug Reports
Post by: Runer112 on February 03, 2011, 03:34:39 pm
Hopefully somebody notices it here...I'm pretty sure it's an axe bug b/c pretty much the exact same thing worked before (in TWHG).  Ever since I've updated to Axe 0.4.8, I've been having one problem after another of this nature, also with some problems with RotC( and RotCC( which didn't work when I tried to use them.
So, I was wondering...what changed?  Because data storage to lists and external appvars wasn't failing like this before, and now it fails more often than it works. ???

After close inspection, I noticed a few things that could be causing problems in the code you posted. Firstly, the End:If {L1+D}=2 in subroutine D should just be replaced with an Else. Otherwise, the first if statement may activate and change {L1+D} to 2, thus also activating the following if statement, effectively negating the change you want. The other problem I noticed is that the data isn't being generated correctly for how you step through it later. To generate the data, you loop through Y values inside of a loop through X values, thus making X the "major" direction. However, in all other places in your program, you assign Y as the "major" direction. You should change the data generation code so the X loop is inside of the Y loop. Hopefully these two things will solve your problems!

I also can explain the bugs in Axe 0.4.8 with rotC() and rotCC(), as those are my fault. I supplied Quigibo with optimized routines for them, but neither of us noticed until it was too late that the code had a slight fault. Instead of returning the pointer to the rotated sprite, they return the pointer plus eight. For a temporary fix you can add -8 after any rotate commands in Axe 0.4.8. Hopefully this problem will be fixed in the next version though, so if it is, make sure to get rid of any -8's that you may have added.

Quigibo: If you're reading this and haven't already fixed the rotate problem, I posted the corrected code a while back here (http://ourl.ca/4175/162131).
Title: Re: Bug Reports
Post by: Darl181 on February 04, 2011, 12:41:44 pm
Okay, that helped and it looks like it's mostly taken care of.  Thanks!
Title: Re: Bug Reports
Post by: JosJuice on February 06, 2011, 01:24:47 pm
Pressing a key that corresponds to a letter in the compile list while not having any programs to compile causes a RAM clear.
Title: Re: Bug Reports
Post by: Happybobjr on February 06, 2011, 02:45:38 pm
you have that few programs?
Title: Re: Bug Reports
Post by: JosJuice on February 06, 2011, 02:47:08 pm
I don't have any Axe source programs (I don't use Axe), but I have a lot of other programs.
Title: Re: Bug Reports
Post by: Builderboy on February 06, 2011, 02:50:14 pm
Lots of programs or not, its still a bug.  Also note the appearance of backups remedies this bug as well, it only occurs if there are no Axe programs and no backups as well
Title: Re: Bug Reports
Post by: squidgetx on February 06, 2011, 08:18:56 pm
Oh noes, a bug! D:

Nibble reading and writing is not consistent. It was consistent in .4.6 though, I think since then nibble writing was changed to little-endian while nibble reading remained big-endian. Screenie attached. Btw, I'd like to ask that whatever it was in .4.6 be the default, otherwise I'm going to have to re enter a lot of data... Thank you!

Code: (in case you missed it) [Select]
0->{L1}
1->nib{L1*2}
Disp nib{L1*2}>Dec
Title: Re: Bug Reports
Post by: Darl181 on February 07, 2011, 06:58:33 pm
I think I found something that's both an incompatibility issue and a feature request.
Can the instant goto be made compatible with CalcUtil's "save screen" option?
The save screen is when you quit out of the program editor it asks if you want to save changes or not, very useful :) but it causes crashes with axe :P
Title: Re: Bug Reports
Post by: squidgetx on February 12, 2011, 07:51:03 pm
Er...
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 12, 2011, 07:54:15 pm
Hmm weird bug. Was it introduced in 0.5?
Title: Re: Bug Reports
Post by: squidgetx on February 12, 2011, 08:04:42 pm
Yeah. I think he's fixing it now. Also, the new help screen says "For additional help and examles"... :P
Title: Re: Bug Reports
Post by: Quigibo on February 12, 2011, 08:10:01 pm
Fixed it, that was a really really stupid mistake, something I added in last minute that I didn't have time to test.  I'll get the typo later.  Sorry about that.
Title: Re: Bug Reports
Post by: Happybobjr on February 12, 2011, 08:37:02 pm
EndIf EXP    In loops, it works just like a regular "End" if the condition is true. But it will exit the loop if the condition is false.
End!If EXP    In loops, it works just like a regular "End" if the condition is false. But it will exit the loop if the condition is true.

Shouldn't that be


EndIf EXP    In loops, it works just like a regular "End" if the condition is true. But it will exit the loop if the condition is true.
End!If EXP    In loops, it works just like a regular "End" if the condition is false. But it will exit the loop if the condition is false.
Title: Re: Bug Reports
Post by: FinaleTI on February 12, 2011, 08:42:04 pm
EndIf EXP    In loops, it works just like a regular "End" if the condition is true. But it will exit the loop if the condition is false.
End!If EXP    In loops, it works just like a regular "End" if the condition is false. But it will exit the loop if the condition is true.

Shouldn't that be


EndIf EXP    In loops, it works just like a regular "End" if the condition is true. But it will exit the loop if the condition is true.
End!If EXP    In loops, it works just like a regular "End" if the condition is false. But it will exit the loop if the condition is false.
Shouldn't that be


EndIf EXP    In loops, it works just like a regular "End" if the condition is false. But it will exit the loop if the condition is true.
End!If EXP    In loops, it works just like a regular "End" if the condition is true. But it will exit the loop if the condition is false.
Title: Re: Bug Reports
Post by: Happybobjr on February 12, 2011, 08:43:18 pm
No I was wrong.
It was right the way it was.
I misread it.
Title: Re: Bug Reports
Post by: FinaleTI on February 12, 2011, 08:50:21 pm
Ok.
Title: Re: Bug Reports
Post by: Juju on February 15, 2011, 08:35:53 pm
I compiled an Axe program so it would output an Application, but I didn't had enough archive. Naturally, it error'd. Then I found out with Calcsys it created an unnamed, 0xC6050500 byte (3 GB?) application in the archive. Now the Arc Free counter in 2nd+MEM is stuck to 0 bytes left. And I can't see it there and delete it, due of its lack of a name.

Is it a bug? If not, feel free to move this post somewhere else. Anyway, it's freaking weird.
Title: Re: Bug Reports
Post by: Builderboy on February 15, 2011, 09:35:50 pm
So with Axe 5.0 I am getting some random Err:Symbol errors when a program is archived, as well as sometimes reporting a picture is missing, even if it is not.
Title: Re: Bug Reports
Post by: Darl181 on February 15, 2011, 09:39:15 pm
Axe 0.4.8 did this as well, and now 0.5.0: A sub-program (called by prgmWHATEVER in the source) occasionally gets a part of it wiped out, like in the middle of a pt-on or something.
Tio 5 does/causes this continually D:
Title: Re: Bug Reports
Post by: Compynerd255 on February 16, 2011, 10:30:21 am
I compiled an Axe program so it would output an Application, but I didn't had enough archive. Naturally, it error'd. Then I found out with Calcsys it created an unnamed, 0xC6050500 byte (3 GB?) application in the archive. Now the Arc Free counter in 2nd+MEM is stuck to 0 bytes left. And I can't see it there and delete it, due of its lack of a name.

Is it a bug? If not, feel free to move this post somewhere else. Anyway, it's freaking weird.
Yeah, this is a serious bug. Having insufficient space should not destroy your calculator's memory. Axe should check the amount of space required to write the app, and then refuse to write it if space was insufficent.
In the meantime, to get your memory back, try a Garbage Collect. If that doesn't work, do a Mem Clear.
Title: Re: Bug Reports
Post by: aeTIos on February 16, 2011, 10:48:41 am
^^^But first do a backup of the good files...^^
Title: Re: Bug Reports
Post by: Juju on February 16, 2011, 06:14:24 pm
I compiled an Axe program so it would output an Application, but I didn't had enough archive. Naturally, it error'd. Then I found out with Calcsys it created an unnamed, 0xC6050500 byte (3 GB?) application in the archive. Now the Arc Free counter in 2nd+MEM is stuck to 0 bytes left. And I can't see it there and delete it, due of its lack of a name.

Is it a bug? If not, feel free to move this post somewhere else. Anyway, it's freaking weird.
Yeah, this is a serious bug. Having insufficient space should not destroy your calculator's memory. Axe should check the amount of space required to write the app, and then refuse to write it if space was insufficent.
In the meantime, to get your memory back, try a Garbage Collect. If that doesn't work, do a Mem Clear.
Garbage Collect didn't worked. But I reseted the apps mem and it worked.

And of course I did a backup of all my files. Now I have to reupload all my files.
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 16, 2011, 06:23:26 pm
Yeah I agree with Compynerd. Sometimes we don,t expect to run out of memory too.

Also what's with the 3 GB app thing juju? O.O (on IRC)
Title: Re: Bug Reports
Post by: Juju on February 16, 2011, 06:26:55 pm
Well, the generated, screwed up app reported to be 0xC6050500 byte (3 GB) on Calcsys.

The filesize is actually part of the file format, so if you change 4 bytes, you could change the filesize. It just happened to have C6050500 in the filesize field.
Title: Re: Bug Reports
Post by: Deep Toaster on February 16, 2011, 07:11:56 pm
Yeah I agree with Compynerd. Sometimes we don,t expect to run out of memory too.

Also what's with the 3 GB app thing juju? O.O (on IRC)

You can do stuff like that. Just change the size bytes of any var to anything you want, and the OS will think it's that big.
Title: Re: Bug Reports
Post by: aeTIos on February 18, 2011, 04:37:26 am
I found a bug:
If you use Bitmap(, it doesnt show up good in an application. It shows up a randomly-filled square with the size of the picture.
Is this a known bug?
Else, this is version 0.4.8
Title: Re: Bug Reports
Post by: DJ Omnimaga on February 18, 2011, 04:47:23 am
Hmm Bitmap is one of TI's Bcalls, if I remember. I don't know if it could be used inside apps.
Title: Re: Bug Reports
Post by: aeTIos on February 18, 2011, 05:51:49 am
I hope quigibo can fix it or make a custom routine
Title: Re: Bug Reports
Post by: FinaleTI on February 18, 2011, 06:00:14 am
I found a bug:
If you use Bitmap(, it doesnt show up good in an application. It shows up a randomly-filled square with the size of the picture.
Is this a known bug?
Else, this is version 0.4.8
Yeah, I reported this a long while ago as well.

In order to use it in an App, you have to copy the bitmap to somewhere in RAM be it an appvar or freeram, then use Bitmap() with a pointer to the bitmap.
Title: Re: Bug Reports
Post by: Builderboy on February 18, 2011, 02:11:24 pm
A and not(B) throws an symbol error :( it seems not() cannot be used inter expression?
Title: Re: Bug Reports
Post by: aeTIos on February 18, 2011, 02:21:52 pm
Try A and(not(B))
Title: Re: Bug Reports
Post by: Builderboy on February 18, 2011, 02:36:29 pm
yeah I know how to make it work, but its still a bug ;)
Title: Re: Bug Reports
Post by: aeTIos on February 18, 2011, 02:43:08 pm
Yeah I agree with Compynerd. Sometimes we don,t expect to run out of memory too.

Also what's with the 3 GB app thing juju? O.O (on IRC)


You can do stuff like that. Just change the size bytes of any var to anything you want, and the OS will think it's that big.
That happens to me often if i have some bugs/wrong codes in my prog, then i have a Y1 that is 36656 bytes big or a Str1 that is 123333 bytes O.O only remedy: ram clear.
Title: Re: Bug Reports
Post by: Mighty Moose on February 18, 2011, 02:54:23 pm
Or Calcsys.
Title: Re: Bug Reports
Post by: AngelFish on February 18, 2011, 03:30:57 pm
/me is impressed that Mighty Moose keeps a list of the size of every variable on his calc memorized.
Title: Re: Bug Reports
Post by: Mighty Moose on February 18, 2011, 03:39:20 pm
Naw, I may be a computer calculator but I am not that good. ;) j/k
You can find the size of a variable wherever the variable is located in memory - the first 2 bytes of any(?) variable are its size bytes, meaning that if you set them to 0, then the OS thinks that they don't exist or they are zero bytes in length - useful for removing excessively large equations that crash the Y= editor... :P
Title: Re: Bug Reports
Post by: Deep Toaster on February 20, 2011, 05:17:32 pm
Bug: getKey(0) doesn't work anymore.
Title: Re: Bug Reports
Post by: Runer112 on February 22, 2011, 03:48:22 am
I don't know if this is more of a bug report or a feature request, but none of the GetCalc() routines account for real and complex number variables lacking a 2-byte header. Although a few other data types like lists and matrices don't have a 2-byte size header, they do have a 2-byte dimension header which I think works well with the current method. However, for real and complex number variables, I would suggest the following changes.


p_GetCalc: Also optimized a byte off the page checking.

Code: (Old) [Select]
p_GetCalc:
.db __GetCalcEnd-1-$
MOV9TOOP1()
B_CALL(_ChkFindSym)
ld hl,0
ret c
inc b
dec b
ret nz
inc de
inc de
ex de,hl
ret
__GetCalcEnd:





   
Code: (New) [Select]
p_GetCalc:
.db __GetCalcEnd-1-$
MOV9TOOP1()
B_CALL(_ChkFindSym)
ld hl,0
ret c
dec b
ret p
and %00011111
ret z
cp CplxObj
ret z
inc de
inc de
ex de,hl
ret
__GetCalcEnd:




p_NewVar: No special optimizations here.

Code: (Old) [Select]
p_NewVar:
.db __NewVarEnd-1-$
B_CALL(_EnoughMem)
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(OP1)
B_CALL(_CreateVar)
ex de,hl
inc hl
inc hl
ret
__NewVarFail:
ld hl,0
ret
__NewVarEnd:







   
Code: (New) [Select]
p_NewVar:
.db __NewVarEnd-1-$
B_CALL(_EnoughMem)
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(OP1)
push af
B_CALL(_CreateVar)
pop af
ex de,hl
and %00011111
ret z
cp CplxObj
ret z
inc hl
inc hl
ret
__NewVarFail:
ld hl,0
ret
__NewVarEnd:




p_GetArc: Takes a new approach to determining if the VAT entry is variable length by comparing the VAT pointer to (progPtr) instead of throwing it out and using a list of compares and jumps based on the variable type. This also alleviates 2 other discrepancies with the previous routine, which were that the CListObj and TempProgObj variable types both have variable-length VAT entries but were not accounted for. In the end, even with the added code for checking if the type equals RealObj or CplxObj the whole thing is 3 bytes smaller than the original!

Code: (Old) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
ld hl,0
jr c,__GetArcFail
ld a,(OP1)
cp ListObj
jr z,__GetArcName
cp ProgObj
jr z,__GetArcName
cp ProtProgObj
jr z,__GetArcName
cp AppvarObj
jr z,__GetArcName
cp GroupObj
jr z,__GetArcName
__GetArcStatic:
ld hl,14
jr __GetArcDone
__GetArcName:
ld hl,9
add hl,de
B_CALL(_LoadDEIndPaged)
ld d,0
inc hl
inc hl
__GetArcDone:
add hl,de
__GetArcFail:
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcEnd:



   
Code: (New) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
push de
ex de,hl
ld hl,(progPtr)
sbc hl,de
pop de
ld hl,9
jr c,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l ;cp CplxObj
jr z,__GetArcDone
ld l,14
jr __GetArcDone
__GetArcName:
add hl,de
B_CALL(_LoadDEIndPaged)
ld d,0
inc e
inc e
__GetArcDone:
add hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcFail:
ld hl,0
pop de
ret
__GetArcEnd:






And while we're on the topic of OS variable manipulation, using GetCalc() to create variables can result in an ERR:MEMORY because it doesn't account for the size of the VAT entry or the size bytes when calling B_CALL(_EnoughMem). Here's the easy, although wrong, way to guarantee that you won't get an error. It also includes the changes I made above. The right way would probably end up bloating the routine to a massive size and wouldn't be fun to write.


Code: (Easy way) [Select]
p_NewVar:
.db __NewVarEnd-1-$
push hl
ld de,17
add hl,de
B_CALL(_EnoughMem)
pop de
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(OP1)
push af
B_CALL(_CreateVar)
pop af
ex de,hl
and %00011111
ret z
cp CplxObj
ret z
inc hl
inc hl
ret
__NewVarFail:
ld hl,0
ret
__NewVarEnd:

Title: Re: Bug Reports
Post by: Freyaday on March 05, 2011, 08:31:04 pm
L3->DispGraph and L6->DispGraph both produced
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.
Title: Re: Bug Reports
Post by: calc84maniac on March 05, 2011, 08:50:49 pm
Hey Runer112, with those changes I think you'll need to and $1f before checking for real/complex variables. You might find this particularly necessary for negative real values. It can replace the or a because it affects the Z flag, so only 1 byte lost.
Title: Re: Bug Reports
Post by: Runer112 on March 05, 2011, 08:59:20 pm
Are you sure? ASM in 28 days says the following regarding the type byte:

   Bit   
Meaning
0-4
Object type
5
If a graph equation, then it's active if set.
6
Variable is used during graphing if set.
7
Variable is designated for link transfer if set.


I considered bits 5-7 possibly being set, but I don't think they ever should be set for a real or complex variable. I believe bits 5 and 6 only apply to graph equations, and bit 7 should only be set by the OS link transfer system, which wouldn't be used in the middle of an assembly program.
Title: Re: Bug Reports
Post by: calc84maniac on March 05, 2011, 09:12:19 pm
Actually, looks like bit 6 applies to real variables, meaning that the variable is referenced in an equation. Ever noticed that if you change a variable that is used in an equation, the OS knows to regraph?
Title: Re: Bug Reports
Post by: Runer112 on March 05, 2011, 10:00:35 pm
Ah, you are indeed correct, I'll fix that now.
Title: Re: Bug Reports
Post by: Compynerd255 on March 07, 2011, 10:24:04 am
L3->DispGraph and L6->DispGraph both produced
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.
This actually happens with all <pointer>->DispGraph functions, ever since Axe 0.4.7. That is an incredibly annoying bug. However, I do have a workaround. You could replace P->DispGraph with:
Code: [Select]
Copy(P,L6,768)
DispGraph
This will take up the draw buffer, but not only will the picture appear, you can also draw on it.
Title: Re: Bug Reports
Post by: Freyaday on March 07, 2011, 10:28:36 am
L3->DispGraph and L6->DispGraph both produced
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.
This actually happens with all <pointer>->DispGraph functions, ever since Axe 0.4.7. That is an incredibly annoying bug. However, I do have a workaround. You could replace P->DispGraph with:
Code: [Select]
Copy(P,L6,768)
DispGraph
This will take up the draw buffer, but not only will the picture appear, you can also draw on it.
Unfortunately, this also negates the purpose of L3->DispGraph, to display just the back buffer without messing up the front? buffer.
Title: Re: Bug Reports
Post by: Deep Toaster on March 07, 2011, 08:49:35 pm
And it's a bug, so it should be reported :)

And bump for
Bug: getKey(0) doesn't work anymore.
It returns just the key value of the key group, without taking the group value into account or converting it to GetCSC format.
Title: Re: Bug Reports
Post by: Runer112 on March 07, 2011, 09:48:33 pm
Deep Thought, getKey(0) wasn't designed to give a specific value according to which key was pressed. It was simply designed to return 0 if no key is pressed and something that's not 0 otherwise. If you want a value corresponding to the actual key pressed, the normal getKey does that.
Title: Re: Bug Reports
Post by: Deep Toaster on March 07, 2011, 11:46:42 pm
Deep Thought, getKey(0) wasn't designed to give a specific value according to which key was pressed. It was simply designed to return 0 if no key is pressed and something that's not 0 otherwise. If you want a value corresponding to the actual key pressed, the normal getKey does that.

Oh! For some reason I've always thought it was Axe's version of GetCSC, minus the pauses. Never mind then.

EDIT: Dunno where I got that idea :P
Title: Re: Bug Reports
Post by: ralphdspam on March 10, 2011, 09:34:44 pm
A very odd bug:
I am currently running 2.55MP on a TI84+SE.
The calc has Axe 0.5.0 and DCS 7.1.
Spoiler For Other ASM/Axe Programs that may have interfered:
AXEPAINT
CHESS (thepenguin77)
DRMARIO v.1.0 (Joel Seligstein)
DUST
MARIO v.1.2
OBLITR8
TETRISM
I don't have much context to this problem, but I will explain it as well as I can.
I had a source code for my upcoming (and still unannounced) game in the RAM. 
As I compiled it, Axe saved a backup like usual.  When Axe finished backing up, I opened the Prgm menu. 
The numbers to the left of the program were all scrambled up, and some entries were shown multiple times while others were not shown at all.

Next, I opened DCS to see if the bug screwed up the folders and everything else.  Fortunately, it did not. 
Once I saw that everything (the programs itself) should be okay, I restored the backup and recompiled it. 
This time, the compiling screen (not "backing up") froze.  I was forced to remove a battery. 

After the RAM cleared, I was able to restore the backup and compile it again. 
The menu was back to normal, and the compiled program ran fine. 

Everything I had was archived, and nobody got hurt. :)


Title: Re: Bug Reports
Post by: Happybobjr on March 10, 2011, 09:43:12 pm
I bet you have mirage os don't you...
Mirage and doors don't get along at all :/
Although i might be completely wrong about you having mirage.
Title: Re: Bug Reports
Post by: ralphdspam on March 10, 2011, 09:44:31 pm
No, I don't have Mirage.  I have always wanted to try it (without DCS of course), but I have never gotten around to it.
Title: Re: Bug Reports
Post by: squidgetx on March 10, 2011, 10:58:35 pm
Most likely your program or another wrote to somewhere it shouldn't have been writing. If this happens often while testing your program, that could be it. But sometimes weird stuff like that just happens (which is why everyone should always back up :D)
Title: Re: Bug Reports
Post by: ralphdspam on March 10, 2011, 11:04:37 pm
This happened when I was compiling it in Axe.  I was not able to run my program because of the glitched program menu. ???
Title: Re: Bug Reports
Post by: Happybobjr on March 10, 2011, 11:21:52 pm
you can always write out the program name to run it
Title: Re: Bug Reports
Post by: ralphdspam on March 10, 2011, 11:24:00 pm
Well... the problem was solved with a RAM clear.  I just posted the bug to inform Quigibo so he can find and fix it for a future release.  :)
Title: Re: Bug Reports
Post by: leafy on March 11, 2011, 02:50:58 am
I've noticed that using free RAM in Axe programs corrupts statistics functions.
Title: Re: Bug Reports
Post by: Runer112 on March 11, 2011, 12:54:03 pm
The section of RAM pointed to by L2 is statVars. It contains data for most of the statistics variables, so changing this data will corrupt any existing statistics variables.

Quigibo, perhaps implement B_CALL(_DelRes) somehow? It would probably have to be manually called by the user at their discretion, but it would be useful for people who want to use L2. And for that matter, B_CALL(_DelRes) should probably be a part of the interrupt setup, which it currently is not.
Title: Re: Bug Reports
Post by: Happybobjr on March 17, 2011, 09:42:32 pm
Pt-on(X,Y, Y1 )  fails to work
Title: Re: Bug Reports
Post by: Runer112 on March 17, 2011, 09:44:23 pm
Not a bug. Accessing data from archive requires a special routine that can't be easily applied to work with other routines. That's why you can only access archived data as direct data reads or with Copy().
Title: Re: Bug Reports
Post by: Happybobjr on March 17, 2011, 09:57:09 pm
Ok thank you very much.
Title: Re: Bug Reports
Post by: leafy on March 17, 2011, 10:16:54 pm
Oh, so statVars is L2. Cool, now I know what's screwing me up on tests -.- I always have to ram reset.
Title: Re: Bug Reports
Post by: Darl181 on March 20, 2011, 02:46:13 am
If I use Else!If more than 11 times consecutively, the parser throws ERR:BLOCK

I'm not sure if it's specific to Else!If, tho

btw there's some complex Pt-On( 's between them, maybe it could have to do with # of bytes in the block?
Title: Re: Bug Reports
Post by: Happybobjr on March 20, 2011, 11:43:26 am
check your code,  When i was optimizing, i think it was gravitater, I had used Else!If more than 11 times consecutively.
Title: Re: Bug Reports
Post by: Ashbad on March 20, 2011, 11:44:48 am
I've used as many as 20 in a row, it might be another problem with your code.
Title: Re: Bug Reports
Post by: Deep Toaster on March 20, 2011, 01:11:59 pm
I've used as many as 20 in a row, it might be another problem with your code.

Same (although apparently it gets really unoptimized). I still can't seem to find a pattern for when there's a bug with ElseIf. I know earlier versions of Axe occasionally messed up on nested If - ElseIf - End loops randomly.
Title: Re: Bug Reports
Post by: Darl181 on March 20, 2011, 04:34:25 pm
I'm using 5.0.0, so it's the latest version...
idk, For now I just have them split apart into two blocks
Title: Re: Bug Reports
Post by: ralphdspam on March 22, 2011, 10:21:31 pm
A very odd bug:
I am currently running 2.55MP on a TI84+SE.
The calc has Axe 0.5.0 and DCS 7.1.
I don't have much context to this problem, but I will explain it as well as I can.
I had a source code for my upcoming (and still unannounced) game in the RAM. 
As I compiled it, Axe saved a backup like usual.  When Axe finished backing up, I opened the Prgm menu. 
The numbers to the left of the program were all scrambled up, and some entries were shown multiple times while others were not shown at all.

Next, I opened DCS to see if the bug screwed up the folders and everything else.  Fortunately, it did not. 
Once I saw that everything (the programs itself) should be okay, I restored the backup and recompiled it. 
This time, the compiling screen (not "backing up") froze.  I was forced to remove a battery. 

After the RAM cleared, I was able to restore the backup and compile it again. 
The menu was back to normal, and the compiled program ran fine. 

A similar problem happened.  ???

This time, Axe did not freeze.  It seemed to compile like usual. 
When I tried to open any Flash Apps, it said "ERR: Validation".  It also messed up the menu screen (see quote above).  Also, one of my subprograms went missing from the archive. 
Title: Re: Bug Reports
Post by: Darl181 on March 23, 2011, 12:08:18 am
Umm...axe 0.5.5 doesn't exist...version 0.4.5 does tho
To start with, I would suggest updating axe.
If it's the latest version, than it's probably time to re-send, sounds like the app is corrupted or something.
Title: Re: Bug Reports
Post by: ralphdspam on March 23, 2011, 01:03:18 am
Oh, sorry. I meant 0.5.0.  I will try to resend the app.

The weird thing is that it only happens sometimes.  When I try to compile the same source again, Axe works fine.  ???
Title: Re: Bug Reports
Post by: Happybobjr on March 23, 2011, 07:53:08 am
garbage collect may help.
also, what calc are you using?  Free ram? Free archive?
Title: Re: Bug Reports
Post by: ralphdspam on March 23, 2011, 10:14:59 am
I am using a TI-84 Plus SE (no extra ram).

Yes, there was free ram and archive.  (Again, the weird thing was solved with a ram clear :))
Title: Re: Bug Reports
Post by: aeTIos on March 23, 2011, 10:29:04 am
Weird...
Title: Re: Bug Reports
Post by: Deep Toaster on March 23, 2011, 05:05:34 pm
New bug: Apparently Axe adds two after finding a pointer to a real var after using GetCalc(, even though it isn't needed (you probably already know about this).
Title: Re: Bug Reports
Post by: Runer112 on March 23, 2011, 05:09:58 pm
New bug: Apparently Axe adds two after finding a pointer to a real var after using GetCalc(, even though it isn't needed (you probably already know about this).

For more info, see: http://ourl.ca/4072/176999 (http://ourl.ca/4072/176999)
Title: Re: Bug Reports
Post by: Deep Toaster on March 23, 2011, 05:20:07 pm
Ah, didn't see that. Which reminds me:


A list of all reported bugs since 0.5.0 was released.
Title: Re: Bug Reports
Post by: Freyaday on March 23, 2011, 06:59:06 pm
[0000000000000000]->Pic0->Pic2
Does not work.
Title: Re: Bug Reports
Post by: Runer112 on March 23, 2011, 07:03:25 pm
[0000000000000000]->Pic0->Pic2
Does not work.

I'm not really sure why you would want to do this. If you have already defined the data as Pic0, defining it again as something else would just be a waste of symbols.
Title: Re: Bug Reports
Post by: Freyaday on March 23, 2011, 07:14:39 pm
No, what's supposed to happen is that 8 bytes of 0s get stored to--oh wait, that's not how Axe works. Never mind.
Title: Re: Bug Reports
Post by: Deep Toaster on March 23, 2011, 08:46:44 pm
Code: (Axe) [Select]
:[0000000000000000]→Pic0
:[]→Pic2

Though really you can just access it as Pic0+8 and save a pointer.
Title: Re: Bug Reports
Post by: Runer112 on March 27, 2011, 06:00:09 pm
getKeyr has a slight problem, not sure whether or not it's worth fixing. The bit that is set to prevent 2nd + ON from turning off the calculator is still set when the program exits. If the program is simply run from the homescreen, when it returns, 2nd + ON does nothing. Although this effect can be reversed by doing something like opening a menu, it's still a slight problem.
Title: Re: Bug Reports
Post by: Quigibo on March 27, 2011, 06:29:36 pm
ooo... I had never noticed that.  That does sound like a big problem.  I guess I can use the regular _getkey since its exactly the same except for that, I just thought it would be cool to capture [2nd][off] as a keycode.
Title: Re: Bug Reports
Post by: Runer112 on March 27, 2011, 06:33:37 pm
Or you could use res 7,(iy+28h) after the routine to counteract the effect. If I recall correctly, B_CALL(_getkey) can cause problems if the user shuts off the calculator during it. But then again, they could just use 2nd + MODE for that matter.
Title: Re: Bug Reports
Post by: Happybobjr on March 27, 2011, 06:55:29 pm
... I just thought it would be cool to capture [2nd][off] as a keycode.
It is
Title: Re: Bug Reports
Post by: calc84maniac on March 27, 2011, 07:55:30 pm
Or you could use res 7,(iy+28h) after the routine to counteract the effect. If I recall correctly, B_CALL(_getkey) can cause problems if the user shuts off the calculator during it. But then again, they could just use 2nd + MODE for that matter.
2nd-mode wouldn't quit, it would just return a key code. I think using the 2nd-on capture and resetting the flag afterward would be a good idea.
Title: Re: Bug Reports
Post by: Deep Toaster on March 27, 2011, 08:01:24 pm
If I recall correctly, B_CALL(_getkey) can cause problems if the user shuts off the calculator during it.

Yeah, it leaves a copy of the program in RAM if it was run from the homescreen.

getKeyr currently uses _getKeyRetOff, right? If so I think resetting the flag after is a good idea.
Title: Re: Bug Reports
Post by: Freyaday on March 27, 2011, 11:06:30 pm
I have 2.53mp and Axe 0.4.7
I got a Error:Duplicate because I tryed to redefine Str0. Then, I opened the F1-4 menubar, and none of the text in the menu showed up. It worked exactly as normal, it even had the selection box, but there was no text.
Title: Re: Bug Reports
Post by: ZippyDee on March 28, 2011, 12:43:32 am
If the last character in a program is ) then it gets an error.
Title: Re: Bug Reports
Post by: Deep Toaster on March 28, 2011, 06:46:15 pm
I have 2.53mp and Axe 0.4.7
I got a Error:Duplicate because I tryed to redefine Str0. Then, I opened the F1-4 menubar, and none of the text in the menu showed up. It worked exactly as normal, it even had the selection box, but there was no text.

You probably set Fix 5 somewhere and forgot to change it back to Fix 4? Or maybe Axe did that.
Title: Re: Bug Reports
Post by: Freyaday on March 29, 2011, 02:33:35 am
When I try to GetCalc an appvar in Archive, and the appvar exists, but in RAM, it gives me a nonzero value. I do not know what that value is but it is consisent and wrong. The converse also seems to be true: the same sort of thing happens when I'm looking for an appvar in RAM and it's in Archive. The erstaz address also seems to be unique to each appvar's name. I don't know if this only happens with appvars.
Title: Re: Bug Reports
Post by: Runer112 on March 29, 2011, 09:24:10 pm
The weirdest Axe bug I have ever encountered!

After a bit of testing I found the problem, and I bet you'll never guess in what code I found it...



COMMENTS! You thought they didn't affect your program, but you were wrong! Apparently there's a very peculiar bug regarding multi-line comments for which I will make a post in the Bug Reports thread as soon as I'm done with this post. If the ending "..." for a multi-line comment has an odd number of blank lines immediately preceding it, the comment doesn't actually end! So although you thought the parser was doing this:
Code: [Select]
... [[START COMMENT]]
SOLID WALL
BREAK WALL
WALK FLOOR
INCREASE RADIUS

... [[END COMMENT]]

[7EFFFFFFFFFFFF7E→Pic1
[7EC39FBFFFFFFF7E
[7EC5A3A995C5A37E
[7EFFFFFFFFFFFF7E
[00242400423C0000
[FFDBDBFFBDC3FFFF
[003C525E7A4A3C00
[003C7E7E7E7E3C00]



... [[START COMMENT]]
P1
P2
P3
P4
BOMB SMALL
BOMB MED
BOMB LARGE
BOMB EXPLODE
TOMBSTONE
... [[END COMMENT]]

It was actually doing this:

Code: [Select]
... [[START COMMENT]]
SOLID WALL
BREAK WALL
WALK FLOOR
INCREASE RADIUS

... [[1 BLANK LINE ABOVE, DO NOTHING]]

[7EFFFFFFFFFFFF7E→Pic1
[7EC39FBFFFFFFF7E
[7EC5A3A995C5A37E
[7EFFFFFFFFFFFF7E
[00242400423C0000
[FFDBDBFFBDC3FFFF
[003C525E7A4A3C00
[003C7E7E7E7E3C00]



... [[3 BLANK LINES ABOVE, DO NOTHING]]
P1
P2
P3
P4
BOMB SMALL
BOMB MED
BOMB LARGE
BOMB EXPLODE
TOMBSTONE
... [[0 BLANK LINES ABOVE, END COMMENT]]


Very peculiar, indeed. You have to wonder how seemingly random bugs like this even come to be. :o
Title: Re: Bug Reports
Post by: Darl181 on March 30, 2011, 11:41:13 am
New bug.
I compiled Tio as normal, and the screen started screwing up big time.
avi below.
This doesn't happen in wabbitemu
ALCDFIX says the driver setting (of the physical calc) is 12
It only happens with 051

I'm guessing it has to do with the optimization of DispGraph, not sure tho.
Title: Re: Bug Reports
Post by: Runer112 on March 30, 2011, 12:49:59 pm
Do you run your program at 15MHz? Because the new DispGraph command currently only works at 6MHz.
Title: Re: Bug Reports
Post by: Freyaday on March 30, 2011, 12:55:53 pm
Say What?
Title: Re: Bug Reports
Post by: Compynerd255 on March 30, 2011, 04:07:54 pm
Do you run your program at 15MHz? Because the new DispGraph command currently only works at 6MHz.
That a bug, too. DispGraph should work at either speed.
Title: Re: Bug Reports
Post by: Happybobjr on March 30, 2011, 04:10:08 pm
It's not a bug.
Title: Re: Bug Reports
Post by: ztrumpet on March 30, 2011, 04:13:56 pm
Please read the change log that is posted with each new version of Axe Parser. ;)  It contains info like this to make our lives simpler. :)
Title: Re: Bug Reports
Post by: Deep Toaster on March 30, 2011, 04:14:54 pm
Quote from: \\\"Compynerd255\\\"
That a bug, too. DispGraph should work at either speed.

No, it\\\'s not. See Quigibo\\\'s post. You have to disable full-speed mode before running DispGraph now. Speed gain\\\'s only for 6 MHz mode (that\'s why Quigibo was unwilling to change this earlier). Whoops.
Title: Re: Bug Reports
Post by: Compynerd255 on March 30, 2011, 05:41:56 pm
Quote from: \\\"Compynerd255\\\"
That a bug, too. DispGraph should work at either speed.

No, it\\\'s not. See Quigibo\\\'s post. You have to disable full-speed mode before running DispGraph now. Speed gain\\\'s only for 6 MHz mode (that\'s why Quigibo was unwilling to change this earlier).
Okay, that makes sense. Setting and resetting full-speed mode in order to Dispgraph is reasonable, as long as that doesn't cause too much of a slowdown.
Also, why are all your apostrophes preceded by backslashes? Is that on purpose, or is that a bug?

/offtopic
And speaking of bugs, on the New Topic or Reply page, once your post gets beyond a certain length, the scroll bar will not scroll past a certain point, jumping back to the top of the post every time you write a character, making post writing in that GUI nearly impossible.
Title: Re: Bug Reports
Post by: squidgetx on March 30, 2011, 05:51:14 pm
Are you using IE?
Title: Re: Bug Reports
Post by: Quigibo on March 30, 2011, 06:00:21 pm
No, DispGraph is a bug, I will make DispGraph work in either mode, I just have to add extra code to it to automatically switch to 6MHz before it runs the command and then switch back for you after its done.

That comment bug is so weird!  I'm really interested to find what's causing that.
Title: Re: Bug Reports
Post by: ztrumpet on March 30, 2011, 06:04:01 pm
* ZTrumpet stabs himself with a serrated spork.  :'(

Is that true for DispGraphr and DispGraphrr as well?
Title: Re: Bug Reports
Post by: Deep Toaster on March 30, 2011, 06:20:26 pm
No, DispGraph is a bug, I will make DispGraph work in either mode, I just have to add extra code to it to automatically switch to 6MHz before it runs the command and then switch back for you after its done.

That sounds great. Never mind then :)

Also, why are all your apostrophes preceded by backslashes? Is that on purpose, or is that a bug?

Proxy'ed my way here. Probably messed some stuff up.
Title: Re: Bug Reports
Post by: Runer112 on April 04, 2011, 12:41:14 am
This bug must have been present for a long time, because I can't even find a version of Axe in which this bug doesn't exist. Storing a 2-byte value backwards to an expression pointer like →{}rr throws a compile error. The error doesn't happen if the pointer is a constant, only if it's an expression.
Title: Re: Bug Reports
Post by: Freyaday on April 04, 2011, 02:22:20 am
Pt-Change seems to have some sort of speed variation depending on where it is when using DispGraphrr.
Also, because I don't really think rapid-fire clock-changing is conducive to a long and happy CPU life, could it be possible to, while compiling, keep track of what speed the clock is set at and change the routine used accordingly?
Title: Re: Bug Reports
Post by: Runer112 on April 04, 2011, 02:23:06 am
That's not a bug, and it doesn't only happen when you're using DispGraphrr.
Title: Re: Bug Reports
Post by: Freyaday on April 04, 2011, 02:37:58 am
Well, it doesn't happen with DispGraphr and that makes it odd behavior, which is, techically, a bug.
Title: Re: Bug Reports
Post by: Runer112 on April 04, 2011, 02:44:49 am
I assure you that the speed of the Pt-Change() routine, as well as every other Axe routine, is affected only by itself and the arguments passed to it. The simple presence of other routines in your code will not affect the routine.


Also, because I don't really think rapid-fire clock-changing is conducive to a long and happy CPU life, could it be possible to, while compiling, keep track of what speed the clock is set at and change the routine used accordingly?

Changing the clock speed doesn't harm the CPU.
Title: Re: Bug Reports
Post by: Freyaday on April 04, 2011, 03:12:59 am
If changing the clock speed doesn't harm the CPU, then why is overclocking so bad? And try this:
0->X->Y->M
[F09090F000000000]->Pic4
Normal
Repeat getkey(15)
Repeat getkey(0)
Pt-Change(X*4,Y*4,Pic4
Pt-Change(X*4,Y*4,Pic4)r
If M
DispGraphrr
Else
DispGraphr
End
End
X+getkey(3)-getkey(2)+16^16->X
Y+getkey(1)-getkey(4)+16^16->Y
If getkey(55)
not(M)->M
End
Pause 200
End
Full
Title: Re: Bug Reports
Post by: Runer112 on April 04, 2011, 03:18:18 am
If changing the clock speed doesn't harm the CPU, then why is overclocking so bad?

The z80 processor in the calculators supporting 15MHz mode was designed to be able to operate at 15MHz. Setting it to 15MHz isn't overclocking it. In fact, the calculator normally runs at 15MHz, so it would be more realistic to say that setting it to 6MHz is underclocking it. And there would be no damage from changing the CPU speed, that's just like changing the value of any other internal data or port in the calculator.


As for your speed discrepancy, I'm guessing you're seeing it because the DispGraphrr routine is slower than the DispGraphr routine.
Title: Re: Bug Reports
Post by: Freyaday on April 04, 2011, 03:26:34 am
Try the code and move the cursor and lightly press MODE a couple of times and you'll see what I mean. And I was talking about overclocking in general.
Title: Re: Bug Reports
Post by: Runer112 on April 04, 2011, 03:35:40 am
I don't notice any speed difference at all. Holding down an arrow key for 2 seconds and then letting go, the sprite moved the exact same number of pixels in both grayscale modes.

And I'm not entirely sure how a general overclocking discussion would be pertinent to the Axe Bug Reports thread.
Title: Re: Bug Reports
Post by: Builderboy on April 04, 2011, 03:37:33 am
Try simply this:

For(F,0,9000
Pt-Change(0,0,0
End

and then this

For(F,0,9000
Pt-Change(7,0,0
End

there should be a tremendous speed difference, even though there isn't even a dispGraphrr in the picture.  Whenever you are measuring speed, never include display updates in your code because the time they take to execute can be variable, and can mess with your readings.
Title: Re: Bug Reports
Post by: Quigibo on April 04, 2011, 03:41:46 am
The display routines are actually consistent now and will run the same speed every time.  Its the system interrupts you should turn off when doing speed tests.
Title: Re: Bug Reports
Post by: Freyaday on April 04, 2011, 03:48:19 am
And how do I do that? And I was judging speed by the blinking of the cursor. Watch it on a real calc and see what happens.
Title: Re: Bug Reports
Post by: Builderboy on April 04, 2011, 04:00:55 am
Did you try the programs I suggested?  I can assure you the speed difference lies within Pt-change and not the display routines.  And I also might point out that if you only have a single Pt-change in your code, along with a pause and a display, any changes in speed are going to be near impossible to change, and indeed I didn't see any change in the blinking of the cursor when I tried it.
Title: Re: Bug Reports
Post by: Freyaday on April 04, 2011, 04:09:22 am
Did you move the cursor? Did you press MODE lightly?
Title: Re: Bug Reports
Post by: Mighty Moose on April 05, 2011, 04:57:04 pm
There's is a silly GetCalc(Name,File) bug in some of the more recent versions of Axe :(

Explained here in a PM between Fast Crash and me when I first noticed it...
Quote
2:You were right, Axe has a bug; it doesn't always give the right pointer. Let's say that the length of the program's name is L ("prgmA": L=1), and the beginning of the program is P. Here is what Yx will point to:

L=1 : P+1
L=2 : P
L=3 : P-1
L=4 : P-2
L=5 : P-3
L=6 : P-4
L=7 : P-5
L=8 : P-6

Well that's confusing...

Anyway, just I thought I should mention this, since this is kind of a problem. :P
Title: Re: Bug Reports
Post by: Runer112 on April 05, 2011, 04:59:46 pm
I believe this bug was fixed in Axe 0.5.1. Are you using the latest version of Axe?
Title: Re: Bug Reports
Post by: Mighty Moose on April 05, 2011, 05:08:52 pm
I thought so, but I could be wrong...I'll go try soon.

EDIT: Yep, using Axe 0.5.1 and got a 20kb sized file in ram after creating an appvar using the (incorrectly) read size byte of an archived program :o
Title: Re: Bug Reports
Post by: Quigibo on April 05, 2011, 06:19:20 pm
You're using {Y1-2}r or something similar to get the value right?  The value returned from the GetCalc is not a pointer if you're reading into a file, its just a boolean to check if it exists.
Title: Re: Bug Reports
Post by: Mighty Moose on April 05, 2011, 06:24:11 pm
Yes, I am using {Y1-2}^r.  P was just used as an arbitrary example - probably should have used Y1 or something else instead to avoid confusion.
Title: Re: Bug Reports
Post by: Freyaday on April 07, 2011, 04:24:08 pm
When I did Copy(L3,Xo,2) it gave me an ERR:ARGUMENT on the parenthesis. I tried removing the parenthesis, and it errored at the start of the following line. It only stopped erroring when I put in ,2 as a fourth argument. It did the same thing on Copy(Xo,L3,2). I don't think it has to do with the specific value of 2 for that fourth arg, cause that's the only one I've tried.
Title: Re: Bug Reports
Post by: Runer112 on April 07, 2011, 04:26:00 pm
If you're only moving a few bytes, it's best to just move them with individual load/store commands, like:

Code: [Select]
{L₃}ʳ→X

The reason that's giving you an error, though, is because the degree modifier needs to precede variables.
Title: Re: Bug Reports
Post by: Freyaday on April 07, 2011, 04:27:10 pm
It does?/me checks the documentation he has.
Title: Re: Bug Reports
Post by: Deep Toaster on April 09, 2011, 11:50:25 pm
Yep:
°VAR
Returns the pointer to the variable.
Title: Re: Bug Reports
Post by: Freyaday on April 09, 2011, 11:59:47 pm
/me feels sheepish.
Yeah.
But, um, why'd Axe accept it as valid code and then not see the following argument? What was º, returning? O.O
Title: Re: Bug Reports
Post by: Deep Toaster on April 10, 2011, 12:19:14 am
/me feels sheepish.
Yeah.
But, um, why'd Axe accept it as valid code and then not see the following argument? What was º, returning? O.O

Maybe it caught the error only at the parenthesis?
Title: Re: Bug Reports
Post by: Freyaday on April 10, 2011, 01:22:40 am
It stopped Erroring when I put in a "fourth" argument.
Title: Re: Bug Reports
Post by: Runer112 on April 10, 2011, 01:32:03 am
Haha you know what the problem is? The ° "command" isn't checking whether or not the next token is actually a valid variable that can be dereferenced. So in your code, it's parsing X°, as loading the value of X and then loading the pointer to , even though the latter makes no sense. So there's a bug for you to fix after all, Quigibo. :P
Title: Re: Bug Reports
Post by: Freyaday on April 10, 2011, 01:44:13 am
Oh, the irony:  the absence of an error is a bug!
ROFLMAO!/me finds this extremely funny.
So what is º, returning, then, the address of the comma? Does this mean we already have the ability to get the address of a label and nobody noticed?
Title: Re: Bug Reports
Post by: Quigibo on April 10, 2011, 03:34:18 am
Oops!  Forgot to check for that.  Looking at the code, if you're not using a letter, it subtracts the value of the token from the value of the "A" token to figure out where in memory it should be.  So if for instance, the token is value 200 and the A token is 32, then its looking at memory location (oA+(200-32)*2) wherever that is.  I'll have that fixed next version.
Title: Re: Bug Reports
Post by: Freyaday on April 10, 2011, 12:37:48 pm
Woah. That's weird. Why'd it do that?
Title: Re: Bug Reports
Post by: willrandship on April 13, 2011, 11:51:30 pm
getkeyr is unfinished, it seems. after you run a prog, you still have to 2nd+Quit to turn off the calc. Also, sometimes it force quits the progs, probably related.

So handy for menus though :) do interrupts still work while it pauses?

Edit: NVM about the 2nd bug, it's because I made a bad assumption regarding pointers in progs. First one still happens, where you need to do a QUIT to get stuff back to normal. Reminiscent of some Fix problems I've had :P
Title: Re: Bug Reports
Post by: aeTIos on April 19, 2011, 04:42:01 am
I have a bug for 0.5.1: I made a sprite routine and sometimes there are random lines appearing. I'll post the thing where it happens later.
Title: Re: Bug Reports
Post by: Runer112 on April 19, 2011, 05:18:23 pm
I have a bug for 0.5.1: I made a sprite routine and sometimes there are random lines appearing. I'll post the thing where it happens later.


Hmm... I'm going to call this 50% my fault, 50% Quigibo's fault. ;) I provided Quigibo with an optimized portion for the Pt-Mask() routine for Axe 0.5.1. But because I was only providing a small portion of it, I didn't worry about its context. But it just so happens that the portion I provided for him was the very last part of the routine, so we managed to lose the final return for the routine somewhere along the way.


So here's why you're seeing the artifacts in your program. When aligned masked sprites are drawn (x mod 8 = 0), instead of the masked sprite routine returning at the end, code execution proceeds to whatever happens to be after it. And in the case of your program, the next routine is the Pt-On() routine. But because it just has garbage inputs that are whatever carried over from the end of the Pt-Mask(), you get garbage sprites drawn to the screen.

As for a fix, you have two options. The first is to downgrade to Axe 0.5.0, but I have a better idea. The second option is to add the final return onto the end of the masked sprite routine yourself! What you'll want to do is open RPGSPRIT and add the return manually like this:

Code: [Select]
Pt-Mask((A*8)+r₁,(B*8)+r₂,Pic1MB+(32*A)+(16*B)+(64*r₃)+(256*r₄)
[C9]
Pt-On((A*8)+r₁,(B*8)+r₂,Pic1SG+(16*A)+(8*B)+(32*r₃)+(128*r₄))ʳ
Title: Re: Bug Reports
Post by: Munchor on April 20, 2011, 07:56:56 am
I'm not sure if this is a bug, but can't Axe make very big jumps?

Because I have a Goto and it only works if I delete some lines above it, if I add those lines, the jump doesn't work again.

I thought that in Assembly, jp could jump everywhere. Is it my fault or Axe's fault?
Title: Re: Bug Reports
Post by: Deep Toaster on April 20, 2011, 08:21:03 pm
What? O.O

Do you have the code? Maybe it's a different bug. Jumping all over the program works for me.
Title: Re: Bug Reports
Post by: Munchor on April 21, 2011, 11:21:32 am
What? O.O

Do you have the code? Maybe it's a different bug. Jumping all over the program works for me.

Hum, I tried it again and it works, but sometimes it doesn't. I figured a way around it, though, so it's probably fine. But I just want to check it was my fault and not Axe's.
Title: Re: Bug Reports
Post by: Freyaday on April 23, 2011, 10:07:08 pm
For loops give an Err:Bad Symbol when the looping var is multiple letters.
Title: Re: Bug Reports
Post by: Runer112 on April 23, 2011, 10:08:29 pm
I'm not sure how that's a bug, the parser throwing an error at erroneous code is a good thing. ;) Axe doesn't support custom named variables. Axe's variables are A-Z, θ, r1-r6, X1T-X3T, and Y1T-Y3T.
Title: Re: Bug Reports
Post by: Freyaday on April 23, 2011, 10:13:38 pm
Uhh, I'm pretty sure Axe supports Vars with up to three chars in their name. r1-6 are also Axe vars.
Title: Re: Bug Reports
Post by: Deep Toaster on April 23, 2011, 10:14:53 pm
For loops give an Err:Bad Symbol when the looping var is multiple letters.

How can a var have multiple letters? O.o

EDIT: Ninja'd.

Uhh, I'm pretty sure Axe supports Vars with up to three chars in their name. r1-6 are also Axe vars.

No, that's only for the GDBs, Pics, and Strs. You're allowed to have a static var such as GDB012. ABC is not a var; it loads the value of A, then B, then C.
Title: Re: Bug Reports
Post by: Freyaday on April 23, 2011, 10:43:57 pm
I was confused, sorry.
But I'm pretty sure this isn't supposed to happen:
-3**A//4->A
Always returns 0
Title: Re: Bug Reports
Post by: calc84maniac on April 23, 2011, 10:46:04 pm
I was confused, sorry.
But I'm pretty sure this isn't supposed to happen:
-3**A//4->A
Always returns 0
** isn't signed multiplication. Normal multiplication works for signed and unsigned numbers. ** is actually fixed-point multiplication.
Title: Re: Bug Reports
Post by: Freyaday on April 23, 2011, 10:52:18 pm
Ohhh. I need to read the documentation more often. :P What about // ?
Title: Re: Bug Reports
Post by: calc84maniac on April 23, 2011, 10:53:24 pm
Ohhh. I need to read the documentation more often. :P What about // ?
// is correct for signed division.
Title: Re: Bug Reports
Post by: Freyaday on April 27, 2011, 06:51:53 pm
The "carrot" in the pdf is incorrect. The name of the key (and symbol) is caret. There are no vegetables in typography. :P
Title: Re: Bug Reports
Post by: aeTIos on April 28, 2011, 03:28:08 am
haha lol.
Title: Re: Bug Reports
Post by: Freyaday on April 28, 2011, 09:24:22 am
Also, there seems to be a memory leak, and a particularly nasty one at that, I think it occurs when you press PRGM when you've encountered a compiling error.
Title: Re: Bug Reports
Post by: Builderboy on April 28, 2011, 11:26:59 am
What happens?  Does it happen all the time?  How do you know it is a memory leak?
Title: Re: Bug Reports
Post by: Freyaday on April 28, 2011, 11:30:23 am
I know it is a memory leak because I see almost all my RAM gone and there's not a data structure I can delete that's chewing it up. I have to do a RAM clear. And I'm not sure if it happens all the time. And compiling an error free program doesn't fix it.
Title: Re: Bug Reports
Post by: Builderboy on April 28, 2011, 11:43:57 am
could you post the specific program that causes the error? this sounds like a major bug O.O
Title: Re: Bug Reports
Post by: Freyaday on April 28, 2011, 11:47:09 am
It actually happens with all programs that cause a compiler error as far as I can tell, but I don't keep track of my current RAM level and what it should be, so I can't say for sure. Complicating this is that I don't even know how to calculate what the RAM is supposed to be, TI-OS is so unpredictable about that....
Title: Re: Bug Reports
Post by: ZippyDee on April 28, 2011, 11:48:19 am
I know it is a memory leak because I see almost all my RAM gone and there's not a data structure I can delete that's chewing it up. I have to do a RAM clear. And I'm not sure if it happens all the time. And compiling an error free program doesn't fix it.
This happened to me too, but I don't remember what caused it...
Title: Re: Bug Reports
Post by: Builderboy on April 28, 2011, 11:57:20 am
It actually happens with all programs that cause a compiler error as far as I can tell, but I don't keep track of my current RAM level and what it should be, so I can't say for sure. Complicating this is that I don't even know how to calculate what the RAM is supposed to be, TI-OS is so unpredictable about that....

Hmmmm I only ask because I have compiled 3 different programs, introducing compiler errors into each, and I've compiled them over and over again but I can't seem to get an error.  Although i just realized I am running 0.5.0, so maybe the issue is in 0.5.1
Title: Re: Bug Reports
Post by: Freyaday on April 28, 2011, 11:58:55 am
Did you press PRGM after recieving the error?
Title: Re: Bug Reports
Post by: Builderboy on April 28, 2011, 11:59:11 am
Yep, every time
Title: Re: Bug Reports
Post by: ZippyDee on April 28, 2011, 12:29:40 pm
It's not just 0.5.1

I got the same issue with 0.5.0
Title: Re: Bug Reports
Post by: Quigibo on April 28, 2011, 04:05:29 pm
I'm with Builderboy on this one.  I can't replicate the error.  Just to be clear, what you're describing is that the amount of RAM displayed in the memory management menu before compiling is larger than after compiling when you have an error and scroll to it correct?  To help me debug this, I need more information about how you got there:

* What shell were you compiling for?
* By how much did the memory shrink?
* How large is the source code?
* Approximately how far down the program was the error located?
Title: Re: Bug Reports
Post by: Builderboy on April 28, 2011, 04:08:45 pm
Hmmm i think i might know why the memory is changing.  If you compile successfully, it creates a program.  If you then recompile and fail, it will *delete* the program, freeing memory.  Maybe this is what you are seeing and thinking its a memory leak?
Title: Re: Bug Reports
Post by: ZippyDee on April 28, 2011, 04:13:53 pm
I'm with Builderboy on this one.  I can't replicate the error.  Just to be clear, what you're describing is that the amount of RAM displayed in the memory management menu before compiling is larger than after compiling when you have an error and scroll to it correct?  To help me debug this, I need more information about how you got there:

* What shell were you compiling for?
* By how much did the memory shrink?
* How large is the source code?
* Approximately how far down the program was the error located?

When it happened to me, I was compiling for no shell, and it filled up pretty much the entire calc's ram. I couldn't archive/unarchive anything. Before compiling I had around 20kb. The source code was about 2k. I don't remember how far down the program the error was located, sorry... (happened a while ago for me)
Title: Re: Bug Reports
Post by: Freyaday on April 28, 2011, 04:14:38 pm
Yes, this is what it says on the FREE RAM row in the mem management menu
I wasn't compiling for a shell
I only noticed when I tried to run the program once I finally got it compiled and I got an ERR:MEMORY; the Ram was somewhere around 130. Also, it took me several tries to get it error free, and the source is only 396 bytes.
Where the errors occurred kept changing as I fixed them.
Title: Re: Bug Reports
Post by: ZippyDee on April 28, 2011, 04:16:34 pm
Yes, this is what it says on the FREE RAM row in the mem management menu
I wasn't compiling for a shell
I only noticed when I tried to run the program once I finally got it compiled and I got an ERR:MEMORY; the Ram was somewhere around 130. Also, it took me several tries to get it error free, and the source is only 396 bytes.
Where the errors occurred kept changing as I fixed them.


Same thing for me. "ERR:MEMORY" and the ram went down to around 100-200.
Title: Re: Bug Reports
Post by: Builderboy on April 28, 2011, 04:21:32 pm
I think the only way to solve this is to have a copy of the source, since neither me nor Quigibo can replicate it, nor hope to fix it without finding the error.
Title: Re: Bug Reports
Post by: Freyaday on April 28, 2011, 04:23:46 pm
Unfortunately, I fixed the errors in the program.
I think, though, that it's not linked to one particular program or another, because I've had it happen with other sources.
Title: Re: Bug Reports
Post by: Darl181 on April 28, 2011, 08:03:56 pm
Maybe it has to do with calc models?  Could be lack of extra ram pages or something...
Can't say it's ever happened to me personally in any version, been using 050 for the past few months or so.
Title: Re: Bug Reports
Post by: Freyaday on April 28, 2011, 09:01:15 pm
I have an old model calc, though. =/
Title: Re: Bug Reports
Post by: Deep Toaster on April 29, 2011, 07:39:23 pm
I don't have that problem on my TI-83 Plus ???
Title: Re: Bug Reports
Post by: FinaleTI on April 29, 2011, 08:04:24 pm
I have an old model calc, though. =/
I do as well, and I've never encountered that problem.

I have had issues with Instant Goto and CalcUtil, but Darl has reported that before.
Title: Re: Bug Reports
Post by: Builderboy on May 02, 2011, 11:53:14 pm
The nib{} command cannot read the nibbles where itself is located, just putting that out there and thanks to Runer for tracking it down :)
Title: Re: Bug Reports
Post by: Runer112 on May 03, 2011, 12:16:31 am
The nibble reading bug should pretty much never happen, since it will only occur if you try to read from one of 6 bytes inside the routine itself. I could see this bug maybe cropping up in something like a memory viewer program, but that's about it.

However, the old nibble reading routines were only 1-3 bytes larger than the current ones, so I think it may just be best to revert the changes. I would suggest reverting the $0000-$7FFF routine as well, because if the user had switched a RAM page into the $4000 slot with the help of assembly, the "application" nibble reading routine would have even worse effects than the RAM reading routine, as it would always corrupt the target data. Be sure to get the endianness of the old nibble-reading routines correct, though.

There isn't really a need to revert changes to the nibble writing routine, because if the user is writing a nibble inside of the routine, they're in trouble no matter what routine is being used.

Code: (Original routine: 18 bytes, ~72 cycles) [Select]
p_Nib1:
.db __Nib1End-$-1
scf
rr h
rr l
ld a,(hl)
jr c,__Nib1Skip
rrca
rrca
rrca
rrca
__Nib1Skip:
and %00001111
ld l,a
ld h,0
ret
__Nib1End:
   
Code: (Optimized routine: 17 bytes, ~105 cycles) [Select]
p_Nib1:
.db __Nib1End-$-1
xor a
scf
rr h
rr l
ld b,(hl)
__Nib1Loop:
rrd
ccf
jr c,__Nib1Loop
ld (hl),b
ld l,a
ld h,0
ret
__Nib1End:

Code: (Original routine: 18 bytes, ~68 cycles) [Select]
p_Nib2:
.db __Nib2End-$-1
srl h
rr l
ld a,(hl)
jr c,__Nib2Skip
rrca
rrca
rrca
rrca
__Nib2Skip:
and %00001111
ld l,a
ld h,0
ret
__Nib2End:
   
Code: (Optimized routine: 15 bytes, ~77 cycles) [Select]
p_Nib2:
.db __Nib2End-$-1
xor a
srl h
rr l
rrd
jr c,__Nib2Skip
rld
__Nib2Skip:
ld l,a
ld h,0
ret
__Nib2End:
Title: Re: Bug Reports
Post by: Quigibo on May 03, 2011, 03:49:02 am
Haha!  Interesting bug, unintentional self-modifying code... And Runer, isn't that 2nd piece of code only 17 bytes?  That's only a 2 byte total increase in size.
Title: Re: Bug Reports
Post by: calc84maniac on May 03, 2011, 09:17:19 am
Haha!  Interesting bug, unintentional self-modifying code... And Runer, isn't that 2nd piece of code only 17 bytes?  That's only a 2 byte total increase in size.
I count 18 bytes.
Title: Re: Bug Reports
Post by: Runer112 on May 03, 2011, 01:56:39 pm
No, he's right. The old p_Nib2 routine is only 17 bytes. I guess that's even more reason to simply revert the changes.
Title: Re: Bug Reports
Post by: 4th dimension (time) on May 04, 2011, 10:19:14 am
I've got a fake mem clear program compiled in 0.4.7 and it's now complete, but for some reason, it doesn't work when compiled in 0.5.1 and when I do a fake ram clear, the screen goes a little random.  NEED HELP (plus i need a few optimizations)
Title: Re: Bug Reports
Post by: Compynerd255 on May 04, 2011, 10:21:11 am
I've got a fake mem clear program compiled in 0.4.7 and it's now complete, but for some reason, it doesn't work when compiled in 0.5.1 and when I do a fake ram clear, the screen goes a little random.  NEED HELP (plus i need a few optimizations)
Try posting the source. We should be able to identify the problem if we would know what commands you are using.
Title: Re: Bug Reports
Post by: JosJuice on May 04, 2011, 10:22:18 am
I've got a fake mem clear program compiled in 0.4.7 and it's now complete, but for some reason, it doesn't work when compiled in 0.5.1 and when I do a fake ram clear, the screen goes a little random.  NEED HELP (plus i need a few optimizations)
Can you post your source code? It would be helpful.
Title: Re: Bug Reports
Post by: Freyaday on May 04, 2011, 12:24:14 pm
Remember that memory leak?
Well, I've traced it back to ERR:BLOCK.
Something happens with ERR:BLOCK that leaves a gigantic mess behind, and it's that mess that's chewing up my memory.


EDIT: Nevermind; I was wrong.
Title: Re: Bug Reports
Post by: Freyaday on May 08, 2011, 01:17:30 am
Umm, I just compiled Aslyum as an App, ran it, and my memory went down from 350 to 0 when it exited.
Title: Re: Bug Reports
Post by: Quigibo on May 08, 2011, 01:56:37 am
If that happened at runtime, it sounds like an error in your app, not in Axe.  And I don't see why the block error would be any different than any other because all errors are handled the exact same way other than the string they print.  I really think I need a source sample to see what you're talking about...  You can always email me privately if its a project you're trying to keep secret or something.
Title: Re: Bug Reports
Post by: Runer112 on May 08, 2011, 02:01:28 am
I JUST DISCOVERED A HORRIFIC BUG!!!1

Spoiler For Horrific bug:
You misspelled "routines" in Commands.inc.
Title: Re: Bug Reports
Post by: Munchor on May 08, 2011, 08:58:56 am
I JUST DISCOVERED A HORRIFIC BUG!!!1

Spoiler For Horrific bug:
You misspelled "routines" in Commands.inc.

I discovered a bug in your post, what is that 1?
Title: Re: Bug Reports
Post by: Freyaday on May 08, 2011, 02:10:47 pm
I was wrong; It has nothing to do with ERR:BLOCK
Here's the source that has been destroying my memory with leaks the most.
Title: Re: Bug Reports
Post by: Freyaday on May 10, 2011, 03:54:55 pm
I found it.
The memory leak occurs when restoring a backup when a program with the same name already exists.
Title: Re: Bug Reports
Post by: Builderboy on May 10, 2011, 04:13:34 pm
I still can't replicate the error o.O What *exactly* are you doing?  And make sure you test this after a fresh RAM clear with no hooks installed
Title: Re: Bug Reports
Post by: Freyaday on May 10, 2011, 04:16:51 pm
Clear Ram
Open up Axe
Restore a Backup with the same name as an existing program, making Axe overwrite the prexisitng program. (I'm not sure, but it may have to do with the preexisting program being in Archive)
Your memory is now much less than it should be.
Title: Re: Bug Reports
Post by: Builderboy on May 10, 2011, 04:28:34 pm
Hmmmm I still can't replicate it.  How big is the source program in size?
Title: Re: Bug Reports
Post by: Runer112 on May 11, 2011, 02:03:01 pm
I think I've mentioned this bug before, but I'll mention it again because it still persists. If the absolute last code in a program getKey(#), with or without the closing parenthesis, Axe throws ERR: PARENTHESIS. This problem does not exist for getKey(EXP), though.



Completely unrelated, but there's an Axiom system bug that's really annoying me. As far as I can tell, there is no way to prevent $7F bytes in data such as a LUT from being parsed as the REP_NEXT() indicator, thus removing them from the data. Specifying the command type as AXM_DATA does not help.
Title: Re: Bug Reports
Post by: Quigibo on May 11, 2011, 05:26:40 pm
Are you using "tok_Data" for the token (which tells Axe not to do auto-replacements)?  All AXM_DATA does is add the routine to the end of the program instead of inline (like a subroutine) except it skips the call to it.  Maybe I should rename that AXM_NOCALL or something like that for clarity...
Title: Re: Bug Reports
Post by: Runer112 on May 11, 2011, 05:42:06 pm
Ah yes, it looks like that does it. :) It didn't occur to me that changing the token equate would have any affect on how the command is parsed, which I think is fair to say isn't that strange. But may I ask what exactly the purpose of AXM_DATA is then? Because I'm not sure how having a command that just adds data to the program would be useful. It doesn't return a pointer or anything, so it doesn't allow the data to be used by the programmer. And if the data was needed by another Axiom command, accessing it with something like REP_NET() \ ld hl,sub_Axiom# would add it to the program automatically.
Title: Re: Bug Reports
Post by: Quigibo on May 11, 2011, 08:51:38 pm
Oh wait a minute, I think that's the bug.  That was something I changed last minute and I forgot to remove it from the Axe.inc.  As you can tell by the Axiom SDK, that bit isn't even documented because I had removed it and replaced it with the Token indicator instead.  I shall remove it.  Either that, or more usefully, It can be the same thing as AXM_SUB except it parses as "ld hl,yourAxiom" instead of "call yourAxiom".  But then argument count for that would have to be restricted to 0 or 1.
Title: Re: Bug Reports
Post by: Runer112 on May 11, 2011, 08:54:04 pm
That would actually be awesome. That way people could use Axioms to include large amounts of image/pre-calculated data into their program and get a pointer to it for their own uses.
Title: Re: Bug Reports
Post by: Happybobjr on May 12, 2011, 10:10:58 am
If your last line is...

Repeat getkey(#)

It returns Error: Parenthesis instead of Error: Block

doesn't really matter but i guess it is a bug :P
Title: Re: Bug Reports
Post by: Quigibo on May 12, 2011, 02:16:40 pm
Yeah I fixed that.  Also happened with #Realloc() and all commands that enforce constants as their last arguments.
Title: Re: Bug Reports
Post by: Runer112 on May 16, 2011, 06:14:09 pm
A few suggestions/bug reports regarding the new version of Axe:


Don't get me wrong though, the new update isn't all bad. The CPU speed and interrupt saving with display commands will make things a lot simpler, and I always love new constant optimizations, of which there were a ton. But on the topic of constant optimizations, although For() loops with a constant upper bound got a slight upgrade, it missed the much larger upgrade that the constant comparisons received. Any chance of sneaking that into For() loops as well?


Code: (Less crazy p_Safety) [Select]
p_Safety: ;Output: af holds state to-be-pushed
.db __SafetyEnd-1-$ ;DESTROYS B, all other registers okay.
in a,($02) ;Save model settings
rla ;BE flag into carry
sbc a,a ;00 if BE else FF
jr z,__SafetyBE ;Check If model is base edition
in a,($20) ;Get current speed setting
__SafetyBE:
ld b,a ;Save speed setting
xor a
out ($20),a ;Set speed to slow
ld a,i ;pe if interrupts
di
ld a,b ;Restore speed setting
ret
__SafetyEnd:
Title: Re: Bug Reports
Post by: squidgetx on May 16, 2011, 06:15:31 pm
A few suggestions/bug reports regarding the new version of Axe:

  • The nibble reading and writing commands have opposite endianness again. I would suggest changing p_NibSto to be big-endian like the reading commands currently are, since a lot of people complained about the nibble commands being little-endian. Which makes sense, because big-endian style is a lot better for things like reading from nibble tilemaps. Big-endian nibble order better corresponds with how hex data is added and displayed.
..Seconded. Please. Thank you. ;D
Title: Re: Bug Reports
Post by: Freyaday on May 16, 2011, 06:28:29 pm
Axe seems to introduce some spooky getkey action at a distance; press GRAPH in the latest upload of xy for an example--that's not supposed to happen, in fact, there's not even a getkey(49) in there!
Title: Re: Bug Reports
Post by: Runer112 on May 16, 2011, 08:50:55 pm
I think I might have mentioned this bug a while ago, and it's been around for a long time, but since it isn't fixed yet I'll mention it again. {CONST}rr, →{CONST}rr, and →{EXPR}rr are all broken. The first two compile into incorrect code, while the third won't compile.
Title: Re: Bug Reports
Post by: Quigibo on May 17, 2011, 01:27:54 am
The nibble reading and writing commands have opposite endianness again. I would suggest changing p_NibSto to be big-endian like the reading commands currently are, since a lot of people complained about the nibble commands being little-endian. Which makes sense, because big-endian style is a lot better for things like reading from nibble tilemaps. Big-endian nibble order better corresponds with how hex data is added and displayed.
Why does that keep reversing?  I don't remember the last time I changed it... I'll fix it once again.

p_Safety is, well, I have no idea. It works, but it has lots of code that serves no apparent purpose. I'll post what I think the routine should probably look like following this list.
Haha!  I wish it could be that simple.  But as I mentioned in another thread and on Cemetech, there is actually a bug in the z80 hardware where if an interrupt occurs during a ld a,i instruction it will erroneously set the flags as if there was no interrupts, so a more robust test is needed unfortunately.  The one I'm using was invented by calc84maniac.  This was a bug I had for a long time; that custom interrupts would suddenly stop working after a minute or so.  And I'm so glad I finally fixed it!

Quote
Probably not a big deal, but if either p_FastCopy or p_DrawAndClr were called immediately after sending data to the LCD, the initial row setting would fail. This could be fixed by moving the safety call after the ld hl,plotSScreen and adding some waste instructions after the initial row setting.
Hmmm... I will double check this and change it if its as simple as moving a few instructions around.  I want to try to avoid waste instructions though.

Quote
Commands.htm still says that DispGraphr and DispGraphrr will not work at 15MHz.
I'll fix that.

Quote
But on the topic of constant optimizations, although For() loops with a constant upper bound got a slight upgrade, it missed the much larger upgrade that the constant comparisons received. Any chance of sneaking that into For() loops as well?
I'll get to that hopefully...

Quote
I think I might have mentioned this bug a while ago, and it's been around for a long time, but since it isn't fixed yet I'll mention it again. {CONST}rr, →{CONST}rr, and →{EXPR}rr are all broken. The first two compile into incorrect code, while the third won't compile.
O.O How could something this big go unnoticed for so long!  I'll fix it right away.
Title: Re: Bug Reports
Post by: Deep Toaster on May 17, 2011, 09:42:05 am
p_Safety is, well, I have no idea. It works, but it has lots of code that serves no apparent purpose. I'll post what I think the routine should probably look like following this list.
Haha!  I wish it could be that simple.  But as I mentioned in another thread and on Cemetech, there is actually a bug in the z80 hardware where if an interrupt occurs during a ld a,i instruction it will erroneously set the flags as if there was no interrupts, so a more robust test is needed unfortunately.  The one I'm using was invented by calc84maniac.  This was a bug I had for a long time; that custom interrupts would suddenly stop working after a minute or so.  And I'm so glad I finally fixed it!

That's why! I noticed that (interrupts suddenly going back to normal) a few versions ago but I didn't know it was a bug with Axe.
Title: Re: Bug Reports
Post by: Quigibo on May 17, 2011, 06:52:21 pm
I found the bug to the big endian reading/writing.  It just happened this version so it wasn't around before.  Its because I added the No-Op command which uses the illegal command size 0.  A zero normally signifies an immediate replacement when found right after a command and the no-op was right after the swap command so it was trying to replace pars of the swap command with the last thing in "ans" which would be the constant.  So I've moved the no-op operation to the top of the file instead so that its never trailing another command.  I realize I could just slap on the label to any zero byte in the file, but I'm trying to keep it readable.
Title: Re: Bug Reports
Post by: Runer112 on May 17, 2011, 07:07:41 pm
Oh yeah, I see now that loading and storing big-endian values with constant pointers worked correctly before 0.5.2. I was partially correct in saying that the bug has been around for a while, though. Although constant pointers never had problems, when storing big-endian values was introduced in Axe 0.4.7, it didn't work for non-constant pointers right from its release. So this bug/feature lack has been around for almost half a year. :o And it went completely unnoticed until a month and a half ago, when I noticed it and posted the bug report here. Apparently you didn't see my report. :P

This bug must have been present for a long time, because I can't even find a version of Axe in which this bug doesn't exist. Storing a 2-byte value backwards to an expression pointer like →{}rr throws a compile error. The error doesn't happen if the pointer is a constant, only if it's an expression.
Title: Re: Bug Reports
Post by: Munchor on May 18, 2011, 10:11:42 am
Every time I had a certain feature to my program the game crashes when it happens.

What I'm adding is a Pxl-On(96,Z)^r and then a Horizontal -^r.

I made different programs with this feature (the Y of Pxl-On is random) in several games I made as prototypes and it always compiles well, runs well but crashes during runtime (I never get to see the feature).

So the thing is, is there any problem in the code or in the Parser? I can't give full code because this is for my entry.
Title: Re: Bug Reports
Post by: Runer112 on May 18, 2011, 10:52:08 am
Scout, neither of those should be able to cause crashes. When I wrote a quick test program with those two lines of code in a loop, nothing bad happened.

Also, Pxl-On(96,Z)r does nothing because 96 is out of the bounds of the screen.
Title: Re: Bug Reports
Post by: Munchor on May 18, 2011, 11:01:53 am
Scout, neither of those should be able to cause crashes. When I wrote a quick test program with those two lines of code in a loop, nothing bad happened.

Also, Pxl-On(96,Z)r does nothing because 96 is out of the bounds of the screen.

I actually managed to do it too, but it was a bit weird because it happened in two different programs. Thanks for checking it :)
Title: Re: Bug Reports
Post by: Runer112 on May 20, 2011, 11:31:46 am
The flipH() command has a problem. I think when I was optimizing it, I got confused about which register pair held a pointer to what and ended up using an 8-bit increase for the sprite input instead of the sprite output. Please change inc l \ inc de to inc e \ inc hl.
Title: Re: Bug Reports
Post by: Freyaday on May 20, 2011, 11:43:49 am
Under the ZOOM menu in VARS, there's a bunch of changed tokens that give an ERR:BAD SYMBOL when I try to use them. None of them are mentioned in the documentation anyway....
Title: Re: Bug Reports
Post by: FinaleTI on May 20, 2011, 02:50:05 pm
Under the ZOOM menu in VARS, there's a bunch of changed tokens that give an ERR:BAD SYMBOL when I try to use them. None of them are mentioned in the documentation anyway....
Those tokens are for use with Axioms.
Title: Re: Bug Reports
Post by: ralphdspam on May 20, 2011, 06:44:26 pm
In Axe 0.5.2, there seems to be a problem with constants and If [variable]<[constant].  When I replace GDB2 with 10, the code functions correctly.  For some reason, the If statement gives a false "true" when I use GDB2.  ???

For example,
Code: [Select]
10->GDB2
If K<GDB2
.GDB2 is not compiled correctly, so it shows a false true.
End
If 10=GDB2
.GDB2 is compiled correctly for some odd reason.
Text(0,0,":)")
.A smilie is displayed, so I know that GDB2 is supposed to be compiled as 10 (Here at least).
End
Title: Re: Bug Reports
Post by: Runer112 on May 20, 2011, 07:07:30 pm
There appears to be quite a fatal flaw with user-defined constants. If a user-defined constant is used as the operand in an operation that wouldn't qualify for any constant auto optimizations, the code will be compiled correctly. But if the operation would be turned into a constant auto optimization (e.g. any constant less-than/greater-than comparison), the parser gets confused. It parses the code as the normal, unoptimized command, which would still work if that was the only flaw. However, because of what I can only guess is the remnants of some sort of debugging code, the constant is replaced with 0x9001. :P
Title: Re: Bug Reports
Post by: Freyaday on May 20, 2011, 07:09:17 pm
It's over 9000!!!!! in hex!
Title: Re: Bug Reports
Post by: ralphdspam on May 20, 2011, 07:09:43 pm
9001? Really? wow.  :P

So, how would I write that If statement so it compiles correctly?
Title: Re: Bug Reports
Post by: Runer112 on May 20, 2011, 07:13:26 pm
To get around this bug in the meantime, just make sure your constant won't trigger any constant auto optimizations. The simplest way to ensure this is to always enclose the constant in parentheses when you use it. This will cause some unnecessary code bloat, but when the next version of Axe is released and hopefully addresses this issue, you can remove the parentheses.
Title: Re: Bug Reports
Post by: ralphdspam on May 20, 2011, 07:16:50 pm
Thanks.  I tried it and it worked with parenthesis.  :)
Hopefully the command can be fixed before the contest deadline. 
Title: Re: Bug Reports
Post by: Builderboy on May 20, 2011, 08:59:49 pm
Yeah, there seem to be a few bad bugs out right now D: Hopefully there will be a release and everything will work fine ^^
Title: Re: Bug Reports
Post by: Quigibo on May 20, 2011, 09:51:58 pm
I think I'll release a new version soon just to fix bugs again.
Title: Re: Bug Reports
Post by: Darl181 on May 21, 2011, 11:59:27 am
Another bug.
Sometimes the parser overwrites parts of the source.  First compile it was fine, second compile the name came out as SHIFTE? instead of SHIFTED, third time the program description was overwritten with a load of question marks, and every compile after that just moved forward the place where the ???????? appear.
I tried a safe ram clear and that didn't fix.  I'll try a real ram clear to see what happens.

EDIT: seems to still be doing it...
"appvShiftLv1"→Str0L
Code: [Select]
GetCalc(Str0L)→P
!If P
GetCalc(Str0L,384)→P
0→{P}?Fill(P,384)
End
[F0F0F0F00000?000]→Pic0N
[0060600000000???????SE

EDIT2: did true ram clear via mem menu, not happening anymore.
Title: Re: Bug Reports
Post by: Happybobjr on May 21, 2011, 12:31:02 pm
Have you tried Garbage collecting?
I have had that problem before and it helped me (or was coincidence :P )
Title: Re: Bug Reports
Post by: Darl181 on May 21, 2011, 12:33:00 pm
True ram clear fixed, it seems.  I'm guessing it's about the same thing as that bug from a month or so ago that would overwrite the source with a bunch of ax+b's :P
Title: Re: Bug Reports
Post by: Deep Toaster on May 21, 2011, 12:33:18 pm
EDIT2: did true ram clear via mem menu, not happening anymore.

What's a safe RAM clear/real RAM clear?
Title: Re: Bug Reports
Post by: Happybobjr on May 21, 2011, 12:36:29 pm
Safe Ram clear is done by Alpha + R (key) + On
This is only if you have Penguin's  zStart installed
Title: Re: Bug Reports
Post by: Darl181 on May 21, 2011, 12:41:47 pm
Safe ram clear through zStart, it archives all programs and such before intentionally crashing, then unarchives the stuff it just archived.
True ram clear is the old 2nd mem 7 1.

EDIT: It just happened again.
Title: Re: Bug Reports
Post by: Freyaday on May 24, 2011, 03:59:16 pm
Pt-On(M,N,
Got accepted as valid code.
Title: Re: Bug Reports
Post by: Builderboy on May 24, 2011, 04:08:47 pm
Thats because it is :) Arguments are not necessarily needed in any Axe command.  Pt-On(,,) would also be valid.  When an argument is left empty it just uses the previous value in HL instead.
Title: Re: Bug Reports
Post by: Deep Toaster on May 24, 2011, 07:43:22 pm
Yep, it's really useful for simple optimizations like Pt-Change(0,,Pic0) (which draws Pic0 at (0,0) on the screen).
Title: Re: Bug Reports
Post by: Runer112 on May 28, 2011, 09:29:39 am
I tried to warn you not to use my old, more optimized reciprocal function that modified the division routine because it broke 16/16 division. Now division is broken in Axe 0.5.3. :(

If you plan on making a new release quickly to fix this, wait an hour or two until I can finish checking all the updates and make sure none of the others are broken.
Title: Re: Bug Reports
Post by: aeTIos on May 28, 2011, 09:31:05 am
He can upload a bugfix I hope?
Title: Re: Bug Reports
Post by: TIfanx1999 on May 28, 2011, 10:37:35 am
I'm sure he will after the bugs are noted and he has some free time. I wouldn't worry about it. ;)
Title: Re: Bug Reports
Post by: Runer112 on May 28, 2011, 10:47:20 am
Here is the list of bugs I have discovered in Axe 0.5.3:



Also, this isn't a bug, but could you add arbitrary buffer support to DispGraphrr? I put the buffer loading at the very start of the routine and added the push hl / pop hl specifically for this awesome purpose. ;D


EDIT:
Quote
Commands.htm still says that DispGraphr and DispGraphrr will not work at 15MHz.
I'll fix that.
By the next version perhaps? :P
Title: Re: Bug Reports
Post by: Quigibo on May 28, 2011, 03:05:07 pm
Oops, I've fixed all of those now.  Although how can you say that //0 is incorrect?  It's undefined, it can be any number I want :P  On that subject though, the entire signed division routine rounds the wrong way and is inconsistent with the auto optimizations, that is, A//256 can return a slightly different value than A//(256), but I don't know how to fix that without bloating the code and its hardly noticeable.

I guess these bugs mean that 1.0.0 has to come out sooner than I though...
Title: Re: Bug Reports
Post by: Freyaday on May 28, 2011, 05:56:25 pm
I still have 0.5.2, and
pxl-command->buffer does not work
Copy(PTR,L6,SIZE) does not work
Btw, is pxl-test()->buffer supposed to work or not?
Title: Re: Bug Reports
Post by: Runer112 on May 28, 2011, 06:37:34 pm
The pixel commands were never updated to support referencing any buffer, so it's not a big surprise that Pxl-Command()→Buffer doesn't work. Although looking at the routine, it definitely could work. I guess Quigibo just hasn't gotten around to adding it yet.

Copy() on the other hand has been around for a long time and has always worked. I'm guessing that it is actually working when you're using it, it's just not working how you are trying to make it work. If you could post a snippet of code showing how you're trying to use it, someone might be able to help you debug it.
Title: Re: Bug Reports
Post by: Quigibo on May 28, 2011, 07:22:28 pm
The main thing I'm concerned about with new pixel buffer commands is what I'm supposed to do about pxl-Test() which is half the reason you would use the command in the first place.  It looks too funky to have pxl-Test(X,Y)->P->A mean reading a pixel on buffer P into value A.  I guess I could have an optional 3rd argument instead so it looks like pxl-Test(X,Y,P)->A but this is inconsistent with the sprite drawing to buffers.  I would like consistency so I would rather change Pt-On(X,Y,S)->P into Pt-On(X,Y,S,P) as well if I did that, but that involves a compatibility issue.  I guess this is something to resolve before 1.0.0 because I don't want to make changes like this after.  Unless anyone is really against the change, I will probably change to the new syntax.  I never really liked the original storing syntax anyway, its not really any more intuitive than an extra argument, I don't remember why I did that in the first place.
Title: Re: Bug Reports
Post by: Freyaday on May 28, 2011, 07:25:24 pm
Zeroes(8)->I
.code defining W as mod 64
Pxl-On(W,0)->I
ClrDraw
Copy(I,L6,8)
DispGraph
.blank screen
ClrDrawr
Copy(I,L3,8)
L3->DispGraph
.Line from (0,0) to (63,0)
Title: Re: Bug Reports
Post by: Runer112 on May 28, 2011, 07:28:01 pm
I personally like the argument syntax as well. I think DispGraph(L3) looks better than L3→DispGraph, too. This would also make DispGraph(L6,L1)rr a possibility. ;D *hint hint*


EDIT: And in response to Freyaday, since Pxl-Command()→Buffer isn't supported, Pxl-On(W,0)→I not only doesn't operate on the bytes pointed to by I, but it stores a value into I, overwriting the value you want it to hold. That's probably why you're not seeing what you want from the copying.
Title: Re: Bug Reports
Post by: Freyaday on May 28, 2011, 07:49:14 pm
Ok./me goes to request a feature
Title: Re: Bug Reports
Post by: ztrumpet on May 28, 2011, 09:43:43 pm
I personally like the argument syntax as well. I think DispGraph(L3) looks better than L3→DispGraph, too. This would also make DispGraph(L6,L1)rr a possibility. ;D *hint hint*
That sounds awesome, and I second the DispGraph(L6,L1)rr idea. :D

Quigibo, why don't you release a 0.5.4 or a 0.6.0 version with all of the current bugs fixed instead of pressuring yourself to have it all fixed by 1.0.0. :)
Edit:  Never mind:
I re-uploaded a fixed version so you won't have to wait until 1.0.0 :)
Title: Re: Bug Reports
Post by: Munchor on June 01, 2011, 06:02:05 pm
Quigibo, in the AXEPONG.8XP game, the ball sometimes goes through the screen, perhaps because it has a velocity >256? Not really an Axe bug, but it's worth mentioning.
Title: Re: Bug Reports
Post by: Darl181 on June 03, 2011, 07:35:36 pm
Code: (working) [Select]
ClrDraw
For(A,0,767)
{A+L6} and (255)→{A+L6}
End
Makes a solid black screen.  Works fine. However,
Code: (not working) [Select]
ClrDraw
For(A,0,767)
{A+L6} and ([FF])→{A+L6}
End
...makes a bunch of vertical bars, when it looks like it should do the same thing.

I'm not sure if this is a bug or if there's something different about hex chars...

EDIT: nvm, need to use EFF instead of brackets
Title: Re: Bug Reports
Post by: Runer112 on June 05, 2011, 09:37:03 pm
I discovered this bug a while ago but forgot about it! Good thing I rediscovered it. If you put a comment on a data line, like so:

[0123456789ABCDEF] .The mage

The parser thinks the comment is an operand and produces code to load the data pointer into hl.
Title: Re: Bug Reports
Post by: Quigibo on June 05, 2011, 10:17:56 pm
Technically, that's an illegal use of a comment.  They're only supposed to start a line and not be put inline with other commands.  I don't check for that though because some people like to abuse it.  I guess I should either check or fix this.  There are other places that would have this problem too that I can think of.
Title: Re: Bug Reports
Post by: Runer112 on June 05, 2011, 10:29:59 pm
Ah. They work fine inline with just about everything else though. :)

Another bug that has probably been mentioned a bunch of times: drawing sprites to an arbitrary buffer reverses the X and Y coordinates. You pop them in the wrong order!
Title: Re: Bug Reports
Post by: Quigibo on June 05, 2011, 10:44:53 pm
That was already fixed as part of my revamping of buffer drawing commands. :)
Title: Re: Bug Reports
Post by: Freyaday on June 06, 2011, 01:53:16 am
Code: [Select]
For()
.Loopy stuff
EndIf condition
doesn't work.
Title: Re: Bug Reports
Post by: Hot_Dog on June 06, 2011, 11:02:46 pm
This is a weird one...but if bit 1 of (IY + appFlags) is not set, sometimes text drawn with Output( or Disp( will disappear when the program calls for user input (keyword Input).  My guess is Output( and Disp( do not automatically update TextShadow, and B_CALL($4E5E) will only show what was stored into the text buffer.
Title: Re: Bug Reports
Post by: Hayleia on June 08, 2011, 08:05:00 am
I don't know if it was already reported so I report it.
I'm using a TI-84+SE and my friend is using a TI-83+, both of us have Axe 0.5.3.
When we do "Output(0,Y,K>Dec" with 0<Y<7 and 0<K<200, it displays the K in the wrong column.
When K<10, it displays it in the fifth column. When 9<K<100, it displays it in the fourth column, etc.
I wanted to make a gif with Wabbitemu but everything is normal with Wabbitemu ??? I made a mistake somewhere.
I thought it was the fault of my calc, that's why I tries GarbageCollecting and RamClear, but the bug persisted. So I tried with my friend's calc but there was the same bug.
(At least, when I say "Output(0,etc", it writes in 5 and when I say "Output(1,etc", it writes in 6).
Has anyone else got that bug ?
Title: Re: Bug Reports
Post by: Deep Toaster on June 08, 2011, 09:45:54 am
It's not a bug. The routine that Axe uses for ►Dec (_DispHL) displays a two-byte number right-justified in the next five character blocks. That means that no matter how many digits your number has, it'll always take up five spaces and be on the right side. So if it's one digit, it'll have four spaces and then that digit; if it's two, it'll have three spaces. It's just the way TI wrote their routine, so a workaround would be making your own number display routine.
Title: Re: Bug Reports
Post by: Hayleia on June 08, 2011, 10:08:08 am
Good to know. Thank you (You got a +1).
Hey, I'm a living ERR:Syntax ! I said that the "bug" wasn't in Wabbitemu but it is (fortunately).
I don't know what I typed to make it display the 0 in the first column (maybe this ").
What a noob I am.
Title: Re: Bug Reports
Post by: ztrumpet on June 08, 2011, 11:34:14 am
This is a weird one...but if bit 1 of (IY + appFlags) is not set, sometimes text drawn with Output( or Disp( will disappear when the program calls for user input (keyword Input).  My guess is Output( and Disp( do not automatically update TextShadow, and B_CALL($4E5E) will only show what was stored into the text buffer.
I think Quigibo could add a "set 1, (IY + appFlags)" at the start of the input routine to fix it. :)  Thanks for the bug report! ;D
Title: Re: Bug Reports
Post by: Hot_Dog on June 08, 2011, 12:24:14 pm
This is a weird one...but if bit 1 of (IY + appFlags) is not set, sometimes text drawn with Output( or Disp( will disappear when the program calls for user input (keyword Input).  My guess is Output( and Disp( do not automatically update TextShadow, and B_CALL($4E5E) will only show what was stored into the text buffer.
I think Quigibo could add a "set 1, (IY + appFlags)" at the start of the input routine to fix it. :)  Thanks for the bug report! ;D

Couldn't hurt.  It's interesting, though, I'm almost sure that B_CALL($4E53) sets it automatically after it gets input
Title: Re: Bug Reports
Post by: ztrumpet on June 08, 2011, 01:34:35 pm
Hmm, I was just thinking about this, and Hot Dog, is there any chance you were on a Math Print OS?
Title: Re: Bug Reports
Post by: Hot_Dog on June 08, 2011, 07:09:32 pm
Hmm, I was just thinking about this, and Hot Dog, is there any chance you were on a Math Print OS?

No chance.  This was a Ti-83+.
Title: Re: Bug Reports
Post by: thepenguin77 on June 10, 2011, 08:41:06 pm
With the API entry points, some glitches were brought to my attention.

Whenever you compile something from the API entry points, the Auto Backup is turned off. Also, the Compile For: is set to whatever was compiled last.

The Compile For: might not exactly be a glitch, but the Auto Backup getting turned off is. Probably just a flag somewhere...
Title: Re: Bug Reports
Post by: Quigibo on June 11, 2011, 12:13:21 am
Oh yeah, I forgot to mention that!  Bit 3 controls if auto backups should be turned on or not when using the CompileOP1 entry point.  Axe always saves the current setting configuration when it exits so if you want it to restore the original settings, you'd have to read and then modify the Axe appvar, which contains a single byte: the setting.  Maybe I'll change that for 1.0.0 though since I see how that can be annoying.
Title: Re: Bug Reports
Post by: thepenguin77 on June 11, 2011, 09:47:48 am
Yes, you would probably want to change that. That way, each different way of compiling has it's own settings. You have Axe settings, zStart settings, <future program> settings, and they are all independent of each other.

So bit 3, I would have never figured that one out... ;)

Edit:
   Lol quigibo, I don't think that works.
Quote from: Quigibo
Code: [Select]
apiEntryPoint:
cp 5
jr c, $+3
xor a
;$$
ld ($886B), a

But nonetheless, my code is ready for when it happens.
Title: Re: Bug Reports
Post by: DrDnar on June 15, 2011, 12:03:35 am
I tried to do a Copy( with a {Y1+offset} in the length argument. Axe compiled it, but the program instantly crashed, regardless of where the statement was. In general, Axe doesn't like nesting {} and doesn't always give an error.

Edit: Hmm, now I can't duplicate the Copy( crashing.

Here's the fragment of code I was writing when I came across the problem. It works fine now, by the way. It does some pretty evil things. Points to anybody who can identify what it's doing. Y1 is supplied as an argument.
Code: [Select]
Data(24,7,8,8,8,5,5,8,8,0,0,0,2,4,7,0,0,0,0,0,0,0,5,0,1)->Str2
.
.
.
If (Y1+1)r>Asm(EFE542)
 Disp Str4
 Goto UDE
End
0->{$8478}
Fill($8478,0)
{Y1+3}->A
A->{$8478}
!If {A+Str2) and 4
 If {A+Str2} and 8
  Goto UDT
 End
 Disp "Not supported.",i
 Goto UDE
End
Copy(Y1+10,$8479,{Y1+9})
If Asm(EFF14221000038012C)
 Disp Str3
 Goto UDE
End
{Y1+9}->C
{Y1+C+10}r->A
{Y1+3}->B
C+10->D
If {B+Str2} and 2
 A*8+A->A
 $31->{C+$8478}
End
If B=13
 A*2->A
End
$15->{$8478}
AAsm(EF6A4EED53E28922E089)
{Y1+3}->{V}
Copy(Y1+D,W,A+2)
If {B+Str2} and 2
 0->{V-C-6}
End
Title: Re: Bug Reports
Post by: Builderboy on June 15, 2011, 12:14:19 am
Hmmm could you post some code?  Are you sure you are setting up the variables correctly?  Since I tried it myself, and didn't have any trouble at all o.O And what do you mean that Axe doesn't like nesting {} in general?  Are there more issues?  What kind of problems have you been having?
Title: Re: Bug Reports
Post by: Quigibo on June 15, 2011, 12:21:42 am
I think its more likely that {Y1+offset} evaluated to 0 meaning it would have copied the entire 65536 bytes of RAM which would certainly cause an instant crash.
Title: Re: Bug Reports
Post by: DrDnar on June 15, 2011, 12:28:23 am
No, that's only a small fragment of the program. It would crash the moment I ran the program. That code doesn't get run until you select an item to process.

What I meant is that doing something like {Y1+{Y1+9}+10}r doesn't work. Seriously, create a program whose contents is
Code: [Select]
:.SOMENAME
:{Y1+{Y1+9}+10}r . Don't bother saving the result.
It should read a random word and do nothing, right? It crashes.
Title: Re: Bug Reports
Post by: Quigibo on June 15, 2011, 04:46:57 am
Ah yes I found it thanks.  I was storing the "Is File" boolean in a variable instead of the operator stack and that made file references non-nestable.  I'll have that fixed next version.
Title: Re: Bug Reports
Post by: p2 on June 15, 2011, 02:24:16 pm
Maybe I found a bug:

If you have no PRGM with axe language on your TI and you press enter, the display contrast will become darker, The screen is upside down, strange symbols on screen, Error Memory, Ramclear.
I've had it two times yet.

(because I hadn't known that I should have been making a PRGM with axe language first)


Title: Re: Bug Reports
Post by: Runer112 on June 15, 2011, 02:27:56 pm
That most certainly is a major bug, and a great find! I always have Axe source code on my calculator so never noticed this before.
Title: Re: Bug Reports
Post by: p2 on June 15, 2011, 02:50:51 pm
http://ourl.ca/11557 (http://ourl.ca/11557)
Here I've descriped it exactly.

I hope someone could do against it.

(Other programmers wouldn't be so happy, if all their programs are deleted by the ramclear.


p2

Title: Re: Bug Reports
Post by: p2 on June 15, 2011, 02:59:46 pm
Maybe I've found another problem: :)


with Axe EVERYONE could program an APP like this, send it someone else and start it:

.MEGAMAN
:disp ("AN ERROR HAS ACCOUNTED")
:pause 2000000000000


That would be a problem, because you just jan take out the batteries, and that will be a ramclear or worse. :-\
Title: Re: Bug Reports
Post by: Runer112 on June 15, 2011, 03:06:05 pm
Numbers in Axe are limited to 2-byte values, so 0-65535. Compiling will fail upon reaching a number greater than this.

Also, it's not a bug that people can create malicious code with Axe. You can create malicious code with any language, but because Axe is powerful, you can create powerfully malicious code.
Title: Re: Bug Reports
Post by: DrDnar on June 15, 2011, 03:32:48 pm
Code: [Select]
:AsmProg
:C7
No Axe needed.

Edit: C7
Title: Re: Bug Reports
Post by: calc84maniac on June 15, 2011, 03:39:37 pm
Code: [Select]
:AsmProg
:C9
No Axe needed.
            Done
Title: Re: Bug Reports
Post by: DrDnar on June 15, 2011, 03:42:52 pm
Make that C7.
Title: Re: Bug Reports
Post by: Ashbad on June 15, 2011, 03:43:35 pm
or, FEC832.
Title: Re: Bug Reports
Post by: DJ Omnimaga on June 15, 2011, 03:44:53 pm
And don't do like people did last year. Instead, this time, backup your projects before trying the code above.
Title: Re: Bug Reports
Post by: DrDnar on June 15, 2011, 03:46:19 pm
That's a good point. Someone could embed a call to the Clear All Memory OS routine. Or even the boot code self test.
Title: Re: Bug Reports
Post by: Quigibo on June 15, 2011, 07:19:39 pm
I can't seem to replicate that no-axe-source bug.  I'm looking at the source code where this problem would be, but I don't see anything suspicious.  Can someone explain starting from a RAM clear how to reproduce it?  It probably depends on what's in the program or something, I've tried 5 different BASIC programs (and all together) and none of them do it.
Title: Re: Bug Reports
Post by: Runer112 on June 15, 2011, 08:05:41 pm
I'm not sure how he triggered the empty compile list bug, but here's how I triggered it:

Title: Re: Bug Reports
Post by: p2 on June 16, 2011, 03:14:59 am
There's another little problem in Axe:

Have you ever tried to display a Text with äöüÄÖÜßáàÁÀ...
There are some strange things...
"ÄÖÜäöü" will become "q9äuÄË" and so one.
It's a bit nervy, if you want to write something in a textmode.
Title: Re: Bug Reports
Post by: aeTIos on June 16, 2011, 04:40:19 am
Uh, yeah. You should use the character numbers. for example 32>char will become a space.
Title: Re: Bug Reports
Post by: p2 on June 16, 2011, 04:49:54 am
How to write that?
I've never done tat before.

Is it like the real(13,1,X in xLib?
Title: Re: Bug Reports
Post by: Quigibo on June 16, 2011, 04:57:16 am
Actually, that's something I can fix.  I haven't updated the token replacement chart for ages since no one's requested any new ones.  I'll see what I can do for the next update.
Title: Re: Bug Reports
Post by: p2 on June 16, 2011, 05:03:18 am
maybe a posibillity to activate Axe AND xLib:
if I open Axe, xLib and Deutsch (mages my TI german) are automatically deactivated.

Can't you do something that It's possible to  use real( (that one of xLib) in programs with axe code, too?
it would be a great help for xLib-users
Title: Re: Bug Reports
Post by: aeTIos on June 16, 2011, 08:03:35 am
Nope, Axe is compiled, not parsed. Also, axe includes every function xLib has (actually even more)
Title: Re: Bug Reports
Post by: p2 on June 16, 2011, 08:04:53 am
 ???
If I use a xLib command, It says error.
Title: Re: Bug Reports
Post by: aeTIos on June 16, 2011, 08:07:45 am
Of course. Axe 'translates' the code to hexidecimal machine code, while xLib adds functions to the TI-Basic parser. Axe and xLib are not compatible with each other (and will never be). For example, you can draw a sprite with xLib with some real( command, but with Axe you use pt-On(X,Y,Sprite).
Title: Re: Bug Reports
Post by: Runer112 on June 16, 2011, 08:44:29 am
Actually, that's something I can fix.  I haven't updated the token replacement chart for ages since no one's requested any new ones.  I'll see what I can do for the next update.

Why do you need your own chart? When parsing strings, couldn't you use [wikiti]83Plus:BCALLs:4594[/wikiti], which converts a token into its equivalent ASCII string? You may want to use your own chart for the common, short tokens like all the letters, numbers, and some punctuation for speed purposes, though.
Title: Re: Bug Reports
Post by: Quigibo on June 16, 2011, 05:11:26 pm
Thanks Runer, I completely forgot about that, much easier!
Title: Re: Bug Reports
Post by: Deep Toaster on June 17, 2011, 03:33:50 pm
???
If I use a xLib command, It says error.

Axe and BASIC are completely separate languages. xLIB and Celtic III are BASIC extensions.
Title: Re: Bug Reports
Post by: Darl181 on June 17, 2011, 05:43:03 pm
There's another little problem in Axe:

Have you ever tried to display a Text with äöüÄÖÜßáàÁÀ...
There are some strange things...
"ÄÖÜäöü" will become "q9äuÄË" and so one.
It's a bit nervy, if you want to write something in a textmode.
Make sure they're not two-byte tokens?
Title: Re: Bug Reports
Post by: Deep Toaster on June 19, 2011, 10:30:27 pm
They are the two-byte tokens, but Axe converts some of them already. These were the ones that were left out, so I guess that'd make it a bug?
Title: Re: Bug Reports
Post by: calc84maniac on June 19, 2011, 10:32:06 pm
With Runer112's suggestion several posts up, all tokens should be converted properly.
Title: Re: Bug Reports
Post by: aeTIos on June 23, 2011, 03:20:00 am
Bug report: interrupts are broken (afaik). If I compile Continuity in 0.5.3, it runs friggin' slow when using interrupts to draw grayscale. maybe the dispgraph is broken?
Title: Re: Bug Reports
Post by: Quigibo on June 23, 2011, 06:29:52 am
Should be fine... Have you tested the previous version on real hardware?  Grayscale DispGraphs used to not work in 15MHz mode but the emulator would never show that.  If you didn't put a Normal before and a Full after in the old version then you had a bug in your code.  But now, this is automated for you, so that bug can no longer exist and all DispGraph commands run at their proper speeds, so that could have been the reason.
Title: Re: Bug Reports
Post by: aeTIos on June 23, 2011, 06:36:37 am
I always test directly after compiling. So yeah, I tested on real hw.
Title: Re: Bug Reports
Post by: ztrumpet on June 23, 2011, 10:54:01 am
Try using the fnInt like this:
fnInt(XXX,6)
This 6 will slow down the speed of the interrupts.  If it's too slow there remember that interrupts are triggered fast and each time that they're triggered it runs DispGraph.  For instance, this may happen 20 times durring your main loop when normally you'd only have 2-3 DispGraphs in there.  I hope this helped. :)
Title: Re: Bug Reports
Post by: thepenguin77 on June 28, 2011, 02:01:06 pm
1.0.0 is coming out soon so I need to make sure you fixed this. Did you fix the way the CompileOP1 handles A? You told me that bit 3 would toggle the auto backups, but I found code that clearly showed that it did not.

Just asking because you never replied. ;)
Title: Re: Bug Reports
Post by: Quigibo on June 28, 2011, 03:37:27 pm
Actually instead I will fix it to not update the appvar settings so you won't need that bit anyway.
Title: Re: Bug Reports
Post by: thepenguin77 on June 29, 2011, 06:48:19 pm
Ok, easy enough.
Title: Re: Bug Reports
Post by: annoyingcalc on July 03, 2011, 11:56:51 pm
I am not sure if this was Axe but in 5.3b my calc gave EXAPLE:: when I press up it gave me graph and crazy text and pull out all batteries even backup then push random buttons to cause RAM clear sorry no screenies I have no camera at my grandmas
Title: Re: Bug Reports
Post by: Darl181 on July 04, 2011, 12:13:25 am
Um, can you explain that a bit more?  Was it in the actual axe app or compiled code that you ran?
Title: Re: Bug Reports
Post by: leafy on July 04, 2011, 12:45:11 am
annoyingorange that happens when you write to a section of free ram, notably L2 or L4, in a manner that corrupts graph data.
Title: Re: Bug Reports
Post by: DrDnar on July 04, 2011, 12:46:56 am
More compilation bugs. The two programs below are identical, except one is missing the single line X*{Y1+13}*9->A. This line causes Axe to freak out and stop producing anything that looks like logically connected assembly. (Seriously, a disassembly of the resulting program shows gibberish.) Compile the first, and it runs fine; compile the second, and it crashes instantly. The interesting part is that line in question doesn't get run on start up. Furthermore, doing {Y1+13}->A:X*A*9->A works fine.
Title: Re: Bug Reports
Post by: Quigibo on July 04, 2011, 01:26:04 am
Works fine with the new version, so whatever bug that was I will assume is fixed now.
Title: Re: Bug Reports
Post by: Runer112 on July 04, 2011, 01:53:50 am
It's not just him, Quigibo. AAAA.8xp does crazy stuff for me when compiled. Not only does it print garbage to the screen and RAM clear, but it even messes up wabbitemu's debugger.

Upon looking at compiled code, you can clearly see that something is going wrong. Here is a snippet of the Axe source code where things start to go wrong:

Code: [Select]
X*{Y₁+13}*9→A
Else
 {Y₁+12}ʳ→A

And here is a breakdown of the assembly:

Code: [Select]
ld hl,(axv_X) ; X

push hl ; *{

ld hl,(axv_Y1) ; Y1

ld de,13 ; +13
add hl,de

ld a,(axv_Y1Page) ; }
call p_ReadArc
ld h,0
ld bc,$67A4 ; Where in the world did this come from? This should be pop de
call p_Mul

ld d,h ; *9
ld e,l
add hl,hl
add hl,hl
add hl,hl
add hl,de

ld (axv_A),hl ; ->A

rrca ; This should be a jp (Else). However, the hex looks familiar:
and h ; A4
ld h,a ; 67

ld hl,(axv_Y1) ; {Y1

ld de,12 ; +12
ld a,$3F ; More mysterious code

and h ; }
ld h,a ; Look familiar?
call p_ReadArc

ld (axv_A),hl ; ->A
Title: Re: Bug Reports
Post by: Quigibo on July 04, 2011, 02:26:04 am
Well whatever it was, both versions work now.  I even undeleted something just to be sure.  That disassembly makes me think it had the asm pointer off by 1 during the 2nd pass, so when it was doing the substitutions it was overwriting actual instructions rather than the instruction's argument.
Title: Re: Bug Reports
Post by: Freyaday on July 05, 2011, 06:11:15 am
{,} is valid code
Title: Re: Bug Reports
Post by: annoyingcalc on July 05, 2011, 08:59:48 am
It was a Noshell-not Axe error I used program writeback and I ran my mario game
Title: Re: Bug Reports
Post by: p2 on July 05, 2011, 11:32:31 am
Axe is deactivating xLib and Deutsch automatically!
And it's not possible to activate xLib again, while you have Axe on your TI

that's ANNOYING!
Title: Re: Bug Reports
Post by: defmenge on July 05, 2011, 01:19:21 pm
Axe is deactivating xLib and Deutsch automatically!
And it's not possible to activate xLib again, while you have Axe on your TI

that's ANNOYING!

Even though I don't use the German/Deutsch app often, I agree with you, sometimes I need it for the special characters menu, which is unloaded as well IIRC.
I've never used xLib, but being unable to use it once you run Axe sounds kinda annoying. :P
Title: Re: Bug Reports
Post by: ztrumpet on July 09, 2011, 02:59:08 pm
I think I found a strange bug:
If the calc GarbageCollects it disables the hook that Axe installs that renames tokens.
(I was using zStart at the time, so it may have been that, but I can't think of a reason that zStart would interfere there.)
Title: Re: Bug Reports
Post by: defmenge on July 13, 2011, 08:39:38 am
Great job on 1.0.0, but I already have to report a bug. :P
DROD8x does not compile at all right now, it complains about a missing program, even though the program is there and it compiled perfectly fine with 0.5.3 seconds ago. When pressing PRGM, it opens the base program which 'includes' all other programs and scrolls to the line ".INIT".
Code: [Select]
.DROD
.DROD8x v0.0 "ROACHIE"
.DATA
prgmD8XDATA
.INIT
prgmD8XINIT
.MAIN
prgmD8XMAIN
.AI FUNCS
prgmD8XAI
.DRAW FUNCS
prgmD8XDRAW
.ROOM LOADER
prgmD8XLOAD

The editor is also affected by this and it seems like a rather severe bug since multiple program includes may be impossible now.

Sorry for complaining about bugs this fast, but I can't really continue working on DROD8x if Axe refuses to include subprograms.
Title: Re: Bug Reports
Post by: ztrumpet on July 13, 2011, 08:47:59 am
Yeah, I'm having problems with includes too. :(
Title: Re: Bug Reports
Post by: FinaleTI on July 13, 2011, 10:30:00 am
I've hit the include bug as well, though I encountered something else rather serious. I'm not quite sure what caused it, as every app compile after that one has successfully defraged and compiled. What happened is that I compiled an app to update it from 0.5.3, but when it began to defrag, corrupted coordinates appeared at the bottom of my screen and my calc seemed to freeze. I did a battery pull and everything seemed ok. Then I noticed things where randomly corrupting, and whenever I tried to set my window coordinates(among other things, like use Celtic's lineread function), I would receive an ERR:UNDEFINED. I believe that through some odd twist of fate, my OS was corrupted.

I don't think this was entirely Axe's fault, but I do find it to be a bit odd. I was using a TI-84+ SE with OS 2.43 and a certificate modded using thepenguin's program. The only other thing installed was zStart, and I believe I had RAM cleared shortly before that fateful compile. I haven't yet had a chance to restore my OS, as I'm away from my laptop for the next several hours.
Title: Re: Bug Reports
Post by: Runer112 on July 13, 2011, 11:33:47 am
Not all of what follows are bug reports, but I figured it's just easier to make one post here instead of 3 posts across multiple topics.


Some errors in the command list:


Some actual errors:


An optimization:


A suggestion:

Code: [Select]
p_CheckSum:
ld b,h
ld c,l
pop af
pop de
push af
ld hl,$FFFF
__CheckSumNext:
ld a,(de)
xor h
ld h,a
push bc
ld bc,8<<8+$10
__CheckSumLoop:
add hl,hl
jr nc,__CheckSumSkip
ld a,h
xor c
ld h,a
ld a,l
xor $21
ld l,a
__CheckSumSkip:
djnz __CheckSumLoop
pop bc
ex de,hl
cpi
ex de,hl
ret po
jr __CheckSumNext
Title: Re: Bug Reports
Post by: p2 on July 13, 2011, 11:36:49 am
Strange things are happening with the getkey-command in Axe.
If I press 3 keys at the same time, it says, I'm pressing this three keys.

If I press 4 keys at the same time, it says, I'm pressing six keys.

Title: Re: Bug Reports
Post by: ztrumpet on July 13, 2011, 11:41:56 am
That's not an Axe error, that's due to how TI made the calculators.  More info: http://ourl.ca/7652
Title: Re: Bug Reports
Post by: Darl181 on July 13, 2011, 01:35:47 pm
Drawing a sprite to an arbitrary buffer switches the coordinates.
Was happening last night..


nvm, that was version 053
Title: Re: Bug Reports
Post by: Quigibo on July 13, 2011, 02:28:03 pm
I'll get on that include error right away.  That should be easy to fix, I'll release a new version tonight so there is still time for the contest.

Quote
  • Inline if statements (and I mean actual inline If:.true:End statements) seem to cause problems if they are inside of the argument list for Axe commands.
  • Shade() does not load a 0 into the h register. I'm guessing you left this out because in most uses, it wouldn't matter. But it could still matter in some, like testing if the value is greater than, less than, or equal to a certain value.

Thanks!  That first one is a bug in that it doesn't error when it should when you use an if inside of parenthesis.  The colon would then cause it to end the if statement but keep the parenthesis open.

The second one was intentional.  But I can see why you'd want that for comparisons... I guess as long as I can still peephole opt the differences out I could still add the extra bytes to the command while keeping it the same size in the final program when it can be.
Title: Re: Bug Reports
Post by: XVicarious on July 13, 2011, 11:32:08 pm
I don't seem to have a problem with multiple includes. Rott Engine built perfectly the first time (and the compiled code was smaller than before :D) without changing a thing.
Title: Re: Bug Reports
Post by: ZippyDee on July 14, 2011, 03:26:33 am
I think I found a strange bug:
If the calc GarbageCollects it disables the hook that Axe installs that renames tokens.
(I was using zStart at the time, so it may have been that, but I can't think of a reason that zStart would interfere there.)
Garbage collect apparently does some weeeeeird stuff. I once had my whole program corrupted because it didn't have enough space and I was stupid enough to accept the garbage collect while it was compiling >.< It corrupted the program AND the backup, and wouldn't allow me to back up a second version of that program because it said "That backup name is reserved for another program" even after I deleted the corrupted appvar from my calc.
Title: Re: Bug Reports
Post by: Freyaday on July 14, 2011, 05:55:00 pm
Umm, found one in 1.0.0
Tryed compiling my level saver for Nymless.
Axe choked on the first line of code(the one after the header), Lbl 0, claiming the zero wasn't a valid token (in a black bar underneath the percent screen. is this normal?)
I changed the Lbl 0 to Lbl A and changed all the references to it.
Compiled it again, but it crashed midbackup.
I turned the calc back on, and it was stuck on the screen it crashed.
I did a battery pull, and it was still stuck.
I pulled the battery again, and this time turned it on while holding Clear.
it worked.
Then I tryed running Axe.
Exact same thing again. (Me having to hold Clear)
So I plug it into a computer to replace 1.0.0 with 0.5.3, and it says Access Denied, and on the calc, the cursor is blinking, but instead of a blank space behind the cursor, there's a Thick Down Arrow.
So I try replacing Axe again, and it works, but now there's nothing in the list of programs, either in Axe's list or when I press PRGM.
Title: Re: Bug Reports
Post by: calc84maniac on July 14, 2011, 08:21:56 pm
I tried compiling one of my programs and I got a Bad Flash error. I checked my swap sector and it had been erased (the starting byte was 0xFF instead of 0xFE). I tried compiling again and it worked. What the heck was going on there?

Edit: In particular, what causes a Bad Flash error?
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2011, 09:53:54 pm
Both of those bugs should have been fixed with the 1.0.1 update.  The issue was that the swap sector was being cleared but I forgot to reset the bit to re-indicate it was the swap sector once compiling finished.  A bad flash error means that either the calculator could not find a swap sector or that flash failed to unlock.
Title: Re: Bug Reports
Post by: calc84maniac on July 14, 2011, 09:55:32 pm
Both of those bugs should have been fixed with the 1.0.1 update.  The issue was that the swap sector was being cleared but I forgot to reset the bit to re-indicate it was the swap sector one compiling finished.  A bad flash error means that either the calculator could not find a swap sector or that flash failed to unlock.
I was using 1.0.1. The swap sector was cleared, which mean flash was unlocked.

I think a better idea, though, is to set the 0xFE byte directly after you erase the page, then use the rest of the sector as you please. After you're done, you won't have to erase it again because the identifier byte is there. (Trust me, I do this with TI-Boy)
Title: Re: Bug Reports
Post by: Ti-Programmer on July 14, 2011, 09:58:24 pm
Hey!

Sorry if i am reposting this, i found a small bug in axe (truely in asm moreso) that causes the display to do weird things  in the new ti MathPrint OS. (2.55 for 84+SE, 2.56 for Nspire) the quick fix is to enable classic mode (mode, then scroll down till you see "MathPrint Classic" select Classic and press clear, now run asm prgm. Although if it could be helped it'd be better to solve the mathprint bug.

Thanks!

Edit:
Triggered by code:
Code: [Select]
.AXEPRGM
"Hello World!"->Str1
Disp Str1
clrHome

asm(prgmAXEPRGM)
it displays an 'H' and then done the first time (if it is the first entry), the rest just random pixels on a line. (numerous entries on calc screen) I could maybe post a vid for better details.
Title: Re: Bug Reports
Post by: Freyaday on July 14, 2011, 09:59:15 pm
What triggers it?
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2011, 10:12:46 pm
Both of those bugs should have been fixed with the 1.0.1 update.  The issue was that the swap sector was being cleared but I forgot to reset the bit to re-indicate it was the swap sector one compiling finished.  A bad flash error means that either the calculator could not find a swap sector or that flash failed to unlock.
I was using 1.0.1. The swap sector was cleared, which mean flash was unlocked.

I think a better idea, though, is to set the 0xFE byte directly after you erase the page, then use the rest of the sector as you please. After you're done, you won't have to erase it again because the identifier byte is there. (Trust me, I do this with TI-Boy)
Ah, I always thought the identifier might imply that the sector was expected to be cleared for other programs, that's why I had to erase it twice.  Its strange it didn't write the byte there the second time, I guess that would explain the bad flash error.
Title: Re: Bug Reports
Post by: calc84maniac on July 14, 2011, 10:16:31 pm
You will always want the first byte to be 0xFE. That's how the OS knows where the flash sector is. If Axe happens to crash while compiling without an 0xFE at the start of the swap sector, the swap sector might be lost. I've had this sort of thing happen in TI-Boy -- the swap sector kept moving higher and higher in flash until it filled up with garbage. Not good.
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2011, 10:24:15 pm
Ah okay.  Yeah I just realized now that that could happen if the parsing doesn't complete as a result of an error.  Is that bug as serious as requiring a ROM clear?
Title: Re: Bug Reports
Post by: ztrumpet on July 14, 2011, 10:24:58 pm
Yes.  * ZTrumpet looks at the past four (five?) hours of #omnimaga...
Title: Re: Bug Reports
Post by: FinaleTI on July 14, 2011, 10:30:48 pm
I had to ROM clear several times as well.
Title: Re: Bug Reports
Post by: Quigibo on July 14, 2011, 10:34:40 pm
Alright, I guess its another update tonight then.  ::)
Title: Re: Bug Reports
Post by: calc84maniac on July 14, 2011, 10:44:16 pm
To be clear, if the OS doesn't find a sector starting with 0xFE, it uses the first sector starting with 0xFF as a swap sector instead. This causes a 64KB memory leak in archive each time.
Title: Re: Bug Reports
Post by: defmenge on July 15, 2011, 06:02:08 am
I'm not quite sure what these sector things are, but I guess you're talking about the bug that occurs after compiling which messes up the calc (or in this case, Wabbitemu), causes errors when sending files and clears the RAM after my app has executed until I restore an older saved state or clear the Archive. :P
It would be nice if you could fix that, I'm currently having incompatibility problems with the room drawing routines (objects and the player disappear sometimes), which I can't fix if I have to restore an old save state after each compile.

Also, I found out that DROD8x outputs a lot of random garbage to the home screen whenever I load a room, even though there is not a single command for printing text inside the room loading code. Perhaps that's related to MathPrint, though I haven't had any problems with that in 0.5.3 and earlier.
Spoiler For Lengthy room loading code:
Code: [Select]
Lbl LOA
Copy(Y1+R,L1+150,144)
sub(LDR,L1+150)
.Random garbage occurs above this line
sub(DRU)
sub(DRR)
If {L1+123}>0
For(I,0,{L1+123}-1)
sub(DRO,I)
End
End
0->{L1+114}->{L1+115}
0->{S+34}
sub(PSW)
Return

Lbl LDR
.r1: DATAPTR
0->{L1+123}->{S+186}
Fill(S+186,288)
For(J,0,11)
For(I,0,11)
If inData({J*12+r1+I},GDB1O)^(length(GDB1O)+1)!=0
{J*12+r1+I}->{{L1+123}*2+S+186}
I->nib{{L1+123}*2+S+187*2}
J->nib{{L1+123}*2+S+187*2+1}
{L1+123}++
0->{J*12+I+S+42}
Else
{J*12+r1+I}->{J*12+I+S+42}
End
End
End
sub(MSK)
Return

Lbl MSK
0->{L1+150}
Fill(L1+150,144)
For(I,0,143)
If inData({I+S+42},GDB1S)^(length(GDB1S)+1)!=0
1->{L1+I+150}
End
End
For(I,0,min({L1+123}-1,287))
sub(OMK^^r,I,1)
End
Return
Title: Re: Bug Reports
Post by: Freyaday on July 15, 2011, 01:50:01 pm
A sector is the four pages of ROM that have to be erased at once.
Title: Re: Bug Reports
Post by: defmenge on July 15, 2011, 02:46:13 pm
Ah okay, thanks. I've never worked with anything more low-level than Axe and I don't know much about how the TI-8x's flash memory works, so I was a bit confused between sectors, pages, swap memory and why APP sizes have to be multiples of 16 KB.
Title: Re: Bug Reports
Post by: Runer112 on July 15, 2011, 10:13:44 pm
'appv' is not parsed as 15h, unlike it is when in a string. This should probably be changed to return the same ASCII value it would represent in a string. The same probably goes for 'var' and 'grp'.


EDIT: Also, an entirely unrelated bug. B_CALL(_DelVarArc) apparently trashes (OP1) if the variable was archived, so attempting to create a variable that already exists in the archive deletes the old one and then fails to create the new one. Luckily, this is easily fixable. I found a solution that I think is as good as it gets, but I could be wrong. It only costs a single byte.

Code: [Select]
p_NewVar:
.db __NewVarEnd-1-$
B_CALL(_EnoughMem)
pop hl
ex (sp),hl
jr c,__NewVarFail
push de
push hl
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__NewVarSkip
B_CALL(_DelVarArc)
__NewVarSkip:
pop hl
ld a,(hl)
MOV9TOOP1()
pop hl
push af
B_CALL(_CreateVar)
pop af
ex de,hl
and %00011111
ret z
cp CplxObj
ret z
inc hl
inc hl
ret
__NewVarFail:
ld hl,0
ret
__NewVarEnd:
Title: Re: Bug Reports
Post by: Darl181 on July 18, 2011, 04:30:00 pm
Apparently the bad flash error is still there.  I upgraded straight from 053 to 101 (no, I didn't use 100 at all and yes, it's actually 101) and it's happening.

Edit: have now downgraded back to 053 :P
Title: Re: Bug Reports
Post by: calc84maniac on July 18, 2011, 05:20:09 pm
Apparently the bad flash error is still there.  I upgraded straight from 053 to 101 (no, I didn't use 100 at all and yes, it's actually 101) and it's happening.
I chatted with Quigibo the other day and he's going to fix some of the flash handling stuff soon.
Title: Re: Bug Reports
Post by: Quigibo on July 19, 2011, 02:42:02 am
I know I know, I've been meaning to update but I've been so busy IRL, as soon as I have free time again, I'm going to fix all the bugs.  Sorry about that.
Title: Re: Bug Reports
Post by: mrmprog on July 19, 2011, 03:57:05 am
Will the update add any thing new, or just bug fixes? I just printed the documentation and command list, and I don't want to have to reprint :)
Title: Re: Bug Reports
Post by: TIfanx1999 on July 19, 2011, 08:25:52 am
I know I know, I've been meaning to update but I've been so busy IRL, as soon as I have free time again, I'm going to fix all the bugs.  Sorry about that.

It's all good. No need to rush. Everyone appreciates all the hard work and time put into axe. :)
Title: Re: Bug Reports
Post by: Runer112 on July 20, 2011, 01:10:28 am
Yay, another bug involving a routine dealing with OS variables. In p_GetArc, it's possible that the VAT entry inside of the archived variable can span two pages, which isn't accounted for. It's unfortunate to have to add 9 bytes to account for a one in a thousand error, but it must be done. It doesn't have to be done after B_CALL(_LoadDEIndPaged) though, because Axe's archive access routines account for page overflows on their own.

EDIT: An even worse bug, the routine doesn't even verify that the variable being searched for is archived in the first place! This has been fixed too in the second code block.

Code: (Old code) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
B_CALL(_IsFixedName)
ld hl,9
jr z,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l
jr z,__GetArcDone
ld l,14
jr __GetArcDone
__GetArcName:
add hl,de
B_CALL(_LoadDEIndPaged)
ld d,0
inc e
inc e
__GetArcDone:
add hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcFail:
ld hl,0
pop de
ret
__GetArcEnd:
       
   
Code: (New code) [Select]
p_GetArc:
.db __GetArcEnd-1-$
push de
MOV9TOOP1()
B_CALL(_ChkFindSym)
jr c,__GetArcFail
dec b
inc b
jr z,__GetArcFail
B_CALL(_IsFixedName)
ld hl,9
jr z,__GetArcName
__GetArcStatic:
ld l,12
and %00011111
jr z,__GetArcDone
cp l
jr z,__GetArcDone
ld l,14
jr __GetArcDone
__GetArcName:
add hl,de
bit 7,h
jr z,$+7
res 7,h
set 6,h
inc b
B_CALL(_LoadDEIndPaged)
ld d,0
inc e
inc e
__GetArcDone:
add hl,de
ex de,hl
pop hl
ld (hl),e
inc hl
ld (hl),d
inc hl
ld (hl),b
ex de,hl
ret
__GetArcFail:
ld hl,0
pop de
ret
__GetArcEnd:
       
Title: Re: Bug Reports
Post by: Runer112 on July 20, 2011, 06:51:55 pm
Some more bugs:

Title: Re: Bug Reports
Post by: defmenge on July 25, 2011, 10:19:52 am
The increment/decrement operators (++/--) seem to be "invalid tokens", if used with memory locations/curly brackets (haven't tested variables).
Title: Re: Bug Reports
Post by: calc84maniac on July 25, 2011, 11:11:53 am
The increment/decrement operators (++/--) seem to be "invalid tokens", if used with memory locations/curly brackets (haven't tested variables).
Did you put them before or after? They need to go after.
Title: Re: Bug Reports
Post by: defmenge on July 25, 2011, 11:34:49 am
I put it after the expression, the bug was not present in 1.0.1.
Title: Re: Bug Reports
Post by: calc84maniac on July 25, 2011, 11:53:59 am
I just tried it myself, you are right. It only seems to occur with one-byte constant pointers, though.
Title: Re: Bug Reports
Post by: Runer112 on July 29, 2011, 03:31:27 pm
The increment/decrement operators (++/--) seem to be "invalid tokens", if used with memory locations/curly brackets (haven't tested variables).

I just tried it myself, you are right. It only seems to occur with one-byte constant pointers, though.

It's probably worth clarification that although parsing only fails with one-byte increments/decrements at constant pointers, all increments/decrements at constant pointers are afflicted with a problem. It seems that somehow all the routine references were shifted one position according to the number of r modifiers. If you specify n r modifiers, the parser will look for the routine that would correspond to n-1 r modifiers. So the one-byte increments/decrements fail because there is no routine for -1 r modifiers, but although the other two do not error, they look to the wrong routines.
Title: Re: Bug Reports
Post by: calcdude84se on July 30, 2011, 03:49:46 pm
It's not just increment/decrement. For example, this code will display the value of the two bytes at $BEEF (arbitrary value):
Disp {EBEEF}minY>Disp
Note that by ">Disp" I mean the single token, and that minY is a two-byte token (It's a statistics variable) whose second byte happens to be the same as the single byte of the r token.
Title: Re: Bug Reports
Post by: Runer112 on July 30, 2011, 04:00:28 pm
Well that's a whole other problem entirely. Axe 1.X seems to have problems identifying invalid tokens and throwing errors upon reaching them. As an extension of this problem, if you use an invalid token that Axe does recognize as invalid but you have included an Axiom in your program, it takes Axe a good few seconds upon reaching the invalid token to finally throw an error.
Title: Re: Bug Reports
Post by: calcdude84se on July 30, 2011, 04:03:30 pm
Well that's a whole other problem entirely.
Really? It just seems like it's skipping a byte. I can replace minY with, say, +r and it still ignores that first byte. (That is, it does the same thing as the code I gave earlier.)
Title: Re: Bug Reports
Post by: calc84maniac on July 30, 2011, 04:04:50 pm
Well that's a whole other problem entirely.
Really? It just seems like it's skipping a byte. I can replace minY with, say, +r and it still ignores that first byte. (That is, it does the same thing as the code I gave earlier.)
That certainly does explain why there's an error with ++, and also why n r's are parsed as n-1.
Title: Re: Bug Reports
Post by: Runer112 on July 30, 2011, 04:05:03 pm
Oh wait, you're right. This is a really bad bug then, it could completely break programs. O.O
Title: Re: Bug Reports
Post by: Compynerd255 on August 02, 2011, 09:03:45 pm
There's a bug in 1.0.2 that I can't place very well. In my game The Slime, there is a bit of code that adjusts the scrolling view window for the tile environment. The code worked perfectly in 0.5.3b, but in the newer version, scrolling goes beyond the right and bottom of the view, revealing the other side of the level on the right and garbage on the bottom:
Code: (Variable Explanation) [Select]
{L1} = level width
{L1 + 1} = level height
X & Y = slime's top left coordinates
U & V = camera's top left coordinates

Code: (Scrolling View) [Select]
Lbl GAM
...update the slime...
sub(CAM
...draw everything...
Return

Lbl CAM
X-41?U:Y-30?V
U>=>=0*U?U
V>=>=0*V?V
If {L1}-12*8<U
{L1}-12*8?U
End
If {L1+1}-8*8<V
{L1+1}-8*8?V
End

I tried changing the If blocks to min( expressions that did the same limiting (min(VAR,CAP)?VAR), and I got the exact same problem. And I know that it isn't a problem with the level boundary definitions, because the slime collides with where they are supposed to be, even in the new version of Axe. Do you know what is happening?

EDIT: Here's the link to the topic: http://ourl.ca/11736/232631
Title: Re: Bug Reports
Post by: calcdude84se on August 02, 2011, 09:05:57 pm
It might be the same problem as above. Axe 1.0.2 seems to skip a byte after dereferenced constant addresses.
Title: Re: Bug Reports
Post by: Compynerd255 on August 02, 2011, 09:12:05 pm
It might be the same problem as above. Axe 1.0.2 seems to skip a byte after dereferenced constant addresses.
Yup, that's it! The goalpost also uses dereferenced addresses to store its position, and it is always drawn at 8-U,8-V!
Title: Re: Bug Reports
Post by: Quigibo on August 03, 2011, 05:09:09 am
I'll get to fixing this soon.  Hopefully 1.03 will be stable.  Just FYI, ticalc always has the latest stable version.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 03, 2011, 02:29:55 pm
It might be good if Axe is open-source it might be good that someone else double-checks the compiling code and stuff to be certain the bug is totally gone.

Btw Quigibo Fishbot edited the 3 Axe 1.0.x release posts to add red warnings about calc damages and using it at their own risk, because it seems it can damage calculators with no way to recover.
Title: Re: Bug Reports
Post by: Quigibo on August 03, 2011, 04:13:20 pm
There shouldn't be "unrecoverable damages".  A rom clear should fix it, which unfortunately could mean loss of data if it can't be backed up.  1.0.2 has fixed that problem by the way.
Title: Re: Bug Reports
Post by: DJ Omnimaga on August 03, 2011, 04:14:38 pm
Well, p2 tried a rom clear, mem clear, the testing flash thing with ON+MODE, OS reinstall, etc. None of them worked. As for Zeldaking, after messing up his calc, it caused TI-Connect to no longer recognize his calc anymore, but it could just be TI-Connect being bad. As of now a Mem clear didn't fix his problem.

As for 1.0.2 I heard it still happened, to a lower extent, but maybe it was a different bug that does something else.
Title: Re: Bug Reports
Post by: Quigibo on August 03, 2011, 04:23:44 pm
That sounds like more of a problem with the calc itself than a problem caused by Axe.  Booting into test flash mode should be independent of the swap sector.  Its possible some other program could have been confused by the swap sector error and wrote something where it wasn't supposed to, but that still shouldn't prevent booting I think.

It is possible to have problems if you upgraded from 1.0.0 or 1.0.1 to a different version without ROM clearing first, which is probably the cause for anything like that in 1.0.2 or other versions.

But I keep emphasizing that this is still a beta release, so bugs like this are bound to happen.  This one in particular wasn't because of an error I made, but due to lack of knowledge of the OS documentation.  If you want the most stable version, always use the version currently on ticalc.org.
Title: Re: Bug Reports
Post by: FinaleTI on August 03, 2011, 04:28:18 pm
I'm also having some issues, though not as serious as p2 or zeldaking.

I'm not sure if the culprit is Axe 1.0.2 or zStart 1.2.013, as when zStart was the only thing installed on my calc after a ROM clear and fresh OS installation, the run on RAM clear feature worked perfectly. I then proceeded to send my other apps back, though Axe was the only one I installed. I wrote a simple program, just drew a few rectangles, inverted some text, and XOR'd a sprite, compiled and ran it. No issues. Then, when I RAM cleared, zStart did not kick in, and I've had some interesting issues when I tried to uninstall and reinstall the run on RAM clear feature, such as a ERR: MEMORY when I went to the memory clear menu, or my contrast value being 104. If run on RAM clear is not installed, I have no issues.

I'm also going to post this in the zStart topic, as I don't know which app is at fault.
Title: Re: Bug Reports
Post by: zeldaking on August 03, 2011, 04:52:27 pm
Run and pray, that sounds like what happened to me. After the memory issues I had no issues and then *whambo* I got hit.
Title: Re: Bug Reports
Post by: chattahippie on August 04, 2011, 12:33:12 am
Run and pray, that sounds like what happened to me. After the memory issues I had no issues and then *whambo* I got hit.

Did you have Axe 1.0.? or zStart installed when your calculator bricked itself? 

I hope this problem is solved so that no other projects are lost and no more calcs have to break
Title: Re: Bug Reports
Post by: mrmprog on August 04, 2011, 02:07:04 am
I think I am going back to 0.5.3. I have been using 1.0.2, but some of these reports are worrying. I have only one calc, and if that one is bricked, I will die.
Title: Re: Bug Reports
Post by: thepenguin77 on August 10, 2011, 10:58:03 am
So I made my first Axe program today, and I already found a glitch ;D

Code: [Select]
:.AXEPROG
:Disp "I'm compiled____ ;that's 4 spaces (for a newLine)

This code, when run, displays "I'm compiler____".

The assembly is:
Code: [Select]
ld hl, string
bcall(_putS)
ret
string:
.db "I'm compiler    ", 0

So it's not some homescreen glitch. I'll leave this one up to you  ;D
Title: Re: Bug Reports
Post by: Runer112 on August 10, 2011, 12:41:34 pm
thepenguin77, I have no such problem. And I have absolutely no idea what would change a 'd' into an 'r'. Perhaps by some strange chance the source got corrupted? Is it still a 'd' in the source?
Title: Re: Bug Reports
Post by: FinaleTI on August 10, 2011, 01:00:22 pm
I've had a similiar problem. It doesn't always manifest itself, but sometimes when I compile, certain letters are replaced by 'r'. Recompiling it always fixes the issue for me.
Title: Re: Bug Reports
Post by: p2 on August 11, 2011, 02:03:31 pm
iI found a bug:

If I use
Code: [Select]
:getCalc("varA")
:Disp A>Dec
It is always an Error if A is not 0 and I don't think that should be an Error!!
Title: Re: Bug Reports
Post by: AngelFish on August 11, 2011, 02:17:38 pm
I don't think that's a bug...
Title: Re: Bug Reports
Post by: FinaleTI on August 11, 2011, 04:32:21 pm
iI found a bug:

If I use
Code: [Select]
:getCalc("varA")
:Disp A>Dec
It is always an Error if A is not 0 and I don't think that should be an Error!!
There's no bug there, since you aren't storing the pointer for the real var A anywhere, and you would need to use float{} to correctly read the data from the real var anyway.
Title: Re: Bug Reports
Post by: Ashbad on August 11, 2011, 04:32:41 pm
iI found a bug:

If I use
Code: [Select]
:getCalc("varA")
:Disp A>Dec
It is always an Error if A is not 0 and I don't think that should be an Error!!

You realize all you're doing is printing the pointer to the location of the TIFP number A, right?  You're not printing it's value at all.
Title: Re: Bug Reports
Post by: ztrumpet on August 13, 2011, 03:53:28 pm
So I made my first Axe program today, and I already found a glitch ;D

Code: [Select]
:.AXEPROG
:Disp "I'm compiled____ ;that's 4 spaces (for a newLine)

This code, when run, displays "I'm compiler____".

The assembly is:
Code: [Select]
ld hl, string
bcall(_putS)
ret
string:
.db "I'm compiler    ", 0

So it's not some homescreen glitch. I'll leave this one up to you  ;D
I've had a similiar problem. It doesn't always manifest itself, but sometimes when I compile, certain letters are replaced by 'r'. Recompiling it always fixes the issue for me.
Was it in Archive each time?  Is there a chance that 'r' is the ASCII representation of reading across page boundaries?
Title: Re: Bug Reports
Post by: Darl181 on August 13, 2011, 06:08:44 pm
I recently upgraded to axe 1.0.2.
After a full mem clear and OS resend, I'm still getting bad flash errors...
For the record all that I have installed is zStart and Omnicalc through zStart.

EDIT:
I'm wondering what brought about this bad flash thing in the first place.  What change happened that caused this (though I'm guessing it's from the re-write)?  Is there a way to work around it?
Title: Re: Bug Reports
Post by: Quigibo on August 14, 2011, 02:39:03 am
The error message "Bad Flash" is unrelated to the sector issue in the previous versions (I think).  That error is only thrown when flash could not be unlocked for some reason.  I don't know what would cause that, it was more of a sanity check.  When do you get the error?
Title: Re: Bug Reports
Post by: Darl181 on August 14, 2011, 02:56:52 am
Pretty much whenever I try to compile a large program.  I compiled a key code thing fine (press 2nd, it displays 54) but when I went to compile a sprite editor, source of about 1100 and executable about 1900, it throws it.

I'm guessing the size has to do with it?  At least that's the conclusion I came to after messing with it for a bit (after backup ofc :P )

EDIT:
Quote
That error is only thrown when flash could not be unlocked for some reason.
Are there any programs that unlock flash, to see if it works?
Title: Re: Bug Reports
Post by: shmibs on August 19, 2011, 02:31:10 pm
/\i've gotten that error once or twice as well. the second time i try to compile it always works, though.

are the draw to arbitrary buffer operations not working in 1.02?
Pt-on(0,0,L1)
Pxl-on(0,0,L1)
pxl-Test(0,0,L1)
all work on the front buffer rather than L1
do i have to manually enter the address to saveScreen? i didn't think so, because Dispgraph(L1) works just fine.
Title: Re: Bug Reports
Post by: calc84maniac on August 19, 2011, 02:48:37 pm
The error message "Bad Flash" is unrelated to the sector issue in the previous versions (I think).  That error is only thrown when flash could not be unlocked for some reason.  I don't know what would cause that, it was more of a sanity check.  When do you get the error?
How do you check whether flash is unlocked or not?
Title: Re: Bug Reports
Post by: Runer112 on August 19, 2011, 02:56:48 pm
shmbis, you are correct that the pixel commands to arbitrary buffers are not working. The parser is correctly identifying the commands as arbitrary buffer commands, but it's calling the wrong entry point to the pixel routine. So Quigibo needs to fix this.

Sprite commands still work for arbitrary buffers, though. Remember, sprite commands take 3 arguments just for a normal call. ;)

I haven't checked all the other drawing commands, but I'm just going to assume they work correctly.
Title: Re: Bug Reports
Post by: Quigibo on August 19, 2011, 03:48:11 pm
The error message "Bad Flash" is unrelated to the sector issue in the previous versions (I think).  That error is only thrown when flash could not be unlocked for some reason.  I don't know what would cause that, it was more of a sanity check.  When do you get the error?
How do you check whether flash is unlocked or not?
Its when the WriteAByteSafe bcall returns nz, which I think means that flash writing permissions have not been enabled properly.  Could it mean something else?  WikiTI doesn't really explain it.

I will fix that too.  Hopefully I'll have another release tonight.
Title: Re: Bug Reports
Post by: calc84maniac on August 19, 2011, 03:50:51 pm
The proper way to check flash unlockage is by checking bit 2 of port 2. I think WriteAByteSafe will probably return the flag on any kind of failure (like passing a bad address or writing a set bit over a reset bit)
Title: Re: Bug Reports
Post by: Runer112 on August 20, 2011, 12:14:21 am
Here's a pretty nasty bug. The length() routine isn't being inserted properly; the code for checking if the ON key is pressed is being inserted in its place. And that code doesn't have a return, which can cause very bad stuff to happen... If there's some table you can easily look at that simply has an incorrect value for the length routine, perhaps you should check all the other routines while you're at it.
Title: Re: Bug Reports
Post by: Quigibo on August 20, 2011, 01:39:32 am
Oh wow, thanks.  Yeah, it was just a wrong value in the table.  Fixed that now.
Title: Re: Bug Reports
Post by: Freyaday on August 20, 2011, 01:54:46 am
Encountered in 0.5.3
GetCalc(Str1,W+Length(P)) threw a Bad Symbol at me upon encountering Length(). Changing it to Length(P)+W fixed it.
Title: Re: Bug Reports
Post by: Hayleia on August 20, 2011, 02:56:20 am
I have lots of those Bad Symbol bugs. Sometimes, I unarchive the source, re-compile (ERR: Out of mem) then re-archive it and re-compile and everything works ??? Also, removing the appvar AxeData seem to make the compiling work afterwards ??? ???
Title: Re: Bug Reports
Post by: Quigibo on August 20, 2011, 05:06:04 am
I have lots of those bugs. Sometimes, I unarchive the source, re-compile (ERR: Out of mem) then re-archive it and re-compile and everything works ???

That's not a bug.  Axe needs lots of RAM to compile, even when compiling for an app.  If you don't have enough on your calculator, it will throw an out of memory error.  Archiving the source will often free up enough memory to compile for large sources.
Title: Re: Bug Reports
Post by: Hayleia on August 20, 2011, 09:03:50 am
Yes, I was not talking about that but about the Bad Symbol bug. It says Bad Symbol (with the source archived, after 67% of 1st pass), then I unarchive the source, re-compile (ERR: Out of mem of course, after 100% of 1st pass, 0% of 2nd pass) then re-archive it and re-compile and everything works, without the original Bad Symbol "error". Sometimes, it also works with the Pic missing bug (I have the pic in the Rom)
In fact, it sees error when they aren't
Title: Re: Bug Reports
Post by: thepenguin77 on August 23, 2011, 10:16:32 pm
zTrumpet tells me that Axe makes trial apps. If that's the case, there's a really easy way to make them valid.

Here (http://wikiti.brandonw.net/index.php?title=83Plus:OS:Certificate/Headers#App_Trials_Table) is a little section I wrote on the topic, and here is some code that you can put in Axe to make an app valid.

Code: [Select]
;###############################
;validate an app
;input: b = page
; flash = unlocked

validateApp:
in a, (02)
rlca
ld de, $1F18
ld a, $15
jr nc, havePageAndAddress
ld de, $1E50
in a, ($21) ;I know
rrca
ld a, $29
jr nc, havePageAndAddress
ld a, $69
havePageAndAddress:
push af

sub b

add a, a

ld h, 0
ld l, a
add hl, de
push hl
bcall(_getCertificateStart)
pop de
add hl, de

pop bc
in a, (02)
rlca
jr c, not83PBE
ld b, $1E-$15
not83PBE:
ld a, b
add a, $15

ld b, a
bcall(_loadCIndPaged)
ld a, c
ld c, b
and $80
ld b, a
ld a, c
ex de, hl
push af
bcall(_writeAByte)
pop af
ld b, 00
bcall(_writeAByte)

ret

It even has a check to make sure it won't crash if the app trials table is zeroed. Of course the proper thing to do would be to remake the entire certificate, but you probably don't want to be doing that. Plus, if you do end up writing 00 00 to the certificate, that kind of app will still run fine, so that's really not a problem.
Title: Re: Bug Reports
Post by: Runer112 on August 24, 2011, 12:17:22 pm
Zeros() should immediately throw an error if the size argument contains a constant that has not yet been defined. Using a constant that has not yet been defined in the size argument can cause multiple problems.


And while we're on the topic of the Zeros(), any chance this old feature request could be implemented?

Can we have a feature like "Zeros()," but for any data.  For instance, something like this:
Command(1,12) would be the same as [010101010101010101010101]
Command([56],4) would be the same as [56565656]
Command(127,6) would be the same as Data(127,127,127,127,127,127)
Potentially, this command could even be used for repeating sets of data.  For instance:
Command([010203],12) would be the same as [010203010203010203010203]
Command("Text"[00],15) would be the same as "Text"[00]"Text"[00]"Text"[00]

So, what do you think?  Could this be a command?  I think it's a good idea, to avoid situations like this (http://ourl.ca/10185/195814). :)

I really like that idea. What about changing Zeros( (det() to something more universal?

I would suggest changing the token replacement to Block(). Feeding 1 argument would create a block of the specified size filled with zeroes. Feeding 2 arguments would create a block of the specified size filled with a specified value. Maybe you could even add a Block()r command for creating a block filled with a specified word while you're at it, although this probably isn't as necessary as a normal byte-filling block command.
Title: Re: Bug Reports
Post by: Quigibo on August 24, 2011, 04:33:19 pm
@thepenguin77 Thanks!  I was avoiding that initially because some people were uncomfortable with modifying the certificate page.  But if you're sure that code works, I'll try it out.

@Runer112, I would have to modify a bunch of code in order to make data recursively definable.  Either that, or just allow a single non-zero byte to be filled instead of only zeros.
Title: Re: Bug Reports
Post by: Runer112 on August 24, 2011, 04:39:11 pm
Being able to fill a block with one number (possibly words as well as bytes) is all I ever really wanted. I think the more complicated data insertion should be handled at a later date when you add macro support. ;)
Title: Re: Bug Reports
Post by: Runer112 on August 26, 2011, 11:06:19 am
It looks like you were in the middle of changing the multiplication routine when you released Axe 1.0.3. If I had to guess, I'd say you were going to make a separate routine for simple multiplication that doesn't worry about the high 16 bits of the result, while using the old routine for *^ and **. This sounds like a great idea to me. It would save about 300 cycles for most multiplications and save 5 bytes if neither *^ nor ** is used in the program, which probably fits many programs. If you wanted to go even further with this optimization, you could split off yet another routine that doesn't worry about the high 8 bits of the result for fixed point multiplication. I would personally do this because I love speed, but it's up to you.

But enough of that, back to the actual bug. Right now the two separate multiplication routines are lumped into one, resulting in an unnecessarily big multiplication routine, as the second copy is useless. *^ and ** will not work properly either, since the first routine and thus the routine that is called for multiplications is the simplified routine that disregards the high 16 bits of the result.
Title: Re: Bug Reports
Post by: Runer112 on August 27, 2011, 02:51:34 pm
Nice to see that you added the faster archive reading commands in 1.0.3. And using port 7 for applications was pretty smart, not sure why I didn't think of that. But there's one slight problem with your adaptation. You hijack p_Safety at a point where a should equal zero, but you don't set a to zero. Inserting a simple xor a before the call to p_Safety should fix this problem.
Title: Re: Bug Reports
Post by: Quigibo on August 27, 2011, 10:31:01 pm
Shoot!  I totally forgot I was experimenting with modifying multiplication and didn't revert it before releasing... But yeah that's why I was doing it, I figured since *^ and ** are used so rarely, it would be nice to have a 32bit multiplication routine for those and use the faster 16bit multiplication for *.  It would always be faster and still be smaller for most programs.

I think after these bug fixes I will upload 1.0.4 as an official stable version.
Title: Re: Bug Reports
Post by: Freyaday on August 27, 2011, 10:47:12 pm
Woot, 32bit multiplication!
Can we get the other operations too, please?
Title: Re: Bug Reports
Post by: Runer112 on August 28, 2011, 05:03:45 pm
These are pretty rare finds, but I discovered a bug with the app and not the language. Axe doesn't unset G-T mode upon opening, only Horiz mode. There's a simple fix for this, and it's actually an optimization! Changing res grfSplit,(iy+sGrFlags) to B_CALL(_ForceFullScreen) should do the trick.

Also, when I was inspecting the first few instructions of the app to see what code should be changed to fix this, I saw 2 copies of set textWrite,(iy+sGrFlags). Any reason for this?



EDIT: Regarding screen modes, B_CALL(_ClrScrnFull) in the ClrHome command should probably be B_CALL(_ClrScrn). It's exactly the same as B_CALL(_ClrScrnFull) when the calculator is in full screen display mode, which is 99% of the time anyway, but it will correctly clear the homescreen if it's not in full screen mode as well.

EDIT 2: Also, perhaps there should be an Axe command for B_CALL(_ForceFullScreen)? Axe programmers could run into this problem of not being in full screen mode and then their program displaying very strangely, especially if they're printing text to the homescreen. Perhaps another Fix command would work, but you'd need to branch into 2-digit numbers. This would also require changing how multiple options can be chained together with Fix, but I didn't really like the old way anyways. And on a similar note of OS settings that can mess stuff up, how about adding the ability to enable/disable APD as well?
Title: Re: Bug Reports
Post by: Freyaday on August 29, 2011, 10:30:56 am
Wouldn't APD only work when the OS is in control, though? I thought that that didn't really happen in Axe programs.
Also, unless #Realloc has been used, an APD would seriously screw over an Axe program, considering that the Axevars are stored at the end of SaveSScreen, to where the OS dumps the current contents of the screen on an APD.
Title: Re: Bug Reports
Post by: JosJuice on August 29, 2011, 10:51:00 am
Wouldn't APD only work when the OS is in control, though? I thought that that didn't really happen in Axe programs.
Some BCALLs give control to the OS, for example the BCALLs that that prompt the user to input text.
Title: Re: Bug Reports
Post by: Freyaday on August 29, 2011, 03:01:55 pm
Wouldn't APD only work when the OS is in control, though? I thought that that didn't really happen in Axe programs.
Some BCALLs give control to the OS, for example the BCALLs that that prompt the user to input text.
I figured that was why input was buggy (really, I did).
APD would still screw up the Axevars though.
Title: Re: Bug Reports
Post by: Runer112 on August 29, 2011, 10:55:00 pm
Returnr needs an alternate version for applications. I believe jp $4083 would work.
Title: Re: Bug Reports
Post by: Runer112 on August 31, 2011, 12:06:14 pm
I think there's a problem with the Axiom system. It looks like if you have two versions of a command, one which accepts 0 arguments and one which accepts 1 argument, whichever is first in the Axiom will always be the one used. I think that if a command is followed by an r modifier, colon, newline, or period (or any number of spaces followed by one of these), it should be treated as having 0 arguments. Otherwise, it should be treated as having at least 1 argument.
Title: Re: Bug Reports
Post by: Quigibo on August 31, 2011, 01:19:57 pm
How would you ever have 2 versions of a command that are 1 and 0 arguments respectively?  That means it would be valid syntax to both end with a parenthesis or not end with one.  If the token itself had an open parenthesis, it would be counter-intuitive that the parenthesis could never be closed in the 0 argument case, and if the token did not have an open parenthesis, it wouldn't make sense that you had to add one to close the expression in the 1 argument case.  In other words, if you find yourself in this situation, you're violating the rules of the language.
Title: Re: Bug Reports
Post by: Runer112 on August 31, 2011, 01:24:45 pm
Hmm I guess I see the dilemma. But you get around it by having commands like DrawInv (BUF). Can this style of argument addition be used for Axioms as well? You'd probably need an extra bit or two of metadata per command, which could be piled into the command type byte.
Title: Re: Bug Reports
Post by: Quigibo on August 31, 2011, 01:40:31 pm
Ah I see what you mean, so add a new command type bit that implies the token expects a parenthesis, that could work.  Alternatively, and probably better, I could enforce these rules automatically by getting the string for each token at compile time and checking if it ends with a parenthesis.  If it doesn't end in one, require one in the code if arguments are required.  If it does end in one, throw an axiom error if using it in a 0 argument case.
Title: Re: Bug Reports
Post by: Runer112 on August 31, 2011, 01:50:24 pm
Automagically checking for an opening parenthesis in the token string would be very cool. But why would you need to throw an error for the 0-argument case if the token has an opening parenthesis? I would imagine that commands should be parsed like this:

:Z-Test(    0 arguments
:Z-Test(→A    1 argument
:Z-Test()    0 arguments
:Z-Test(()    1 argument
:Z-Test(ʳ    Error
:T-Test    0 arguments
:T-Test →A    0 arguments
:T-Test )    Error
:T-Test ()    1 argument
:T-Test ʳ    0 arguments
Title: Re: Bug Reports
Post by: ralphdspam on September 01, 2011, 01:49:29 am
I'm not sure if this has been pointed out yet.
Quote from: Changes.pdf Page 2
I enforce this restriction because it optimizes your code a lot more optimized.

Spoiler For Spoiler:
successful troll is successful :P
Title: Re: Bug Reports
Post by: Darl181 on September 01, 2011, 02:53:07 am
Quote from: http://netham45.org/irc/EfNet/view.php?log=omnimaga.20110714
[13:49:44] <+OmnomIRC> (O)<calc84maniac> lol, I can tell quigibo was pulling all-nighters :P
[13:49:52] <+OmnomIRC> (O)<calc84maniac> "I enforce this restriction because it optimizes your code a lot more optimized."
:P

At this point I haven't had more than one bad flash error for about a week of use, and I tried to compile again just afterwards then it worked so idk. (also I was playing with calcsys a bit the same day so yeah)
So, I'd say it's stable for the most part when used normally ;D
Title: Re: Bug Reports
Post by: Quigibo on September 01, 2011, 04:12:50 am
That PDF was intended just for the pre-release guinea pig testers and was quickly written in just a few hours.  I planned to rewrite it for the actual release but got lazy and released it as-is without proofing it again.  Redundant statements are redundant :P  This file will be removed in all versions after 1.0.4 anyway (stable), its just for those transitioning from 0.x versions to 1.x versions.
Title: Re: Bug Reports
Post by: willrandship on September 02, 2011, 11:32:53 pm
so, I have a new bug.

When using the text command (not sure if it happens with all strings, but I haven't noticed it so far) it randomly replaces individual letters with "r", like once I got omnimagr.org, and once I got omrimaga.org. It changes every time I recompile, and sometimes (about 40%) doesn't occur, so for now I'm just recompiling till it doesn't show up.
Title: Re: Bug Reports
Post by: calc84maniac on September 03, 2011, 09:50:06 am
so, I have a new bug.

When using the text command (not sure if it happens with all strings, but I haven't noticed it so far) it randomly replaces individual letters with "r", like once I got omnimagr.org, and once I got omrimaga.org. It changes every time I recompile, and sometimes (about 40%) doesn't occur, so for now I'm just recompiling till it doesn't show up.
Yep, seems like a recurring issue (http://ourl.ca/4072/234477). Methinks Quigibo needs to fix this.
Title: Re: Bug Reports
Post by: willrandship on September 10, 2011, 01:42:11 am
It's not a big deal in small sources, but in larger progs I'd rather not have to check ALL my dialogue for random rs. :P Because sometimes it does take 3-4 compiles to get it gone completely, and it crops up in seemingly random places.

Hmm, RNG solution? :P
Title: Re: Bug Reports
Post by: Darl181 on September 10, 2011, 03:57:34 pm
Ok, I've been getting bad flash errors something like 4 times a day.  I'd just quit axe, run some asm program (from flash, using zStart) and try to compile again and it would work ???

Also, I've had a few problems with the instant goto.  I'd get err:parenthesis and goto.  Editing is fine, but once I quit some program or another will sometimes have an edited name (ie one time the archived program "SDOTRUN2" became SDOTRU►2").  thepenguin's archive cleaner fixes it, btw, but it's still kind of concerning..
Title: Re: Bug Reports
Post by: Builderboy on September 19, 2011, 02:17:44 pm
Would it be possible to get a very small update of Axe out that fixes the fixed point multiplication?  It doesn't sound like it would be a very hard fix, since the reason it got broken was a simple mistake.  Thanks :)
Title: Re: Bug Reports
Post by: Freyaday on September 20, 2011, 12:30:29 am
Encountered this in 0.5.3. No amount of recompiling will remove this, and I can make no sense of it.

I made a font viewer with a cursor. The cursor is pure decoration, and it is the char under the cursor, but in white-on-black. To fix the bits left behind on the screen when the cursor moves, I print both the formerly selected char and the one to the left of it in black on white.

You press enter to switch halves of the font, and arrow keys to move the cursor.
I will post the code later, but, to sum it up, weird shit happens when you select D6h. Even zStart avoids the char. In fact, instead of showing up as the placeholder char (a 3x3 centered, filled box in the OS font) it gets displayed as a space. (zStart displays it as a filler char, though)

tl;dr
What is up with the nonchar at D6h?
Title: Re: Bug Reports
Post by: calc84maniac on September 20, 2011, 12:32:52 am
That's the TI-Basic newline char (display it on the homescreen and you get a newline then a colon, and I don't remember what happens on the graph screen)
Title: Re: Bug Reports
Post by: Builderboy on September 20, 2011, 12:35:10 am
I thought that was 3Fh?
Title: Re: Bug Reports
Post by: Freyaday on September 20, 2011, 12:35:47 am
That's the TI-Basic newline char (display it on the homescreen and you get a newline then a colon, and I don't remember what happens on the graph screen)
That explains why it shows up like that. Thanks!
Also, that explains the weird shit.
Now to figure out how to fix it.
If statements, here I come!
Oh, and it's on the homescreen :)
Title: Re: Bug Reports
Post by: calc84maniac on September 20, 2011, 01:09:17 am
I thought that was 3Fh?
That's the token value, but D6h is the character value.
Title: Re: Bug Reports
Post by: Builderboy on September 20, 2011, 01:14:19 am
Ah I see, the character code table in TiBD must be slightly off then, because the character listed for 214 is Ö o.O

EDIT; Silly me, TiBD redirected me to the 89 area of the site  ::)
Title: Re: Bug Reports
Post by: Freyaday on September 20, 2011, 10:36:03 am
Found this in 103
The latest version of Nymless on my calc has the option to display in two, three, or fourscale (dispgraph,r,rr)
When you press the key for fourscale, the lines pause for somewhere around fifty frames, and then they start moving again.
What do I mean by "the lines"?
Why, the diagonal bands of pixels Axe uses to make its fourscale!
Also, the game runs just fine during those fifty frames.
Title: Re: Bug Reports
Post by: Darl181 on September 20, 2011, 10:38:18 am
I've had some occurrences of frozen scanlines as well, tho it's kind of random (and only happens in one program).  Maybe 1 out of 20 times.
Title: Re: Bug Reports
Post by: Freyaday on September 20, 2011, 10:39:56 am
I've had some occurrences of frozen scanlines as well, tho it's kind of random (and only happens in one program).  Maybe 1 out of 20 times.
This happens every time you press the button. D:
Title: Re: Bug Reports
Post by: Runer112 on September 20, 2011, 01:15:35 pm
Can you elaborate on frozen scanlines? If it's grayscale but the diagonal scanlines aren't really moving, like this (http://www.omnimaga.org/index.php?action=dlattach;topic=1578.0;attach=7894), that just means that the frequency of grayscale updates is near perfectly out of sync with the LCD's refresh rate, which isn't the fault of Axe. However, if you mean that the image shows up in black and white because the grayscale mask isn't being changed at all between frames, that would be a bug.
Title: Re: Bug Reports
Post by: Freyaday on September 21, 2011, 09:08:43 pm
Runer: can you provide that in a mp4? I can't view it as a wmv.

Axe: Practically every time I try to compile a source from archive, I get a BAD FLASH 0%. I UnArchive it, and it works fine.
Also, I compiled some stuff for an Application, and it no longer copies stuff from an appvar to L3
Title: Re: Bug Reports
Post by: Runer112 on September 21, 2011, 09:30:21 pm
Here is the video in GIF form. I won't actually post the image here because it's 3MB which is quite large, but here's the link:

http://img.removedfromgame.com/imgs/calc.gif (http://img.removedfromgame.com/imgs/calc.gif)
Title: Re: Bug Reports
Post by: Freyaday on September 21, 2011, 09:55:07 pm
Thanks!

And, unfortunately, the problem is not like that. The scanlines are completely frozen.
Title: Re: Bug Reports
Post by: Runer112 on September 24, 2011, 07:07:02 pm
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.
Title: Re: Bug Reports
Post by: Quigibo on September 24, 2011, 09:45:34 pm
I refuse to lose bytes and de-optimize! ;) Found an alternative the same size as the original:

Code: (old) [Select]
ld a,%11011011
or a
ld hl,flags+asm_flag2
inc (hl)
jr z,__Disp4LvlSkip
rra
ld b,(hl)
djnz __Disp4LvlSkip
rra
ld (hl),-2
__Disp4LvlSkip:
Code: (new) [Select]
ld a,%10110110
ld hl,flags+asm_flag2
cp (hl)
jr z,__Disp4LvlSkip1
jr c,__Disp4LvlSkip2
ld a,%01101101
__Disp4LvlSkip1:
scf
rla
__Disp4LvlSkip2:
rla
ld (hl),a

Its a pretty cool optimization.  Instead of the mapping (-2:-1) (-1:0) (0:-2) the new mapping is now (equal:larger) (larger:smaller) (smaller:equal) with respect to the number %10110110.
Title: Re: Bug Reports
Post by: Freyaday on September 26, 2011, 02:35:27 am
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!
Title: Re: Bug Reports
Post by: Quigibo on September 26, 2011, 03:19:03 am
Horizontal should only be unnoticeably faster... regular multiplication was the only routine that received a significant speedup, but only when you don't use ** or *^ anywhere in the code.

I've fixed the A429992 error now, I'll upload the patch soon.  I just need to find a couple other easy things to add to make the update have some kind of new features.  For that other problem, could you post some source code that caused the error (if it was indeed the compiler's fault)?
Title: Re: Bug Reports
Post by: Freyaday on September 26, 2011, 04:57:37 am
I'm using Horizontal to move the screen off to the right in an animation.

The source for MINEDIT is attached.
Title: Re: Bug Reports
Post by: Darl181 on September 26, 2011, 10:18:57 am
I've had a few problems with the instant goto.  I'd get err:parenthesis and goto.  Editing is fine, but once I quit some program or another will sometimes have an edited name (ie one time the archived program "SDOTRUN2" became SDOTRU►2").  thepenguin's archive cleaner fixes it, btw, but it's still kind of concerning..
Still exists in 1.0.4 :(
Title: Re: Bug Reports
Post by: p2 on September 26, 2011, 11:21:22 am
Fryaday, I have two!!  ;D


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...  :-\
Title: Re: Bug Reports
Post by: AngelFish on September 26, 2011, 11:22:43 am
Quigibo says he already fixed the A429992 error.
Title: Re: Bug Reports
Post by: Runer112 on September 26, 2011, 04:44:35 pm
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:

Code: [Select]
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.
Title: Re: Bug Reports
Post by: Quigibo on September 26, 2011, 05:30:20 pm
That makes so much sense now, lol!  I can't believe you were able to get that from disassembly, awesome job!

Those other 2 are not bugs though:

Tokens that are more than 1 character are clipped to create their character counterparts.  For example, the token "det(" just turns into "d" to make it consistent since these are character strings, not token strings.  Also, this is the same routine used for individual character reading in single quotes so it wouldn't make sense there either.

The 'var' token is not a 1-to-1 mapping to a character in a searchable string form.  There is an extra zero that has to be added.  It is handled separately in the string parsing routine instead, just like the string, matrix, and custom list tokens.
Title: Re: Bug Reports
Post by: Runer112 on September 26, 2011, 05:43:02 pm
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. :P

EDIT: Whoops, I meant a multi-character token.
Title: Re: Bug Reports
Post by: Quigibo on September 26, 2011, 05:49:05 pm
Whaaaaaaaaat!  It was just working!  I swear!  One sec.

Eh... I'd rather keep string parsing simple for now, so no multi character tokens.

EDIT: That was it Runer, I just found it lol.  That's what I get for coding so fast  <_<
Title: Re: Bug Reports
Post by: Oninoni on September 27, 2011, 02:28:54 am
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
Title: Re: Bug Reports
Post by: Eeems on September 27, 2011, 02:32:42 am
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
You might want to try with the new 1.0.5b that Quigibo just released today.
Title: Re: Bug Reports
Post by: Freyaday on September 27, 2011, 10:38:14 am
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
You might want to try with the new 1.0.5b that Quigibo just released today.
Gah, another new Axe :P

Nymless again.
To do a quicksave, I create the appvar NYMSAVE and then copy L3 to it, followed by all the predefined AxeVars (I have yet to code in saving for the three extra vars).
Unfortunately, something goes REALLY screwy with r3, which points to the start of the data for the mines. when you load form that save (copying the beginning to L3 and the rest to oA) all the mines are rotated 90 degrees to the left!
Title: Re: Bug Reports
Post by: p2 on September 28, 2011, 11:16:48 am
We should start a statistic how often you guys upload a new, latest version!
One every week. Or was it every day?? ;)


But I have a question!
If I save the code of another program as "H" (for example)
Why can't I use this:
:if {H+4} =5
I always must save the numbers/letters I need to search for (in the code) saved in the code, too:
:"5"->Str1
:{Str1+0}->{H+0}
:if {H+4} = {H+0}
OR:
:if {H+4} = {Str1+0}

But That's so annoying (especially if you have to save 27 different things there!!
It would have been so much easier if I could have written:
:5->X
:if {H+4} =X

Can't you please add that or tell me where my mistake is?
Title: Re: Bug Reports
Post by: calc84maniac on September 28, 2011, 12:05:17 pm
So if I understand correctly, you're trying to compare to a character value? Try using '5' in the code (i.e. surround the character with single quotes), that will convert a character directly to a usable value without needing to use a string.
Title: Re: Bug Reports
Post by: p2 on September 28, 2011, 12:07:52 pm
But how to check for a Var (X) or a Letter ("B")
Title: Re: Bug Reports
Post by: calc84maniac on September 28, 2011, 12:11:49 pm
Converting a variable X (0-9) to a number character can be done with (X+'0'). You can do letter characters the same way as number characters, for example, 'B'. Similarly, if you have a letter index L (1 to 26), you can create a character A-Z by doing (L-1+'A')
Title: Re: Bug Reports
Post by: Darl181 on September 30, 2011, 10:32:32 am
Horizontal (BUFF)- makes the calculator freeze.  No other variation of Horizontal has this problem.
Title: Re: Bug Reports
Post by: Freyaday on October 03, 2011, 03:07:00 pm
While and Repeat loops that are empty
:While getkey(54)
:End
:Repeat 0
:1
:End!If getkey(54)
Stop looping before their condition is up.
Title: Re: Bug Reports
Post by: Runer112 on October 03, 2011, 03:12:00 pm
Freyaday, I'm pretty sure loops work exactly like they're supposed to. Your problem might be key bouncing, meaning that for a small fraction of a second after depressing or letting go of a key, the key's state will bounce between pressed and not pressed. You probably don't see this when the loop contains code because the small amount of time it takes to execute that code is enough for the key's state to stop bouncing.
Title: Re: Bug Reports
Post by: Freyaday on October 03, 2011, 03:13:05 pm
Freyaday, I'm pretty sure loops work exactly like they're supposed to. Your problem might be key bouncing, meaning that for a small fraction of a second after depressing or letting go of a key, the key's state will bounce between pressed and not pressed. You probably don't see this when the loop contains code because the small amount of time it takes to execute that code is enough for the key's state to stop bouncing.
That is bizzare. Is it something physical that happens, or an electrical glitch?
Title: Re: Bug Reports
Post by: Runer112 on October 03, 2011, 03:37:49 pm
Freyaday, I'm pretty sure loops work exactly like they're supposed to. Your problem might be key bouncing, meaning that for a small fraction of a second after depressing or letting go of a key, the key's state will bounce between pressed and not pressed. You probably don't see this when the loop contains code because the small amount of time it takes to execute that code is enough for the key's state to stop bouncing.
That is bizzare. Is it something physical that happens, or an electrical glitch?

I think it's just the nature of how metal contacts act when extremely close together, but not quite touching. I'm not 100% sure, but that's my best guess.



Anyway, here are some bugs that I think are actually the fault of Axe and not strange hardware quirks. ;)

Title: Re: Bug Reports
Post by: mrmprog on October 03, 2011, 05:15:23 pm
Another thing about loops appearing to quit early. If you have a menu, or something that checks for enter being pressed at the beginning of your game, sometimes it "picks up" the enter from the home screen to run the program. Sometimes this creates the illusion of quitting early.
Title: Re: Bug Reports
Post by: Eeems on October 03, 2011, 05:26:41 pm
Another thing about loops appearing to quit early. If you have a menu, or something that checks for enter being pressed at the beginning of your game, sometimes it "picks up" the enter from the home screen to run the program. Sometimes this creates the illusion of quitting early.
That's an easy fix, just put a wait at the start of your program for until enter is no longer pressed.
Title: Re: Bug Reports
Post by: NecroBumpist on October 03, 2011, 05:55:52 pm
What's up with all the last line bugs anyway?

Lol, in the numerous parsers I've written, there has always been some fucking last line bug or another. The simplest answer I find that usually works is to append a newline character to input before processing begins.
Title: Re: Bug Reports
Post by: Builderboy on October 03, 2011, 06:08:55 pm
{CONST} or {CONST + Var} produces a 'Wrong # of Args' error D:
Title: Re: Bug Reports
Post by: Quigibo on October 04, 2011, 05:36:39 am
{CONST} or {CONST + Var} produces a 'Wrong # of Args' error D:
Thanks, I just caught that.  A workaround for now is to just add the constant after the variable: Var + CONST, which is more optimized anyway.
Title: Re: Bug Reports
Post by: Camdenmil on October 07, 2011, 01:02:59 pm
Not a very big problem, but sometimes when I try to compile an archived source, it will give an invalid token error. If I unarchive the source (and don't edit it) it compiles just fine.
Title: Re: Bug Reports
Post by: BalancedFury on October 12, 2011, 10:36:59 pm
My bro found the bug in new Axe: My bro tried to add some pics into appvar, and gave him a memory error. He had a good amount of RAM left, but still gave him it. He said it won't let him add more than 2 pics in 7680 bytes appvar. And he also said it worked well in previous version of Axe.
Title: Re: Bug Reports
Post by: parserp on October 12, 2011, 10:38:35 pm
Question: what does "Err: bad flash" mean?
sometimes it does it, and sometimes it compiles it without an error.
???
Title: Re: Bug Reports
Post by: mrmprog on October 12, 2011, 10:39:00 pm
Question: what does "Err: bad flash" mean?
sometimes it does it, and sometimes it compiles it without an error.
???
What version of Axe are you using?
Title: Re: Bug Reports
Post by: parserp on October 12, 2011, 10:41:10 pm
1.0.3 (but I need to upgrade to 1.0.5)
Title: Re: Bug Reports
Post by: Runer112 on October 12, 2011, 10:44:41 pm
1.0.3 (but I need to upgrade to 1.0.5)

Upgrade and watch the error magically disappear!


My bro found the bug in new Axe: My bro tried to add some pics into appvar, and gave him a memory error. He had a good amount of RAM left, but still gave him it. He said it won't let him add more than 2 pics in 7680 bytes appvar. And he also said it worked well in previous version of Axe.

This sounds more like a coding error than an Axe error. Perhaps if you posted the culprit code some other coders could try to assist in finding the source of the problem?
Title: Re: Bug Reports
Post by: parserp on October 12, 2011, 10:45:27 pm
1.0.3 (but I need to upgrade to 1.0.5)

Upgrade and watch the error magically disappear!
ok I will ;D
Title: Re: Bug Reports
Post by: mrmprog on October 12, 2011, 10:46:24 pm
I am no expert on the bug, but I believe it can cause some bad problems. My advice:Full back up, Full ROM clear, update to the latest stable version of AXE (the one on ticalc).
Also, if your archive is messed up, try this: http://ourl.ca/12245
Title: Re: Bug Reports
Post by: Yeong on October 13, 2011, 08:40:52 am
the code was:
Code: [Select]
.NAPPV
[Pic1]→Str1
[Pic2]→Str2
[Pic3]→Str3
GetCalc("appvS04",7680)→A
Copy(Str1,A,768)
Copy(Str2,A+768,768)
Copy(Str3,A+1536,768)
It worked on Axe 1.0.3...
but why not in 1.0.5?
Title: Re: Bug Reports
Post by: aeTIos on October 13, 2011, 09:26:10 am
I experience the same problem. I have an appvar of ~5300 bytes and the size is ok, but I always get a memory error.
Title: Re: Bug Reports
Post by: calc84maniac on October 13, 2011, 11:57:43 am
Maybe you don't have enough RAM free? Keep in mind that when you run a program with Asm() a copy of the program is put in RAM, and your program there contains multiple fullscreen images.
Title: Re: Bug Reports
Post by: Yeong on October 13, 2011, 09:10:43 pm
I did have enough RAM(like 15000+)
Title: Re: Bug Reports
Post by: Builderboy on October 13, 2011, 10:48:57 pm
would you mind posting the specific programs that give the errors, as well as the source programs so we can try this ourselves?  That would help a lot :)
Title: Re: Bug Reports
Post by: Yeong on October 14, 2011, 07:31:28 am
the code was:
Code: [Select]
.NAPPV
[Pic1]→Str1
[Pic2]→Str2
[Pic3]→Str3
GetCalc("appvS04",7680)→A
Copy(Str1,A,768)
Copy(Str2,A+768,768)
Copy(Str3,A+1536,768)
This was my code.
Title: Re: Bug Reports
Post by: Runer112 on October 14, 2011, 09:18:06 am
The variable creation routine hasn't been changed since Axe 1.0.2, so I'm pretty sure that your code should work exactly the same in 1.0.3 as in 1.0.5. I'm guessing the problem is that, upon running the program, you just barely no longer have sufficient free RAM to create the appvar. Something that you might call a bug does exist in the variable creation routine, in that it doesn't account for the size of the new VAT entry when checking to see if there is enough space for the new variable. So if you want to create a 7680-byte variable but have 7685 bytes free, Axe will think you have enough space and will try to create the variable. However you can't actually fit the variable and its VAT entry, so you will get an ERR:MEMORY.
Title: Re: Bug Reports
Post by: aeTIos on October 14, 2011, 09:19:16 am
lol, I changed straightaway from 0.5.3 to 1.0.5
Title: Re: Bug Reports
Post by: thepenguin77 on October 14, 2011, 05:43:10 pm
The API entry points don't cooperate nicely with the new Zoom feature. Sometimes it will compile as Zoom, sometimes it won't.

So basically you should make one of the bits in A represent which mode to use.
Title: Re: Bug Reports
Post by: Quigibo on October 15, 2011, 09:10:26 pm
Ah, didn't think about that.  I will add that next version and update the docs.
Title: Re: Bug Reports
Post by: Freyaday on October 16, 2011, 05:19:00 pm
when I compile a program for an app, there is a line that, instead of coypying data from an appvar into L3, it just clears L3 instead. However, it's just that one line. The exact same line elsewhere in the program works fine, and it works when I compile it into a no-stub, it works too.
Title: Re: Bug Reports
Post by: Builderboy on October 16, 2011, 05:25:15 pm
Could you post the code itself?  That would probably help ferret out the bug quicker :)
Title: Re: Bug Reports
Post by: Freyaday on October 16, 2011, 06:44:58 pm
Copy(N,L3,768)
Title: Re: Bug Reports
Post by: Builderboy on October 16, 2011, 06:56:58 pm
Where is the pointer N coming from?  That might have something to do with the issue
Title: Re: Bug Reports
Post by: Freyaday on October 16, 2011, 11:19:48 pm
GetCalc("appvNYMSCAPE")->N
Title: Re: Bug Reports
Post by: Builderboy on October 16, 2011, 11:23:45 pm
Hmmm, is the appvar archived?  Does this still pose an error if you just type those two lines and compile to application?
Title: Re: Bug Reports
Post by: Freyaday on October 16, 2011, 11:26:55 pm
Hmmm, is the appvar archived?  Does this still pose an error if you just type those two lines and compile to application?
The appvar is not archived. In fact, it is reading correctly from the appvar on  the next line, Copy(N+768,oC,12)
Title: Re: Bug Reports
Post by: calc84maniac on October 16, 2011, 11:33:15 pm
Hmmm, is the appvar archived?  Does this still pose an error if you just type those two lines and compile to application?
The appvar is not archived. In fact, it is reading correctly from the appvar on  the next line, Copy(N+768,oC,12)
That copies the data to the variables C,D,E,F,G,H. Is that what you wanted?
Title: Re: Bug Reports
Post by: Builderboy on October 16, 2011, 11:34:29 pm
How are you checking whether or not L3 is cleared or not?
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 12:25:15 am
Hmmm, is the appvar archived?  Does this still pose an error if you just type those two lines and compile to application?
The appvar is not archived. In fact, it is reading correctly from the appvar on  the next line, Copy(N+768,oC,12)
That copies the data to the variables C,D,E,F,G,H. Is that what you wanted?
Yes.
How are you checking whether or not L3 is cleared or not?
ClrDraw
DispGraphrr
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 12:35:55 am
Hmm i can't seem to replicate it, can you replicate it just by using those lines of code like you showed me?
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 12:52:57 am
Hmm i can't seem to replicate it, can you replicate it just by using those lines of code like you showed me?
It works fine when I put just those lines into an app. However, there is a lot of other code, including the same line changed only in variable elsewhere (this is a multi-file source wherein the programs are intended to also work as standalones)
However, I checked to see if the peephole optimizations are at fault by pressing ZOOM instead of ENTER, and the same problem occured.
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 01:09:05 am
would you mind posting the entire faulty code in that case then?  Are all these lines right after each other or are they spaced out?  Is it possible you are accidentally modifying the value of N somewhere, or clearing the screen?
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 01:19:56 am
It's a lot of code. I'll post it later, when I get a chance. There's no chance N is being messed with, as the two lines are separated by :If N, and the copy to °C works.
Oh, and Axe said a duplicated constant definition in two files was an ERR:DEFINE BEFORE instead of ERR:DUPLICATE
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 12:02:07 pm
I changed all the references to L3 to that of a temporary appvar, including the DispGraphrr.
It displayed the exact same behavior. Also, the If N still triggered even when there's no appvNYMSCAPE in RAM. Either that, or the RectIs are failing in the Else statement
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 01:07:48 pm
Try outputting the value of N right after the GetCalc statement, to see if it really is 0 when there is no appvar.  Maybe the If statement is getting triggered or some other problem that is not being seen.  The fact that we can't replicate this in the base case makes me think either the bug has to do with different combinations of code, or there is something about your code that is not behaving the way you expect it to.  Until we see the whole chunk of code though, it's hard to debug D:
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 01:15:18 pm
WTF. I added
ClrHome
Disp N>Dec
Repeat GetKey(41)
End
anfter the getcalc and it works perfectly now!
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 01:20:26 pm
o.O And if you remove that code, it goes back to not working again?  Are you using L5 at any point?
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 02:48:06 pm
I have tried many variations of the code, and it seems to only be that one that makes it work. I do not use L5 at any point.
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 05:43:28 pm
Well that's strange o.O Really it's hard to make any more progress without the full code though, as it's probably a combination of many things that is causing this bug to happen.
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 06:04:52 pm
Here are all the code files. The one we've been talking about is LVEDIT.
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 07:00:44 pm
Hmmm I couldn't replicate the bug, even removing the displaying of N.  Try outputting the String that you are using to access the appvar, I have had some instances of Strings getting corrupted, even in the newer version of Axe (btw what version are you using?).
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 07:08:43 pm
Hmmm I couldn't replicate the bug, even removing the displaying of N.  Try outputting the String that you are using to access the appvar, I have had some instances of Strings getting corrupted, even in the newer version of Axe (btw what version are you using?).
That's bizarre. Are you sure you have the right file? Because it's theta in the code. I tried changing the var to see what happened, it didn't work, so I changed it back. When I wrote the initial post, I was using N, and I kept referring to it as such to be consistent.
Also, the GetCalc works fine, because the Copy(theta+768,oC,12) works just fine.
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 07:12:05 pm
Yeah I know its theta in the program, I was just referencing the previous code you had posted.  And also what was the version of Axe you used?  Maybe I'm using a different version
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 07:13:14 pm
Yeah I know its theta in the program, I was just referencing the previous code you had posted.  And also what was the version of Axe you used?  Maybe I'm using a different version
Kk, just making sure.
I am using 1.0.5
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 07:23:39 pm
Yep same here and no issues o.O This is really strange...
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 07:27:26 pm
I put a Goto around the added code, to make it never reached, and, as I suspected, the compiled program still works.
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 07:29:55 pm
Hmmm, so maybe it has something to do with the total size of the program?
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 07:36:56 pm
Hmmm, so maybe it has something to do with the total size of the program?
Then why did it still not work when, without those lines of code, I pressed ZOOM?
I checked, and the code w/o the peephole optimizations was still bigger than the code with the extra lines.
Also, are you compiling to an App?
Title: Re: Bug Reports
Post by: Builderboy on October 17, 2011, 07:38:23 pm
Yeah i always try with and without app, and they have been the same all times.  Probably the best thing to do now is to get a version that doesnt work, and have someone look at the binary to see what it's *actually* doing

EDIT: also see how much of the program you can remove before it stops producing the error
Title: Re: Bug Reports
Post by: Freyaday on October 17, 2011, 07:48:07 pm
Here's the bad app.
Title: Re: Bug Reports
Post by: Michael_Lee on October 18, 2011, 11:13:17 pm
From the Q&A thread:

Okay, I'm sure that this is just stupidity on my part, but I just can't see a bug in this.

Axe 1.0.5

Code: [Select]
.ZA

Text(0,0,F(5,6)>Dec)
Text(50,0,F(6,5)>Dec)

Text(0,10,F((6-1),(6+1))>Dec)
Text(50,10,F(6,6)-1>Dec)

Text(0,20,F(6,(5+4))>Dec)

Text(50,20,F(6,5)+F(6,4)>Dec)


Pause 5000

Lbl F
r1*r2+r1+r2
Return

Compiling halts at 57% during the first pass -- error message: "WRONG #