Post by: bfr on September 16, 2006, 06:08:00 am
EDIT: I decided to post a summary of the progress here
Progress:
Parsers: 3/5
Commands: 1/20
Variables/VAT: 2/5
Plan (note that the order may change, some steps may be combined and intertwined, etc.):
- Finish parsers and VATs; will take *some* time
- Add many commands; will take *some* time
- Talk to programmers of MLC for Casio calculators, and try to fix any incompatibilities; won't take too long
- Beta testing and optimization;
-- Release MLC 68K 1 -> Hopefully by the end of the summer of 2007, maybe sooner or later
- Finish the MLC converter; will take quite a while
- Finish MLC sprite and tile-map editor; will take a while
- Work on an editor for MLC 68K 2; will also take a while
- Slightly change the parsing of MLC commands to work with editor, thus creating smaller and faster programs; won't take very long
- Possibly make new commands...any suggestions?
-- Release MLC 68K 2 -> Hopefully by end of the summer of 2008, maybe later
Post by: Liazon on September 16, 2006, 07:15:00 am
It should probably act like a parser like xlib.
Post by: DJ Omnimaga on September 16, 2006, 07:55:00 am
Post by: Demon on September 16, 2006, 08:11:00 am
| QUOTE |
| I think what you need is to design MLC 68k to be like PreOS and HW3_Patch, I forget the term, but it means that it's a program that's kind of always running in the background. |
TSR (Terminate and Stay Resident), I think, is the word you may be looking for - correct me if I'm wrong.
Post by: Liazon on September 16, 2006, 12:24:00 pm
Do 68k flash apps still need to be sent to TI in order to be signed, or did they release the app signer? Kevin Kofler told me that TIGCC does not support apps though.
Post by: DJ Omnimaga on September 17, 2006, 02:25:00 am
Post by: bfr on September 22, 2006, 12:25:00 pm
QuoteBegin-Liazon+-->
| QUOTE (Liazon) |
perhaps require a special MLC heading so that MLC games can still be made with the basic editor. MLC will have to search for basic programs with these headers. This alone may be enough |
Actually, there is already a special header (which is "MLC:", without the quotes). Also, at the moment, the user can edit MLC programs in the text editor or the TI-BASIC editor. But I might end up choosing one or the other. What would you all prefer? The text editor or the TI-BASIC editor?
Post by: Liazon on September 23, 2006, 03:05:00 am
Post by: bfr on September 23, 2006, 05:33:00 am
Post by: bfr on September 23, 2006, 09:41:00 am
Here is a screenshot:
Right now, the only way to run an MLC program is as an argument. I'll work on the other stuff later, such as letting MLC programs be selected from a list and ran.
Post by: Liazon on September 23, 2006, 12:02:00 pm
Post by: bfr on September 23, 2006, 02:10:00 pm
| QUOTE (elfprince13) |
@bfr: contact me if you need help with a parser. I can't code the routines to handle the commands, but I can help with some basic stuff like the parsing itself and probably control structures. |
I've come to that part. All MLC commands are prefixed with "#", and probably for a reason They probably tell the parser the difference between a command and a variable. So, I guess the parse should check for "#" first, and then if it encouters it, then it should compare it to a list of commands or something, or else, treat it as a variable or something. Hmmm...variables will be interesting. I'll have to make my own variable-allocation table or something...or ues TI-BASIC variables, which might be slower to access.
Post by: DJ Omnimaga on September 23, 2006, 04:17:00 pm
Post by: bfr on September 23, 2006, 04:34:00 pm
EDIT: This is starting to get a bit off-topic of MLC 68K, but I guess it's fine if we get back on topic soon.....
Post by: Ranman on September 23, 2006, 04:42:00 pm
If you go with the text editor, then you may not have any limitations.
Post by: tifreak on September 23, 2006, 04:57:00 pm
http://www.ticalc.org/archives/files/fileinfo/384/38404.html
It just might require that program to access alot of different characters :)
Post by: DJ Omnimaga on September 24, 2006, 02:44:00 am
thx for the link
Post by: bfr on September 24, 2006, 01:06:00 pm
QuoteBegin-Ranman+23 Sep, 2006, 22:42-->
| QUOTE (Ranman @ 23 Sep, 2006, 22:42) |
| The TI BASIC editor may impose other limitations too -- I don't know. If you go with the text editor, then you may not have any limitations. |
I think xlibman meant that the TI-83+ version of MLC can't edit access #$%&@, and there isn't a builit-in (not preinstalled application) for it anyway, at least to my limited knowledge of the TI-83+. Or am I the one misunderstanding something...hmmm... o.o
Post by: DJ Omnimaga on September 27, 2006, 01:25:00 am
Post by: Alex on October 06, 2006, 12:33:00 pm
- Alex
Post by: bfr on November 03, 2006, 02:47:00 pm
. The command is...CLRS. It clears the screen. :P
Also, elfprince13, I think you were offering help with the parser, so, I'm working on the parser now, just so you know.
EDIT: Added two commands - PAUS and DRAW. Commands may also begin with "#" (for compatibility with other versions of MLC) or "|" (for easy access on 68K calculators, but no compatibility. Maybe in the converter, I could make it convert "|" into "#"). PAUS obviously pauses the program, waiting for any key press, not just enter. DRAW updates the screen, because all drawing commands are drawn to hidden buffers. This makes MLC programs automatically double-buffered :)
EDIT AGAIN: Added another command - HALT. It stops execution of the program.
Post by: bfr on November 05, 2006, 06:05:00 am
#STOP mybuffer
Note that the name can only be up tp 8 characters. This command also doesn't use a complex string parser or anything - it just uses the all of the characters up to a newline or whitespace character, and the maximum is 8. The maximum amount of pictures that one can have is 5, but I can increase that (or decrease that) if you all feel that more (or less) are needed. I'm probably going to increase that amount.
This can be compared to: StorePic 1 in TI-BASIC on the TI-83+, or StoPic mybuffer in TI-BASIC on 68K calculators. The MLC version is better though because it's faster, supports grayscale pictures, and the names don't have to be numbers (on 68K calculators, the names don't have to be numbers either, but...).
EDIT: It's still buggy though, because after running a test MLC programs a few times, the calculator froze.
EDIT AGAIN: It's bug-free! :)
Post by: Liazon on November 05, 2006, 07:09:00 am
Post by: bfr on November 05, 2006, 12:43:00 pm
. Maybe it should be changed to "SPIC", but then it wouldn't be compatible with the current version of MLC 86 and MLC Casio AFX. Now that I've got STOP working, time to get working on the next command: RCLP. I also need to make a good expession parser and a good variable system.
Post by: tifreak on November 05, 2006, 01:25:00 pm
Curious though... this is supposed to be cross platform compatible... Even though they will still have to include all the programs for each calc in the zip, since you cannot send a .83p to an .86p and expect it to work...
Post by: bfr on November 05, 2006, 02:39:00 pm
I added RCLP, which is like RecallPic in TI-BASIC for the TI-83+ (I think it's RecallPic, isn't it?). RCLP didn't take much work because I basically copied the code from STOP and slightly modified it.
I'm going to try to get a screenshot up of a demo MLC program. It's going to use a command called AAAA which really isn't an MLC command, but it'll be there just for the demo. It just writes some zeros and stuff on the screen. When I finish the TEXT command though, it won't be needed.
EDIT: Here's a screenshot:
Post by: Alex on November 05, 2006, 05:27:00 pm
- Alex
Post by: necro on November 06, 2006, 04:39:00 am
Post by: Alex on November 06, 2006, 09:55:00 am
- Alex
Post by: bfr on November 06, 2006, 04:15:00 pm
necro: I honestly am not really sure. I just kind of work on what I feel like working on, but sometimes certain things have to come before others. I plan to add a few more simple commands this weekend, and maybe add sprites in a few weeks. Sorry, I don't have much time to work on MLC Monday through Thursday, and my time on the weekend is limited. But, I should have some other (simpler) graphics-related (and non-graphics-related) commands ready soon. I also plan to add tilemapping, but that will definitely come much later, if I even incorperate it at all.
Post by: Liazon on November 06, 2006, 04:57:00 pm
most of us are also busy a lot, so don't worry.
Post by: bfr on November 18, 2006, 08:08:00 am
Post by: DJ Omnimaga on November 18, 2006, 08:27:00 am
Post by: bfr on November 18, 2006, 10:21:00 am
Post by: DJ Omnimaga on November 25, 2006, 07:59:00 am
Post by: Liazon on November 25, 2006, 01:06:00 pm
I'm just throwing ideas out. So far things look awesome.
Post by: bfr on November 25, 2006, 01:30:00 pm
Post by: bfr on December 09, 2006, 06:38:00 am
. It's going to be done hopefully sometime between this Sunday and the end of Christmas break. I've never really written a mathematical expression parser before, so I don't really know how long it will take.
Post by: bfr on December 11, 2006, 02:58:00 pm
Post by: necro on December 11, 2006, 07:34:00 pm
Post by: DJ Omnimaga on December 12, 2006, 03:06:00 am
Post by: necro on December 12, 2006, 06:31:00 am
Post by: bfr on December 12, 2006, 11:46:00 am
And how does it parser files? Well, don't try this with computer C, but I'm using low-level http://tigcc.ticalc.org/doc/vat.html. I'm using those routines as opposed to http://tigcc.ticalc.org/doc/stdio.html, because it allows for smaller and faster programs. With the higher-level ANSI-compatible routines, one could merely do:
FILE* file = fopen("myfile","w"); // w for write mode
By using routines from vat.h, it's a tiny bit more complicated. Besides, to me at least, it is more fun to use the vat.h routines. :P
Post by: DJ Omnimaga on December 13, 2006, 02:46:00 am
Basically this use 4 truncated road pics and two lists (L2 and L3), and depending of if the list element is a turn or coast it display a different road sprite where it's supposed to display. However sprite size keep varying in height, depending of if you are in a coast or not. I was wondering if such program could be done in MLC?
EDIT: that thing is written in BASIC+xLIB btw, don't wonder why it isn't too smooth
Post by: Liazon on December 13, 2006, 10:19:00 am
Post by: bfr on December 13, 2006, 10:51:00 am
Post by: tenniskid493 on December 13, 2006, 05:44:00 pm
Post by: DJ Omnimaga on December 14, 2006, 01:45:00 pm
Post by: bfr on December 15, 2006, 11:33:00 am
Until winter break for me starts (which will be 3 days before Chirstmas or something like that), progress on MLC will most likely be slow.
Post by: Liazon on December 15, 2006, 11:57:00 am
x.x as for me, it's still a week before break and I've already got more school work due the day after than I can chew. x.x
Post by: DJ Omnimaga on December 15, 2006, 02:02:00 pm
Post by: bfr on December 22, 2006, 11:12:00 am
Post by: elfprince13 on December 22, 2006, 01:17:00 pm
Post by: bfr on December 22, 2006, 01:20:00 pm
Could you teach me your method?
Post by: elfprince13 on December 22, 2006, 02:10:00 pm
if not you should go read up on it. otherwise here's some fairly easy to translate java code for it (assuming you have floating point capability.....if you dont care about the decimals it should work anyway.)
c1-->
| CODE |
| ec1public static double sqrt(double value){ Post by: DJ Omnimaga on December 22, 2006, 04:01:00 pm Post by: bfr on December 23, 2006, 02:14:00 pm I've added full support for integers and floating-point numbers. Both of their ranges are huge and accessing them and storing values to them is really fast. The range for floating-point numbers is 1e-999 to 9.999999999999999e999 the value for integers is -2147483648 to 2147483647. These ranges should be more than enough. :) The next variable types I'm going to add with the new VAT system are probably going to be "pictures" and strings. EDIT: I've come up with an idea, which I think is pretty awesome. I'm going to allow MLC programs to manipulate the VATs in all sorts of awesome ways, to allow the VAT to act as an array, and to allow pseudo-pointers and all sorts of crazy stuff (there will be normal arrays and regular pointers to be backwards-compatible with MLC 86). Here's some pseudo-code to demonstrate what I mean (kind of a combination of C and MLC and a made-up language :P ):%int=534 // First VAT item %int2=745 // Second VAT item IntVatItem(1).name="int2" // Change first VAT item's name to int2 IntVatItem(2).name="int" // Change first VAT item's name to int %int3=55555; // Make third VAT item // Time to use the VAT as an array for(%a=0;%a<3;%a++){ IntVatItem(%a).value=%a if(IntVatItem(%a).name="int2"){ display("Name is int2") } } Post by: bfr on December 29, 2006, 07:04:00 am http://bfr.tifreakware.net/cgi-bin/mlc.cgi (My new website is at http://bfr.tifreakware.net) Post by: DJ Omnimaga on December 31, 2006, 09:25:00 am Post by: elfprince13 on December 31, 2006, 01:27:00 pm just a fun new language. anyway, awesome work, do you have any sort of functional demo?
Post by: DJ Omnimaga on December 31, 2006, 01:59:00 pm Post by: Halifax on December 31, 2006, 09:05:00 pm Post by: Liazon on January 01, 2007, 03:11:00 am Post by: bfr on January 17, 2007, 12:34:00 pm Would you all be interested in a demo? I've got finals coming up soon, but if you would like, I could release a demo of MLC within a few weeks. Also, I'm trying to keep MLC 68K backwards-compatible with MLC for the TI-86, but I'm not sure if it's going to be completely compatible with MLC for the Casio AFX, unfortunately, because there was little communication between the one programming MLC for the Casio AFX. The MLC converter will take care of any minor incompatibilities though between MLC 68K and MLC for the TI-86 (and hopefully for the TI-83+, some time), such as changing "|" to indicate a command, supported by MLC 68K but not MLC for the TI-86, to a "#" to indicate a command. I might just have the converter generate errors or warnings for major incompatibilities, such as advanced VAT manipulation. Hopefully, even if MLC 68K and MLC Casio AFX are completed independently, I can let the MLC converter handle any incompatibilities. Post by: DJ Omnimaga on January 17, 2007, 02:07:00 pm Post by: bfr on January 17, 2007, 02:20:00 pm Once I complete all of these parsers and VATs (which could take anywhere from probably a couple weeks to maybe a month or so), though, then loads of new commands are going to be implemented, including graphics/sprites/tile-mapping commands, which is going to be a good thing to take screenshots of.
Post by: DJ Omnimaga on January 17, 2007, 03:07:00 pm 
Post by: lachprog on January 18, 2007, 08:15:00 am I'm looking forward to be able to program in this! And btw, a demo would be nice ;)
Post by: DJ Omnimaga on January 18, 2007, 01:09:00 pm (now i should remember to check mario 68k progress more often as well %)  )
Post by: bfr on April 04, 2007, 09:27:00 am Anyway, after not working on MLC 68K in months, and having a lot of time due to Spring Break, I decided to work on it. The code was really disorganized (because things were in the middle of being changed from the static VAT to the dynamic VAT, and because I also just have a bad habit of coding things in a disorganized way) and hard to make sense out of, especially after not doing much C for a while, and there were routines that were partially finished which I didn't really know where I left off, so I've just created a new TIGCC project file (this is not really a new project...just a different file) for an organized rewrite. Basically the only things that I don't need to rewrite are the initial MLC program detection/checking for the "MLC:" header, and the mathematical expression parser (the string parser was supposed to be easier, yet I never finished it...). I'll hopefully have a cool screenshot (or even demo, but probably not) to show to you all by this Saturday, but if not, then the next progress on MLC might occur as late as in May or June, due to a really intense forth quarter history project and other things.... Post by: Madskillz on April 07, 2007, 04:16:00 pm Post by: bfr on April 07, 2007, 04:48:00 pm I seriously would be really upset with myself if I don't finish MLC within a year (it will hopefully be done by the end of this summer), and there should be a demo probably whenever after I get sprites or something cool like that finished (which might be sometime around June or July). I could release a demo now, but stuff like pausing and clearing the screen and declaring variables isn't that exciting. I'm not really going to be able to work on MLC much the rest of this school year, particularly during the next few weeks, because I have a lot of work - mainly a dreadful forth quarter history project in which I must prepare a varied lesson plan for a few weeks for a unit and then present, in front of the class, a portion of it. Post by: bfr on April 18, 2007, 12:44:00 pm ). Anyway, I made some progress on the string parser and the declaration of strings. At the moment, the string parser can parse literal strings, which wasn't really complicated to code, and strings can be declaraed. What still needs to be done? The string parser can't parse variables that are strings yet, and the values of strings that are already declared can't be changed. Both of these things should be fixed by the end of this weekend.Here's a screenshot:  The weird stuff being displayed is temporary debugging stuff that shows that it is working, and the error that occurs at the end is because I didn't make the program counter update by the proper amount after declaring a string (which should be fixed by this weekend). Post by: Insanity on April 18, 2007, 12:47:00 pm Post by: Liazon on April 19, 2007, 04:32:00 am good work bfr! Post by: graywolf on April 19, 2007, 11:01:00 am And 89t might support usb68k in the future ;) (for game storage :P).
Post by: bfr on April 21, 2007, 12:07:00 pm And I just finally finished stuff with strings! Meaning that the string parser is finally complete, and strings can be declared and their values can be manipulated. :) This also means that more commands are going to be on their way that use strings and/or numbers for arguments, such as the "text" command.
Post by: Halifax on April 21, 2007, 12:44:00 pm Post by: bfr on April 21, 2007, 01:21:00 pm EDIT: I got part of the "text" command working. Its syntax is: text x,y,"String",color . I also am going to try to make it so that the string parser can convert numbers into strings. EDIT AGAIN: The text command almost completely works. Here is a screenshot:  ANOTHER EDIT: Grayscale text is now supported. B) 
Post by: graywolf on April 22, 2007, 10:30:00 am Post by: bfr on April 22, 2007, 11:10:00 am I've been kind of banned from programming though (my mom...) for two weeks (but I have a lot of homework then anyway), except I'm allowed some time on Friday, so don't expect much progress for until those two weeks are over :/  :( Post by: bfr on June 15, 2007, 05:30:00 am I have a question though - what should the tokenized program be? A text file? If so, then it would be editable (even if it is kind of unreadble) from the Text Editor. Or A custom file type? This would make it uneditable from any of TI's editing applications, and would allow for "closed-source" programs (although it wouldn't be too hard to make a detokenizer that converts the tokens in the custom file type back into readable code in a text file). EDIT: I might be able to make it so that users will be able to choose whether the tokenized program is stored in a text file or a custom file, but then I might have to modify some code in the MLC parser/shell.... Post by: bfr on December 27, 2007, 12:43:00 pm I worked on the MLC tokenizer for a few hours yesterday, and then for a few more hours today (after not working on it in months)...and now it's finished. What does it do? It converts human-readable MLC source code (stored in a TI-OS text file) into a more compact format (the custom MLC file type). This of course not only makes the resulting program smaller, but makes the MLC interpreter able to interpret it faster. While at the moment it's fully functional and supports tokenization of all of the MLC commands, I still could probably improve it a bit more to not only make the resulting tokenized programs be smaller, but the MLC tokenizer itself be smaller. Anyway, to give you an example of how much smaller it can make MLC programs, here are some sample inputs and outputs: Input: 30 bytes Output: 21 bytes Input: 51 bytes Output: 42 bytes UPDATE: I've actually found a bug when tokenization certain source files...I'll hopefully have it fixed soon EDIT: The bug is that for whatever reason, sometimes the calculator freezes with the BUSY indicator (TIGCC programmers here...what is this normally a sign of?) after tokenizing a file. Even if you don't know anything about TIGCC/C, any testing at all would be nice. You can download the latest version of the MLC tokenizer with the following links (Remember: The MLC tokenizer is still unstable and may damage your calculator, download at your own risk) http://bfr.tifreakware.net/miscarchives/mlc/mlctok.89z http://bfr.tifreakware.net/miscarchives/mlc/mlctok.9xz http://bfr.tifreakware.net/miscarchives/mlc/mlctok.v2z Note that the file type of the outputted program should be "MLC", and NOT "EXPR" or anything else. http://web.archive.org/web/20060710202041/http://dysfunction.earthforge.com/?p=mlc-readme.php lists some commands you can test with (don't worry about the arguments for the commands...anything, correct or not, should be able to be tokenized at the moment). You can also try typing in random text to see what happens. Anything with the "MLC:" header should get tokenized, otherwise, the tokenizer should return an error. Post by: DJ Omnimaga on December 27, 2007, 01:37:00 pm
Post by: Liazon on December 28, 2007, 04:55:00 pm |