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:



Do you like it? Wanna change something?

(Yes I know, this will take up 70K of RAM...)

Looks great! It's 70K of RAM at 8bpp, 320x240? Out of curiosity, why are the right and top margins different from the bottom and left margins? It bothers me, because it looks like a mistake, although I know you said it was a stylistic choice.

Yep, I think I need to fix that somehow
That white edges are not actually for the image, because I use a cut program of Windows to get the image from Windows

Ahhh, that makes sense. What program do you use for graphics manipulation? If you haven't tried GIMP, I recommend giving it a try. Anyway, as the users on SAX pointed out, there's a limit of 64KB of data stored in AppVars and programs. I therefore recommend coming up with a way to crop this, for example fading the edges to a solid color and filling the background with that solid color before adding this splashscreen on top.

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!

I've very happy to say that the Shunting Yard Algorithm works for 95%. I've implemented the normal operators, booleans, numbers of course, and if the token doesn't match, it pushes it to the stack. When the program reaches either a ',' or a ')' it will pop operators/booleans/functions from the stack to the output, until there is a '(' or a function which ends with '('. Sorry, still no screenshots!
I hope to finish it today, and maybe today or tomorrow I can start with actually parsing it and porting it to ASM

Just be patient...

EDIT: I got the functions ready. Now bug-testing, and then continuueeee!

Today I've 'worked' on creating the logo, here is my result:

or


Which one is better (I prefer the black background)

Happy to see that you are making good progress on this, as of now, do you know which commands will be available, which ones you might add and which ones will certainly not be available? Oh and I personally prefer the black one

I prefer the black one as well. And if you want to put in on a light background, I'd put it in a gray-bordered black rectangle to make it stand out.

*bump* How goes the coding and logo design? Have you been thinking about any new features or a more precise definition of what kind of language features ICE will offer yet?

Unfornately, I was this week pretty busy with exams, so not really time for designing/programming, but I have created some ideas in my mind for parsing RPN notation.

For the features, I will update the GitHub account of that:
https://github.com/PeterTillema/ICE/blob/master/Commands

But yea, I first need to finish parsing any mathematical expression, which is the hardest, but also the most important, and after that, I will be able to implement commands.

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







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: ld a, <number> / ld hl, <variable> / sub a, (hl)

EDIT: here is my table for multiplying a variable with a given number:

What if A was a floating-point number? Then just a sub wouldn't really work on it, would it?

For now, I assume that all the variables are 1-byte numbers. Later, I gonna add 3-byte numbers as well.

That table won't work for multiplying numbers greater than 32.... Might I recommend using the bootcode functions, or just copying them to RAM? You wouldn't even need to compile them into ICE, as long as you knew the jump table entry and the length of the routine, which then you could bypass the need for the pipeline stall.

You mean... if there are more than 2 division algorithms needed, compile the algorithm itself into the program, and call it from the program?

On another side, I've worked on the division algorithms, and they are much harder than the multiplication or so. Many, many thanks to Runer, who gave me insane routines to divide A by a known number, and now I got this table ready:


Dividing two variables is this code:

Code:

If you think you can make it shorter/faster, don't hesitate to post

For dividing numbers by variables, I'm just thinking about using the standard routines, available at WikiTI or so.

And then, after I got this ready, I can implement the ease routines, for BASIC commands like and, not(, ->, or and some more.

Well, good job. Although I doubt at this point that the performance boost will be that great, since you're going to be doing bcalls everywhere anyway.

I think a JIT would work best in the long run, rather than compiling 4000 bytes worth of a BASIC program into 10000 bytes of a program which would barely fit into RAM without turning it into a flash program. (Kerm's GRAPH3D for 84+CSE is 6567 bytes on my calculator.)

I definitely like the black background more.
Great work! This is an amazing project!
Its awesome that we are getting more programming techniques.

Please, please, please make this for the TI-84+CSE!!!!

I have thought about this, but since the OS works with TIOS variables, floating point numbers, this would barely decrease the executing time. For example, if you have A+B, you need
1) Search A
2) Copy it to OP1/OP2
3) Search B
4) Copy it to OP1/OP2
5) bcall(_FPAdd)
6) bcall(_StoAns)
or something like that. My guess is, that this would take at least 40 bytes without the bcalls, and thousands clock cyles. For comparison, my A+B would look like this: (unsigned 8-bits)

Code:

which is 9 bytes and 44 clock cycles. I think the compiled program would be MUCH faster, and I hope to prove it soon with screenshots!


Thanks! The syntax looks like normal BASIC, so that it shouldn't be hard to make the step to ICE


Not very likely. At first is the screen totally different, so any graphical command needs to be rewritten. And 2, the memory is only 22K or so, so you can't make big programs. When porting this to the CSE, is the same as rewriting almost the whole stuff. Also, the ez80 (CE) has more commands, like mlt hl which saves much bytes and thus cycles too.