Hi i'm developping an TI variables library for java. Currently i'm able to edit and save monochrome 8xi files, Strings and Programs. Now i'm trying to develop an editor for 8ci images.
Can somebody point out how the colordata is stored?
Thanks in advance

Hey biohax, here's the format for Image and Picture files for the TI-84 Plus C Silver Edition, provided by Kerm!

- As you'd expect, the files follow the standard header format, more or less, with a few notable exceptions.
- Picture files have these header bytes in the variable header (ie, the header that starts at offset 0x55):
-- 0x04 (variable type ID) = 0x07 (tPictObj)
-- 0x05 (variable name) = 0x60 (tVarPict), 0x01 (Pic2) (or whatever)
-- 0x0D (version) = 0x0A (TI-84+CSE)
-- 0x0E (flag) = 0x80 (archived)
- Image files have these header bytes in the variable header (ie, the header that starts at offset 0x55):
-- 0x04 (variable type ID) = 0x1A (tImgObj)
-- 0x05 (variable name) = 0x3C (tVarImg), 0x01 (Image2) (or whatever)
-- 0x0D (version) = 0x0A (TI-84+CSE)
-- 0x0E (flag) = 0x80 (archived)
- Picture file contents: 265 columns, 165 rows. The image data is (266/2)*165 bytes, so two pixels are packed into each byte, and each row has an extra 0 nibble at the end to pad it out to exactly 133 bytes. Pixels are stored in row-major order: left to right, then top to bottom. The nibble for each pixel is an indexed color: 0 = transparent, 1-15 = a color. The color table is as follows (please excuse the PHP formatting; these are (R,G,B) triples, starting with color 1):
-- array(array(0,0,31), array(31,0,0), array(0,0,0), array(31,0,31), array(0,39,0), array(31,35,4), array(22,8,0), array(0,0,15), array(0,36,31), array(31,63,0), array(31,63,31), array(28,56,2, array(24,48,24), array(17,34,17), array(10,21,10));
- Image file contents: 82 rows, 133 columns, so every pixel is expanded to be 2x2 LCD pixels. Each pixel stored takes two bytes, and is packed as a 5-6-5 R-G-B value. Although image files are stored in row-major order, they are stored bottom-to-top, like BMP images, so left-to-right and bottom-to-top. Inexplicably, each row is padded with two extra bytes, bringing it to 268 bytes wide. The total data in an Image is therefore 268*82 bytes.

Hope this helps! I'd be happy to answer any follow-up questions.

*bump* I was just curious how this library was coming along, biohax17, and if you had any additional questions that we might be able to answer. I presume you've been looking at the File Format and Link Protocol Guide as you go?

I've have seen this documents (too much :p) and they were a big help.
Due finals in june i won't be able to finish the library before summer.
Basically I'm remaking a crossplatform (even android) tilp in java from scratch. For now it only supports serial communication (only bluelink tested) to TI84+. In the future i will add TI84 CSE support and the direct-usb protocol. If someone is intrested i'm more than willing to share my sources.

You should absolutely post this up on GitHub or a similar public version control service (like Bitbucket) so other people can look and contribute. Keep up the great work!

I will do it tommorow and put the link here.

Could you give us a bit more insight into your motivations ?
(for me, "for learning purposes" is nearly always a valid answer)

You're obviously not the first person to think about making a brand-new linking software, and some people are worse positioned for doing such a task than you are (because they are less knowledgeable, use a programming language less suitable for the task, aren't doing the tasks in the right order, or whatever)
This post is aimed at a wider audience than yourself, and meant to be a friendly explanation - I stress that I wouldn't want to discourage you or other persons from learning and honing their programming skills - of the fact that it's not easy to reach the stage of usefulness for a linking software stack, for a variety of good reasons I'll outline below.

As you (but not necessarily others) know, the bulk of the work on a linking software does not lie within the UI and additional features (the visible shiny stuff), it lies in the base layer (the invisible stuff). Without a sane base layer that actually works well for most purposes relevant to end users, a pretty UI with special features and good platform integration is lipstick on a pig.
An example of what not to do, in my opinion, is PrimeComm. Its author spent quite a bit of time on great visible features, such as a PPL editor with syntax highlighting, which remains unmatched by official software to date. He did clearly bring something useful to the community, I'm not diminishing that. However, it's been a year since PrimeComm, unlike libhpcalcs, started failing to communicate with real Prime calculators for most purposes. And PrimeComm is written in a way that makes it both non-interoperable (technology choice) and non-portable (coding choice on top of the technology choice).


Let's go a bit more to the point.
libti*/gfm/tilp are far from being perfect: the todo/wish/bug list is lengthy, though myself, Benjamin Moody, Jonimus, other minor contributors are working on it. GTK+ is no longer the portable UI toolkit of choice, whereas it used to be the only sane solution, a decade ago.
However:
* reimplementing dozens of thousands of lines of code, in order to get to feature parity with libti*, is a huge amount of work, to begin with. The TILP saga started in 1999, and while I have no precise estimation of the amount of time spent on it by the maintainers and contributors, the most appropriate unit is clearly the man-year of full-time work. By now, over nearly six years, I've spent weeks on the code base, and Romain / Julien spent much more time than I did;
* the libti* family has adequate portability, given that can be compiled for all of the relevant OS: Windows, MacOS X, Linux - including Android, as shown by Graph89 for three years - and at least FreeBSD;
* nothing is more interoperable than C;
* AFAICT, using Java won't help you against the nightmare that modern Windows versions are for drivers: that is a platform limitation, not an application limitation;
* Java remains one of the most popular choices, but its popularity has waned somewhat. It's dead on the Web, and has competitors with strong characteristics of portability, stronger characteristics of performance, and usually a more native look&feel, for both desktop and mobile platforms, starting with C++/Qt;
* the license of the libti* family is not a problem in practice, all the more the libs are usually accessed through dynamic linking.

