Current Progress

[simplethinker]

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

[DarkerLine]

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.

[vuurrobin]

[nitacku]

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.

[Demon]

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

[justusdude]

ANOVA anyone?

[Iambian]

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.

[DJ Omnimaga]

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

[Weregoose]

[Iambian]

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.

[vuurrobin]

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

[Iambian]

[Areign]

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

[Iambian]

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.

[Iambian]

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.

[magicdanw]

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.

[Iambian]

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

[Demon]

[vuurrobin]

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.

[Iambian]

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.