Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
quigibo wrote:
Not sure how realistic that goal is anymore. I was actually planning to finish by end of August.
Ah, I see.
quigibo wrote:
Its true though, I have significantly less on my to-do list in terms of commands to add. Those I will finish by then most likely. But I was planning a lot more things with the parser itself like improving the TI-BASIC editor, that help option on the menu that currently does nothing that everyone is asking about, 2 page app compiling, etc. I'm not sure what I will do, either start making it very stable so I can release 1.0 soon, or I can continue adding new features but at a much slower rate come September.
It sounds to me like the latter would probably be your better option, would you agree? I think I'd prefer to see a fuller, more complete, and still stable program later than an abridged but stable program sooner.

Does the calc-calc linking use the TI-OS routines or something custom?
Haha! I would never use the OS linking routine. It's hideously slow! I wrote my own that takes less than 200 T-states per bit so its nearly instant and you can receive large amounts of data with no noticeable time delay. It was a little faster before but it was occasionally receiving shifted bits between different models of calculators so I had to increase the tolerance.

I just wrote a quick program to test it; at 6MHz it can send the entire graph buffer in about one third of a second.
quigibo wrote:
Haha! I would never use the OS linking routine. It's hideously slow! I wrote my own that takes less than 200 T-states per bit so its nearly instant and you can receive large amounts of data with no noticeable time delay. It was a little faster before but it was occasionally receiving shifted bits between different models of calculators so I had to increase the tolerance.

I just wrote a quick program to test it; at 6MHz it can send the entire graph buffer in about one third of a second.
And it handles 6MHz to 15MHz even if the 15MHz calc is in fast mode? That's decently respectable.
Hmm, will axe be ported to other calcs?

Some other language for the nspire would be nice x.x
qazz42 wrote:
Hmm, will axe be ported to other calcs?

Some other language for the nspire would be nice x.x
I doubt it will be ported to the Nspire as a C program any time in the near future; note that it generates z80 ASM; making it generate ARM ASM instead would be extremely non-trivial in my opinion.
Indeed. Axe was pretty much built on z80. Different syntax and possibly a whole new language would be required for ARM.
calcdude84se wrote:
Indeed. Axe was pretty much built on z80. Different syntax and possibly a whole new language would be required for ARM.
Indeed. That's not to say that it wouldn't be possible, once the different architectures and screen sizes were accounted for, but it would be a ton of work.
The only assembly languages I've programmed for are x86 and z80, if ARM is anything similar to them I think it could be possible. The Axe language is designed as a higher level language that can translate directly to assembly kind of like C with each command corresponding to specific groups of instructions. It would not be trivial for sure, but I think it would be possible to translate it to other forms of assembly. So that's not the reason I say it would be impractical.

The main reason I wouldn't port it is because of the tokens. Axe syntax is designed around the limited tokens on the 83/84 series calculators and I am often forced to use modifiers like the "r" modifier to expand the commands enough without needing to have entirely separate tokens for similar commands. If the language were not token based, it would be much more flexible since you could have any command be named whatever you want and you wouldn't need modifiers.

So if Axe were ever ported, the syntax would have to completely change, but the core flow of the language would remain the same.
quigibo wrote:
The only assembly languages I've programmed for are x86 and z80, if ARM is anything similar to them I think it could be possible. The Axe language is designed as a higher level language that can translate directly to assembly kind of like C with each command corresponding to specific groups of instructions. It would not be trivial for sure, but I think it would be possible to translate it to other forms of assembly. So that's not the reason I say it would be impractical.
Fair enough.

quigibo wrote:
The main reason I wouldn't port it is because of the tokens. Axe syntax is designed around the limited tokens on the 83/84 series calculators and I am often forced to use modifiers like the "r" modifier to expand the commands enough without needing to have entirely separate tokens for similar commands. If the language were not token based, it would be much more flexible since you could have any command be named whatever you want and you wouldn't need modifiers.

So if Axe were ever ported, the syntax would have to completely change, but the core flow of the language would remain the same.
Ah, that makes sense. Is this something you have any plans to actually do, though?
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 2 of 2
» All times are GMT - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement