CodeWalrus

Development => Calculators => Calc Projects, Programming & Tutorials => Topic started by: PT_ on March 25, 2016, 08:14:17 am

Title: [TI-84+CE] ICE Compiler
Post by: PT_ on March 25, 2016, 08:14:17 am
Hello everyone!

I can imagine many, many people are waiting for this post, but yeah, one must be the first to start such project ;)
I want to introduce this program:

ICE - an interpreter/compiler of CE-BASIC

Hooray! It would look like Axe Parser, but then for the newest calculator, the TI-84+CE.
Now are there many people who have questions, about what is possible with it, how long would it take to complete, what are the pros/cons?
Let me answer some questions.

What is ICE?
ICE is an interpreter/compiler of CE-BASIC. Normally, the OS reads a BASIC programs, and compiles it to some ASM commands, and then execute it. ICE does almost the same, but only read it, and compiles it to ASM commands, but instead of executing, it stores them into another program! In that way, you can turn your BASIC program into an ASM one, which is 1000x faster.

Why ICE?
Because I want to make a cool project (and not only games), and I think this program would be very useful for many people, so I decided to give it a try :)

What is possible with ICE?
I've no details yet, because I'm in an early stage, but I want to make it possible to keep it as BASIC as possible. I mean, you should be able in the future to compile all the BASIC programs to ASM. I never gonna reach that.... Like Axe Parser, it doesn't work with the TI-OS variables, because they are sloooowwwww. Instead, all the variables are in the RAM.

What are the pros and cons of ICE?
You can compile almost all the BASIC programs to ASM, which is 1000x faster. Since the CE has a memory-mapped screen, I'm going to implement a bunch of graph routines as well. A disadvantage is that you're a bit limited with the BASIC commands. I hope I can explain this later

When will you finish it?
In these weeks, I'm busy with school stuff, so I can't really do something with programming. But after that, I hope to finish it as fast as possible. Depending on the difficulties, I hope to finish it in some monts :)

