merthsoft wrote:
Hey Mateo, what would be the best way to save some settings? An AppVar? Or is writeback possible?
Writeback is entirely possible, but it would probably be safer to save to an AppVar, in case a shell changes the name of the program, or something else happens. Here's some sample code:
Code: /* CE Keypad C Library */
#include <fileioc.h>
/* Main Function */
void main(void) {
unsigned int file;
uint8_t array[] = { 10,20,30 };
/* Close all open file handles before we try any funny business */
ti_CloseAll();
/* Open a file for writting -- delete it if it already exists */
file = ti_Open("AppVar", "w");
/* write some things to the file */
if (file) {
if(ti_PutC('A',file) != 'A') goto w_err;
ti_Write(array, sizeof(uint8_t), sizeof(array)/sizeof(uint8_t), file);
}
w_err:
ti_CloseAll();
pgrm_CleanUp();
}
Oops, this reminds me, the fileioc library is way out of date in the demos folder. I'll update that when I have a chance 
MateoConLechuga wrote:
Oh, that's because that's an outdated example you are trying to compile. The new demo_0 should have what you need
KermMartian wrote:
MateoConLechuga wrote:
Oh, that's because that's an outdated example you are trying to compile. The new demo_0 should have what you need
Nah, not a dumb question The fileio demo will give you exactly the same errors because I haven't updated it yet. Been trying to fix all the bugs that seem to be coming from everywhere
Thanks for those kind words.
And thanks to your help, SourceCoder 3 is now running the latest version of the toolchain (with its own Makefile) and the latest libraries. As suggested previously, #include <lib/ce/somelib.h> is all that's necessary to use the libraries in your own programs.
Mateo, I'm trying to do something such that I store the previous state of the keyboard so I can check against it to see if a key WAS down before the most recent scan. So, I've got this function which I showed you before:
Code: bool Key_IsDown(key_t key) {
uint8_t group = (key & 0xFF00) >> 8;
uint8_t code = key & 0x00FF;
return kb_dataArray[group] & (code);
}
I've added this declaration:
Code: uint16_t __previousKeys[7];
And then I do this:
Code: void Key_ScanKeys() {
memcpy(__previousKeys, kb_dataArray, 7);
kb_Scan();
}
And then I want to call this:
Code: bool Key_WasDown(key_t key) {
uint8_t group = (key & 0xFF00) >> 8;
uint8_t code = key & 0x00FF;
return __previousKeys[group] & (code);
}
However, Key_WasDown is always returning true, so it's like the memcpy isn't quite working as expected. Do you have any insight in what I may be missing or doing wrong here?
The third argument of memcpy is num bytes, which means you need 7*sizeof(uint16_t), or since __previousKeys is properly declared as an array and not as a pointer, you should do sizeof(__previousKeys) to minimize the number of magic numbers in your code.
Ah, that's silly of me. I changed that so the new function looks like this:
Code: void Key_ScanKeys() {
memcpy(__previousKeys, kb_dataArray, sizeof(__previousKeys));
kb_Scan();
}
However, the error still persists.
What's extra weird is if I do this:
Code: void Key_ScanKeys() {
int i = 0;
for (i = 0; i < 7; i++) {
__previousKeys[i] = 0;
}
kb_Scan();
}
It still always returns true. And when I move the array declaration from the .c to the .h, it always returnes false, even when I restore it to the memcpy!
EDIT: IN TODAY'S EPISODE OF SHAUN DOESN'T KNOW HOW TO COUNT: It should be 8, not 7...
Yet another update to the toolchain and libraries! This one fixes some minor bugs in the fileio library, and changes the makefiles a bit to be easier to use. It is important as always that you have the latest release of the toolchain and libraries in order to make sure nothing goes wrong
When including libraries, it is now more practical to do it like this:
Code: #include <lib/ce/graphc.h>
This just makes it easier for IDEs to automatically include libraries for you.
Anyways, here are the usual links for getting the new libraries and toolchain: (Note that now the header files are included in the release, rather than in the source )
Quote:
Note that now the header files are included in the release, rather than in the source
Oh thank god.
Thanks for keeping this updated and fixing bugs! I've upgraded SourceCoder 3 to the latest versions.
Minor toolchain update that fixes a bug in memset_fast, and also removes a few unnecessary functions from the standard libraries.
Here it is
MateoConLechuga wrote:
Minor toolchain update that fixes a bug in memset_fast, and also removes a few unnecessary functions from the standard libraries.
Here it is
Well, I've been rather busy as spring break winds down, so here is update 3.0 which includes a lot of major changes:
Library functions are now only compiled in if you use them. This reduces your program size, and generally is a lot cleaner.
The _OS macro has been replaced with an _OS function; which provides a default wrapper for all assembly functions on-calc. Wrappers for particular assembly functions can also be made now; which will be really handy in the future.
The source for runtime library and build tools have been added to the toolchain for faster and easier testing and development.
Download links:
C SDK:
Download
C Libraries:
Download
Also, the library setup is a little different, just copy everything in the dev folder in the library download to CEDev\lib\ce folder and it will be fine
Anyways, enjoy! This is a pretty big update; I think I'll focus more on fixing a few library bugs, but the toolchain setup is pretty much perfect now
(By library functions not being added in, I mean that they aren't added to the relocatable jump table)
A function seems like a worse idea than a macro in this case, since it adds function-call overhead, and eZ80CC doesn't support the inline keyword.
A function is a much better idea in this case. If you would like me to explain why, I can.
Just the libraries have been updated for now; with a small fix to the fileioc bug found by Merth concerning reading archived variables, among a few other things. Also, another demo including how to draw sprites using convpng with ease.
Enjoy!
Download:
https://github.com/CE-Programming/libraries/releases/latest
My next plan is to implement simple token reading for variables, and simple parser running as that is rather difficult in C without a bit of asm knowledge.
Also, Curmred_Snektron recommended splitting the make process into multiple directories to prevent clutter, so I'll probably look into that as well.
Quote:
My next plan is to implement simple token reading for variables, and simple parser running as that is rather difficult in C without a bit of asm knowledge.
Does that mean, like, parsing a line of BASIC? That would be awesome!
merthsoft wrote:
Quote:
My next plan is to implement simple token reading for variables, and simple parser running as that is rather difficult in C without a bit of asm knowledge.
Does that mean, like, parsing a line of BASIC? That would be awesome!
Yeah; it does.
Woo! That's fantastic! With that I'll be able to port my little turtle program over, and it'll be nice and speedy in C instead of BASIC.
I recall that there were some problems withe makefile on linux, have those been fixed, Mateo?
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
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
