Posts that would fit in here are coming up all over. You finally can complain to Quigibo about bugs in an organized thread. Yay!
I'll go first:
Why does the ON= valid keypress not work in my program?
If I put
Code: getKey->K
ReturnIf K=41
it won't register the key.
And does the Axe documentation claim that the getKey operation can catch the ON key? It's non-trivial to catch ON in z80 ASM, so I could easily believe that it's not meant to catch it.
Here's my request: move the internal variables to the end of the safeRAM area so that Axe will play nice with CALCnet.
Agreed. Playing a real-time game like F.I. over three or more calcs would be awesome!
Also, on the Axe 0.4.6 documentation, it does claim to catch ON.
This is what the changelog says for 0.4.6:
Quote:
0.4.6 ***(November 28, 2010)***
* Direct key support for the [On] key using getKey(41)
* Added new Axiom Tokens (but they aren't usable yet)
* Static data can be stored to variable pointer
* Pressing alpha-character jumps to program in compile menu
* Selector wraps around in the compile menu
* Fixed bug that made some invalid syntax become comments
* Fixed Elseif bug
* Added new auto-optimizations
* Automatic backups only after finishing compile with no errors
* Compiling to apps always attempts a defragmentation
* App signature improved and resignable on-calc with external program
* Fixed program menu bug after manual backups
* Manual backup key is now "Alpha"
* Fixed sector boundary reading bug when reading large source from archive.
So obviously it's either Axe or. . .
2.53MP!!!!!
Don't you need to be using getKey(41) instead of this?
Code: :getKey->K
:If K=41
://code
:End
getKey(41) returns 1 if [ON] is pressed.
Yes, but I have other keypresses I need to detect. I'll try though. Thanks.
Yeah, Axe only detects ON with getKey(41), not with getKey(0) or getKey, and even then getKey(41) is done totally differently from any of the other getKey(#)s, because ON works differently.
OK. That clears ONE problem up.
KermMartian wrote:
It's non-trivial to catch ON in z80 ASM, so I could easily believe that it's not meant to catch it.
On the contrary, the On key is the easiest on the entire calculator to detect - just check bit 3 of port 4!
benryves wrote:
KermMartian wrote:
It's non-trivial to catch ON in z80 ASM, so I could easily believe that it's not meant to catch it.
On the contrary, the On key is the easiest on the entire calculator to detect - just check bit 3 of port 4!
From a hardware perspective you can check the state of the On key by looking at the 3rd bit of port 4. If it's 1 the On key is released, if it's 0 it's pressed. In BBC BASIC this would be expressed as (GET(4) AND 8)=0 (2³ is 8). I'm not familiar enough with Axe to suggest a replacement (it doesn't seem to support direct port I/O), though if using key 41 (as per the documentation) doesn't work I'd suggest filing a bug report.
KermMartian wrote:
benryves wrote:
KermMartian wrote:
It's non-trivial to catch ON in z80 ASM, so I could easily believe that it's not meant to catch it.
On the contrary, the On key is the easiest on the entire calculator to detect - just check bit 3 of port 4! :)
In which case I agree. :-)
Yeah, getKey(41) does work, just not getKey or getKey(0) to check for ON, since they wouldn't register with plain key input anyway.
Deep Thought wrote:
Yeah, getKey(41) does work, just not getKey or getKey(0) to check for ON, since they wouldn't register with plain key input anyway.
That seems a bit counter-intuitive to me, as confirmed by c.sprinkle's confusion. Why not let getKey catch [ON] all the time? Does Axe let you ON-break programs?
KermMartian wrote:
Deep Thought wrote:
Yeah, getKey(41) does work, just not getKey or getKey(0) to check for ON, since they wouldn't register with plain key input anyway.
That seems a bit counter-intuitive to me, as confirmed by c.sprinkle's confusion. Why not let getKey catch [ON] all the time? Does Axe let you ON-break programs?
Because the getKey in Axe is GetCSC, and iirc GetCSC doesn't catch the [ON] key. It does not let you ON-break programs because Axe compiles Axe basic into an ASM program or Flash App (unless you set up an interrupt to catch th ON key and quit).
souvik1997 wrote:
KermMartian wrote:
Deep Thought wrote:
Yeah, getKey(41) does work, just not getKey or getKey(0) to check for ON, since they wouldn't register with plain key input anyway.
That seems a bit counter-intuitive to me, as confirmed by c.sprinkle's confusion. Why not let getKey catch [ON] all the time? Does Axe let you ON-break programs?
Because the getKey in Axe is GetCSC, and iirc GetCSC doesn't catch the [ON] key. It does not let you ON-break programs because Axe compiles Axe basic into an ASM program or Flash App (unless you set up an interrupt to catch th ON key and quit).
Edit: I know it compiles to ASM, but if Quigibo had written it to have a custom interrupt, Axe programs (or any programs with such an interrupt) could be ON-broken. In fact, one the of the MOS interrupt modes emulated by Doors CS lets ASM programs have such a feature.
Yes, but whenever Axe finds a getKey in the source it will have to add that code for every getKey, which could increase the size of a program very quickly.
souvik1997 wrote:
Yes, but whenever Axe finds a getKey in the source it will have to add that code for every getKey, which could increase the size of a program very quickly.
I was under the impression that Axe replaced tokens with routines at the end that it calls from each place that that token appears. For example, with zero getKeys, that no getKey code would be included. For ten getKeys, the getKey code would appear once at the end, and be called from ten places.
I don't know exactly how Axe works, but in disassembled code I have found that compiling this Axe program:
Code:
getKey
getKey
getKey
getKey
Return
becomes this:
Code:
bcall GetCSC
ld h,00
ld l,a
bcall GetCSC
ld h,00
ld l,a
bcall GetCSC
ld h,00
ld l,a
bcall GetCSC
ld h,00
ld l,a
ret
Yeah, it would only make sense to have a three-byte call to a seven-byte subroutine instead of that six-byte code when you have at least three such calls, so I can only assume that Quigibo took the easy way out, decided you won't have a huge number of getKey calls, and didn't provide for the three-byte call to a seven-byte subroutine, in which case my idea is extremely hard to implement.
Btw, should this go in the Axe Parser subforum here on Cemetech?
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.
»
Go to Registration page
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
