Omnimaga
Calculator Community => TI Calculators => Axe => Topic started by: Ikkerens on October 04, 2010, 11:45:10 am
-
So... I was working on porting necro's gfx to axe parser format (for my zelda-like game), and I stumbled upon 2 questions.
1. Can axe read from programs stored in the archive? (Then I mean, my program, since my gfx are in a program in the archive)
2. I have this program data file (created the same way as an appvar), but its source is open (I can read it using TIOS's edit), how can I lock this?
3. Can I "break" loops? For example, I have a for loop that goes from 1 to 10, but as soon as it discovers that number 6 is empty, that it will skip the 7-10 as well?
-
I don't know about questions 1 and 2, but I think that to break out of loops you could just set A to a number higher then 10.
So...
For(A,0,10)
Misc. Code
If A=6 or other conditions
11->A
End
End
-
Hmm... strange I didn't think of that myself.
Thanks though.
-
1. Can axe read from programs stored in the archive? (Then I mean, my program, since my gfx are in a program in the archive)
2. I have this program data file (created the same way as an appvar), but its source is open (I can read it using TIOS's edit), how can I lock this?
3. Can I "break" loops? For example, I have a for loop that goes from 1 to 10, but as soon as it discovers that number 6 is empty, that it will skip the 7-10 as well?
1) If you mean can Axe compile from Archive, then yes. To read data from Archive within a program is possible, I think, but the routines aren't the same as reading from RAM.
2) If you don't want to user to see the source, then I simply wouldn't include the source with the program.
3) You could also use a Goto to skip somewhere in the program. But the 11-->A thing is more memory efficient.
-
No, I mean. I am Copy('ing my pics to a prgm created by Getcalc(
But that file is also editable trough the TIOS basic editor.
Even though the contents make no sense at all
How can I "lock" this program?
-
Oh... I've been wondering how to do that for a little while now. I think if you put an invalid character into the file name, TI-OS shouldn't be able to open it. But my guess is as good as yours.
-
So... I was working on porting necro's gfx to axe parser format (for my zelda-like game), and I stumbled upon 2 questions.
1. Can axe read from programs stored in the archive? (Then I mean, my program, since my gfx are in a program in the archive)
2. I have this program data file (created the same way as an appvar), but its source is open (I can read it using TIOS's edit), how can I lock this?
3. Can I "break" loops? For example, I have a for loop that goes from 1 to 10, but as soon as it discovers that number 6 is empty, that it will skip the 7-10 as well?
1. Yes, Axe is able to read data from archive. Reading tilemap data and sprite data from the archive is how my Zelda demo worked :P (It seems that everybody wants to make a Zelda or Zelda-like clone lol)
2. You can change the protection status of programs with the flash application Calcsys (http://www.ticalc.org/archives/files/fileinfo/97/9781.html) by finding the program in the VAT and typing "P" to change its protection status.
3. As others have said, to break from a loop, just set the loop variable to an exit condition.
-
Could you give an example on how to read from the archive?
-
I suggest looking at page 15 of the Documentation.pdf file. Reading from archive is explained well there, and it has an example too.
-
So... I was working on porting necro's gfx to axe parser format (for my zelda-like game), and I stumbled upon 2 questions.
1. Can axe read from programs stored in the archive? (Then I mean, my program, since my gfx are in a program in the archive)
2. I have this program data file (created the same way as an appvar), but its source is open (I can read it using TIOS's edit), how can I lock this?
3. Can I "break" loops? For example, I have a for loop that goes from 1 to 10, but as soon as it discovers that number 6 is empty, that it will skip the 7-10 as well?
1. Yes, Axe is able to read data from archive. Reading tilemap data and sprite data from the archive is how my Zelda demo worked :P (It seems that everybody wants to make a Zelda or Zelda-like clone lol)
/me hopes it is still alive D:
Also I think Ikkerens has been working on one for a while too, as he had it in his sig for months. However he went inactive for a while then worked on the contest entry. Also, if you think many people wants to make a Zelda clone, then you haven't seen with Pokémon. Had jsj795 and Iambian started their respective Pokémon clone attempts and had Shmibs continued his xLIB one, I would have started a project sub-forum just for Pokémon clones and it would still get more activity than United-TI forums as a whole :P
-
I suggest looking at page 15 of the Documentation.pdf file. Reading from archive is explained well there, and it has an example too.
Ok, now I feel stupid, can't believe I didn't spot that before.
-
I think it was added in the last few versions, because it wasn't there before. I tend to not check the doc much because it used to be rarely updated at all. In fact, it was updated so rarely that sometimes the version number stated in it was a few versions behind.
-
well, I thought it was just only the version number in the Commandlist that was not updated. But I've just only token a look at the Documentation one or two times, but it clarified a lot :D
IMO it is nice but not usual in pre-releases of programs to update the doc every new release (I even forget creating a Documentation al all (A))
-
Just to let everyone know, the only commands currently able to read from files in archive are {} and Copy(), but I am hoping to extend this to int{}, float{}, and nib{} in the future. Also, a goto is more efficient to exit a loop than to set a variable to a number above the maximum because it will save time in the code and its 3 bytes less.
EDIT: In the future, I will add that the documentation was updated in the update descriptions :)
-
I assume nib{} will be useful for example to read half-byte tilemap data directly?
-
Also, a goto is more efficient to exit a loop than to set a variable to a number above the maximum because it will save time in the code and its 3 bytes less.
How is it more efficient? I though jp commands (assuming that's what goto uses) took quite awhile to jump.
-
We have to remember that ASM Gotos are not like TI-BASIC Gotos, though. In TI-BASIC, they are inneficient in most cases (and even cause leaks), but it doesn't mean it will be the same in Axe/ASM.
-
ASM is a totally different animal from BASIC. But the ASM jump commands I'm familiar with, JL and JP both take fairly long times to jump as far as I'm aware. I'm not sure if Axe uses those commands for GOTO though.
-
Ah, I didn't know that. Maybe it is not as slow as you think? Sadly I am not experienced with z80 so I wouldn't be able to confirm. You could always run some Axe tests, though, to see.
-
ASM is a totally different animal from BASIC. But the ASM jump commands I'm familiar with, JL and JP both take fairly long times to jump as far as I'm aware. I'm not sure if Axe uses those commands for GOTO though.
JR and JP take 12 clock cycles at most. That's 2 microseconds (2*10-6 seconds) at 6MHz, so I would hardly call that a "fairly long time." :P
-
Only 12 clock cycles? Ignore everything I said before then. I obviously need to look at that part in ASM in 28 days again.
EDIT: For the names as well :P
-
Only 12 clock cycles? Ignore everything I said before then. I obviously need to look at that part in ASM in 28 days again.
EDIT: For the names as well :P
You might have been thinking of ASM's implementation of the BASIC Goto statement. In pure ASM, all Z80 instructions should take about sixteen cycles or less.
-
Only 12 clock cycles? Ignore everything I said before then. I obviously need to look at that part in ASM in 28 days again.
EDIT: For the names as well :P
You might have been thinking of ASM's implementation of the BASIC Goto statement. In pure ASM, all Z80 instructions should take about sixteen cycles or less.
*23 cycles or less. :)
-
I think the BASIC goto can take over 9000 cycles in some cases (like when the lbl is at the very bottom of a 18 KB program)
-
*23 cycles or less. :)
Instructions like CPDR can be a bit misleading though ;)
-
WHat makes them misleading? Can they take random amounts of clock cycles?
-
Well what they do is a little complicated, but basically they keep repeating themselves over and over again until a certain condition is met, so they take different amount of clock cycles depending on the situation. But * technically* its not 1 instruction, but its a whole bunch of instructions being done over and over so thats where it can get misleading :)
-
Ah right, makes sense :)
-
To be technical, they're called "block instructions," and are LDIR, LDDR, CPIR, CPDR, INIR, INDR, OTIR, OTDR, and maybe some other ones I don't remember.
The number of times they execute is based on the contents of BC (a 16-bit register), though some (notably CPIR and CPDR) are also affected by the contents of RAM (they essentially work as one-byte finds.)
[/rant]
;D
-
What does that extra R stand for, anyway?
-
It's the last two letters you should be interested in. :)
"IR" stands for "Increment Repeat" and "DR" stands for "Decrement Repeat."
-
Yeah, I knew what I and D stood for (they're in LDI and LDD, anyway). I just couldn't figure out that last R, for some reason :D
-
How the repeat works is rather interesting, actually.
For example, LDIR acts almost exactly like LDI, in fact, this code acts almost exactly the same (except for speed :P)
Effectively the pc does not change unless bc is zero; the instruction is executed over and over.
ldir_loop:
ldi
jp pe,ldir_loop