So, another update. I've gotten the "compiled token files" working. The interface for the seperate program is shown in the screenshot.

I decided it might be a good idea to define the file type in each token file (that's what "File type" is), so a file compiled for, say, the 85 could say "85P" in the VAR-LINK menu instead of 8XP. But I haven't implemented that in code yet.

This causes token initialization times to be near instantaneous- under a second. The downside? The size of a compiled token file is about double the size of the text file. So I left the code to parse text files in Solar89, giving users a choice between the larger and faster files or the slower and smaller files.

The actual tokenization process is still slow- hopefully that can be rectified with additional optimizations.

Yeah, OS 1.7, not Ndless 1.7. The CAS Touchpad won't boot OS 1.7 for some unknown reason, nothing to do with Ndless (if I understand it correctly).

So- here's a C language question that reflects my lack of understanding of C- is it possible to define a variable-length string (aka character array) in a structure? (Specifically, in the GNU C implementation used by TIGCC/GCC4TI).

That's the basic question- here's why I want to know:

I have this structure defined in Solar89 (Comments should describe what each item is for):

typedef struct
{
    size_t chars; // How many chars are in the string making up the token
    int twoByteToken; // Whether or not the token is two bytes (0 or 1)
    unsigned char hex[2]; // The two bytes making up the token, or only hex[0] if it's a one-byte token
    char name[14]; // The name of the token (never more than 14 chars!)
} tokenInfo;
The way Solar89 currently works is that it reads in a text file and creates an array of these structures. This allows an editable database to store tokens, but it means the initialization will be slow.

I decided I could make it faster by making a second program that does the same thing and writes that array directly to a file. In theory (and correct me if I'm wrong- if I am this entire question is irrelevant) I could read the tokens in much faster by just doing something this (with size being the length of the file, or something like that):

fread(tokens, size, sizeof(tokenInfo), file);
Well, I tested the "token file compiler". The token file outputted is about twice the size as the text file is- for a 5000 byte file, it's around 11000 bytes. Now, this might be worth it if it made the process much faster- I haven't tested that though.

I suspect I could get rid of some space if I could shrink down tokenInfo.name when the token name was only "A" or "1" or "prgm"... etc. But I don't know how to do that.

Is this clear? If not, please just go back to the first paragraph for the actual question and try to ignore the context.

Nope, it's a commandline program.

But it also serves as a linker for assembly programs, which Rabbitsign can't do.

Signing apps means packaging an application in TI's *.8xk format, with a digital signature (the 0104 key) so it can be sent to a calc. If an app is not signed, the calculator won't accept it (and I think TI-Connect won't even try to send it?). An app would run fine unsigned on a calculator (if compiled there using Axe), but if it wasn't signed it couldn't be sent to a computer.

For instance, ZDS (Zilog Developer Studio, one way to make apps- the only example I can think of) produces *.hex files. This contains all the code needed for an application. But you cannot send it to a real calculator without signing it first.

The 0104 key is the only signing key TI actually released, and it can be found in their 83+/84+/73 SDK along with Wappsign, a program to do that.

But Rabbitsign, a community-made program, can also sign apps, along with z80 OSes, 68k apps, and 68k OSes- as long as you download all the keys from BrandonW.net.

Does that explain it?

renamr68k it is.

I've uploaded it to the Cemetech archives, and to ticalc.org. I take it the Omnimaga database isn't finished yet, as there has been no announcement... so not there yet.

EDIT: It's available on Cemetech now.

Kerm suggested "Renamr" on Cemetech- I amended it to renamr68k. Unless I (or someone else) can come up with a better name, that's what it will be called.

Indeed, the TI-68k Developer Utilities, integrated from GCC4TI 0.96 Beta 10 onwards, do not contain a tool for that purpose specifically.

Ah- I was a little worried something like it already existed and I was reinventing the wheel here.

Cool to see new version out

As for the special tokens, are you planning to add them in future versions or are they out of the question?

Yeah, I'm going to add them (as I said, most are listed on Misc. Tokens). I just was too lazy to do it now.

EDIT: Cemetech download up now.