So, after a long period sticking with 3-byte integers, I think it's good to think about some ways to define variables to be 1-, 2- or 3-byte integers, or even floats. As already said, Mateo and Adriweb discussed a method to cast variables and eventually functions, like this:

Code:
(1)A+3->(3*B)

for example. This gets A as a 1-byte integer, adds 3 and store it as an 3-byte integer to B. This method works fine, and generates optimized output... however, it is pretty hard to learn and understand, if you are not used to C. That is why I propose an alternative, and that is another function DefineVarType (or something similar), which sets the variable to be a 1-, 2- or 3-byte integer, or a float. This is much easier to work with, and produces almost the same outpupt. If you still want to mask a variable, you could use something like [3] or (3) for a 3-byte integer. For pointers, I could use a simple "*" before the variable, number or function. That requires a bit more parsing, but is easy to remember. Thoughts?
This is not even close to anything we suggested. Allow me to try again I guess...

1) Variables should be interpreted to the best of the parser's ability for length. You can use some kind of define() for types, but please for the love of everything do not mix types and pointer access lengths. The computer police will come for you.

2) Pointers are of type void. I feel like I said this over 100 times, but obviously it didn't sink in. This allows you to easily dereference and assign at will.

3) You need to take the address of a variable in some cases. The degree symbol, like Axe, was suggested.

Anywho, good luck.

Also the syntax is nothing like that. It was:

(*1)A for single dereference, (**1)A for a double dereference and so on.

Alternatively I have really been liking the look of:

*{A} for single 1 byte dereference, **{A} for a 2 byte deference, and ***{A} for a 3 byte dereference. Just add {} for the number of deference stages. I prefer this syntax because it just looks cleaner in code I guess.
Dang Mateo laying on the fire

MateoConLechuga wrote:
This is not even close to anything we suggested

MateoConLechuga wrote:
I feel like I said this over 100 times, but obviously it didn't sink in.

MateoConLechuga wrote:
Also the syntax is nothing like that.
Ok this a guest Smile
You guy know I have trouble with the defineSprite command
Confused
Is this how you use the command .

Code:

