I have two *.89t files and one *.89p files that are part of my project. The *.89p (my unfinished custom toolbar) is not so important at the moment, but the text files are- one is a demo and the other contains all of my tokens.

Is there any way I can convert *.89t files to *.v2t and *.9xt files? Is the file format the same, so I could just copy and rename the files? Or would I need to do some hex editing?

A note- this is 68k C (GCC4TI), not Nspire C. Shouldn't really be a difference except for the nature of my error...

I've mostly finished making z89 (that's my z80 Basic editor for 68k calcs) read in the list of tokens from a token file, then build them into an array of tokenInfo structures. The code to do this is rather complicated and probably poorly written- I'm not the best C programmer. I only started programming in C recently. However, it works.

Or, at least, it would work if not for the Address Error I get when I try to free allocated memory at the end of the process. I have four pointers to strings being dynamically allocated- the text of the token file, a "working" string (for storing end-of-line characters and other things necessary in procedures like strcpsn()), a line string (for storing each line of the text file), and a "tokenstr" string, for storing token information (first the name, then the first token in hex).

I had had problems with this before. Specifically, originally I was using realloc() to shrink and decrease the line string on each pass through the while loop. But that was causing an Address Error. I "solved" it by allocating enough memory to store the entire file to the line string- I'm not entirely sure why that solved the problem, though.

The GCC4TI docs offer the definition of an address error below, but I'm not sure how trying to free the pointers would cause that.

Q: What kind of error in my program usually causes an "Address Error"?

A: Well, writing over the boundaries of an array can usually cause all sorts of errors, since it usually destroys code or the return address of the function. However, an "Address Error" actually means that a short or long value is read or written at an odd address. So if you get an "Address Error" while you are dealing with pointers, check that you do not cast an odd address to a pointer to a short or long integer. 

Here is my long and probably over-complex initTokens() function, which is where the array of token infos is built. It assumes the text file is formatted as follows (name\byte1\byte2, with byte2=0 if the token is one byte):

:BoxPlot\0x05\0
:ClrHome\0xE1\0
void initTokens(tokenInfo *tokens, char *tokenfile)
{
    int length;
    int bool;
    int newlength;
    int span = 0;
    int i = 0;
    char newchar;
    char endline = '\r';
    unsigned long rawhex;
    unsigned short size = 0;
    unsigned char hex = '0';

    char *tokentext = NULL;
    char *working = NULL;
    char *line = NULL;
    char *tokenstr = NULL;

    tokenInfo token;
    SYM_ENTRY *sym;
   
    if ((working = (char *)calloc(2, sizeof(char))) == NULL)
    {
        DlgMessage("DMA Failure", "Unable to allocate space for working string", BT_OK, BT_NONE);
        return;
    }
    if ((line = (char *)calloc(10, sizeof(char))) == NULL)
    {
        DlgMessage("DMA Failure", "Unable to allocate space for line string", BT_OK, BT_NONE);
        free(working);
        return;
    }
    if ((tokenstr = (char *)calloc(16, sizeof(char))) == NULL)
    {
        DlgMessage("DMA Failure", "Unable to allocate space for token working string", BT_OK, BT_NONE);
        free(working);
        free(line);
        return;
    }
   
    //Get the size of the token file and allocate memory accordingly
    sym = SymFindPtr(SYMSTR(tokenfile), 0);
    size = ((MULTI_EXPR*)HeapDeref(sym->handle))->Size + 2;
    if ((tokentext = (char *)calloc(size, sizeof(char))) == NULL)
    {
        DlgMessage("DMA Failure", "Unable to allocate space for token file string", BT_OK, BT_NONE);
        free(working);
        free(line);
        free(tokenstr);
        return;
    }
   
    //Get input from file, set length and reallocate memory to troublesome pointers
    bool = getPrgmFromText(tokenfile, tokentext, size);
    if (bool == 0)
    {
        free(tokentext);
        free(working);
        free(line);
        return;
    }
    length = strlen(tokentext);
    line = (char *)realloc(line, (length + 2) * sizeof(char));
    tokenstr = (char *)realloc(tokenstr, (length + 2) * sizeof(char));

    //Loop until the length of the input string is zero
    while (length > 0)
    {
        //Maintain num token size!
        i += 1;
        if (i > NUM_TOKENS)
        {
            tokens = (tokenInfo *)realloc(tokens, i * sizeof(tokenInfo));
            NUM_TOKENS = i;
        }

        //Get the length of the line up to trailing character, reallocate memory
        memset(working, '\0', strlen(working));
        memset(line, '\0', strlen(line));   
        memset(tokenstr, '\0', strlen(tokenstr));           
        sprintf(working, "%c", endline);
        span = strcspn(tokentext, working);
       
        //Load the line into a string, and then remove it
        line = strncat(line, tokentext, span);
        tokentext = strpbrk(tokentext, working);
       
        //Then clear out the \r at the front of the string and clear the working string out
        newchar = tokentext[2];
        sprintf(working, "%c", newchar);
        tokentext = strpbrk(tokentext, working);
        length = strlen(tokentext);
       
        //Init the token
        token = tokens[i];
        token.twoByteToken = 0;

        //Seperate the name component from the line and set it (and it's length!)
        memset(working, '\0', strlen(working));
        sprintf(working, "%c", '\\');
        newlength = strcspn(line, working);
        tokenstr = strncat(tokenstr, line, newlength);
        line += (newlength + 1);
        token.chars = newlength;
        token.name = tokenstr;
       
        //Seperate the hex component from the line and set it
        memset(tokenstr, '\0', strlen(tokenstr));
        tokenstr = strncat(tokenstr, line, 4);
        rawhex = strtol(tokenstr, NULL, 0);
        hex = (unsigned char)rawhex;
        token.hex[0] = hex;
        line += 5;

        //Then check if what's left of the string is the second byte of a two-byte token and deal with it
        if (line[0] != '0')
        {
            rawhex = strtol(tokenstr, NULL, 0);
            ngetchx();
            hex = (unsigned char)rawhex;
            token.hex[1] = hex;
            token.twoByteToken = 1;
        }

        //Update the token
        tokens[i] = token;
    }
   
    //Free memory
    free(working);
    free(tokenstr);
    free(line);
    free(tokentext);
}