It's obviously possible to do something simpler than libti*/tilp, and therefore to spend less time on such a brand-new code base. However, some functionality - and therefore some incentive for users to use your work - will be missing, at least one among:
* file format support: libtifiles handles TI-Z80+TI-eZ80+TI-68k+TI-Nspire files;
* cable support: libticables supports all of them, and then we plan on adding network cables;
* calculator protocol family support: libticables supports DBUS+DUSB+NSP;
* calculator support (commands and sequences thereof): all calculators are supported by libti*/TILP;
* calculator operations: besides exceedingly rare and undocumented stuff such as DBUS TestGuard packets, which can be made on top of libticalcs anyway because the dbus_send family has been exported for a long time, the full range is built into libticalcs+tilp.

Nowadays, what matters most is:
* 83+/84+ family (including the 84+CSE), 83PCE/84+CE, 89T, Nspire support;
* SilverLink + direct USB support;
The thing is, supporting those still mandates support for all four sets of files and all three calculator protocols, i.e. a relatively large subset of the current libti* functionality, and therefore a relatively large subset of the development time.
Not aiming at supporting the 89T, which is exactly what TI did in the recent TI-Connect CE, removes the need for one set of files and one set of commands, but all three protocol families still need to be supported. It's not possible to support the 84+ DUSB without supporting the 89T DUSB partially, it's the same set of commands, though the bytes of the upper layer vary.

BTW, the linkguide only contains partial, and occasionally wrong documentation about file formats and linking protocols. It is unmaintained, and yes, I'm the one to blame for that. The information inside the libti* code is definitely both far more complete and more correct...

[EDITed multiple times to expand and reword content.]

I began to develop an application that is compatible with BlueLink. At this point i didn't notice BlueLink would work with TiLP and TI Connect. Either way I also wanted an Android app (so I could send and receive text messages on my TI84 using bluetooth) so I choose to write an Java application from scratch using your link guide.

I'm not worried about the drivers though. I'm using a third-party crossplatform library for the serial communiactions: jSSC[/url]

Alright. I had seen that topic and I was watching it, but when you mentioned "bluelink" in your previous post, the bell didn't ring.


I see. But as I wrote, the linkguide is both incomplete and wrong, especially for newer models, so you'll have to delve into the libticalcs code anyway.
And you'd save time (though possibly learn less, or at least hone different skills: nowadays, as a professional software engineer, I find that thanks to the variety of good FLOSS, the job is more about finding and assembling the best existing pieces and less about pure coding than it used to be) by leveraging libti*


Indeed, the GrayLink is the easiest cable for drivers and general fiddling. You have that, which proves to be a major annoyance, covered.

I'd love to use libti in my android app. But i don't have a clue how to implement C code in java. I've heard about JNI though. Could you give me directions?

I've never had to do it either myself, but...


... that is the usual way of interoperating between C and Java, yeah.
EDIT: there's also JNA, https://github.com/twall/jna / https://en.wikipedia.org/wiki/Java_Native_Access , based on libffi, and quite possibly easier, it's said to support Android.


The best direction I can give you is probably to have a look at Graph89's source code, since that is, precisely, an Android Java application which uses JNI to call into TIEmu / TilEm (which then call into libti* directly, but there could be one fewer level of indirection): https://bitbucket.org/dhashoandroid/graph89-free .

The most interesting stuff is under jni/wrapper/*. For instance:
* jni/wrapper/wrappercommonjni.c calls into jni/wrapper/wrappercommon.c;
* jni/wrapper/tilemwrapperjni.c calls into jni/wrapper/tilemwrapper.c;
* jni/wrapper/tiemuwrapperjni.c calls into jni/wrapper/tiemuwrapper.c.

A complete call chain:
* src/com/graph89/emulationcore/RomManagerActivity.java calls EmulatorActivity.nativeInstallROM();
* src/com/graph89/emulationcore/EmulatorActivity.java declares nativeInstallROM() as a native method;
* jni/wrapper/wrappercommonjni.c contains Java_com_graph89_emulationcore_EmulatorActivity_nativeInstallROM(), notice the naming convention, which calls
* jni/wrapper/wrappercommon.c, graph89_install_rom(), which calls
* jni/wrapper/tilemwrapper.c, tilem_install_rom(), which calls
* ticables_library_init().

Of course, the devil is in the details. I know that managing allocated memory with JNI needs to be done carefully, otherwise memory leaks or memory access errors ensue. Type conversion isn't necessarily huge fun, either.
FWIW, I recently added a bunch of freeing APIs to all libti* (only on the experimental branch for now), for the purposes of symmetry and slight abstraction of the memory allocator, for the benefit of any client of the library.

JNA is infinitely more enjoyable to work with, but if you're writing performance critical code (on the Java side) that calls C, you're going to need JNI because it gives you more control over the low-level stuff.