This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - Runer112
Pages: 1 ... 52 53 [54] 55 56 ... 153
796
« on: May 18, 2012, 01:25:58 am »
Hayleia, I believe the point thepenguin77 is trying to make is that, unless your save file mostly fills a whole 64KB sector, manually rewriting the save file back over it's original location in flash will produce more flash wear and actually be slower in the long run than archiving it normally with the occasional garbage collect.
If the issue is people who have no idea what garbage collecting is, put a note somewhere to tell them to accept the garbage collect if they're prompted. If this is for Pokemon, to save most Pokemon games you have to hit save, and then confirm it. You could display this note during the confirmation display.
797
« on: May 15, 2012, 04:26:09 pm »
They are fine with recursion, it just takes a lot of memory the way Axe does it, since it backs up all 6 variables each time you call the routine
Nope, Axe only backs up the function variables that you would overwrite with the call. So something like sub(LBLr,A) only pushes 2 words onto the stack, the previous value of r1 and the return address (required for any function call). My Fibonacci program just causes a RAM Clear, probably due to a stack overflow. Z80 processors aren't very good with recursion, are they?
That depends how deep you need to recurse. The OS has allocated 400 bytes for the stack, which gives you space for 200 stack entries. You can expect about 20 of these to be in use when your program is run, so you have an allowance of roughly 180 stack entries. That's about 90 recursive calls with one argument, 60 recursive calls with two arguments, etc. So as long as you don't overflow the stack, the z80 is fine at recursion. Overflow the stack, and expect a RAM clear.
798
« on: May 15, 2012, 12:45:58 am »
For some reason, even a simple factorial program did not work correctly for me.
Lbl Fact
If r1 <= 1
1:Return
End
r1*Fact(r1-1):Return
Can somebody post a working sample?
Your routine worked fine for me.  Just note that, for factorials of numbers larger than 8, the calculation will overflow so the result returned will be incorrect. EDIT: In your code, r1 gets overwritten. You need to call FACT as sub(FACTr,r1-1).
Actually this is not the case. Once *Fact( is reached, the first r1 has already been pushed onto the stack.
And because I can't resist optimizing, here is a very optimized recursive factorial function I came up with, weighing in at 17 bytes.  Lbl Fact
!If
Return +1
End
Return *(-1Fact())
799
« on: May 12, 2012, 05:22:19 pm »
Everything in Axe is just raw data. You could draw a list of numbers as a sprite, you could read a string as a list of numbers, you could print sprite data as a string. None of those would have any meaningful output, but I'm just trying to get the idea across that, to Axe, data is just data. One implication of this is that the Buff(#) command, which is probably det(#) in an environment like TokenIDE without the custom Axe tokens, can be used to allocate data for any purpose. For GDB1, it looks like you want it to hold 64 bytes of data. So you would initialize it like this: det(64)→GDB1To initialize a string that holds 16 characters, however, you need to allocate an extra 17th byte. This is because strings need a terminating null character to mark the end of the string. This is why you saw the behavior of printing Str1 resulting in both the 16 numbers and "HELLO!" because Str1 didn't have a terminating null character, so the print method printed the next string in memory as well. Defining a string like "STRING" automatically adds the terminating null character, which is why the printing stops after "HELLO!". Anyways, to initialize a string that holds 16 characters, you would do this: det(17)→Str1Hopefully this will help with the issues you've been experiencing!
800
« on: May 07, 2012, 03:59:16 pm »
I'm guessing you are defining Str0 to be a pointer to a block of data set aside inside of your executable, perhaps like this:
Buff(10)→Str0
This works fine for programs, as they are run from RAM so the 10-byte block of data is contained inside of the program in RAM. But applications are run from ROM, which you probably know stands for read-only memory. And as the name suggests, you cannot* write data to ROM, so attempting to write data back to Str0, which is part of your application in ROM, will fail.
The solution for applications is to use a section of safe RAM or an appvar to hold any data that will be modified.
* Data can be written to ROM, but it's through a complicated method of interfacing with the flash chip that usually involves backing up a whole 64KB of data, erasing the original 64KB of data, and then copying the 64KB back to its original location with the desired changes made.
801
« on: May 06, 2012, 11:51:44 am »
Why not adding in the Commands.html the size of each routine and the size of each routine call ? 
That actually might be a pretty good idea, since people always ask about this information and it's nowhere to be found. Perhaps speed data could be added as well? My only concern is that theses would complicate the otherwise fairly clean and simple command list.
802
« on: May 05, 2012, 12:10:49 am »
Also, it's "Never gonna run around and desert you," not "Never gonna turn around and desert you." 
803
« on: May 04, 2012, 01:00:26 am »
Oops, I wasn't correctly remembering my previous experience with conditional comments. Yes, ...Else works. What had me confused is that I remembered ...ElseIf not working and I must have grouped the two together in my mind.
804
« on: May 03, 2012, 10:34:44 pm »
The equals operator in Axe is a 16-bit comparison. Perhaps A is being set improperly?
805
« on: May 03, 2012, 05:16:48 pm »
when ever i get to the bottom right most square, the screen auto scrolls...  i still cant seem to get around that.
res appAutoScroll,(iy+appFlags) EDIT: And as Xeda112358 mentioned, make sure to reverse the change before you exit with set appAutoScroll,(iy+appFlags). Note: That's res 2,(iy+13) if you're not using ti83plus.inc, although I suggest you do use it.
806
« on: May 03, 2012, 04:49:07 pm »
If °CONST=83, Code1 is compiled, else Code2.
:83->°CONST
:
:...If °CONST=83
:.Code1
:...Else
:.Code2
:...End If you tried to compile that, Axe would throw an error. There is no End to end conditional comments, you just end blocks like you would end any conditional comment: :...If CONSTANT_EXPRESSION
:.Code goes here
:...Else
:.Other code goes here
:...
What's the sense of using comment ifs?
I mean, you could just make it normal, I don't think it compiles different on other calcs....
You are correct that the code doesn't compile differently on different calculator models on its own. But you can make it compile differently by changing the value of a constant, allowing you to quickly and easily change what code is compiled. This is useful for Axe libraries, creating multiple compiled variations of your program, and testing your programs, among other things. For instance, you could put blocks like this in your program: ...If °DEBUG
ClrHome
Disp A►Dec,i,B►Dec,i,C►Dec
getKeyʳ
...
And then simply change the value of the constant °DEBUG before compiling to allow you to turn debugging output on and off. The advantage over a normal If statement is that, if °DEBUG equals 0, the debugging code is not included in the compiled program, which is good if you have 500 bytes of debugging code and you don't want it bloating your official program release.
807
« on: May 01, 2012, 07:37:09 pm »
To quote the official commands list, Commands.html, which you can find in your Axe download: | EXP→Port | | Key: ClrTable | | Sets the link port to a given status with a number 0-3. Must exit program with status 0 if changed! |
If you do not reset the port status with 0→port before returning to the OS, the OS will see that the port is active and will constantly check for link activity that isn't there.
808
« on: April 29, 2012, 12:59:17 pm »
For most of your z80 math routine needs, Z80 Bits is an excellent resource. It has a variety of multiplication, division, square root, and other z80 routines.
809
« on: April 26, 2012, 04:11:20 pm »
getKey(41)
(the on key)is broken. It worked fine in previous versions
getKey(41) appears to work fine for me. Can you show us the section of code in which it is located and not working?
810
« on: April 25, 2012, 08:32:15 pm »
aeTIos:
What is the "and" equivalent of ^2 then ?
and 1 pretty much is the equivalent of ^2; and 2 just doesn't set the high byte to 0, and is thus 2 bytes smaller and 7 cycles faster. Or you could use the full 16-bit bitwise AND, ·1, which results in the exact same compiled code as ^2. There is sub(LBL,arg) and sub(LBLr,arg).
There is LBL(arg). But is LBLr(arg) valid ??
I would imagine that LBL(args)r doesn't exist because parsing that would require look-ahead parsing to detect the r before the arguments are parsed, but LBLr(args) seems like it could be implemented. Not sure why it isn't yet. How much space does calling "stdDev(PTR,N)" take ??
How much space does calling "sub(LBLr,arg)" take ??
Excluding PTR and N of course, the stdDev(PTR,N) call takes 4 bytes, plus 14 bytes for the routine itself. Again excluding the arguments, sub(LBLr,args) takes a pretty substantial 12 bytes per argument, plus 3 bytes for the call. Unless you absolutely must have a recursive function, I suggest avoiding this, as this costs an extra 9 bytes per argument.
Pages: 1 ... 52 53 [54] 55 56 ... 153
|
Show Posts