Post updates on your projects here, or give other authors your feedback on their works in progress.

When posting about an upcoming program of yours, please include a link to any relevant information (screen shots, etc.) in the URL field.

To have an entry removed, please Contact Us.

my prog just stops when i want it to do the getkey function again (over the repeat from the "goto lbl") so the user can select another item from the menu.

all that is there is a label, then my getkey stuff (that works the 1st time), then the program corresponding to the getkey value, then a "goto" at the end of the program sending you back to the label at the start. ..no getkey the 2nd time

how can i make this go away???

Try replacing all of that with this
(0 -> A
While (A = 0)
(getkey -> A
End

It will wait until the user presses a button before going on, and will remember their answer even if you do other calculations later. It works every time through. I personally just wrote a program prgmGETKEY that did all that, and just executed it every time I needed a button press.

Yah, that's the basis for pretty much any getkey system. It's kinda hard to do it any other way.

Just a heads up, my method is as folows

Lbl A
Getkey -> G
If G=0
Goto A

This is nice because you can also have this use as well:

Lbl A
Getkey -> G
If G=0
Goto A

(code to check if keycode G was valid)

(example of key check for when the up key is pressed and the cursor C is not at top position)
if G=25 and C>0
then
Output(C,1," ")
C - 1 -> C
Output(C,1,">")
End
(end example)

(After all the checks, no valid key was pressed, or need to go to the get key function again.)

Goto A

A thing to note about my method: I think it runs the fastest because the TI-OS doesn't have to put any program counters on stack like in a while...end loop or a prgm call. A goto with labels is the fastest and safest way to create loops in BASIC.

Well, Your'e only half right. Yah, the labels can be faster since the calculator doesn't have to constantly check for the conditions of the while or repeat. But your biggest problem is that many programs are really big. And if you put this lable getkey thing near the bottom of a big one, It will take a whole lot longer. This is because when the calculator sees the goto, It goes from the top of the program to the bottome scanning for the lable. That sometimes takes a while. My favorite method works as followed for lets say... moving an object around the screen:

Delvar A
1->B
1->C
While A=0
Getkey->A
Output(B,C,"X
If A=24 and C>1
Then
Output(B,C,"_
B-1->B
End
If A=25 and B>1
Then
Output(B,C,"_
A-1->A
End
If B=26 and C<16
Then
Output(B,C,"_
B+1->B
End
If B=34 and B<8
Then
Output(B,C,"_
A+1->A
End
End

This is real nice because you don't get a blinking cursur or anything.

Your code has problems, I tried fixing the obvious errors, but it doen't seem to work the way you wanted it to. Your code also slows down response times by checking key codes when no keys are pressed, it is much more responsive when you check to see if a key is pressed first, then check the key codes. A possible combination of our techniques would produce this, which would probably run better than either technique alone:

Lbl A
While A=0
getkey->A
End
If A=24
Then
.do something.
End
If A=25
Then
.do something.
End
.so on and so on.
Goto A

Keycodes aren't checked when keys aren't pressed in this example. Since Lbl A is at the top of the program or near the top, This would work rather quickly.

Whoa, man... I just looked back at my code... Whew, that was pretty funny. I totally screwed up the variables... BADLY. Anyway, If i had gotten the variables right, then it would work magnificently. You're right that it does go through the whole program every time and does slow down the key response a little. What I do in that case is...

...
While A does not equal 45 (clear)
Getkey->A
Output(B,C,"X
If A=0
Then
//Most of everything else I wrote in my last post (with the correct variables, sorry bout that, must have been tired or something)
End
End

That way the program skips everything unless a button is press and you still don't have those pesky lables (I dunno why, I just don't like labels). Anyway, if you fix ALL of the mistakes I made, then it works real nicely. If you need an example, take a look at some of my games.

Doh, I meant If A does not equal Zero. Man I'm bad at this

I just have the getkey function in a seperate program, and whenever I need to use getkey, I have the main program run the getkey program (this way I can use it for alot of programs and save myself some code)
the seperate program would be:

Repeat ans
getkey
end

simple, eh? and it uses ans up instead of a variable. w00t!

I've found that the easiest and smallest amount of code for a GK loop is:

getkey -> K
Repeat K
getkey -> K
End

or even:

getkey
Repeat Ans
getkey
End

(thats only 5 tokens on 4 lines (8 bytes))

Yah, but it doesnt do anything. The point is it has to at least do something like move a cursur or something.

he means to use something along the lines of this...
(the "//" and anything following it is a comment and is NOT part of the code, "-->" is the store symbol)

While 1

GetKey
Repeat Ans
GetKey
Ans-->A //Any test on "Ans" alters it's value so I End //need to save it somewhere

//put all "If...Then...End" statements concerning the
//value of "A" here

End

He means to use something along the lines of this...
(the "//" and anything following it is a comment and is NOT part of the code,
"-->" is the store symbol)

While 1

GetKey
Repeat Ans
GetKey
Ans-->A //Any test on "Ans" alters it's value so I End //need to save it somewhere

//put all "If...Then...End" statements concerning the
//value of "A" here

End

[Sorry about the double post but it messed up the first copy of it]

I am releasing my FINAL version of PearJam, by the end of February and will also be launching a web site with the same idea as ticalc.org. It is for my newest venture: "The PearONE Network". This is where newbies as well as gurus in TI-Calculator Basic/Assembly can gather to work on projects together from all over the country. It will also be a place to download these programs. The only catch is that "The PearONE Network" will make these programs available for download one month before they are sent to ticalc.org. Check back later, because I will be posting the web address for "The PearONE Network" under this comment.

If you would like to join "The PearONE Network" you can send me a list of your abilities and your desired screenname/password to: joshuak@intercom.net.

Thank you,

Joshua Kendall.

I would like to make the world's greatest OS!

You dare laugh? It will be done by April, and will be based on the Linux OS.

Look for details on this thread later after alpha testing.

\\Joshua Kendall.

I am developing a high-level programming language for z80 calcs (starting with ti83+). It will be like the better parts of C++ & Java, but it usess syntax and commands from TI-BASIC, and many stuff defined in assembly (it can do anything you can do in assembly).

The variables will all be user-defined (aside from the readily accessible system vars) and can exist in MULTIPLE INSTANCES. Routines take and return values...I've been going at this for several months now, and I have a site with 30+ people involved. If you are interested or want to help (not that it is greatly NEEDED, but it would be nice and I want to give people the chance to be part of this).

I'm sure this will be very popular and well-known when it's done; this is the biggest thing since...sliced bread (They make news about simple BASIC programs that look cool...THIS will be very...[adjective]...you tell me).

NOTE: the following address had to be spaced out or it wouldn't let me post it (exclude the spaces)

webpage: http:// groups.yahoo.com/ group/ HighLevelz80
email: shkaboinka@yahoo.com

THAT POST IS OLD and much has changed since then. The project is much better and VERY NEAR COMPLETION; I just need a little help with some assembly stuff; see the NEW link and talk to me if you care:

http://groups.yahoo.com/ group/Antidisassemblage

(remove the SPACE before "/group")

You can email me at shkaboinka@yahoo.com
or send an IM to CrazyProgrammer

Thanks to all who downloaded the pre-release version of the RAM file manager. I'm just going to let everybody know what is going on with it now.

First of all, I have fixed the naming problem, the full version will allow names from 00000 to 99999 (I may add another digit, but I think that 100000 possible names is good enough, there isn't but 24000 or so bytes of RAM). This is significant because the current naming allows only 10 to 63 to be used and my file said that the max would soon be 65535, but that changed because I found a better way to do names.

I will also add error checking to all of the programs (This is what is taking the longest). I may re-format the way it handles input as well for clarity.

Also to note, some of the new functions that will be added will enclude a char to integer, a ineger to char, a couple of string modyfing functions, and functions to resize the RAM Files.

I may also make all the programs into one library program so that the 11 or so planned functions don't clutter the program menu.

Any questions or comments, post here or just e-mail me for quicker results. Thank you for the interest.

Just one thing I though of, I want to make other functions for BASIC, but I can only work on one project at a time, so, which of these libraries would you like to see next?

-Enhanced String capabilities

-Compressed pictures (quick loading anyway, saving might be another story) with RAM limited number of pictures

-String Compressor/Decompressor

-Graphic functions (like a faster circle and black and white lines that use pixel coordinates and possibly some sprite routienes along with allowing full screen)

-Basic grayscale and graphic functions for drawing and animating in grayscale (if this is wanted, it will take some time, but would be well worth it)

-a timer for basic that runs while the program executes (believe me, this is possible)

If you have any other ideas, just let me know. I just want to know what people want.

I'd definately go with the graphing functions

You're the only one to respond so far. As soon as I get back from spring break, I will try to put the finishing touches on the RAM file manager and then I will work on the graphic programs since I'm working on a basic program that would benifiet from drawing white lines rather than being forced to erase pixel by pixel. I'm also working on a slightly improved interface that offers the advantage reducing the program size and the number of programs to one. I also want to use lists to pass paramaters with, but this is proving somewhat difficult and would not be sutible for beginners because functions would be numbered rather than named. For instance, the RAM file manager functions may soon look like this:

the create RF might be replaced by
{1,15,25}:prgmRFLIB

delete RF might be replaced by
{2,15}:prgmRFLIB

and so on. The first number would be the function number. This would eliminate repetitive code common to all functions (like RF recognization and location) and keep the prgm list small for basic users. I know it can be very fruterating to have many programs under the exec menu, so I've considered this idea. The other idea would be to do something like omnicalc and use an app to just add tokens rather than calling a program which reduces the number of bytes required to call a function. The problem is that I can't seem to find any documentation on how to create tokens and menus for the TI-OS. Does anyone know where such documentation might exist?

Just an update

I am changing the format of the input to the kind as stated in a previous message. This will cause the programs to be more suitable for advanced users, but it will keep the size of the program down and the number of programs down.

I will start the graphics program soon using the same input and I may combine the two projects together and create a new project which I will call the Basic Plus library. I will keep the projects now and in the future seperate as well so that users could also choose only the parts they want, but for those who would like all the parts, they could use the Basic Plus library to conserve space that would be used by all the file names and repeated code and it would only take up only one program in the EXEC menu.

At any rate, I will try to post updates periodically for anyone who actually reads anything here.

Another update...

I'm having a little trouble with the program when the calc runs low on memory. Don't worry, I'll soon be done with the problem.

Two interesting functions I will include now are functions to check how much RAM and flash memory is left. Handy for those basic programmers that like to make pie charts showing free memory.

If I had to judge how much is complete. I would say about 15% of the functions are written and about 60% of the code (the functions that I haven't written yet shouldn't be very big.) The largest part of the code turns out to be name recognition and paramater interpretation which is used by almost every function. I'm also having to write a routine to replace ConvOP1 as its limits are no good for this project. This will take up a little more space and will take more time, but the project is still continuing.

Hey, good to see that you're sticking with it. well, sounds like the program is comming a long nicely. I just thought I'd say something... I know what it's like being the only one talking on a page.

Thanks. Easter weekend will give me a lot of time to work on the program, but I don't know if it will be finished. Maybe I'll release a part finished program untill I finish it. If you want you could beta test the program for me as I get parts finished.

Just e-mail me if you (or anybody else) are interested: Qbman321@aol.com

This is yet another update, but there is some good news.

1. The memory error has been fixed. It was simpler than I thougt, I just forgot to clean up the stack when the program quit, and that would corrupt the ram on the flash debugger. Now it runs smooth and warns you when you run out of ram rather than crashing.

2. I now have more than the original four functions working, so if anybody wants to beta test this library, they need to e-mail me.

3. This is the first bit of awesome news. GetRF can now read from files in the archive without unarchiveing them first. This will allow basic programs to use the flash for data storage intended to be read. Perfect for text and graphics in a game.

4. This is the next bit of awesome news. While debugging GetRF, I discovered some hardware ports that might allow me to put a large portion of the library in the flash and run it straight from there like an app (but without requireing a mostly wasted 16000 bytes). This will first of all reduce RAM requirements from the current size of about 900 bytes (completed size estimated about 1100 to 1200 bytes) to just under 100 bytes. Of course, the other 1000 bytes would have to be in the archive, but that memory is so much larger anyway. The first version won't use this feature, but if I get enough feedback, I might try to make a version that uses this feature so future libraries don't have to take up so much precious ram.

I would like to see more feedback, but although I'm not, I'm sure that there are people at least reading this.

Just to let everyone know, there has been a delay. I have had several computer problems and I have spent the last couple of weeks trying to piece together a computer that will hold. I have not lost the source code; in fact, I backed it up on a cd-R and a cd-RW. I have finally put together a computer I think will work as long as I don't have another hard drive or monitor failure.

Another part of the delay is the end of school. I am constantly running around trying to get everything done, so I haven't had much time to work on it.

And finally, I am not getting feedback from anyone, so despite it still being a beta version at this point, I will clean up the readme and post the program here soon to try to attract attention.

On a good note, however, I have set the plans for more new functions because I have come to realize that formatted data could be hard to work with (such as lists and floating point numbers), so I am will add support for strings, lists, and floating point numbers (unless there's demand for it, I will not likely support matrixes, but instead include hints on how to deal without). Support for floating point numbers already works.

If I feel like I have enough time, I will include support for changing the size of the files.

And sadly, I am already finding limits to this library. Without access to information to be able to do what omnicalc does with its tokens, I will probably have to move some (probably all to keep everyting uniform) inputs and outputs to system vars. I really have not liked this thought since there are aroun 30 usable vars in BASIC and only 10 strings (about 40 if you count all the functions).

As soon as things calm down again, I will continue to work on the project.

Amen to that! Another reaspon to do this is cuz omnicalc doesn't work on OS over 1.14

I only use os 1.14, but Omnicalc needs an update (BAD). Anyway, when I complete RFLIB, I will start on a graphics library that should be compatible with 1.14 and up (and likely lower as well). A graphics library should get a quick start since I will use some of the code from thr RFLIB to work with inputs and outputs. If I get really lucky with time and talent, the next library might be able to run from flash without being a bulky app. I have discovered how to run executable code from flash pages within a asm program. I haven't had the time to actually write out the code, but the planning of the concept is about 80% worked out; in fact, RFLIB already uses some of flash page reading without ROM calls. Flash reading will be slower, but will take up only minimal space (for small RAM code and whatever vars). This is a concern since RFLIB's beta version 0.68 already requires 1330 bytes free.

I scrapped the old idea (more like shoved it aside) for running from the flash. While looking at how the TI-OS archives things, I realized that it copied small portions of itself to RAM. It would use more space, but it would be about 10 times faster than my old idea. The amount of code for the main program would be lessend and the code could be run from Safe RAM which means the library may only need about 100 bytes of RAM to run. Btw, I haven't released the BETA version yet because I have yet to move it to a computer in which I can post it. I've also been busy with the last two weeks of school. Summer will start soon, so I hope to complete this project by August.

In other somewhat related news, I will hopefully submit a program which allows almost all BASIC drawing functions to write to the buffer instead of the screen. It actually works and it is only 28 bytes in size (8 for the name). I just have to write a readme before posting it, but it should be very beneficial to BASIC programs.

Alright! I've finally gotten around to documenting the project and submitting it to ticalc. Be sure to check it out under its new name "RAM File Library". I've added new functions to it and fixed various bugs and quirks. There have been some input/output changes, but they should all be explained. It also took some time to create the example programs.

I would like some feedback. Is this a good project or what? What would make it better?

I don't know the link yet for where the file is in the file archives, but I will post it once I know.

The RAM File Library can be found by clicking the web page button at the top of this message.