Not terribly long ago, I decided to learn how to make RPM packages for Fedora. The software I chose to package was TiLP, because there are no up-to-date packages and because running the installer script on Fedora (especially 64-bit Fedora) seems to have additional complications.

After the next release of TiLP, I intend to try and get them into the official Fedora repos. I'm waiting because there are various issues with TiLP 1.15 that rpmlint (that's the tool for checking RPM packages for conforming to standards and suchlike) complained about.

So, in the meantime, here are the RPMs. To install them, either use a GUI tool (whatever Fedora launches when you double-click on a .rpm file), or use the rpm command: "rpm -i [filename]" as root. Please note: you must install the RPMs in this order:

-libticonv
-libtifiles2
-libticables2
-libticalcs2
-tilp2, gfm, and tiemu

Then, you'll need to run the "tilp" command in the terminal (or "gfm" to use gfm, or "tiemu" to use tiemu).

If you use 32-bit Fedora, you must download the i386 zip. If you use 64-bit Fedora, you should download the x86_64 zip, but you can install the 32-bit packages instead, if you really want to.

So this is something I just started playing around with, and I thought I'd make a post about it mainly so it'd be easy to ask for help.

Python-on-a-Chip (formerly known as PyMite) is a Python interpreter designed for embedded systems. It supports a "significant subset" of the language. Here are it's features:

•Requires roughly 55 KB program memory
•Initializes in 4KB RAM; print "hello world" needs 5KB; 8KB is the minimum recommended RAM.
•Supports integers, floats, tuples, lists, dicts, functions, modules, classes, generators, decorators and closures
•Supports 25 of 29 keywords and 89 of 112 bytecodes from Python 2.6
•Can run multiple stackless green threads (round-robin)
•Has a mark-sweep garbage collector
•Has a hosted interactive prompt for live coding
•Licensed under the GNU GPL ver. 2

That sounds pretty decent for the 89, which has 256 KB of RAM and 188 KB of it user-accessible.

So theoretically, all I would have to do to make this run on a 68k is write some platform-specific routines for the 89 and get it to compile using GCC4TI.

That might be trickier than it sounds, though, because I'm not that great of a C programmer, and I'm not entirely sure yet how PyMite works. You need to use a Python script to convert your Python code into an image file of some sort, which then gets linked up to the C program... at least, I think it does.

I almost got it to build this morning, but it was complaining about the missing Python images- which I didn't even realize I needed until an hour ago. I haven't done any more on it yet.

This project is my longstanding attempt to create a command line utility and Python library for accessing, searching, and downloading projects from ticalc.org (and other sites).

Current version is 1.1; 2.0 has been in development for a while but is hopefully nearing a release with possible support for downloading programs from Cemetech and Omnimaga as well.

Development is generally happening at github- you can clone a snapshot from there. Or, you can download the latest version from ticalc.org for Windows or Linux. (Downloads are also hosted on Cemetech for Windows and Linux). Once it's downloaded, extract the archive and run "python setup.py install". Note that if you're on Linux, this command will probably require root access (su or sudo); no matter what platform you are on you will need Python 2.x to run it.

After installing it, you can run it on the command line using:

python calcpkg.py [command] [filename]

Note that if you're on Linux and using 2.0 or higher (or the 2.0 snapshots from github), you should instead be using:
calcpkg [command] [filename]

The first command you run should run is "update"- this will create a local copy of the master.index file from ticalc.org that calcpkg knows how to use for searching and so on. Then you can run "calcpkg search" and "calcpkg install", which will list and download programs. For a full list of all possible options, run "calcpkg -h" (or possibly refer to the README).

Here is a rather old screenshot:

This is the project that I alluded to here- a program to extract data from X-Link appvars into programs.

X-Link is potentially very useful in that it allows 83+/84+ calcs to receive data from all other TI calculators (the 85, 86, and 68ks- not Nspire though). But because the 89 Titanium has a very large archive memory, I would rather store TI-84+ programs on the Titanium and send them to an 84+ instead.

Rather than try to create an 89 version of X-Link, I decided to do something simpler. Make a computer program to package 8xp files as 89y custom variables (called "X-Packager"), and then make a z80 assembly program to unpack X-Link appvars and copy the contents into a program.

