Since the color-screen TI-84 Plus C Silver Edition calculator was first discovered here at Cemetech eight and a half months ago, the programming community has had mixed reactions to the device. On the plus side, we're very happy that it represents an extension of the TI-83 Plus/TI-84 Plus-series calculator line, and hope it indicates TI's commitment to continuing the series for many years to come. In addition, its math features represent a significant improvement over the black-and-white calculators, especially for graphing and statistics, as I mentioned in my review of the calculator TI kindly sent to me. The programming community's one gripe has been that the calculator's processor and memory are nearly identical to the internals of the TI-84 Plus Silver Edition, save for doubled Flash ROM memory. Nevertheless, many of us are happy to face the programming challenges presented by the new device.

In that spirit, I'm proud to present the first hybrid TI-BASIC library for the TI-84 Plus C Silver Edition, Celtic 2 CSE. Based on Iambian Zenith's unreleased Celtic 2 code, it offers a host of program- and file-manipulation functions to TI-BASIC programmers, plus a powerful sprite routine. At the behest of tifreak8x, I re-created and re-fixed it from Iambian's latest (non-lost) source code, then added my own tweaks and features. It features the ability to read lines from programs and AppVars in RAM or Flash (archive), the ability to insert, delete, or overwrite lines in a specified program, to create a specified program and to find out how many lines there are in a BASIC program, and to output special characters into a string that is not normally storable into a string via any other method (doublequote and sto). It also contains a powerful, BASIC-compatible palletized sprite routine.

I encourage all of our TI-84+CSE-owning TI-BASIC coders to give this a try, and show off what you can do with it. I expect that a future TI-84+CSE shell (like some version of Doors CS) will contain libraries similar to these, so it makes sense to get used to them now. I also want to mention the huge debt of gratitude I owe to TIFreak8x for extensive testing as well as the thorough C2TEST program included in this file.

Download
Celtic 2 CSE

Woo! Glad I was able to offer some small amount of assistance in getting this project into a releasable form! Smile Hope other people are able to put it to good use in the future!
Excellent news; I greatly enjoy using Celtic! I mildly wonder, though, where Celtic III went? it was in DCS7...
It's still in DCS7? To my knowledge, nothing major like a library removal happened in the latest DCS..
CalebHansberry wrote:
Excellent news; I greatly enjoy using Celtic! I mildly wonder, though, where Celtic III went? it was in DCS7...
I suspect you're asking why, if Doors CS 7 had Celtic III, I reverted to the numerically-inferior Celtic 2 for this TI-84+CSE library. The answer is that Celtic III is a massive, 12KB-ish set of very powerful routines, but far, far too big for a standalone, non-app library. Celtic 2 was around 1KB, and with all of my fixes and additions, this version grew to the neighborhood of 1.5KB. It has many fewer functions than Celtic III, but it provides at least a nice cross-section of functionality. Plus it's a nice base to build future TI-84+CSE shells/libraries on.
Ah, okay. "numerically inferior" - excellently put. Smile
This is very cool. By the way is it possible to draw sprites outside the graph screen boundaries or are we limited to the 265x165 area?
DJ_O wrote:
This is very cool. By the way is it possible to draw sprites outside the graph screen boundaries or are we limited to the 265x165 area?
Technically you're limited to the 265x165 area, because this is designed to be compatible with Picture variables, normal drawing, and so on. It writes to both the LCD and the graph buffer, in fact. Technically you could give it negative or >264/>164 coordinates, and it would happily draw the pixels on the screen, but at the next redraw or Pause, things would suddenly turn wonky.
Ah I see now. Actually I tried drawing at a coordinate that is out of bounds and it drew over the gray border, but unless I did something wrong I couldn't seem to draw to the top or left of the screen using negative numbers. I guess I'll have to experiment more.

EDIT: It appears that drawing too far to the right will draw on the left side of the screen instead, which, I guess, could be used as a workaround, since negative values appears to act like positive or something.

lol I hadn't even thought about doing that. Looks like you had a bit of fun with things, though Smile
Thanks for investigating that, DJ_O. I suspect if you use 65535-(some small number) for x, you can go beyond the left edge in a more controlled manner, and 256-(some small number) for going above the top edge, thanks to the magic of wraparound. Then again, you might just crash your calculator. Wink
Drawing on the border does some cool stuff:

That's using the restoring feature of the sprite function. The bottom-leftish is where I accidentally had some sprites for Minesweeper drawing. The right is, I assume, just garbage memory making pretty colors.
I have improved the graphics of my Pegs game clone using Celtic 2 CSE and TokenIDE Hex sprite editor.

Before

After
Very nice!

How much of a speed increase did you get out of using Celtic? Did you find it easy to use?
Two features I'd love to see for the sprite drawing:
1: xor mode
2: Have a switch to not store the previous screen contents back to Str9.
tifreak8x wrote:
Very nice!

How much of a speed increase did you get out of using Celtic? Did you find it easy to use?


Drawing the map of first level took 12.4 seconds in the basic version. 17.4 seconds in the hybrid version.

The only feature I understand from Celtic is the drawing sprite routine.
merthsoft wrote:
Two features I'd love to see for the sprite drawing:
1: xor mode
I thought about that, but I can't figure out what it means to xor colors. That's why it gives you Str9 back, to make erasing to the previous contents easier. It also supports two types of transparency, by the way (0, which leaves the contents of that pixel intact, and H, which replaces that pixel with transparency).
Quote:
2: Have a switch to not store the previous screen contents back to Str9.
That's certainly something to consider. In what instances would that be valuable?
For example, in my minesweeper game, at the end, I'm drawing the mines where they are (or smileys if you win). It's always going to be the same sprite drawn there, so I don't want to restore Str9 each time. Anytime you want to draw the same sprite more than once in a row this would be useful.
I see, that makes sense. In that case, that's definitely something I'll try to add to the next version, although perhaps that next version will be in the form of some sort of shell with Hybrid support rather than another standalone ASM program version.
Additional feature: it would be cool to pass in a line number and an appvar and have it draw the sprite straight from there without having to store into str9. That might mitigate some of the overhead, I imagine.
  
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
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement