Quote from: DJ Omnimaga 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

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?

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.

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.

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!

Cemetech: 749
CodeWalrus: 101
TI-Planet: 87
Omnimaga: 12
Total: 949
Not bad

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 step 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: fixed that bug that the step in a For loop is a variable, had to reset a bit...

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 
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 :/

Quote from: DJ Omnimaga 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?

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

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

• Added operators * and /. Together this took about 15 minutes (4/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

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!

Quote from: DJ Omnimaga 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?

According to CEmu exact 181cc, which is pretty fast I would say Also, I'm very hard busy, so changes are coming fast

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/

Quote from: DJ Omnimaga 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?

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 from: 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.

No, since the archive structure is totally different Programs are stored as in RAM, but the header is a little bit different.

So I finally had a free day, so I made a lot of changes:

• You can now (re)compile archived programs
  
• ICE now compiles the whole program, instead of only the first line
  
• Fixed main structure
  
• Fixed operators + and -, the other 12 need to be done soon :|
  
• Added the function not(
  
• Added the structure for my custom tokens, still need to start with
  
• My custom tokens are now replacements of statistics tokens, instead of accented letters. I did this because TI-Planet members told me at least French people use them more than normal.
  
• Removed the Inc( and Dec( token, because these are only useful for 1-byte variables.
  
• Added the tokens switch( and case: which could be very useful in programming
  
• Added some safety. If it encounters an error, it jumps to a function that display the error string, but then it may happen that the stack is messed up, so I stored the beginning stack pointer somewhere, and recall it before an error.
  

To-Do-List for the next release:

• Cesium icon/description
  
• Auto-optimization
  
• Finish operators (2/14 done). This gonna take time
  
• Add more functions, at least the custom ones
  
• When you have only once Input , it would be faster and smaller to move that directly into the output program, instead of calling it, like this:
  

<code>
<input code>
<code>
retinstead of<code>
call <input>
<code>
ret
<input code>

• Get right random routine.
  

Well, every week I'm pretty busy, so I guess not many time for programming sadly

In speed or size it doesn't matter, so no worries. It only looks a bit bad
And sadly no, I first wanted to finish the operators, but it's actually not a bad idea to start with some functions!