This would allow a TI-89 user to download TI-84+ games and share them with friends who have z80 calculators (the reason I wanted to do it).

I'd say it's about 50% complete. I've completed a Python program to make the 89y files (it uses ttbin2oth from the TI-68k Developer Utilities for the packaging, and a Python script I wrote to extract data). And I've written a z80 assembly program to extract data from an appvar and copy it to a program (I used Andree Chea's ZCopy as an example for this- it basically did what I wanted, but it copied a program into another program.

I still need an X-Link appvar containing a TI-89 variable, however, to take this any further, for the reasons outlined in the other topic.

So I currently am trying to fix someone's broken 83+ at school.

At first I thought it was bricked- pulling all 5 batteries didn't do anything; the LCD was frozen on the Y= screen with lots of error messages.

Then I discovered (once I hooked it up to a laptop) that I could communicate to it with TI Connect. But I can't fix the LCD...

Netham45 mentioned on IRC there was a fix for this, but I don't know where it is (neither did he). Any ideas?

So, I've recently installed a Fedora 13 partition on my desktop (replacing an old XP partition). I've been installing various calculator-related stuff, but I'm having a little problem with TiEmu.

I ran ./configure after extracting the tar archive, and got the following error message:

configure: error:
in the prefix, you've chosen, are no KDE headers installed. This will fail.
So, check this please and use another prefix!

This is most likely because I don't have KDE installed on my system- Fedora (13, at least) comes with Gnome. What I'm not sure about is what package to install without installing KDE itself- is there something containing just the headers?

In the process of making the latest version of Solar89, I got fed up with having to copy and paste *.89t and *.89p files and change their extensions to *.v2t and *.9xt. I wrote a Python script to do it for me called renamr68k.

What exactly am I talking about, you ask? (If you understood exactly what I just said, skip the next two paragraphs).

GCC4TI produces executable files for all three supported 68k calculators- the 92+, the 89, and the V200. However, if an assembly program needs external files, or is coupled with useful TI-BASIC programs (both of which are true for Solar89) and you only have one 68k calculator, you'll need to manually create duplicate versions for the other calculators. So if I need the text file "test.89t", I send it to my computer from my 89, make two copies, and change them to "test.9xt" and "test.v2t".

The same problem is true if you are making BASIC programs with your calculator and would like to support the other 68ks. Yes, in both cases a user could do it themselves, but they may not know that the file formats are identical on all three 68k calculators.

Hence, this Python (2.x) script. Credit to Kerm for coming up with the core of the name- renamr (which I expanded to renamr68k).

It has been submitted to Cemetech and ticalc.org... download here on Cemetech.

This morning, I checked if Solar89 can properly handle two-byte tokens (by adding the Matrix tokens). Most of the time it works... but sometimes it doesn't, and I'm not sure how I can fix it.

Here's a situation that would cause a problem: trying to run a text file containing "[A]", or the matrix A token, through Solar89. Why? The hex code for this token is 5C00h.

The way Solar89 is programmed, each line of the text file is looked at individually, and then the hex code for the token is added to an unsigned character array (since unsigned char = 8 bits). So if the line contains the token ClrHome, the program will add the character E1h to the array, then add 3Fh to the array to finish it off. A two-byte token is handled by splitting the hex code into two characters and adding them both to the array. So for the token [C] (5C02h), the character 5Ch and then the character 02h.

The problem? For any token that has a byte of 00 (there aren't too many, but they include [A]), the \0 character is what will be added to that character array. And that seems to prevent me from adding anything else to the array. So if I'm trying to tokenize [A], no end-of-line character will be added, and anything after [A] on that line won't be added either.

But that's not the main problem. The main problem is that the code that saves the token array to a file does it by writing each individual character to the file, and it stops before it reaches \0. So even for a file only containing [A], I won't get 5Ch 00h 3Fh (3Fh being the hard return, the newline character), I'll just get 5Ch.

Fortunately, only a few tokens have a byte of 00h, and probably a lot of programs can be written without using them. But it would be nice to support them, but I'm not really sure how. Would I need to use something other than an unsigned character array? Or can I implement some workaround?