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!

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

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 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!

How well does this work with the new commands introduce in OS 5.2? or will it work at all?

Only some specific tokens will be implemented, not necessary OS 5.2 tokens, so that doesn't mind. ICE will run on all the 5.X OS's.

Because it's possible, I added again a bunch of thinks.

• Added operators * and /. Together this took about 15 minutes (14/14 done)
  
• jacobly and I discussed some main points about where to store the output program (before it will be created). I figured out that if the output program size > 6500 bytes or so, then the calc will crash, because then it's bigger than the size of ICE itself, and other important data get overwritten. Instead, I located the stacks to saveSScreen and the output program to vRAM+320*240. There I will have 76800 bytes of free RAM, enough for a nice program
  
• Want to see speed? Here, ICE compiles a program which consists of 1200 lines full of "3+4-L1((3+A)-B->C+3->L1(4".
  
  (Real speed = ^ speed * 2)
  
• I've added a kind of statusbar, as you can see in the image, but it's only useful for pretty large programs.
  
• Bugfixes + less output size
  
• Fixed important bug with selecting a program from the list if you want to scroll.
  
• Added about 1000 bytes, not important
  
• If all goes right, ICE now triggers an error if you have not enough RAM to store the program, but I haven't tested it - it's hard to fill the 154kB
  
• Fixed the bug that added a "push hl" at the end of a program, for some reason.
  

Hopefully more are coming soon, at least I will try to finish it as soon as possible

Having some troubles with the compiler. I first tried to compile a (very long) program that I had been working on. It didn't reset, but the top of the screen went black with multicolored pixels. I had to hard reset it. I tried a simple project to test it, and my calc reset.
What the sample program was:
Disp "HI"
Disp 12+98
Disp 32/4
"1234"→Str1
Disp Str1
I triple checked that I was following the syntax to compile it. Any thoughts?

That's very likely. ICE v1.1 is still very limited, and cleary no error checking. That is also why I said to use Cesium or CEmu, because you have a high change that the calc resets. Anyway, the first 3 lines gives me no error (outside of incorrect results, I know), but in the 4th line, you store a string to Str1, which is not supported, also not in the new version. That is why "Disp Str1" will also not work.

