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 - Quigibo
Pages: 1 ... 51 52 [53] 54 55 ... 135
781
« on: October 05, 2010, 04:40:20 am »
The only problem with that statement is this part:
!If GetCalc(Str1) GetCalc(Str1,16)->Z
End
You should change it to this:
!If GetCalc(Str1)->Z GetCalc(Str1,16)->Z <Code for new appvar> End
Most importantly is the ->Z after the first GetCalc(). Now in the case that the appvar IS found, Z points to it. And of course when it is not found, it is created so Z always points to the data. The other thing to keep in mind is that you might want to have some special code to take care of what happens when the appvar is created for the first time. Usually, this involves filling in some default values to the appvar or maybe prompting the user for some input on how to format it or something.
782
« on: October 04, 2010, 09:17:37 pm »
Actually, the closing parenthesis are interchangeable and behave the exact same way. In fact, they are sometimes implied when you don't see them. For instance "Disp A" is actually parsed as "Disp(A" and thus you can add the unneeded parenthesis "Disp A)" and it will parse fine. Since they are interchangeable, you can even do "Disp A}". It saves code for me not to have to do all these formatting checks.
783
« on: October 04, 2010, 04:55:35 pm »
The syntax is °A not A°, is that the reason?
784
« on: October 04, 2010, 04:46:43 pm »
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
785
« on: October 03, 2010, 10:41:02 pm »
You need a fnOn after any DispGraph command while your custom interrupt is running or else it gets disabled after a while (It's a bug in the z80 hardware).
786
« on: October 03, 2010, 06:32:43 pm »
A while loop is better if you can avoid a comparison operation and use the "0 is false everything else is true" instead:
For(A,0,5) <code> End
0->A While -5 <Code> A+1->A End
The second one is actually smaller and faster than the first one. The only reason I can't make this the default behavior for the for loop is actually because if A happens to be above 5 in this example, it would keep counting up until it passes 65536 and loops back to 5 again. You're basically coding a less optimized for loop here but since you skip the comparison, it actually makes it 1 byte smaller and negligibly faster.
787
« on: October 03, 2010, 05:04:31 pm »
To copy a appvar's picture to the graph buffer, yes you would do:
conj(P,L6,768) To display it, you simply use DispGraph. That's what DispGraph does, it just copies the main buffer to the LCD. No need to bitmap anything.
Alternatively, if you just need to show a picture and don't need to actually copy it to the buffer, you can just do this instead:
P->DispGraph That will copy the 768 bytes in P to the LCD directly and not touch any of the buffers.
788
« on: October 02, 2010, 07:21:04 pm »
The value of the function and the slope have to be equal at 1+ and 1-
3-x = ax2+bx -1 = 2ax + b
Both occur at x=1 so: 2 = a + b -1 = 2a + b
solving: a = -3 b = 5
789
« on: October 02, 2010, 03:48:41 pm »
If you want a really extreme optimization for or-ing the screen, here it is. It will be noticeably faster and smaller:
.# represents the 16-bit or operation L₆→A While -768-L₆ {A}ʳ#{A+L₃-L₆}ʳ→{A}ʳ+1→A End
790
« on: October 02, 2010, 04:54:49 am »
The main optimization I see you should do here is subroutine-ize more of your code. Even simple operations like adding 2 variables together can become subroutines if they're used really often. For instance, I see a lot of reference to K+V in the code. Loading a variable takes 3 bytes and adding is another byte so that's 7 bytes each time you use it. A subroutine however is always 3 bytes. So if you used the expression K+V in your code 50 times (which seems like the case here) you save 4 bytes for each call which saves almost 200 bytes from your program with this simple one:
:Lbl KV :Return K+V
^ By the way, this is valid syntax now to put a return before an expression. It was something I added in 0.4.5 so that you can do it all on one line instead of having the return on the next line.
You can do similar optimizations to other often-used expressions. The cost of using a subroutine is 1 byte for the extra "return" and then a savings of original size minus 3 each subsequent time its used. It turns out that if a routine is more than 7 bytes and used even just twice, you still get a size optimization to subroutine it. 7 breaks even (but of course is more optimized if it were used 3 or more times instead of just twice):
Original: 7 bytes used 2 times = 14 bytes Subed: 3 bytes for each call to subroutine, called 2 times = 6 bytes + subroutine itself (7 bytes) = 13 bytes + return (1 bytes) = 14 bytes
Also, here is a more optimized "Length of Numbers"
:.Length of Numbers :Lbl LN :r1>=10+(r1>=100)+(r1>=1000)+(r1>=10000)→Y :Return
791
« on: October 01, 2010, 04:56:25 am »
There has always been support for inline data with the Asm() command. It literally just inserts the hex code right there. But the other data like strings are still added to the data section at the end of the program, it just doesn't assign a name to the pointer.
792
« on: September 30, 2010, 10:35:41 pm »
The example was already edited in
793
« on: September 30, 2010, 12:33:30 am »
It would be something very similar to this, I haven't tested it yet. Maybe I'll test it and then edit this post with an example that uses this.
:.Initialize Vat pointer (using P as pointer) :Lbl VI :{E9830}r->P :Return : :.Get Next Entry :.Returns 1 if End of Vat or 0 otherwise :Lbl VNX :P-{P-6}-7->P>={E982E}r :Return : :.Get current entry type :Lbl VT :{P} :Return : :.Get Pointer to current entry data :Lbl VD :{P-4}rr :Return : :.Get archive status (0 is RAM, non-zero is archive) :Lbl VA :{P-5} :Return : :.Get Pointer to current name length :Lbl VNL :{P-6} :Return : :.Get Pointer to current entry name (backwards) :Lbl VN :P-7 :Return
EDIT: Okay, fixed it up. Here is an example program using this library that displays a list of all the programs on your calculator. File type '5' is the type for programs by the way.
:sub(VI) : :Lbl L :If sub(VT)=5 : For(A,1,sub(VNL)) : Disp {sub(VN)-A+1}>Char : End : Disp i :End :If sub(VNX) : Goto L :End :Return
794
« on: September 29, 2010, 04:55:10 pm »
I can't seem to find anywhere in that code where it actually loads a picture from RAM. There are 2 places where it creates a new picture though, so maybe that's the error? Remember, one argument means it loads the variable and 2 arguments means it creates a new variable.
795
« on: September 28, 2010, 04:44:40 am »
One example is that you can create multi-byte data abstractions. Lets say you want to define a "vector" which has a 16-bit X component and a 16-bit Y component. Conveniently, you can store these in consecutive addresses. Like A would be the X-part and B would be the Y-part. Now, lets say you want to write a routine that adds 2 vectors and stores the result in a 3rd vector. You can do this with a singe routine by pasing the pointer to the vector instead of the vector values themselves (since you can only pass 16-bit numbers at a time):
:.Add 2 vectors :.Vector 1 pointer in r1 :.Vector 2 pointer in r2 :.Resultant vector pointer in r3 :Lbl ADD :{r1}r+{r2}r->{r3}r :{r1+2}r+{r2+2}r->{r3+2}r :Return
So the first line you're adding the X components and the second line you're adding the Y components. You can use this code for example like this:
:.Initialize vector A with (10,20) :10->A :20->B : :.Initialize vector C with (5,-10) :5->C :-10->D : :.Add the vectors and store the result into vector E :sub(ADD,°A,°C,°E)
So now the E holds 15 and F holds 10 thus the vector E has value (15,10). You can also call the same routine with L1 instead of °E for instance which would save the vector to the locations {L1} through {L1+3} instead of to one of the Axe variables.
The best way to think about the dereferenced variables is like you think about the L1-L6 pointers. Each variable has it's own "free-ram" (exactly 2 bytes of it) so just like you can get a free ram location using L1, you can now get the ram location of any variable. The biggest difference is that when you want to read from a variable, you can just type the letter of the variable so it saves you a lot of typing. If you wanted to get the ram in L1 on the other hand, you would have to do {L1}r. And yes, that means that {°A}r is exactly the same as just typing A.
Pages: 1 ... 51 52 [53] 54 55 ... 135
|