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
United-TI Archives -> Celtic III
 
    » Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Author Message
simplethinker
snjwffl


Active Member


Joined: 25 Jul 2006
Posts: 700

Posted: 07 Oct 2007 04:45:22 pm    Post subject:

I can't remember which topic (or utility) it was for, but a while back someone (for some reason Weregoose is in my mind) suggested using the superscript 'T'. If it was preceded by something then it would be passed to the OS, but if not then the utility would pick it up. I'm not sure why that wouldn't work.

[edit] In response to vurrobin's 2 posts down (not worth a new post): Thanks, I tried searching for CelticII, CelticIII, Xlib, Omnicalc and Calcsys, but forgot Codex2


Last edited by Guest on 07 Oct 2007 07:04:38 pm; edited 1 time in total
Back to top
DarkerLine
ceci n'est pas une |


Super Elite (Last Title)


Joined: 04 Nov 2003
Posts: 8328

Posted: 07 Oct 2007 04:50:59 pm    Post subject:

I think det( is neater. And T is used more often, even in non-mathematical programs, so it would be more confusing.

det( is unambigous enough, since it takes a matrix argument in its normal use.


Last edited by Guest on 23 Sep 2010 11:35:22 pm; edited 1 time in total
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 07 Oct 2007 06:34:55 pm    Post subject:

simplethinker wrote:
I can't remember which topic (or utility) it was for, but a while back someone (for some reason Weregoose is in my mind) suggested using the superscript 'T'.  If it was preceded by something then it would be passed to the OS, but if not then the utility would pick it up.  I'm not sure why that wouldn't work.
[post="114032"]<{POST_SNAPBACK}>[/post]



it was weregoose in the codex 2 forum.

http://www.unitedti.org/index.php?showtopi...indpost&p=64180
Back to top
nitacku


Advanced Member


Joined: 23 Aug 2005
Posts: 408

Posted: 07 Oct 2007 08:19:35 pm    Post subject:

Would it be possible to combine xLIB with Celtic?
I want to use Celtic with future programs, however, I am concerned that many people will find having to install 2 apps (xLIB + Celtic) sort of memory consuming.

Also, could you add the ability to archive pictures based on their number?
Currently the only way to do this in Basic is to use XtraVar to get the hacked token and use Archive /token/
It would be awesome if something like det(archive, pic#) could be added.
Back to top
Demon


Advanced Member


Joined: 17 Jun 2006
Posts: 369

Posted: 07 Oct 2007 08:28:01 pm    Post subject:

I second that idea. Someone should run over to MaxCoderz and add that on Tr1p1ea's idea list.
Back to top
justusdude


Advanced Member


Joined: 24 May 2006
Posts: 265

Posted: 07 Oct 2007 09:12:56 pm    Post subject:

ANOVA anyone?
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 08 Oct 2007 05:44:02 pm    Post subject:

Sorry, but no screenies right now, but...
I have so far the application built so that it would at least assemble. The app now displays a splash screen that's essentially ASCII art, just to show off this stupid little aligned text drawing routine I wrote a while back that would make the thing look all console-ish.

I'll start working on the hooks, and then I'll start working on getting the actual commands up and running. But before I really start with anything regarding the commands, I'm going to make sure that any other application that had hooks in the system gets preserved and subsquently "chained" so that an application such as xLIB would continue to work under Celtic III.
Back to top
DJ Omnimaga
http://i-lost-the-ga.me


Calc Guru


Joined: 14 Nov 2003
Posts: 1196

Posted: 08 Oct 2007 05:51:42 pm    Post subject:

I,m glad somehow this turned into an app, because while in app form I will never use it inside a game since I use xLIB I had another neat project idea for celtic app use Very Happy
Back to top
Weregoose
Authentic INTJ


Super Elite (Last Title)


Joined: 25 Nov 2004
Posts: 3976

Posted: 08 Oct 2007 06:15:00 pm    Post subject:

justusdude wrote:
ANOVA anyone?
ANOVA( is a two-byte token.

Last edited by Guest on 23 Sep 2010 11:35:06 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 09 Oct 2007 11:22:57 am    Post subject:

I figured that I'd have to process two-byte tokens anyway, since other apps that use these hooks would possibly use them, too. I'm going to explore the possibility of using det( in the hook, along with imag( and possibly ANOVA(, but I'm likely going to stick with det(. The reason why I'm going to process these two byte tokens is because sub( and inString( are both two-byte tokens, and I plan to do something with them.

As far as the development on the APP version of Celtic III goes, I managed to get the hooks to chain, so you'd be able to use whatever hook was previously installed on the calculator alongside this APP. The only stipulation is that Celtic III must be the last thing to be installed, since other apps may not care what else was installed there. Because of the nature of this chaining, the hooks that are "behind" Celtic III will operate a little slower than without chaining. I do not know how much of a slowdown this will introduce, but I think it would be minimal. In time-critical environments, such as the way some games will use xLIB, I think the slowdown might become noticable. Still, I haven't tested this.

But for now, there's actually an interface with Celtic III that will allow you to install and uninstall Celtic III. If there were any hooks that Celtic III chained with, it will try to restore the previous hook, though I cannot guarantee the integrity of that hook, especially if apps have been deleted between the time Celtic III was installed and then uninstalled.

Right now, my next job would be to write the part of the parser hook that accepts the commands that will then be passed to Celtic III to work on. I'll then have something that is functionally equivalent to the ram-based version of Celtic III.

EDIT: Somehow, I broke the VAT searching routine, so I'll need to fix that somehow. During speed testing, I found somewhat disturbing results, so I got to thinking while I was at my job. I *could* rearrange the VAT so that my appvar appears at the top, and then just *assume* that it'll remain there, seeing as things are only appended to the thing, and the appvar isn't designed to stay in the event of a system crash. *sigh*... more work to make it speedier.

btw, the speed tests were based on a BASIC program counter on my calc versus a counter in the emulator. The control was with no hooks installed. The first test was with xLIB installed, using real(14, and the second test was Celtic III's hooks with xLIB chained to it. According to the results I got, it turns out Celtic III spends more time locating xLIB's hook than it takes xLIB to perform the function intended for it. I've forgotten what the exact results were, but they were pretty big.

EDIT2: I've "fixed" the bug, though I don't really know what's been causing it. I decided to ditch the lookup thing and just put the hook in a location in RAM that's not likely to be touched. Of course, the appvar will still be there for semi-permanent storage. The hook's designed to refresh the location of the chained hook every so often, so as to help prevent damage from other apps. For the curious, the location I picked was $FFFD.


Last edited by Guest on 09 Oct 2007 11:49:07 pm; edited 1 time in total
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 09 Oct 2007 04:40:25 pm    Post subject:

I'm not sure if I like celtic as an app, but if you also keep working on the ram based program, I'm fine with it.

good luck with it Smile
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 10 Oct 2007 04:36:42 pm    Post subject:

vuurrobin wrote:
I'm not sure if I like celtic as an app, but if you also keep working on the ram based program, I'm fine with it.

good luck with it Smile
[post="114157"]<{POST_SNAPBACK}>[/post]

All I'm really trying to do is get the APP version of Celtic III on-par with what the RAM based version currently is. So far, the APP can't do anything with regards to what the RAM version can do. Right now, I'm just trying to hammer out how I can make the crossover. The hooks seemed like the right place to start. Then I'll start working on compatibility.

But to ease woes, any new feature I come out with (i.e. The list to string converter) will be added to both versions and tested as both to ensure that they work properly. There might be a delay, but it'll be done.

EDIT: I just found out that the hook chaining will not work with CalcUtil, since it seems to use the same memory area that my app uses. I was wondering if the next available slot, $FFFA, is up for grabs?
EDIT2: *sigh*. There's no playing nice with these hooks, is there? In order to install Celtic III on a system with CalcUtil already installed, you'll need to "overwrite" the current hooks. And by "overwrite", I wrote code that would disable all the hooks contained in the IY offsets +34h, +35h, and +36h. The problem doesn't seem to happen anymore. Any suggestions on how to work around this "problem" should go to the feature request section.

EDIT3: (edit4: code removed since it doesn't seem to work)


Last edited by Guest on 22 Oct 2007 09:00:22 pm; edited 1 time in total
Back to top
Areign


Newbie


Joined: 27 Jan 2007
Posts: 31

Posted: 11 Oct 2007 04:06:06 pm    Post subject:

it seems like the guy who made calc util did it so that it would chain with other stuff?

" and it chains with Omnicalc and probably any other app using parser, rawkey, or app change hooks."

is this accurate? maybe you dont have to do anything but install calcutil over celtic3
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 15 Oct 2007 12:20:37 pm    Post subject:

See previous post for edit.

The problem seems to have been worked out. All I needed to do was store my hook at the temporary location $FFFA so it wouldn't overwrite CalcUtil's hook. After that, CalcUtil will appropriately chain with Celtic III, but now I've been looking into speed issues with regards to having up to three apps in a chain (i.e. xLIB -> Celtic III -> CalcUtil). When I get the time, I'll be viewing the source code for CalcUtil and determine if I can make a few optimizations to it. If anyone can use it, this piece of code will work quickly to locate an appvar. All one needs to do is change the compares for matching the name of the appvar with yours.

Code:
findappvar:  ;routine used to quickly find the Celtic III appvar (illegally named)
 ld hl,(progptr)
 ld de,(ptemp)
 ld bc,-6
findappvarloop:
 bit 4,(hl)  ;if not zero, is either appvar or group. Unsafe, but fast.
 add hl,bc  ;does not affect zero flag.
 ld c,(hl)  ;gets size info in C
 dec hl      ;move to next byte. In name.
 jr z,findappvarEL;if bit 4,(hl). is 1, is a group or appvar.
 bit 3,c        ;if bit 3,c is zero, then the name isn't 8 letters long.
 jr z,findappvarEL
 ld a,(hl)      ;...
 dec hl
 dec c
 cp $23
 jr nz,findappvarEL
 ld a,(hl)
 cp $16
 jr z,findappvargood
findappvarEL:
 ld a,c
 neg
 ld c,a
 add hl,bc
 ld c,-6
 or a
 sbc hl,de
 add hl,de
 jp nz,findappvarloop
 scf
 ret
findappvargood:
 inc hl
 inc hl
 inc hl
 ld a,(hl)
 or a
 jr z,$+11
 ld hl,cAVAR
 rst 20h
 bcall(_Arc_Unarc)
 jr findappvar
 inc hl
 ld a,(hl)
 inc hl
 ld l,(hl)
 ld h,a
 inc hl
 inc hl
 ret

This makes a LOT of assumptions. One such assumption is that the appvar is 8 characters long, even though this routine does not check for all eight characters. It actually checks for the first two characters, which are ones that a person would not be likley to use in an appvar name. This routine would function fairly slower if there happened to be lots of groups on the calc with 8 letters for each name, but I still contend that it's faster than the romcall ChkFindSym.

EDIT: Another note is that the label "cAVAR" contains the name of the appvar that I'm using, complete with its starting "AppVarObj"

EDIT2: I just figured out that the arguments are placed onto the FPS *backwards*, with the LAST argument appearing in Op1. This really puts a kink in things, though it should be solved relatively easy.

EDIT3: Okay. I figured that none of the aforementioned code would work in the previous post, since I failed to figure out exactly how the arguments are being loaded to the FPS and what is being loaded to OP1. I'll be writing code to figure that out, or if someone were to be nice enough, post that information here.

EDIT4: Just got the hook system to work right. Now I can really focus on converting the input/output to conform to this new system.

EDIT5: Fixed archive reading bug, now working on converting the other commands. It won't be long.


Last edited by Guest on 22 Oct 2007 09:01:33 pm; edited 1 time in total
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 28 Oct 2007 10:51:36 pm    Post subject:

This right here is the current build for the APP version. Please let me know if there are any noticeable problems.

One known problem in this build is that it won't catch attempts to use a function number greater than its current list, resulting in a crash. That's already been addressed with the build I'm working on. I won't release that because I'm in the middle of putting in one of my older projects into this (PicArc), and I don't want to release that until I have something testable for that.

On another note, there was a consensus on IRC regarding how those added functions will be accessed. The consensus was to put PicArc-related functions into another token. This time around, it's "identity(". Keep in mind that all the functions are usable for their intended purposes, and Celtic III will only work on those functions if used in a fashion outside of its normal use.

The good thing about the "det(" and the "identity(" commands is that they're both one byte tokens and they're both unary, so checking for non-normal use is relatively easy. Also, as a response from the Feature Requests thread, the "det(" command when checking to determine whether or not Celtic III is installed will act only on a 1x1 matrix, since I can't possibly see anybody needing to get the determinant of such a matrix. Correct me if I'm wrong.

------------
On a side note, ignore the batch file. It'll do you no real good unless your development environment happens to be set up in exactly the same way as mine.
------------
(EDIT) : Attachment removed in favor of most recent update.


Last edited by Guest on 31 Oct 2007 11:02:00 pm; edited 1 time in total
Back to top
magicdanw
pcGuru()


Calc Guru


Joined: 14 Feb 2007
Posts: 1110

Posted: 28 Oct 2007 11:19:22 pm    Post subject:

I took a peek at the source code. Looks nice. But you don't crash the calculator for real, even when they ask you to? I think it should crash the calculator for real. Knowing there's a malicious program installed on your calculator keeps you on your toes. At least, that's how I justify the bugs I haven't been able to track down in CalcUtil. Very Happy
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 31 Oct 2007 07:11:23 pm    Post subject:

This is going to be one 'em intermediate releases. I'm still not done with the PicArc addon, but at least it has a few of its capabilities. It still doesn't support compression yet, since that is taking me a while to code (sadly), because the exact method I used in the ASM program is unsuitable for use in the APP version. The method of compression I'm using is a very simple one: RLE. If someone has any algorithms to share to help increase the number of compression routines I've got, I'd be happy to take 'em. Keep in mind that I need routines to compress AND decompress, so providing only a decompressor is no good.

If anyone wants to test out Celtic III, be sure to at least *try* to make it crash, and let me know how you did it.

Also, I'll be looking back at the feature request topic so I can see if I can find anything else I can group with the PicArc section of Celtic III.

The ReadMe has not been updated to include all the new error codes that could pop up, but I'm pretty sure you know an error when you see one. It's in the source code of "_utility.asm" right around the 720th line forward.
-----
And as a response, no. I don't crash the calculator even when the option is selected. Crashes only happen when something terrible goes wrong in the project. You know, the kind of stuff good testers tend to find Smile
-----
EDIT: I forgot to mention that a small ASM program is also attached to this project. Its purpose is to allow the BASIC program to autoinstall Celtic III in the event it is not installed upon execution. You should also be able to use the OpenLib( and ExecLib commands to install Celtic III as well, but that method has not been tested, as I don't have anything that'll emulate a TI-84+, and I can't transfer that app to my calculator due to the link software/USB drivers not working right with Windows ME.

EDIT2: While looking back at the posts, I figured I could add in a small routine that'll allow image files to be swapped in and out of RAM based on their number, 0 thru 255. Implementation would be simple enough.


Last edited by Guest on 31 Oct 2007 11:04:12 pm; edited 1 time in total
Back to top
Demon


Advanced Member


Joined: 17 Jun 2006
Posts: 369

Posted: 01 Nov 2007 11:26:50 am    Post subject:

nitacku wrote:
Would it be possible to combine xLIB with Celtic?
I want to use Celtic with future programs, however, I am concerned that many people will find having to install 2 apps (xLIB + Celtic) sort of memory consuming.

Also, could you add the ability to archive pictures based on their number?
Currently the only way to do this in Basic is to use XtraVar to get the hacked token and use Archive /token/
It would be awesome if something like det(archive, pic#) could be added.
[post="114044"]<{POST_SNAPBACK}>[/post]


I second this idea. xLIB and Celtic as apps would be quite large (especially for the poor 83+ users like me Razz) and even if Celtic stayed... well not an app you'd still need xLIB to copy it to RAM if you write programs in which all the program's subroutines stay archived and get copied.


Last edited by Guest on 01 Nov 2007 11:27:44 am; edited 1 time in total
Back to top
vuurrobin


Advanced Member


Joined: 09 Aug 2006
Posts: 428

Posted: 01 Nov 2007 06:35:19 pm    Post subject:

yes, it would be awesome if xlib and celtic would be combined to make 1 superapp for basic programmers.


I'll test it when I have time, but I am currenty a bit short of :blush: , and I am still looking for those cursortokens.
Back to top
Iambian


Advanced Member


Joined: 13 Mar 2004
Posts: 423

Posted: 19 Nov 2007 02:00:03 pm    Post subject:

Just to let you know, I'm still working on the project, even though progress has slowed down a bit. I wrote a bunch of features, none of which has been actually tested out yet. Before the next release, I'm going to fix the compression for image database storage, and ensure that all the features are working. Along with the planned features is going to be a string tilemapper with your tiles being defined in a/some Pic file(s).

Also, a bugfix with the GETARGTYPE command was fixed where the output would be zero no matter what you passed through. It was an ugly fix, but at least it works.

With this upcoming release, you'll be able to retrieve Pic images from groups, and I'll probably set the inputs so that 1=Pic1 and Pic0=10 (it currently is Pic1=0 and Pic0=9). Since the tilemapper requires that the string is in binary format, I added Celtic III functions that lets you convert hex strings to binary and back.

Perhaps I would also tack in the list to string thing, but that's questionable, especially until I can find a better method of converting the list elements to string. If I find that better method, though, then I'll likely be able to write a small amount of additional code to handle matrices as well, but we'll have to see about that.

In short, I'm still working on it.
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
    » Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 2 of 6 » All times are GMT - 5 Hours

 

Advertisement