Questions Regarding Celtic III

[Iambian]

A series of questions regarding how Celtic III should turn out:

( 1 ) When selecting image files, should I start with 0 being Pic1 through 9 being Pic0, or should I keep to the xLIB style and go from 1 to 10? Benefits of the former being that you save a byte each time you access Pic0. Benefits of the latter include simplicity on the user's end. What should I do?

( 2 ) For the TokenCode command, should I just do away with the second "y" input and ask that the user convert the thing into one huge number in the even that two-byte tokens need accessing? If I follow that, then the code would be easier and it might alleviate some problems stemming from what x or y should be.

( 3 ) Does the command set need rearranging? I ask this because I could have the user save a little bit of memory by putting most frequently used functions in the single-digit section of the command list (1 thru 9).

( 4 ) Since the output is ugly and an OS of above 1.13 (shouldn't be a problem, tho) is required for the "UNGROUPFILE" command, should I remove that command and make the user responsible for their own ungrouping? BASIC code will be available as to how to work around the input of the GETGROUP and the EXTGROUP commands in their own little section sometime in the (near) future.

( 5 ) Does the error system need reworking? Since I do not really have a size limitation, should I include the option of displaying long versus short error codes? Does the long error codes require additional text to make the problem more evident ?

( 6 ) Do you think the inputs for any of the commands above should be changed out with something that might suit the needs of the programmer a little better? For example, should I condense, say, the TOGGLEARC, the DELETEPROG, the TOGGLELOCK, the TOGGLEHIDE, and the TOGGLEAVAR commands all into one command with an additional input to perform the requested operation?

Those are all the questions I have for now.

[vuurrobin]

(1) I would keep the xlib style, 1 byte wouldn't make much difference and I have already made some mistakes with the pic numbers. plus, you have xlib included, might as well keep it consistent.

(2) what would that number be, something between 0 and 65536? I also kinda like the y part, it allows someone to get the sto and doublequote token without using the function 2 times. you have to include checks to see if x or y is {92,93,94,96,97,98,99,126,170,187}, since that means its a 2 byte token. if x is one of those numbers, include y. if y is one of those numbers, exclude y

(3) well, it doesn't really need rearranging, but it might be usefull. commands like the var to string would more used than others, and if you were to compress functions into 1 (as you suggest in number 6) you would move the functions anyway.

(4)the good thing about the ungroup function is that it ungroups everything, including real vars, strings, lists, matrices, Y= equations, the window and table, ect. if there would be a way to get also those out of a group, then it wouldn't be needed.

(5) I don't think that we need both error outputs, so I wouldn't include toggling error codes. I think that the short would be better, since it would be smaller, and people can expr( it and use a temp file to display what the error was. then after debugging, they could delete the temp file.

(6)condensing some functions like that would be a good idea. maybe the same for createpic, delete pic, storepic, display pic ect?


I do have some questions/comments of my own.

there are some commands that are in the app 2, like the ram checking function. since you somewhere said that they are pretty much identical, it seems easier to take 1 out.

how much memory is celtic now, and how much is left before it gets to the 16k?



I thought I had some more questions, but I can't seem to remember them. I'll post them when I can



edit: what will you do with the version function, det(0. it was usefull for the program, but it is unneccesairy now.

[Iambian]

At this point, I could probably drop the "tokencode" command and have its users use the "hextobin" command, which basically does the same thing except you can generate any number of tokens you want, and the input is in a format similar to how it's displayed in the ti83plus.inc file (hex).

What do you think ?

[vuurrobin]

if the hextobin command can replace the tokencode command completly, then sure, go ahead and remove it. but you may want to explain in the readme how people can get that token with the hextobin command.

and for a table of the tokens, you can also put a link to this:

http://tibasicdev.wikidot.com/tokens

[Iambian]

One more.

Since xLIB will be implemented/embedded into this project, should I drop the hook chain? Dropping this "feature" should be safe since I don't know of any application that would use the parser hook AND not use the real() token at the same time. I'm sure there are some, but may I just not concern myself with those? Also, dropping the "feature" may increase speed since there is nothing else to handle. Also, the drop will free up some room so I can perform other types of upgrades, including an overhauled version of the hook's handler.

So, what do you think? Is it safe? Is it okay? Is it appropriate?

[TheStorm]

I'd leave it because their may be programs int he future that will want to chain with your app.

[pugboy]

Or someone might have xLib on there calculator, not knowing Celtic integrated it.

[vuurrobin]

but then celtic would just overwrite the xlib hook and parse the xlib commands itself, instead of letting xlib do that. the user wouldn't notise anything.

if it would improve speed, I would leave it out. I can't think of an app that would need to have a hook installed while playing a game (other than celtic).


and if futere apps need to chain hooks, then imo its there responcebillity for chaining the hooks, not yours.

[Art_of_camelot]

I'd say if it gives celtic more speed and gives you some more space to work with then drop em. It doesnt really seem that necessary.

[elfprince13]

allow the hook to be chained, just not with xLib. otherwise, using it will be a nuisance.

[TheStorm]

Many apps use the parser hook so I think it would be a good idea to keep it but you should definitely uninstall xlib's hook if you encounter it.

[magicdanw]

Why uninstall xLib's hook? There might eventually be an updated version of xLib with more features, and Celtic III should be compatible with it. Is there any downside to chaining with a current version of xLib? Wouldn't it just act as if xLib wasn't installed? It's the user's own fault if it's a tiny bit slower, because they didn't bother to read the Celtic III manual and see that it handles xLib commands.

[TheStorm]

true but either way you should allow for chaining.

[DJ Omnimaga]

Would all that chaining with other apps hook prevent the following from happening?

[vuurrobin]

awesome screenshot, dj omnimaga. I like :biggrin:

as for the grayscale to work with celtic, it would depend on how fast it would be (I think)


wouldn't it be possible to somehow backup the installed hooks at the start of an program and restore them at the end, so celtic can run at maximum speed during a program and the user wouldn't have to install the hooks itself after playing that game. maybe only put this in the install program and not in the app itself.

also, would the commands of celtic slow down if it checked for installed hooks, but didn't find anything?

[TheStorm]

It would still be a slight slowdown if there wasn't one because it has to check weather it needs to chain or not... though if he had the free space he could have two hooks one for chaining and one that didn't and have the user decide when the installed it. It wouldn't even have to be the whole hook just like a first section that handels chaining.

[DJ Omnimaga]

Thanks Vuurrobin

Would it be faster if all other apps hooks are uninstalled?

[Liazon]

i would say chaining, but idk much about hooks.

does tr1p1ea intend to update xlib any time soon?

[Iambian]

Just keep in mind that the chain itself requires time to run, which will produce a slowdown. If it's not Celtic III processing the information by itself, provided that the routines that it will chain with are just as fast, the material being chained will invariably be slower.

Hook information may also change as applications are changed or removed so that any hook that was previously on the calc would then become invalid. I don't expect this to happen, so it may be safe bet to rely on saving the hook information during an overwrite.

Also, since Celtic III uses the real() token, distinguishing whether or not you want to enable real() to be handled by either Celtic III or some other application would (using a safe method) require that the Celtic III appvar be looked up each time a hook is executed, resulting in ungodly-slow hook handling. That is something I want to avoid, so you'd have to personally rebuild Celtic III yourself if you were to exclude Celtic III's influence over the real() token in favor of a potentially better version of xLIB.

As an answer to a previous question, hook chaining only happens when there is an actual hook to chain. Otherwise, it will exit normally.