Omnimaga
Calculator Community => Other Calc-Related Projects and Ideas => TI Z80 => Topic started by: Xeda112358 on November 11, 2010, 10:53:52 pm
-
I have already unveiled this project on TIBD and I am liking it enough to post it here. I started this back near the end of June, but after a few days I finally came across something called Axe Parser. I thought Axe was pretty cool and was pretty far along compared to my start of a programming language, so I put it aside. Then I started thinking. Axe doesn't actually execute the code it compiles, which is what mine did. Mine was an interpreted language whereas Axe actually compiled it into an assembly program. Axe has the advantage of speed and the fact that it is pretty far along in development, whereas mine has the advantage of using less memory. I just checked my computer yesterday and it seems that I have deleted everything except one random file which detailed the first few commands. Today I started over and I made the basic outline of the program and I made the Pause command. The Pause in my original program was very similar to the one in Axe and I did not change that.
And for those who are curious, yes it is in hex at the moment. I have got two small calls in their mnemonic form, I will work on the rest when I have time (so right now).
prgmA is the program
prgmB is the example use (not really much of an example)
-
Seems interesting. What is going to be the focus for this language (like Axe is game oriented)? Or what is it going to look like? It seems interesting though, can't wait to see what this becomes :)
-
This sounds similar to stuff like xlib, am I right?
-
I think it's going to be more like Axe where it's an actual language.
-
Sorry I am late to getting back to y'all, I am having to fix the charger on my computer, but yes, it will be an actual language instead of a library.
-
coolio!
what about support for the calling of asm/axe progs? if so and this turns out well it could act as a replacement for basic+libs entirely/save people a lot of space who would otherwise be writing pure asm/axe.
-
Also, couple questions. Are you going to eventually make this an app or are you going to keep it as a program? Also, how fast will it be?
-
Will this be open source (or alternatively, will you make the source available)?
-
Interesting. Just make sure to start with the small stuff first then the larger stuff afterward and try to make sure the interpreter is not too large. Seems interesting. One thing I like with BASIC is that code is smaller than Axe, but data is ridiculously large.
-
Again, sorry to be late responding.
-I can throw in the ability to call assembly programs, but for now only up to 768 byte of code.
-I plan to make it an app, but for now it is a program. It takes a short time opening the asm program (like all asm programs), but while it is actually interpreting the code, it is just as fast as assembly (because it is). If I made a command equivalent to an OS command, it would be faster.
-For now, the source is in hex (because that is how I am programming), but I am slowly converting it to mnemonics when I get the chance.
-I definitely plan to start small and then I will build my way up. I think I will wait to add crazy things like labels and jumps and calls.
Actually, I just thought of this with that last one... I think I am going to make calls end with "End" and the code end with "Stop" because I only need to change one byte of the code for that.
-
Again, sorry to be late responding.
-I can throw in the ability to call assembly programs, but for now only up to 768 byte of code.
-I plan to make it an app, but for now it is a program. It takes a short time opening the asm program (like all asm programs), but while it is actually interpreting the code, it is just as fast as assembly (because it is). If I made a command equivalent to an OS command, it would be faster.
-For now, the source is in hex (because that is how I am programming), but I am slowly converting it to mnemonics when I get the chance.
-I definitely plan to start small and then I will build my way up. I think I will wait to add crazy things like labels and jumps and calls.
Actually, I just thought of this with that last one... I think I am going to make calls end with "End" and the code end with "Stop" because I only need to change one byte of the code for that.
YAY coding in Hex is super hard, you are one of the few who can make games and stuff using HEX 100%, though.
-
I think there is a small bug when dealing with commas. I am going to test it (I think I just need a Inc HL), so the Disp x,y,<<String>> idea I had isn't working for me. But, I have made it so that you can store numbers to Ans! ...Which isn't very useful, yet. It would be better if I could make use of Ans instead... Anyway, I am not going to upload it yet, but after I get a few more commands in, I will. I was working on it during Calc, so I didn't get very far.
-
This sounds really interesting. And also, you write asm in hex? That's awesome! I'm an unbelievably huge noob at asm so I'm wondering how would one go about doing that?
-
well, I learned BASIC first, so if you need any help I can try to give the BASIC or English behind assembly :D I started playing with Celtic 3 and modifying data before I really figured it all out.
-
Wow, you program Assembly in hex? That is seriously badass! :D How many programmers can say they program practically in binary ^^
-
Indeed. I guess the only downside can be if he needs ASM help, few people can help, but otherwise that's kinda cool.
Unfortunately I won't have much time to try the program yet, I'll still be looking forward for updates, though. :)
-
Speaking of updates... I put together a spread sheet (It uses OpenOffice) that has been a real help with my programming. It pretty much eliminates the need to calculate addresses. For that reason, I have optimized the code a bit, but there really are still only two things it can do at the moment.
-
Interesting stuff, although I don't understand much in the spreadsheet yet D:
-
yeah, my only goal in the spread sheet was to make it take all of my code and put it all together. It was designed for my uses, but anybody is welcome to use it.
Column A is the name
Column B is the size of the code in bytes
Column C is 1 if it is to be included in the final code, 0 if not
Column D converts Column B to hex
Column E is the start address of the code
Column F is the hex code
Column G is whatever F is if C is 1
Column H is all of the code in column G
Column I is the address as it is used in hex (1234→3412)
Column J is the length of the hex code (uses !!! if it doesn't match B)
Column K is the cumulative size of the code to be used
-
Okay, I have a new update... I have finally added the Disp command to the list. Apparently I didn't have a bug, but I guess it is always safer to be, well, safe. Also, I forgot to mention that I have not compressed the program. I will start doing that after the next command, though.
The next command I plan to use Line(a,b,x,y,t where it makes rectangles. For now I am going to use the OS routines, but I think I will make my own routines at another date.
-
Okay, I have a new update... I have finally added the Disp command to the list. Apparently I didn't have a bug, but I guess it is always safer to be, well, safe. Also, I forgot to mention that I have not compressed the program. I will start doing that after the next command, though.
The next command I plan to use Line(a,b,x,y,t where it makes rectangles. For now I am going to use the OS routines, but I think I will make my own routines at another date.
Sounds good! Definetely make your own routines! This seems pretty useful to be one of the libraries for KOS, by eliminating any TIOS routines it should be KOS compatible already (albeit you should inform Sir about that...)
-
Well I am going to eliminate OS routines later. For now, I am just making it so that I have an outline, but that might be cool...
-
Okay, my latest update now has the Line( command which is used to draw rectangles. I actually made the example program prgmB do something this time and I have the compressed version of the program called prgmRECODE.
At the moment, you can comment on your code without a problem unless you use commands. The problem is, every byte gets read by the interpreter and this can slow down your code. I was thinking about using "." to start a comment and have it skip to the next line to save speed, but if anybody has a better idea for starting a comment, I can easily change it.
Also, the example program has a pause just about every other line, so it isn't slow, it's just taking a pause so you can actually read the words :D
Finally, this is as far as my original version got. Now I get to be a little more inventive. I am going to take it slow and easy, but if there are any ideas, I would be happy to read them. I do not plan to do anything major like a tile-mapping routine yet, but simpler things are okay.
-
nice!
however, could it be possible to change the Disp command? having Disp X,Y where X is a row 0-7 and Y a column 0-15 is confusing, since X usually increases as you go horizontally to the right, not vertically downwards.
-
Oh, yeah, sorry about that. I was just using variables, not coordinate logic. Should I just change the order to Disp Y,X or do you want the code changed (it is only 2 bytes to change)?
-
Okay, so this version has no new commands, but it does have a new feature that will soon allow for math functions and vars to be implemented. At the moment, you can now optimize some codes by using commands as functions. This means that something like this:
Line(5,17,8,Pause 33,23
is the same as:
Pause 33
Line(5,17,8,33,23
Commands will run a few millionths of a second slower, but It will be quite worth it :D
-
Does the pause have to be right in the middle? O.o I'm not sure if I understand the code. Nice to see it is still progressing, though.
-
Does the pause have to be right in the middle? O.o I'm not sure if I understand the code. Nice to see it is still progressing, though.
the Pause 33 takes 33 as an argument. in the Line(5,17,8,Pause 33,23) line, it means that both pause and line take the argument 33 as a parameter
-
So basically that 33 is used in both the Pause command as well as the 4th argument in Line(), as a way to save space, right?
-
So basically that 33 is used in both the Pause command as well as the 4th argument in Line(), as a way to save space, right?
exactly. i'm assuming you could put it anywhere, if you want. and assuming that this would be syntactically correct:
Line(0,0,Pause 95,Pause 63,0
-
Yes, exactly! I just decided to mention it just to document it. It saves on memory a little, so it will probably just be a trick used by people who are really into it. Otherwise, yes, it is kind of tough to grasp. Now that I am back from work, I can start working on some math functions... Yay?
@Nemo: Thanks, I have trouble looking for the right words, so that really helped.
...
"Parameter"
-
no problem. where oh where would we be without math functions though? quigibo may be able to help you there.
-
I actually have them planned out (I was working in classes on them :D), but I am sure I could use some help on more advanced functions... I have a 16-bit routine for each of the four main functions...
-
It's been an hour, right? Okay, I was having a problem with adding the addition routinem but then I realised that I had forgotten a 7E (ld a,(hl)). Now To move on to Subtraction, then multiplication and division...
-
It has been 59 minutes and 59 seconds. A glitch caused your previous post time to be off by about 9 minutes and half. ;D
Joking aside, I wonder how many nested commands there can be? Like, could we do Line(1,1,1,Pause Text(33,10,"HI")) and it would work? That might get confusing, though. :P
-
Well, theoretically you could keep going, but yeah it gets very confusing. On another note, at the moment at least, commas are not needed and unless you use a Disp command, you don't need to jump down to the next line. However, you do need an unused variable to separate numbers. So, for example, you can separate everything using a space if you wanted to. Of course, that just gets confusing, so I wouldn't try it...
*Actually, you can only go until the stack is filled, so don't go more than a hundred (just to stay on the safe side-- some commands use the stack, too).
-
It has been 59 minutes and 59 seconds. A glitch caused your previous post time to be off by about 9 minutes and half. ;D
Joking aside, I wonder how many nested commands there can be? Like, could we do Line(1,1,1,Pause Text(33,10,"HI")) and it would work? That might get confusing, though. :P
So let me get this straight...
Line( sees the parameter list {1,1,1,33,10,"HI"} and just ignores everything past the fifth? and pause sees {33,10,"HI} and similarly ignores everything except the first?
Cool! :D
-
It's been an hour, right? Okay, I was having a problem with adding the addition routinem but then I realised that I had forgotten a 7E (ld a,(hl)). Now To move on to Subtraction, then multiplication and division...
Can it add in base N yet?
-
Just got out of classes and a Math Club meeting...
Let's see...
The commands should be seen as functions. They either take an input and output a result or they just output a result. The result they output is always (at the moment, anyway) the last converted value. When I add things like getKey, the result will obviously be based on that. So for example, Line(T,A,B,X,Y will output Y as a result. Disp Y,X,<<String>> will output X as the result, since X is the last calculated result. So, when you use Disp Y,X in place of T for the Line( command, you are actually only using the X from the Disp command.
So to lookitsan00b, yes, you are right, if you think of it that way. It took me a bit to understand how you were saying it, but yes.
@Qwerty.55: I have not added any ability to work with number bases other than ten, but I do have 16-bit addition, subtraction, and multiplication ready. I just finished a 16 bit divide routine during Calc III, so now I have to add that in...
-
Well, theoretically you could keep going, but yeah it gets very confusing. On another note, at the moment at least, commas are not needed and unless you use a Disp command, you don't need to jump down to the next line. However, you do need an unused variable to separate numbers. So, for example, you can separate everything using a space if you wanted to. Of course, that just gets confusing, so I wouldn't try it...
*Actually, you can only go until the stack is filled, so don't go more than a hundred (just to stay on the safe side-- some commands use the stack, too).
Ah ok cool. I personally may not use this very much, because I easily get confused at stuff, but I might still use it for some optimizations.
Btw will it be possible to squish data and be able to read it (from archive) using this? The major problem with BASIC is that data is rather large. In ASM, you can store a 12x8 tilemap with tiles from 0 to F in 48 bytes. In BASIC, in string format it's 96 and in list format, it's like 2-3 bytes per elements because of all the commas.
-
Okay, I know have the four functions added for +, -, *, and /, but I have to go to class soon...
So pretty much:
-the result will never go above 65535
-Negative numbers have 65536 added to them (not really, but it is a BASIC version of the explanation) This means that -2 will result as 65534
-Division only returns the integer part of the quotient. Later I will add a way to get the remainder
I may have missed something...
Oh yeah, order of operations...
This is from the commands readme:
|points. Order of operations is not used. functions
|are evaluated from right to left. Here is an example
| 3+2*6-3
| 3+2*3
| 3+6
| 9
I hope that makes sense...
-
Ah I see, so basically operations are evaluated in the complete opposite way than Axe?
Also could you answer my question in the previous post, about data?
-
Just got out of classes and a Math Club meeting...
Let's see...
The commands should be seen as functions. They either take an input and output a result or they just output a result. The result they output is always (at the moment, anyway) the last converted value. When I add things like getKey, the result will obviously be based on that. So for example, Line(T,A,B,X,Y will output Y as a result. Disp Y,X,<<String>> will output X as the result, since X is the last calculated result. So, when you use Disp Y,X in place of T for the Line( command, you are actually only using the X from the Disp command.
So to lookitsan00b, yes, you are right, if you think of it that way. It took me a bit to understand how you were saying it, but yes.
@Qwerty.55: I have not added any ability to work with number bases other than ten, but I do have 16-bit addition, subtraction, and multiplication ready. I just finished a 16 bit divide routine during Calc III, so now I have to add that in...
That's not exactly what I was saying, but yes that answers my question.
I was thinking that when it sees the line
Line(1,1,1,Pause Text(33,10,"HI"))
It parses it to a list like this
Arguments:
{1,1,1,33,10,"HI"}
Commands:
Line at an index of 0
Pause 3
Text 3
Line would then grab the first five parameters starting at an index of 0,
Pause would grab the first parameter starting at an index of 3, and
Text would grab the first three parameters starting at an index of 3.
Now that I think about it, it seems a little idiotic, since it wouldn't allow for addition and subtraction in parameters...
But that's what I meant. You're doing it so much better :P
-
Xeda, is there any reason operations are evaluated right to left instead of left to right? unless it makes the code more optimized, i'd suggest left to right for readability, and it would also be similar to axe, which people are used to by now.
Also, if/when you add support to define data, what will the scope of the data be? for example, could i start the interpreter, define some data, use Stop, and then if i re-start the interpreter will my data still be there (assuming i haven't used the Asm() token to modify anything).
-
Sorry, I just got out of class...
@nemo: It is easier, more optimized, and faster for the numbers to be calculated this way. Sorry about that...Well, actually, now that I think about it, I might be able to come up with a way to fix that. Okay, I will work on that and come up with a definite answer later...
@DJ Omni: Actually, once I get to making variables, it will be easier to use compressed data. If you check SpriteLib, I have a method to take a 128 byte "screen shot" of the homescreen which then gets compressed to 64 bytes (because only 16 tiles are used). Plus, I have a method to extract that data from archive. So yes, when I get to that point, I will definitely add the ability to compress data and access archived data because I already have the calls made.
I have a bunch of calls made from previous programs, but I am only implementing them as I need them so as not to take up too much memory. I have been making a bunch of new ones for this program and I still have a few more I need to make (like getting all the data I need when accessing a string argument...). So for now, I will be making a bunch of random calls and using them, but the commands are going to be more SpriteLib-like. Also, I need to make a way to implement variables... I tried a method that worked, but the variables were accessed using numbers. I think I am going to stick with using the letters like in BASIC...
-
if it's faster and more optimized to calculate the numbers from right to left, by all means, do it. you can never have too much speed. if you can get similar speed from left to right, i'd suggest that though.
-
Yes, I actually am trying to visualize it right now, but I am pretty sure I can do it for almost no loss in speed. It was just easier for me conceptually at the time (2:00 this morning).
-
@DJ Omni: Actually, once I get to making variables, it will be easier to use compressed data. If you check SpriteLib, I have a method to take a 128 byte "screen shot" of the homescreen which then gets compressed to 64 bytes (because only 16 tiles are used). Plus, I have a method to extract that data from archive. So yes, when I get to that point, I will definitely add the ability to compress data and access archived data because I already have the calls made.
Ah ok thanks for the info. Sounds promising. :)