Login [Register]
Don't have an account? Register now to chat, post, use our tools, and much more.
This is an archived, read-only copy of the United-TI subforum , including posts and topic from May 2003 to April 2012. If you would like to discuss any of the topics in this forum, you can visit Cemetech's Your Projects subforum. Some of these topics may also be directly-linked to active Cemetech topics. If you are a Cemetech member with a linked United-TI account, you can link United-TI topics here with your current Cemetech topics.

This forum is locked: you cannot post, reply to, or edit topics. Celtic III => Your Projects
Author Message
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 23 Jan 2008 03:33:21 pm    Post subject:

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.
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 23 Jan 2008 06:40:13 pm    Post subject:

(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.


Last edited by Guest on 30 Aug 2010 08:13:11 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 02 Feb 2008 11:04:34 pm    Post subject:

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 ?
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 04 Feb 2008 06:02:30 pm    Post subject:

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


Last edited by Guest on 05 Mar 2008 05:13:57 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 18 Feb 2008 08:32:24 pm    Post subject:

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?
Back to top
TheStorm


Calc Guru


Joined: 17 Apr 2007
Posts: 1233

Posted: 18 Feb 2008 09:20:22 pm    Post subject:

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


Active Member


Joined: 11 Apr 2007
Posts: 544

Posted: 18 Feb 2008 09:47:29 pm    Post subject:

Or someone might have xLib on there calculator, not knowing Celtic integrated it.
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 19 Feb 2008 07:36:44 am    Post subject:

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.
Back to top
Art_of_camelot


Member


Joined: 05 Jan 2008
Posts: 152

Posted: 19 Feb 2008 01:43:54 pm    Post subject:

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.
Back to top
elfprince13
Retired


Super Elite (Last Title)


Joined: 11 Apr 2005
Posts: 3500

Posted: 19 Feb 2008 07:39:35 pm    Post subject:

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


Calc Guru


Joined: 17 Apr 2007
Posts: 1233

Posted: 19 Feb 2008 10:33:12 pm    Post subject:

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.
Back to top
magicdanw
pcGuru()


Calc Guru


Joined: 14 Feb 2007
Posts: 1110

Posted: 19 Feb 2008 10:41:33 pm    Post subject:

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.
Back to top
TheStorm


Calc Guru


Joined: 17 Apr 2007
Posts: 1233

Posted: 19 Feb 2008 10:52:45 pm    Post subject:

true but either way you should allow for chaining.
Back to top
DJ Omnimaga
http://i-lost-the-ga.me


Calc Guru


Joined: 14 Nov 2003
Posts: 1196

Posted: 20 Feb 2008 03:26:36 am    Post subject:

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



Last edited by Guest on 20 Feb 2008 03:27:30 am; edited 1 time in total
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 21 Feb 2008 04:27:26 pm    Post subject:

Neutral 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?
Back to top
TheStorm


Calc Guru


Joined: 17 Apr 2007
Posts: 1233

Posted: 21 Feb 2008 05:39:04 pm    Post subject:

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.
Back to top
DJ Omnimaga
http://i-lost-the-ga.me


Calc Guru


Joined: 14 Nov 2003
Posts: 1196

Posted: 21 Feb 2008 06:25:20 pm    Post subject:

Thanks Vuurrobin

Would it be faster if all other apps hooks are uninstalled?
Back to top
Liazon
title goes here


Bandwidth Hog


Joined: 01 Nov 2005
Posts: 2007

Posted: 21 Feb 2008 07:25:01 pm    Post subject:

i would say chaining, but idk much about hooks.

does tr1p1ea intend to update xlib any time soon?
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 21 Feb 2008 08:48:57 pm    Post subject:

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.
Back to top
Display posts from previous:   
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
    »
» View previous topic :: View next topic  
Page 1 of 1 » All times are GMT - 5 Hours

 

Advertisement