| Author |
Message |
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
 Posted: 17 Dec 2009 08:59:43 pm Post subject: |
|
|
That would be awesome! 
I'd like nice linking routiens. |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 21 Jan 2010 01:55:25 pm Post subject: |
|
|
Here is the proper post...
When I was solely a BASIC programmer, I made extensive use Celtic3, Omnicalc, and xLIB. One feature that I like about Celtic3 is the identity(5 command. The trouble was in two things:
1) it took a little while to make the hex strings
2) Tokenized strings weren't handled well
Now that I am starting to get a grasp of assembly, I solved this with a few small and simple codes. GetSprite8x8 will return a
tokenized string representing the sprite data and TokenSprite is like identity(5, except it uses tokenized strings. These are included in my program QSprite (which can be found on TICalc.org). The GetSprite8x8.txt uses two other calls I made, but I have an idea you have some better calls. I only put them in so that you can see how it works. It is the last one you should be interested in.
(I used Courier New and font size 11)
By the way, Celtic3 really helped me understand how to manipulate data ☺.
Last edited by Guest on 21 Jan 2010 01:57:10 pm; edited 1 time in total |
|
| Back to top |
|
|
ZagorNBK
Newbie
Joined: 29 May 2008
Posts: 36
|
| Posted: 24 Jan 2010 09:36:37 am Post subject: |
|
|
| Dunno if somebody already proposed this, but I think I have a way of having full xLIB compatibility: instead of putting all of those functions in Celtic III, why not just have Celtic III chain xLIB's keyhooks? I think this should be pretty easy to do... |
|
| Back to top |
|
|
simplethinker
snjwffl
Active Member
Joined: 25 Jul 2006
Posts: 700
|
| Posted: 24 Jan 2010 11:06:56 am Post subject: |
|
|
ZagorNBK wrote: Dunno if somebody already proposed this, but I think I have a way of having full xLIB compatibility: instead of putting all of those functions in Celtic III, why not just have Celtic III chain xLIB's keyhooks? I think this should be pretty easy to do...
If I remember correctly, Iambian did try chaining hooks with both xLIB and Omnicalc, but there was a slow-down in acknowledging the hooks (I don't know if I phrased that right). Plus, Iambian's implementations of xLIB functions are much faster than the originals. |
|
| Back to top |
|
|
Galandros
Active Member
Joined: 29 Aug 2008
Posts: 565
|
| Posted: 24 Jan 2010 05:27:44 pm Post subject: |
|
|
simplethinker wrote: ZagorNBK wrote: Dunno if somebody already proposed this, but I think I have a way of having full xLIB compatibility: instead of putting all of those functions in Celtic III, why not just have Celtic III chain xLIB's keyhooks? I think this should be pretty easy to do...
If I remember correctly, Iambian did try chaining hooks with both xLIB and Omnicalc, but there was a slow-down in acknowledging the hooks (I don't know if I phrased that right). Plus, Iambian's implementations of xLIB functions are much faster than the originals.
Why TI-OS hooks are so slow? Every APPS I know with hooks slows down a bit but humanly noticeable TI-BASIC executing... |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 24 Jan 2010 06:15:49 pm Post subject: |
|
|
| Is it possible to have a swap function where the Graph Screen Buffer would be swapped out with whatever is currently on the screen? |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 25 Jan 2010 12:16:06 am Post subject: |
|
|
simplethinker wrote: ZagorNBK wrote: Dunno if somebody already proposed this, but I think I have a way of having full xLIB compatibility: instead of putting all of those functions in Celtic III, why not just have Celtic III chain xLIB's keyhooks? I think this should be pretty easy to do...
If I remember correctly, Iambian did try chaining hooks with both xLIB and Omnicalc, but there was a slow-down in acknowledging the hooks (I don't know if I phrased that right). Plus, Iambian's implementations of xLIB functions are much faster than the originals.
I did. The problem was acknowledging the hooks in such a way that Celtic III can pass its hook to another app (like xLIB). The noticeable slowdown occurred each time Celtic III's hook is called and needed to check whether or not it was something that xLIB could handle. Each time the hook went through, it needed to perform this check and if it was right, it would spend some time trying to route the execution to xLIB through some memory juggling. It wasn't pretty and the result was a slowdown that was great enough for people to notice (and complain about). That, and there was complaints about having two apps on the calculator do the job that only one app should.
Somewhere in the old threads, there should be some information on when I dropped hook support. The version prior to that, you can try it out for yourself. They should still be there after all this time.
ztrumpet wrote: Is it possible to have a swap function where the Graph Screen Buffer would be swapped out with whatever is currently on the screen?
Wouldn't make much sense. Nearly all of Celtic III's graphical functions trash the previous contents of the buffer and update the screen with what's on it. Sure, something like that could be easily programmed (a few romcalls away), but again, it wouldn't make much sense. If you could clarify under what conditions something like that would be useful, let me know.
And no, I'm never going to rewrite any of Celtic III's graphical functions to touch only the screen and not the buffer. Way too complicated. Not much benefit (would be far slower). Not enough space in the app (there's about 1KB left). Using another buffer would be out of the question, as some of Celtic III's graphical functions go as far as to use the other buffer for backup while performing what it needs to do on the current buffer. Some of them had to be rewritten so it would only use two buffers instead of its original triple-buffer design.
------------
On another note, I'm thinking of writing a test suite so all of Celtic III's functions can be verified each time I rebuild the app so I know I haven't broken anything. The fact that real(14) was broken for all this time (and no one seemed to have reported it) is partially a testament to that. Why now? It's about high time something ought to be done to verify that the app is being "correctly" written and changed. Perhaps this might encourage others to edit Celtic III for their own purposes if they can verify their change against the "standard," whatever that might be.
Last edited by Guest on 25 Jan 2010 12:17:01 am; edited 1 time in total |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 25 Jan 2010 03:57:10 pm Post subject: |
|
|
Iambian wrote: And no, I'm never going to rewrite any of Celtic III's graphical functions to touch only the screen and not the buffer. Way too complicated. Not much benefit (would be far slower). Not enough space in the app (there's about 1KB left). Using another buffer would be out of the question, as some of Celtic III's graphical functions go as far as to use the other buffer for backup while performing what it needs to do on the current buffer. Some of them had to be rewritten so it would only use two buffers instead of its original triple-buffer design. This single paragraph pretty much renders what I was thinking as useless. I was thinking that swaping screens might be useful for games that use two compleatly different screens, but I had forgotten about how slow the LCD screen is. Thanks! |
|
| Back to top |
|
|
AMkiller
Advanced Newbie
Joined: 16 Dec 2008
Posts: 64
|
| Posted: 29 Jan 2010 04:26:07 pm Post subject: |
|
|
| I would love to see some linking functions in celtic III (like somebody else also mentioned) |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 03 Feb 2010 07:43:35 am Post subject: |
|
|
Here is an idea for the graph screen/home screen thing:
Graph→Screen
This neat routine will put the graph screen image on the
current screen.
214093063EEF7048
Screen→Graph
This will put the current screen image on the graph screen.
214093EF7B4C
The current screen is what ever is currently on the display. Sorry, I don't have the mneumonics right here. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 03 Feb 2010 11:45:31 am Post subject: |
|
|
ThunderBolt wrote: Here is an idea for the graph screen/home screen thing:
Graph→Screen
This neat routine will put the graph screen image on the
current screen.
214093063EEF7048
Screen→Graph
This will put the current screen image on the graph screen.
214093EF7B4C
The current screen is what ever is currently on the display. Sorry, I don't have the mneumonics right here.
The first routine already exists. It's called FastCopy. Use either det(19) or real(6) to access it.
The second one might actually be useful if you're doing homescreen stuffs. Thanks for the update.
And you guys will never be satisfied until some sort of linking functionality is enabled in Celtic III, eh? |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
|
| Back to top |
|
|
AMkiller
Advanced Newbie
Joined: 16 Dec 2008
Posts: 64
|
| Posted: 04 Feb 2010 06:32:19 am Post subject: |
|
|
Iambian wrote: ThunderBolt wrote: Here is an idea for the graph screen/home screen thing:
Graph→Screen
This neat routine will put the graph screen image on the
current screen.
214093063EEF7048
Screen→Graph
This will put the current screen image on the graph screen.
214093EF7B4C
The current screen is what ever is currently on the display. Sorry, I don't have the mneumonics right here.
The first routine already exists. It's called FastCopy. Use either det(19) or real(6) to access it.
The second one might actually be useful if you're doing homescreen stuffs. Thanks for the update.
And you guys will never be satisfied until some sort of linking functionality is enabled in Celtic III, eh?
indeed, linking is what we need |
|
| Back to top |
|
|
ZagorNBK
Newbie
Joined: 29 May 2008
Posts: 36
|
| Posted: 04 Feb 2010 08:03:47 am Post subject: |
|
|
| And repair the real(12 while you're at it. |
|
| Back to top |
|
|
Xeda112358
Active Member
Joined: 19 May 2009
Posts: 520
|
| Posted: 05 Feb 2010 07:35:52 am Post subject: |
|
|
ztrumpet wrote:
Wow, yeah I'm okay with that. TIBasicDev was my go to site when I had any BASIC programming questions and that was where I started to play with assembly. Thanks, I feel honored. And the maker of Celtic3... Wow. |
|
| Back to top |
|
|
ztrumpet
Active Member
Joined: 06 May 2009
Posts: 555
|
| Posted: 05 Feb 2010 05:00:48 pm Post subject: |
|
|
ThunderBolt wrote: ztrumpet wrote:
Wow, yeah I'm okay with that. TIBasicDev was my go to site when I had any BASIC programming questions and that was where I started to play with assembly. Thanks, I feel honored. And the maker of Celtic3... Wow.
You're welcome, and if you want once you get an account at TIBD, you can edit pages. I'm pretty sure Iambian and I feel pretty honored now to. |
|
| Back to top |
|
|
justm3
Newbie
Joined: 17 Feb 2010
Posts: 5
|
| Posted: 17 Feb 2010 06:39:34 pm Post subject: |
|
|
I have a feature that I think will be a great addition to Celtic III: Making it so that you can go to a label based off of an input. Let me be more specific.
I am working on a program that is a notepad-type program that takes place on the graph screen, for a bigger size. One problem is that I have at least 30-50 If statements that check to see what key was pressed, and then goes to the corresponding label. This slows it down a lot. If there was a way to say something like, I dunno, GoTo det(40, for example, that would jump to a label that is the input or GetKey value, that would be awesome. It would also make the program a lot smaller. Get what I'm saying? I don't know if it is possible to do, cause I don't do assembly, but, in my opinion, that would be probably one of the most, if not the most, useful things that Celtic III could do. Personally, I wouldn't care if it took up another flash page or whatever it is called. Thanks.
justm3 |
|
| Back to top |
|
|
Graphmastur
Advanced Member
Joined: 25 Mar 2009
Posts: 360
|
| Posted: 17 Feb 2010 06:47:14 pm Post subject: |
|
|
justm3 wrote: I have a feature that I think will be a great addition to Celtic III: Making it so that you can go to a label based off of an input. Let me be more specific.
I am working on a program that is a notepad-type program that takes place on the graph screen, for a bigger size. One problem is that I have at least 30-50 If statements that check to see what key was pressed, and then goes to the corresponding label. This slows it down a lot. If there was a way to say something like, I dunno, GoTo det(40, for example, that would jump to a label that is the input or GetKey value, that would be awesome. It would also make the program a lot smaller. Get what I'm saying? I don't know if it is possible to do, cause I don't do assembly, but, in my opinion, that would be probably one of the most, if not the most, useful things that Celtic III could do. Personally, I wouldn't care if it took up another flash page or whatever it is called. Thanks.
justm3
Well, yes, but there are easier ways. Look at piecewise expressions, strings, and the sub( command. |
|
| Back to top |
|
|
Iambian
Advanced Member
Joined: 13 Mar 2004
Posts: 423
|
| Posted: 17 Feb 2010 08:01:05 pm Post subject: |
|
|
justm3 wrote: I have a feature that I think will be a great addition to Celtic III: Making it so that you can go to a label based off of an input. Let me be more specific.
I am working on a program that is a notepad-type program that takes place on the graph screen, for a bigger size. One problem is that I have at least 30-50 If statements that check to see what key was pressed, and then goes to the corresponding label. This slows it down a lot. If there was a way to say something like, I dunno, GoTo det(40, for example, that would jump to a label that is the input or GetKey value, that would be awesome. It would also make the program a lot smaller. Get what I'm saying? I don't know if it is possible to do, cause I don't do assembly, but, in my opinion, that would be probably one of the most, if not the most, useful things that Celtic III could do. Personally, I wouldn't care if it took up another flash page or whatever it is called. Thanks.
justm3
Doing something like that would mean messing around with the operator stack, and I don't know a whole lot about that tidy little structure that the TI-OS likes to keep while running BASIC programs. If there was a good resource to look at, please. Point me in that direction! Especially what the operator stack looks like while running a parser hook. |
|
| Back to top |
|
|
justm3
Newbie
Joined: 17 Feb 2010
Posts: 5
|
| Posted: 17 Feb 2010 09:35:14 pm Post subject: |
|
|
Graphmastur wrote: justm3 wrote: I have a feature that I think will be a great addition to Celtic III: Making it so that you can go to a label based off of an input. Let me be more specific.
I am working on a program that is a notepad-type program that takes place on the graph screen, for a bigger size. One problem is that I have at least 30-50 If statements that check to see what key was pressed, and then goes to the corresponding label. This slows it down a lot. If there was a way to say something like, I dunno, GoTo det(40, for example, that would jump to a label that is the input or GetKey value, that would be awesome. It would also make the program a lot smaller. Get what I'm saying? I don't know if it is possible to do, cause I don't do assembly, but, in my opinion, that would be probably one of the most, if not the most, useful things that Celtic III could do. Personally, I wouldn't care if it took up another flash page or whatever it is called. Thanks.
justm3
Well, yes, but there are easier ways. Look at piecewise expressions, strings, and the sub( command.
But would this work by simply saying something like:
...
Getkey->K
(K=41)(str1+"A")...->str1? |
|
| Back to top |
|
|
|
Celtic III => Your Projects
