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 - AngelFish
Pages: 1 ... 212 213 [214] 215
3196
« on: September 07, 2010, 12:39:56 am »
It would be nice to be able to initialize a program whether Axe or BASIC without having the compiler put the code for the secondary program into the compiled code. For example, this would allow end users to install only the levels for a game that they have the memory to run. It would also open up the possibility of creating a base program to which one can add modules for different functions.
It's clearly possible in Assembly since BASIC is simply interpreted Assembly, but I don't know if it could be implemented efficiently in Axe.
3197
« on: August 20, 2010, 01:43:28 pm »
Yep, it was recompiled. Looks like I'll have to just hope other calculators can understand if I ever use that in a program.
3198
« on: August 20, 2010, 12:50:04 pm »
You need to do Disp Str1. 
Before that the memory looks like this:
"HELLO",0,0,0,0,0,0,0," WORLD",0
After that, the memory looks like this:
"HELLO WORLD",0," WORLD",0
I suspect something might be wrong with my calculator, then. The code I put in was .AB
"Hello"->Str1
Zeros(6)
" World"->Str2
Copy(str2,length(Str1)+Str1,length(Str2)+1)
Disp Str1
While getkey=/=9
End
What I get back out is a blank line where Str1 should be displayed.
3199
« on: August 20, 2010, 12:03:26 pm »
Here's a way to do what you said, I think. Note that extra data bytes are inserted after Str1 is defined. This is important! Otherwise the new data at Str1 would overflow into other data.
.Data initialization
"HELLO"->Str1
Zeros(6)
" WORLD"->Str2
.Code to append Str2 to Str1
.Copies length(Str2)+1 bytes to include null terminator
Copy(Str2,length(Str1)+Str1,length(Str2)+1) So, that takes Str1 and adds it to Str2? Writing it into my calculator with a Disp Str2 doesn't return "Hello World"
3200
« on: August 18, 2010, 05:59:56 pm »
I'll release it after I get the hex conversion working and I write the user instructions down. I think I might have gotten a bit crazy with the features, though.
EDIT: I didn't see Nemo's commented code. I'm going to look it over, although it seems to leave the String undefined. I see the reference to the location of the pointer, but not the definition of the pointer itself.
Nemo, when I try the code with a sample string, it doesn't work. Disp Str1 gives me back a blank line. RCL Str1 gives me about 16 While tokens.
BTW: The graphics and the commands are entirely finished and debugged.
3201
« on: August 18, 2010, 12:56:18 am »
I don't have room for a full Hex display. The grid is a 73x57 object and reducing it would mean that I'd have to recode all of the sprites or eliminate them. But I could use the real time hex code to draw a stationary sprite to illustrate how the final code will look.
@DJ, I'm writing it in Axe, so porting would essentially just be optimization, which I assure you my code could get.
Also, the Erase all feature is coded and working.
EDIT:
Nemo, I'm not sure I understand the routine you posted. Where does the Hex string store to and how would the user call it? Would it be {I+P} and Rcl {I+P}?
Also, since strings are numbers, could I use a For() loop to store generate the binary strings like
pxl-Test(X, Y)+"Str1"->Str1
3202
« on: August 18, 2010, 12:47:13 am »
The features I currently have written and debugged:
Moving cursor(s)
Plot pixel/invert pixel
Plot all pixels
Invert pixels
Plot all pixels in a row
Plot all pixels in a column
Exit to Hex code
I'll definitely be adding an Erase all pixels feature, an Erase all in Row feature, and an Erase all in Column. I'm going to try to implement "flip grid horizontally," and "Flip grid vertically" as well.
3203
« on: August 18, 2010, 12:28:23 am »
I had no idea you could manipulate strings like that in Axe. Hope you don't mind if I throw that bit into the code, nemo, once I finish up the last few editing features
3204
« on: August 17, 2010, 11:47:11 pm »
I'm currently working on rewriting Quigibo's HEXPIC sprite editor to work in Axe. The whole thing simplifies a lot due to the added graphics features of Axe over TI-BASIC. However, as far as I can tell, Axe has next to no string support. The program should work as follows: - The user first draws a picture on an 8x8 grid using what are essentially magnified pixels.
- After the picture is drawn, the program goes through each of the grid cells and determines whether they are on(1) or off(0).
- This series of binary strings is then converted into a series of hexadecimal numbers, using the first and second four number string of each row. For example, given the first row 0 0 0 1 1 1 1 1, the program should output the hex string 1F
- This list is then stored to the Ans variable for later recall by the user
The problem is that I can't figure out how to store anything to the strings. In BASIC, all you would do is "0"->Str1
For(A,0,7
1->X
Y+offset->Y
For(B,0,7
X+offset->X
If pxl-Test(X,Y:Then
"1"+Str1->Str1
Else
"0"+Str1->Str1
End
End
End
sub(Str1,2,length(Str1->Str1
Then you simply convert Str1 to Hex, which is also easy in BASIC. But would anyone know how you might implement something similar in Axe?
3205
« on: August 17, 2010, 11:15:31 am »
I think I figured out the problem: corrupted RAM.
While testing the Axe version of HEXPIC, I actually cleared the memory. Running HEXPIC again shows it working perfectly on my system without the offset that I had noticed yesterday. It's actually kind of creepy how much the program changed while I slept.
3206
« on: August 17, 2010, 02:47:44 am »
That's next week  Actually, I have the rest of the night, with nothing to do except a lot of paperwork for college tomorrow. Ah, the wonders of insomnia... BTW: My calculator normally isn't in Mathprint mode, as I can't stand it, but with the RAM clears from learning Axe, it's been reset to that. So Mathprint may very well be the problem.
3207
« on: August 17, 2010, 12:55:13 am »
I really am new to this language. I've tried to rewrite the program like that at least a half dozen times without success. It kept producing weird results, until the last time.
3208
« on: August 16, 2010, 09:44:03 pm »
What you can do is "inflate" the value to get more accuracy. 256 is a great number since it's very optimized in both division and multiplication. Since Axe variables hold 16-bit numbers, you can use the lower byte as the decimal and the higher byte as the number. 9.8 can be represented by 9 + 205/256. You get your inflated number by multiplying by 256 so that's 9*256 + 205 = 2509 == 9.8 as an inflated decimal. You can treat this number like any other number. If you add 1 to it, you're really adding 1/256th and adding 256 is like adding 1, etc. When it comes time to display the point, just divide by 256 so that you recover the integer part for the pixel. So you're doing math with the precision of 1/256th and then just drawing it to the nearest pixel.
Let's say that 47->X and 32->Y, with velocities U and V respectively. So, it would be something like While 1
256*X+U->X
256*Y+V->Y
Pt-On(X/256, Y/256, Pic1)
End
or am I not understanding this? I think I'm okay with the N mod 256 part, but I'm not sure if this is precisely that.
3209
« on: August 16, 2010, 07:47:54 pm »
It could just be my calculator then. That would make sense, as my computer and calculator are bitter rivals. I've only managed to get them to play nicely together without losing an OS very recently.
3210
« on: August 16, 2010, 07:38:55 pm »
I know. I only put it here because it's included in the Axe package. Well, that and I don't like making more threads than are necessary. It helps keep forums in some sort of order.
Pages: 1 ... 212 213 [214] 215
|
Show Posts