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 ... 5 6 [7] 8 9 ... 153
91
« on: December 01, 2015, 10:13:27 pm »
Sorry to interrupt with a different question, but when I display a token, it displays the basic token.
Like instead of displaying #Axiom( is displays AsmComp(.
Is there an easy way to display Axe tokens instead (probably by intercepting whatever Axe sends to the basic editor)?
Also, is there a way to call the OS's catalog? (I don't want to make my own.)
For the record, I haven't answered either of these questions because they're beyond both my knowledge and the capabilities of native Axe. You might have better luck asking these questions framed as assembly questions in the appropriate place. The ASM board isn't particulatly active, though, so you may want to try Cemetech's equivalent (or both). Regarding your first question, I believe the main issue is that the token hook isn't normally invoked when displaying tokens in a running assembly program. I don't know how to solve this, but if you do eventually solve it, be aware that Axe's token hook will only replace tokens if cxCurApp is $83 (and, with Axe 1.3.0, if the token hook is enabled in the options menu).
92
« on: November 29, 2015, 10:35:29 pm »
There is a major bug related to inline custom named vars:
Line({*xpos},{*ypos},+5,+5works fine while
Line(xpos,ypos,+5,+5currupts the ram / crashes the calc
(The star is the angle circle thing)
I can't seem to reproduce this in my small test program. Would you be able to provide the source and/or compiled programs that are causing this?
93
« on: November 28, 2015, 01:00:49 pm »
It is possible to have the source of Axe 1.2.2 because I don't find on this topic.
The source for all of the built-in subroutines is available in each Axe.zip download at Developers\Commands.inc, but the source for the application itself is not available, as it is a closed-source project. Sorry for this triple post but I download the Axe 1.3.0 and it bugs 
So, I search an other version on the Google and I find this version.
Yes, I feared that Axe 1.3.0 would have some bugs, which is why I only released it unofficially as a test release. That link should be Axe 1.3.0 with a few bugfixes applied. If you use that and still encounter bugs, you should report them in the bug reports thread. If you do so, please mention the version of Axe you're using.
94
« on: November 28, 2015, 12:51:31 pm »
How can i convert, in axe, a wavelength (Freq() uses wavelengths, right?  ) into a string like "C4" or "C4♭" and back?
There's nothing particularly special about doing this in Axe compared to any other language. I'd imagine the part that might be a bit tricky is knowing what WAVE arguments to Freq(WAVE,TIME) correspond to what notes. If a calculator is running at normal speed (~6MHz), then this should be roughly 64000/ x, where x is the desired frequency in Hz. You'd probably want to calculate these values for an octave or every note ahead of time and store them in a table. As for converting to/from strings, that's certainly no different than how it would be done in any other language. If you call C0 the lowest note, then a note's index in a full note table is contributed to by octave*12, C=0, D=2, E=4, F=5, G=7, A=9, B=11, sharp=1, and flat=-1. If you're only storing one octave of data, then omit the octave*12 part and just multiply or divide the WAVE value for a note by 2 for every octave offset.
95
« on: November 27, 2015, 12:30:29 pm »
If you're doing a lot of math, BASIC actually is a pretty good language to use. But if you only need a little bit of it and still want to use Axe, jacobly's floating point math axiom might be useful. It doesn't evaluate expressions as text; the functional format it uses may be a bit cumbersome, but it does avoid the interpreter overhead that way.
96
« on: November 20, 2015, 02:57:21 pm »
I did use the mini USB port.
And I have to use the mini USB because the guys wnating to play the game(thats what im trying to create)
only have the mini USB link cable.
Is there really no way to send any data with that cable?
It's certainly physically possible to send data with that cable, as the OS does it. But as far as I'm aware, the OS doesn't expose its code for this. At least, not in a useful manner. And USB is more complicated than a simple serial transfer, and nobody has implemented their own code for calc-to-calc USB transfers.
97
« on: November 20, 2015, 01:06:54 pm »
What is the proper way to send data from one calculator to another?
The Command List says "Send(" can send a byte, which is a number 0-(2^8)-1, but when I try to send a Variable and get the Variable with "Get->A"
A doesn't have the value that was sended.
I did loop Get, until A≠-1 but A wont change...
First question: what kind of link cable are you using? Because Axe can only send data over the serial port, not the mini USB port. If you are using a serial link cable, though, sending data should certainly be possible. In this case, could you post the relevant code? Sending data between calculators can be a bit finnicky in terms of synchronization, which is usually why link code doesn't work.
98
« on: November 17, 2015, 07:44:13 pm »
I have been hunting around and I can't seem to fine a good tutorial on how to use the VAT.
Can anyone give me a good tutorial? (I got lost at reading backward)
I mentioned this tutorial in a response to an earlier post of yours, which gives a rough overview of the structure of the VAT and how you might scan through it with Axe. And I think I mentioned it before and you didn't seem too interested, but either the official MemKit axiom found in the Axe download or the alphabetical MemKit axiom can provide this functionality for you. Also, does anyone have a list of all the OS memory location? (like the VAT is E9830 and E982E and the text pen is E86D7 and E86D8)
Thanks! 
The most complete list is found in the equates file used by assembly programs; search for "RAM equates" for the relevant section. It doesn't document what they all mean, and there isn't really such a documentation. WikiTI documents a few, but I've never found this particularly useful. Information about how RAM areas are used is generally found paired with documentation of system calls that interact with them.
99
« on: November 08, 2015, 12:20:13 pm »
Is there a way to display the custom tokens? I can't seem to find a good way to choose tokens without creating a program with them or by chaining if statements.
I'm not sure what you mean. Could you elaborate?
100
« on: November 05, 2015, 04:26:03 pm »
Is it possible for a pointer to move itself as in A +10 -> A?
I am using A as the pointer to a program.
I don't understand what you mean by a pointer "moving itself," but A+10→A is certainly valid and increases the value of the A variable by 10. And if you were using the value of A as a pointer, then you've "moved" the pointer (more accurately, you've changed the location pointed to). I am trying to be able to read programs longer than 2^16 bytes.
Variables on the calculator cannot be larger than 2^16 bytes = 64KB, and there's only up to about 24KB of free RAM. So I'm not sure what you're getting at here. If you did want to be able to edit large programs, you'd have to store it in smaller pieces.
101
« on: November 04, 2015, 03:35:29 pm »
Awesome! The only other thing I need to know (for now) is what is the best way to find a program's size?
Is it with the length( command or with {ptr - 2}?
{P-2}r is the correct way to read the size of a program, appvar, picture, string, or equation variable pointed to by P. Note the r modifier, which was missing from your otherwise correct second suggestion. edit: is there a way to get (not set) the cursor's position?
Since you're working on a small font program editor, I'm going to assume you mean the graph screen cursor, which is actually called the "pen," rather than the home screen cursor. The pen cloumn is stored at penCol = 86D7h and the pen row is stored at penRow = 86D8h. Each are one-byte values, so you could read them with {ᴇ86D7} and {ᴇ86D8}. But if you plan on referencing them a lot, you should probably turn these into named variables with statements like ᴇ86D7→°PX and ᴇ86D7→°PY and then reference them with PXʳ and PYʳ.
102
« on: November 04, 2015, 10:14:20 am »
Is there a way to tell if a token is one or two byte when you display it?
All two-byte tokens have one of the following hexadecimal values as their first (low) byte: 5C 5D 5E 60 61 62 63 7E AA BB EFFor the purpose of displaying a token in Axe, you shouldn't need to do anything different for one- or two-byte tokens. I guess that could be another reason why the input for displaying a token is a pointer rather than an actual token value. The display function can tell if it's a one- or two-byte token after reading the first byte and then only read the second byte if necessasry.
103
« on: November 03, 2015, 08:50:01 pm »
How would I write tokens back to the program? "token" -> A doesn't work
→{A} for one-byte tokens and →{A}ʳ for two-byte tokens. EDIT: And if you're using tokens, you probably shouldn't have to have their string data anywhere in your program. You should just be using the token codes, which (as previously suggested) are one- or two-byte values. In case you weren't aware, you can get the value of most tokens in Axe with the Ttoken syntax.
104
« on: November 03, 2015, 08:11:23 pm »
For the tokens I have decided to have the program written out in letters so it is easier to display and have it convert each command to token form when the user quits.
I wouldn't suggest this method, but it's ultimately your decision. As I understand Axe has a limit on the number of named variables (around 150?) and this would bypass that since when it is written to the program it would be written as {L1 +8}
It depends on how long your names are, but it's closer to 1500 than 150. I can't imagine a program using that many named constants/variables, or if it did, it probably wouldn't matter because it would be too large to fit in RAM and actually be editable. I must be missing something on the >Tok command. When I ask it to display {A} (or {A}r) >Tok, it displays a completely different token.
The OS calls for displaying tokens require a pointer to the token to be displayed. And Axe uses these calls to implement ▶Tok, so the same applies. I presume this decision was made because tokens are almost always displayed as part of a program or string in RAM, and putting the read in the call saves callers from having to do so. Since you're also editing a program in RAM, this decision should actually make your code simpler. Just drop the curly brackets for the memory read.
105
« on: November 03, 2015, 07:42:59 pm »
I am not sure whether to go with writing out programs by letters (which would be easier to display and make the editor smaller) or by tokens (which would make the editor much bigger but the saved files smaller).
It looks like reading and writing the programs will be the hardest part (so I can compile code written in the editor or edit it in the basic editor also).
If you want your files to be usable by anything else on the calculator, tokens are the required format. It would be really cool if it could display code like "{L1 +8}" as "boss1hp" if the user declares the name. That way variables can have really long custom names and there (theoretically) is not a name limit.
For editing Axe programs, which it looks like is what you're alluding to, I don't think such a feature would need to be supplied by the editor. The Axe language already lets users declare named constants/variables. In your example, the user would declare L1+8→°boss1hp and could then refer to it as the one-byte variable boss1hpr throughout the rest of the code. Is there any way to convert between the program editor tokens and the display tokens without way too many if statements?
You mean displaying the string represented by a token code? Using the ▶Tok conversion with a display command does this.
Pages: 1 ... 5 6 [7] 8 9 ... 153
|
Show Posts