Now we have a need for Omicalc's ExecAsm( function! This could be a real help... archiving or locking/unlocking programs within a BASIC program.

But that's why Kevin uses Flash Gordon and Codex, to unarchive/archive programs in BASIC (and just copy them to RAM).

I don't care how hard ASM is. 83+ basic programers always earn more respect from me.

Provided their programs are good.

Yes, it is hard to compete with most of the ASM programs, but some of these BASIC programs can actually run faster than some of the z80 programs! I try to compete with them, and *I* think I do pretty well at it, but, still, BASIC is nothing compared to ASM.

I was very impressed with that basic bomerman game. It ran nicely on my regular 83+!

Kind of reminds me of an ASM tool I was developing for use with BASIC. There seems to be a good amount of ASM utilities for doing better Graphics in Basic, but the fact that Kevin used lists to store game data indicates that data manipulation/storage is still a problem in BASIC. The tool I was working on would greatly help to solve some of the problems, but since there was a lack of interest in it's completion, I've went on to other things. If people are interested in it, I could pick back up on it again. The beta version is at the web page link on this message if you are interested.

I am very interested, any form of data storage would be very useful, but what exactally do you have in mind?

Wow, someone IS interested in it. :D Maybe I'll get back to working on it again soon.

Ok, actually, the BETA version I have uploaded here works great for storing numbers and can be riged to handle strings (but currently very slowly). If you know anything about memory, it allows BASIC to work with data at a byte for byte level.

It's pretty simple. You create a file of a size in bytes. Then you read and store data to whatever byte in the file you want. To prevent clutter in the prgm menu, the files are stored as AppVars. I also enabled direct reading of archived files. You can read without archiveing, but to make changes to files, you have to unarchive them first. Since map data, script/text, pictures rarely change, it would be best to keep them in archive to free up RAM required to play a game.

Just in case: A byte is an 8-bit number that can store a number between 0 and 255. Since ascii is also 8-bit, you can also store text as bytes. Working with individual bits allows you to store pictures as bytes, though pictures are least of my concern since there are already asm tools to handle pictures through slightly different methods.

Now, one of my goals is to make the interface to the functions much like OmniCalc. If you have ever used Omnicalc, you will have noticed that it adds new commands that can be used in basic like Sprite(. If I ever figure out how to do this, I will try to implement it as it should speed up and simplify the interactions with the functions.

Oops, I made some mistakes in this post. Let me clarify:

Where it says, "You can read without archiveing, but to make changes to files, you have to unarchive them first," It should say, "You can read files that are archived, but to make changes to files, you have to unarchive them first."

I know I proofed it, but I must have been really tired to miss that mistake.

I read the readme, and I think that creating text-storing appvars would be very useful, though I'm not quite sure if that is even possible. It's been a long time since I've messed around with ASM.

It is quite possible, I just haven't figured out the best way to get/send paramaters from/to BASIC. So far, my best solution has been:

"test"->Str0
{paramater list}:asm(prgmRFLIB

to store a string, and

{paramater list}:asm(prgmRFLIB

to get a string (the string would be in Str0).

I'm not to fond of having to have multiple lines of paramaters, so I stopped for a bit to try to see if I might be able to use tokens like OmniCalc. I may not be able to create my own tokens, but the method above is very doable.

I think you'll need to make an app for something like that.

From what I've seen, It looks like that might be the only choice for that kind of interface, but I would hate to waste the space since I know I don't yet have anywhere near 16kb worth of functions yet. I only have between 1 to 3kb, so doing it as a program seems to be the best way right now. Maybe if this project continues to grow beyond it's original purpose will it ever approach 16kb and then become worthy of becomming an app. Oh well, that's pretty far into the future as far as I'm concerned. I'm just going to concentarate on completing RFLIB as I had originally planned to do it.

From what I read about it it seems a little bit complicated, I think a good way of doing it would be to have maybe a few programs...
prgmRFLIBSTR
prgmRFLIBLST
prgmRFLIBMAT
and depending on what you're storing it uses it, like, maybe something along the lines of
lLIST->L1
1->A
Asm(prgmRFLIBLST
and RFLIBLST always reads the list in L1 and then stores it in the AppVar number that's in A, and basically do that for all of them (well, not the same thing, but similar).

Because of the length limit of posts, I can't include everything I meant to say, so when you see ..., that means I cut something out to be able to post it. If something doesn't quite make sense or seems incomplete, blame all the spammers who moved ticalc.org to enforce such a limit.

Actually, that's very similar to how the project started back when I called it the "RAM File Manager", ... . Before I changed the way I did it, the "RAM File Manager" supported only the first 4 functions, 53 file names, and no error checking. I also believe that even though it was a lot more incomplete, the four files together were almost the same size as the current RFLIB version (RFLIB supports 99999 file names, error checking, and more than twice as many functions).

In it's current form, you could store multiple lists and matrices in the same appvar. Of course, the older method also allowed this, but I had to use more than one variable. ...

Another problem is that you would need programs to recall those vars after they've been stored. ...

Another problem was storage space. There is a good amount of code that is shared between almost all functions, so splitting the functions would either require each function to have their own copy, ... . I would estimate that splitting the functions may double or even triple the current size of the library.

The last issue with dividing the functions is convinence. If someone wants to uninstall/delete RFLIB, they only have to delete one program file and any appvars they created with it. ...

It's actually a little easier to code each function as its own program, but it just seems to make much more sense to make it the way it currently is.

Thanks for your input.

Wow...this would take a long time to do in assembly, and much longer in BASIC!!! Must have taken a lot of patience on the part of the author - I could *never* work on something for that long...

Would this really take longer in BASIC? I've always thought that pretty much anything would take longer with ASM.

may take longer in basic if the whole thing was done on calc as opposed to computer. ASM programmers generally have comments and copy/paste functions that help speed things along. Though graphlink is available to use to program for BASIC, I don't think many basic programmers use it since it can't go to math class with them.

Any program I program in BASIC, I program straight onto the calculator. I have Graphlink, but I only use it to examine code when I'm too lazy to send it to my calculator.

I'm pretty much the same way, and after a while I was able to type as fast, if not faster on my calculator.

bleh, i would love the zelda game on my calculator but i dont have a serial graphlink...only usb... but i do have alot of other calc stuff though, hehe heres the list:

Ti-81
Silver Edition Ti-83+
Silver Edition Ti-83+
Silver Edition Ti-83+
Black Ti-83+
Black Ti-83+
Ti-83
Ti-89
Ti-89 Titanium
usb graphlink
usb graphlink

wow... thats nine calculators... and two graphlinks jeez, i should stop buying these things...

Why do you need 3 83SE's and 2 USB and serial graphlinks? It's just wierd. BTW, where do you get all the money to pay for all that?

Dude... Something is wrong with your head... It's ok to have all the calculators, but just have one of each kind. Something is wrong if you have three of the same calc!

Sell one of your SE's, and buy a regular Graph Link. Or sell two of your SE's, and buy a TI-Keyboard :)

I'm pretty much the same... typing fast gets you the awe of your classmates it's pretty funny... I'm suprised by the dedication the programmer of these games puts into his hobby. I myself programmed many, many RPG's for the calculator but all could fit into RAM ;)... Now working BASIC with asm makes it a much more powerful tool... it's a good idea although I wouldn't have the patience to work 900 hours on an RPG: generally they're finished within maybe... 40 hours? (big difference!)