How works ICE?
The hardest part is to express a string (and eventually store it to a variable). I will implement the Shunting-Yard-Algorithm for that (I will explain later). Once I got that ready, I need to write routines that replaces BASIC commands, like ClrHome would be call _HomeUp / call _ClrTxtShdw or whatever. Once THAT is ready, or enough of them, I will release a beta :)`

How smart is ICE?
For now, it is pretty smart, and by "smart" I mean, that if you display 2 strings which are exactly the same, it will be only once in RAM, an example:
Code: [Select]
Disp "ICE","ICE"would be this:
Code: [Select]
   call _NewLine
   ld hl, _pointer_disp_0
   call _PutS
   call _NewLine
   ld hl, _pointer_disp_0
   call _PutS
   ret

_pointer_disp_0:
   .db "ICE", 0
which saves some RAM.

Example of Shunting-Yard-Algorithm:
Let's say I have this code:
Code: [Select]
F/2+3->AThe algorithm converts this to:
Code: [Select]
F 2 / 3 + A ->Now I gonna read this sentence, and convert it to this (for example code)
Code: [Select]
   ld a, (address_of_variable_F)
// Now I now that I need to divide A by 2, which is a power of 2, so just rotate the byte
   or a
   rra
// Now to add 3, which is a value, not a variable
   add a, 3
// Now store it to variable A, so
   ld (address_of_variable_A), a
This is basically how the algorithm works, but then a bit more complicated :P especially when you have a long string.

Progress:
As some of you may know, it's very hard to work in ASM :P. That is why I decided to first create this in PHP (that's why I asked how to read .8xp with PHP). After I finished that, I will port it to ASM. I'm now in the stage for developing the Shunting-Yard-Algorithm, which is the main and hardest part.

I know,  there are still a ton of questions, so feel free to ask anything if you don't understand it, or whatever you want to say! :)


Psst, don't mind my English, I'm only a sweet Dutch boy :D


Originally posted on Cemetech: https://www.cemetech.net/forum/viewtopic.php?t=12616&highlight=






Current version: 1.2.1
========DOWNLOAD========
(http://www.cemetech.net/img/icon/dl.gif) Download ICE Compiler (https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/ICECompiler.zip)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on March 25, 2016, 01:50:49 pm
Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on March 25, 2016, 02:58:44 pm
Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out :)
Yea, that is why I started with this project, and I hope to make good progress within weeks!
Like Axe, I'm going to work with ints, and MAYBE with floats, but then only for numbers, and not lists or eventually matrices.

But a difference is, that you get an element of L1, you need this: {L1+5} or whatever. I will just allow L1(5), like BASIC programmers already do :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on March 25, 2016, 03:00:25 pm
Oh that a nice idea. You should keep the {...} notation though, for Axe programmers and else you'd need to something weird to get other locations :P
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on March 25, 2016, 03:02:24 pm
Oh that a nice idea. You should keep the {...} notation though, for Axe programmers and else you'd need to something weird to get other locations :P
That sounds good, but if I'm right, it's hard to do operations on lists, such as L1+5. That is why I keep it close to BASIC, so people doesn't need to learn many new things if they aren't familiar with Axe :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on March 25, 2016, 04:22:03 pm
I saw this on TI-Planet and Cemetech and I like the idea of a new language like BASIC or something similar to Axe. As I saod on TI-Planet, the best idea would be to implement the most popular commands first, so that it's not a burden for you, especially if it's one of your first projects.

The other thing I would suggest also is to use integers instead of floating points, both for the reason above and the fact integers are much faster and smaller.

And yeah thanks for the cross-post. A lot of people here were into Axe Parser and wanted a similar language for the CE. People here tend to also be more open-minded towards such language, given how popular Axe was, so I wish you good luck with ICE.

Also don't worry about your English. Most of us speak French and Dutch as main language (only 1 staff speak English as native language) :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on March 25, 2016, 05:23:56 pm
I saw this on TI-Planet and Cemetech and I like the idea of a new language like BASIC or something similar to Axe. As I saod on TI-Planet, the best idea would be to implement the most popular commands first, so that it's not a burden for you, especially if it's one of your first projects.

The other thing I would suggest also is to use integers instead of floating points, both for the reason above and the fact integers are much faster and smaller.

And yeah thanks for the cross-post. A lot of people here were into Axe Parser and wanted a similar language for the CE. People here tend to also be more open-minded towards such language, given how popular Axe was, so I wish you good luck with ICE.

Also don't worry about your English. Most of us speak French and Dutch as main language (only 1 staff speak English as native language) :)
I will definitely use integers, both 1-byte and 3-byte. I've yet no idea how to determine whether it's 1 or 3 bytes, but whatever  :w00t:
On the other side, while I spoke with someone at Cemetech, we figured out a nice way how to determine whether it's a BASIC or an ICE program. The first line of the program-to-compile would look like this:
i<target_program_name>i, with the imaginary i of Ice :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on March 26, 2016, 03:09:41 am
Hm, 3 bytes integers is not something I hear about everyday. Most of the time people use 1, 2 and 4 bytes integers and I even saw people use nibbles. 1 byte is too small for most purposes, but can still be handy. Axe uses 2 bytes by default for variables and is more versatile. 4 bytes is much larger, but still smaller than floating points, but I guess that 3 bytes wouldn't hurt for size and it's still allow numbers from 0 to 16777215 anyway (as unsigned integers).

Also yeah, it's better to have something to check if the program is ICE or BASIC, just like we had with Axe. I forgot how Axe did it, but I think programs had to start with .PRGMNAME but it's best to avoid using that syntax in case one day they decide to port Axe to the CE and use the same check.


Also what would be nice about the language is if it allowed us to change the screen bitrate (and color palette when needed), as well as displaying LCD content from any location in the LCD RAM (eg for fast scrolling).
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on March 26, 2016, 09:28:04 am
3 bytes since the eZ80 uses 3 bytes instead of 2 bytes :P. Thats why the CE doesnt need paging like Z80 based calculators which could only index 65536 locations.
So it would actually be slower to use 2-byte ints. (Unless ofcourse you'd put the calculator in Z80 mode)

Btw, is this an open source project?

Also how are you going to handle parentheses in your algorithm? will ((((((((((3*2)))))))))) + 3 become
Code: [Select]
push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl
ld hl, 3
ld bc, 3
call _imuli
pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc
ld bc, 3
add hl, bc
?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on March 26, 2016, 09:36:52 am
Hm, 3 bytes integers is not something I hear about everyday. Most of the time people use 1, 2 and 4 bytes integers and I even saw people use nibbles. 1 byte is too small for most purposes, but can still be handy. Axe uses 2 bytes by default for variables and is more versatile. 4 bytes is much larger, but still smaller than floating points, but I guess that 3 bytes wouldn't hurt for size and it's still allow numbers from 0 to 16777215 anyway (as unsigned integers).

Also yeah, it's better to have something to check if the program is ICE or BASIC, just like we had with Axe. I forgot how Axe did it, but I think programs had to start with .PRGMNAME but it's best to avoid using that syntax in case one day they decide to port Axe to the CE and use the same check.


Also what would be nice about the language is if it allowed us to change the screen bitrate (and color palette when needed), as well as displaying LCD content from any location in the LCD RAM (eg for fast scrolling).
Indeed, the ez80 has 3-byte registers, so I will use that too. Then people could just work with 2-byte values, like they always did.
I believe I already said it, but I'm going to implement a bunch of graph routines.
3 bytes since the eZ80 uses 3 bytes instead of 2 bytes :P. Thats why the CE doesnt need paging like Z80 based calculators which could only index 65536 locations.
So it would actually be slower to use 2-byte ints. (Unless ofcourse you'd put the calculator in Z80 mode)

Btw, is this an open source project?

Also how are you going to handle parentheses in your algorithm? will ((((((((((3*2)))))))))) + 3 become
Code: [Select]
push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl \ push hl
ld hl, 3
ld bc, 3
call _imuli
pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc \ pop bc
ld bc, 3
add hl, bc
?
I think the PHP version would be open-source, but the ASM version not.
For your second 'question', you might want to take a look at how the Shunting-Yard-Algorithm works. It filters out the parenthesis, so it will become 3*2+3 :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on March 26, 2016, 09:38:51 am
You i only just realized that problem only occurs when using shunting yard. I should implement shunting yard :P

Still, the problem remains when doing something like 3 + 4 * 5, but i guess then you can use push:
Code: [Select]
ld hl, 3
push hl
ld hl, 4
ld bc, 5
call _imuli
pop bc
add hl, bc
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on March 26, 2016, 09:49:12 am
You i only just realized that problem only occurs when using shunting yard. I should implement shunting yard :P

Still, the problem remains when doing something like 3 + 4 * 5, but i guess then you can use push:
Code: [Select]
ld hl, 3
push hl
ld hl, 4
ld bc, 5
call _imuli
pop bc
add hl, bc
Nope ;)
With my algorithm, it first calculates 4*5, and then add 3.
Second, it knows when to use either 3-byte or 1-byte registersregisters. In this case, the most likely is 1-byte, so it will look like this:
Code: [Select]
ld h, 4
ld l, 5
mlt hl
ld a, l
add a, 3
I don't know if this is exactly what it will look like, but that is my target :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: c4ooo on March 26, 2016, 03:08:55 pm
Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out :)
Yea, that is why I started with this project, and I hope to make good progress within weeks!
Like Axe, I'm going to work with ints, and MAYBE with floats, but then only for numbers, and not lists or eventually matrices.

But a difference is, that you get an element of L1, you need this: {L1+5} or whatever. I will just allow L1(5), like BASIC programmers already do :)

Maybe ile take a stab at making an on calc c-compiler later, good luck to you! :)
Well in axe {L1+foo} is not a list. L1 is just a number that point to an arbitrary memory address.  ;)

Maybe ile take a stab at making a C compiler later, good luck to you! :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: MateoConLechuga on March 26, 2016, 04:36:09 pm
Interesting project. I've had a few stabs at a CE language too, with C using a parser generator called leg (http://piumarta.com/software/peg/peg.1.html)
A few obstacles i encountered were:
- i wanted to ideally use the ZDS routines. Due to the register arguments they take (HL and BC) it became impossible to do a proper precedence based expression
compiler, since it would need complex register allocation or a lot of useless swaps
- A CE lang would need to be compatible with other C routines, which would add the problem of types.
- I got frustrated with the C SDK since the makefile makes a lot of mess.

I've implemented a non precedence based expression compiler, which works.

What types of variables are you going to implement? floats, ints or ti's floats?

im interested in how this will turn out :)
What are you talking about? The makefile is literally a drop-in replacement. Also, registers are preserved on calls, so it is just a simple matter to either do it inline or put all your assembly into a .asm file (Which is also compiled in with the toolchain.) Multiple files are also sanely handled, so I have no idea what you mean by the makefile is too hard ;) Unless you are doing things completely wrong, using the SDK is a piece of cake. Please explain. :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on March 26, 2016, 04:50:50 pm
I'm not really a fan of how everything is just spewed in one directory, and not in some proper folder like src/ and build/. I made my own makefile for that but it broke.

Also the register thing had nothing to do with the SDK. It had to do with the way i wanted to do expression compiling, where + and - would operate on hl (so you could use
add hl, bc and sbc hl, bc). * and / would operate on BC, so you could use something like call mul_bc_de. Then the constants would get loaded into de.
It would produce quite short code, but i also wanted to use the RTL functions, where __imuls takes arguments hl and bc and thus ruining my algorithm :(
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: MateoConLechuga on March 26, 2016, 05:01:06 pm
I'm not really a fan of how everything is just spewed in one directory, and not in some proper folder like src/ and build/. I made my own makefile for that but it broke.
Ah, that totally makes sense :) I dislike that a lot too; I see what I can fix about it :)

Also the register thing had nothing to do with the SDK. It had to do with the way i wanted to do expression compiling, where + and - would operate on hl (so you could use
add hl, bc and sbc hl, bc). * and / would operate on BC, so you could use something like call mul_bc_de. Then the constants would get loaded into de.
It would produce quite short code, but i also wanted to use the RTL functions, where __imuls takes arguments hl and bc and thus ruining my algorithm :(
Ah, yeah, that sounds rather difficult :( Pretty neat idea though, sounds like it would be quite nice :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on March 31, 2016, 09:12:35 pm
Today I've started creating an image, as for the homescreen of the ASM port, and as a logo for my documentation. This is the result:

(http://i.imgur.com/SjWk6PV.png)

Do you like it? Wanna change something? :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Unicorn on April 01, 2016, 06:34:55 am
That looks pretty nice!
Maybe get rid of the Options:  text? It seems a bit unnessicary
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on April 01, 2016, 09:30:47 am
That looks pretty awesome! Good job :)
Meanwhile i've also thought of more complexities: formula's like (a + b) / (c + d) aren't possible without a stack :(
(actually this one is, but formula's can always be expanded for more complexity :P)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 01, 2016, 11:21:27 am
That looks pretty awesome! Good job :)
Meanwhile i've also thought of more complexities: formula's like (a + b) / (c + d) aren't possible without a stack :(
(actually this one is, but formula's can always be expanded for more complexity :P)
Thanks :)
You have 2 ways to 'save' temporary data. One is indeed pushing the value on a stack, the other is just loading it in another register, which won't be used until that value will be used. Then you only need an algorithm to check whether you use that register. On another side, I've started porting this to ASM, and I have the numbers ready, and being busy with operators :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 01, 2016, 06:01:05 pm
While I had much free time today, I've implemented the operators in the Shunting Yard Algorithm in ASM, including their precedence. It now builds 2 stacks, one at (saveSScreen), the other at (saveSScreen+1000), one for the actual stack, and the first one for the output, which I need to read after that. Unfortunately, I have no screenshots of that :(
I hope to make good progress these weeks! :thumbsup: :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Jkolade936 on April 01, 2016, 07:53:23 pm
Yay! Progress!
Keep up the good work!  :thumbsup:
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on April 02, 2016, 05:42:38 am
Today I've started creating an image, as for the homescreen of the ASM port, and as a logo for my documentation. This is the result:

(http://i.imgur.com/SjWk6PV.png)

Do you like it? Wanna change something? :)
I like it, but I was shocked by a post on Cemetech when you said the image alone was 70 KB large. O.O That's nearly half of the calculator RAM, so if program code has to be edited from RAM, then that leaves about 35 KB left for games >.<

That's unless you use compression or that the image is an april fools joke, though. You could perhaps reduce the quality and amount of colors and implement compression? This title screen looks nice, though. Also I'm glad to see new progress. :) On a side note, will this language compiler be in pure ASM or will it use both C and ASM?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 02, 2016, 07:20:22 am
Today I've started creating an image, as for the homescreen of the ASM port, and as a logo for my documentation. This is the result:

(http://i.imgur.com/SjWk6PV.png)

Do you like it? Wanna change something? :)
I like it, but I was shocked by a post on Cemetech when you said the image alone was 70 KB large. O.O That's nearly half of the calculator RAM, so if program code has to be edited from RAM, then that leaves about 35 KB left for games >.<

That's unless you use compression or that the image is an april fools joke, though. You could perhaps reduce the quality and amount of colors and implement compression? This title screen looks nice, though. Also I'm glad to see new progress. :) On a side note, will this language compiler be in pure ASM or will it use both C and ASM?
Yep :( Maybe I could go in 4bpp, which takes 'only' 35Kb or RAM, or even in 2pp, which takes still 17Kb. (NO April fool!) The compiler will be in pure ASM. :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on April 02, 2016, 07:23:40 am
What about making the background 160*240 and stretching it horizontally? Or even 160*120. You don't need much details, since it's ICE content that matters. :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on April 02, 2016, 08:51:38 am
You could also make a special blue palette for it
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on April 02, 2016, 06:29:53 pm
Yeah that could work. I heard that lower bit modes are palette-based, so quality would not suffer much. Or you could store the bg in archive and read it from there when the title screen is loaded. The compiler would not be in one single file, but I bet people wouldn't mind much.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 08, 2016, 08:52:25 pm
I'm very happy to say that I got the Shunting Yard Algorithm ready, for parsing the input to RPN notation, which is much easier for compiling. It builds 2 stack, at saveSScreen and saveSScreen+1000, each entry of 2 bytes, one for the type, and the other one for the token itself (yet no 2-byte tokens). These commands are already included:
Code: [Select]
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZtheta+-*/,()and also the functions, like sin(, cos( etc.
Again, I'm really sorry to don't have screenshots yet, tomorrow I hope to work on parsing RPN notation. Be patience! :)
In the meantime, has someone a good code in ASM to get all the programs or should I write it myself?

NOTE: ^ has in ICE left-associativity, if-you-know-what-that-means-but-no-one-cares :D
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on April 09, 2016, 04:48:47 am
Nice PT_. Just one thing, though: Does it mean we will not be able to program in algebraic mode? Also I am unsure if I understand what you mean by left-associativity. D:
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 09, 2016, 06:58:40 am
Nice PT_. Just one thing, though: Does it mean we will not be able to program in algebraic mode? Also I am unsure if I understand what you mean by left-associativity. D:
No, you just program like you always did qua mathematical expressions, such as 5*(2+3)-3. ICE will convert it to RPN notation, because parsing RPN notation is much easier (search Google for Infix->postfix). For Left-associativity, I will give you an example. When you calculate 1*2*3, you calculate (1*2)*3. Officially spoken, when you calculate 2^3^4, you calculate 2^(3^4) which is 10^24, because the ^ has right-associativity. But in the program editor, if you type 2^3^4, the TIOS will calculate it as (2^3)^4 which is 4096. ICE will do the same, such that 2^3^4 = (2^3)^4.
Hope this helps! :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on April 09, 2016, 07:16:53 am
Will you implement a modulo operator? (it's been one of the more usefull things in Axe :P)
In the meantime, has someone a good code in ASM to get all the programs or should I write it myself?
What do you mean?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 09, 2016, 08:05:18 am
Will you implement a modulo operator? (it's been one of the more usefull things in Axe :P)
In the meantime, has someone a good code in ASM to get all the programs or should I write it myself?
What do you mean?
The CE has the token remainder( for that, and I will try to implement it yes.
For my question, I've received some code from Mateo, so I don't need it anymore. :) What I tried to say, was that ICE recognizes programs that starts with a special token, and search them in the VAT.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 09, 2016, 12:52:18 pm
Today I've 'worked' on creating the logo, here is my result:
(http://i.imgur.com/cKHtKeE.png)
or
(http://i.imgur.com/mjZCYqD.png)

Which one is better (I prefer the black background)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on April 09, 2016, 02:29:53 pm
I actually prefer white, maybe because snow etc is white too
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: 123outerme on April 09, 2016, 03:43:42 pm
If you could remove the black outlines on just the holes in the text, I think I'd like the white version a lot better, for the same reason as said above. Or maybe you want to go a light blue route?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Jkolade936 on April 09, 2016, 07:31:10 pm
I like the black background, but I agree with @123outerme 's outline suggestion.
Or you could do something like this:

(http://piskel-imgstore-b.appspot.com/img/6d78841c-fe89-11e5-9f8d-3972bab46360.gif)

but with a gradient with lighter blues at the bottom.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on April 09, 2016, 10:20:22 pm
Actually, I wonder if keeping a background, but making it tiled (Minecraft style) would be feasible and still look nice? It could be an ice background based on the other one, but made of 16*16 blocks. Otherwise I kinda like the white background.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on April 10, 2016, 07:06:27 am
That seems like a cool idea, dj. How big is the screenshot now as is?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 11, 2016, 06:35:46 am
Actually, I wonder if keeping a background, but making it tiled (Minecraft style) would be feasible and still look nice? It could be an ice background based on the other one, but made of 16*16 blocks. Otherwise I kinda like the white background.
So, just like how xLIBC[E] background work? With a kind of spritesheet etc?
That seems like a cool idea, dj. How big is the screenshot now as is?
Now my whole program is 16K, which means the logo+background is about 15.5K
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Jkolade936 on April 11, 2016, 12:55:35 pm
Or could you do a cracked ice background? Like DJ's suggestion, but slanted in places?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on April 11, 2016, 04:01:03 pm
Actually, I wonder if keeping a background, but making it tiled (Minecraft style) would be feasible and still look nice? It could be an ice background based on the other one, but made of 16*16 blocks. Otherwise I kinda like the white background.
So, just like how xLIBC[E] background work? With a kind of spritesheet etc?
That seems like a cool idea, dj. How big is the screenshot now as is?
Now my whole program is 16K, which means the logo+background is about 15.5K
Yep, like a tile map.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on April 30, 2016, 03:17:57 pm
Sooo.....

Long time no post of this project. I'm sorry for that, I am pretty busy with exams and the study next year after the exams, but that doesn't mean I haven't worked on it. As you may know is the Shunting-Yard-Algorithm already done, which means I've started with the part to evaluate the RPN notation stuff. Not very easy, because I want to optimize the output very well, but that also means more statements, and stuff, bla bla bla.... For each operator, there are 4 possibilities:
- <number> <number> <operator>
- <number> <variable> <operator>
- <variable> <number> <operator>
- <variable> <variable> <operator>
Both numbers, is just popping the numbers and operator from the stack, and push the result. And for the other cases, I've written routines to evaluate them and add the output to the program data. For now, it's pretty optimized, and I'm finally happy that I've a screenshot now :D

(http://i.imgur.com/oCQNHrb.png)
(http://i.imgur.com/y8SfXUo.png)

(http://i.imgur.com/F6RgYkz.png)
(http://i.imgur.com/paFM4Vo.png)

I've only implemented + and - yet, and I'm busy with *. I hope to make good progress! :)

P.S. Now that I'm posting this post, I see that <number> - <variable> can be shorter:
Code: [Select]
ld a, <number> / ld hl, <variable> / sub a, (hl)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on April 30, 2016, 04:04:58 pm
Good to see this still alive and kicking. :) Will this auto-optimize certain additions and substractions like explained by Axe Parser's auto-opt text documentation?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 17, 2016, 09:28:17 am
Small post despite my final exams: I've 'implemented' an API. That is, when running ICE from an ASM program, it will skip the header and directly search and compile the program. An example would be this:
Code: [Select]
  ld hl, ICEname
  call _Mov9ToOP1
  call _ChkFindSym
  ex de, hl
  ; skip header
  inc hl
  inc hl
  push hl    ; save for later
    ld hl, varname
    call _Mov9ToOP1
  pop hl
  ld (callAdress), hl
callAdress = $+1
  call $000000
  ; continue
Of course, you can modify it for your own, but the program name should be in OP1 and to skip the ICE header, increment twice the starting data point.
My ICE program would look like this:
Code: [Select]
  jr noAPI
  jr APIContinue
noAPI:
  header....
APIContinue:
  call _ChkFindSym
etc
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 17, 2016, 04:19:27 pm
When do your finals end by the way?

Also I am unsure if I understand your post. Is that header thing so that people can compile ICE programs from any ASM program they want?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 17, 2016, 04:42:05 pm
When do your finals end by the way?

Also I am unsure if I understand your post. Is that header thing so that people can compile ICE programs from any ASM program they want?
Next Monday, in 6 days. After that, I'm more than happy to continue this :)

Do you know what an API is? I made it such, that you can compile an ICE program within an ASM program, without starting ICE, selecting the program etc. The header is just displaying the logo and selecting the programs.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 17, 2016, 04:49:02 pm
An API is some sort of software routine that lets someone use the software feature in their own, right? (like how we can embed Twitter posts in our own site via some code). Thanks for the clarification, though. I wasn't sure if that was the main purpose of the ICE API or not.

If an ICE program is smaller in source code form than it is in compiled form, then maybe this could be used to save space? :P (eg a game made of multiple files where it only compiles the code it needs at the time, then deletes the compiled program once it's no longer needed before compiling another)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 17, 2016, 05:28:52 pm
If an ICE program is smaller in source code form than it is in compiled form, then maybe this could be used to save space? :P (eg a game made of multiple files where it only compiles the code it needs at the time, then deletes the compiled program once it's no longer needed before compiling another)
You mean that it first compiles the first program, and if it reaches a subprogram, it first compile it and then run it? That sounds very complicated and hard, and 2) compiling takes (dependant of the size) at least some seconds, so I doubt whether the user will pause the game for a second or so, and then continue.
Remember, the CE has 154K of RAM, so I think that should be enough to compile-in-one. :)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 17, 2016, 06:23:43 pm
The game would be a TI-Basic program that launches ASM programa that compile ICE ones to machine language only when needed, then run them. But it's hard to explain really.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: SiphonicSugar on May 17, 2016, 10:26:50 pm
WHOA THERE! This is the most amazing thing that I've seen in years besides Walrii!

Instead of thinking of games and stuff like that, I'm going to think about using this to make a whole new CE operating system! (Which I won't be able to run unless I by a CE :()
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 18, 2016, 08:41:47 am
WHOA THERE! This is the most amazing thing that I've seen in years besides Walrii!

Instead of thinking of games and stuff like that, I'm going to think about using this to make a whole new CE operating system! (Which I won't be able to run unless I by a CE :()
Thanks! :)

But... an operating system is MUCH more as only one simple parser lol. And 2) ICE won't work for floating point numbers, and at least 60% of the normal BASIC programs... :(
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on May 18, 2016, 09:49:28 am
You could always provide some basic functions like fmul(*x, *y, *result).
BTW, are you going to provide something similar to axioms?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 18, 2016, 10:17:32 am
BTW, are you going to provide something similar to axioms?
I haven't thought about that, but that sounds like an incredible idea. Fantastic! Can you show me an example of how that works? What can an Axiom do and how would that look like?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 18, 2016, 04:34:10 pm
WHOA THERE! This is the most amazing thing that I've seen in years besides Walrii!

Instead of thinking of games and stuff like that, I'm going to think about using this to make a whole new CE operating system! (Which I won't be able to run unless I by a CE :()
To install a third-party 84+CE OS we need the private RSA key, right?

Also an OS is a lot of work so it's better if ICE remains in program or appvar format.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Lionel Debroux on May 18, 2016, 08:42:48 pm
Quote
To install a third-party 84+CE OS we need the private RSA key, right?
In theory, yes, we'd need that.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: SiphonicSugar on May 18, 2016, 09:21:10 pm
WHOA THERE! This is the most amazing thing that I've seen in years besides Walrii!

Instead of thinking of games and stuff like that, I'm going to think about using this to make a whole new CE operating system! (Which I won't be able to run unless I by a CE :()
Thanks! :)

But... an operating system is MUCH more as only one simple parser lol. And 2) ICE won't work for floating point numbers, and at least 60% of the normal BASIC programs... :(
Well nothing is too much if you have the time...
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 19, 2016, 07:15:05 pm
But the problem @SiphonicSugar is that most students need access to the TI-OS. Having to get rid of TI-OS and the risks of user mistakes making it hard to get it back would be enough to deter people from using a third-party OS that can only do one thing. Unless ICE supported dual-booting, I don't think it should become an OS.

Plus making a TI-84+CE OS is currently impossible under currently publicly-available methods anyway.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: SiphonicSugar on May 20, 2016, 01:25:41 am
Oh, I guess I should have clarified this earlier: I meant that you would use ICE to make the OS, not turn ICE into an OS. You would obviously have to add some boot features to it from a computer but for people who do not understand anything, they could make the OS in TI-Basic, then have someone else add finishing touches for like pointers or something... I don't know.  :-|
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 20, 2016, 03:41:11 am
It probably depends what feature does the compiler supports. For example, good luck compiling an OS with Axe Parser
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 20, 2016, 05:34:35 am
Well, making an OS is ICE is EXTREMELY hard but not impossible I would say. Just clarify the whole OS in a string *cough* and copy it to the existing OS :D
IF you wanna make an OS, I would recommend writing it directly in ASM, that is the best way I think. Of course, then you can use ICE to parse the input.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 20, 2016, 06:05:47 am
Yeah my main worry about a non-ASM OS would be the extremely large size. :P But of course if your language is designed to work well on the CE then the size wouldn't be that bad. I think I'll stick to making games, though. :P
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 21, 2016, 09:23:15 am
Hey guys, I'm struggling with a code snippet in ASM for representing the BASIC "xor". The output should in register A and is 1 if A xor B is true, and 0 if false. Of course, it's not super hard, but my code is yet 18 bytes and 80cc, and I'm 99% sure it can be shorter/faster. Can anyone give it a try? Thanks! :)

My code:
Code: [Select]
ld a, (address_A)
sub a, 1
sbc a, a
inc a
ld b, a
ld a, (address_B)
sub a, 1
sbc a, a
inc a
xor b

Note: Just one simple "xor (hl)" or so doesn't work :(
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 25, 2016, 08:07:41 pm
/me wonders if @Cumred_Snektron might be able to help since he's also working on a language? I can't help, though
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on May 26, 2016, 12:30:46 am
@PT_  what about
Code: [Select]
ld a, (Address_A)
cp (Address_B)
ld a, 0
jp nz, _
inc a
_:
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: JWinslow23 on May 26, 2016, 03:13:51 am
I know nothing about z80 asm, but can't you just do an xor, but convert a nonzero output to 1? Like maybe:

Code: [Select]
Load (HL) with (A xor B)
Is (HL) != 0 ?
If so, then Load (HL) with 1
Return (HL)

That's just pseudocode (I don't know asm), but I'm thinking that should work.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: MateoConLechuga on May 26, 2016, 04:42:43 am
The best that I can do is by having varB directly after varA, saving 2 bytes.

Code: [Select]
ld hl,varA
ld a, (hl)
sub a,1
sbc a,a
inc hl
ld b,a
ld a, (hl)
add a,-1
sbc a,a
xor a,b
inc a
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 26, 2016, 07:12:16 am
My answer to all of you is no ;) For Cumred and Ivoah: what if A=1 and B=2? Xor would give 3 which is false. Mateo: A and B was only as an example, it can be any variable I (the user) want. It is useful though in some cases.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on May 26, 2016, 07:25:00 am
If A = 1 and B = 2 woul;d give you

Code: [Select]
ld a, (Address_A)
cp (Address_B) ; 1 - 2 = -1, so nz
ld a, 0
jp nz, _
inc a     ; set a to 1
_:
; outcome: a = 1

Is that not what you want? else im not entirely sure what you want
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 26, 2016, 08:05:08 am
In your case: what if both A and B are 1? Then cp a, b will be zero, en thus (according to you) the outcome is 1, while it should be 0.  But if A and B > 0 but not equal, the output is 0, which is right. So your code fails if A=B
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on May 26, 2016, 08:14:57 am
Eh, i think i used the wrong flag, jp nz, _  should be jp z, _. (It was late yesterday)
now if A != B cp 0 will reset z (so nz) and it will not jump past inc a, so the end result is 1 in a. If A == B then cp 0 will set Z, jumping past inc and the outcome would be a = 0.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: JWinslow23 on May 27, 2016, 01:47:32 am
My answer to all of you is no ;) For Cumred and Ivoah: what if A=1 and B=2? Xor would give 3 which is false. Mateo: A and B was only as an example, it can be any variable I (the user) want. It is useful though in some cases.
Well, then can't you just turn each input into a 1 or 0 and do it like that? Like (pseudocode):
Code: [Select]
Is A != 0?
If so, then load A with 1
Is B != 0?
If so, then load B with 1
Load (HL) with (A xor B)
Return (HL)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: MateoConLechuga on May 27, 2016, 03:11:31 am
My answer to all of you is no ;) For Cumred and Ivoah: what if A=1 and B=2? Xor would give 3 which is false. Mateo: A and B was only as an example, it can be any variable I (the user) want. It is useful though in some cases.
Well, fine, the best I can save is just 1 byte then :P

Code: [Select]
ld a, (varA)
sub a,1
sbc a,a
ld b,a
ld a, (varB)
add a,-1
sbc a,a
xor a,b
inc a
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on May 27, 2016, 08:52:44 am
I think you can save another one by replacing add a, -1 with dec a ;)
Unless that add is intended to set the carry flag at the same time which it probably is
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 28, 2016, 08:29:16 am
I'm very happy to say that parsing a mathematical expression is almost done! :)
It now 'chains' operators, i.e. A*B+3, instead of the seperate routines for A*B and A+3 for example. Out of the 14 booleans/operators (+ - * / or xor and -> => <= > < = !=) I've finished 10. I only need >= <= > < to do, and after that, I'm ready with parsing such string (yet without functions). I haven't implemented auto-opt yet, but I will definitely do. Here is an example of what it can do:
String = A+4*B/(1-C)+3
Output =
Code: [Select]
ld a, ($D05301)    ; B
add a, a
add a, a
push af
ld a, 1
ld hl, $D05302  ; C
sub a, (hl)
pop hl
ld l, 1
mlt hl
call _DivHLByA
ld a, l
ld hl, $D05300     ; A
add a, (hl)
add a, 3
ret
The only good optimization I see is replacing the "push af" with "ld h, a" and remove the "pop hl".
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: MateoConLechuga on May 28, 2016, 09:11:27 pm
I'm very happy to say that parsing a mathematical expression is almost done! :)
It now 'chains' operators, i.e. A*B+3, instead of the seperate routines for A*B and A+3 for example. Out of the 14 booleans/operators (+ - * / or xor and -> => <= > < = !=) I've finished 10. I only need >= <= > < to do, and after that, I'm ready with parsing such string (yet without functions). I haven't implemented auto-opt yet, but I will definitely do. Here is an example of what it can do:
String = A+4*B/(1-C)+3
Output =
Code: [Select]
ld a, ($D05301)    ; B
add a, a
add a, a
push af
ld a, 1
ld hl, $D05302  ; C
sub a, (hl)
pop hl
ld l, 1
mlt hl
call _DivHLByA
ld a, l
ld hl, $D05300     ; A
add a, (hl)
add a, 3
ret
The only good optimization I see is replacing the "push af" with "ld h, a" and remove the "pop hl".

Code: [Select]
ld ix,$D05300
ld a,(ix+1)    ; B
add a, a
add a, a
sbc hl,hl
ld l,a
ld a,1
sub a,(ix+2) ; C
call _Div16By8 ; this changed names in the latest equate file
ld a, l
add a,(ix) ; A
add a,3
ret
Optimized by using an offset pointer sort of like a stack frame used in C. Probably not applicable, but meh, it's an idea.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 30, 2016, 03:59:50 am
So how exactly will math operations be done? I mean, will it be like Axe, where they are done one after another regardless of if it's + or * or will it be like the TI-OS where multiplications are done first?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 30, 2016, 08:14:15 am
So how exactly will math operations be done? I mean, will it be like Axe, where they are done one after another regardless of if it's + or * or will it be like the TI-OS where multiplications are done first?
Exactly. It runs the operators just like the OS does. So 3+A*B would be 3+(A*B) and not (3+A)*B. This makes it very hard to implement, but I thought people are used with it, and it has no advantages to delete the precedence (first * /, then + -).
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on May 30, 2016, 04:42:39 pm
Can't wait to stress test it  >:D
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 30, 2016, 04:45:35 pm
So how exactly will math operations be done? I mean, will it be like Axe, where they are done one after another regardless of if it's + or * or will it be like the TI-OS where multiplications are done first?
Exactly. It runs the operators just like the OS does. So 3+A*B would be 3+(A*B) and not (3+A)*B. This makes it very hard to implement, but I thought people are used with it, and it has no advantages to delete the precedence (first * /, then + -).
I would have been fine with both, but of course you would need to warn users in the readme about order of operations clearly, like with Axe Parser.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: aeTIos on May 31, 2016, 12:01:58 pm
To be honest I'd prefer left to right order of operations, except of course for parentheses.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on May 31, 2016, 12:25:49 pm
To be honest I'd prefer left to right order of operations, except of course for parentheses.
That means I need to rewrite the whole first part of the parser. I think people are used with the normal order of operations, like the OS does, so why not in ICE?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on May 31, 2016, 12:49:06 pm
I think order of operations will be better. Btw, i had an idea a while ago for something like c arrays, where you can basically do
Code: [Select]
A[10]->B
L1[A]->B
1000[A]->B
To read from an offset. You can even do something with r to multiply the offset with 2/3, for 2 or 3 byte elements.
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on May 31, 2016, 09:52:55 pm
To be honest I'd prefer left to right order of operations, except of course for parentheses.
That means I need to rewrite the whole first part of the parser. I think people are used with the normal order of operations, like the OS does, so why not in ICE?
Yeah I am ok with TI-OS order of operation personally. I think aeTIos' point is for the many people used to Axe Parser who are seeing ICE as Axe's successor for them to transition easier from monochrome to color calcs. But it would be better to keep things consistent with the TI-OS (except maybe how Output(), Text() and Pxl-???() switched the X/Y coordinates around.)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: Snektron on June 01, 2016, 07:02:53 am
(except maybe how Output(), Text() and Pxl-???() switched the X/Y coordinates around.)

I really wonder how TI ever got the insane idea to use (Y, X) as coordinates. Do they literally hate everyone?
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on June 01, 2016, 05:12:07 pm
I DID IT!!!!!!!!!

I'm so happy now :) I succesfully compiled a normal program, without any errors :D

Ofc, I've finally a gif for you guys!
(http://i.imgur.com/nqqGMr5.gif)

The program is still far from perfect, but I'm more than happy with this now :D

EDIT:
(http://i.imgur.com/FsfbUQw.png)
(http://i.imgur.com/1TEcnXR.png)
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: xlibman on June 01, 2016, 06:59:57 pm
Very nice to see ICE finally in action :3=
Title: Re: ICE - an interpreter/compiler of CE-BASIC
Post by: PT_ on June 11, 2016, 10:56:15 am
ICE v1.0 is ready!!!



ICE Compiler is a program that compiles TI-BASIC-like language to ASM, the machine code. Create insane games, use the color screen, and make the step to ASM smaller! Speed up your BASIC programs and it's super easy to use! Type your program in the normal editor, compile it within seconds, and you have hours of fun! It doesn't require any shell.

Download is at the first post of this topic  >:D
Please, please read the README and DOCUMENTATION...
Title: Re: ICE Compiler
Post by: xlibman on June 11, 2016, 04:40:33 pm
Wait, you completed the entire language? Or is it a demo? I am surprised that it came out in v1.0 this fast O.O

I'll download it soon and give it a try. You should put the download link (https://codewalr.us/index.php?action=dlattach;topic=1234.0;attach=1032 ) in the first post of this topic so people can find it faster. :)
Title: Re: ICE Compiler
Post by: PT_ on June 14, 2016, 05:30:20 am
Version 1.1 June XX, 2016
☐ Lbl/Goto
☐ Display strings
☐ getKey
☐ Use ix for accessing variables
☐ Input
☐ rand
Title: Re: ICE Compiler
Post by: xlibman on June 14, 2016, 07:18:04 am
Nice to see getKey and string display addition! :)
Title: Re: ICE Compiler
Post by: Snektron on June 14, 2016, 09:13:54 am
now all we need is a better editor
Title: Re: ICE Compiler
Post by: xlibman on June 14, 2016, 04:55:11 pm
Well, so far I think I would be fine with SourceCoder 3, TokenIDE (whcih I use) and the on-calc editor. Maybe you could do a custom commands file for TokenIDE? It's possible IIRC.
Title: Re: ICE Compiler
Post by: Snektron on June 14, 2016, 09:02:43 pm
i mean the on calc editor. It works pretty bad imo.
Title: Re: ICE Compiler
Post by: xlibman on June 15, 2016, 01:24:10 am
Well, I can agree that it's not that great, especially the slow Goto scrolling, but I think it should at least remain compatible so people can still use it if they want to or any of the established TI-BASIC/Axe editors out there.
Title: Re: ICE Compiler
Post by: xlibman on June 16, 2016, 06:50:07 pm
On a side note, shouldn't ICE v1.0 be called ICE v0.1, since it still doesn't have all planned features? It might be less misleading to people, because if they see v1.0 and that it lacks getKey, sprites, Text() or whatever, then they might be less inclined to check for updates than if it's called version 0.1 (which means incomplete, so people tend to check for progress more).

Also Axe Parser started becoming popular when Sprites and getkey became possible. Once games become possible, maybe there could be an ICE topic where we can showcase small programs we made or games that could later be included as examples?
Title: Re: ICE Compiler
Post by: PT_ on June 20, 2016, 08:09:50 pm
☑ Custom name, after {i}, max length of 8

Pretty easy to implement ;)
Title: Re: ICE Compiler
Post by: xlibman on June 20, 2016, 10:12:58 pm
What is the custom name for? I forgot.
Title: Re: ICE Compiler
Post by: PT_ on June 21, 2016, 05:31:55 am
Quote from: KermMartian
It looks like you didn't post about it in this thread yet; on IRC, you proposed the following two possible header formats, where {i} is the imaginary i, sqrt(-1):
Code: [Select]
{i}PROGNAME

{i}PROGNAME DESCRIPTION OF MY PROGRAM
To make it easier to detect whether a program is ICE source code, and to make it easier for you to parse descriptions to boot, I propose:
Code: [Select]
{i}PROGNAME

{i}PROGNAME
{i}DESCRIPTION OF MY PROGRAM
In fact, you might want to consider a third option as well:
Code: [Select]
{i}PROGNAME
{i}DESCRIPTION OF MY PROGRAM
{i}DCE ICON
;)
Title: Re: ICE Compiler
Post by: xlibman on June 21, 2016, 05:43:46 am
Ah right, that's a nice idea. Also I'm glad you support DCE icons (I should really make some for Wal-Rush! CE and my other games)
Title: Re: ICE Compiler
Post by: Snektron on June 21, 2016, 04:02:56 pm
Pretty nice. I also was thinking, maybe its a nice idea to add a checksum function, which you feed a pointer and a size and returns a 24 bit checksum. Could be usefull for making custom level packs for games and such, or checking for corrupted save data.
Title: Re: ICE Compiler
Post by: xlibman on June 22, 2016, 03:53:45 pm
External files such as appvars would definitively nice. But if you implement those, then make sure that the syntax to generate or read them isn't as confusing as with Axe (in the way that we can easily mix it up)
Title: Re: ICE Compiler
Post by: PT_ on June 25, 2016, 05:28:42 pm
☑ Use ix for accessing variables - saves on average 6cc and 1.2 bytes each
☑ getKey
Almost done: rand, pretty easy to implement now.

And still bugfixing... :P
Title: Re: ICE Compiler
Post by: xlibman on June 25, 2016, 05:51:31 pm
Good job so far. Do you think a game like GalagACE or Block Dude with no sprite can be made with ICE now?
Title: Re: ICE Compiler
Post by: PT_ on June 25, 2016, 05:52:41 pm
Good job so far. Do you think a game like GalagACE or Block Dude can be made with ICE now?
No, 'cuz I haven't implemented sprites or any graph command yet.

Another question: is "ld a, r" random enough for games?
Title: Re: ICE Compiler
Post by: Snektron on June 25, 2016, 06:16:07 pm
i doubt it, and its only 256 different values anyway. Isn't there an OS routine for it?
Title: Re: ICE Compiler
Post by: xlibman on June 25, 2016, 06:26:20 pm
I think 256 values would be enough for randomizing, right? After all, in BASIC we often use stuff like randInt(1,10).
Title: Re: ICE Compiler
Post by: Snektron on June 25, 2016, 06:28:03 pm
yeah but what if you want more? you could multiply and add, but that will always result in the same number being added (due to r being the number of insructions that have passed)
Title: Re: ICE Compiler
Post by: xlibman on June 25, 2016, 06:29:57 pm
Yeah true, but that seems like something that would be more needed for a math probability program or something.
Title: Re: ICE Compiler
Post by: PT_ on June 25, 2016, 08:00:44 pm
I wil look into it :)

For anyone who wants to see good speed:
(https://i.imgur.com/HV6AYoq.gif)
vs
(https://i.imgur.com/yhnvuz0.gif)
Size without header: 23 bytes vs 56 bytes. Pretty good, right?
Title: Re: ICE Compiler
Post by: xlibman on June 26, 2016, 06:15:51 am
Nice, but IMHO the TI-OS text routines are not a good way to showcase your language speed. There is a reason why most ASM/C programmers and even some Axe programmers decided to use custom text/font routines instead. I bet your screenshots would have been even faster with custom text display routines. Of course you don't have to implement those, but I'M just saying, since TI's text routines are inneficient.
Title: Re: ICE Compiler
Post by: PT_ on June 27, 2016, 07:02:57 pm
☑ Pause <expression> in ms, 1-256 ms (0=256 ms)

(https://i.imgur.com/8nu29HG.png)
(https://i.imgur.com/8fSbuYK.gif)

Already fixed some bugs ;)
Title: Re: ICE Compiler
Post by: xlibman on June 27, 2016, 08:47:17 pm
That's a nice addition. I hope in future versions there will be longer delays support, though, so that we don't have to use 8 Pause commands in a row. But accoridng to IRC that will come when 24-bit numbers are supported, right?
Title: Re: ICE Compiler
Post by: PT_ on June 28, 2016, 05:28:25 am
That's a nice addition. I hope in future versions there will be longer delays support, though, so that we don't have to use 8 Pause commands in a row. But accoridng to IRC that will come when 24-bit numbers are supported, right?
Exactly. In one of the next versions, 24-bits integers will be supported, and then you can pause for either 16.78 s or 16777 s. Not sure if I will do milliseconds or microseconds ;)
Title: Re: ICE Compiler
Post by: xlibman on June 28, 2016, 06:00:48 am
Milliseconds might be better in terms of useability. I mean, does anyone really need microseconds in a game? O.O
Title: Re: ICE Compiler
Post by: Snektron on June 28, 2016, 10:27:43 am
It would be handy if there was a timer function, which you pass like a label and an interval, which then calls the function at that interval.
Title: Re: ICE Compiler
Post by: xlibman on June 28, 2016, 03:45:44 pm
Would it be interrupt-based? Or do you mean like a command that returns the current time and lets you store the result somewhere? That could be handy to keep frame rate consistent in games.

Also question: For the sake of keeping things simple for the user, would it be possible for 8-bits mode (if that ever gets implemented) to use the xLIBC palette by default?
Title: Re: ICE Compiler
Post by: PT_ on June 28, 2016, 04:03:46 pm
I interpreted his post as "loads the time into register a, and then call a function (address) that pauses a ms". That way you only need to load values in a and call that function when you have more Pauses.
I've zero experience with interrups, so I doubt I will ever implement it  >B)
And yes, when going into 8bpp mode, whenever I will make that possible, the xLIBCE palette is automatically loaded. You should be possible to change an entry of the palette though.
Title: Re: ICE Compiler
Post by: Ivoah on June 28, 2016, 04:12:24 pm
☑ Pause <expression> in ms, 1-256 ms (0=256 ms)

(https://i.imgur.com/8nu29HG.png)
(https://i.imgur.com/8fSbuYK.gif)

Already fixed some bugs ;)
It's great to see work continuing on this project. I really hope it takes off like Axe Parser did, and we see a whole slew of games and programs come to the CE because of it.
Title: Re: ICE Compiler
Post by: Snektron on June 28, 2016, 04:36:32 pm
I interpreted his post as "loads the time into register a, and then call a function (address) that pauses a ms". That way you only need to load values in a and call that function when you have more Pauses.
I've zero experience with interrups, so I doubt I will ever implement it  >B)
And yes, when going into 8bpp mode, whenever I will make that possible, the xLIBCE palette is automatically loaded. You should be possible to change an entry of the palette though.

I meant like the setInterval method in Javascript, it could be done without interupts as a loop that waits untill a certain time has passed.

Too bad its still not open source. I'd love to help to implement some commands.
Title: Re: ICE Compiler
Post by: xlibman on June 28, 2016, 04:45:35 pm
☑ Pause <expression> in ms, 1-256 ms (0=256 ms)

(https://i.imgur.com/8nu29HG.png)
(https://i.imgur.com/8fSbuYK.gif)

Already fixed some bugs ;)
It's great to see work continuing on this project. I really hope it takes off like Axe Parser did, and we see a whole slew of games and programs come to the CE because of it.
While the community is less active overall now than it was when the first versions of Axe came out, as soon as Axe got sprites and getkey support Axe language popularity really took off. I think the first ICE release that supports those should include some mini-game examples, including a space shooter (at least 1v1 battles with just 1 stage), to showcase what the language can do. Many people learn from code examples. But you would also obviously need a list of all commands like with Axe.

I don't know if ICE will be as popular but if well-documented like Axe and stuff, it should eventually have a decent fanbase.
Title: Re: ICE Compiler
Post by: PT_ on June 28, 2016, 05:12:01 pm
I interpreted his post as "loads the time into register a, and then call a function (address) that pauses a ms". That way you only need to load values in a and call that function when you have more Pauses.
I've zero experience with interrups, so I doubt I will ever implement it  >B)
And yes, when going into 8bpp mode, whenever I will make that possible, the xLIBCE palette is automatically loaded. You should be possible to change an entry of the palette though.

I meant like the setInterval method in Javascript, it could be done without interupts as a loop that waits untill a certain time has passed.

Too bad its still not open source. I'd love to help to implement some commands.
1) That actually sounds like a good idea, but I've serious no idea about how to do that. Maybe you can explain me some about interrups/give links and/or a code example? :)
2) I've said multiple times ICE v1.1 would be open-source. Once it's ready I will upload it to GitHub, of course with a good license to prevent misuse.


While the community is less active overall now than it was when the first versions of Axe came out, as soon as Axe got sprites and getkey support Axe language popularity really took off. I think the first ICE release that supports those should include some mini-game examples, including a space shooter (at least 1v1 battles with just 1 stage), to showcase what the language can do. Many people learn from code examples. But you would also obviously need a list of all commands like with Axe.

I don't know if ICE will be as popular but if well-documented like Axe and stuff, it should eventually have a decent fanbase.
I will include a small program with every version of ICE I upload. I believe I already did with the current version, but I'm not sure. And yes, I gonna write a small website with all the commands. About the well-documentation. XD I'm not the person who can describe it very well, and my English is bad, so yeah... haha



Other notes: I've tried to implement Input <variable> and this is my code:
Code: [Select]
call _ClrScrn
call _HomeUp
ld hl, 0003D<variable>h
ld (ioPrompt), hl ; "A=", 0
xor a, a
ld (curUnder), a
call _GetStringInput
ld hl, (editSym)
call _VarNameToOP1HL
call _ChkFindSym
ex de, hl
ld b, (hl)
inc hl
ld e, 0
Loopppp:
inc hl
ld a, (hl)
ld d, 10
mlt de
sub a, 030h
add a, e
ld e, a
djnz Loopppp
ld (ix+<variable>), e
jp _DeleteTempEditEqu
which is, if I'm right 62 bytes and insane cycles. Is it worth/can someone make it smaller? Thanks!

Another note: what do you guys thing about IS>(<variable>) and DS<(<variable>) for incrementing/decrementing variables?
Title: Re: ICE Compiler
Post by: Snektron on June 28, 2016, 07:11:29 pm
I interpreted his post as "loads the time into register a, and then call a function (address) that pauses a ms". That way you only need to load values in a and call that function when you have more Pauses.
I've zero experience with interrups, so I doubt I will ever implement it  >B)
And yes, when going into 8bpp mode, whenever I will make that possible, the xLIBCE palette is automatically loaded. You should be possible to change an entry of the palette though.

I meant like the setInterval method in Javascript, it could be done without interupts as a loop that waits untill a certain time has passed.

Too bad its still not open source. I'd love to help to implement some commands.
1) That actually sounds like a good idea, but I've serious no idea about how to do that. Maybe you can explain me some about interrups/give links and/or a code example? :)

i don't really know how to get the current time on the CE, so i will write it down in pseudocode:
Code: [Select]
while enabled do
    time = timemillis() + interval
    routine() // the routine that needs to be called on interval
    while timemillis() < time
    end
end

though i think some problems might occur when the time number overflows back to zero
You could probably do it with interrupts too, but i don't really know how :(
Title: Re: ICE Compiler
Post by: PT_ on June 28, 2016, 07:34:52 pm
i don't really know how to get the current time on the CE, so i will write it down in pseudocode:
Code: [Select]
while enabled do
    time = timemillis() + interval
    routine() // the routine that needs to be called on interval
    while timemillis() < time
    end
end
though i think some problems might occur when the time number overflows back to zero
You could probably do it with interrupts too, but i don't really know how :(
That's basically just this:
Code: [Select]
Repeat 0/While 1
  <routine>
  ld a, <interval>
  <pause routine>
End
Any thoughts on my other notes?
Title: Re: ICE Compiler
Post by: xlibman on June 28, 2016, 08:19:11 pm
Regarding a website with all the commands, IMHO you should have a backup alternative, such as an HTML or text file listing and explaining all commands that is included with ICE zip file. Otherwise, what happens if your website shut down in a few years? All documentation becomes gone. If you want, I could make a sub-forum for this project where you could post a copy of the commands list, but even then  you should still include an offline copy inside the zip file like with Axe Parser, for the sake of posterity in case one day something bad happened to CW (eg data loss).

It's fine if the commands are not explained in the best English quality. People will understand and help you clarify if needed anyway.
Title: Re: ICE Compiler
Post by: Snektron on June 29, 2016, 10:00:55 am
i don't really know how to get the current time on the CE, so i will write it down in pseudocode:
Code: [Select]
while enabled do
    time = timemillis() + interval
    routine() // the routine that needs to be called on interval
    while timemillis() < time
    end
end
though i think some problems might occur when the time number overflows back to zero
You could probably do it with interrupts too, but i don't really know how :(
That's basically just this:
Code: [Select]
Repeat 0/While 1
  <routine>
  ld a, <interval>
  <pause routine>
End
Any thoughts on my other notes?

Not really, since the time of route + timeout needs to be qual to the interval. I guess if pause can take a variable as argument it wouldnt be soo hard, but i think in axe it could only use literals
Title: Re: ICE Compiler
Post by: PT_ on June 29, 2016, 03:07:09 pm
I guess if pause can take a variable as argument it wouldnt be soo hard, but i think in axe it could only use literals
Yes, you can pause anything you want, even Pause getKey, Pause A+B*C, Pause 5-3 and in the future like Pause max(A+B,3)
Title: Re: ICE Compiler
Post by: xlibman on June 29, 2016, 03:42:08 pm
Cool to hear. That will be handy :)
Title: Re: ICE Compiler
Post by: PT_ on June 29, 2016, 07:36:12 pm
Basically, all that commands, like Disp, Pause and all the future functions like sin( for example, just parses the expression what comes after. If that is just "getKey", it will be getKey. It's not like you are restricted to only numbers or so.
Title: Re: ICE Compiler
Post by: xlibman on June 30, 2016, 03:41:34 am
YEah and that's good. I think I recall some languages or commands that only allowed constant values, such as RecallPic in TI-BASIC. This is kinda restrictive.
Title: Re: ICE Compiler
Post by: PT_ on June 30, 2016, 03:11:13 pm
I gonna change the compiling a bit. It now builds the compiled program at D407DF or so :P, but it's much easier if that actually starts at UserMem, for jumps. But because ICE will be runned from UserMem, I need to jump to ICE in RAM, and clear the space after UserMem. No problem though, but I hope it's possible :)
Title: Re: ICE Compiler
Post by: xlibman on June 30, 2016, 03:39:29 pm
By UserMem, do you mean the 150 KB of user RAM available on the calculator? I am curious if ICE will be able to use SafeRAM areas for data storage like Axe did, such as temporary tilemap data?
Title: Re: ICE Compiler
Post by: Ti64CLi++ on June 30, 2016, 04:20:11 pm
I wait the 1.1 version :D
Title: Re: ICE Compiler
Post by: PT_ on June 30, 2016, 05:31:28 pm
By UserMem, do you mean the 150 KB of user RAM available on the calculator? I am curious if ICE will be able to use SafeRAM areas for data storage like Axe did, such as temporary tilemap data?
Lol, UserMem is the memory ($D1A881) where the ASM program is copied to, and executed from. Thus, if I use UserMem myself, the executed program will be overwritten, and that is why I need to change pc if I don't want it to be messed up.

Other note: if I relocate the variables (with ix offset) to $E40000 or so, the waitstates are less, and thus faster :)
Title: Re: ICE Compiler
Post by: xlibman on June 30, 2016, 05:34:21 pm
That's a very misleading memory address name. <_< Shouldn't TI have called it ProgramMem or something?

Also speed increases are always good :) (even though BASIC coders will probably not care as much since ICE would already run way faster than BASIC no matter what :P)
Title: Re: ICE Compiler
Post by: Ti64CLi++ on July 01, 2016, 01:48:36 pm
In future release, ICE would compile all TI-Basic function?
The program ICE will be very big no?
Title: Re: ICE Compiler
Post by: PT_ on July 01, 2016, 03:33:33 pm
In future release, ICE would compile all TI-Basic function?
The program ICE will be very big no?
No, because BASIC has many *useless* functions, that almost nobody uses, like ANOVA(, Fix 5 (no floating-point-numbers), a+bi and more.
Yep, ICE will be big, but I don't care about that. If it would be too big, I gonna implement the same routine as both Cesium and DoorsCE has, dividing itself into a launcher program, and a big, archived, main program ICE. For now, it's still < 8000 bytes.
Title: Re: ICE Compiler
Post by: xlibman on July 01, 2016, 04:22:51 pm
That's not big IMHO. Also yeah I think you should stick to the essential game commands overall.
Title: Re: ICE Compiler
Post by: PT_ on July 02, 2016, 01:48:21 pm
Oki, some *big* updates from me:
- located the program data at UserMem, no need to calculate offsets. it jumps to the actual data of ICE with this routine:
Code: [Select]
start:
ld hl, ICEName
call _Mov9ToOP1
call _ChkFindSym
ld hl, ICEStart-start+4 ; skip this pc routine + 4 bytes size+header
add hl, de
jp (hl)
ICEStart:
Now I can mess up UserMem easily
- the variables are now located at $E30800, which has 2 wait states, instead of 3, and thus you can save 1cc each time you get a variable :)
- implemented IS>( and DS<( for respecitively incrementing and decrementing variables :D
- another method for jumping to a function routine. Not a bunch of "cp XX \ jr nz, +_" but a jump table. Much easier for adding functions.
Title: Re: ICE Compiler
Post by: PT_ on July 02, 2016, 06:01:55 pm
Compile archived programs:  :D
Pretty easy, but meh

(https://i.imgur.com/Dv130Ld.png)
(https://i.imgur.com/Uu0jP45.png)
(https://i.imgur.com/2xWfXsk.png)
Title: Re: ICE Compiler
Post by: xlibman on July 02, 2016, 06:31:08 pm
That's nice :D. By the way, does ICE need to be installed in order to run ICE executables? And can we use a program icon for Doors CE?
Title: Re: ICE Compiler
Post by: PT_ on July 02, 2016, 07:08:52 pm
That's nice :D. By the way, does ICE need to be installed in order to run ICE executables? And can we use a program icon for Doors CE?
No. The compiled programs are pure ASM, and it doesn't need a library for it (if such one exists). And yes, in a newer version I gonna add both description+icon support for Cesium, and if possible DoorsCE.

Version 1.1.0: July XX, 2016
   ☑ Custom compiled program name
   ☑ Compile archived program
   ☑ getKey, rand
   ☑ Pause
   ☑ Direct incrementing/decrementing variables
   ☑ Changed accessing variables using ix, located at $E30800
   ☑ Lbl/Goto
-- not done yet --
   ☑ Input
   ☑ Display strings
Title: Re: ICE Compiler
Post by: xlibman on July 03, 2016, 04:30:42 pm
Ah ok good. I was wondering because NewProg programs required a proprietary shell in order to run. I don't know if it's because programs used routines from the shell or if it was just because the author wanted things that way, but it was strange since programs were not interpreted.

Also nice additions for version 1.1.0 . Does Pause do like you first described, with a millisecond  delay?

On a side note, how many variables or list of variables can we use at the same time? Can we access them by typing a memory area offset or something? (like list elements in TI-BASIC)
Title: Re: ICE Compiler
Post by: PT_ on July 04, 2016, 05:29:38 am
Ah ok good. I was wondering because NewProg programs required a proprietary shell in order to run. I don't know if it's because programs used routines from the shell or if it was just because the author wanted things that way, but it was strange since programs were not interpreted.

Also nice additions for version 1.1.0 . Does Pause do like you first described, with a millisecond  delay?

On a side note, how many variables or list of variables can we use at the same time? Can we access them by typing a memory area offset or something? (like list elements in TI-BASIC)
Yep, it's not necessary to have ICE installed to run the compiled program. I'm not sure about this is true: maybe I gonna add a token hook, which will 'add' some tokens, in order to have more functions in the CE. Like ReadLine(<line number>,<program> or so. NOT SURE THOUGH!!!
Pause is what I described, it pauses for some milliseconds.
For now, only the variables A-Z+theta are allowed - more than enough I think.
Sneak preview on v1.2: Sprites, GUI and-bits integers :)
Title: Re: ICE Compiler
Post by: xlibman on July 04, 2016, 05:44:33 am
What would ReadLine() do? Would it be like Celtic commands?

Also I think 27 variables is not enough unless you also support lists, because what if a game has tilemaps or what if someone makes an RPG with lots of data?

Also I can't wait for v1.2 :D. Hopefully I have more free time and am less tired when it comes out so I can try doing a little something. :)
Title: Re: ICE Compiler
Post by: PT_ on July 04, 2016, 10:53:23 am
It was more an example of what could be added. Or maybe changing IS>( to Inc( or so. Just a randomidea somewhere iin my giant brain ;)
Lists are not supported yet but you can use them in v1.2. Sorry I can't make more than 27 variables if they don't exists ;)
Hehe me too. I have made a to do list for the next three version XD and they look all promising. Maybe I should split it to more releases :)
Title: Re: ICE Compiler
Post by: Ti64CLi++ on July 04, 2016, 02:06:16 pm
A new good feature is in the disp funtion:
If the string contain the character i (the imaginary i), I write the text after this char at a new line ;)
Title: Re: ICE Compiler
Post by: xlibman on July 04, 2016, 04:35:27 pm
Ooh nice idea actually. This is like @grosged Sprites library. Will Text() do that too? And will thr Text(-1 trick be supported?
Title: Re: ICE Compiler
Post by: PT_ on July 04, 2016, 07:48:37 pm
A new good feature is in the disp funtion:
If the string contain the character i (the imaginary i), I write the text after this char at a new line ;)
Sounds like a pretty good idea, but only useful for displaying pure strings, not something like Str0 or so.

Good news: Lbl/Goto works
Bad news: Lbl/Goto doesn't work

(https://i.imgur.com/OFKRgfJ.png)
:trollface: 


EDIT: it works now fine. I declared the pointer to the compiled program name as a 1-byte integer, while it should be a 3-byte integer ;)
Title: Re: ICE Compiler
Post by: xlibman on July 05, 2016, 01:51:57 am
Wait, did the Lbl/Goto bug mess up your VAT or something in that screenshot? I hope it did not corrupt anything archive-related, though. That would be bad if you hit the OS certificate by accident and bricked your calc O.O
Title: Re: ICE Compiler
Post by: PT_ on July 05, 2016, 05:26:38 am
Wait, did the Lbl/Goto bug mess up your VAT or something in that screenshot? I hope it did not corrupt anything archive-related, though. That would be bad if you hit the OS certificate by accident and bricked your calc O.O
No, not really. I accidentally set the pointer to the compiled program name to $DD47E1 or something like that. Why it would mess up? I dunno. Btw, I use CEmu and I can easily redownload it ;)
Title: Re: ICE Compiler
Post by: Snektron on July 05, 2016, 10:39:00 am
Does ICE support negative values?
Title: Re: ICE Compiler
Post by: xlibman on July 05, 2016, 04:28:58 pm
Wait, did the Lbl/Goto bug mess up your VAT or something in that screenshot? I hope it did not corrupt anything archive-related, though. That would be bad if you hit the OS certificate by accident and bricked your calc O.O
No, not really. I accidentally set the pointer to the compiled program name to $DD47E1 or something like that. Why it would mess up? I dunno. Btw, I use CEmu and I can easily redownload it ;)
Ah ok lol. I was unsure, since it was possible to corrupt the TI-83+/84+ archive if you unlocked flash and did bad stuff.
Title: Re: ICE Compiler
Post by: PT_ on July 05, 2016, 05:22:17 pm
Does ICE support negative values?
Nope, yet not.

NEW UPDATE: Disp <string>
It builds ANOTHER (:() stack for the program data, and at the end it copies it to the end of the program, and update all the pointers. Standard size = 13+length_string, and I've no idea about the speed.
(https://i.imgur.com/WtGeUtx.png)
(Actually, that ":" should be a ".". There is a difference between characters and tokens :(

Size: source = 31 bytes.
Compiled program = 64 bytes. Pretty good :)
Title: Re: ICE Compiler
Post by: xlibman on July 05, 2016, 06:47:38 pm
What's the maximum string length?
Title: Re: ICE Compiler
Post by: PT_ on July 05, 2016, 06:49:23 pm
What's the maximum string length?
There is no maximum. Well, as long as vRAM is, maybe. But yeah, whould would like to display a string of 320*240*2 tokens? :trollface: 
Title: Re: ICE Compiler
Post by: PT_ on July 05, 2016, 08:32:07 pm
And... I think this is double-post-worth :) :
ICE v1.1 is ready! Input, Lbl/Goto and Disp <string> now works too!
Here's an example program:
(https://i.imgur.com/I5GLBr4.gif)

Code: [Select]
rand->A
Repeat A=B
Input B
If B>A
Goto TOOHIGH
Disp "TOOLOW"
Goto GETNEXT
Lbl TOOHIGH
Disp "TOOHIGH"
Lbl GETNEXT
1->C
While C
IS>(C
Pause 5
End
End
Asm(CD8C0D02     // call _GetKey
Disp A
Pretty good, right? Size = 104 vs 211 bytes. WOW :D :D :D

I can't say it's bugless (notice the wrong value of A at the end), but yeah, I'm super happy with this. I hope to upload it very soon! :)
Title: Re: ICE Compiler
Post by: xlibman on July 06, 2016, 01:50:11 am
Cool. I assume that 1.1 is sitting in ticalc.org or Cemetech pending queue, right? I might give it a try if I'm not too busy with going out  in the next few weeks (yay $1 public transit promotion and extended service).

The size is not bad. Normally such language ends up twice larger than ASM but if it's quite efficient then I can live with it, just like with Axe. :)
Title: Re: ICE Compiler
Post by: Unicorn on July 06, 2016, 03:18:38 am
So are there memory leaks with those gotos? And why make the code so confusing? Why not multiple if's for the checking?
Title: Re: ICE Compiler
Post by: xlibman on July 06, 2016, 04:00:37 am
Maybe he was just demonstrating Goto? Sometimes tutorials make useless code purposely to showcase one command in particular.
Title: Re: ICE Compiler
Post by: PT_ on July 06, 2016, 05:30:54 am
Cool. I assume that 1.1 is sitting in ticalc.org or Cemetech pending queue, right? I might give it a try if I'm not too busy with going out  in the next few weeks (yay $1 public transit promotion and extended service).
Nope, I first want to test it all, and fix some bugs. After that, I will upload it :)
The size is not bad. Normally such language ends up twice larger than ASM but if it's quite efficient then I can live with it, just like with Axe. :)
Indeed, and with the Goto's and Repeat/While, I can chop off 4 bytes by using a "jr" instead of "jp" but for now, I'm more than happy with it ;)
So are there memory leaks with those gotos? And why make the code so confusing? Why not multiple if's for the checking?
No, there aren't any memory leaks. A Repeat looks like this: <code> \ or a \ jr z, <code>. A simple Goto is just a jump. So you will get <code> \ <jump> \ or a \ jr z, <code> which doesn't cause an overflowed stack, because there is no stack. And as DJ said, this example is just for showing what is possible, and I admit, it's pretty bad :trollface: 
Title: Re: ICE Compiler
Post by: Snektron on July 06, 2016, 11:52:01 am
Does stuff like
Code: [Select]
A*3->B*6->C
work too?
Title: Re: ICE Compiler
Post by: PT_ on July 06, 2016, 12:51:53 pm
Does stuff like
Code: [Select]
A*3->B*6->C
work too?
Sure :trollface:  that always saves space and speed:)
Title: Re: ICE Compiler
Post by: Snektron on July 06, 2016, 04:47:41 pm
BTW, are you going to provide something similar to axioms?
I haven't thought about that, but that sounds like an incredible idea. Fantastic! Can you show me an example of how that works? What can an Axiom do and how would that look like?

I've only noticed this just now, but they're basically natives for Axe, allowing people to make commands and add tokens. Not sure how to implemente them, but m,aybe they could work with Libload?
Title: Re: ICE Compiler
Post by: xlibman on July 07, 2016, 03:52:53 am
Cool. I assume that 1.1 is sitting in ticalc.org or Cemetech pending queue, right? I might give it a try if I'm not too busy with going out  in the next few weeks (yay $1 public transit promotion and extended service).
Nope, I first want to test it all, and fix some bugs. After that, I will upload it :)
The size is not bad. Normally such language ends up twice larger than ASM but if it's quite efficient then I can live with it, just like with Axe. :)
Indeed, and with the Goto's and Repeat/While, I can chop off 4 bytes by using a "jr" instead of "jp" but for now, I'm more than happy with it ;)
So are there memory leaks with those gotos? And why make the code so confusing? Why not multiple if's for the checking?
No, there aren't any memory leaks. A Repeat looks like this: <code> \ or a \ jr z, <code>. A simple Goto is just a jump. So you will get <code> \ <jump> \ or a \ jr z, <code> which doesn't cause an overflowed stack, because there is no stack. And as DJ said, this example is just for showing what is possible, and I admit, it's pretty bad :trollface: 
Can multiple loops or blocks be nested?


As for Axioms, you could always add support for inline ASM and have people type the hexadecimal inside the Asm() command or something.
Title: Re: ICE Compiler
Post by: Snektron on July 07, 2016, 01:55:07 pm
I don't think this is supposed to happen
(http://i.imgur.com/nADN9qA.gif)
Title: Re: ICE Compiler
Post by: PT_ on July 07, 2016, 03:01:44 pm
Can multiple loops or blocks be nested?


As for Axioms, you could always add support for inline ASM and have people type the hexadecimal inside the Asm() command or something.
Yep. There is a limited count to them, due to the stack, and because I move the stack temporary to vRAM, you can nest about 15000 loops or so. Enough? :trollface:

Asm(<hex> is already supported. And for Axioms, I've zero idea about how they works etc.. so yeah, I doubt I will implement it in the next X versions.


New update: I replaced a big part of the compiler. Instead of using register de as a pointer to the program data (zero safety), I use the OS calls + memory locations: curPC, endPC, _CurFetch and _IncFetch. This takes more time (1/100 s vs 1/101 s :P) but is much safer, and easier to use.
Title: Re: ICE Compiler
Post by: xlibman on July 07, 2016, 04:14:26 pm
Nice to see such high nested block/loop limit. I think i would be fine with just 10 but we never know. :P

Also great work on ICE so far.
Title: Re: ICE Compiler
Post by: PT_ on July 07, 2016, 06:16:30 pm
Okay..... IT'S FINALLY READYYYYYY :) :) :D
Compiling is now much easier (not faster), and better understandable.
The download should be in the first post, but.... the zip is too large... Download it here:
https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/ICE.zip (once it's accepted)
or here:
https://tiplanet.org/forum/archives_voir.php?id=587211

"ICE Compiler is a program that compiles TI-BASIC-like language to ASM, the machine code. Create insane games, use the color screen, and make the step to ASM smaller! Speed up your BASIC programs and it's super easy to use! Type your program in the normal editor, compile it within seconds, and you have hours of fun! It doesn't require any shell."

Have fun and don't hesitate to post anything!

Also, it will be open-source, I will upload it soon to GitHub


(https://i.imgur.com/BO02SMr.gif)
Title: Re: ICE Compiler
Post by: Snektron on July 07, 2016, 09:08:20 pm
Very nice :)
Are you going to implement variables of more letters someday too?
Title: Re: ICE Compiler
Post by: xlibman on July 07, 2016, 09:42:53 pm
Great! This is v1.1, right?
Title: Re: ICE Compiler
Post by: PT_ on July 08, 2016, 05:32:41 am
Very nice :)
Are you going to implement variables of more letters someday too?
Thanks :)
No, only lists, which is equal to a bunch of 'variables'. I can't add more variables if they don't exists :P
Great! This is v1.1, right?
Thanks :) Yeah, sure.

Epharius pointed me to a thing that the compiled program should be a protected program. I thought that was it already, because I had the filename as
Code: [Select]
.db ProtProgObj, "VARNAME", 0 but I used the wrong call to create it. Not important enough to update though ;)
Title: Re: ICE Compiler
Post by: xlibman on July 08, 2016, 06:21:37 pm
Yep, it's better to protect compiled program code. Not that it's urgent but game players might edit the code by accident. Also I did that back in the days with Galaxian, in a trial and error fashion, to make all the enemy ships shoot at the same time every 2 second. :P
Title: Re: ICE Compiler
Post by: Snektron on July 08, 2016, 08:09:08 pm
Very nice :)
Are you going to implement variables of more letters someday too?
Thanks :)
No, only lists, which is equal to a bunch of 'variables'. I can't add more variables if they don't exists :P
I mean variable names that consist of more than one letter, so you can do like
Code: [Select]
8*4->Test
Also are you going to implement storing strings into variables? And if so how will you distinguish string pointers and number arguments?
Title: Re: ICE Compiler
Post by: PT_ on July 14, 2016, 08:55:04 pm
Time for some important notes/question.

As promised, ICE v1.1 is open source. You can download/view it at https://github.com/PeterTillema/ICE. There is currently no license, but please don't copy/share it, as normal. I hope to find a good one soon :)

I'm going abroad for about 3 weeks, so then I can't work on it.

I will split the main to-do-list in 2 parts. The first part is more focused on compiling, errors, and a good GUI. The second part is more focused on adding stuff, and customs tokens.

That said, about customs tokens, I have some interesting questions for you guys. First, let me explain how I want to do this. What I need: 3 hooks: GetCSC, Menu and Token hook. My goal was
1) check if you are in the program editor
2) if so, check if you pressed [TRACE]
3) if so, force the OS to being [PRGM] pressed
4) set a special bit
5) Menu hook -> bit set, my own menu with
6) customs tokens.

Now some questions:
- if you have the token hook, and you change DE (token number), would it still work somehow?
- when the OS displays a menu, and it reads a token to be displayed as an option, would the Tokenhook run?
- if you enable the recall queue in the program editor, and you insert a *non-existent* token for some reason, would it run the Tokenhook? (call _Get_Tok_Strng or call _GetTokStrng?)
- the Wiki says about the Tokenhook, that you can point hl to the string. Would it start with the string length, or should it be null-terminated?

Thanks in advance! :)
Title: Re: ICE Compiler
Post by: DarkestEx on July 14, 2016, 08:57:48 pm
There is currently no license, but please don't copy/share it, as normal. I hope to find a good one soon :)
My suggestion is the new 3-clause BSD license. I used the same one in the entire Claw project:
https://tldrlegal.com/license/bsd-3-clause-license-(revised) (https://tldrlegal.com/license/bsd-3-clause-license-(revised))
Title: Re: ICE Compiler
Post by: xlibman on July 14, 2016, 11:33:45 pm
I can't help you on the hooks PT_ but I'm glad ICE is noe open-source. :) When Quigigo left nobody could continue working on Axe until he handed the source to Runer112 :(
Title: Re: ICE Compiler
Post by: PT_ on July 18, 2016, 02:35:42 pm
Well, the first step is made to my own custom tokens!!! (Btw, after inserting it in the program, it crashes :()
(https://i.imgur.com/stR5pZG.gif)
Title: Re: ICE Compiler
Post by: xlibman on July 19, 2016, 02:38:32 am
IMHO I think that instead of using new tokens, you should maybe use existing ones, like xLIBC does with real(), but rename them like Axe (ideally such decision should be taken early to avoid confusing ICE programmers), because illegal tokens or ones added via hooks tend to not only become unstable, but they also make it incredibly hard to send programs between the PC and calculator or between two calculators, as I witnessed with early versions of Omnicalc back in the days.

That's unless you found a solution around those issues, though. But yeah, you should try sending a program containing that Hello token to a PC and then vice-versa without ICE compiler installed, so you see what I mean.
Title: Re: ICE Compiler
Post by: xlibman on July 25, 2016, 05:28:11 pm
On a side note, I'M late to this @PT_ but congratulations on the ticalc.org front page feature. :)
Title: Re: ICE Compiler
Post by: PT_ on August 11, 2016, 10:28:43 am
Thanks :)

Time for some updates. This week I came back from my holiday, which means I had some time for programming again. And yes, of course, I picked up ICE to start with, outside of some small projects. I'm currently working on 4 parts:
- GUI
- Optimization
- Auto-optimization
- Add custom tokens.

The first part, the GUI, is halfway done, I still need to get all the programs from the VAT, starting with [\i], and display them, and of course select one. The second point is just underway, many thanks to grosged who gave me some tips, and now I can save about 100 bytes, maybe even more. I'm about to start with point 3, the auto-opt. For example I have this peace of code: Repeat A=5
ICE now compiles that into
Code: [Select]
ld a, (ix+variableA)
sub a, 5
add a, $FF
sbc a, a
inc a
or a
jp z, ******
Well, it could be MUCH shorter!
Code: [Select]
ld a, (ix+variableA)
sub a, 5
jp z, ******
This will be done at the auto-opt part, and I guess it can optimize much stuff! :)

Last part is the custom tokens, or a replacement of uncommon tokens. I've posted earlier how I gonna do that, and I'm only struggling with the extended keypresses for tokens.
Side note, I want to 'create' these tokens:
ExecHex(
Sprite(
Rect(
ReadByte(
ReplaceByte(
AddByte(
DeleteByte(
SetupPrgm(
CreateVar(
ArchiveVar(
UnArchiveVar(
DeleteVar(
Inc(
Dec(

Wanna see things added? Let me know, even if you have questions what they can do! :)
Title: Re: ICE Compiler
Post by: xlibman on August 11, 2016, 04:54:18 pm
Glad this has resumed. I was getting a bit worried it bit the dust like most other custom language projects. Make sure the GUI is simple so that it doesn't take too much space. Are the auto-opt like Axe's? And sorry you still have issues implementing custom tokens. By the way, will custom tokens work on calculators that don't have ICE installed?

Sprite() is definitively one I am looking forward to :3=
Title: Re: ICE Compiler
Post by: PT_ on August 12, 2016, 08:33:47 am
Glad this has resumed. I was getting a bit worried it bit the dust like most other custom language projects. Make sure the GUI is simple so that it doesn't take too much space. Are the auto-opt like Axe's? And sorry you still have issues implementing custom tokens. By the way, will custom tokens work on calculators that don't have ICE installed?

Sprite() is definitively one I am looking forward to :3=
I don't know how Axe has implemented auto-opt, but the first post I read was that he says auto-opt for multiplication was very hard. He only has the standard case, while I have already the easy cases for *2 etc, so I don't need to optimize it even. I will focus me more on the combination of code snippets, as you can see in the example :)
Yes, custom tokens will just replace standard, unused in ICE programs, tokens, so no problem  :thumbsup:
Title: Re: ICE Compiler
Post by: xlibman on August 12, 2016, 04:20:31 pm
There is a text file in the zip file that shows some auto-ops. :)
Title: Re: ICE Compiler
Post by: PT_ on August 19, 2016, 07:18:42 pm
It's time for maybe the biggest update ever of ICE. As you all know, it can only handle 8-bit integers, and is pretty limited to only variables and numbers, not strings, not lists, a very few functions, no arguments for a function. So it's time for a giant update. Since I at least need to change the whole algorithm to handle 3-byte integers, I thought it would be useful to change the whole stuff, so that
1) lists(functions) are supported
2) strings(functions) are supported
3) easy way to add functions
4) correct handling of arguments, even lists or strings
The giant update means too a giant increasing size... I still need to have all the code for adding, subbing, dividing etc, but now even more. For the interesting part: here are all the possibilities that should be supported, for adding:
- <integer> <integer>
- <integer> <variable>
- <integer> <list>
- <integer> <function>
- <variable> <integer>
- <variable> <variable>
- <variable> <list>
- <variable> <function>
- <list> <integer>
- <list> <variable>
- <list> <list> (even not the same dimension)
- <list> <function>
- <string> <string> ("ABC"+"DEF" -> "ABCDEF"

Interesting, not? :P
This would mean a giant update, and that takes much time, but if this is finished, adding new stuff is peanuts. I hope you don't blame me, as this is very useful. Also, university starts next week, so I doubt if I have enough time.... I will continue this! :)

@DJ Omnimaga : mines are better :trollface:
Title: Re: ICE Compiler
Post by: xlibman on August 19, 2016, 08:22:02 pm
List support is definitively a nice addition IMHO. It makes it easier for data management and tilemap storage. Glad to see new progress :)
Title: Re: ICE Compiler
Post by: PT_ on August 20, 2016, 06:47:37 pm
Thanks! :D

GUI almost done:

(https://i.imgur.com/iBeB5O4.gif)
Title: Re: ICE Compiler
Post by: xlibman on August 20, 2016, 08:42:08 pm
Looks simple and good. :)
Title: Re: ICE Compiler
Post by: PT_ on August 23, 2016, 02:05:42 pm
Another big problem is fixed: custom tokens. Now it finally works fine!

(https://i.imgur.com/s1PSK5Q.gif)

The code is so complicated you don't want to see it :P
I had 2 possibilities: either locating the hooks at a fixed point in RAM, or create my own appvar, and insert them. I chose the last option, because compiled ICE programs can use all the RAM, and I suffer what will happen when one accidentally overwrites the hooks. So, each time I start ICE, it checks if it exists, remove it if necessary and create an appvar with the hooks in it. Then it archives it, so it's a bit harder to delete it, and if you delete it from the memory management, it still exists. The main problem is, that you now don't know what the starting memory of the hooks is, for relative jumps/whatever. So yeah, it seems I fixed it, and I'm pretty happy with it ^^ :D

Now that I have fixed the main structure, is it pretty easy to add new tokens.
Title: Re: ICE Compiler
Post by: E37 on August 23, 2016, 04:43:06 pm
It looks really awesome!
What arguments does Sprite( take?
It's really neat to see the project come this far!
Good luck  :D
Title: Re: ICE Compiler
Post by: PT_ on August 23, 2016, 07:15:41 pm
Yet nothing :trollface:
In the future, it would look like Sprite(x,y,width,height,data) for example. I'm not sure though, because these 'tokens' doesn't work currently.
Title: Re: ICE Compiler
Post by: xlibman on August 24, 2016, 01:44:47 am
Question @PT_ : If you try to send an ICE program source code to the computer and it uses the Sprite() command, can you send it back to the calculator afterwards without any problem and code corruption? And can SourceCoder open the code? I am curious because on early versions of Omnicalc (version 1.00 through 1.10), programs that contained the Sprite() command or other Omnicalc ones could not be transfered between calculators unless grouped, and if you tried opening the source code on a calculator that doesn't have Omnicalc hooks installed, then the calculator crashed with a RAM Clear or displayed junk instead of code. Something to note also is that those versions of Omnicalc only ran on OS 1.13 and 1.14, not 1.15 and higher.

Anyway I like how this is coming along. I can't wait until that sprite command actually displays sprites :)

IMHO I think the sprite command should be as simple as possible (as in, as few arguments as possible). For example, Sprite(X,Y,zoom,pointer). That way it's easier to remember.
Title: Re: ICE Compiler
Post by: PT_ on August 24, 2016, 07:31:42 am
Question @PT_ : If you try to send an ICE program source code to the computer and it uses the Sprite() command, can you send it back to the calculator afterwards without any problem and code corruption? And can SourceCoder open the code? I am curious because on early versions of Omnicalc (version 1.00 through 1.10), programs that contained the Sprite() command or other Omnicalc ones could not be transfered between calculators unless grouped, and if you tried opening the source code on a calculator that doesn't have Omnicalc hooks installed, then the calculator crashed with a RAM Clear or displayed junk instead of code. Something to note also is that those versions of Omnicalc only ran on OS 1.13 and 1.14, not 1.15 and higher.

Anyway I like how this is coming along. I can't wait until that sprite command actually displays sprites :)

IMHO I think the sprite command should be as simple as possible (as in, as few arguments as possible). For example, Sprite(X,Y,zoom,pointer). That way it's easier to remember.
Yes, the custom tokens are a replacement of existing tokens. Well, 'tokens'. They replace VERY unnecessary tokens such as 'Á' etc, or Î. So if you send the ICE program to your computer, it won't crash, no weird tokens (Á is not weird :P). Maybe ICE support could be implemented in SourceCoder, need to speak with Kerm about that though. Sending an ICE program to another calculator also doesn't mind. If it has ICE installed, the tokens are displayed right, and if not, just Á or so.
You need to run ICE at least once to install the tokens.
Title: Re: ICE Compiler
Post by: xlibman on August 24, 2016, 07:45:03 am
Oh I see. I thought the custom tokens were brand new tokens, which were known on older calcs as illegal tokens. Good move to use the less used tokens by the way, although I wonder if that makes them harder to find in Catalog. Does ICE sort the Catalog menu?
Title: Re: ICE Compiler
Post by: PT_ on August 24, 2016, 07:48:23 am
Oh I see. I thought the custom tokens were brand new tokens, which were known on older calcs as illegal tokens. Good move to use the less used tokens by the way, although I wonder if that makes them harder to find in Catalog. Does ICE sort the Catalog menu?
No. The accented letters are not accessable through the Catalog, but if you press [TRACE] in the program editor, you will get the menu with my custom tokens. You can also install at least the Dutch OS, because there are the accented letters accessable. I dunno how that will look like though :trollface:
Title: Re: ICE Compiler
Post by: PT_ on August 24, 2016, 10:19:45 pm
What about this?

(https://tiplanet.org/forum/images/forum_uploads/86795_1472077014_57be1cd6c1193.png)
Title: Re: ICE Compiler
Post by: xlibman on August 25, 2016, 03:29:36 am
This seems good to me. Would PRGM be in the CTL menu, though? It might make more sense to group the program commands in the PRGM menu, such as the I/O ones, unless PRGM up there was a typo and you meant CTL. Also glad to see a rectangle command. :)

And yeah language apps have extra characters available via the Catalog menu's first option. It's not necessarily convenient, though, for typing actual commands.
Title: Re: ICE Compiler
Post by: Ti64CLi++ on August 25, 2016, 08:48:12 am
The ICE token menu is always ready or just in ICE prgm?
Title: Re: ICE Compiler
Post by: PT_ on August 25, 2016, 09:23:37 am
The ICE token menu is always ready or just in ICE prgm?
You can access the menu every time you are in the program editor.
Title: Re: ICE Compiler
Post by: xlibman on August 25, 2016, 04:21:01 pm
By the way, will the sprite data be similar to xLIBC?
Title: Re: ICE Compiler
Post by: c4ooo on August 27, 2016, 02:08:56 am
For the language to be more usable, please dont have commands to modify bytes ;) Just use something like "{foo}" to identify read byte #foo and "bleh->{foo}" to write a byte.
Title: Re: ICE Compiler
Post by: xlibman on August 27, 2016, 06:44:07 pm
For the language to be more usable, please dont have commands to modify bytes ;)
Why not?
Title: Re: ICE Compiler
Post by: PT_ on September 20, 2016, 12:02:43 pm
Well, I'm really busy with school, so not really enough time to finish the next version. Despite that kind of struggles, I implemented lists, and only 2 options: storing a fixed custom list to an OS list (fixed = only integers allowed, no variables or whatever) and also doing operations on a single list element, like 5+L1(A-3) works too.
My test code was this:
Code: [Select]
A-(3-L1(A-(B-3which is only 14 bytes. ICE turns this into:
Code: [Select]
-- ld ix, cursorImage
ld hl, (ix+3)
dec hl
dec hl
dec hl
ex de, hl
ld hl, (ix)
or a
sbc hl, de
ld de, saveSScreen
add hl, de
ld de, (hl)
ld hl, 3
or a
sbc hl, de
ex de, hl
ld hl, (ix)
or a
sbc hl, de
which is, if I'm right, 32/37 bytes. A bit too much, but I'm still proud of it ;)

Also, I'm still working on the auto-optimization, which is pretty hard.

-- calc84 pointed me to a bug, that the offset to a list element needs to be multiplied with 3. Should be easy to fix though.

That said, the whole code for one operator ( - ) is done, which means I can continue with the others. That should go a little bit faster though, because I have the structure done.
Title: Re: ICE Compiler
Post by: xlibman on September 21, 2016, 06:11:37 am
By fixed list only allowing integers and not variables, does it mean the list cannot be altered once it's stored in that format or something else? Glad to see updates, by the way. Good luck with school and this project :)
Title: Re: ICE Compiler
Post by: PT_ on September 21, 2016, 06:41:11 am
No, you can only store a list of integers to an OS list, such as {1,2,3,4,5->L1 but you can store anything to a list element, such as A->L1(5. What I tried to say is, that you can't do this for example: {1,2,3,4,A->L1.
Title: Re: ICE Compiler
Post by: xlibman on September 23, 2016, 04:54:22 am
Oh I see now. I guess that could put some constraints on programmers, but if they can do {1,2,3,4,5->L1, followed by A->L1(5 then that can probably do the job, even if not necessarily ideal. As long as we can modify individual list elements fine.

Any luck with sprites and/or changing colors of individual pixels, by the way?
Title: Re: ICE Compiler
Post by: PT_ on September 23, 2016, 06:07:02 am
In speed or size it doesn't matter, so no worries. It only looks a bit bad :trollface:
And sadly no, I first wanted to finish the operators, but it's actually not a bad idea to start with some functions!
Title: Re: ICE Compiler
Post by: PT_ on September 24, 2016, 07:23:59 pm
So I finally had a free day, so I made a lot of changes:
To-Do-List for the next release:
Code: [Select]
<code>
<input code>
<code>
ret
instead of
Code: [Select]
<code>
call <input>
<code>
ret
<input code>
Well, every week I'm pretty busy, so I guess not many time for programming sadly :(
Title: Re: ICE Compiler
Post by: xlibman on September 24, 2016, 07:25:12 pm
Nice to see progress! By the way, will custom tokens work if the user has a language localization app enabled?
Title: Re: ICE Compiler
Post by: E37 on September 24, 2016, 07:26:09 pm
Quote
You can now (re)compile archived programs
Awesome! Hopefully you won't have the same troubles that Axe did with it.
Title: Re: ICE Compiler
Post by: PT_ on September 24, 2016, 07:27:00 pm
Nice to see progress! By the way, will custom tokens work if the user has a language localization app enabled?
Yes, as I said my custom tokens are replacements of statistics tokens, which 1) nobody uses in the program editor and 2) will stay the same in another language. :)

Quote
You can now (re)compile archived programs
Awesome! Hopefully you won't have the same troubles that Axe did with it.
No, since the archive structure is totally different ;) Programs are stored as in RAM, but the header is a little bit different.
Title: Re: ICE Compiler
Post by: PT_ on September 26, 2016, 01:21:30 pm
Added rand - 400 bytes extra :) The rand routine itself is 28 bytes large, but sometimes the registers shouldn't be overwritten, so push/pop is needed.
I got it from https://www.omnimaga.org/asm-language/ez80-optimized-routines/
Title: Re: ICE Compiler
Post by: xlibman on September 26, 2016, 07:28:53 pm
Ah ok, I was wonderingabout the language apps because I remember that Omnicalc overwrote the Français app parser hooks. Also how fast is the Rand command?
Title: Re: ICE Compiler
Post by: PT_ on September 26, 2016, 07:32:19 pm
Ah ok, I was wonderingabout the language apps because I remember that Omnicalc overwrote the Français app parser hooks. Also how fast is the Rand command?
According to CEmu exact 181cc, which is pretty fast I would say :) Also, I'm very hard busy, so changes are coming fast ;)
Title: Re: ICE Compiler
Post by: PT_ on September 26, 2016, 09:23:43 pm
Well, I had a *little bit* more free time as I thought, so I made some important changes.

First of all I want to show you the speed of ICE. Here it compiles at program with the normal header and 150 lines with the same code: "3+4-L1((3+A)-B->C+3->L1(4". Guess how fast? See it!
(https://i.imgur.com/G7U5mIm.gif)
It crashes at the end. Debugging would be fun.....

Notice: CEmu seems to be much slower when recording. In real time, compiling takes seriously about 1/3 second, INSANE FAST :D :D :D

I've added the rand-routine, as already said. 28 bytes with a speed of 181cc is not bad, I would say. Again, thousands of bugfixes, it seems I always make errors :P Besides that, I started with the code for my custom tokens, and ReadByte( seems to work.

For all ReadByte, ReplaceByte, AddByte and DeleteByte, I will add a mode option, like ReadByte(<mode>,<address>). Mode = 0 means reading an offset in the program (I will explain later) and mode 1 means reading directly from the memory. I will explain later, and give some code. At last I finished the 2 operators, and I think they are bugless, so happy time!
Title: Re: ICE Compiler
Post by: PT_ on September 27, 2016, 03:12:35 pm
Because it's possible, I added again a bunch of thinks.
Hopefully more are coming soon, at least I will try to finish it as soon as possible :D
Title: Re: ICE Compiler
Post by: xlibman on September 27, 2016, 04:04:44 pm
I would be OK if gibberish and static appeared in the LCD during compiling if you were in serious need of space to save a temporary copy of the program. A lot of older programs and shells did that. By the way, is external data such as appvars supported and what about archived ones?
Title: Re: ICE Compiler
Post by: PT_ on September 28, 2016, 07:40:57 am
I would be OK if gibberish and static appeared in the LCD during compiling if you were in serious need of space to save a temporary copy of the program. A lot of older programs and shells did that. By the way, is external data such as appvars supported and what about archived ones?
Not really, since the CE has 154kB of free RAM, 170kB of vRAM and 3000kB of Archive, so it's bad if I can't find enouh space to store the program :trollface:
External programs and appvars are both supported. I've these commands for this;
SetupVar( - Load the program/appvar name in OP1 and calls _ChkFindSym and loads the result in memory. If it's archived, the right pointer will be stored.
CreateVar - creates an appvar/program, the starting address of this var will be loaded into memory
ArchiveVar - archives var
UnArchiveVar - unarchives var
DeleteVar - deletes the var.

(Originally I replace Var with Prgm, but to support appvars, these will be replaced with Var
Title: Re: ICE Compiler
Post by: E37 on September 30, 2016, 03:19:08 pm
Sounds like it is really getting along!
Are you updating the download on the first post, or will the newest releases be posted along the thread?
Title: Re: ICE Compiler
Post by: PT_ on September 30, 2016, 07:23:30 pm
Well, progress is going faster than you can imagine, and I don't like making 3 times a day a new post with new features  9_9
I will post soon a BIG post with BIG updates :)

And to respond to your question: wit each ICE update, also documentation will be included, and CodeWalrus doesn't like big updates, so either I need to remove the documentation, and upload it, or don't upload it here :/
Title: Re: ICE Compiler
Post by: PT_ on October 01, 2016, 06:34:21 pm
Last week I made insane progress, tbh. I've implemented several commands, updated stuff, and of course, fixed many bugs. Let me point out the most important ones:
So basically, this was it, and thus time for a nice screenshot!
(https://i.imgur.com/H1bRgyU.png)
(https://i.imgur.com/EuVPaUu.gif)
Oops, I see that the loop step is not 100% correct...

Things to do:

So that's it! I hope you guys enjoyed it :D

EDIT: fixed that bug that the step in a For loop is a variable, had to reset a bit...
Title: Re: ICE Compiler
Post by: E37 on October 01, 2016, 08:58:17 pm
 O.O Again, looks really neat!
Will ICE stay mainly basic focused, or will it become more specialized like Axe?
Some of the features seem true to basic, while others seem specialized like file management.
It is already at the point though, that you can't compile a basic program and have it come out the same but faster right? (that uses only commands that ICE can compile)
I think that ICE would be better breaking from the basic syntax, but that's just my uneducated opinion.
Title: Re: ICE Compiler
Post by: xlibman on October 01, 2016, 09:20:02 pm
Darn that's a lot of progress! We can now make some games, sort of :). Good job so far @PT_
Title: Re: ICE Compiler
Post by: PT_ on October 12, 2016, 09:25:04 pm
Sorry for the delay, school and other things were taking my time. But whatever, I can finally say ICE sees the finish line! I've finished all the operators/booleans + big optimization (14000 -> 11000 bytes :P), fixed some stuff with functions, and fixed the function ReadByte(). In fact ICE v1.2 will already work, but when you use another custom tokens, it will generate an error (not a crash!), so basically I'm coming in the stage of both test/debugging and eventually adding/fixing functions. Stay tuned!
Title: Re: ICE Compiler
Post by: PT_ on October 14, 2016, 07:42:20 pm
I just want to say that Sprite() is finished, but I'm now busy with huge optimization in it! The sprite command looks like Sprite(x,y,width,height,data) where data is in the same form as ExecHex(, so it compiles every 2 bytes to a byte (color). I'm currently busy with HUGE optimization in the routine, because I could optimize it a lot when for example y is a constant, or the width etc, so I need a different routine for that. ;)
Title: Re: ICE Compiler
Post by: xlibman on October 15, 2016, 01:43:08 am
Glad to see it's working, but the syntax concerns me. Does this mean that "data" will have to be static, as in we won't be able to store the data in another variable/array/string/pointer then use that copied data instead? There are many situations where variable sprite data instead of constant sprite data might be needed, like this pseudo code:


Code: [Select]
For(X,0,19
For(Y,0,15
Data(TileID(X+20Y))->SpriteData
Sprite(16X,16Y,16,16,SpriteData
End
End

Otherwise, with only static/constant data, this is what our code would look like:

Code: [Select]
For(X,0,19
For(Y,0,15
If TileID(X+20Y)=1
Sprite(16X,16Y,16,16,Data1
If TileID(X+20Y)=2
Sprite(16X,16Y,16,16,Data2
If TileID(X+20Y)=3
Sprite(16X,16Y,16,16,Data3
If TileID(X+20Y)=4
Sprite(16X,16Y,16,16,Data4
If TileID(X+20Y)=5
Sprite(16X,16Y,16,16,Data5
If TileID(X+20Y)=6
Sprite(16X,16Y,16,16,Data6
If TileID(X+20Y)=7
Sprite(16X,16Y,16,16,Data7
If TileID(X+20Y)=8
Sprite(16X,16Y,16,16,Data8
If TileID(X+20Y)=9
Sprite(16X,16Y,16,16,Data9
If TileID(X+20Y)=10
Sprite(16X,16Y,16,16,Data10
If TileID(X+20Y)=11
Sprite(16X,16Y,16,16,Data11
If TileID(X+20Y)=12
Sprite(16X,16Y,16,16,Data12
If TileID(X+20Y)=13
Sprite(16X,16Y,16,16,Data13
If TileID(X+20Y)=14
Sprite(16X,16Y,16,16,Data14
If TileID(X+20Y)=15
Sprite(16X,16Y,16,16,Data15
If TileID(X+20Y)=16
Sprite(16X,16Y,16,16,Data16
End
End
Title: Re: ICE Compiler
Post by: c4ooo on October 15, 2016, 03:51:47 am
PT_ you should port the C libs. Not only will it be very easy to do (the code to do almost anything from graphics to fileio to even a tilemapper is already written), it will also be very powerful ;)
Its litraly the most complete library for CE calcs.
Title: Re: ICE Compiler
Post by: xlibman on October 15, 2016, 04:39:14 am
From what I implied from what Mateo said earlier on IRC in response to that, I have the feeling PT_ wants to attempt doing the entire thing himself.
Title: Re: ICE Compiler
Post by: PT_ on October 15, 2016, 10:03:35 am
True, I want my programs to be independant. Maybe I can add an option to compile for shells, like Cesium or DoorsCE, and also an option to port it to C for example. I know it all, that Mateo wants me to use his C libs, and I'm willing to take a look at that, but I also said that it isn't possible to make 50 Axe versions in 1 ICE version. ICE v1.2 is already pretty complicated, good compared with v1.1, so I think I will add that later.
Title: Re: ICE Compiler
Post by: c4ooo on October 15, 2016, 05:46:35 pm
What I meant is instead of writing your own Sprite() routine, to copy/paste mateo's, if he allows.
Title: Re: ICE Compiler
Post by: xlibman on October 15, 2016, 05:54:03 pm
By the way @PT_ did you see my suhgestion about Sprite() in the following post?  https://codewalr.us/index.php?topic=1234.msg46122#msg46122
Title: Re: ICE Compiler
Post by: PT_ on October 17, 2016, 08:36:19 pm
By the way @PT_ did you see my suhgestion about Sprite() in the following post?  https://codewalr.us/index.php?topic=1234.msg46122#msg46122
Yep

Mateo (and I) discussed another (better) way to handle custom tokens, instead of replacements of existing tokens, just use something like det(0) or det(43), for *every* C graphic function. I would like to hear other thoughts about this? Personally I like it, because the custom tokens are pretty limited, and this looks like xLIBCE, which looks like BASIC. What do you think?
Title: Re: ICE Compiler
Post by: xlibman on October 17, 2016, 09:39:09 pm
det() would definitively expose ICE to much less potential compatibility issues with future OSes, if TI decided to change how tokens work (such as OS 1.14->1.15 with Omnicalc, back when it still used custom tokens). I am not opposed to such change.
Title: Re: ICE Compiler
Post by: PT_ on October 22, 2016, 05:17:15 pm
Time for some new important updates!



I'm busy with a real game, so yet no screenshots :)
Title: Re: ICE Compiler
Post by: xlibman on October 22, 2016, 05:27:34 pm
GalagICE? Nice additions by the way :3=
Title: Re: ICE Compiler
Post by: PT_ on October 31, 2016, 12:45:15 pm
Nope, I'm not done yet, but I made this:

(http://i.imgur.com/XJ6dztb.gif)

108 vs 381 bytes.

(Source: http://tibasicdev.wikidot.com/sierpinski-triangle )
Title: Re: ICE Compiler
Post by: xlibman on October 31, 2016, 05:25:32 pm
That is friggin amazing and fast. I can't wait to draw stuff with this :)
Title: Re: ICE Compiler
Post by: E37 on October 31, 2016, 06:08:32 pm
real( commands? Please, Please, Please tell me you are going to cover them with a token hook.
a real( command is SO UGLY.

Looks great!
Title: Re: ICE Compiler
Post by: PT_ on November 01, 2016, 12:42:39 pm
real( commands? Please, Please, Please tell me you are going to cover them with a token hook.
a real( command is SO UGLY.

Looks great!
Let's find 80 consecutive unnecessary tokens!

Tada!

(http://i.imgur.com/t4Ux4su.gif)
Title: Re: ICE Compiler
Post by: xlibman on November 02, 2016, 02:55:06 am
E37 I am ok with it because it ensures long-term compatibility with future OSes, but I am fine if tokens are parsed as new ones. Anyway I see in the screenshot that you at least display the real token names then parse them as det(. My suggestion would be to display the equivalent next to each command or have a pop up documenting the syntax pop up when pressing the Catalog Help key.
Title: Re: ICE Compiler
Post by: PT_ on November 08, 2016, 11:10:42 pm
It's coming closer and closer...

(http://i.imgur.com/J6Yvw26.png)
Title: Re: ICE Compiler
Post by: xlibman on November 08, 2016, 11:11:12 pm
Is it due to the GIF or does the game really run at 4 FPS on a real calc? O.O
Title: Re: ICE Compiler
Post by: PT_ on November 08, 2016, 11:11:59 pm
Is it due to the GIF or does the game really run at 4 FPS on a real calc? O.O
It's the framerate. The game itself is pretty smooth, and I've added a Pause too, or it would run too fast!
Title: Re: ICE Compiler
Post by: xlibman on November 08, 2016, 11:12:54 pm
Ah ok, I was a bit worried since, after all, it's Pong lol. In any case, I can't wait to give this and GalagICE a try :)
Title: Re: ICE Compiler
Post by: PT_ on November 08, 2016, 11:51:26 pm
I'm very happy to say that ICE v1.2 is ready :)

Download here: (sorry, file size is too big)
https://tiplanet.org/forum/archives_voir.php?id=587211
Title: Re: ICE Compiler
Post by: xlibman on November 08, 2016, 11:51:57 pm
Awesome! I'm gonna check it out soon. Does it contain a quick doc about each command syntax and stuff?

EDIT: @PT_ I can't get Pong to work properly, even with the latest Libload:

(http://img.codewalr.us/ice.gif)

I can move the pad but it moves at about 10 pixels a second, the ball doesn't move and everything flickers like mad D: . Is it because I am using OS 5.1.5?

EDIT: Also there is a bug: When you compile a program then go to the 2nd+LINK menu, if you press 2nd+MODE to quit back to the home screen then the calc freezes with the run indicator active.
Title: Re: ICE Compiler
Post by: PT_ on November 09, 2016, 06:59:11 am
That PONG 'bug' is maybe because I didn't update my example ;)
I will upload a new version soon, but that's not a bug :P

However, I can't exactly replicated your second bug, and I'm not sure I understood it correctly. Can you elaborate that more? :)
Title: Re: ICE Compiler
Post by: xlibman on November 09, 2016, 07:04:51 am
Compile a program, then go to the calculator linking menu (where you can send/receive files). From there, if you quit with 2nd+Quit (mode), the calculator freezes.


EDIT: I tried on-calc (OS 5.2) and I had no issues @P_T
Title: Re: ICE Compiler
Post by: PT_ on November 09, 2016, 09:15:08 pm
I will upload soon a revised version, with some minor bugs fixed, and more examples, to make it more clear what you can do with ICE ;)

This is the famous bounce program:
(http://i.imgur.com/9hTXQem.gif)
It should run smooth!

Source:
Code: [Select]
[i]BOUNCE
det(0
det(5,0
[maxY]0,8,8,"0000E0E0E0E0000000E0E0E0E0E0E200E0E000E2E2E2E2E2E0E2E2E2E2E2E7E7E2E2E2E7E7E7E7E7E2E7E7E7E7E7E7E700E7E7E7E7E7E7000000E7E7E7E70000"
For(G,0,19
remainder(rand,312->L1(G
remainder(rand,232->L1(G+20
1->L1(G+40
1->L1(G+60
End
det(2,0
Repeat getKey
For(G,0,19
L1(G->H
L1(G+20->I
det(42,H,I,8,8
If H=312 or not(H
0-L1(G+40->L1(G+40
End
If I=232 or not(I
0-L1(G+60->L1(G+60
End
H+L1(G+40->L1(G
I+L1(G+60->L1(G+20
det(59,0,L1(G),L1(G+20
End
Pause 5
End
det(1

Copy this into SC, download it, and try it yourself! :D
Title: Re: ICE Compiler
Post by: xlibman on November 10, 2016, 01:48:29 am
So I hit a roadblock: TokenIDE Convert to hex option is greyed out when I am in xLIBC mode and SOurceCoder lacks xLIBC sprite conversion. MateoC tells me that ConvPng lets me convert my sprites to C/ASM format, but the ICE format is way different, so for now I'll probably be stuck either using low quality sprites converted using Find/replace in Notepad++ after converting them to BASIC colors, or hope for some converter that supports ICE format. D:

Title: Re: ICE Compiler
Post by: MateoConLechuga on November 10, 2016, 02:44:58 am
I added an option to ConvPNG in order to output in the ICE format. Here's how to use it; just post any bug if you have problems :)

1) Download the 5.4 ConvPNG prerelease from here (https://github.com/MateoConLechuga/ConvPNG/releases/download/v5.4/convpng.exe)

2) Create a file called "convpng.ini" (Without the quotes, also mind the extension)

3) Copy and paste these lines into convpng.ini:

Code: [Select]
#GroupICE            : ice_gfx
#Palette             : xlibc
#PNGImages           :

Now, below the #PNGImages line you can simply add the names of the png files you wish to convert, as long as the png files are in the same directory as convpng. For example, if I have 3 pngs named xxxx, yyyy, and zzzz, this is what my convpng.ini file would look like:

Code: [Select]
#GroupICE            : ice_gfx
#Palette             : xlibc
#PNGImages           :
 xxxx
 yyyy
 zzzz

To run convpng, simply double click on the convpng.exe file. Output will be written to ice_gfx.txt

Enjoy :)


Title: Re: ICE Compiler
Post by: xlibman on November 10, 2016, 03:35:44 am
Ooh thanks! That's nifty. That tutorial should be included with ICE I think. :)

I converted 1 sprite for now, to see what would happen and this is the data:

Code: [Select]
(1) | 258 bytes
"10102B2B2170707070210A0A2A0A534B2A2A2A2B212B4B4B4B212B732A4B534B2A2A2A2A212A2A2A2B21534B2A2A532B2A2A2B2B212A2A2B2A212B2B2B2A734B2A2B2121214B732A53212121212121212121212121212121212121212B4B532A2A214B532A53212121212A0A534B2B2A2B21744B2A2B212A2A2A2A2A532B2B2A2B212A2A0A53212A2A2A2A2A532B2A2A2B214B4B2A4B212A2A2A2B0A532B2B2A2B21532B2A2B212A2A2A2A2A212121212121732B2B2A212A4B4B53534B534B532121532B2A2B212A2A4B2B2B2A4B2B2B212A532B2A2A212A532A532B2B2B2A2B2121532A2A2B212A2121212121212121210A70707021212A21212121212170707070"

Is that right? Also does it contain the width/height?


Also PT_ I tried the ball demo and the speed is insane O.O. Great job on ICE so far.
Title: Re: ICE Compiler
Post by: MateoConLechuga on November 10, 2016, 03:38:55 am
Sorry, I think I may have forgotten to tell you I fixed the link. Downloading convpng.exe again from the above link should give you the proper width/height again :)

Also, PT_, can you explain why you did not encode the width/height in the string?
Title: Re: ICE Compiler
Post by: xlibman on November 10, 2016, 03:39:20 am
Ok, downloading now :3=
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on November 11, 2016, 01:50:30 pm
(https://i.imgur.com/7n058WS.gif)

:)
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on November 11, 2016, 03:20:47 pm
I've updated ICE v1.2.1 to v1.2.2 :)

There are now more examples to learn from (5 in total [BOUNCE, FLOODIT, GUESS, PONG, SIERP], more are maybe coming soon ;)), and I've included a post of Mateo where he explains how to convert images to ICE sprite data.

(https://www.cemetech.net/img/icon/dl.gif) Download ICE Compiler (https://tiplanet.org/forum/archives_voir.php?id=587211)

Have fun! :P
Title: Re: ICE Compiler
Post by: xlibman on November 11, 2016, 05:35:51 pm
Awesome. Thanks for yhe update. Nice work so far. I will try the examples soon. I saw the Flood It screenshot and I liked it. I might experiment a bit with the code to learn, such as adding moving backgrounds and stuff. :P
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: xMarminq_ on November 12, 2016, 05:28:37 pm
Link doesn't work
Title: Re: ICE Compiler
Post by: xlibman on November 14, 2016, 07:01:13 am
Which link @xMarminq_ ? I clicked the download link in the first post and it works fine...


Also @PT_ does ICE-compiled games and programs erase the screen content and redraw the status bar upon startup? Because I made an ICE program that drew a checkerboard on a certain portion of the LCD, for use in Pokéwalrus, and when the ICE program was ran, the entire screen was erased, the TI-OS status bar redrawn and then the checkerboard drawn. I thought I could use small ICE programs inside BASIC games as I do with Sprites v3.3 and CE Textlib, but alas it seems that I can't :(

I was drawing directly to the LCD in 8-bits mode, by the way. (which was already setup by Sprites v3.3)
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on November 14, 2016, 08:27:43 am
@xMarminq_ : I've fixed that link, somehow that link pointed me to CodeWalrus instead of TI-Planet.

@DJ Omnimaga : That is the so-called crt0 (https://en.wikipedia.org/wiki/Crt0). When an ICE program will run, which uses det( commands, it draws the statusbar after the program is ready. Maybe I should make it an option to remove it ;)
Title: Re: ICE Compiler
Post by: xlibman on November 14, 2016, 08:35:22 am
Ah I see. It would definitively be nice if there was an option to remove it, like some hybrid BASIC libs do as an option, so that we can use our own BASIC libraries in the form of small ICE programs. :)
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 05:49:24 am
sorry for double post but here are some suggestions:

1) A scaled sprite command that supports transparency at the same time
2) The ability to use variables for the sprite index rather than just constants. This would be very handy for magic animations.
3) Direct input with the getKey(KEYNUMBER) syntax where it's true or false. This would allow multiple keypresses and also be much more responsive than the standard TI-OS getkey routine.
4) External variable storage (for highscores).


Also bug reports:

1) Filled rectangles larger than 255 pixels width are not supported. They will not display at all. Could you increase the limit to 320 pixels?
2) The det(21,COLOR)   SetTextFGColor command doesn't support color 255 (white). So using white text under the default xLIBC palette is impossible.
3) Either the SetDraw or SwapDraw commands (det(9 and 10) causes a RAM clear.
4) ICE Compiler freezes after compiling if you try to exit while USB is connected.
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: MateoConLechuga on November 15, 2016, 06:45:10 am
Before you do anything else; pointers. For both absolute and variable pointers; please.
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 06:55:35 am
Also, I just noticed that for transparent sprites, the ICE documentation lacks any info on how to specify which color you want to be transparent. How do I figure that out?
Title: Re: ICE Compiler
Post by: Unicorn on November 15, 2016, 06:58:37 am
I believe you can check out the C graphx command documentation located here (https://github.com/CE-Programming/toolchain/blob/master/CEdev/include/lib/ce/graphx.h), (scroll down) if it is a C command.
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 07:01:55 am
What about people who don't know C? :P I'll probably check anyway, though, but for now I discovered that the transparent color defaults to zero. Which means I'll have some sprite editing to do, because my Opossum uses black :P
Title: Re: ICE Compiler
Post by: Unicorn on November 15, 2016, 07:09:30 am
What about people who don't know C? :P I'll probably check anyway, though, but for now I discovered that the transparent color defaults to zero. Which means I'll have some sprite editing to do, because my Opossum uses black :P


I don't believe you need to know C, if I understand how the C implementation works. Unless @PT_  didn't include the command for it :P
uint8_t gfx_SetTransparentColor(255); -> de(whatever,255

I think. :P
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 07:35:35 am
On a side note, I edited my suggestions/bugs report post earlier because I found a 2nd bug: det(21,COLOR)   SetTextFGColor doesn't work with color #255 (white). O.O
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: MateoConLechuga on November 15, 2016, 07:38:08 am
Yes it does it's just the PT_ hasn't documented how anything works :P As per the documentation in the C header:

Code: [Select]
/**
 * Sets the text foreground (FG), background (BG), and transparent (TP) color indexes
 * Returns previous text color index
 * Defaults:
 *  FG = 0
 *  BG = 255
 *  TP = 255
 */
uint8_t gfx_SetTextFGColor(uint8_t color);
uint8_t gfx_SetTextBGColor(uint8_t color);
uint8_t gfx_SetTextTransparentColor(uint8_t color);
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 07:41:42 am
Does it mean that ICE supports several extra arguments that are not documented in the official ICE documentation? I see a transparent text command, except that it is very vague. It seems to me like something that needs to be set to true or false, the way the doc is written.

I guess it's not a big hurry, though, since ICE is still in its infancy and it's an amazing software already. :)
Title: Re: ICE Compiler
Post by: MateoConLechuga on November 15, 2016, 07:43:58 am
I guess it's not a big hurry, though, since ICE is still in its infancy and it's an amazing software already. :)
Yep, I agree :) PT_ is doing a really nice job on this; keep up the good work :)
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 07:53:28 am
As I suggested on IRC, maybe transparency for foreground color should be independent from the background and vice-versa?
Title: Re: ICE Compiler
Post by: PT_ on November 15, 2016, 11:32:31 am
1) A scaled sprite command that supports transparency at the same time
I already added this function, but I didn't change one bit in the data, so it looks like I didn't add it :trollface:
2) The ability to use variables for the sprite index rather than just constants. This would be very handy for magic animations.
Sprites are compiled during compile-time, and also the starting pointer. When I have variables as the sprite index, I also need to include in the program the starting pointers of the sprites. Seems a bit weird, but I could implement it.
3) Direct input with the getKey(KEYNUMBER) syntax where it's true or false. This would allow multiple keypresses and also be much more responsive than the standard TI-OS getkey routine.
Yep, nice one. I will try to add that in the next release.
4) External variable storage (for highscores).
Also a nice feature in the next release.
1) Filled rectangles larger than 255 pixels width are not supported. They will not display at all. Could you increase the limit to 320 pixels?
This seems to work fine for me...
(https://i.imgur.com/KUab2sr.png)
2) The det(21,COLOR)   SetTextFGColor command doesn't support color 255 (white). So using white text under the default xLIBC palette is impossible.
I guess this conflicts with the transparent color, that you don't see it ;) I've added in the commands list that the default color for transparency is 255.
3) Either the SetDraw or SwapDraw commands (det(9 and 10) causes a RAM clear.
SwapDraw works fine, but indeed, SetDraw causes a RAM clear, due to a very dumb bug. When ICE scans for all the C functions, starting with det(, it says the first number after det( can be 0-7, so det(8 and det(9 are not allowed :P. This causes ICE to return to the main program, and thus ignoring all the C functions after det(8 or det(9
4) ICE Compiler freezes after compiling if you try to exit while USB is connected.
Ah, I need to test this carefully, but I don't know why this would happen, as it seems ICE doesn't conflict with USB related stuff.
Before you do anything else; pointers. For both absolute and variable pointers; please.
Yep, we talked way too much about it, and this is also a feature for the new release ;)
Also, I just noticed that for transparent sprites, the ICE documentation lacks any info on how to specify which color you want to be transparent. How do I figure that out?
Ah, according to the C file, the default transparent color for sprites is 0, and it seems Mateo added a function in v3 that can change that. I added that to the commands list.
Does it mean that ICE supports several extra arguments that are not documented in the official ICE documentation? I see a transparent text command, except that it is very vague. It seems to me like something that needs to be set to true or false, the way the doc is written.
No. As far as I know I've documented all the included staff. And sorry that the doc is not very clear sometimes; you know, English... :P  :-[
I guess it's not a big hurry, though, since ICE is still in its infancy and it's an amazing software already. :)
Thanks :)
As I suggested on IRC, maybe transparency for foreground color should be independent from the background and vice-versa?
That is something for Mateo, not something for ICE, so you should maybe post this in the C SDK thread ;)

/me hates quotes
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 10:54:23 pm
About Suggestion 2, maybe it could be a different set of sprites commands? Also one other time where sprites with a variable INDEX might be necessary is tilemapping, because without them, you basically need to use spaghetti code like this:

If MapTileID=1
Sprite(1,X,Y)
If MapTileID=2
Sprite(1,X,Y)
If MapTileID=3
Sprite(3,X,Y)
If MapTileID=4
Sprite(4,X,Y)
If MapTileID=5
Sprite(5,X,Y)

Which I assume could increase the code size considerably or slow the game down, compared to just Sprite(MapeTileID,X,Y) (this is pseudo code, btw)


As for rectangles, I tried in WabbitEmu and they stop showing up once their width is 255 pixels or greater. I don't remember if this happens with Clipped rectangles or non-clipped ones, though.
Title: Re: ICE Compiler
Post by: PT_ on November 15, 2016, 11:38:33 pm
As for rectangles, I tried in WabbitEmu and they stop showing up once their width is 255 pixels or greater. I don't remember if this happens with Clipped rectangles or non-clipped ones, though.
Maybe this is due to the clipping window? You might want to check it out, if the clip windows is somehow 255 or larger, for some reason. I did it with unclipped rectangles, and that worked fine.
Title: Re: ICE Compiler
Post by: xlibman on November 15, 2016, 11:41:17 pm
So I tried rectangles again and non-clipped ones work fine.

I didn't check the clipping window, though, for the others. I guess that could be why, but would it be possible to explain this in the command list or at least set it to 320 by default?


Also another suggestion: The ability to use Str1-Str0 or at least store strings of text at pointers. Just like sprites, being limited to a string constant can be a serious problem for games like Final Fantasy and Zelda.
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on November 16, 2016, 09:14:30 pm
Yay, time for another update!
I've fixed some bugs, added a little bit auto-optimization, such that if you use only once Input, it won't be in the program data but in the program itself, which saves 10 bytes. This happens too for Pause, which saves either 5 or 6 bytes (if the pause time is constant 6 bytes, otherwise 5). This is rather a small update, the next one would be v2.0 with some very nice features incoming :D
Also, I've changed the type hook, to avoid conflicts with PHASM, ICE now uses the GetKey hook, and not the GetCSC hook, because PHASM already uses that. The most important update is, that I've fixed the closing parenthesis bug. When you use for example "For(A,1,2)" it will generate an error, because of the ")". I've now changed the structure a little bit, and I hope it works now. Maybe there are some more changes, I'm not sure of ;) The Commands list is a bit updated, I've added the default value for colors/clipping. I'm not sure I've already added this in the previous version, but you can now use mean(), which calculates the mean of 2 expressions.

Have fun with it :)

Download:
https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/ICECompiler.zip
https://tiplanet.org/forum/archives_voir.php?id=587211

Source:
https://github.com/PeterTillema/ICE - licensed under GPL v3 :)
Title: Re: ICE Compiler
Post by: xlibman on November 17, 2016, 08:01:44 pm
A front-page CW news is awaiting, but not enough free time to write it. It deserves a mention with example screenshots :)

Also good to see ICE open-source for posterity. :)

EDIT @PT_ it seems that Opossum Massage Simulator no longer runs on the new version of ICE on my TI-84+CE (5.2). After the rainbow logo thing, a RAM Clear happens now. You might have introduced some sort of bug or something, but I could be wrong. The source code is available with my game if you want to check out.

And on CEmu ICE just freezes outright during compiling, on ROM 5.2.0.
Title: Re: ICE Compiler
Post by: xlibman on November 21, 2016, 08:43:02 am
I forgot to post this, but with the new version you posted the other day, Opossum Massage SImulator now compiles and run perfectly. I am now on OS 5.2.1, though, so I am unsure if that's why.

Also, if you don't mind, I could continue working on GalagICE if you give me the source. You would be credited of course, though. I still need to write a news about ICE, but I am looking into showing more animated eye-candy.
Title: Re: ICE Compiler
Post by: xlibman on November 22, 2016, 07:47:20 am
Little suggestion for BLIT command: The ability to copy a portion of the buffer anywhere on the screen or vice-versa, rather than just the same position. Like on the HP Prime, that would be kinda handy, since Axe Parser had a Copy() command that did something similar.

det(75,BUFFER,CopiedX,CopiedY,CopiedWIDTH,CopiedHEIGHT,PastedX,PastedY)


EDIT: ALso @PT_ I found a bug: The < operator doesn't work in ICE. If I do something like "If A<0", then the If block is ignored no matter the result.

EDIT: You now made CW front page (and there's also a Supersonic Ball CE title animation concept there :D) https://codewalr.us/index.php?topic=1727.0
Title: Re: ICE Compiler
Post by: xlibman on November 27, 2016, 05:31:16 am
By the way, what's new in version 1.2.4? With the version I currently have I didn'T have issues but I forgot which one it is.
Title: Re: ICE Compiler
Post by: PT_ on November 28, 2016, 08:05:00 am
By the way, what's new in version 1.2.4? With the version I currently have I didn'T have issues but I forgot which one it is.
One important bug has been fixed with nested For loops, that many program will crash. Secondly, this version is made to optimize the output program, by some bytes :trollface: , just compile it yourself, and see if the size is a bit less :P

Download:
https://tiplanet.org/forum/archives_voir.php?id=587211
Title: Re: ICE Compiler
Post by: xlibman on November 29, 2016, 04:57:24 am
Ah I see. I didn't notice any issues with nested For loops but maybe some crashes I got were partially related. :P

Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 03, 2016, 10:24:37 pm
New update, ICE v1.5. I've added direct key inputting, so very fast checking if a key is pressed, small For loops, which are independant of a variable, and much faster, and CompilePrgm( which compiles a subprogram. Additionally, the graphics library version 3 is supported. Maybe more, but I can't remember :P

(http://www.cemetech.net/img/icon/dl.gif)Download ICE Compiler (https://tiplanet.org/forum/archives_voir.php?id=587211)



Edit by p2: fixed ur bb-code.
EDIT 2 by DJ: Fixed broken link

Title: Re: ICE Compiler
Post by: xlibman on December 03, 2016, 11:24:53 pm
Direct input, yay! *.*

/me should update Opossum soon. This is definitively a great feature for games like Mario. :) Thanks a lot for thr update.

I don't have time to try right now but I'll download it as soon as I have some time off.

Can sub programs be archived?
Title: Re: ICE Compiler
Post by: PT_ on December 04, 2016, 01:26:02 pm
Direct input, yay! *.*

/me should update Opossum soon. This is definitively a great feature for games like Mario. :) Thanks a lot for thr update.

I don't have time to try right now but I'll download it as soon as I have some time off.

Can sub programs be archived?
Nope, and don't try it either. Will fix it soon
Title: Re: ICE Compiler
Post by: xlibman on December 05, 2016, 05:20:44 am
Do you mean v1.5 is completely broken and to wait for next version or do you mean just the archived sub-programs?


EDIT: @PT_ I think you broke regular getKey. I now use direct input for massaging opossum, but I can no longer get past the intro logo with regular getKey D:

EDIT

Quote
*   Walrified post by Streetwalrus on Re: Killing HTTP support on CodeWalrus (site would become HTTPS-only) http://codewalr.us/1262/48791   12:40:35 AM
DJ Omnimaga   Do you know if getKey is supposed to stop working if direct input is also used somewhere later in the program?   12:40:53 AM
MateoC   Huh?   12:41:26 AM
MateoC   idk what PT_ did, but it's probably wrong Tongue   12:41:53 AM
DJ Omnimaga   yeah   12:41:57 AM
DJ Omnimaga   Now i can't get past the it RPG is logo   12:42:05 AM
MateoC   Yes it won't work right   12:42:28 AM
MateoC   Because however PT_ did direct input it probably also disabled interrupts   12:43:00 AM
DJ Omnimaga   Oh I see   12:46:50 AM
DJ Omnimaga   Is there a workaround? Big Frown   12:47:01 AM
DJ Omnimaga   Oh also   12:47:08 AM
DJ Omnimaga   I commented out the code that checks if the user pressed any key (and quit if it's Clear),   12:47:31 AM
DJ Omnimaga   and the result was a crash followed by a Ram clear
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 05, 2016, 08:22:15 am
Welp, yep, it seems ICE v1.5 is broken somewhere. I guess it's not just direct key input, but also something with loops. I will try to fix it :)
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 05, 2016, 08:59:31 am
And... I fixed it! The problem was that something with the standalone getKey (without direct key input) causes the carry flag to be set, and then returns to the main loop. Now ICE reads that the carry flag was set, and will stop parsing. I fixed it and it works fine :D I will reupload it!
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 05, 2016, 11:25:33 pm
Fixed some bad stuff... just redownload and I hope it will be all fine :)
Title: Re: ICE Compiler
Post by: xlibman on December 06, 2016, 12:35:24 am
Downloaded, but now I get an error at Line 88 ???

DJ Omnimaga   welp   8:06:21 PM
DJ Omnimaga   now ice gives an error on line 88 x,x   8:06:26 PM
DJ Omnimaga   det(42,178-A,A,(2*A)-36,4   8:06:34 PM
DJ Omnimaga   det(42,X,Y,WIDTH,HEIGHT)FillRectangle_NoClip

I did not change my code since the version I sent you the other day. I think you broke the math operators inside FillRect_NoClip arguments, because det(42 now only works if the arguments don't have any +, -, * and / symbols D: . It seems that real(60 is affected to, so perhaps it's a problem accross the entire program now D:

Suggestion for the commands list: Below each special token, add the original token name in gray italic text (maybe smaller). Also maybe add the corresponding TokenIDE/SourceCoder equivalent.
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 06, 2016, 11:11:24 am
Fixed and updated:

https://tiplanet.org/forum/archives_voir.php?id=587211

I will add the original token in the commands list in the next version.
Title: Re: ICE Compiler
Post by: xlibman on December 06, 2016, 07:49:56 pm
By the way, would it be possible for next versions to make ICE Compiler so that if a compiling error happens, it returns the exact line of code in 3-bits unsigned integer format rather than 1 bits? Else if the error is past line 255 it gets confusing >.<

Another idea could be to make it like Axe Parser, where if the source code is in RAM, if you press PRGM on an error, it goes straight to the Program editor at the line of code in question. But I remember that in Axe it took ages before this feature becomes stable, since on Unknown errors it usually went berserk.


EDIT I tried the fixed version and now the game compiles perfectly. Only one issue I forgot to mention in previous version, though: The [ character shows up as garbage, while the ] works fine with the text routines.


EDIT: Feature suggestion: getKey(0). Basically, a direct input command that checks if any key is pressed (returns true if that's the case).
Title: Re: ICE Compiler
Post by: PT_ on December 06, 2016, 11:40:24 pm
By the way, would it be possible for next versions to make ICE Compiler so that if a compiling error happens, it returns the exact line of code in 3-bits unsigned integer format rather than 1 bits? Else if the error is past line 255 it gets confusing >.<

Another idea could be to make it like Axe Parser, where if the source code is in RAM, if you press PRGM on an error, it goes straight to the Program editor at the line of code in question. But I remember that in Axe it took ages before this feature becomes stable, since on Unknown errors it usually went berserk.


EDIT I tried the fixed version and now the game compiles perfectly. Only one issue I forgot to mention in previous version, though: The [ character shows up as garbage, while the ] works fine with the text routines.


EDIT: Feature suggestion: getKey(0). Basically, a direct input command that checks if any key is pressed (returns true if that's the case).
Yes I just realized this is a very stupid bug... I will definitely solve it ;)

Well, this would be hard, if experienced ASM programmers took at least some months to get it working right.. don't expect too much from my side :trollface:

Yes, but maybe this is the C library, which has some different characters than the TI-OS set, need to figure out though.

Ah yes, seems interesting, I will try to add that :)
Title: Re: ICE Compiler
Post by: xlibman on December 06, 2016, 11:43:33 pm
Did the lines bug involve going from 99 to :00, then other weird characters? I noticed this happens with variable display when its value is higher than thea mount of digits you want to show, such as 10,000 displaying as :0000 and 17000 displaying as A000.

As for [ maybe @MateoConLechuga might want to look into why the [ char doesn't look right. Maybe a sprite went missing or a typo happened?
Title: Re: ICE Compiler
Post by: PT_ on December 06, 2016, 11:44:56 pm
Did the lines bug involve going from 99 to :00, then other weird characters? I noticed this happens with variable display when its value is higher than thea mount of digits you want to show, such as 10,000 displaying as :0000 and 17000 displaying as A000.

As for [ maybe @MateoConLechuga might want to look into why the [ char doesn't look right. Maybe a sprite went missing or a typo happened?
No, it was supposed to divide the line number by 10 all the times, and then take the remainder and store it as a string. But it didn't get divided by 10 all the times, but other numbers.
Title: Re: ICE Compiler
Post by: MateoConLechuga on December 07, 2016, 12:41:47 am
As for [ maybe @MateoConLechuga might want to look into why the [ char doesn't look right. Maybe a sprite went missing or a typo happened?
ICE doesn't convert characters to ASCII. Not a problem with the libs :P
Title: Re: ICE Compiler
Post by: xlibman on December 07, 2016, 04:54:22 am
Ah ok. I thought this was weird that only this character in particular had this problem :P

As for the line numbers, thanks for the explanation PT_ .
Title: Re: ICE Compiler
Post by: PT_ on December 07, 2016, 07:07:58 am
As for [ maybe @MateoConLechuga might want to look into why the [ char doesn't look right. Maybe a sprite went missing or a typo happened?
ICE doesn't convert characters to ASCII. Not a problem with the libs :P
Is that supposed to do it? It just converts them to the TI-OS font, which is much more logic in my opinion.
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 07, 2016, 07:24:26 pm
Guess what?

(https://i.imgur.com/9YGpAJo.gif)

Took me about 6 hours, and the solution was very simple :P
Title: Re: ICE Compiler
Post by: xlibman on December 07, 2016, 07:53:01 pm
Awesome. You even got instant goto working. :D

Does it work with any code size and 2-byte tokens?
Title: Re: ICE Compiler
Post by: PT_ on December 07, 2016, 07:59:19 pm
Awesome. You even got instant goto working. :D

Does it work with any code size and 2-byte tokens?
If everything went right, yes :trollface: Otherwise not, and then I need some more debugging :P
Title: Re: ICE Compiler
Post by: xlibman on December 08, 2016, 01:24:38 am
Bug report: Numbers can't be used into executable program names. If your header is something like [i]TEST2, the compiler gives an unsupported token error on Line 1.


Also I just tried the L4+Storepic trick and it doesn't work. Because when you run an ICE program, it clears out L4 content upon startup D:. So I guess I'll have to wait a little longer before external saves are supported D:


EDIT: Feature suggestion: Support for Cesium and Doors CE icons
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 08, 2016, 09:56:44 am
Yep, I was aware of that bug, should be fixed quickly.

Oh well, that's a silent poke to add external variable storage? ;)

Yeah sure, also a nice feature, although for now only Cesium as it seems DoorsCE won't come out in months.

I'm currently working on displaying sprite with an index which is not a constant, but that doesn't work right now :trollface:
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 08, 2016, 11:32:16 pm
Added some stuff and fixed many bugs... the main change is that you don't need an index with DefineSprite(), it will now automatically insert that. To 'compensate' this, you can now display sprites with a variable index, like A+3 or even getKey, but be sure that sprite IS defined, otherwise you will get weird stuff :trollface:

Download: https://tiplanet.org/forum/archives_voir.php?id=587211
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: p2 on December 08, 2016, 11:37:09 pm
Nice ^^  :)
seeing all those posts about ICE makes me wish I had the time (and a CE) to try it out, too >.<
Title: Re: ICE Compiler
Post by: xlibman on December 09, 2016, 12:34:42 am
Awesome to see we can now display sprites from a variable index. I think this is a must for games with multiple sprites :)

Also the commands list should probably specify that lists and indexes start at zero, in case people are unsure.
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 10, 2016, 10:05:09 pm
I've uploaded a new version, which adds ReturnIf <exp>, which could be useful, along with many bugfixes nobody knows of. Also I will try to give you some examples about optimization of ICE code:

2+(2*A) can be (A+1)*2

If A=1 can be If not(A-1

For loops where the variable is not used, can maybe be optimized to a 'small For loop', like For(39

Repeat K:getKey->K:End can be Repeat getKey->K:End

66+(32*(B/4)) can be B/4*32+66

Download:
https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/ICECompiler.zip
https://tiplanet.org/forum/archives_voir.php?id=587211
Title: Re: ICE Compiler
Post by: xlibman on December 19, 2016, 05:35:03 am
Ooh nice update. Thanks for the optimization tricks. Will you include them in the readme in the future? That could be handy :)

Also I didn't know we could do Repeat getKey->K O.O
Title: Re: ICE Compiler
Post by: PT_ on December 19, 2016, 09:36:38 am
Ooh nice update. Thanks for the optimization tricks. Will you include them in the readme in the future? That could be handy :)

Also I didn't know we could do Repeat getKey->K O.O
No problem. You can do litereally everything in the Repeat condition as what you normally do, outside of functions, so Repeat getKey->K-3->L1(A)->B is definitely valid :trollface: but Repeat ClrHome is not valid, if I'm right :)
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 21, 2016, 09:54:23 pm
In case you didn't know, I'm making a new game in ICE for Cemetech Contest 18: Snowball Struggle

(http://i.imgur.com/tTKrjND.gif)

It is almost done, but I won't upload it before next Monday, as it is a competition ;)

(it seems to crash at the end of the gif but I already fixed that)
Title: Re: ICE Compiler
Post by: xlibman on December 21, 2016, 09:59:19 pm
I like it so far. I wasn't sure if this was made with ICE or C earlier. Glad to see ICE capabilities being showcased again. I hope this evolves into a full standalone game on ticalc :) (as well as GalagICE)


By the way, do you still plan to add the ability to store stuff into external lists in future releases or even appvars? That would be handy for highscores :) (especially that GalagACE supported highscores :P)
Title: Re: ICE Compiler
Post by: PT_ on December 21, 2016, 10:01:17 pm
By the way, do you still plan to add the ability to store stuff into external lists in future releases or even appvars? That would be handy for highscores :) (especially that GalagACE supported highscores :P)
Yes, but I don't know when, as I have 0% motivation to make big changes :(
Title: Re: ICE Compiler
Post by: xlibman on December 21, 2016, 10:05:37 pm
SOrry to hear. D:

If all else fails, have you considered adding a new command that allows users to prevent ICE games from clearing L4 on startup? Everytime I launch an ICE program, L4 content is pretty much cleared and it would be nice if it was possible to keep what was left behind in it from the last time we launched an ICE program so that we can re-use that data in another ICE program. In summary, this would make the StorePic/RecallPic trick possible.
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 24, 2016, 03:13:20 pm
I've finished the game! I've created 17 levels, from simple to extreme, the last one is almost unbeatable. I will upload it next week to the Archives (including the source) so that you guys can play it too. In the meantime, enjoy this screenshot :)

(https://i.imgur.com/9gwN9P5.gif)

There are 2 Easter Eggs, one is pretty hard to trigger, but it maybe helpful. The other one was added accidentally, I was just playing and then I noticed it :P



ICE remark: I'm busy with adding pointers, currently debugging it, and it saved me 500 bytes lol
Title: Re: ICE Compiler
Post by: xlibman on December 25, 2016, 05:12:29 am
Glad to see this finished. Good luck with the contest :) This looks very polished by the way :).

Also good luck with ICE pointers. From the IRC convo earlier, they seemed tricky to implement >.<
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: p2 on December 26, 2016, 12:24:52 am
well it did look like a really nice game but I didnt expect it to look that cute in the end, I really like it  :thumbsup:
what happens if you "shoot" multiple times without moving? WIll a single snowball then be able to break the stacked arrows all at once? ^^

the only thing that might be optimized is the death... I think the snowballs should continue falling down after your death but then sink in 50% an freeze (so you have snow hills in the end) instead of them disappearing ^^
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 27, 2016, 01:33:47 pm
well it did look like a really nice game but I didnt expect it to look that cute in the end, I really like it  :thumbsup:
what happens if you "shoot" multiple times without moving? WIll a single snowball then be able to break the stacked arrows all at once? ^^

the only thing that might be optimized is the death... I think the snowballs should continue falling down after your death but then sink in 50% an freeze (so you have snow hills in the end) instead of them disappearing ^^
Thanks :D Well, you can't double shoot, without 1 powerup, so you can't break a ball immdeiately twice ;)
You mean that after death, all the balls will only fall once, and then 'melt at the ground'?

Btw, a second game/puzzle is incoming :)

(https://i.imgur.com/oNIRjek.gif)
Title: Re: ICE Compiler
Post by: xlibman on December 28, 2016, 06:35:23 am
That's some fast puzzle-solving PT :P

Nice job, though :D
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on December 29, 2016, 08:01:38 pm
Last update:

(https://i.imgur.com/Oyl5W6D.gif)

I will only change something if someone asks ;)

Side note: the shuffling looks fast, but it can be even faster, because I added a Pause in it
Title: Re: ICE Compiler
Post by: xlibman on December 30, 2016, 06:43:14 am
Oh, now you gave me an idea for a new ICE feature: Inverted rectangles and Inverted filled rectangles. xLIBC and HP PPL both have this and it's quite nice. Otherwise, a color shift feature like xLIBC (eg color 0 becomes color 5, color 10 becomes color 15 and color 255 becomes color 5) has would work as well.

If it's too hard to implement as rectangles then on pixel basis would do the job as well


Nice game update by the way :)
Title: Re: ICE Compiler
Post by: PT_ on December 30, 2016, 11:26:03 am
Oh, now you gave me an idea for a new ICE feature: Inverted rectangles and Inverted filled rectangles. xLIBC and HP PPL both have this and it's quite nice. Otherwise, a color shift feature like xLIBC (eg color 0 becomes color 5, color 10 becomes color 15 and color 255 becomes color 5) has would work as well.

If it's too hard to implement as rectangles then on pixel basis would do the job as well


Nice game update by the way :)
I believe color shifts is already implement in C, gfx_Lighten or gfx_Darken, but yet not in ICE, but (almost) all the C functions will be implemented in the new version of ICE, which I'm currently very hard working on. If I'm not right, you should poke @MateoConLechuga :P
Title: Re: ICE Compiler
Post by: xlibman on December 31, 2016, 06:20:59 am
Oooh cool. :D Also I just saw the version added on ticalc.org. Is it more recent than what you last posted?
Title: Re: ICE Compiler
Post by: PT_ on December 31, 2016, 09:31:35 am
Oooh cool. :D Also I just saw the version added on ticalc.org. Is it more recent than what you last posted?
I don't know, I recently updated it at ticalc.org. The latest version is ALWAYS at TI-Planet, and almost ALWAYS at Cemetech, and whenever I like it, I will upload on ticalc.org too ;)
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on January 07, 2017, 04:22:39 pm
I just want to say that pointers are implemented, but almost everything else is broken, and I want to implement a lot more functions, and I'm working on AoCE, so don't expect a new update soon ;)
Title: Re: ICE Compiler
Post by: xlibman on January 07, 2017, 07:54:16 pm
Good luck fixing the other issues you have when you decide to work on this again. Pointers addition will definitively be awesome :3=
Title: Re: ICE Compiler
Post by: xlibman on January 18, 2017, 05:13:30 pm
So I just saw that Snowball Struggle has been released last month via a TI-Planet news and I will definitively give it a try soon. :).
Title: Re: [TI-84 Plus CE] ICE Compiler
Post by: PT_ on January 18, 2017, 07:29:11 pm
I updated ICE, the size went from 18kB to 10kB using Mateo's program compressor ;)

Download:
https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/ICECompiler.zip
https://tiplanet.org/forum/archives_voir.php?id=587211

Also, if you still didn't know, I made a new game in ICE, Snowball Struggle
Download: https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/games/SnowballStruggle.zip
https://tiplanet.org/forum/archives_voir.php?id=810889
Title: Re: ICE Compiler
Post by: xlibman on January 18, 2017, 07:45:29 pm
That is cool. MateoC seems to have done a pretty good job with his compressor. It reminds me of CrunchyOS for monochrome calcs, except as standalone programs rather than requiring a shell. :)

I wonder if ICE games are compatible with the compressor? Opossum Massage Simulator is quite large because of all graphics.
Title: Re: ICE Compiler
Post by: PT_ on January 18, 2017, 07:47:20 pm
I wonder if ICE games are compatible with the compressor? Opossum Massage Simulator is quite large because of all graphics.
Yep, you can compress any ASM program with his program, and the best compression was about 60%, if I'm right, so maybe you have luck ;)
Title: Re: ICE Compiler
Post by: xlibman on January 18, 2017, 07:51:19 pm
Ah nice. That said convhex doesn't appear to let me choose the output file name, so if I try to compress opossum.8xp it overwrites itself D: (EDIT Nevermind, it creates a new file with an underscore at the end of the file name). Opossum compresses to 8400 bytes or so instead of 24800 bytes *.*
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on March 20, 2017, 02:15:47 pm
Output( and running a BASIC subprogram now works!

(http://i.imgur.com/OyNCvfy.gif)

Note: I don't do any error-checking, so please be sure your BASIC program works fine, I can't guarentee what would happen if you have an error in it :P

Download:
https://tiplanet.org/forum/archives_voir.php?id=587211
https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/ICECompiler.zip
Title: Re: ICE Compiler
Post by: xlibman on March 20, 2017, 04:08:33 pm
Awesome. By the way, Sin() Cos() Tan() Walrii()
Title: Re: [TI-84+CE] ICE Compiler
Post by: Alvajoy123 on April 02, 2017, 11:38:11 pm
Whats wrong with ICE  >:(
it messed up when i was playing pong i can not see the ball or anything but colors  >:(
Title: Re: ICE Compiler
Post by: _iPhoenix_ on April 02, 2017, 11:49:48 pm
Whats wrong with ICE  >:(
it messed up when i was playing pong i can not see the ball or anything but colors  >:(

Do you have source?
Or is it the default example?
Title: Re: [TI-84+CE] ICE Compiler
Post by: Alvajoy123 on April 03, 2017, 12:25:11 am
 
Whats wrong with ICE  >:(
it messed up when i was playing pong i can not see the ball or anything but colors  >:(

Do you have source?
Or is it the default example?
i have a default example

i need this for Linux please help  :w00t:
Title: Re: ICE Compiler
Post by: xlibman on April 03, 2017, 04:22:57 pm
You might want to try different program examples. Pong was made in the earlier days of Ice and I don't even know if it was updated to work on more recent versions. I remember having issues with it before, too.
Title: Re: [TI-84+CE] ICE Compiler
Post by: Alvajoy123 on April 08, 2017, 06:21:32 am
Um while what is define Sprite
And where do you get it  :-|

Do you type it in?
???

And can it be use with other libs such as testlib libload and much more libs
Title: Re: ICE Compiler
Post by: xlibman on April 08, 2017, 02:19:43 pm
You need to use Convpng which is included somewhere in MateoConLechuga's Github repo for the CE toolchain. It will generate hexadecimal
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on April 12, 2017, 09:09:21 pm
In Case of Emergency (ICE..), you can join #icedev for (almost) instant help :)
Title: Re: ICE Compiler
Post by: xlibman on April 12, 2017, 11:20:41 pm
Ok thanks for the heads up.
Title: Re: [TI-84+CE] ICE Compiler
Post by: Alvajoy123 on April 13, 2017, 02:39:12 pm
thank for the heads up  :thumbsup:

one more problem in ice when you fill the screen with the color u what other shapes come up why is that
Title: Re: ICE Compiler
Post by: xlibman on April 16, 2017, 11:58:24 pm
Could you rephrase Alvajoy? I'm unsure if I understand what you mean
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on April 17, 2017, 05:50:13 pm
No the fillscreen command doesn't add 'other shapes', it's just you using it wrong.
Title: Re: ICE Compiler
Post by: xlibman on April 18, 2017, 02:14:49 pm
What's ICE Compiler by the way?














But seriously, yeah I suspect he did something wrong. Also remember: Always back up your progress often when testing ICE code. It's not like TI-BASIC. TI-BASIC will give an error if the code is wrong. ICE, ASM, C and most BASIC add-in libs will delete your RAM content. Heck, even pure TI-BASIC can delete your RAM apparently if you trigger a TI-OS bug. Always keep your data safe.
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on April 21, 2017, 08:13:51 am
We are more than happy to announce that the online TI-BASIC editor and IDE SourceCoder 3 (https://cemetech.net/sc/) gets an upgrade again. You have now the possibility to compile ICE programs (https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/ICECompiler.zip) online, rather than doing it on-calc! The syntax is basically the same as TI-BASIC, but you don't need a "Then" for indentation. While the highlighting is exactly the same, except the commands of course, we are still working on a nice styling system for ICE, to make it even easier to write programs! But, you say, why can't we use the TI-BASIC section of SourceCoder 3? That is very simple: ICE has a lot of graphic commands, imported from the C libraries, and replaced them with det(XX..). From now on, you don't need to remember this anymore, you can just directly type "FillScreen(255)" for example!

In the sidebar you can see some groups, which are the same groups as listed in commands file of ICE Compiler, to make it even easier! Also, you can easily add comments as well, in order to explain variables or routines to yourself. You can do this by placing "//" in front of the line, the same as in with BASIC.

As far as we know, there is only 1 thing to mention:
Anyway, we hope that this makes development of ICE programs much easier, and we are happy to receive feedback and or questions/comments about this!

Launch Tool:
(https://www.cemetech.net/img/icon/dl.gif) SourceCoder 3 Online TI-BASIC, ASM, and C Editor and IDE (https://cemetech.net/sc/)

(https://i.imgur.com/ujeH8BX.png)

Many thanks to KermMartian for helping me in this process, correcting me when needed, and moving it to the real website!

Source: https://www.cemetech.net/forum/viewtopic.php?t=13679
Title: Re: ICE Compiler
Post by: xlibman on April 21, 2017, 11:18:13 pm
I'm happy to see SourceCoder support ICE. I liked SourceCoder since it seemed easier with it to work with the Minus symbol (as in, the smaller -, not the substraction one)
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on May 01, 2017, 09:24:59 pm
So well, yeah, time for some updates, or whatever you call it. As you might already know, I'm recreating ICE in C to make development faster, and easy add new features. This is coming along very well, I need to say. Currently numbers, variables, operators and parenthesis are supported (still need code for every operator), and more are coming soon. However, I'm running into a huge problem, and that are C functions. They are not like 'normal functions', such as not( and remainder( and so on. For the last type of tokens, I just add code for every possible argument type(s), rather than using the stack, like C functions need. However, this method simply doesn't apply to C functions, as they are supposed to take the input (arguments) from the stack, not registers etc. Thus, with the Shunting Yard Algorithm I'm doing, it is VERY hard to add C functions, and I'm not sure yet how to solve this. Let's take a look at some example:
Code: [Select]
det(2,det(15,X+2->X                 2 15 X 2 + det( det( X ->

det(2,det(15,X)+2->X                2 15 X det( 2 + det( X ->

det(2,det(15),X+2->X                2 15 det( X 2 + det( X ->

det(2,X+det(15),2->X             2 X 15 det( + 2 det( X ->

det(2,X,2*det(15))+3->X             2 X 2 15 det( * det( 3 + X ->

2*det(15,X)+3->X             2 15 X det( * 3 + X ->

det(2,X+2,1,2,3     2 X 2 + 1 2 3 det(
Left is the input, right is the input in infix notation.

Now let's take my last example. If I just parse them as normal, first the "+" is parsed, so X+2, but since the output isn't used in the next 2 elements (as an operator or function), the output is pushed to the stack, and that is where problems arise, it should not even parse the +. First 3, then 2, then 1 should be pushed, afterwards X+2 parsed and pushed, then the det( function will be called.

Again, I've no idea how to solve this, and I'm open for any ideas! :)


Progress: I've added icon and description support:
(https://i.imgur.com/CECPVua.png)
Title: Re: [TI-84+CE] ICE Compiler
Post by: E37 on May 07, 2017, 09:32:51 pm
Very fancy!
What does the det( command do? (in ICE)
Title: Re: [TI-84+CE] ICE Compiler
Post by: xMarminq_ on May 07, 2017, 11:44:46 pm
Detect? IDK
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on May 08, 2017, 09:35:30 am
det( is the start of a C function, for example det(0 is "Begin", det(5 is "FillScreen" etc.
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on May 08, 2017, 04:03:47 pm
I've added SetBASICVar( which... sets a BASIC variable! :D

Download: https://tiplanet.org/forum/archives_voir.php?id=587211
Title: Re: ICE Compiler
Post by: xlibman on May 08, 2017, 06:40:33 pm
OMG does this mean external saves are now supported? O.O Also does it set to real vars?
Title: Re: ICE Compiler
Post by: PT_ on May 08, 2017, 06:41:46 pm
OMG does this mean external saves are now supported? O.O Also does it set to real vars?
You can now store integers to the real BASIC variables A-theta :)

(http://i.imgur.com/wcDwvzg.gif)
Title: Re: ICE Compiler
Post by: _iPhoenix_ on May 08, 2017, 07:43:57 pm
That's great, but is the progress bar through the "Successfully compiled" a gif glitch?

EDIT: Perhaps add the ability to edit/read BASIC programs or AppVars (i.e. files), token by token.
EX: editFile(*file*, *token number, from start*, *token to change to*)
EX: readFile(*file*, *token number, from start*)
EX: checkFile(*file*, *token number, from start*, *token to check for*
The last one would return 1 if the token indicated in the specified file was the same as the token to check for.

Perhaps make 'token' byte, even, that would be easier to handle, I'd think (but take what I think with a grain of salt)


Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on May 08, 2017, 11:24:36 pm
I'm SUUUUUPPEERRRRR excited to announce this very great news:

https://ice.cemetech.net (http://ice.cemetech.net)

It redirects you to a page at Cemetech Learn, where I will put all the needed information, and Tips and Tricks! :D
Title: Re: ICE Compiler
Post by: xlibman on May 09, 2017, 05:07:26 am
Nice :D. Also I'm happy to see real vars supported. Are their content preserved when entering or exiting an ICE program, though (unlike Pic4)? :P
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on May 09, 2017, 10:54:18 am
As long as other BASIC programs don't overwrite them ;) I'm working on GetBASICVar( as well, to eventually get the highscore :D
Title: Re: ICE Compiler
Post by: xlibman on May 09, 2017, 09:33:36 pm
Yeah I was mainly wondering, so that using BASIC code, people can do things like this:

{A,B,C,D,E,F,G,H,I,J,K,L,M,N,O,P,Q,R,S,T,U,V,W,X,Y,Z->L1
Title: Re: ICE Compiler
Post by: _iPhoenix_ on May 09, 2017, 09:36:47 pm
I saw that the program you used had the "getBasicVar()" as a token. Is that due to the fact that you are programming it in C?
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on May 13, 2017, 03:34:55 pm
No, that is because ICE didn't had the possibility to interact with BASIC programs, but now you can.

Time for some quick updates about my C version: I've implemented all the operators, and added code for functions, which work fine, I only need to add them :P Chaining things also work, so the only thing I need to do is doing weird stuff with C functions and get that working :)
Title: Re: ICE Compiler
Post by: xlibman on May 13, 2017, 05:05:56 pm
The combination of the ability to run BASIC sub-programs and being able to store to real vars in ICE will be very handy I think, for people like @Pieman7373 who wants to make JRPGs or people who wants to have highscores in their games.

And maybe @PT_ could finally finish GalagICE :P
Title: Re: [TI-84+CE] ICE Compiler
Post by: Alvajoy123 on June 21, 2017, 09:23:25 am
@PT_
:thumbsup: like the update

But can make command that can make appvars strs and vars

And can you give the user more freedom by adding costum logos  ;)

And add some Sprites commands for game etc.

And one bug when you try inputing a costum
command by press trace the screen messes up the screen

Can you show us some pictures of the program in this stage  :P

Your doing good keep up the good work
Title: Re: ICE Compiler
Post by: _iPhoenix_ on June 21, 2017, 05:36:30 pm
@Alvajoy123

What do you mean by "costum logos"?
IIRC there are sprite commands, check the documentation, though.
For the bug, can you please provide code/screen shots?

Agreed <3
Title: Re: ICE Compiler
Post by: Alvajoy123 on June 21, 2017, 07:26:26 pm
@Alvajoy123

What do you mean by "costum logos"?
IIRC there are sprite commands, check the documentation, though.
For the bug, can you please provide code/screen shots?
By costum logo a way to make there own logo for cemuim

Does it have have a way to make tittle maps

The bug has no code it when u press [trace] and choose a command the srceen messes up try it for your self
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on June 21, 2017, 07:33:57 pm
Adding your own Cesium icon is already added in the C version, but not the ASM version. Whenever the C version is ready, you can use it. You can't use appvars/strings yet, that is going to be in the C version as well.

Thanks for the bug report, I will fix that asap!
Title: Re: [TI-84+CE] ICE Compiler
Post by: Alvajoy123 on June 22, 2017, 04:02:44 am
@PT_

Adding your own Cesium icon is already added in the C version, but not the ASM version. Whenever the C version is ready, you can use it. You can't use appvars/strings yet, that is going to be in the C version as well.

Thanks for the bug report, I will fix that asap!

Will there be any tittle maps and more Sprite commands in the C program

And when will the C program come out :p

What are you using to program ice in C ???
Title: Re: ICE Compiler
Post by: _iPhoenix_ on June 22, 2017, 05:22:52 am
I'm not PT_,but I hope I can help! #iPhoenixToTheRescue

1) Probably not. The current list of sprite commands seems pretty complete to me, but there might be a few that could be implemented.
2) When he finishes it :P
3) He is using Notepad++ (I saw it in HCWP, which is a Cemetech thing) along with the C compiler, which is part of the C tool chain IIRC.
Title: Re: ICE Compiler
Post by: Alvajoy123 on June 22, 2017, 06:14:23 am
I'm not PT_,but I hope I can help! #iPhoenixToTheRescue

1) Probably not. The current list of sprite commands seems pretty complete to me, but there might be a few that could be implemented.
2) When he finishes it :P
3) He is using Notepad++ (I saw it in HCWP, which is a Cemetech thing) along with the C compiler, which is part of she C tool chain IIRC.
@PT_
Kind of sad if it has no tittle maps :'(

And how do you make a Sprite character
How do you the Sprite character move ???

Can you make it in a way where you can put 2 or more programs into one program  (-_(//));

That will be cool
Title: Re: ICE Compiler
Post by: _iPhoenix_ on June 22, 2017, 02:13:18 pm
Tile maps are not really needed. We have lists!

Check the documentation
1: Erase the sprite. 2: Redraw the sprite a few pixels away in the desired direction. 3: Rinse and repeat.

You can already, I recommend checking the documentation, it's very informative, even if it is scary at first :)
Title: Re: ICE Compiler
Post by: Alvajoy123 on June 22, 2017, 04:35:59 pm
Tile maps are not really needed. We have lists!

Check the documentation
1: Erase the sprite. 2: Redraw the sprite a few pixels away in the desired direction. 3: Rinse and repeat.

You can already, I recommend checking the documentation, it's very informative, even if it is scary at first :)
@PT_
What is the link to the document because I think the one I have is outdated
Title: Re: ICE Compiler
Post by: _iPhoenix_ on June 22, 2017, 05:29:17 pm
Download the ICE compiler program from here (https://www.cemetech.net/programs/index.php?mode=file&id=1481)

Open the folder, and double tap the document called "commands.hrml"

It should open in your preferred browser.
Title: Re: ICE Compiler
Post by: Alvajoy123 on June 22, 2017, 05:56:12 pm
Download the ICE compiler program from here (https://www.cemetech.net/programs/index.php?mode=file&id=1481)

Open the folder, and double tap the document called "commands.hrml"

It should open in your preferred browser.
Thanks I was outdated
By 4 or 5 commands

I do have questions about some of the command

Which is better clipped of no clip ???
Title: Re: [TI-84+CE] ICE Compiler
Post by: p4nix on June 22, 2017, 06:12:12 pm
Clipping allows the sprite to be outside of the screen. So, it can render half a sprite if the other half is outside of the screen (for example x=-8).
If you, for example, write a tile engine with smooth scrolling, you want to use clipped functions (at least for the outside tiles) in order to be able to let them go smoothly out of the screen.
However, clipping requires checking whether the coordinates are out of the screen or not, which makes it slower.
So, you got to decide whether the thing you draw might go off the screen or not, and based on that decide if you need clipping or not. If not needed, you could in theory always use clipping but as I said this will be slower.
Title: Re: [TI-84+CE] ICE Compiler
Post by: Alvajoy123 on June 23, 2017, 08:12:59 am
@PT_
Where do you put the Sprite file made by Covpng
Title: Re: ICE Compiler
Post by: _iPhoenix_ on June 23, 2017, 01:39:05 pm
Where the documentation tells you to put it.  :banghead:
(click to show/hide)

Edit:
Dammit I can't spell!
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on July 17, 2017, 03:32:53 pm
I had finally a free day off, which means I had a lot of time for programming :D

Today, I added Asm(, ReturnIf, remainder(, Lbl, Goto, Output( and Disp. The days before, in my spare free time, I added strings + string concatenation (like "ABC"+Str1) and length(. I have the framework done for sub( and toString(, both will be implemented soon :)

As far as I know, this is my to-do-list until the first C version release:
If you have suggestions on what to add more, feel free to nag me, I'm now in the mood for adding things :)
Title: Re: ICE Compiler
Post by: xlibman on August 14, 2017, 06:45:41 pm
I'm kinda late but have you gotten any luck adding any of the above features since your post, especially pointers?
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on September 04, 2017, 03:30:46 pm
Good news! I added GetPixel( in the ASM version! :D
It's still a bit primitive, the syntax should look like this:
Code: [Select]
det(7,<expression>,<expression>)-><variable>. You do need the closing parenthesis, otherwise it won't work.

Download: https://www.cemetech.net/programs/index.php?mode=file&path=/84pce/asm/programs/ICECompiler.zip

(http://i.imgur.com/McufX7r.png)
Title: Re: ICE Compiler
Post by: xlibman on September 06, 2017, 12:16:07 pm
GetPixel will be very handy o.o . I remember many games in the past used such collision detection. Can it pixel test from both VRAM?
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on September 06, 2017, 01:14:58 pm
Yes, it's the same as the C lib function, so it should work fine.
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on September 27, 2017, 12:27:35 pm
I'm ready with implementing everything, so it's time for bugtesting. I've tested all the non-expression functions, like If, Repeat, Call etc.
Also, it seems the icon and description works :D

(https://i.imgur.com/kdrkOVO.png)
Title: Re: ICE Compiler
Post by: xlibman on September 27, 2017, 05:47:32 pm
Yay, icons! Maybe someday I should update Opossum Massage Simulator so that it features highscores and an icon.
Title: Re: ICE Compiler
Post by: PT_ on September 27, 2017, 07:18:24 pm
Yay, icons! Maybe someday I should update Opossum Massage Simulator so that it features highscores and an icon.
I bet that OMS is now 5% smaller due to more heavy optimizations in ICE :P Anyway, I'm planning to add tilemaps soon, and then the final bugtesting can begin, which means the C version will probably be released within some weeks.
Title: Re: ICE Compiler
Post by: _iPhoenix_ on September 27, 2017, 09:06:45 pm
How does Cesium know that an ice program is written in ice, not assembly?
Title: Re: ICE Compiler
Post by: MateoConLechuga on September 27, 2017, 09:36:52 pm
How does Cesium know that an ice program is written in ice, not assembly?
The same way it knows a C program is written in C not assembly. ;)
Title: Re: ICE Compiler
Post by: _iPhoenix_ on September 27, 2017, 10:13:42 pm
How does Cesium know that an ice program is written in ice, not assembly?
The same way it knows a C program is written in C not assembly. ;)

I thought so. (That was actually more help than it may have seemed.)
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on September 29, 2017, 07:47:13 pm
I'm finally done with bugtesting, at least all my test programs work fine (during testing I solved another bug or 2), so it's time to share it with you guys. Feel free to download this ICE, please test all the edgy cases, and if there's an ICE ERROR: Please report it, please send me your source code, then I can try it as well :)

Things I still want to fix but that are not really important:
- Max label/variable name length
- More syntax errors at impossible cases
- All the remaining bugs lol

https://www.dropbox.com/s/ehk81xwu4foeil8/ICE.zip?dl=0
 
There is an .exe in the folder, it works exactly the same as the C version. Just run it with
Code: [Select]
ice <input program>, i.e.
Code: [Select]
ice SUM.8xp, and it will compile your program and output the program in the main directory. I know, I still need to rewrite the entire commands.html and documentation.pdf, but will do that later, so you guys have to do it without documentation ;)
Let me explain the most important changes, some others should be straightforward:
- Pointers. *{ } for 1-byte dereference, **{ } for 2-byte dereference and ***{ } or just { } for 3-byte dereference. The amount of nested { } is the level, so {{A}} gets the word at address at word at address A.
- Copy( copies arg3 bytes from arg1 to arg2. If there are 4 arguments, the first argument will be ignored, but the copy will be reversed (lddr instead of ldir)
- Data( returns a pointer to the data section in the program data. First argument should be the size of the next elements (1 = 8-bits, 2 = 16-bits, 3 = 24-bits). All the remaining elements will be inserted in the program data and it returns a pointer to this.
- L1-L6 are now pointers, so accessing the first element of L1 will be ***{L1+0} instead of L1(0).
- Alloc( allocated some memory, for example for rotating or enlarging sprites. Returns a pointer to the data.
- sum(... all the same as det(, but sum( is used for the FILEIOC lib. Sorry, won't show all the arguments needed, but you can select the right function in the program editor by pressing [TRACE].
- sin( cos(, range is [0, 255] (so 256 = 2*pi)
- String concatenation, storing, displaying
- for displaying a new line

And much more which I can't tell now. But have fun exploring ICE, and hopefully I can make it an official release soon! :D
Title: Re: ICE Compiler
Post by: _iPhoenix_ on September 29, 2017, 11:36:34 pm
so {{A}} gets the word at address at word at address A.

So it goes to the location stored in pointer A, gets the location stored there, and returns what it finds at the location?

Edit: I may be able to help with/do the commands file, if you want.
Title: Re: ICE Compiler
Post by: MateoConLechuga on September 29, 2017, 11:47:19 pm
so {{A}} gets the word at address at word at address A.

So it goes to the location stored in pointer A, gets the location stored there, and returns what it finds at the location?

Edit: I may be able to help with the commands file, if you want.
I think you are along the right lines. There is still a lot of confusion I feel on the difference between words and pointers; so here's how it works really quick: (Let's assume the variable A holds the value 5).

A is a pointer to an address, in this case 5.
{{A}} Returns the pointer stored at address 5. Let's say at address 5 this pointer holds the value 10.

So 30->*{A} would store the 1-byte value 30 to address 5.
But 30->*{{A}} would store the 1-byte value 30 to address 10.
Title: Re: ICE Compiler
Post by: _iPhoenix_ on September 30, 2017, 12:03:45 am
That’s what I meant.

I’ve read enough Assembly topics that I knew it was possible to do so, and inferenced (that’s a word, right?) my post from the info in those threads.

Multi-level pointers are things I never knew existed, but desperately need...
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on October 03, 2017, 11:57:59 am
Updated version:
- Fixed strings. Now 'w' or 'r' is actually a 'w' or 'r', and not the BASIC token. This means, however, that all BASIC tokens are converted to the characters, which means that "sin(" is now 4 bytes instead of 1 byte.
- Fixed the main bug reported by KryptonicDragon

https://www.dropbox.com/s/7a3qiexqgc2r01i/ICE_3.zip?dl=0
Commands: http://htmlpreview.github.io/?https://github.com/PeterTillema/ICE/blob/C-version/documentation/commands.html
Title: Re: ICE Compiler
Post by: xlibman on October 05, 2017, 05:43:54 pm
Good update ^^
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on October 05, 2017, 07:27:53 pm
Meanwhile I'm fixing much more (small) important bugs. You can always get the latest release here:
https://github.com/PeterTillema/ICE/releases
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on October 14, 2017, 09:29:04 pm
Several main bugs has been fixed, and tilemaps has been added, and much more, so just check it out!
http://htmlpreview.github.io/?https://github.com/PeterTillema/ICE/blob/C-version/documentation/commands.html
https://github.com/PeterTillema/ICE/releases
Title: Re: [TI-84+CE] ICE Compiler
Post by: shak0579 on October 16, 2017, 03:58:17 pm
Why dont you make more commands
Title: Re: ICE Compiler
Post by: _iPhoenix_ on October 17, 2017, 07:22:09 pm
Why dont you make more commands

Because he is a very busy person, who actually has a life.

Continuing to make high quantities of low quality posts is generally not acceptable, according to the rules, which you should have read.

No, I am not an administrator, but I feel that reprimanding other members to improve overall post quality is/should be a paramount responsibility of most users when the administration is incapacitated/busy/too awesome and amazing to care. (Which is OK, I think)
Title: Re: [TI-84+CE] ICE Compiler
Post by: merpaderp on October 18, 2017, 01:01:34 am
Well spending 2 to 3 hours on cemetech and graphing calculator sites is basically saying you have no life
Title: Re: [TI-84+CE] ICE Compiler
Post by: MateoConLechuga on October 18, 2017, 01:18:22 am
Well spending 2 to 3 hours on cemetech and graphing calculator sites is basically saying you have no life
No; it means that you have none. ;)
Title: Re: [TI-84+CE] ICE Compiler
Post by: c4ooo on October 18, 2017, 02:06:50 am
Well spending 2 to 3 hours on cemetech and graphing calculator sites is basically saying you have no life
No; it means that you have none. ;)
Wait are you agreeing with him? If so why did you start your paragraph with "no"? I am confused ???
Title: Re: [TI-84+CE] ICE Compiler
Post by: PT_ on October 18, 2017, 08:54:44 am
Well spending 2 to 3 hours on cemetech and graphing calculator sites is basically saying you have no life
Just sit in a corner and cry, to stop making dumb posts like this. Looking at the fact that you 'know' I'm more than 2 or 3 hours active means you are *active* at Cemetech as well, which means too, that you should know that I'm an admin over there. Being an admin means for me that I'm pro-active, chatting with other people, and whatever. Sure, I'm a lot online, but you don't f***ing know anything about my real life. Being 3 hours online means 21 hours offline. Minus 7 hours sleep on average, which leaves 14 hour per day to do cool things. How dare you to say that I don't have a social life, if you don't even know who I am, what my hobbies are, and what I'm doing in my free time?
Title: Re: ICE Compiler
Post by: merpaderp on October 19, 2017, 12:34:32 am
 I wasn't even talking to you. Geez
Title: Re: ICE Compiler
Post by: c4ooo on October 19, 2017, 01:40:16 am
I wasn't even talking to you. Geez
Well then who are you talking to? PT_ is the OP of this thread...
Title: Re: ICE Compiler
Post by: xlibman on October 20, 2017, 04:50:44 am
I wasn't even talking to you. Geez
True, but if someone posts something very negative towards another member, then the CodeWalrus rules allows anybody on the forums, including those who are not directly involved in the incident, to retaliate. Posting comes with responsibility. Although I have to say that I can manage to spend 3 hours on CodeWalrus and still have a life outside of it. ;)