UPDATE: Beta v0.2 has been released, and can be downloaded here (from the Cemetech Archives).


So I thought I might as well announce my first serious calculator project, even though it's probably of little use to anyone other than myself or in my current situation, though.

This project (which I have not yet named) is a suite of 68k programs and computer programs to allow someone to write a program in Z80 Basic (83+/84+) on a TI-89 (or other 68k calculator), using the text editor. The program is then tokenized on the calculator, and then can be sent to a computer to be converted to an 8xp file. This is not an interpreter for Z80 Basic for 68k calcs, nor is it an emulator or a debugger- you cannot actually run the programs on the 68k calculator.

Why? Well, you might remember that my link port broke on my old TI-83 Plus, and I haven't yet gotten a new Z80 calculator. So for the time being, I'm limited to WabbitEmu or my Titanium, and while I can still write assembly programs and test them with WabbitEmu, I'd much rather write Basic programs (both Axe and regular Basic) on an actual calculator. And true, the 89's keyboard is just different enough from the 83+'s to make entering text annoying, but it's better than nothing.

And while chronomex (Duncan Smith of ticalc.org) is working on a Z80 emulator at the moment, by the time it's finished I might actually have an 84+. And since I'm learning C and needed to work on something that actually did something, I decided to work on it. This will probably be obsolete when Duncan Smith's emulator comes out- indeed, as I said, it might be obsolete before then, as I don't know how many people would actually need something like this.


So that's why. Now, as for the how:

There will be three different programs involved (technically, four depending on how you count).

One, a 68k Basic program (that I have named token8x), installs a custom toolbar with all the 83+ (and 84+, when I look them up) tokens. This can then be activated by pressing 2ND - HOME on a 89, and accessed from anywhere on the calc, including the Text Editor. This is mostly finished.

Using this, you would write programs in the Text Editor, save them as a text file, and then use a 68k C program to tokenize the text file into an application variable with the tokens in hex format. This is mostly finished in that it works, but there is other stuff I'd like to add in the future.

Then, the appvar can be sent to a computer, where you would use a suite of Python programs to extract the tokens and save them in 8xp format. This is probably complete (short of supporting other calculators)


Here are some screenshots, of the dialog menu and of the custom toolbar. All screenshots are from TiEmu, nothing has actually been done on calc... and as you might be able to tell from the name of the program, all it does is "ClrHome".

Is there any way to write flash apps for the 68k calcs anymore, without using TI's Flash Studio? Because Microsoft's JVM is no longer available on their site, which is required for it to run.

TIGCC/GCC4TI doesn't support flash apps- are there no third-party programs that let you do this?

I'd have put this in either the ASM or C forums, but I'm not sure what language apps on 68k calcs are written in.

Hi!

I first learned to program my old TI-83 Plus last year (in Basic), and since then I've become more interested in calculator programming, leading to me getting a TI-89 Titanium, fooling around with assembly for the 83+, and, by a sort-of direct path, joining this site (even though I discovered it two months ago).

I have some knowledge of Z80 assembly, but it's very sparse at the moment, as is my knowledge of C for the Titanium, something I started learning only recently.

I also can do computer programming, in Visual Basic .NET and in Python.