You can use the latest releases PDF, which is essentially the same, or you can use the latest commands list, available here
If you still didn't know this: I'm very busy creating an ICE debugger! With this nifty program (or in fact, appvar), you can step through your code, view and edit variables, view/edit memory, view all the information about opened slots, view the screen and buffer, and jump instantly to labels!

Some screenshots:
Wow nice progress. I look forward to using debug !!!
The most important part of the debugger is pretty much ready: stepping through code! It was quite some work, but after all not very hard:

Huge thanks to Runer112 for helping with setting breakpoints and a breakpoint handler!
Don't want to sound rude or anything, but what benefits do you get as a programmer? Can this help me stop crashing my calc when I'm ICE testing?
It helps you debug. Wink
It will help you to stop crashing your calc. Just run it with the debug mode, and debug away!

Also, how can we find what's wrong with code that's not compiling? Other than reading through the whole program character by character, can there be a way to find out what's wrong?

Something that happens to me a lot is that I add a space after a command like End or Pause. If the debugger could be made into a program, and look through the code without compiling, that'd be great. (I don't know if that's feasible though)
Welp, I need some help with the debugger, stepping through subprograms and stuff Sad Runer and I tried some methods, but they all had huge drawbacks, and I'm not sure if there's a better way to do this:

When the debugger is called, I can get the global number (global = all (sub)programs combined in a large program) using the return address. When the user selects "Step through code", it needs to display the proper program and line. However, global line number != line number in correct program if you have some subprograms, so that's where problems arise. ICE outputs all the (sub)programs during prescanning, as well as the global start line, global end line and the depth of the subprogram (main program = 1, subprogram = 2, subsubprogram = 3 etc..).

My current method to select the right program and line is this: loop through all programs backwards, and the first program that matches startLine <= global line <= endLine is the right program (that is always true). Getting the local line number is quite harder. I have to loop through all subprograms with the depth being equal to inputDepth + 1 (so get all the subprograms from that program), and substract the amount of lines from the input line, as well as the startLine. See this:

                Line:   Line in prog:
[i]B            1       (1 - 1) = 0
dbd(0           2       (2 - 1) = 1
3->A            3       (3 - 1) = 2
AsmComp(C       4       (4 - 1) = 3
AsmComp(F       14      (14 - 1) - (13 - 5 + 1) = 4
3->A            18      (18 - 1) - (13 - 5 + 1) - (17 - 15 + 1) = 5

[i]B            5       (5 - 5) = 0
9->B            6       (6 - 5) = 1
AsmComp(D       7       (7 - 5) = 2
10->B           13      (13 - 5) - (12 - 8 + 1) = 3

[i]B            8       (8 - 8) = 0
AsmComp(E       9       (9 - 8) = 1
5->D            12      (12 - 8) - (11 - 10 + 1) = 2

[i]B            10      (10 - 10) = 0
3->F            11      (11 - 10) = 1

[i]B            15      (15 - 15) = 0
dbd(0           16      (16 - 15) = 1
5->G            17      (17 - 15) = 2

This method is currently up and running (it was pretty hard though!). However, this is still far from done. When displaying the program it also shows you the breakpoints. Thus, for each line in the program, I have to get the global number and check if a breakpoint is placed at that line. However, this part is almost impossible. I can't get the right global line number where it starts drawing, unless I want to loop through all programs ~25 times when displaying the program and that doesn't seem right to me. If this is already done, I also need to add setting/removing a breakpoint, which is pretty much the same idea, so yeah.

Runer had another idea where the first program gets lines 1-X, the first subprogram X+1-Y, the second Y+1-Z etc. This has the disadvantage that you have to loop through all single lines to see where the call address matched. Also, placing a breakpoint on the next line would be much harder.

Is there anyone with a better idea? ICE can output many things related to subprograms, so that is not the problem. The debugger only gets the call address where it can get the global line number from, but that's it.
Maybe it's too difficult, maybe a disassembler could be enough ?

Maybe a source coder 3 editor usable directly on TI-84 PCE would be easyer and useful ?

Thank you again for Ice Compiler !
Just do it like gdb does...... Or just keep reinventing the wheel like you like to do.
I was wondering if someone could post a compiled version of ICE Debugger here, as I don't have the ability to compile it.
Why don't you have the ability to compile it? Not a hardware problem? You can do it. There's documentation. If you can't figure it out, wait for a release.
I agree with Jcgter777.

Peter have made a very easy procedure to install Ice compiler in 1 line to execute.

It's the first page of manual....
calclover is not referring to the compiler, but the debugging tool which has not yet been officially released and must be assembled from source code. It's possible that his computer is incompatible with the assembler required to create the binary.

It's generally considered a bad idea to take random binary files from people on the internet, as you cannot verify that it is actually compiled from the source.
Ah ok, sorry
It seems that ICE 2.1 does not work with the newest version of clibraries (released by Mateo 12 days ago). I had to update clibraries for HDPic, but then when I hit the [trace] key, the ICE menu did not pop up (yes, I ran ICE at least once after a RAM reset). I ended up resetting my calculator and trying to re-download over again. I finally realized I had changed my clibs recently. After re-downloading the old version, ICE menu worked again.

Edit: Way to go me... time to go download ICE 2.2.
To avoid you problems of memory lost, you can store ICE and a version of your programs srce in Archive. Generally Archives are not touched with Ram reset. (Except if you disable clip mode and overwrite importants memory data such as pointers).
The Archive isn't "touched" by RAM reset, because it's not RAM...

Also, that issue, Calcuon, happens to me as well. it starts off working, then stops (maybe clibs or something), and is fixed with an update of ICE.
Dear Friend wrote:
To avoid you problems of memory lost, you can store ICE and a version of your programs srce in Archive. Generally Archives are not touched with Ram reset. (Except if you disable clip mode and overwrite importants memory data such as pointers).

I know about RAM and ROM. Very Happy
I reset all memory on purpose to see if I had screwed up my calculator.
I think it's very rare to definitively screw up a calculator just with a program.
Do you know an link for exemple ?


If you mean it damages the calc irreversibly, there are some here.

I don't think that the issue is data loss or a corrupted calc, but that generally, good programs should not crash, and that a program that crashes is unusable.
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 ... 27, 28, 29, 30, 31  Next
» View previous topic :: View next topic  
Page 28 of 31
» All times are GMT - 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