The Ti calculator API is a set of macro's and routines that is assembled to make calculator programming in z80 more simple. Normally, you have to deal with all those pesky registers and Ti-OS routines, even if you just want to display a simple string. With the Ti API you just tell the API to output the string for you, and it'll do all the boring work!

And convert it to working code. This will ask you a few questions in the graph screen, and respond depending on whatever you type in.

I'm not sure if this is worth the name API, but I guess it's as close as it gets to one on a calculator And I must say it's a hell of a lot more fun to code simple things like in- and output in this way than in pure asm.

How it worksNope, it's not object based, nope it doesn't add redundant code and nope you don't need a new compiler. The include file that I'm working on defines a few macros for TASM if you include this at the beginning of your file:

Code:

#define api_defines#include "api.inc"

The ones that are more complex than a few lines call one of the routines that you include at the bottom of your file (or wherever you like) like this:

Code:

#define api_routines#include "api.inc"

TASM will "know" which routines need to be included and which need to be left out based on the ones that you actually use, so it shouldn't clutter up your memory with useless code.

I'm currently working on link.println(str) and link.readln(buffer,maxsize) to enable writing a string over the link port, but the Ti-OS routines don't seem to be willing... And I NEED to go get some sleep because I have to get on a bus to Germany in seven hours

The input routines are pretty crude at the moment. You can type in caps when you turn Alpha on, and space works, but that's about it. I hope to be able to use Ben's routines once he's done with his keyboard project, so that you can use just the Ti keyboard or also an external one by adding another define. Either way, it would be abstract to the programmer where the input comes from, as long as he gets some input from the API.

Anyway, my list of ideas (so far):

Code:

- Add word wrapping (it wraps already, also in the graphscreen, but not at words)- More String routines (append,copy,etc)- Better linking (get it working :)/faster/running in background/more than 2 calcs)- file.read(filename) / file.write(filename,data) for programs- var.read(varletter) / var.write(varletter,value) for A-Z vars- str.read(strnumber) / str.write(strnumber,data) for str0-str9- menu.choice(str1,str2) to give a choice between two things (return in z and a)- menu.alert(str) to give an alert that goes away after a keypress- menu.question(str) to ask "str? Yes/No" (return in z and a)- menu.options(menu) to give a proper menu (.db 1,"Option one" \ .db 2,"Option two" \ ... \ .db $FF) (return in a)

I don't really plan on making all that myself, but since this is all just a collection of routines anyone can optimize it and add to the API once I release the source. I plan on making a simple website where you can download the latest version, and submit ideas/improvements et cetera.

Please let me know what you think, but don't expect any response from me untill after the weekend. (Convention in Germany, see my girlfriend, party in Groningen on saterday night, calc convention on sunday in Amsterdam... so much to do ) Good night!

well basically rather than having to write the several lines of code for certain functions you simply have to remember macros. The benefits is it would be quicker to code simple interfaces that would normally take couple hours for inexperienced coder. Interface can be a time consuming part of coding, I can imagine this might speed things up a bit.

I hope you plan on include graphic routines.(Sprite, mapping)

How do you plan on handling a variable or constant? like say something like this:

I've slept for the amazing amount of three hours because I couldn't stop thinking about this But anyway, here's some short answers before I go get my bus:

Jim e wrote:

I hope you plan on include graphic routines.(Sprite, mapping)

How do you plan on handling a variable or constant?

Well, the big idea is that everyone will be able to add and improve routines, it's like a replacement for that codebank idea that kv and I were working on a while ago, so yes I do expect sprite and mapping routines to be included in the near future And at the moment you just give it a pointer to a string, and it displays it. To make a string with changing content, you could point it to a buffer and use the string routines (that haven't been made yet ) to copy/paste some text in it. Or you could call the println routine "by hand".

necro wrote:

so, do you think you could explain this a little better for us with little to no asm understanding?

Well, think of it like this: in the final state where I hope to get, this include file would contain the combined knowlegde of half the community. So when writing a program you could rely on other people's routines, without having to copy them in and understand what it does. You only have to deal with the interface. In other words: ASM will become almost as simple to code in as Basic (except for if-statements and for-loops).

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum