I had the following code:
[spoiler].TRY03AXE
1->X
1->Y
fnInt(I,0)
Repeat getKey(15)
X+1->X
Output(1,1,X>Dec
Output(1,2,Y>Dec
End
Goto E
Lbl I
Y+1->Y
ReturnY
Lbl E
LnReg^r
[/spoiler]
It ended with B being set to 3 but X still counting... (Interrupt stopped working)
Then I modified it like this:
[spoiler].TRY03AXE
1->X
1->Y
Repeat getKey(15)
X+1->X
Output(1,1,X>Dec
Output(1,2,Y>Dec
fnInt(I,0)
End
Goto E
Lbl I
Y+1->Y
ReturnY
Lbl E
LnReg^r
I Put the call for teh Interrupt inside the main loop[/spoiler]
Like this it was working (both counting up)..
Then thanks to c4ooo I found another way it was working:
[spoiler].TRY03AXE
1->X
1->Y
fnInt(I,0)
Repeat getKey(15)
X+1->X
Output(1,1,X>Dec
Output(1,2,Y>Dec
fnOn
End
Goto E
Lbl I
Y+1->Y
ReturnY
Lbl E
LnReg^r
Now setting interrupts ACTIVATED every single time in the loop[/spoiler]
But why did the interrupt stop working in the first place? BEcause of the "Output" command or something?
Edit: Fixed massive use of wrong var names sorry >.<
Here's some working [and optimized] code:
.TRY03AXE
1->X->Y
Fix 5
fnInt(INTERRUPT,0)
Repeat getKey(15)
X++
ClrDraw
Text(0,,X>Dec) .double comma is *Not* a typo
Text(0,9,Y>Dec)
DispGraph
End
LnReg^r
Return
Lbl INTERRUPT
Y+1->Y
Return
It should work. Anyways, what are you trying to accomplish here, if i may ask? :)
Just comparing the speed of the main loop to the interrupt (to see how fast the speed settings 0, 2, 4, 6 are ^^)
Edit:
Just tried jour code.
It works but the interrupt counter is like 10 times faster now O.o
Then the interrupt counter (Y) reaches 1000, the counter in the main loop (X) is only at 85... O.o
And was it the Output( causing the problem?
*Edit of Edit: Actually the interrupt counter is like 2-3x faster while the main loop is muuuuch slower >.<
For me, at speed "0", when the interrupt counter reaches 1000, the loop counter is at around 150. Well using graph screen is slower then home screen i guess; also my interrupt code is about a dozen T-states faster then yours.
When adding "Full" at the top of the code, I get 150 for X, too (with Y>999). But only the main loop speeds up, the interrupt remains the same speed it seems ^^
what calc are you using? :)
TI-84 plus. Also i dont use Full.
Is there any function to give you the exact time an interrupt at current speed would be triggered per second...? would be interesting >.>
Edit: quote from omnimaga:
Quote from: Hayleia on October 03, 2012, 03:16:42 PM
The speeds for the interrupts are as follow (according to Hot Dog):
Speed // 83+ // 84+
0 // 560 Hz // 512 Hz
2 // 248 Hz // 228 Hz
4 // 170 Hz // 146 Hz
6 // 118 Hz // 108 Hz
And shouldn't there be a warning like "Dont use Output( command it will break your interrupts" or something...?
(As far as I understand it that has been the problem?)
Quote from: p2 on August 17, 2016, 10:00:02 AM
Is there any function to give you the exact time an interrupt at current speed would be triggered per second...? would be interesting >.>
Edit: quote from omnimaga:
Quote from: Hayleia on October 03, 2012, 03:16:42 PM
The speeds for the interrupts are as follow (according to Hot Dog):
Speed // 83+ // 84+
0 // 560 Hz // 512 Hz
2 // 248 Hz // 228 Hz
4 // 170 Hz // 146 Hz
6 // 118 Hz // 108 Hz
And shouldn't there be a warning like "Dont use Output( command it will break your interrupts" or something...?
(As far as I understand it that has been the problem?)
I see what you mean.
The command output sets the position of the cursor, but then is interrupted by the interrupt which moves the cursor.
When it returns back to the first output it continues where the cursor is and displays the text.
Output(x,y,exp)
is the same as :Output(x,y):Disp exp
so if I just wanted to display something like a counter (always overwrite the last text at the same position) it'd be faster to once to Output(x,y) and then use nothing but a DISP inside a loop? :)
Quote from: p2 on September 27, 2016, 09:11:00 AM
so if I just wanted to display something like a counter (always overwrite the last text at the same position) it'd be faster to once to Output(x,y) and then use nothing but a DISP inside a loop? :)
No you can't. Disp updates the cursor position. There is a way you can do it but you won't like it as much.
You can simply disable interrupts before the output and enable them after. Thankfully the disable and enable commands take only one byte each.
(what kind of project are you using interrupts on the home screen anyway? I have never heard of interrupts being used for anything other than greyscale)
I'm not using it for any seroius project, just curious to learn some more about axe xD
aaaand used interrupt to display a counter since I'm stupid and I just wanted to see how fast these interrupts really are :3
Quote from: p2 on September 27, 2016, 03:28:17 PM
I'm not using it for any seroius project, just curious to learn some more about axe xD
aaaand used interrupt to display a counter since I'm stupid and I just wanted to see how fast these interrupts really are :3
That's the best way to learn!
I hardly ever use interrupts. Unless you are doing a serious graphics projects, or need the most beautiful greyscale, it is best to leave interrupts alone.
More often than not, interrupts are not needed, simply displaying at the end of a loop is sufficient to create acceptable greyscale.
(plus it destroys L2 which is the biggest of all the free ram areas)
Quote from: E37 on September 27, 2016, 03:33:43 PM
(plus it destroys L2 which is the biggest of all the free ram areas)
L1 is the biggest area :P And it only destroy about 256 bytes of L2 (if I remember well) , so you can still use it.
Quote from: TheMachine02 on September 27, 2016, 03:36:56 PM
Quote from: E37 on September 27, 2016, 03:33:43 PM
(plus it destroys L2 which is the biggest of all the free ram areas)
L1 is the biggest area :P And it only destroy about 256 bytes of L2 (if I remember well) , so you can still use it.
No, that's untrue. L1 is the same size as L3 and L6.
L2 is the biggest at 800+ bytes.
Axe only lists L2 at 512 bytes, but the actual usable memory extends to beyond 800 (I don't remember the exact number)
Quote from: E37 on September 27, 2016, 03:38:51 PM
L2 is the biggest at 800+ bytes.
Axe only lists L2 at 512 bytes, but the actual usable memory extends to beyond 800 (I don't remember the exact number)
https://www.omnimaga.org/asm-language/8384-free-ram-areas/
well, I guess it could work then. But yeah, who want more than 768 bytes anyway :P
Quote from: TheMachine02 on September 27, 2016, 03:43:18 PM
Quote from: E37 on September 27, 2016, 03:38:51 PM
L2 is the biggest at 800+ bytes.
Axe only lists L2 at 512 bytes, but the actual usable memory extends to beyond 800 (I don't remember the exact number)
https://www.omnimaga.org/asm-language/8384-free-ram-areas/
well, I guess it could work then. But yeah, who want more than 768 bytes anyway :P
I use it as another buffer and the space after that to store custom variables. (I don't usually have more than 16 named vars)
@E37 @TheMachine02 From the official axe docs: :)
L1-768 (nothing)
L2-531 (interrupts)
L3-768 (back screen buffer)
L4-256 (currupted by archiving/unarching)
L5-128 (text buffer (homescreen))
L6-768 (screen buffer)
However!!! You can actually have FIVE 768 byte buffers! (Greylib used this and so do I in my game lazer II)
L6, L3, L1, L2+103, L4-512
All the above can be used as 768 byte buffers, and still have interrupts running, as well as be able to display to home screen. (However you can't have interrupts and display to the homescreen at the same time >_> ) Be aware that it can cause some weirdness though, but nothing that can't be handled by some code :)
Didn't L2 have compatibility issues with MirageOS and other programs, though? Can this be solved via some code too?
IDK Greylib does this and doesn't seem to have issues :)
Ah ok. It's possible that has been fixed since I last coded seriously in Axe in 2010. I remember the doc warned about that
Quote from: DJ Omnimaga on October 06, 2016, 08:11:30 PM
Didn't L2 have compatibility issues with MirageOS and other programs, though? Can this be solved via some code too?
Yes. L2 is 800+ bytes. Interrupts take up some amount of the beginning of it. I don't know how much. (I've heard somewhere between 100 to 256 bytes) I never use interrupts so I don't know. :P
Anything after that space is free to use.
It is 256 bytes, due to how interrupts works on the 84+, or 100 bytes (in hex)
That's weird then cause I (and greylib) use L2+103, not L2+256 >_>
Quote from: TheMachine02 on October 08, 2016, 02:51:03 PM
It is 256 bytes, due to how interrupts works on the 84+, or 100 bytes (in hex)
what do you mean by "in hex"...?
@c4ooo: MAybe that's where your +103 is coming from. +102 in case someone accidentally assigned a 2-byte var to +100 plus another byte just to be sure ;)
Quote from: p2 on October 10, 2016, 11:59:25 AM
Quote from: TheMachine02 on October 08, 2016, 02:51:03 PM
It is 256 bytes, due to how interrupts works on the 84+, or 100 bytes (in hex)
what do you mean by "in hex"...?
256 in hexadecimal is 0x100
oooh yess... <_< /me hides in a deep deep hole
Then it shouldnt have anything to do with it since it's an adress not a byte count ^^
So after looking through axe code source of fnint() and LnReg, it seems it doesn't touch L2 at all finally, the cake is a lie :P
It install interrup table at $9200, ISR at $9300 and use some restoring code placed at $8624 (if I get code right though). So L2+103 is maybe a warp for being able to execute with MirageOS instead :P
EDIT : it was changed in 1.2.1 :
QuoteMoved custom interrupt data out of L2 (statVars) so it can be used with a custom interrupt enabled.
Lol nice find :D