Feature Requests

[Harrierfalcon]

You can read programs from archive...

[magicdanw]

Just to let you know, BASIC programs can't be executed out of archive without copying them to ram first, at least without some serious OS-modding, or writing a custom BASIC parser. Even CalcUtil copies the programs to ram before running them.

[Iambian]

What say you about an exact functional replica of xLIB implemented into Celtic III? By that, I mean that I include all those "real(" commands as they are in such a way that any program that uses xLIB will also be able to use Celtic III with no necessary modification.

The reason why I ask about this is because I've received some criticism regarding how I'm supposed to implement xLIB compatibility, so I figure that keeping it "real" would be the best thing for just those functions. This, in no way, will diminish the importance of the other chosen tokens ( det and identity ).

For another, smaller reason, I'm doing the real thing because there exists a speed issue if I try to use det or identity, especially det. Since xLIB makes fewer checks as to how real( is being used, I can write some code that'll possibly accelerate the processing of the arguments.

[vuurrobin]

some ideas for commands

1) a get os version command, usefull to see if some tokens will be displayed right or to see if the ungroup command works.

2) a check battery command, there is a romcall for this, so it shouldn't be so hard, a simple 1 or 0 to see if the batterys are ok or not is good enough.

3) maybe a get (parsial) calc id command, I heard that getting the full id is really hard to do, but if we could get a piece of it, it would be great.

4) pack the get ram/rom/calc/os/battery/id into 1 command

5) a linking command, basic really needs a good linking command. timendus on maxcoders created a linking protocol, maybe you could use that.

what I had in mind is that an asembly hook checks the linkport to see if something was send from another calc and store that while a basic program is running. it would cause some slowdown, but it would be very usefull for multiplayer basic programs.
so you would have a sending command, a getting command and maybe a command to see if the linkport is bussy, so we know if its done sending something.

6) either a command to find and extract numbers, strings, lists, matrices and the like from groups, or the ungrouping command without the trash on the screen (can't you block updating the screen or something?)


these are all the commands I can think of now, but if I remember some more, I'll post them

[Art_of_camelot]

I like the suggestions of #3 and #5 also. I think that both of them could be really useful . If you have the time and the space to add them that is . Im not sure how much space you have left or what kind of space either of those would require. Checking the ID should be pretty small ( I rember seeing an entry on this in the wiki or somewhere). I would think that linking would take up a significant amount more space.

[vuurrobin]

well, timendus created a linking program to be used by basic programmers that is below 400 bytes. of course the hook would be bigger, but it wouldn't have to be that big.

[vuurrobin]

I thought up another function

a speed toggling function, to toggle between 6 and 15 mhrz (or whatever you spell that) for the calcs that support it. handy for multiplayer games that are between a 83+ and a faster calc.

[Liazon]

linking would be cool. the most annoying thing about the link is you can only send data 1 bit at a time. most likely Iambian will have to set up some kind of queue/buffer structure to handle what comes in and out, similar to usb8x iirc.

[Iambian]

I'll just end up going with the romcalls that are already in the TI-OS to handle data transfers (likely in the form of sending programs/variables). This will hald the calculator in some way, but that's probably a good thing, maybe. I dunno exactly how this will work, since I don't know if the BASIC program will remain intact if a variable is sent over the link silently.

If something wrong with the implementation happens, I might just send the information like how Omnicalc sends it. I'll need a couple of calculators to test this, though, especially between the old TI-83+ and the newer ones that support link assist.

On another note and an answer to a previous question, you should be able to change the clock speed yourself if you happen to know the hex codes for doing so. Just use the EXECHEX command to run it.

[vuurrobin]

when you get a variable, will it overwrite the current variable on the calc, since that wouldn't be handy if you would try to get the opponents coordinates and it would overwrite your coordinates. also, would you be able to get single elements from lists?

and how big would that slowdown be for real vars?

[Zaphod Beeblebrox]

How difficult would an omnicalc-esque "play(" function be? Because that would be really nice. That way one could do good graphics AND sound in the same program.

[magicdanw]

I think I remember reading that Celtic III was pressed for memory, and glancing at Omnicalc's play function, it's f*ckin huge! So, I'll let Iambian speak for himself, but it looks unlikely to me...

[JoostinOnline]

[Zaphod Beeblebrox]

I know it pauses until the music is finished, but it would be useful to add sounds to keypresses or something similar.

[brandonw]

[Demon]

Since the TI-83+ SE has those crystal timer things, it would be awesome if there were some timer functions for the 83+ SE. I need these very badly 'cause I want to improve my synchronized lyrics display and editor.

[Iambian]

[brandonw]

I put most of those on WikiTI...if they don't say a minimum version, then that means they exist on all versions. They're safe to use everywhere, or I wouldn't have suggested them.

The silent link hook was added in 1.13, but that's just a hook...all the silent link stuff has always been there.

[Iambian]

I've just thought of something, though I'm pretty sure this was suggested some time ago.

For xLIB support in the Celtic III application, I have a mode set such that if any error is tripped while running a Celtic III-specific subroutine, such error is suppressed to avoid incompatibilities with xLIB behavior.

Should I have a settable mode that will tell Celtic III exactly what to do with tripped errors, configurable between each of the three sets of instructions (det,identity,real)?

Modes can include full suppression, numeric error code, string error code, output type match, ERR: screen, and perhaps any other suggested.

[vuurrobin]

how will we be able to check and chanse the error modes, so the programs don't gives an unexpected output because the user chanced the modes.