UPDATE: Beta v0.2 has been released and can be downloaded here.


This is my first (serious) calculator project, a suite of programs to allow you to write Z80 Basic programs on a 68k calculator, then tokenize and save as an 8xp file that can be ran on a Z80 calculator.

It has a thread on Omnimaga, and as I stated there, it might not be very useful, since more people have an 83+ or an 84+ than have an 89. I started it because my 83+'s link port died, and while I could use WabbitEmu and/or SourceCoder for writing Z80 Basic (and Axe) programs, I much prefer programming in Basic on a calculator. And the 89 has a keyboard and keyset that's similar enough for something like this to work.

The name is a reference to Lunar IDE, an editor for z80 BASIC on z80 calculators.

It will consist of three main parts. I'm writing a 68k Basic program to install a custom toolbar with all the 83+ tokens, for access from anywhere on the TI-89. Then the text editor would be used to actually edit the programs, and save them as 89t files- on calc text files. Then an on-calc C program can tokenize the program on the calculator, for transfer to a computer where a Python (2.x) program- that will include Kerm Martian's BinPac8x- will convert the 89y into a 8xp program file.

It's about 60-70 percent complete. The tokenizer works as is at the moment, but my goal is to change over to storing the tokens in an editable text file on the calculator- and even have the UI prompt for that text file. This would eventually mean that the program could tokenize for TI-82, TI-83, TI-85, and TI-86 Basic. This might be even less useful, since there aren't many people developing for those calculators anymore, but I still think it's a cool feature.

I've been working on the Python end of things at the moment, integrating BinPac8x with my other Python modules. I've gotten it to work on an older tokenized program I had copied out of TiEmu, but since I've also been taking apart and rebuilding the tokenizer I can't verify it works on anything newer.

Some screnshots follow, those posted on Omnimaga when I first announced it.

TC01, this project sounds very cool, and I could definitely see the merit of writing TI-BASIC for the z80 calculators on the 68k's. I'm glad that my BinPac8x is coming in handy for your project, and I appreciate your tips on possible ways to make it work on Python 2.x. How does the tokenizer work, is it similar to SourceCoder in that it has an exhaustive list of text to token conversions, and it tries to find the longest string that is a token at each point in the plaintext file?

That's basically how it works, yeah. It strips down the text file into lines and then shortens the line until it finds a token, and then does the same with the remainder of the line, and so on.

Unfortunately, this means some of the weirder statistics tokens won't work, like 2762h, or "df". How do you possibly handle "df" without being unable to handle the tokens "d", and "f"?

Does SourceCoder have a solution for this?

Interesting question, and of course one I considered myself. In TI-BASIC for the 83+/84+ series, since all the variable names are uppercase, 'd' 'f' cannot possibly implicit multiplication, and must just be text. Since lowercase characters are 2 bytes, and the df token is also two bytes, there's actually no downside to interpreting 'd' 'f' as the 'df' token. There's a few other similar cases, but none that I've found that impact the language in any detrimental way.

Oh, so it doesn't even matter- Disp "df" works whether or not it's d, or f. Good.

Also, you asked me about BinPac8x: here's what I did so far, in addition to what I posted in the other thread:

1. Added an "if __name__ == "__main__":" line above all the topline code at the bottom of the script- this stops it from running when imported.

2. Added an optional argument, oncalcname, to parsefile(). This is to prevent the on-calc name of a program from becoming "C:\USERS" or "C:\PYTHO" if the script is not in the same folder as the file I want to convert (which it probably won't be for my project). The name is calculated normally if oncalcname == "", otherwise the override is used. My script uses the override- BinPac8x itself does not.

Apart from that, I still need to figure out what to change to stop it from producing protected programs. Do you know what byte I would need to change?

I most certainly do, I'm surprised I didn't comment it in there.
In the following sequence, change 6 (ProtProjObj) to 5 (ProgObj):


Code:


And I'll most certainly be including your fixes and modifications.

Thanks Kerm!

Now I just have to get the tokenizer's file I/O system working and write the token text file.

Sounds excellent, good luck with that. I'm working on incorporating the changes you suggested, although I'm still a bit stumped on how I'm going to made the 2.x version work with bytes(..,..). I don't suppose there's a conditional you can use that only evaluates to true under 2.x...

You could try checking the value of sys.version[0].

sys.version is the string of information printed out after the "Python " at the top of the interpreter when you start it up. On Python 2.x, sys.version[0] (the first character in sys.version) is 2. Presumably, then, it would be 3 on a Python 3.x install, so you could do something like this:


Code:

Qazz, Swivel, and TC01, would it be possible for you to test the following beta of BinPac8x v1.2?

http://www.cemetech.net/files/binpac8x.py

Major changes:
1) Added optional -O NAME to specify the on-calc name
2) Updated the disphelp() accordingly
3) Added the ' if __name__ == "__main__": ' that TC01 suggested
4) Replaced my uses of bytes() with mybytes():


Code:


This seems to be working; I'm a little uncomfortable with specifying encoding like that, though.

Edit: Qazz42 reports that it's still broken under 2.7. Line 75, specifically bytearray([bbsize_lb,bbsize_hb]), isn't too happy.

Kerm, it no workey, glad I could help though

Try replacing line 75 with this:


Code:


I didn't try it, but I guess you forgot to convert all the floating point numbers to integers- Python 2.x can't make floats into a bytearray.

Code:


with



Code:



?

Yes. I realized I forgot to say why and edited the above post- you need to call int() to convert floating point numbers to integers before making them part of a bytearray.

Hmm, surprisingly I understand what you are saying

You totally mentioned that before, and it totally slipped my mind. Download link is same as above:

http://www.cemetech.net/files/binpac8x.py

The super-duper-awkward workaround that works for string and lists:

Code:

Code:

I finally broke down and installed Python 2.7 on one of my Linux servers so I could do some fast debugging. I finally got it, I believe; I think the byte() and bytearray() objects in general are quite poorly done in Python. Please test at your convenience:

http://www.cemetech.net/files/binpac8x.py

Yay Kerm! It works, good job



Code:

Awesome! I'll have to take out those debug statements and republish. Did you happen to check that the program produced still worked properly?

Edit: On second check, now 3.x is slightly broken. The testing continues. >_<