[i]icetest
defineSprite(???,10,3)
Det(0
//Code
Det(1


am sorry metroC I got hacked on code walrus will you forgive me plz
No:

Code:
DefineSprite(<width>,<height>,<data>)

A sprites.txt is included in the ICECompiler.zip which explains how to create the data from an image with ConvPNG.


Also, I've added Repeat and While in the C version, both are more optimized than the ASM versions Very Happy
PT_ wrote:
No:

Code:
DefineSprite(<width>,<height>,<data>)

A sprites.txt is included in the ICECompiler.zip which explains how to create the data from an image with ConvPNG.


Also, I've added Repeat and While in the C version, both are more optimized than the ASM versions Very Happy

Ohh yaa sorry I forgot thank for help Very Happy
FYI, I've added If, Repeat and While to the C version. Interesting note:

Code:
[i]B
If A or B
2->C
End

is 13 bytes SHORTER in the C version, because I'm optimizing things Very Happy
I had finally a free day off, which means I had a lot of time for programming Very Happy

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 Smile

As far as I know, this is my to-do-list until the first C version release:
  • Integer types and pointers
  • sub(, toString(
  • For( loops
  • prgmX
  • DefineSprite(, ExecHex(, Call , CompilePrgm(, SetBASICVar(, GetBASICVar(
  • Eventually some sort of lists/data ish
  • More C functions
  • More random functions


If you have suggestions on what to add more, feel free to nag me, I'm now in the mood for adding things Smile
Is it possible, on the commands that have BASIC counterparts (and the same syntax), to use the respective BASIC commands, but still compile in the same way?
_iPhoenix_ wrote:
Is it possible, on the commands that have BASIC counterparts (and the same syntax), to use the respective BASIC commands, but still compile in the same way?

What do you mean by using the "respective BASIC commands"?
If you mean taking a basic program that runs correctly in basic (uses basic commands with regular syntax) and compiling it (assuming you add the name at the top), then it works... that is the point of ICE Razz
Here is what I mean...

Code:
[i]EXAMPLE
ClrHome
Disp "iPhoenix confuses me"

If you type this into your calc using the tokens, then (besides the name of the program) it will run fine since it uses the regular correct ti-basic syntax that we know and love. If you then ask ICE to compile it (of course, with the program name) then it will compile fine and run fine as an asm program, because the syntax for these commands is the same in both ICE compiled basic and regular basic. In that sense, yes, it is possible, but I think I may have misunderstood your question.
I have run into a bit of a critical bug... I compiled a program, and it messed up something...
Lets start from the beginning... The original program no longer exists. The original program was called AA, and it compiled to a program called AMINER. As you might expect, I was compiling quite a lot, basically to test things out as I go. The time that it messed up however, prgmAA was nowhere to be seen, prgmAAA along with other random programs appeared to be unarchived, but gave err undefined when I tried to run one, and prgmAMINER has been converted to a bunch of random character with accented letters and stuff, and I can't go down far enough in the list of programs to see if it works. I can no longer go lower than then 4th program in the program menu, even though more programs are present and are visible in the menu... And at some point, clicking on the prgm menu froze the calc. Also, When I connected my calc to ti-connect and clicked on calculator explorer, ti-connect froze and gave an error Razz. Anyways, I ended up resetting the ram and everything was fine (didn't lose much, I am good at backing my stuff up), but just thought I should notify you. The time it messed up, I had just added a ShiftDown to the program. Here is the exact line of code I added that seems to have messed it up.

Code:
det(45,10

Here is the entire program... MaxY is the DefineSprite token

Code:
[i]AMINER
maxY8,8,"E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0
det(0
det(5,31
det(63,0,10,10,2,2
det(43,10,10,18,18
Pause
det(45,10
Pause
det(1

I ran it a 2nd time and it just reset my ram this time.
Also, a little thing with DefineSprite,

Code:
DefineSprite(8,8,"E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0")

Gives a parentheses mismatch error, which makes a little sense if you consider that MaxY is a token that natively does not accept arguments, but you put some on the DefineSprite(, so maybe just accept if the user puts a closing parenthesis? Evil or Very Mad
mr womp womp wrote:
_iPhoenix_ wrote:
Is it possible, on the commands that have BASIC counterparts (and the same syntax), to use the respective BASIC commands, but still compile in the same way?

What do you mean by using the "respective BASIC commands"?
If you mean taking a basic program that runs correctly in basic (uses basic commands with regular syntax) and compiling it (assuming you add the name at the top), then it works... that is the point of ICE Razz
Here is what I mean...

Code:
[i]EXAMPLE
ClrHome
Disp "iPhoenix confuses me"

If you type this into your calc using the tokens, then (besides the name of the program) it will run fine since it uses the regular correct ti-basic syntax that we know and love. If you then ask ICE to compile it (of course, with the program name) then it will compile fine and run fine as an asm program, because the syntax for these commands is the same in both ICE compiled basic and regular basic. In that sense, yes, it is possible, but I think I may have misunderstood your question.


I believe iPhoenix means something like instead of det(30 the command would be Line(. Like the commands that do the same thing on BASIC as in ICE should use the BASIC syntax.
Yes, that's pretty much exactly what I meant.
You should probably also keep the current syntax, or make the ICE compiler automatically fix it (if you do change it) too keep the current programs working.
dankcalculatorbro wrote:
mr womp womp wrote:
_iPhoenix_ wrote:
Is it possible, on the commands that have BASIC counterparts (and the same syntax), to use the respective BASIC commands, but still compile in the same way?

What do you mean by using the "respective BASIC commands"?
If you mean taking a basic program that runs correctly in basic (uses basic commands with regular syntax) and compiling it (assuming you add the name at the top), then it works... that is the point of ICE Razz
Here is what I mean...

Code:
[i]EXAMPLE
ClrHome
Disp "iPhoenix confuses me"

If you type this into your calc using the tokens, then (besides the name of the program) it will run fine since it uses the regular correct ti-basic syntax that we know and love. If you then ask ICE to compile it (of course, with the program name) then it will compile fine and run fine as an asm program, because the syntax for these commands is the same in both ICE compiled basic and regular basic. In that sense, yes, it is possible, but I think I may have misunderstood your question.


I believe iPhoenix means something like instead of det(30 the command would be Line(. Like the commands that do the same thing on BASIC as in ICE should use the BASIC syntax.

There is a very important distinction to make between the Basic Line() token and ICE's det(30) command. I believe the det(30) that PT_ uses is actually a C command. He didn't actually make his own line drawing routine in asm, he just used a C function to do so. So by naming them this way, the user knows what is in asm and what is in C (I know it all gets compiled to machine code but its symbolic Razz) I think this is also why for some commands (like DefineSprite()), he "Made a new token".
Would it be better to replace CompilePrgm( and ExecHex( to respectively AsmComp( and Asm(?
I guess it would make it cleaner (plus less tokens to remember.)


I did have a quick suggestion. One of the most useful little commands on the TI is the expr( command. I mostly use that for quick conversions of #'s to strings, but now that ICE is going to support strings, it would nice to have a StrtoNum( or a command of that type.

Also, I'm really happy about where this is going with choosable byte integers and such. Thanks PT_!
mr womp womp wrote:
I have run into a bit of a critical bug... I compiled a program, and it messed up something...
Lets start from the beginning... The original program no longer exists. The original program was called AA, and it compiled to a program called AMINER. As you might expect, I was compiling quite a lot, basically to test things out as I go. The time that it messed up however, prgmAA was nowhere to be seen, prgmAAA along with other random programs appeared to be unarchived, but gave err undefined when I tried to run one, and prgmAMINER has been converted to a bunch of random character with accented letters and stuff, and I can't go down far enough in the list of programs to see if it works. I can no longer go lower than then 4th program in the program menu, even though more programs are present and are visible in the menu... And at some point, clicking on the prgm menu froze the calc. Also, When I connected my calc to ti-connect and clicked on calculator explorer, ti-connect froze and gave an error Razz. Anyways, I ended up resetting the ram and everything was fine (didn't lose much, I am good at backing my stuff up), but just thought I should notify you. The time it messed up, I had just added a ShiftDown to the program. Here is the exact line of code I added that seems to have messed it up.

Code:
det(45,10

Here is the entire program... MaxY is the DefineSprite token

Code:
[i]AMINER
maxY8,8,"E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0
det(0
det(5,31
det(63,0,10,10,2,2
det(43,10,10,18,18
Pause
det(45,10
Pause
det(1

I ran it a 2nd time and it just reset my ram this time.
Also, a little thing with DefineSprite,

Code:
DefineSprite(8,8,"E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0E0000000000000E0E0000000000000E0E0E0E0E0E0E0E0E0")

Gives a parentheses mismatch error, which makes a little sense if you consider that MaxY is a token that natively does not accept arguments, but you put some on the DefineSprite(, so maybe just accept if the user puts a closing parenthesis? Evil or Very Mad


Really sorry to say that I totally missed this post for some reason... anyway, I wonder if that's a bug of ICE, or a bug of the C toolchain. The modification of programs is basically doing bad stuff with the VAT... which can be caused by ShiftUp (or ShiftDown if it doesn't work properly Razz). If you download the latest toolchain and ICE, can you still trigger it?

EDIT: I think you just need to redownload ICE. In one of my previous versions there was a bug that didn't set the clip region properly, which has been fixed. This might be the cause of the strange behaviour Smile
Been having some trouble with ICE.
Using ICE v1.5
Using Ti-84 PCE v5.2.2.0043
I noticed while I was converting over a Ti-BASIC program to one that ICE could compile was that using an Output() token with the actual output being any number or expression makes the compiled program simply quit and say "Done"

Example:

Code:

[i]AAAIEFK
ClrHome
Disp "DERP"
Output(5,5,3)
Pause
Disp "HELLO WORLD"

The above code when compiled will give no compilation errors, and launch just fine using
Asm(prgmAAAIEFK
and will output "DERP"
but it will not output "3" or do anything past the "Output(5,5,3)" command, instead it will exit once it reaches the "Output(5,5,3)" line and say "Done".

Tried this both on my physical Ti 84 PCE with all my stuff on it (backed up of course) and also tried with a fresh ROM using CEmu, both gave the same results.
Good point. You are clearly the first one ever that used either Disp <expression> or Output(..,..,<expression>), because both were broken. Thanks for reporting! You can grab the latest version from the Archives when it's accepted, or meanwhile here:

https://tiplanet.org/forum/archives_voir.php?id=587211
PT_ wrote:
Good point. You are clearly the first one ever that used either Disp <expression> or Output(..,..,<expression>), because both were broken. Thanks for reporting! You can grab the latest version from the Archives when it's accepted, or meanwhile here:

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

I told you about this like 10 years ago and I think you said it was fixed Evil or Very Mad
https://www.cemetech.net/forum/viewtopic.php?t=12616&postdays=0&postorder=asc&start=111 This is right about 10 years right? Razz
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3 ... 13, 14, 15 ... 31, 32, 33  Next
» View previous topic :: View next topic  
Page 14 of 33
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement