Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => Topic started by: TC01 on July 23, 2010, 01:02:55 pm
-
UPDATE: Beta v0.2 has been released, and can be downloaded here (http://www.cemetech.net/programs/index.php?mode=file&path=/89/asm/Solar89_SDK.zip) (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 (http://github.com/chronomex/680), 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".
-
Sounds cool. Although I'll never use it, it sounds like it could be useful to some.
At first I thought you were writing a z80 BASIC interpreter, not just an editor. (I never thought you were writing emulator/debugger, though :P)
Good luck! :)
-
It is nice to see some new stuff for 68k calculators even if with limited use.
But hopefully, is really useful for you and maybe you can give us some z80 TI-BASIC in the future.
It is true that doing something oncalc is more familiar to some of us, so there is hope other people pick and use it.
I liked to hear about the z80 emulator in 68k. Although I know there is Gameboy emulator...
Too bad about your calculator link port. I give you a hint if you want assembly programs on it: http://asmtools.omnimaga.org/asmunsquisher/
More useful to little programs. See by yourself but in the case of doubt of what it does, ask me.
Have fun doing your suite. ;)
-
Sounds cool. Although I'll never use it, it sounds like it could be useful to some.
At first I thought you were writing a z80 BASIC interpreter, not just an editor. (I never thought you were writing emulator/debugger, though :P)
Good luck! :)
Yeah, good point- I've edited it to add that it's not an interpreter either.
It is nice to see some new stuff for 68k calculators even if with limited use.
But hopefully, is really useful for you and maybe you can give us some z80 TI-BASIC in the future.
It is true that doing something oncalc is more familiar to some of us, so there is hope other people pick and use it.
I liked to hear about the z80 emulator in 68k. Although I know there is Gameboy emulator...
Too bad about your calculator link port. I give you a hint if you want assembly programs on it: http://asmtools.omnimaga.org/asmunsquisher/
More useful to little programs. See by yourself but in the case of doubt of what it does, ask me.
Have fun doing your suite. ;)
Thanks!
Yes, I noticed your assembly unsquisher on the Misc page, and it would be useful for running small programs, as you said.
-
Sounds cool. I, for one, can put it to use, since I have both an 84+SE and an 89T.
-
Sounds really neat :) What kind of programs are needed to convert it into a 8xp?
-
Sounds really neat :) What kind of programs are needed to convert it into a 8xp?
Something like Kerm's BinPac8x, probably. Depending on how BinPac8x works, I suppose it might be possible to use it rather than write something else. It takes binary files and outputs and 8xp file, which means it writes the hex data to an 8xp file, adding in all the formatting and everything. I have hex data, so... I'll have to test BinPac8x.
I'm using Romain Lievin and Tim Singer's file format and link protocol (http://www.ticalc.org/archives/files/fileinfo/247/24750.html) guide as a reference for both parts of the project- it documents all the 83+ tokens.
Sounds cool. I, for one, can put it to use, since I have both an 84+SE and an 89T.
Well, you can- I just don't know that you would have to. Maybe if you need the advanced mathematics functions of the 68k but want to work on some 83+ program?
This project reminds me a bit of GTC, the on-calc C compiler. It's very cool, but the only possible use (in my mind) would be programming in 68k C when you don't have a computer handy. (I installed it anyway, though).
-
This sounds pretty cool. Can't wait to play around with it.
-
Very interesting and unique...I can't wait to see how it goes!
-
I've been posting more about this in the C Programming help topic than in this topic. :P
Anyway, I've decided that I'm going to make the list of tokens be stored in an external text file on the calculator. Therefore, I could also make the dialog box prompt for choice of token file- which would mean this program could easily tokenize in 82, 83, 85, and 86 Basic as well (with some changes on the PC end of things in how the file is created).
That might be even less useful, since I don't think there are many 82/83/85/86 Basic developers out there anymore, but I still think it's a cool thing to add.
-
Nice. The only thing you need to realize is that the 85 and 86 stored untokenized code ;)
-
And some actual progress- the program's now successfully (at least, I think it is- again, I don't have the PC end of things in order yet) tokenizing multi-line programs, and lines with multiple tokens.
Nice. The only thing you need to realize is that the 85 and 86 stored untokenized code ;)
The way it works on the 89 is that tokenization happens when you exit the program editor- when you enter the program editor everything is untokenized into raw text (so you can type out all raw commands).
Is this the way it works on the 85 and 86? If it is, then there's no problem.
But I'm going to focus on 83+/84+ for the time being.
-
Hm... I'm unsure. I didn't know that about the 68k series, btw. ;D
Yeah, best to finish what you started first. :)
-
An update: I've began some more serious work on the Python end of things.
I've written a single script that calls functions in two other modules- KermMartian's binpac8x to actually make the 8xp file, and parse89, a module I wrote with functions for extracting data from an *.89* variable file.
It's not entirely finished and it needs to be tested, of course- and for that I need to finish changing the on-calc tokenizer over to using text files (I started it but didn't finish, which means that it doesn't work at present and can't produce test programs).
-
Interesting. Those who want to make 83+ BASIC games but mostly have access to a 68k should definitively find this useful :)
Just make sure to convert the program there aren't too many dependencies to install, though. I heard some people complain about how a software used a different Python version than another and I remember having troubles with GTK too, with two softwares using different versions, forcing me to install/uninstall them back and forth, depending of which software I needed
-
Interesting. Those who want to make 83+ BASIC games but mostly have access to a 68k should definitively find this useful :)
Just make sure to convert the program there aren't too many dependencies to install, though. I heard some people complain about how a software used a different Python version than another and I remember having troubles with GTK too, with two softwares using different versions, forcing me to install/uninstall them back and forth, depending of which software I needed
Yes, I find it rather annoying that Python 3.x broke backward compatibility (or at least partially), since I program in Python 2.x. I did get BinPac8x to work, however, under Python 2.x (at least, I think I did), and posted on Cemetech the changes that I made.
For Windows users, I'm considering using py2exe (http://www.py2exe.org) to package the programs an executable rather than a Python script. Then no installation of Python is necessary- but users would have to install this (http://www.microsoft.com/downloads/details.aspx?FamilyID=9b2da534-3e03-4391-8a4d-074b9f2bc1bf&displaylang=en) first as I don't have the rights to distribute a required DLL. Well, technically speaking, I might have the rights if the DLL was included in Visual Studio 2010, but it doesn't appear to be.
-
A few updates.
First, I've settled on a name for the project (at least temporarily, anyway)- it will be called "z89 IDE". I am, however, considering naming the on-calc component "Solar89" as a reference to Lunar IDE... I'm bad at coming up with names.
Second, the Python end of things is working perfectly (or appears to be). I tested it with a variable generated from an older version of the tokenizer and it produced a *.8xp file, which I ran successfully in WabbitEmu! Admittedly, all it did was clear the screen, but that's progress.
I'm now resuming work on the tokenizer. I just need to finish getting it to read tokens in from a text file, then actually write that text file, and then I can release a beta.
-
mhmm idk about z89, but I can't figure out a better name right now x.x, so maybe it will do, idk.
Glad to see updates :)
-
I suppose I could call the entire thing Solar89. That's already the name of the tokenizer.
At the moment, development is held up due to an address error caused by the token file reading code that I've been unable to fix... I asked for help and posted the source code in this thread (http://ourl.ca/6553). Hopefully Lionel or someone else can help figure out what's wrong.
I haven't been working on the token file because of recent issues with my calculator, but now that it appears to be in a stable state (or as stable as it was before I decided to delete TI's preinstalled flash apps, anyway), I'll get back to work on that.
-
Ouch, sorry to hear. I hope you can figure out the problem. I also hope your calc isn't damaged or something x.x. Normally deleting TI apps shouldn't cause any issues
-
Ouch, sorry to hear. I hope you can figure out the problem. I also hope your calc isn't damaged or something x.x. Normally deleting TI apps shouldn't cause any issues
I've identified the cause of the problem, now I just have to actually fix it in my program.
As for my calculator... well, at the moment it's doing everything I want it to, it appears to be stable as I said, and it also has a lot more memory so I shouldn't need to delete any apps. If I run into some other problems in the future, then I'll deal with it then.
-
Wait, if we could make it so that the 83+ basic prgms made on the 68K calc, wouldnt that be cool?
{we would need some converter though}
-
Ouch, sorry to hear. I hope you can figure out the problem. I also hope your calc isn't damaged or something x.x. Normally deleting TI apps shouldn't cause any issues
I've identified the cause of the problem, now I just have to actually fix it in my program.
As for my calculator... well, at the moment it's doing everything I want it to, it appears to be stable as I said, and it also has a lot more memory so I shouldn't need to delete any apps. If I run into some other problems in the future, then I'll deal with it then.
Aaah cool, good luck!
As for Qazz idea, it would be cool. It would sure require some converter indeed, though. I wonder how hard it would be to create...
-
After a bit of further thought, I've decided to change the name of the entire project to Solar89. I'm thinking that z89 sounds better for a 68k calc assembler for the z80 calcs... which is also a cool idea, definitely possible (if the z80 calcs themselves can support an on-calc assembler, than the more advanced 68ks can too) but probably a bit harder to do.
Wait, if we could make it so that the 83+ basic prgms made on the 68K calc, wouldnt that be cool?
{we would need some converter though}
I guess you mean, actually run the 83+ programs on the 68k calc?
I think it would be pretty cool. It would be an easier programming language for the 68k calcs (I find 68k Basic to be pretty easy compared to, say, assembly or C, but it is definitely harder than z80 Basic and I know others don't), albeit a less powerful and slower one.
I guess there are two ways it could be done- either make an interpreter for z80 Basic or write a program to convert a z80 Basic program (maybe one generated by Solar89?) to a 68k Basic program.
-
Perhaps he meant tokenizing on calc?
-
For a converter, I think it would have to be a computer converter that changes 8xp files to 89p and convert the TI-BASIC syntax to 89 format. The user would adjust the screen size-dependent stuff himself
-
Perhaps he meant tokenizing on calc?
That's what this program does. :P You edit the text file on-calc, tokenize it, and then send the tokenized file to a computer and convert it to an 8xp file.
For a converter, I think it would have to be a computer converter that changes 8xp files to 89p and convert the TI-BASIC syntax to 89 format. The user would adjust the screen size-dependent stuff himself
Yeah, true.
But an on-calc z80 Basic interpreter might not be out of the question- although it would be much harder to do than this...
-
An update- I now have a working tokenizer and converter! Screenshots follow, showing a rather simple program in 89 text file format, then the converter interface, and then the program in WabbitEmu (which is animated because I'm not quite sure how to take a non-animated screenshot).
I still have to write a token file before first release, though. And implement an error-checking system (to write 0x00 or something like that if there's an incorrect token).
-
Nice to see this coming along :)
-
Perhaps he meant tokenizing on calc?
That's what this program does. :P You edit the text file on-calc, tokenize it, and then send the tokenized file to a computer and convert it to an 8xp file.
I know that, but his post is rather confusing.
Glad to see more progress on this. It is coming along rather nicely! :)
-
wow, this is cool, this project has a future! I hope to get a 68K calc >:)
-
Update: All one-byte tokens are now supported.
I've been working on an error-handling system, but it has some bugs at the moment (sometimes it works, sometimes it doesn't)... however, here's how it will work:
-If the converter reduces a line to a single character, and that character is not a token, an error message appears in a dialog box.
-The program then writes a question-mark token (not one of the unused tokens, the actual AFh question mark) in place of that character.
This is necessary because otherwise the program will enter an infinite loop, trying to break down the one-character line further.
-
Wow, this is coming along great, I cant wait till christmas when I get a 68K calc, wanna tell me which would be the best to have?
-
Wow, this is coming along great, I cant wait till christmas when I get a 68K calc, wanna tell me which would be the best to have?
Well, if you want to use the calculator on standardized tests, a TI-89 Titanium. True, there are compatibility problems with older programs but most of those have been solved.
I think the Voyage 200 is pretty cool, but it's blocked on standardized tests, which was one reason why I didn't get one.
Then the TI-89, TI-92, and TI-92+ I don't think are sold anymore, and they're outdated and have less memory-getting the 89 and 92+ would be like getting an 83+ instead of an 84+(SE). But I wouldn't recommend the 92 even if you could get it, because TIGCC/GCC4TI doesn't compile for it and it doesn't have built-in assembly support like all the other 68k calcs.
-
I second TC01, the 89T is clearly the best choice if you want to use your calculator on standardized tests.
The 92(II) suffers from lower math capabilities, a lower amount of memory, and much less advanced assembly programming (albeit possible with Fargo and TIGCC/GCC4TI) due to fewer functions and most of all, the lack of a jump table, which translates to a low count of assembly programs (compared to that of the rest of the TI-68k family). Just don't buy a 92.
-
And multi-line programs, and multi-token lines both work now, as you can see from the Hello World program I've tokenized and loaded into WabbitEmu.
I'm still not sure if error checking is working properly- I'll need to look at that.
The entire process of initializing the one-byte tokens, then tokenizing Hello World, takes five seconds. For small programs that's okay but once I add the two-byte tokens it might become problematic.
-
I have attached v0.1, an alpha and testing version, since everything seems to be working (even though there are only one-byte tokens supported at the moment).
If you use it on a real calculator, I highly recommend doing a backup and then installing a crash protection program (either PreOS or KerNO) if you don't use one already, simply because even though it seems to work perfectly, there's always the chance of a bug that I missed.
I have provided a demo that you can try tokenizing (the same program in the screenshot above). There's documentation on what exactly to do with all of the programs included (in the various readme files), and once you get everything setup I recommend trying the demo (since I know it should work).
I'd like people with a Voyage 200 or TI-92 Plus to try it on those calculators, to see if it works- I have versions provided for them but I obviously can't test them. You can also try testing other calculator models- the only one that definitely won't work is the 85 since BinPac8x makes strings, not program files for it. (And the 86 probably uses different token codes than the 82, 83, and 84+).
[Attachment removed- outdated version].
-
I'm glad this is still progressing. Also I renamed your topic per your request
-
Two more updates.
First, two-byte tokens now work! I've only tested (and added) the matrix tokens, but they tokenize fine. I did have a bug involving any token with a 00 byte, but with TravisE's help I fixed it. Now I can start adding the other user variable tokens.
Second, I've added a new feature (of a sort): the ability to run this program by passing it three arguments instead of from the dialog box. This might not sound too useful, but I did it because it would allow you to call this program from a 68k BASIC program, allowing you to quickly retokenize a program that you are editing without needing to fill in the dialog again (something that has annoyed me in my testing).
It also doesn't break the dialog- if you do not have three arguments to the program, the dialog box appears instead.
Also, I can see that a few people have downloaded the alpha I uploaded... if you have, has it worked? Any bugs to report?
-
Nice, I like the running of the program with 3 arguments. I personally tend to dislike filling multiple forms and stuff and I find the 68k ones to be a bit annoying to fill.
Sadly I did not have time to test yet, though, hopefully I might next week.
-
Another update: all user variable tokens and statistics tokens are now supported.
Unfortunately, I've discovered a bug- if you have more than 15 tokens on a line, the program freezes after execution. (I assume this occurs with the currently posted version too). Tested only in TiEmu thus far, but I'd guess it happens on-calc as well.
I'm not sure why, or even what kind of problems could cause this, but I'll fix it before I release 0.2.
-
Weird, I hope you can manage to fix it x.x
Btw, will you support some of the hard to reach ASCII tokens? In Illusiat 13, for example, I use the Omega symbol, the arrow before the Frac command but alone, the $ symbol, etc.
-
Weird, I hope you can manage to fix it x.x
Me too. ;) No luck so far though.
EDIT: That was rather ironic. I fixed it just after I posted that I was having no luck with it! ;D The problem was pretty simple- I wasn't allocating enough memory to the array containing the tokenized line. Or, rather, there was enough for the line itself... but not enough for the hard return token afterwards too.
So I was overwriting some memory on the calculator, hence a corrupt heap (what I got when I installed KerNO on TiEmu).
Btw, will you support some of the hard to reach ASCII tokens? In Illusiat 13, for example, I use the Omega symbol, the arrow before the Frac command but alone, the $ symbol, etc.
I'll support them- as long as their hex codes are documented somewhere (otherwise, of course, I can't support them).
-
Beta v0.2 has been released! I've uploaded it to the Cemetech Archives here (http://www.cemetech.net/programs/index.php?mode=file&path=/89/asm/Solar89_SDK.zip) (since I prefer uploading to a downloads database than just attaching to a post, and also because I don't want to post it on ticalc.org until I'm sure it's bugfree).
In addition to the new tokens, the bugfix, and the argument-passing, here are the other changes:
-I modified BinPac8x to make *.85p files (changed the file and variable type)
-I added some error handling code in make8xp; it prints a message explaining that the file path and/or name is incorrect and then waits for a keypress, rather than just printing the Python exception and exiting (especially important if running by double-clicking rather than the command-line).
-I fixed another bug where all tokens starting with a space ended up with an extra space at the front of the name
-
I think their ASCII code is available in ASM in 28 days near the end.
Nice to see new updates ^^ I also like how you can do programs for multiple calc models. It should make porting much easier.
Also we're soon gonna have a downloads section too so you're gonna be able to upload your stuff there too :)
-
I think their ASCII code is available in ASM in 28 days near the end.
Nice to see new updates ^^ I also like how you can do programs for multiple calc models. It should make porting much easier.
Also we're soon gonna have a downloads section too so you're gonna be able to upload your stuff there too :)
Ah- found it. But it's not the ASCII code I need, it's the token code I need. The two are different. (ASCII characters are used as part of tokens, and some are tokens, but their codes won't necessarily match up).
And yeah, I'm looking forward to the Omnimaga downloads section. I'm also going to upload it to ticalc.org, of course, but I wanted to wait for that until I had all the 83+ tokens supported and there were no obvious bugs (but for that, I need other people to test it).
-
Ah ok I see. I'm not sure how to help, then :( (I'm not tech savy when it comes to that stuff)
-
Well, the Omega symbol, the $ symbol, and probably others of those hard-to-reach tokens are all documented on the Misc Tokens (http://tibasicdev.wikidot.com/miscellaneous-tokens) page on TI|BD.
I can't seem to find the arrow there, though. So if you want to help, you could put that token in a program, maybe format it like this (_ = the token):
:ARROW
:_
And then just send it to a computer and upload it. Using a hex editor, I could look at it to see what the token code is.
I could do this myself if I had a z80 with a working link port, but even then I don't know how to access that token, so...
-
After some time (during which I've been busy, primarily with getting back to school...), another update. Window, finance, and graph format tokens have now been added. I just need to add the miscellaneous and the TI-84+ tokens (again, as defined by TI|BD (http://tibasicdev.wikidot.com/tokens), and then I'll release 0.3, which I plan on posting on ticalc.org as well.
Unfortunately, with such a large token file, the program will continue to get slower, which is why my goal for the version after that is to perform some optimizations. Slowness will be a result of three things:
-Parsing the token file (dependent on size of token file)
-My reverse-substring process to parse the input file (not dependent on token file size)
-Searching for a token in the collection of token infos (dependent on token file size).
I know I can make the first somewhat faster. The other two probably can be made faster, but I lack the knowledge to do it.
I've also decided I would like to eventually have the option to detokenize, to convert an *.8xp file into an *.89z file that can then be detokenized on the calculator. That gave me the idea for another project... with the assistance of X-Link and a z80 assembly program on the other end, it would become possible to use a 68k calculator to transfer z80 programs around! I don't think anything like this already exists- X-Link is the closest to it that I know of.
-
ok, it is official
this is really pushing me to get a TI-89T
you rock
(is Solar interprited or compiled?)
-
I like the ideas you got. It would be nice with the help of X-Link if there was a converter. Would the converter be on the 89 or the 83+? In the later case, would it have to be something in Axe/ASM?
I'm glad this is still progressing, btw :)
-
ok, it is official
this is really pushing me to get a TI-89T
you rock
(is Solar interprited or compiled?)
It's written in 68k C, so it's compiled.
I like the ideas you got. It would be nice with the help of X-Link if there was a converter. Would the converter be on the 89 or the 83+? In the later case, would it have to be something in Axe/ASM?
I'm glad this is still progressing, btw :)
Well, the converter from X-Link appvar to 83+ program would have to be on the 83+ because of the way X-Link works, and it would have to be either in Axe or Assembly.
-
Well, due to the ability of Axe to manipulate data in memory, I guess it could very be possible to convert the 89 file to 83+ program format in Axe. Otherwise, ASM is another good option since it allows even more freedom
-
I've uploaded 0.21 to Cemetech and ticalc.org (will add it to Omnimaga once the database is fully operational!). This does not add the miscellaneous or the TI-84+ only tokens yet... I really didn't feel like doing that. And I realized that it made no sense to keep bloating the size of the token file before I did some optimizations, otherwise things would get really slow. I just wanted to release a version on ticalc.org, and decided to include what I had so far.
Won't be able to download until it goes through, of course, so attached is a zipped copy.
-
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?
-
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. :P
EDIT: Cemetech download up now.
-
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.
-
nice update! In the VAR-LINK menu will the 85P part be .85P at the end of the program or just be part of the file name, not the extension? I'm glad this is still progressing :)
I wonder if this will make it much easier to port games accross calcs?
-
nice update! In the VAR-LINK menu will the 85P part be .85P at the end of the program or just be part of the file name, not the extension? I'm glad this is still progressing :)
I wonder if this will make it much easier to port games accross calcs?
It will be the text in the second column- that says ASM, PRGM, TEXT, EXPR, STR, MATR, etc. I'm calling that the extension- not sure exactly what the technical term is.
Porting eventually might become easier using Solar89, but I'll need to write some other tools first (like an on-calc detokenizer and an on-comp 8xp-89y converter, not to mention a complete set of token files).
-
Ah ok, I guess it would be the extension then, or file type.
-
I've gotten the file type/extension (whatever you want to call it) implemented. This is only a feature if you're using a compiled token file- otherwise, all files will be given the 8XP file type by default.
I've also added code to automatically archive the resultant files- both for my token compiler (on calc-name is maketok) and Solar89 itself.
I added whitespace support, so Solar89 will automatically discard all extra spaces in front of lines. It won't replace them with : characters or anything like that (that's a way to waste memory)- it just trims them out at the start.
I'm also trying to get empty lines supported, but I'm having some weird issues with that. If the line is at the top of the program, it works fine. If it's in the middle, between two other lines of code, tokenization takes much longer than usual and then it hangs. And if it's at the end, the program runs as normal but the lines at the end don't appear for some reason.
The last problem isn't a huge one (because Solar89 already inserts an extra newline character at the end of the each program), but the first problem definitely is.
-
Nice to see more progress :)
Btw on the 83+,
Disp A:Pause
is the same size as
Disp A
Pause
So : doesn't take more space as it is the equivalent of a linebreak.
Good luck fixing your empty lines issue x.x
-
I know that, what I meant is if I was using whitespace like this in the text file:
: ClrHome
: Disp "HELLO WORLD"
Then I could either parse it as this:
::ClrHome
::Disp "HELLO WORLD"
Or as this, and save two bytes:
:ClrHome
:Disp "HELLO WORLD"
-
Oh I see. I would just parse it as the latter. Was it what caused you issues?
-
Oh I see. I would just parse it as the latter. Was it what caused you issues?
Nope, what caused issues would be this:
:ClrHome
:
:Disp "HELLO WORLD"
I've fixed it- partially. Now two empty lines are produced in between instead of one.
-
Ah ok. Well, good luck x.x
-
I've fixed the bug. And I've released 0.3, with versions uploaded to ticalc.org, Cemetech, and Omnimaga. Can't download until they're approved, though.
The full list of changes are:
-Support for binary token files (with included program- maketok- to make them)
-Support for whitespace in text files
-Bugfix where empty lines in the middle of a program caused infinite loop
-Solar89 and maketok auto-archive output files
-
Nice!
I'm gonna head into the pending queue soon :)
-
Just a few brief updates.
First thing, I made a minor interface change- the tokenizer now outputs each line of the file to the status bar as it runs. I made this mainly to convince the user that the calc hasn't frozen- it's actually doing something. (Since tokenizing can take some time).
Second, I recently wrote another example- a quadratic solver. :P Just as an example as a slightly longer program (and how much time a mathematical program might be expected to take).
Third, I talked with thepenguin77 earlier today about making a better tokenizing algorithm- a tree based system- to increase speed. I plan to code that when I have the time (unfortunately, not now).
-
Nice, any screenshot?
-
Nice, any screenshot?
Here are two- one of my quadratic solver in the text editor, and one of the Disp "HELLO WORLD" status message (as Solar89 tokenizes a hello world program).
-
Ah cool. I am confused at the Hello world message, though. I assume it shows the lines of code in the status bar as it compiles? I wonder if it would be too slow for large programs, since Text routines are generally slow?
-
Ah cool. I am confused at the Hello world message, though. I assume it shows the lines of code in the status bar as it compiles? I wonder if it would be too slow for large programs, since Text routines are generally slow?
Right, that's what it's doing.
It's not noticeably slower with that turned on. But if it becomes a problem once the tokenizer itself is made faster, I could make it an option or something.
-
AH ok, because in Axe Parser, compiling refreshed the % every byte or so, and it was like 4 times slower than it is, now. TI's text routines aren't known to be fast, although on 68K calcs this might not be as bad, but on the 83+, several ASM and Axe coders prefer to use their own font routines using sprites to save speed.