In my new version v1.2 ICE will give an error, so no crash (I still can't promise anything), so please wait until that version is out (To be honest, I think that is within weeks, depends on how busy I am)

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:

• Disp - display both the result of an expression and a string, with only one Disp command! Example: Disp A+3,"ICE"
  
• Pause - pauses the program for some time in ms. If you pause a number, like Pause 1337, it waits exactly 48000*number-1 ms (outside of interrupts/DMA)
  
• If - exactly as you expected, If <statement>:<code>:End, no need for a Then, also not for a single line between the If statement and If
  
• Repeat - again as you expected. Repeat <statement>:<code>:End repeats executing <code> until <statement> is true. <statement> will be checked after <code> (post-test)
  
• While - same as Repeat, but then pre-test, just like BASIC
  
• ClrHome - clears the homescreen, this is important before you display stuff
  
• Input - a full routine to input a variable. Valid syntax is Input <variable>. Because the size is pretty large, this routine will be copied to the program data and called from the main program. Nothing is displayed in front of the input, that will come later
  
• For - wow, not recommend to do that Valid syntax is For(<variable>,<expression>,<expression>(,<variable/number>). The step-thing is important. If the token right afer the last comma (thus the first token of the step) is ~, then the variable goes backwards. You can add/substract either the value of a variable, or a number from <variable>, so this are the possible options: ~number, ~variable, number, variable.
  
• I fixed a main bug in the statusbar, at the last token, it didn't display the line to the right of the screen, but some pixels of.
  
• Both optimization and added again 1000 bytes or so, but nobody cares
  
• A very little bit auto-optimization, only noticable in For-loops
  
• Disp displays numbers at the right of the screen
  
• One small thing to keep in mind, that I still need 12 operators/booleans, and since = is not implemented, my code to check is A is even...: If A/2*2-A+1
  

So basically, this was it, and thus time for a nice screenshot!


Oops, I see that the loop size is not 100% correct...

Things to do:

• Cesium icon+description support
  
• Operators
  
• (custom) functions
  
• Auto-optimization
  
• Sprites, If/Else/End
  
• MAYBE running assembly subprograms
  

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

EDIT: For step = variable is fixed

Awesome progress! How does the ClrHome command work? The same as the OS's or a bit faster?

And, huh, I might have missed this, but did you ad some sort of compiling GUI?

Thanks! It calls first _HomeUp and then _ClrLCDFull, almost the same as the OS routine.

I definitely have, the statusbar, but you can't see it, because compiling goes too fast You only see that with pretty large programs.

Ah, ok, I see. About the GUI-type thing, I was talking about starting ICE and there being a menu where you can choose which program to compile.

EDIT: Aha, I see you have implemented such a GUI

So, is there any way for these compiled programs to communicate with anything else? It would be really useful to compile functions that are used often into ASM.

What do you mean by "communicate with anything else"?
Also, this is kind of what this project is meant to do (it speeds things up...) However it is not necessarily favorable to compile functions that you use often because the size of ASM programs is much greater than that of ti-basic programs. I think the best use for ICE would be in the event of loops that go around many times. In that case, it could be the smarter choice to hand over a bit of the size for a dramatic speed increase. Oh and for commands/functions that aren't available in ti-basic like drawing a rectangle.

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 ), 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!

No Mateo, I won't make it in C

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.

Why is width and height not a part of the data. Also, this setup means that the code will be filled with huge blocks of data...

Because my cat is black....






















The width and height shouldn't be only constants, but variables as well, so Sprite(4,4,A,B,"data") would work too, and to make this possible, it can't be in the data itself. I know, the output program contains a lot of data, and I'm sure I will change that soon or later. (No, I won't use C )

But being able to modify the data is pretty important if you want to do sprite transformation functions. You could posibbly set up something like token(index, "data") at the start or end of the program where then you could do Sprite(x, y, index).

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?

I think this is a great idea! first of all, the det() command is one that can be used both ways at the same time (like in doors, it's normal use is not hindered by the fact that it is also used for Celtic) And this also prevents you from having to overwrite a bunch of tokens! Since you are going to be compiling it anyway, then the difference in size in the original program has literally no impact on the final size. On top of that, it is a system that hybrid-basic programmers are already familiar with and could get the hang of quickly I vote a sturdy YEAHH on that!

Just make sure you're not overlapping with with Doors CE uses/will use, I suppose, so there's no potential ambiguity?

Well, I can easily change the token which is used, so no problem.

Time for some new important updates!

• I've added in 54 C functions (all the functions from the graphics lib, without the ones that used pointers or so), so that's going pretty well.
  
• ICE now displays a "#" in front of the name if the program is archived.
  
• Added If:Else:End, I was trying to make ElseIf too, but that didn't succeed yet.
  
• Multiplication with a number <= 20 is now a better routine, instead of the normal "ld bc, * \ call __imulu"
  
• As some of you may know, I've added a screen that asks whether to compile with C libs or not. The C functions are not compatible without the C lib, and I think I won't even add them. If you select "Yes" but you don't use any C function, it won't assume you compile with the C libs.
  
• Fixed a bug with strings, that if you close a string without a " but an enter, it crashes.
  
• I'm thinking about a new way to insert the custom tokens in the program editor. Instead of showing an OS menu when pressing [TRACE], I want to clear the screen, display ALL the C functions (size += 1000) , and that the user selects one and then the data will be inserted. I had the idea from Epharius' PHASM, and since that's open-source with a nice license, I can take a look over there
  
• Maybe I gonna implement the FILEIO and KEYPAD libs too, with another token like real(5 etc.
  

I'm busy with a real game, so yet no screenshots