Unsigned char is a fine replacement for byte.

Does it really make a difference if I use unsigned char or unsigned int?

I mean, I know that unsigned char is the same size as a byte. It's just I already have the code written that treats the output as an array of integers.

"unsigned char" is 8 bits, "unsigned short" is 16 bits. "enum Bool", "BYTE" and "BOOL" are seldom used.

Okay, so really there's no reason to use BYTE or BOOL, then? Or is there some specific case where BYTE and BOOL are better to use?

Quote

The trouble is if the "next character" in the string is the same as one of the characters that's part of the token, it won't work. So if the line is: Disp "HELLO", then the program will hang when it's truncated "HELLO" down to LLO", because two Ls are next to each other, and so strpbrk("LLO"", "L") will return "LLO"".

In many parsers, characters are divided into classes of lexical elements (string, comma, etc.), and a lexical analyzer is built to recognize them (e.g. a string starts with a '"' and it lasts until the next '"' or maybe end of line). On top of the lexical analyzer, there's a syntactical analyzer, which tries to parse a stream of lexical elements (get an element, then act upon its type - maybe there are other expected elements of various types after it). And on top of the syntactical analyzer, if the language is complicated enough, there's a semantics analyzer (e.g. {, number 234, comma, number 567, comma, number 8 is a list).

But maybe I'm replying out of scope because I'm dense ?

Well, I understand what you're saying, but I'm not sure how it's relevant... Well, I know how it's relevant (since I'm writing a program to look through text files), but I'm not sure if any of the information is useful to my current problem.

Well, GCC4TI seems to take issue with some of that- it didn't like me defining things as bytes or BOOLs (or with asterisks before the variable type). I changed it, though (to use integers instead of bytes and bools).

But shouldn't the tokenInfo object also contain the name of the string? Or is there a way to compare the name of a variable against a string?

And I did add it, would the size_t chars data even be necessary? Couldn't I just call strlen() on the string?

That seems like it would work much better than what I was doing. Thanks!

Your assumptions are mostly correct- I hadn't been using a tokenInfo structure, but I eventually would have needed to create one. (I was using arrays for the handful of tokens I had defined, but that would have gotten unwieldy pretty quickly, especially with two-byte tokens).


Also, sort of unrelated: I'm wondering if it might be easier to define all the tokens (the strings and the hex) in a text file on the calculator, and read them in as tokenInfo structures (well, as a collection of tokenInfo structures defined in a tokens structure, or something like that). That way, I don't have to figure out how to handle all the weird characters, plus, the list of tokens could be modified without recompiling everything. The only downside is that the text file would be required on-calc.

To more experienced programmers- which seems like a better idea? Define them in the program or an external text file?

Unfortunately I'm having another issue- although not with the "read text files into lines" part, the "parse lines into 83+ tokens" part (see here for what my project is).

The way I'm removing characters from a string is strpbrk(). So my function to parse lines works recursively and does the following:

1. Send the line to a function to check if it's a token.
2. If it is a valid token, adjust the array of hexadecimel tokens and return.
3. If it is not, truncate it by removing a character from the end each time using strncpy() until it finds a token.
4. When a token is found, adjust the array of hexadecimel tokens, use strpbrk() to remove the part of the string that's a token (by getting the first character in the string that's not part of the token), and call the entire function again, this time for the rest of the string.

The trouble is if the "next character" in the string is the same as one of the characters that's part of the token, it won't work. So if the line is: Disp "HELLO", then the program will hang when it's truncated "HELLO" down to LLO", because two Ls are next to each other, and so strpbrk("LLO"", "L") will return "LLO"".

Is there some other way to split strings that doesn't have this problem? Can I slice them like "string[2:5]" and get back the string containing characters 3, 4, and 5 (or something like that)? If I knew a bit more about C I'm sure I could figure this out... but I don't.

I've dropped my 83+ a few times before, but I don't think I damaged it.

Then again, my calc's link port did break, and I couldn't find a flaw in the soldering when I went and looked, so... maybe I did damage it.

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".

Where would I find a copy of 1.15?

Google it (or use any other search engine), or use WebArchive.

We can't give it to you (assuming anyone has it), just like no one can post any of the old Nspire or 84+ OSes.