0->A
1->B
If A=0 or B=0
Output(0,0,"HI
EndIf A=0 or B=0
If ((A=0) or B)=0If A=0 or (B=0):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
:
:ReturnWhile K=/=9
getkey->K
Disp K
Disp i
End
getkey->K
X+(K=2)-(K=3)->X
0->F
While getKey!=15
Output(0,0,2*F
Output(0,1,F+F
F+2->F
Pause 100
EndHmmm it seems that Axe computes 16*16*16 as Zero :(Yeah, that should come out to 4096 (which is less than 65536).
Its not above the maximum value right? Maximum for real numbers is 2^16 665536 if i remember correctly...
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.
output(2,2,"hi
clrHomerun that then open a menu and close it again. When you close it 'hi' will show up again...
#^rand->AAh 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
[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 [] ))Hmm, how hard would it be to add something that when it errors it tells you what line it's on?
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.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.
Remember, me giving you the freedom to run lower level assembly code and commands is a trade-off with the safety of running it.
: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
0->{L1}
8*{L1}->AOk found the problem code, its when you multiply a value by data read from RAMWhat happens if you put parentheses around the braces?Code: [Select]0->{L1}
8*{L1}->A
Gives a very weird happening.
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 :)
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
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+.
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.oMaybe 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.
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.
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?
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:If {X*3+L1}=1
Pt-Off({X*3+L1+1},{X*3+L1+2},Pic1
End
repeat F
If Y>0
Y-1-->Y
end
endexcept that F is set by something and there's a couple more conditions, but they are kinda irrelevantYou 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
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.
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...
The bad symbol is somewhere in your code, not in the header.
Is this intentional?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)
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
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.I especially like being able to do things like Fill(0->{L1},15)
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.
-2→A
A/2→A-2→A
-(-A/2→A
Wait, what do you mean "by zero"? Anytime you divide by zero the calculator is supposed to explode! (or return -1)I thought division by zero results with Axe were >9000? :P
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.
[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
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.
I think you're just missing the parenthesis. You need them for logic operators, at least on all the arguments after the first one.oh thanks I forgot about parhentesises for that x.x
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.
:.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)
"Axe" instead of "Axe "
I don't think he added that feature yet.It's available actually because he mentions it in the doc
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.
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
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 :/
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 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.
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...?
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.
Oh yeah, you're right, I forgot to check if its archived :-X Thanks for helping me find that problem!
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
.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
alright. Err: Undefined
Tribal said this compiled correctly in 2.4... I used 2.5Code: [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
91-sub(CS)91-(sub(CS))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))
what would sub-routine usage in expression do?
91-(sub(CS))Lbl CS
S=8*2
Return{V+2}r→T
T→{L1+2}rSo if i understand you correctly, you are saying that storing 2 byte numbers works incorrectly because it stores the bytes in backwards order?
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)
Right. That is exactly how I did it on the calculator. Token for token, hex for hex, and number for numberThat shouldn't be happening, I'll look into it.
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
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
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. :)
I after reading the these reports, I would recommend to NOT use the error scrolling features until I figure out what the bug is.
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.
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)
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)
Bug report with Text command (or boolean logic):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(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")
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.You need to garbage collect. I could have Axe ask you periodically, but I think it would get annoying.
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.
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'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. :)
i accidentally press enter while at home screen. ( last prog run before failed compile was the successful compiled prog )
2.53, I take it. And that sounds bad... But then again, it's 2.53...correct it is 2.53
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?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.
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.
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
:.TANGENT
:Lbl T
: sin(→A)*256//cos(A)
ERR: UNKNOWN ERRCode: [Select]:.TANGENT
:Lbl T
: sin(→A)*256//cos(A)
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
Aaaah ok ^^
I hope you stay interested in programming those little machines for a while ^^
@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.
Okay, I think I might know what the problem is. Can those who had problems confirm this:No, that can't be the issue. The OS knows what it's doing when it messes with archive.
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.
What do you mean? You can't really replicate it because it's random.Failed 3 out of 5 times, sounds pretty replicate-able.
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.
I THINK I MIGHT HAVE FOUND IT!Oh, you seriously haven't been checking for page switching? That could explain it. :P
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...
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.
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?
DrawInv
Shade(63)
DispGraph
Repeat getKey
End
Shade(47)before the suspect code lets you see the differencei 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...
0->L+3->J
deltaList(46,59->String0
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.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.
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.
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.
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?
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.
.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?...
1st Pass: 28%getKey() only supports constant values. getKey(X) is an invalid statement.
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].ASBCOh, 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?...
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
:Goto AB:Sub(AB,A,B
:Return:Goto AB,A,B
I hit "compile" on the main Axe menu and the calculator crashed....That happened once to me too (on 0.2.6). I have no idea why. ;.;
I am not sure as to why..maybe I have too much stuff on my calc (omni, os 2.53, zStart, and mirage hooks)
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 clearedThat 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.
Pt-Off(2,2,1+1+1+1+Pic3This also happens if you hide archived programs. :)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 clearedThat 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.
:.PRGONE
:[Pic0]→Pic0
:[Pic1]→Pic1
:"vGNTPICS→Str1
:GetCalc(Str1,1536)→P
:Copy(Pic0,P,756
:Copy(Pic1,P+756,756
:.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
:.PRGONE
:[Pic0]→Pic0
:[Pic1]→Pic1
:"vGNTPICS→Str1
:GetCalc(Str1,1512)→P
:Copy(Pic0,P,756
:Copy(Pic1,P+756,756
:.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
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--
:Copy(Pic0,{L6},756)
:Copy(Pic1,{L3},756)should be: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().
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....
:{3,2,1→{L3}
:{5,4,2→{L6}
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?
Disp C►Char
C→Ans
No, the problem is that L3 shows up as {L3} in Sourcecoder, which is a valid (and completely different) Axe statement.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#100793Code: [Select]:{3,2,1→{L3}
:{5,4,2→{L6}
.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.:.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...:.PRGTWO
:"vGNTPICS→Str1
:GetCalc(Str1→P
:conj(P,L6,756
:StorePic
:conj(P+756,L6,756
:Repeat getKey(0)
:DispGraph^r
:End
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 :-\
yeah but what I meant is does it happnens on the real calc too?Yeah, unfortunately it does. :(
So i am having a slight problem with the error stroller. Specifically a piece of code like thisCode: [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.
.TEST
!If -1→A+1
Disp "HI"
Pause 5000
EndCompiles to 58 bytes, while the following program:.TEST
If -1→A=-1
Disp "HI"
Pause 5000
EndCompiles 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.Because then you wouldn't be able to use it with logical operators. Good luck trying to do A=5 xor (B=3)
If A-5 xor (B-3)
In binary,
%00000001 = 1
%00000010 = 2
apply xor to each bit
%00000011 = 3
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? :)
.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->CMost 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.
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"
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!
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.
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. :)
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. :-\
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
*bump*You'll need to get Quigibo, probably w/Brandon's help, to fix this.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
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.
When I App compiled the interrupt based music player example Quigibo uploaded, it would crash whenever I ran it.I thought interrupts weren't usable in Apps yet.
Would this just be because I didn't send it to my computer and recompile it? Or is this an Axe bug?
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 :)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?
Pause A/10
with A = 0, the calc freezes for a pretty long time..BUG
Circle(47,31,31
DispgraphThe compiler pauses for a second or two then says "Error:Out of Mem" and pressing prgm takes me to the Dispgraph statement
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?
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
the getkey->G was very inportant in my program because u would have it double check with getkey(...)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.
for example if i press left, down, and enter; it acts as if i were holding down +.
PRGM:HELLOWLD
:End
:PrintScreenClearEntriesLOLOLOL
Instead of likePRGM:HELLOWLD
:
:
:A+2->A
:
:
:
:End
:PrintScreenClearEntriesLOLOLOLIn 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.AXEPRGM
0→{L₁}.AXEPRGM
[Pic0]→Pic0
A*2→{8*12+Pic0}.AXEPRGM
0→{L₁.AXEPRGM
[Pic0]→Pic0
A*2→{8*12+Pic0}
Pause 5000.AXEPRGM
0→{L₁}r.AXEPRGM
Copy(L₃,L₆,{2+L₂}
getKey->G
Disp GgetKey->G
bG->G
Disp G.B
5->{L1}
GetCalc("L1",1)->A
{L1}->{A}
Text(0,52,C^213*256▸Dec)
Text(0,58,C^213*256/213▸Dec) ld hl,25600
ld a,213 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 bcThat'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?
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
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).
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
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.
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.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?
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
um... this is supposed to happen, right?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.
(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 helpCode: [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
@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.
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.
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 pxl-Test(58-Z, X->P fixes the problem for me.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 likenot(pxl-Test(50-Z/7,round(70+X/7,0->PThat'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...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.
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
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 -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.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:-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.Code: (Axe BASIC) [Select]:If -1 and 0will always display "Hi!".
:Disp "Hi!"
:End
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).
asm(FALL1which kept returning thisasm(FALL1
Donewithout actually executing the code (which worked fine for the past several weeks)Sin(A????????rref((or something vaguely like that)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.These two sound like you ran a program that corrupted something. I doubt if it's the Axe App itself. :)
...
But when I go back up to highlight it, it turns into a weird combination of symbols, like thisCode: [Select]Sin(A????????rref((or something vaguely like that)
I had to reset my RAM, but it hasn't happened again.
Also, once, I kept trying to run my program (no shell), like thisThis 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. :)Code: [Select]asm(FALL1which kept returning thisCode: [Select]asm(FALL1
Done
I am intrigued.I wasn't aware that it doesn't?
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?
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,loopBasically, 65535+1 is less then 65535 ;) 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: 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: 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:
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.I am intrigued.I wasn't aware that it doesn't?
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?
That makes it more cool to own a 83+SE ;DYup! ;D
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)This is leftover data in L6. If you use L6 in your program, you should have a ClrHome near the end. :)
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.
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)This is leftover data in L6. If you use L6 in your program, you should have a ClrHome near the end. :)
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.
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)
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 :PThough, 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()
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.
Compiling
1st Pass 41%
1->{Y*12+X+GDB1}
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.
1->{L1}->{L5+4}
and I would really like to, because I am told that it is much more efficient this way.
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...
1->{L1}r->{L5+4}r
Output(0,0,{L5+4}r>dec.B
L1->Q
1->N+1->O
1->{Q+O}->{Q+N}
which gives me a 37 ???
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
.AXEPARSE
[FFFFFFFFFFFFFFFF]->Pic1
fnInt(R,0)
Repeat getKey(15)
FnOff
DispGraph
FnOn
End
LnReg
Return
Lbl R
Pt-Change(0,0,Pic1
Interesting that it's still in 0.4.4...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.
.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
.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
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.
ERR: UNKNOWN ERR
Code: 4423816
and after this a RAM clear.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.
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.
Ah I see. I guess it's a conflict between both apps, then. Also try to not double-post :P.
I'll try it.
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 :PI'll try it.
COMPILING...
1st Pass: 100%
2nd Pass: 100%
Writing App...
15258 Byt 95%
ERR: UNKNOWN ERR
Code: 4435555
input acts funnily...
prgmBASIC
[code=BASIC]Input "THE GAME: ",AprgmAXE when compiledinputRunning these two programs in the order given, My screen will look like this: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.
Quote from: Michael_LeeYes - 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.
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.As you are probably aware, there is a leak-free (or less so) version of _GetKey, undocumented and called _GetKeyRetOff ;D
There isn't a way to fix the memory leaks since this is an OS call.
Quote from: Michael_LeeYes - 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.
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.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.As you are probably aware, there is a leak-free (or less so) version of _GetKey, undocumented and called _GetKeyRetOff ;D
There isn't a way to fix the memory leaks since this is an OS call.
I wonder if something similar exists for the input bcall...
Good luck making it work! :)
Yeah this is why it's better to reset every now and then x.xQuote from: Michael_LeeYes - 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
Nah, this is an undocumented OS call, which is different from an undocumented Z80 instruction. It should work just fine.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.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.As you are probably aware, there is a leak-free (or less so) version of _GetKey, undocumented and called _GetKeyRetOff ;D
There isn't a way to fix the memory leaks since this is an OS call.
I wonder if something similar exists for the input bcall...
Good luck making it work! :)
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?
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. :)
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. :)
"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 SSo, 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)0->C
Lbl S
X-1+16not(X->X
C+1->C
If not(X
Goto S
Disp C
Is the "65536->Ans" line a typo, though? It seems like it should be "65535->X"* ZTrumpet feeds himself to the lobster. :(
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?
Oh right I remember that. When exiting games with clear, the homescreen content is cleared almost in an instant.
While getKey(15)
End
I think the solution is to put a simple getKey before the program exits. That will read and clear out the recorded keypress.
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.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 might work, actually.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
GetCalc("appvARCHIVED",Y1
Copy(Y1,L6,768
DispGraphYou can use Copy( and { with them.0->H
For(P,1,4
P->{°Y1
For(X,E4000,E7FFF
X->{°Y1+1
{X}+H->H
End
EndYes, 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.)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->HYes, 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.)
For(P,1,4
P->{°Y1
For(X,E4000,E7FFF
X->{°Y1+1
{X}+H->H
End
End
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.
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
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.
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...
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.
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 :(
Just found 1 bug. It seems impossible to Copy( anything with the archive as destination (Y1 for example).How is that a bug?
It gives the error file misuse.
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.
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
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!
Ummm. not sure if this has been mentioned yet, but are Axe programs supposed to disable MirageOS [ON] functions after a while?
0->A
Repeat getkey(15)
output(0,0,A>Dec
A+1->A
End
* calcdude asks Quigibo to document how instructions affect interrupts. (More specifically which ones turn them on/off)
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.
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...
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 . :)
:.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)
For those who can't open the file for any reason or can't access SC2 here's Guy602665 code below:
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.
Ok. :)how do you mean? you can set letters in a string, but you cant create StrHEY or so
So it is not possible to create a string with letters? :(
"MON TEXTE"→Str1
I would like to do something like that:that is possible. to display that, you should use:Code: [Select]"MON TEXTE"→Str1
"MON TEXTE"-> Str1
[00]
Text(Xpos,Ypos,Str1)
That should work
It seems like DCS7 doesnt support descriptions when I compile an axe code to an Ion prog.
Ah I see. So this is definitively an issue on Axe's side.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?
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.
;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::!If EXP1
:.Code
:ElseIf EXP2
:.Code
:End:If EXP1=0
:.Code
:ElseIf EXP2
:.Code
:EndNot 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.
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.
???
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?
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:
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.
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.
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.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.
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.
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 ???
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.
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
([01234567])*2→A
For(E,0,7)
Text(E*10,0,nib{A+E}>Dec)
End
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 :(
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.
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.. ???
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
[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
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.
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.
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(
He says that with the code you just quoted now, he still gets errors even if he actually closes the parhentesises.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.
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.
But he said that the compiler errored when he did close the quotes, and worked when he left them open.
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.
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.
DelVar [04720000]
If GetCalc([01720000],9)->V
1->{V-2}r
93->float{V}
EndBUG: 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?
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?Wait, your text command doesn't have an opening parenthesis?
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?
Port has disappeared from the commands.
is this supposed to happen, I keep getting bad symbol error. :banghead:Did you try closing all your parenthesis?
EDIT: After reading your edit, this is definitely what happened.
BTW: I have to thank Runer for the Avatar.
BTW: I have to thank Runer for the Avatar.
Try this one on for size :) Can me modified in whatever way you want
Simple bug: the *-1 auto-optimization is missing.BTW: I have to thank Runer for the Avatar.
I remember making that! ;D
[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
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)?
...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))...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.
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.
Now we can all play WFRNG properly ;DYep! But we have an OS for it, though...
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
EXP→DispGraph :'( don't work in last update :ERR: UNKNOW ERR
Code: 4726231
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
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?
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.
.B
getKey
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)
I assume you're talking about the 3 level grayscale right?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=
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 :(
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.
That's true... happybobjr, have you ran ALCDFIX first? There's also something like that built into DCS now that does the same thing.
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: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?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...
It seems that there is a bug in the curly bracket command. I've noticed that when I do this,Code: [Select]If {L1+70that something is always executed, rather than stopping when {L1+70} reaches zero. But when I do this:
.do something
{L1+70}-1->{L1+70}
EndCode: [Select]If {L1+70the code works correctly, no longer executing when {L1+70} hits zero. Do you know what's going on?
{L1+70}->I
.do something
I-1->{L1+70}
End
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>
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. :)
Maybe Axe got corrupted? Try redownloading it (make sure it's 0.4.8).
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).
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.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
Okay, IDK what's wrong with this.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.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.Spoiler For code:
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. ???
0->{L1}
1->nib{L1*2}
Disp nib{L1*2}>Dec
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
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.Shouldn't that be
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.
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.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.
Is it a bug? If not, feel free to move this post somewhere else. Anyway, it's freaking weird.
Garbage Collect didn't worked. But I reseted the apps mem and it worked.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.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.
Is it a bug? If not, feel free to move this post somewhere else. Anyway, it's freaking weird.
In the meantime, to get your memory back, try a Garbage Collect. If that doesn't work, do a Mem Clear.
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)
I found a bug:Yeah, I reported this a long while ago as well.
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
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.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.
Code: (Old) [Select] p_GetCalc: | | Code: (New) [Select] p_GetCalc: |
Code: (Old) [Select] p_NewVar: | | Code: (New) [Select] p_NewVar: |
Code: (Old) [Select] p_GetArc: | | Code: (New) [Select] p_GetArc: |
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:
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. |
L3->DispGraph and L6->DispGraph both producedThis 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:
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.
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.L3->DispGraph and L6->DispGraph both producedThis 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:
Unknown Err
Code: 4726231
on the 1st pass. When I pressed prgm, the cursor was on DispGraph both times.Code: [Select]Copy(P,L6,768)This will take up the draw buffer, but not only will the picture appear, you can also draw on it.
DispGraph
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.
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.
I've used as many as 20 in a row, it might be another problem with your code.
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.
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).
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.
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.
A and not(B) throws an symbol error :( it seems not() cannot be used inter expression?
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. I would suggest the following changes.
L3->DispGraph and L6->DispGraph both produced
Unknown Err
Code: 4726231
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.
If I use Else!If more than 11 times consecutively, the parser throws ERR:BLOCK
btw there's some complex Pt-On( 's between them, maybe it could have to do with # of bytes in the block?
[0000000000000000]->Pic0->Pic2
Does not work.
:[0000000000000000]→Pic0
:[]→Pic2... I just thought it would be cool to capture [2nd][off] as a keycode.It is
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.
If I recall correctly, B_CALL(_getkey) can cause problems if the user shuts off the calculator during it.
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.
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
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.
That a bug, too. DispGraph should work at either speed.
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.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).
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.
Also, why are all your apostrophes preceded by backslashes? Is that on purpose, or is that a bug?
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?
If changing the clock speed doesn't harm the CPU, then why is overclocking so bad?
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...
{L₃}ʳ→X
°VAR Returns the pointer to the variable.
/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
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.
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₄))ʳ
What? O.O
Do you have the code? Maybe it's a different bug. Jumping all over the program works for me.
For loops give an Err:Bad Symbol when the looping var is multiple letters.
Uhh, I'm pretty sure Axe supports Vars with up to three chars in their name. r1-6 are also Axe vars.
I was confused, sorry.** isn't signed multiplication. Normal multiplication works for signed and unsigned numbers. ** is actually fixed-point multiplication.
But I'm pretty sure this isn't supposed to happen:
-3**A//4->A
Always returns 0
Ohhh. I need to read the documentation more often. :P What about // ?// is correct for signed division.
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...
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....
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?
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.
I have an old model calc, though. =/I do as well, and I've never encountered that problem.
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: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:
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: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:
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.
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.
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.
I JUST DISCOVERED A HORRIFIC BUG!!!1Spoiler For Horrific bug:
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:
A few suggestions/bug reports regarding the new version of Axe:..Seconded. Please. Thank you. ;D
- 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.
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!
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.
Commands.htm still says that DispGraphr and DispGraphrr will not work at 15MHz.I'll fix that.
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...
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.
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!
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.
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.
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.
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
GetCalc(Str0L)→P
!If P
GetCalc(Str0L,384)→P
0→{P}?Fill(P,384)
End
[F0F0F0F00000?000]→Pic0N
[0060600000000???????SEEDIT2: did true ram clear via mem menu, not happening anymore.
By the next version perhaps? :PQuoteCommands.htm still says that DispGraphr and DispGraphrr will not work at 15MHz.I'll fix that.
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
I re-uploaded a fixed version so you won't have to wait until 1.0.0 :)
ClrDraw
For(A,0,767)
{A+L6} and (255)→{A+L6}
EndMakes a solid black screen. Works fine. However,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.For()
.Loopy stuff
EndIf condition
doesn't work.
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
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
Hmm, I was just thinking about this, and Hot Dog, is there any chance you were on a Math Print OS?
Code: [Select]apiEntryPoint:
cp 5
jr c, $+3
xor a
;$$
ld ($886B), a
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
:.SOMENAME
:{Y1+{Y1+9}+10}r . Don't bother saving the result.It should read a random word and do nothing, right? It crashes.
:AsmProg
:C7No Axe needed.DoneCode: [Select]:AsmProgNo Axe needed.
:C9
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.
???
If I use a xLib command, It says error.
There's another little problem in Axe:Make sure they're not two-byte tokens?
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.
X*{Y₁+13}*9→A
Else
{Y₁+12}ʳ→A
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
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!
.DROD
.DROD8x v0.0 "ROACHIE"
.DATA
prgmD8XDATA
.INIT
prgmD8XINIT
.MAIN
prgmD8XMAIN
.AI FUNCS
prgmD8XAI
.DRAW FUNCS
prgmD8XDRAW
.ROOM LOADER
prgmD8XLOADp_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
- 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.
I think I found a strange bug: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.
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.)
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.
.AXEPRGM
"Hello World!"->Str1
Disp Str1
clrHome
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.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)
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:
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.
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.
Code: (Old code) [Select] p_GetArc: | Code: (New code) [Select] p_GetArc: |
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.
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.
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.
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.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.)
{L1} = level width
{L1 + 1} = level height
X & Y = slime's top left coordinates
U & V = camera's top left coordinates
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
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!
Run and pray, that sounds like what happened to me. After the memory issues I had no issues and then *whambo* I got hit.
:.AXEPROG
:Disp "I'm compiled____ ;that's 4 spaces (for a newLine)
ld hl, string
bcall(_putS)
ret
string:
.db "I'm compiler ", 0
:getCalc("varA")
:Disp A>DecIt is always an Error if A is not 0 and I don't think that should be an Error!!
iI found a bug: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.
If I useCode: [Select]:getCalc("varA")It is always an Error if A is not 0 and I don't think that should be an Error!!
:Disp A>Dec
iI found a bug:
If I useCode: [Select]:getCalc("varA")It is always an Error if A is not 0 and I don't think that should be an Error!!
:Disp A>Dec
So I made my first Axe program today, and I already found a glitch ;DCode: [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?
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?
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.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?
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 ???
;###############################
;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
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.
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).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.
| :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 |
I enforce this restriction because it optimizes your code a lot more optimized.
[13:49:44] <+OmnomIRC> (O)<calc84maniac> lol, I can tell quigibo was pulling all-nighters :P:P
[13:49:52] <+OmnomIRC> (O)<calc84maniac> "I enforce this restriction because it optimizes your code a lot more optimized."
so, I have a new bug.Yep, seems like a recurring issue (http://ourl.ca/4072/234477). Methinks Quigibo needs to fix this.
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.
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!
I thought that was 3Fh?That's the token value, but D6h is the character value.
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:
Code: (old) [Select] ld a,%11011011 | Code: (new) [Select] ld a,%10110110 |
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 :(
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
Hi i just downloaded Axe 1.0.4 and wanted to compile a code i made with 1.0.2 into an app.You might want to try with the new 1.0.5b that Quigibo just released today.
After backupping an unknown error appears :
A429958
If you close it the app still works normally
Gah, another new Axe :PHi i just downloaded Axe 1.0.4 and wanted to compile a code i made with 1.0.2 into an app.You might want to try with the new 1.0.5b that Quigibo just released today.
After backupping an unknown error appears :
A429958
If you close it the app still works normally
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?
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?
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.
What's up with all the last line bugs anyway?
{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.
Question: what does "Err: bad flash" mean?What version of Axe are you using?
sometimes it does it, and sometimes it compiles it without an error.
???
1.0.3 (but I need to upgrade to 1.0.5)
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.
ok I will ;D1.0.3 (but I need to upgrade to 1.0.5)
Upgrade and watch the error magically disappear!
.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...the code was:This was my code.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)
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?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)
Yes.That copies the data to the variables C,D,E,F,G,H. Is that what you wanted?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)
How are you checking whether or not L3 is cleared or not?ClrDraw
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)
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.
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 versionKk, just making sure.
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?
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.5Code: [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 # OF ARGS".
Pressing [pgrm] jumps to the sixth 'Text'Code: [Select]Text(50,20,F(6,5)+F(6,4)>Dec)
^
(In case anybody was wondering, I was brute-forcing a solution to an SAT problem (in my defense, I was feeling too tired to be clever)).
Pick that post back up and take it right on over to the bug reports thread, because that's definitely Axe's fault, not yours. It's treating +F as adding the variable F instead of noticing the opening parenthesis immediately following it and treating it as adding the return value of a function.
I found freyadays bug, it was in his code and not in AxeYeah. I am not used to weird code interactions like that so....
Code: (axm.z80) [Select] #include "Axe.inc" | Code: (A) [Select] :.AA | Code: (B) [Select] :.BB |
Code: (AA) [Select] ld hl,$9d9c | Code: (BB) [Select] ld hl,$9d9c |
Copy(L₆,GetCalc("Pic0"),756)
Fails when peep-hole opts are enabled:Code: (Zooming...) [Select] ld hl,plotSScreen | Code: (Compiling...) [Select] ld hl,plotSScreen |
jacobly, what do you mean by that? Do you mean it doesn't display correctly? How do you think it should be displayed? o.O
In the mean time, "LA" can be replaced with [015D]"A".
[21:02:28] Runer112 it also happens with one-byte variable reads
[21:02:48] Runer112 but the address has to be a constant
:.TEST
:[FFFFFFFFFFFFFFFF]->Str1
:0->{L1}
:0->A
:Pt-on(8,8,8*{L1+A}+Str1
:DispGraph
This gives the "Wrong # of Args" err. Is this a bug, or am I just stupid?
Code: [Select]:.TESTThis gives the "Wrong # of Args" err. Is this a bug, or am I just stupid?
:[FFFFFFFFFFFFFFFF]->Str1
:0->{L1}
:0->A
:Pt-on(8,8,8*{L1+A}+Str1
:DispGraph
{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.
Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",)->B
Copy(A,B,48I know exactly what is causing that error. It is as runner said, the peephole optimizer. There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:Code: [Select]Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",)->B
Copy(A,B,48
The current offset in the code is 48 and you were using 48 at the same time to specify the size. It also happens to be in a pattern that normally peephole optimizes. So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes! You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data. Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.
ld hl,Data000
ld (axv_A),hl
ld hl,Data001
push hl
ld hl,48 ;I'm still here
call p_NewVar
ld (axv_B),hl
ld hl,(axv_A)
push hl
ld hl,(axv_B)
push hl
ld hl,48
pop de
;Note the abrupt end
p_NewVar:
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:
Data000:
.block 48
Data001:
.db AppVarObj,"MTEMP",0
0->I
For(I,1,8)
rand^16->{I+L1}
End
0->I
For(I,1,8)
Output({I+L1},I,"*")
End
Pause 5000
It ran fine, but upon returning to the home screen it filled with garbage. Free RAM hit 0.For(I,1,8)
rand^16→{I-1+L₁}
End
For(I,1,8)
Output({I-1+L₁},I-1,"∗")
End
Pause 5000
I know exactly what is causing that error. It is as runner said, the peephole optimizer. There is currently a bug where Axe confuses offsets with constants and is turning your code into exactly this:Aha, so this must be why the Essence editor truncates randomly...Code: [Select]Data(0,0,0,0,0,0,0,0,0,......)->A
GetCalc("appvMTEMP",)->B
Copy(A,B,48
The current offset in the code is 48 and you were using 48 at the same time to specify the size. It also happens to be in a pattern that normally peephole optimizes. So now its attempting to create an appvar with a size equal to the pointer which is a number around $9E00 which is over 40,000 bytes! You can fix this temporarily as Runer said by using zoom compile or adding one more zero to your data. Adding more code to the end wouldn't fix anything because there aren't any known bugs with ending code changing behavior to my knowledge.
[23:23:08] <+Runer112> I believe the documentation has fPart and iPart mixed uo
[23:23:10] <+Runer112> up*
[23:23:20] * Quits: +geekbozu ([email protected]) (Quit: i need sleep it what like sunrise or somthing X.x)
[23:23:24] <+Runer112> it says nib{ is fPart( and it says float{ is iPart(
[23:23:27] <+Runer112> but it's backwards
[23:23:30] <+OmnomIRC> (#)<CoolioJazz> it says they are both iPart(
[23:23:51] <+OmnomIRC> (#)<CoolioJazz> so maybe he fixed one and forgot the other was wrong? :P
[23:24:30] <+OmnomIRC> (#)<CoolioJazz> regardless, nib{ is iPart( and float{ is fPart( then?
Also, I still get random errors that occur some of the time in my programs, including randomly failing to assimilate pictures into programs correctly.Are you importing the pictures as tilemaps by any chance? Because there might still be a problem with that feature 1% of the time. Also, does recompiling fix the issue?
I'm not 100% sure of this one, but I think Axe might use some bcalls that aren't present in older operating systems. In this case, Axe should either avoid those bcalls or check the OS version before running.
:Repeat getKeyʳ=64
:End
Could cause an infinite loop that may be impossible to get out of, if lowercase is enabled.Although the new getKeyʳ is more useful, it can also now be very confusing. For example:Code: [Select]:Repeat getKeyʳ=64Could cause an infinite loop that may be impossible to get out of, if lowercase is enabled.
:End
The reason for this is that if you type a lowercase letter, it is stored at $8446, but if you type any other key, it does not reset the value at $8446. (Edit: This causes all of the other keycodes to change to different values every time a lowercase letter is typed.) On the plus side, its value does seem to always be reset at the beginning of the program.
Some fixes for this are to only read $8446 if a >= $fc, reset $8446 after it is read, or to change checks for any key that is not a lowercase letter to getKeyʳ^256=key code.
Edit: And in the last case, it should probably be documented somewhere, since it is not obvious just from playing around with getKeyʳ.
[]->GDB1
Although this:Data()->GDB1currently can function as a replacement.
| 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. |
| EndIf EXP | In loops, it will exit the loop if the condition is true. But it works just like a regular "End" if the condition is false. | |
| End!If EXP | In loops, it will exit the loop if the condition is false. But it works just like a regular "End" if the condition is true. |
This also means error scrolling can finally be automatic since it won't ever crash. No need to press [prgm] anymore, it will always take you to the error unless you press [clear].Does error scrolling work even if the program being compiled is in archive? Thepenguin added a place for you to chain into zStart for that to happen, and it would certainly be a wonderful addition to Axe.
Some fixes for this are to only read $8446 if a >= $fc, reset $8446 after it is read, or to change checks for any key that is not a lowercase letter to getKeyʳ^256=key code.I haven't been following this discussion, but I think you mean A ≥ $FB (kExtendEcho3), not $FC. kExtendEcho3 was added in OS 1.15, and is used for various new tokens as well as the TI-Keyboard keycodes. Confusingly, $FB was used as a keycode in older OSes (kwnA) but it wasn't a prefix. For compatibility, I'd recommend that you zero keyExtend before calling GetKey:
Edit: And in the last case, it should probably be documented somewhere, since it is not obvious just from playing around with getKeyʳ.
xor a
ld (keyExtend), a
bcall GetKey ; or GetKeyRetOff, whatever
ld hl, (keyExtend-1)
ld l, a
That way, every keycode is unique and consistent across all OSes.
: 0->{T+L4}r->{P+L5}rThe code inside the second !If would be skipped even if it was supposed to be executed on some occasions. This code deals with bombs being detonated in my game, and sometimes the bombs wouldn't be set off, which happened if the second !If was erroneously skipped. By adding more/less code at the beginning of my program I could change where the bomb would fail to be detonated, but I never saw a pattern.
: !If inData(r3*16+r4+1->N,L4)
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End
: 0->{T+L4}r->{P+L5}r
: !If inData(r3*16+r4+1->N,L4)
: 0->{P+L5}r
: !If inData(N,L5)
: N->{P+++L5-1}
: End
: End
Sorry to say it, but it is your code's fault. :P This line is the problem:And now I feel really, really dumb. I should have remembered to check that.
:0→{T+L₄}ʳ→{P+L₅}ʳ
The value left in hl after storing a number to a constant pointer is the original value you stored. But when storing a 2-byte number to a non-constant pointer, the value left in hl is pointer+1.
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..This just happened again in Axe 1.1.1. I can't get wabbitemu to replicate it, but it changed prgmSPRITES to prgmSPRITE► . Evidently it's not just Err:Parenthesis, this time it happened on an Err:missing program.
when using files, the Y# has to be at the beginning of the statement.
opps your right... i use copy.
Copy(Y1+(B*3), L1 , 10) would fail, where
Copy(B*3+Y1, L1 , 10) would work.
| Source | Compiled | |
| If <96-1 .Blah End | ld de,-96 add hl,de sbc hl,hl ld a,h or l jp z,End |
You know how the problem with error scrolling was the longest standing bug in Axe until a few days ago? Well I just discovered a bug that came into existence only 11 days after it and is now contending for the title! The bug involves printing tokens to the graph screen, which has apparently been broken since it was first added. The issue is that the routine feeds B_CALL(_Get_Tok_Strng) the token in hl, although the bcall actually reads the token pointed to by hl.
The 1 or 2 byte token POINTED TO is drawn at the current pen location. Notice how this is different than Disp. See Fix command for drawing details.
The fact that tokens could be inside of the app would need to be dealt with.Umm, isn't ld e,(hl) \ inc hl \ ld d,(hl) executed before the bcall?
:.AXE
:.Initialisation of L1 values (lets try with 20 bytes)
:For(I,0,19)
:I→{L1+I}
:End
:.L2 is empty, we will put received bytes on the 20 first bytes of L2
:Fill(L2,20)
:
:.Lets try if we have 2 calcs
:Output(0,,"Synchronisation ...
:SYN()
:ClrHome
:
:.20 bytes are exchanged
:ECH(19
:.Normally the sum is 190...
:Output(0,,cumSum(L2,20)►Dec
:Pause 4000
:Return
:
:.Synchronisation routine
:Lbl SYN
:Repeat Get(+1
:Send(0,65535)
:ReturnIf getKey(15)
:End
:-1→B
:!If B
:Send(1,65535)
:End
:Return
:
:.Data exchange
:Lbl ECH
:.Check if there is again 2 calcs
:SYN()
:For(I,0,r1)
:!If B
:Send({L1+I},65535)
:GET()→{L2+I}
:Else
:GET()→{L2+I}
:Send({L1+I},65535)
:End
:End
:Return
:
:Lbl GET
:Repeat Get(+1→r2
:ReturnIf getKey(15)
:End
:Returnr2-1Look on wabbitemu all bytes pass easily, but on real calc it doesn't :
p_DrawSteal:
.db 2
pop ix
otherwise drawing sprites to arbitrary buffers doesn't work :/
Just happened again in 1.1.2 x.xAlso, 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..This just happened again in Axe 1.1.1. I can't get wabbitemu to replicate it, but it changed prgmSPRITES to prgmSPRITE► . Evidently it's not just Err:Parenthesis, this time it happened on an Err:missing program.
The program whose name was corrupted was in the archive, btw. I think it was the previous time, too.
Edit: Just noticed this corruption is six letters into the program name as well.
I found an error in the way the token hook is handled. When you copy the text string to ram, I noticed that you don't actually configure the first byte of the string. Since most of the tokens end up being somewhere in the 01xx range, the first byte of the ram string is 1.
But here's the problem. On closer analysis of how this hook works, that first byte actually means something. The format looks like this:
[Key code][length of string][string]
Where key code is the actual key you press to signal the token. As you can see, the key codes you are returning are incorrect and then that leads to all sorts of problems. (01 translates to right, when you use axe tokens in a Recall queue, the calculator hangs because tokens aren't actually being inserted)
So the simple fix is just to put the proper key codes in. The quickest way to get the proper key code is to simply put the token in DE and call _GetKeyPress, that will return the proper key in A.
Edit:
If you are going to call _GetKeyPress from within your hook, make sure you temporarily disable the hook. Otherwise you're going to have fun with recursion.
:Repeat getKey(15)
:!If Get-255
:Disp "ERROR
:End
:EndSo you're probably right, it's due to cable or port of calcs.
Lbl B
->C
Return
[00]->Str1
Str1->Str2
I found an error in the way the token hook is handled. When you copy the text string to ram, I noticed that you don't actually configure the first byte of the string. Since most of the tokens end up being somewhere in the 01xx range, the first byte of the ram string is 1.
But here's the problem. On closer analysis of how this hook works, that first byte actually means something. The format looks like this:
[Key code][length of string][string]
Where key code is the actual key you press to signal the token. As you can see, the key codes you are returning are incorrect and then that leads to all sorts of problems. (01 translates to right, when you use axe tokens in a Recall queue, the calculator hangs because tokens aren't actually being inserted)
So the simple fix is just to put the proper key codes in. The quickest way to get the proper key code is to simply put the token in DE and call _GetKeyPress, that will return the proper key in A.
Edit:
If you are going to call _GetKeyPress from within your hook, make sure you temporarily disable the hook. Otherwise you're going to have fun with recursion.
Can you elaborate on this problem? I haven't noticed any problems with the hook in my testing of it. And I can't seem to cause any problems by recalling strings that contain Axe tokens or by entering Axe tokens into the recall prompt.
I think in the process of fixing replacements in Axioms in 1.1.0, another bug was introduced. Now, if I reference an Axe command or another Axiom command in my Axiom, I get two copies of the referenced command in the compiled code. D:
Is axe 1.1.1 known to be buggy with arbitrary buffers?
Subroutine______Bytes_________________
sub_mul 24
sub_div 26
sub_sdiv 38
Subroutine______Bytes_________________:w00t:
sub_mul 18
sub_div 46
sub_sdiv 35
For(10
End
getKey(41)
(the on key)is broken. It worked fine in previous versions
Is axe 1.1.1 known to be buggy with arbitrary buffers?
If you mean drawing sprites to arbitrary buffers, this should work fine in Axe 1.1.1. There is currently a bug in drawing sprites to arbitrary buffers in Axe 1.1.2, but it shouldn't have existed before this. However, you should be able to get around this bug in Axe 1.1.2 by adding 11 to the buffer argument in sprite drawing commands.
That actually isn't a bug with pt-Get(), that's an issue with the sprite drawing commands:Ok thanks for the tip. It works :)Is axe 1.1.1 known to be buggy with arbitrary buffers?
If you mean drawing sprites to arbitrary buffers, this should work fine in Axe 1.1.1. There is currently a bug in drawing sprites to arbitrary buffers in Axe 1.1.2, but it shouldn't have existed before this. However, you should be able to get around this bug in Axe 1.1.2 by adding 11 to the buffer argument in sprite drawing commands.
If EXP
.I assume an empty For() works
For()
.Code here
End
End
Short explanation:
This isn't the fault of Axe, this is a hardware limitation. To make them simpler/cheaper to manufacture, many keypads/keyboards detect key presses using a grid layout, which can result in phantom key presses if certain keys are pressed together. As an interesting coincidence, this is very much related to my recent How cheap is your keyboard? (http://ourl.ca/16294) topic. :P
Long explanation:Spoiler For Technical explanation:
err....
I have a strange bug in axe 1.1.2
I compiled a programme and <crash> RAM clear :banghead:
I compiled on ion a big programme ( 5752 octets)....
{L1}+1->{L1}1+{L1}->{L1}everything works perfectly (I know it is this line because I didn't change anything else and if I change it back the weird stuff happens again).Strange, I just tried this with Axe 1.1.2, there was no problem.
I have absolutely no idea why this line of code (even if it is in a condition and never ran in execution) mixes up things in the program (like graphics and data storage), but it still runs stable (no errors or crashes occur, it just doesn't do what it should).Code: [Select]{L1}+1->{L1}
if I change it toCode: [Select]1+{L1}->{L1}everything works perfectly (I know it is this line because I didn't change anything else and if I change it back the weird stuff happens again).
As said, the line is in a conditional and it doesn't have to run at all, the stuff happens always from the beginning of the execution, so it has to be axe's fault.
I can't post more because it is part of my contest entry and now I know what to change, so it's not a big deal for me, but it would be interesting to know why this stuff happens.
Strange, I just tried this with Axe 1.1.2, there was no problem.Yeah, latest update, and exact those lines. I rewrote the whole part like 4 times, always the same result.
Are you using 1.1.2 ?
Or are you sure those were the exact lines of code (maybe it was {L1}r instead of {L1}) ?
If I remember correctly Axe does a derp if you add a constant after or something. I could be totally wrong though.Possible. I think I had similar problems before but I didn't care much because they were gone after little changes (which were completely unrelated with the stuff that went wrong though).
Buff(54)→°CA
#Realloc(°CA)
°A-2→°CE
p_TextStrApp:
.db __TextStrAppEnd-$-1
__TextStrAppLoop:
ld a,(hl)
or a
ret z
inc hl
B_CALL(_VPutMap)
jr nc,__TextStrAppLoop
__TextStrAppEnd:
!If GetCalc("L₂",N*9)→L
.Error
End
N→{L-2}ʳ
!If N→{GetCalc("L₂",N*9)→L-2}ʳ+1
.Error
End
Found something in Runer's Axe 1.2.0 : token hook from axioms doesn't work anymore (I was really bored when I realized that FindFirst became 2-SampFZTest :P ).
Axe 1.2.0 breaks horribly Nymless v.93's new Main Menu animations.
You can try it for yourself, but be prepared to pull a battery.
Film at 11.
Also, a clipped line routine would be great for a later version of Axe.Yeah, I agree, because the one I wrote is really unoptimized and I fear I won't be able to optimize it without breaking it :P
Nope, the token hook definitely doesn't work for my AxiomDCS. I downgraded to Axe 1.1.2.
Also, a clipped line routine would be great for a later version of Axe.
Axe lets you include the same program twice.I would think that's a feature, unless it's recursively including the same program.
Why would you ever have any reason to include the same program twice?Axe lets you include the same program twice.I would think that's a feature, unless it's recursively including the same program.
Why would you ever have any reason to include the same program twice?So you'll never include the same program twice, so the fact that Axe lets you include the same program twice is not a problem.
Um, what?Why would you ever have any reason to include the same program twice?So you'll never include the same program twice, so the fact that Axe lets you include the same program twice is not a problem.
So I really don't get where is your problem ???
Hey,
I met a big bug for new 1.2.1 commands
I didn't have enough time to try all combinations, but [W/I/ ][H/V]Line(arg,arg,arg) never worked, and IHLine(X,58000,1500) clears RAM when program stops.
For [W/I/ ][H/V]Line(arg) I had no matter
And ICircle(X,Y,R) bugs : the circle is cut into 4 or 8 pieces of circle when inverted, either on white or black : there are always 4 or 8 pixels missing.
Trying to make a program with a name that contains invalid characters (like lowercase letters) will sometimes flat-out not create a program instead of cutting off the name.
The error message for a too-large app is "ERR:MEMORY". It really should be something more descriptive, like say, "ERR:TOO BIG FOR ONE PAGE" or something.
:.RC2
:"SILLY STRING"→Str1
:length(Str1)→L
:Disp L►Frac
:det(L)→S
:det(L)→C
:0→T
:L-1→M
:For(A,0,M)
:InData({Str1+A},T)→D
:If D≠0
:.This line right here is the problem...
:.It Also happens at the ^r character, which makes no sense to me.
:{C+D}{^r}++→{C+D){^r}
:End
:Else
:{Str1+A}→{S+A}
:0→{C}{^r}
:End
:End
:length(S)→L
:L-1→M
:For(A,0,M)
:Disp {S+A}►Frac
:Disp i,{C+A}{^r}►Dec
:End
It says "invalid token", even though as far as I can tell it should be _completely_ valid in Axe. I've not seen anything saying I can't replace two bytes in ram, as that whole ^r, thing I thought should've fixed it. Anyway below is a screenshot with the data, as I'm way too lazy to make sure I don't accidently type something wrong and it end up being an _entirely_ different thing going on. If you're not able to modify 2 bytes of data at an address in Axe/that shouldn't be allowed to happen anyway in this syntax. I'll go post in the feature request area about it.If you look carefully at that line, you use a right parenthesis instead of a right curly brace, hence your problem. ;)
Interestingly enough, I could figure out this exact problem just from looking at the hex error dump. Boy am I glad I added that.
EDIT: Also, Builderboy is absolutely correct about what he mentioned in the post below. Adding the store there will actually introduce issues because of how the increment operator works.
It's also worthy to note that the ++ operation already stores the incremented value back to where it was read from, so the →{C+D}r part is completely unnecessary (and may not even work 100% of the time, since ++ doesn't always return the incremented value)
It seems that For(12)r doesn't work for me → INVALID TOKEN right on the r.
:.TEST
:2/10->Float{C}
:C*10->C
:Float{C}
:Disp C>Dec1
Done
Actual result.0
DoneYeah, I'm not surprised floating point math isn't working, because Axe doesn't have floating point math. The float{} command is only for converting between OS floats and Axe's standard 16-bit integers.
However, if you want something slightly closer to floating point math than integer math, you can use fixed point math. Standard fixed point numbers in Axe give you a range of about -128 to 128, with a precision of 1/256 (they're essentially signed integers treated as being a fraction over 256). You can find more information about both float{} usage and all the fixed point operators in the Commands.html file included in the Axe download.
:.TEST
:(1/*10)**10->B
:Disp B>Dec
Expected 1, got 0.OK, it _has_ to be a bug then. I'm using Axe 1.2.1 and changing the values to "1.0, and 10.0" makes the number the _same_ 250, which means that, according to you, there's a rounding error(for some reason).
Also the thing that got me into this whole crazy thing in the first place was some "big"(at least I think it is) numbers not working right in Axe.
It was (2/10)*65535. I was expecting a whole number 13,107. But, it never turns into that value... ever. I doubt Axe would be able to do it right now since you're saying it's all 256ths and 65535 256ths wouldn't be the 65535 value(a maximum for the total range in the range encoder I was working), just isn't working at all. I tried the fixed point math, it doesn't work either, nothing seems to work.
The value I get is 65485(which is almost 1.0*65535), and it well should've been 0.2(51/256ths clearly close enough), but somehow that gets converted into nearly 1.0 which makes no sense to me(at the moment) but I imagine it's something with the parser.
Edit: Basically, I wanted to do a simple rouguelike with psuedo-procedural generated content. But I wanted a way to compress the premade "rooms" and other data, in range encoding(seemed like a perfect first program... at least has always worked just fine for all of my other language excursions). Well to be honest, I normally do LZW, as the first one, but axe it looked to be requiring way too much work. But now I don't even know if range encoding will even work, because that's the _only_ spot I have to use non integers, and of course the one spot where I need some sort of non-whole number math, it doesn't work... Basically even if I don't do "real numers" it says it's 0. Even though (2/10)*65535 should be that 13,107. This is _only_ spot I needed non integer math, and of course it's not going to work.
Well... I guess there's two spots, the part where I calculate the share of the range, and then once again when I'm running over the data... but either way I had always used 65535(or some similar "big") number as I don't need super-duper precision. I just needed a way to do fixed point during that part. Then a single operation during the second part too. I was planning on just storing the counts(x bits) one after another and then recalculating the whole range later on. But anyway yeah, 3 decimal points _should_ be way more than enough.(with the whole range I'm using I just need for the values at the end to add up to the whole thing), and then of course make sure that the ranges work right(for the final two byte range value).
009DB900B3AB3FB4
B3ABB3AB55D48AA7
1F00000040018478
8B8068CBI've got 3 issues:
- at some random momments axe will throw up an invalid token error when trying to compile an app from which the source is in archive. I've done some tests, and I think that it keeps throwing that error if you don't change anything, but if you unarchive it, it works perfectly, but even unarchiving and rearchiving sometimes seems to solve the problem.
- for some reason my multiplayer game (with 2 calculators) can't make connections between 2 calculaters. I check whatever the other calculator is waiting, if so, start the game, else, start a loop where you keep checking whatever the other calculator has already started this game. Now, the loops just start at both calculators, which shouldn't appear. I didn't use the port variable, since I don't really understand what it does. I've tried to make connection between a TI84+ silver edition with the latest os (2.55) and a normal ti84+ with the same os, and I use the ports to the right.
- it seems that at the latest os, the input function has a slight difference when in MATHPRINT or in CLASSIC modus: in MATHPRINT, it doesn't clear the screen before execution, while it does in the other modus. this isn't an important issue though.
...and I use the ports to the right.I don't know which port is on which side, but axe can only handle connections trough the I/O port (the round one). If you try to connect them trough the USB port (the rectangular one), axe will act like they aren't connected.
You can't perform writeback to applications. You'll probably need to move whatever that data is to static RAM somewhere to be able to modify it during execution if you're going to proceed with your project as an application.
As for crashing MirageOS, does Axe give you a warning about the program being too large? If so, that's definitely the issue, and you should either convert it to an application or use Fullrene. If not, does the program crash when MirageOS launches it, randomly during execution, or when your program exits? If it's the first one, then that's definitely some weird MirageOS bug that I'm not sure would be avoidable. If it's either of the latter two, it might be due to you using L2, which MirageOS uses. If you do use L2 and it crashes during program execution, try adding LnReg to the initialization code. If you use L2 and it crashes when your program exits, try adding ClrDraw(L2) to the cleanup code.
I think there might be an issue with HLines() drawn off the screen.
I was using 1.2.1a. I took another look, and it was actually my fault. Sorry about that. *embarrassed grin*I think there might be an issue with HLines() drawn off the screen.
What version of the command are you using? Because the 3-argument version is known to be broken in Axe 1.2.1.
DB $7F
RORG PC-1 ; I use mimas
LD HL,CosineTable
; ...
CosineTable:
; ...It returns weird values, but when I build the exact same LUT in my Axe program at saveSScreen and access it with LD HL,saveSScreenIt works perfectly. I think there's a bug with REP_NEXT or something.
Well, I use an application named CalcUtil, and I found two bugs ; one is that, because I'm able to edit archived programs (using CalcUtil), I often compile archived programs, and I (also) get often x.x an ERROR:UNKNOWN, and my calc freezes.
The other bug is that when I get an error, I unarchive the program to find the error (using the [prgm] button), but if I edit the program, the calc freezes and I lose the data... I know this is related to my using of CalcUtil, but if you could fix this, it would be great ;D !
To edit archived programs, I would highly suggest using thepenguin77's zStart (http://ourl.ca/10110/350486) instead of CalcUtil.Ok thanks for the suggestion I'll try when my calc will work :(
Regarding the unknown error, I'm fairly confident I know what causes that and a fix for it is in the pipeline.Ok, then I'll check for updates every day (or more) ;D
To edit archived programs, I would highly suggest using thepenguin77's zStart (http://ourl.ca/10110/350486) instead of CalcUtil.Ok thanks for the suggestion I'll try when my calc will work :(Regarding the unknown error, I'm fairly confident I know what causes that and a fix for it is in the pipeline.Ok, then I'll check for updates every day (or more) ;D
Hi, I'm not sure if this is a bug, but the command ->HEX seems to always point to the string "11" when used with axe fusion. Could you look into it? Thanks.
Activating zStart makes compiling like a russain roulette: you get a freezing unknown error with a 1/2odd.
Lastest version of Axe&zStart on a 2.43 84+
Yeah I noticed that but it's rare enough to make it acceptable, nut still annoying.
There's another issue : when compiling from Axe, the Goto function messes stuff up and leaks all your RAM so you have to RAM clear.
You mean scrolling to errors? Are you using an old version of zStart? I forgot to mention it in the changelog, but Axe 1.2.1+ now checks if zStart exists, and if so, uses its instant goto function for going to errors instead of Axe's. Unfortunately, the API instant goto function was broken in some older versions of zStart, but there's no way for Axe to easily know what version it is so Axe will blindly use the broken API function in older versions of zStart.Yes I mean scrolling to errors. I use the latest versions of both Axe and zStart.
I get it on compiling every program.
Sometimes it happens when I just quitted a Asm program.
But I can't explain more: I just get more often Unknown Error with zStart than normally. You should backup program before compiling.
I think I got a pointer to these unknown errors: I think that's related to RAM allocation for programs. Trying to compile two time a 16kb program made Axe crashed.
Plop,
In Axe 1.2.1a, Exch() seems to use indirection twice. To exchange two bytes situated at for example L1 and L2, I had to do :
:L1->r1
:L2->r2
:Exch(°r1,°r2,2)
Another bug with Axe 1.2.2 : it seems that you forgot to check whether we compile as an app or not before saying "APP TOO BIG". I want to compile a 16464 bytes MirageOS program, but it won't do.
1097E710AFA74E43
A668A668DB990012
0B378B810011FF00
040A406D4AD14976
axiom1:
call sub_axiom2
...
axiom2:
call sub_axiom3 ; several non-consecutive times
...
axiom3:
...With that, Axe compiles fine when it encounters the #Axiom line and even the axiom1( command, but it says "Invalid axiom" when the first pass is fully completed. Besides, when I put axiom3 inside axiom2 as a relative call, everything works fine. De hell ?
Axe does not recognize GDB2, or any variation of GDB1 as a token. Is that a bug report or an understood problem?
When I try compiling that, Axe says 'INVALID TOKEN'
.MAPSRC
If L=1
[222222222222]→GDB1
[200000000002]
[200020000002]
[200000000022]
[200000020002]
[200020000032]
[222222222222]
End
If L=2
[222222222222]→GDB2
[200000000002]
[200000000002]
[200000000002]
[200000000002]
[200000000032]
[222222222222]
End
.TOWERS
DiagnosticOff
ClrDraw
DispGraph
[0000000000000000]→Pic1
[C3A55A3C3C5AA5C3]
.CHARACTER
[FFC3B585A1ADC3FF]
.WALL
[0000001824420000]
.UP
[44AA0022550044AA]
.SPIKES
[FF818999899D81FF]
.PORTAL 1
0→L→N
While L<7
48*L+GDB1→GDB12
ClrDraw
prgmMAPSRC
For(Y,0,7)
For(X,0,11)
nib{Y*6+GDB12*2+X}→Z
Pt-On(X*8,Y*8,Z*8+Pic1
End
End
DispGraph
8→A→B
Pt-On(A,B,Pic1+8
.1 down
.2 LEFT
.3 RIGHT
.4 UP
DispGraph
Repeat N=3
nib{B/8*12+(GDB2)*2+(X/8)}
If getKey(15)
Return
End
If pxl-Test(A-10,B+3
ClrDraw
DispGraph
"The Game"→Str3
For(G,0,65
Text(20,G,Str3
Pause 50
ClrDraw
End
Pause 5000
Return
End
If getKey(1)
Repeat pxl-Test(A,B+8)
Pause 5
Pt-Off(A,B,Pic1
B+1→B
Pt-On(A,B,Pic1+8
DispGraph
End
End
If getKey(2)
Repeat pxl-Test(A-1,B
Pause 5
Pt-Off(A,B,Pic1
A-1→A
Pt-On(A,B,Pic1+8
DispGraph
End
End
If getKey(3)
Repeat pxl-Test(A+8,B
Pause 5
Pt-Off(A,B,Pic1
A+1→A
Pt-On(A,B,Pic1+8
DispGraph
End
End
If getKey(4)
Repeat pxl-Test(A,B-1
Pause 5
Pt-Off(A,B,Pic1
B-1→B
Pt-On(A,B,Pic1+8
DispGraph
End
End
End
L+1→L
For(N,0,96
HLine(96-N
DispGraph
Pause 5
End
End
.MAPSRC
[]→GDB0
.Level 1
[222222222222]
[200000000002]
[200020000002]
[200000000022]
[200000020002]
[200020000032]
[222222222222]
.Level 2
[222222222222]
[200000000002]
[200000000002]
[200000000002]
[200000000002]
[200000000032]
[222222222222]
.et cetera
And I do only have a regular 83+.OK then, forget about what I said, save space in any way you can. For example, I'd advise not to use DoorsCS but MirageOS (and compile as Ion at least so it appears in MirageOS). You could also use zStart but it is a bit annoying on a regular 83+.
The code must be an appvar in ram or archive. However, if you have it as a program in ram, Axe will kindly convert it to an appvar for you.
Another bug ?
I have this in my prog:
[]→°Test .état
This gives an error, and jumps on the first "t" in "état". I guess it's because it didn't get that the "." started a comment but why ?
00B
00000B0034CBB9DB
29DB4AF1800180B3
7004141150800861
CB0866662445C861
The first one is when you try to compile a program which has the same name as the source : you get an error, and pressing the [prgm] key will freeze the calculator during some seconds.
I've also noticed that, when the compiled name takes more than 8 characters, the error "NAME LENGTH" appears in a strange way.
And it would be great if, when compiling to a program instead of an application, the lowercase letters of the program name were converted into uppercase, instead of truncating the name.
Like the "NAME LENGTH" error described earlier, when compiling to a program instead of an application, if the name contains more than 8 characters and uses lowercase, the error "INVALID TOKEN" will appear in a strange way, and pressing the [prgm] key will make the calculator freezing during a few seconds. Here's the hex code corresponding to that error, as it appears on the calculator :Code: [Select]00B
00000B0034CBB9DB
29DB4AF1800180B3
7004141150800861
CB0866662445C861
There are also some problems with the multiline comments... If you end the comment the line after you started it, Axe Parser doesn't detect the comment's end, and make the error "MUST END COMMENT". And if, instead of skipping lines inside a multiline comment, you use colons, you get the same error.
An other little bug for the road : trying to display a string ending with the [sto] arrow generates the "INVALID TOKEN" error.
I'm not sure what you mean by the error appearing in a strange way. It seems fine to me. If you mean none of the progress bar and such have appeared yet, that's because the header of the program is parsed specially and before main parsing begins.Yes, that's what I mean. Before finding these errors, I was not used with error messages without the progress bar and everything.
If the strange appearance is the same as the strange appearance I described before, that's expected. But I think I may have inadvertently reproduced the freeze you're experiencing. If my suspicion is correct, it's due to the fact that changing any Axe settings (anything in the options menu or the target compiled type) results in the Axe settings appvar needing to be modified and saved back to archive, which is done when Axe exits, whether to the homescreen or to an error in the program editor.Ok, so the strange appearance is expected. And the bug is maybe due to the settings ? My settings are the following : "No shell", "Lowcase ON", and "Auto Backup".
I can reproduce this bug. I'll try to fix it, although Axe's comment/newline parsing has always been a bit wonky, so it may not be as easy as it would seem.Yes, but this is not a major bug. I know how complicated it is to interpret a colon, because its behavior may vary : inside a string it's a character, inside a line it can be used between brackets, whereas newlines are always separators of instructions ! So I sympathize :)
Axe has tried to be friendly to BASIC coders used to newlines and store arrows closing/breaking out of any open parentheses, braces, or quotation marks. As a result of this, like in BASIC, you can't include a store arrow in a string, because it immediately ends the string and is parsed as a normal store arrow.Excuse me, I made a mistake, I thought that the store arrow didn't close strings. But, unlike TI-Basic, the store arrow doesn't close the parentheses : "1→Y*2+(Y→Z", "Disp Z>Dec" writes 1.
Ok, so the strange appearance is expected. And the bug is maybe due to the settings ? My settings are the following : "No shell", "Lowcase ON", and "Auto Backup".
Excuse me, I made a mistake, I thought that the store arrow didn't close strings. But, unlike TI-Basic, the store arrow doesn't close the parentheses : "1→Y*2+(Y→Z", "Disp Z>Dec" writes 1.
No no no no no no don't touch parenthesis and brackets O.O you'll kill all of my sources if you do so :w00t:
Yeah, I guess the store arrow doesn't close parentheses in Axe. Come to think of it, it doesn't close curly braces either. I'm not sure how big I'd be on changing this now, though, since it's been this way forever and there haven't been any other problems reported with the way it is. If I did want to change this behavior, I'd probably do it in the theoretical Axe 2.0, since lots of other language grammar changes would be made as well and I'd want to lump them all together.
I assume the bug we're talking about is the slight freeze? Are you sure this happens every time and not only when you've changed a setting in the options menu or the compile target type?
No, seriously, like said Matrefeytontias, don't change this ! It's way better like it is ! Even in an Axe 2.0, even if there are others grammar changes ! When I said "But, unlike TI-Basic, the store arrow doesn't close the parentheses", it was only a remark ! Axe Parser is better than TI-Basic ! How could you write "X*2+(A*3+Y→Z)+GDB0" if the store arrow already closes the parentheses ?
I meant I'd potentially like to change store arrows to not close anything rather than closing everything.If by that you mean store arrows won't close anymore strings and datas, then, fine, it's a good idea ! :thumbsup:
No, that was a TASM issue. Switching to SpASM fixed it.
EDIT : oops just saw the answer in the other thread. Did you try compiling into AXIOM2 with TASM ?
.db $7F ; says next instruction uses an address relative to the start of the axiom
.org $-1 ; since it's only used by Axe at compile time and not included in the final binary, tell the program counter it doesn't exist
Same for $49.
Thanks :) ... it doesn't solve the problem, but I'm now at least sure that the error I encountered are not linked with it.Code: [Select].db $7F ; says next instruction uses an address relative to the start of the axiomSame for $49.
.org $-1 ; since it's only used by Axe at compile time and not included in the final binary, tell the program counter it doesn't exist
.AXE
#Axiom(AXEMENUS)
Menu(
009
E78009E8A3FE69F1
B9F1B000000000B3
700487F0A0000E60
000007BDE
This is usually caused by badly-aligned fields.Yes, it is. This error is caused by a field using one byte instead of two. But Axe Parser should'nt corrupt the source.
You need to add to the size word one for every .org $-1 you wrote in your routine. This is because although PC doesn't take care of the special bytes, they still exist in the axiom (and not in the final Axe program) so they must be taken into account when calculating the routine's size.
It's not Axe that corrupts things. It's the OS. And it's because the token hook definitions are misaligned, so the OS interprets then wrong. It tries to replace non-existing tokens with random strings of random size, so of course it doesn't work.I'm not sure, because the calculator crashes only when I try to open the source after compiling it, whether it be from Axe using the [prgm] key to scroll to errors, or using the OS. Before compiling, even if the Axiom was corrupted, I could edit it without any damage.
I tried a stupid program drawing a HLine between X1 and X2 with the three argument version, it didn't seem to do anything. Adding "L6" at the end solved the problem though, but isn't it meant to work if not specified ?
freq(260,0)
I looked at the source of that command and confirmed that it performs no port modulation if the second argument is less than the first. You might just be picking up on noise. :PDoes not sound like just random noise, unless the OS sends stuff out of the port automatically when you press the keys 2nd - sto (going down) which just happen to be the keys i happen to be using for my calc-a-phon XD
Apparently certain aspects of Axioms have been broken according to this (http://codewalr.us/index.php?topic=199.msg14528#msg14528) post on CW. The same code compiles on an older version of Axe, but not the newer versions, and it's an Axiom thing. I haven't gotten around to testing to see if it is every axiom or Glib itself, but I thought you should know, since the discussion is going on elsewhere.
Copy(,,∗{Y₁})
^
ERROR
PARENTHESIS
Line({*xpos},{*ypos},+5,+5works fine whileLine(xpos,ypos,+5,+5currupts the ram / crashes the calcThere is a major bug related to inline custom named vars:Code: [Select]Line({*xpos},{*ypos},+5,+5works fine whileCode: [Select]Line(xpos,ypos,+5,+5currupts the ram / crashes the calc
(The star is the angle circle thing)
Fix 5
ClrDraw^^R
0->PITCH
10-->XPOS
20->YPOS
REpeat getKey(41)
ClrDraw
If getkey(1)
PITCH<<32?PITCH++
elseif getKey(4)
PITCH>>-32?PITCH--
end
sin(PITCH-32)->S
cos(PITCH-32)->C
Text(0,0,abs(PITCH)>Dec
Line(XPOS,YPOS,C-S//16+XPOS,S+C//16+YPOS
DispGraph
Return
L5->*XPOS+2->*YPOS+2->*PITCH+2->*THROTLEThe bug may as well be somewhere else. Also i am using axe 1.3.0,the download you released on one of the threads ;)
The only thing that I see wrong is a bunch of syntax mistakes, which I guess you didn't directly copy and paste this from some IDE. If you move the last line to the top though, there doesn't seem to be any errors. It works perfectly fine when I tested it on wabbit. Here's a file that should work for what you have.Due to how limited memory is on a calculator, you would usually forgo readability for smaller size code. It's recommended in Axe and Basic to drop the tailing quotes/parenthesis and save space due to them being implicitly added by a newline. When posting the code for others to read it's totally fine to add them in, but when actually storing them on calculator, every extra byte of space is needed.
Also, just some stuff, you should probably close your parenthesis since that doesn't make it faster or smaller, only improve readability, and use DispGraphClrDraw instead of them individually, makes it a lot faster.
One of the games I am creating runs fine with 1.2.2 but on 1.3.0 the the gravity function doesn't work.You're probably going to want to post some example code so that @Runer112 can attempt to recreate the issue and debug it.
I am using pxltest for gravity and there is no complex physics just up or down (no velocity).
I am using the S variable for remaining jump.
If compile any axe program with Axe 1.3, the calculator freeze ???
0 -> Y:For(X,0,2
Y+Pxl-Test(25+Y,25)->Y
EndWhen I closed the parenthesis on the For( loop the statement worked just fine.0 ->Y:For(X,0,2)
Y + Pxl-Test(A+X-1,B+2) -> Y
EndY ends up with a value over 40000!Pxl-Test(A+X-1,B+2)
+Y -> Ygives the right value! (the bug never appears when compiled with 1.2.2)I found a bug!
PRGM:NAME
.CAKE
Disp t sub( >Dec
Disp {GetCalc("prgmTOK")}r >Dec
PRGM:TOK
sub(
The t before sub( is the token character.
The two values are not the same.
The t doesn't get two byte tokens correctly. (I think this is a bug... maybe I'm missing something)
There is still the app too large error with huge data files.
I got one when I tried to include a 18000b file in a program.
Nope I am still using 1.2.2
Is 1.3 stable enough to use now?
(Last time I looked it still had several nasty bugs that made 1.2.2 the only viable option)
Yes! Please!Nope I am still using 1.2.2
Is 1.3 stable enough to use now?
(Last time I looked it still had several nasty bugs that made 1.2.2 the only viable option)
Oh... not really, it still has those particualrly bad bugs... I think? I keep losing track of my progress because I don't revisit it very often, so I never get particulary far. I should really finish it off.
I (think) I found another bug!
I am still using 1.2.2. The command, inData(byte,data,size) won't always work.
inData(byte,data) works fine though.
Here is some code...
GetCalc("prgmNAME",100) sto A
For(X,0,99
X to {X+A}:End
inData(3,A,1000) sto B
Disp B >Dec
Pause 1500
Outputs 891 as the answer.
Changing the 1000 to 100 makes the program work correctly.
It seems that the command won't take a two byte number as an argument.
Ohhhhh! Ok! Could add a way to search backward (such as inData(byte,data)r)?
It seems odd that you can search forward but not back (when you change it).
Will fixing the "bug" break compatibility with programs that use the backwards searching?
If you don't would like to continue Axe Parser, I can do for you :D
You can program ask?!? Can you teach me? I just know the basics.I don't understand this sentence. :(
The Axe application in 1.3.0 version is stable?
It isn't that bad Runner. I compiled my 10000b program and only noticed the byte comparison bug I mentioned earlier.The Axe application in 1.3.0 version is stable?
Definitely not. I "released" it outside of the updates thread because I expected stuff to be broken and wanted to crowdsource the bug finding process. And stuff was definitely broken, including some rather important things like backups and compilation of all but the simplest mathematical expressions.
... And I'm back! With more bugs! As always, I am using 1.2.2a! @Runer112
The first one isn't really a bug but more of an unexpected feature. p2 found this one. Interrupts can occur in the middle of commands like Output(x,y,expr) and if that interrupt changes the location of the cursor, then the Output command will display at the end of where the interrupt left the cursor. I'm not sure if you want to do anything about it or just leave it.
I found the other bug, and it is a bug for sure. Compiling :5 and {Y1}r will compile normally, but on zoom compile it will throw error: undocumented. The five can be replaced with any number and the 'and' can be replaced with any bit-wise command (including the 2 byte plot token ones). The file must have the r after it and be the second argument. In all of the cases normal compile will not error but zoom will.
Ok. I think I have found another. (I'm not sure what's causing it)
I have found that recompiling a certain app causes flash corruption. I'm not 100% sure but it has happened 2 times in a row.
It does use hooks and inline assembly but I have used similar programs without mishap.
Since I need to reset my calc anyway I figured I will try to figure out what is causing it. (I'm sure it is Axe since I haven't been using assembly recently and I have been using the same apps for a year and they never showed any problems)
Oh, and it is 1.2.2a as always.