Good news! I finally made my first add-in... not a great one but still. I named it flashlight... it is a white screen until the user pushes [menu]. I was thinking of adding multi-color support. This is mainly just to get familiar with the sdk and actually make a .g3a ... Okay bad news, I ran 'flashlight' on the Casio fxcg10 90 day emulator and it froze. Wouldn't work at all. Also where it says the name of the add-in it just reads 'example'. What did I do wrong?
No, after I ran it on the emulator I was scared I would mess up my calculator. I guess I'll try in the morning. I think the flashlight is pointless...you can easily do this in basic. Oh well, just familiarizing myself with coding.
zeldaking wrote:
No, after I ran it on the emulator I was scared I would mess up my calculator. I guess I'll try in the morning. I think the flashlight is pointless...you can easily do this in basic. Oh well, just familiarizing myself with coding.
If your Prizm freezes, just push the little reset button on the back of the calculator, and everything (should) be fine. I haven't yet heard a report about the Prizm getting bricked, personally. If you'd rather be safe, want to show us the code?
Okay, here is my code.
Code:
Code:
#include <keyboard_syscalls.h>
#include <keyboard.h>
define true=1;
int main(void) {
while(true) {
if(PRGM_GetKey() == KEY_PRGM_MENU) {
keymenu();
}
}
return 0;
}
void keymenu(void) {
int key = KEY_PRGM_MENU;
GetKey(&key);
Bdisp_EnableColor(1);
DrawFrame(COLOR_BLACK);
}
For the name, the filename does not determine what the addin displays oncalc. Modify your makefile and look for a call to the mkg3a tool and change "example" with the name that you want.
zeldaking wrote:
If you look above at my code is says "while(true) {" Can I just do "while(1) {"?
Yes, true and 1 are synonymous, as are false and 0. However, it's generally better to say "true" or "false" to make it explicit that you're working with Boolean values.
I know that, but why is the while loop just controlled by "1", wouldn't that be a never ending loop? Or does the KEY_Prgm_Menu make the OS return to the main menu
Just from my expertise in other languages, I can say that "While 1" Is an infinite loop, but one that is easily broken. I usually use repeat 0 in all my programs, so that when the program is done, it loops back to the start to run the program again. An easy way to break the loop, is just add a return that is selectable by a menu or a boolean value.
Don't forget that this code will not loop:
Code:
The getkey function is able to break out of addin execution and jump to the OS. When another addin is executed, the running one is dumped and a new one is loaded and executed. There doesn't need to be a return in your addin as the OS is able to do that for you.
(There may be things wrong with that explanation, but that is what happens in effect)
Code:
while(true)
{
break;
}
The getkey function is able to break out of addin execution and jump to the OS. When another addin is executed, the running one is dumped and a new one is loaded and executed. There doesn't need to be a return in your addin as the OS is able to do that for you.
(There may be things wrong with that explanation, but that is what happens in effect)
zeldaking wrote:
I know that, but why is the while loop just controlled by "1", wouldn't that be a never ending loop? Or does the KEY_Prgm_Menu make the OS return to the main menu
Keep in mind, one thing you should *NEVER* do is exit main in an add-in. Once you exit it, until you run another add-in, every time you run it will result in a blank screen and then a return to the MENU screen. Hence why it's a great idea to just have a while loop there.
Is that because of where the PC is at (or whatever the superh uses) and it keeps returning? Would it be safe to read that return address and jump to it instead of returning to it?
AHelper wrote:
Is that because of where the PC is at (or whatever the superh uses) and it keeps returning? Would it be safe to read that return address and jump to it instead of returning to it?
Well yes, it's stuck there because when you return either by the MENU GetKey or return methods, the OS keeps track of the last program .text address pointed to by the SPC and register values, and jumps back there again afterwards; however, with the return statement, the SPC doesn't get considered to be advanced past the return instruction(s) (which ideally should be loading PR with this "fabled" return address you asked about, followed by a "rts \ mov #1, r4"). Simply branching to that address seems like a reckless idea; either it'll make the value in PR dangerous to the code at that return address (if it accidentally branches back to itself over and over), or if nothing else will disorient the OS's stack which would probably be dangerous as well.
As posted before, config.guess can't figure out what my host computer is:
Code:
Note that this is without any cross-compilation options. I need to know what to use for the hostname; it may have to do with the "unknown" bit, so if I can fill that in, I should be set.
Code:
[sean@Deep-Thought build-binutils]$ ../binutils/configure
Configuring for a x86_64-unknown-linux-gnu host.
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Invalid configuration `x86_64-unknown-linux-gnu': machine `x86_64-unknown' not recognized
Unrecognized host system name x86_64-unknown-linux-gnu.
Note that this is without any cross-compilation options. I need to know what to use for the hostname; it may have to do with the "unknown" bit, so if I can fill that in, I should be set.
When I try to use stdlib.h functions (regardless of whether I #include <stdlib.h> or not), I get linker errors like these:
Code:
Code:
bullets.o: In function '_freeList':
bullets.c:(.text+0x384): undefined reference to '_free'
bullets.o: In function '_createNode':
bullets.c:(.text+0x39c): undefined reference to '_malloc'
KermMartian wrote:
zeldaking wrote:
No, after I ran it on the emulator I was scared I would mess up my calculator. I guess I'll try in the morning. I think the flashlight is pointless...you can easily do this in basic. Oh well, just familiarizing myself with coding.
If your Prizm freezes, just push the little reset button on the back of the calculator, and everything (should) be fine. I haven't yet heard a report about the Prizm getting bricked, personally. If you'd rather be safe, want to show us the code?Well, I bricked one, but I think it was a short-cicuit or power surge, and it definitely wasn't because of any code i ran.
Links to my calculator projects
I lurk #cemetech, if you want to contact me that and email are probably best.
I lurk #cemetech, if you want to contact me that and email are probably best.
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
» Go to Registration page
» Goto page Previous 1, 2, 3, 4 Next
» View previous topic :: View next topic
» View previous topic :: View next topic
Page 3 of 4
» 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
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