Omnimaga
Calculator Community => TI Calculators => Calculator C => Topic started by: bwang on May 16, 2010, 10:30:56 pm
-
I have seen more than one post talking about writing some basic libraries for the Nspire, so I felt that it would be a good idea to start a thread to post any headers we have.
I will start with a modified utils.h/c that supports drawing pixels to a screen buffer. This should be useful for people doing graphics functions.
Right now we need:
-Program Loader
-Graphics: Triangles, dithering, filled circles, etc.
-Better Text I/O (I wrote some, but they are a bit weak)
-More OS symbols
-An implementation of the standard library (stdlib.h, stdio.h, etc) for easier porting.
EDIT 1: Attached a file skeleton.zip. Edit your Nspire code in this folder, and then type 'make' to build. It provides the minimal portion of Ndless required to write programs.
EDIT 2: Attached willrandship's modified common.h, with all the keycodes in it.
EDIT 3: Found a small bug in common.h.
EDIT 4: Latest skeleton.zip
EDIT 5: Realized that MakeTNS is platform-dependent. skeleton is split into Linux and Windows versions.
EDIT 6: Attached a graphics.h/c, which is a not quite finished, but still useful, collection of graphics routines. Right now it contains fast circle and line routines, and some functional but slow rectangle and sprite routines.
EDIT 7: common-fixed.h and utils.zip are now unnecessary. They have been integrated into the skeleton.zip files, so don't bother downloading them. graphics.h/c are still separate for now, and will be until they are finished.
EDIT 8: Updated graphics.c/h to graphics2.c/h. This one contains a much better sprite routine that uses proper memory-copying methods to draw the sprite. The sprite data format has changed, so if you have any old sprite data pass them to
convsprite(char* sprite, char* result, int w, int h)
Here, result is a buffer that is of size w * h / 2 used to hold the new data.
EDIT 9: apcalc found a small bug in common.h. Fixed!
EDIT 10: Fixed a nasty sprite() bug.
EDIT 11: skeleton-windows.zip and skeleton.zip merged. I added a few text and string routines to it (string.h, screen.h) as well as dirlist.h, which lets you list the files in a given directory. Yes, I know this violates EDIT 1, which states that skeleton.zip is minimal, but being able to draw text is too useful. Also, common-fixed.h and utils.zip have disappeared.
EDIT 12: added a function filesize(char* path) to utils.h. Pass it the path to a file and it returns its size.
-
Here is the current state of the routines I have, I will continue to update these:
Ok... The alphabet routines are set up except I haven't had a chance to write the code for actually drawing the letters
(I know that A has code in it but it draws an incomplete hourglass as I was just testing if I could get it to work)
The Drawing routines only contain a square, rectangle and 4 directional line drawer, I will add the triangle and circle later
(The circle is throwing up a bunch of weird errors right now)
Note: The length of strings is currently set to 1 (ie only 1 letter, this can be changed in alphabet.c line 56) as I can't use strlen() without it causing problems with malloc (more precisely sizeof) and spaces as I am temporarily using them to terminate the for loop.
I also attacked my common.h header as it has an extra 15 or so controls already put in
This will help those wanting to add new keys (thanks for the link bwang):
http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#900E0000_-_Keypad
bit 0 to 10 = 1, 2, 4, 8, 10, 20, 40, 80, 100 , 200 , 400 if you are a bit confused on that part
-
Interesting...the nspire has an 8-directional Dpad, so up to 16 directions. Not too shabby!
I was thinking about making a non-specific keypad library, that would detect what keypad you have (anyone know the bit that determines this? It's a hardware thing running to one of the keypads, I'll bet) and then substitute keypad commands and such, so touch, 84+ and regular nspire could all be run with the same header.
-
Also, this forum needs to be updated to support .c and .h attachments.
fixed
-
yoshi13: Why are you allocating your integers with malloc()? You can just declare them as, for example, int i.
malloc() is for arrays and such.
Also, you probably want to draw your characters the same way you'd draw sprites. Make an array of pointers to int, with each element being a pointer to the first element of an array containing data for the character. Then to draw a character ch, simply call sprite_routine(char_data[ch]).
-
I know that you don't need to call malloc() for integers but for certain ones it used to crash the calc if I didn't declare them so I have just declared them all until I have a chance to sort through them a fix the bug.
And by the sprite_routine() are you referring to the way you drew the imps in your Ray Caster program.
Thanks for the help, I haven't ever used C before and I haven't done any normal programming since last year.. (just been messing around with command prompt, getting it to crash my brother's computer)
I will go over some tutorials and source code after school and to change up the code a bit and possibly try and use vertices so it's easier to make shapes.
-
sprite_routine() is a non-existent routine for drawing sprites. Someone needs to write it (not very hard, just loop over the elements of the array and draw pixels).
malloc() will not work the way you are doing it. Integers should not crash the calc; can you post your original code?
-
I changed the program so the integers no longer use malloc. I am going to take a break from text routines and the paint program I am working to relearn C since I have spent so much time using Java and C++ and find it hard to go back to a lower-level language.
Thanks for the help, I hope to be more useful in the future,
-
I hope you don't give up on calc stuff D:
-
Nah.... I have atleast 2 and a half years left using the calc to I will try and keep going to then... :]
-
Aaah ok good to hear, hoping you continue a bit afterward too (like some of us) even if not as often (I release new stuff like once a year) :P
-
Here's my common+.h The only difference for now is the keymappings, but I plan on adding touch support later, and maybe keypad detection.
Suggestions/Comments are appreciated, and I will likely change it for reasonable suggestions, especially bugs and key names.
To use as your common.h, just rename it to be so, removing the plus. Everything should work fine, just keep your regular common.h as a standby.
EDIT: Updated, removing + from 84 keymapping. now it's KEY_84_ENTER instead of KEY_84+_ENTER
-
Basically, is it to make the Nspire keypad have a key layout similar to the 84+ one? I would like this so I don't have to constantly switch when Calc84maniac releases his emulators
-
I don't think its good style to use '+' in the key names. You should change them to just KEY_84_*.
-
Not quite what I was thinking, more that programs can support either without having to be reassembled. I'm thinking you'd have a few generic keys, like KEY_ENTER and KEY_UP, while if you need more controls you switch over to KEY_NSPIRE_THETA and so on. This would be the most helpful with the touchpad, since many keys are labeled the same. Using KEY_NSPIRE would require the Nspire Keypad, but it could support both the touch and the original, sans sin, cos, tan, and any other changes.
Can the touch's keypad support more than 16-directional input? I'm curious if it's really an upgrade, since the original keypad can only support that much.
I updated the Common+.h in my last post.
-
If the touchpad still supports only 16 I'm still amazed :P. At least it's better than just 4 (or 8) :P
-
Hmm...you're not supposed to have '(', ')', and the like in the key names. Those should be changed into KEY_NSPIRE_LP (Left Parentheses), KEY_NSPIRE_SQU (X^2), etc.
-
At least it's better than just 4 (or 8) :P
Lol ;D
-
I sometimes despise smileys... (not really hating them, but the fact that sometimes, you don't want to use any and they still show up :P)
-
I added a attachment called skeleton.zip to the first post. It is the minimal part of Ndless needed to develop programs, and should be useful for people uploading source and such.
-
nice, should also be useful for people wanting to startup with Ndless C dev
-
Thanks to bwang, to access time use
int time = * (unsigned*) 0x90090000
-
BTW that returns time in seconds.
I wonder if its possible to access it in milliseconds (for framerate counting purposes).
-
Actually, I was wondering what I could use for the parentheses. Thanks for the tip.
Here's another fixed one. I kinda like the ++, reminds me of c++ :P
Edit: Wow I feel stupid. I forgot to upload the file. Sorry!
-
Actually, I was wondering what I could use for the parentheses. Thanks for the tip.
Here's another fixed one. I kinda like the ++, reminds me of c++ :P
Where's the fixed one?
-
BTW that returns time in seconds.
I wonder if its possible to access it in milliseconds (for framerate counting purposes).
Yeah. I was hoping it would be in milliseconds but at least we can make a stopwatch now...
btw what is the first and second time on : http://hackspire.unsads.com/wiki/index.php/Memory-mapped_I/O_ports#90060000_-_Watchdog_timer ? I know the watchdog timer makes it reset after x amount of time if there is a hang but I don't get what the first and second timer do...
-
Fixed is posted now....guess I need more sleep.
-
Excellent. I attached it to the first post.
-
Glad I could help! Let me know if anyone wants anything else like that and I'd be happy to supply it, providing I know how.
-
Thanks to bwang, to access time use int time = * (unsigned*) 0x90090000
Since that is memory-mapped hardware, you need to use * (volatile unsigned*)
-
Thanks to bwang, to access time use int time = * (unsigned*) 0x90090000
Since that is memory-mapped hardware, you need to use * (volatile unsigned*)
Really? yoshi13 tells me just * (unsigned*) worked.
-
If you have optimization enabled, a loop that waits for this time value to reach a certain amount will probably optimize so 0x90090000 is only read once and that value is compared for the rest of the loop. Using "volatile" will guarantee that the memory will literally be read every time it is referenced.
-
I'm having trouble compiling with the skeleton environment. I was able to successfully compile the Ndless demo, whereas Bwang's raycaster and a small test program I wrote won't compile. It seems to not be loading the headers properly.
Here is the code:
#include <os.h>
#include <common.h>
#include <utils.h>
asm(".string \"PRG\"\n");
int main()
{
int antx = 160;
int anty = 120;
int dir = 1;
while (!isKeyPressed(KEY_NSPIRE_ESC)) {
if (getpixel(antx,anty) == 15) {
setpixel(anty,antx,0);
dir = dir - 1;
}
else {
setpixel(anty,antx,15);
dir = dir + 1;
}
if (dir == 0)
dir = 4;
else if (dir == 5)
dir = 1;
if (dir == 1)
antx = antx - 1;
else if (dir == 2)
anty = anty + 1;
else if (dir == 3)
antx = antx + 1;
else
anty = anty - 1;
if (antx == 0)
antx = 320;
else if (antx == 321)
antx = 1;
if (anty == 0)
anty = 240;
else if (anty == 241)
anty = 1;
}
return 0;
}
And the the full output:
arm-elf-gcc -mcpu=arm7tdmi -O3 -Wall -W -fpie -fno-merge-constants -c -I./header
s -D NON_CAS main.c
In file included from ./headers/os.h:17,
from main.c:1:
./headers/common.h:62:20: warning: missing whitespace after the macro name
./headers/common.h:71:22: warning: missing whitespace after the macro name
./headers/common.h:114:20: warning: missing whitespace after the macro name
./headers/common.h:114:1: warning: "KEY_NSPIRE_" redefined
./headers/common.h:62:1: warning: this is the location of the previous definitio
n
./headers/common.h:116:20: warning: missing whitespace after the macro name
./headers/common.h:116:1: warning: "KEY_NSPIRE_" redefined
./headers/common.h:114:1: warning: this is the location of the previous definiti
on
main.c: In function 'setPixel':
main.c:23: warning: implicit declaration of function 'getpixel'
main.c:24: warning: implicit declaration of function 'setpixel'
main.c:52: warning: 'return' with a value, in function returning void
main.c: In function 'main':
main.c:53: error: expected declaration or statement at end of input
make: *** [main.o] Error 1
If it matters, I'm using the arm-elf-gcc version of yagarto.
-
Fixed code:
#include <os.h>
//notice the quotes around utils.h
#include "utils.h"
asm(".string \"PRG\"\n");
int main()
{
int antx = 160;
int anty = 120;
int dir = 1;
while (!isKeyPressed(KEY_NSPIRE_ESC)) {
if (getPixel(antx,anty) == 15) {
setPixel(anty,antx,0);
dir = dir - 1;
}
else {
setPixel(anty,antx,15);
dir = dir + 1;
}
if (dir == 0)
dir = 4;
else if (dir == 5)
dir = 1;
if (dir == 1)
antx = antx - 1;
else if (dir == 2)
anty = anty + 1;
else if (dir == 3)
antx = antx + 1;
else
anty = anty - 1;
if (antx == 0)
antx = 320;
else if (antx == 321)
antx = 1;
if (anty == 0)
anty = 240;
else if (anty == 241)
anty = 1;
}
return 0;
}
I also updated skeleton.zip to use willrandship's common.h, as well as some other minor changes.
-
I tried that, and I'm still getting the same error message.
-Edit: I feel so stupid! The problem with the getPixel and setPixel was me not capitalizing the P. Now, I get the demo.bin and demo.elf files, but maketns won't work. Here's the error message:
process_begin: CreateProcess(C:\Users\Amar\Desktop\skeleton\tools\MakeTNS\MakeTNS, ./tools/MakeTNS/MakeTNS demo.bin demo-noncas.tns, ...) failed.
make (e=193): Error 193
make: *** [demo] Error 193
-
What does manually running the MakeTNS command do?
yoshi13 said he installed mingw first, then msys.
-
Windows says its not a valid program. I am not using minGW or msys, just yagarto and yagarto-tools.
-
Hmmm...my fault :( The MakeTNS in the skeleton is a Linux version. Go get a fresh copy of Ndless and copy the MakeTNS in it to the appropriate directory.
I shall fix the skeleton when I have time.
EDIT: Fixed!
-
Nice to see an update (and to see you return), bwang ^^
-
I replaced makeTNS and it worked! My test program was a Langton's Ant, which runs crazy fast! Now my only problem is that the calc crashes when I press esc. Anyone know why that's happening?
-
You might be running out of bounds with your setPixel().
-
Yeah, looking at that code, you getPixel(antx,anty) but setPixel(anty,antx,color). Is it supposed to be x,y or y,x?
-
Oh, I think the code I posted was an old version. My current version fills the whole screen.
-
If your pixels travel out of the screen and you don't check the bounds, you will get a crash.
-
Hmmm...I have to doublepost :(
I edited the first post and attached some possibly useful fast (addition only) circle and line routines.
-
no problem, there are over 6 hours between the posts anyway :P
-
It's working now. At first, I thought the bounds would be (1,240) and (1,320), similar to TI-BASIC, but they really start at 0.
-
Doesn't BASIC's pixel-On follow those conventions too?
-
What is the usage of char* scrbuf in the graphics functions?
-
It's a double-buffer, allocated with malloc() in the calling program. It allows for flicker-free animation.
-
How do you write code using the buffer?
-
Like so:
char* scrbuf = (char*) malloc(SCREEN_BYTES_SIZE);
line(scrbuf, x1, x2, y1, y2);
refresh(scrbuf);
-
BUt what value do I use for scrbuf? Also, is there a way to draw a line directly to the screen?
-
BUt what value do I use for scrbuf? Also, is there a way to draw a line directly to the screen?
scrbuf isn't a value, it's a pointer. It is defined by the malloc statement. And to draw directly to the screen, you would use (char*)0xA4000100 instead of scrbuf as an argument to the line routine. This buffer might actually be defined somewhere already, but I'm not familiar with the Nspire include files.
-
There's really no reason to draw directly to the screen. Drawing to a buffer is faster and more versatile.
-
What Bwang said. Plus you won't get flickering when stuff moves around (and needs to be erased to do so). I don't know how Nspire ASM/C compares to 83+ Axe, but on 83+ Axe, inverting the entire screen bit by bit takes about 20-30 seconds for 6144 pixels if you draw directly to the LCD. When storing to the buffer then only updating the screen once everything is done, it took about half a second.
-
What Bwang said. Plus you won't get flickering when stuff moves around (and needs to be erased to do so). I don't know how Nspire ASM/C compares to 83+ Axe, but on 83+ Axe, inverting the entire screen bit by bit takes about 20-30 seconds for 6144 pixels if you draw directly to the LCD. When storing to the buffer then only updating the screen once everything is done, it took about half a second.
Well, on Nspire there won't be any speed difference when drawing to the LCD because it is memory-mapped like the TI-85 model and up. There might be some flickering though, if the screen updates while you are drawing your graphics.
-
Really? I thought that despite the screen being memory-mapped, there could still be a slight difference? I guess it makes sense that there isn't a speed change if it's really tied directly to the buffer, though.
-
"Some flickering" is an understatement. Without double-buffering, animations flicker so much that they are nearly unusable.
-
Well, my emulators actually draw directly to the screen buffer.
-
How do you prevent the flickering, though?
-
Hmmm...interesting.
I remember my raycaster flickering like crazy until I got double-buffering working.
Are you doing anything special?
-
Hmmm...interesting.
I remember my raycaster flickering like crazy until I got double-buffering working.
Are you doing anything special?
Well, in my emulators I'm not clearing the buffer and then drawing new graphics. I draw the graphics over the current buffer line-by-line (which is how the systems I'm emulating tend to operate anyway)
-
oooh I see, that explains why sprites won't flicker while the map is getting displayed. I assume they're drawn at the same time as the map, right?
-
oooh I see, that explains why sprites won't flicker while the map is getting displayed. I assume they're drawn at the same time as the map, right?
That's right. It's how some sprites are able to be displayed behind the map.
Actually, now that I think about it, I do have a very minimal form of double-buffering. In my GBC emulator, I draw the 160 pixels in a line to a small buffer, then copy it to the screen buffer (1 or 2 lines depending on the position, for aspect ratio purposes). In the TI-83+ and TI-89 emulators, there is stored an internal buffer of the emulated screen contents, and it is upscaled onto the screen buffer.
-
Aaah I see ^^
Nice job on the emus regardless, though
-
I've got the buffering all figured out, but it seems like nmath.h is missing from the skeleton. When I tried to compile a program using line, I got an error saying nmath.h doesn't exist.
-
I've got the buffering all figured out, but it seems like nmath.h is missing from the skeleton. When I tried to compile a program using line, I got an error saying nmath.h doesn't exist.
I am assuming that the abs( function is from nmath.h (that is the only one that did not "exist"). A simple solution would be to write your own abs( function, get rid of the "#include "nmath.h"" at the top and add your own abs( to the header. Here is a very basic one I wrote. I am sure that a smaller and faster version could be written:
int abs(int x) {
if (x<0) {
x*=-1;
}
return x;
}
-
How do I use the sprite function, specifically, how would I define the sprite?
-
Declare a sprite like this:
char sprite[32]={15,15,15,0,0,15,15,15,
15,15, 0, 0,0, 0,15,15,
15, 0, 0, 0, 0, 0, 0,15,
0 , 0, 0, 0, 0, 0, 0, 0};
The number of elements in the array should be equal to the height*width of the sprite. Each element should be the color you want the pixel to be. Bwang's sprite drawing functoin takes the syntax:
void sprite(char* scrbuf, char* sprite, int x, int y, int w, int h);
Where scrbuf is the buffer, sprite is the spite you want to draw, x is the x coordinate of the sprite, y is the y coordinate, w is the width, and h is the heigth
If you read my first, unedited post, please disregard it b/c some of the info was wrong. :)
-
Unfortunately, apcalc, I read you unedited post, but now it's all sorted out, and I can play pong on my nspire. 8)
-
Unfortunately, apcalc, I read you unedited post, but now it's all sorted out, and I can play pong on my nspire. 8)
Thats great to hear! I was used to the way you draw sprites on the 89, so I just assumed it was the same way. Feel free to ask if you have any more questions! :)
-
That sprite routine is not production ready. It works, but don't use it for anything fancy!
I need to change it to a proper sprite function that copies blocks of memory one row at a time.
I also attached nmath.h/c. Please please please don't use this in sensitive programs! Its slow, poorly written, and not all that accurate (e.g. sine and cosine are approximated with a couple of power series terms) - I was just collecting some routines for personal use. Your mileage with this file will vary, depending on the program.
Here's a nice way to do abs():
#define abs(a) (a) > 0 ? (a) : -(a)
-
I've been having a very odd bug with an Nspire C program. Every time I exit the program pressing ESC (for some reason my loss detection dosen't work) the calculator reboots (the emulator says "CPU Reset") (I have only tried this on the emulator). All of the other ASM programs I have on the emulator (ncaster, gbc4nspire, ndless demo) work correctly. Also in my code you will see that I have the loss detection commented out. When I have this part of the code, the calc reboots right after the dialog box displays. Here is the code:
#include <os.h>
#include "utils.h"
asm(".string \"PRG\"\n");
int main(void) {
char marker[32]={15,15,15,0,0,15,15,15,15,15,0,0,0,0,15,15,15,0,0,0,0,0,0,15,0,0,0,0,0,0,0,0};
short int leftx,length,ycord,lengthchange;
float spritepos;
char* scrbuf = (char*) malloc(SCREEN_BYTES_SIZE);
char* tempbuf = (char*) malloc(SCREEN_BYTES_SIZE);
showSimpleDialogBox("TI-Nspire Tunnel","TI-Nspire Tunnel\nWritten in C by Danny Clark\n\nUse the arrow keys to control ship");
clearScreen();
leftx=120,length=120,lengthchange=1000,ycord=0;
spritepos=180;
clearBuf(scrbuf);
for(ycord=0;ycord<SCREEN_HEIGHT;ycord++) {
horizontalline(scrbuf,0,leftx,ycord,0);
horizontalline(scrbuf,leftx+length,319,ycord,0);}
sprite(scrbuf,marker,150,236,8,4);
refresh(scrbuf);
leftx=120;
ycord=0;
while (!isKeyPressed(KEY_NSPIRE_ESC)) {
if (isKeyPressed(KEY_NSPIRE_LEFT)) {
sprite(scrbuf,marker,spritepos,236,8,4);
spritepos-=0.7;
sprite(scrbuf,marker,spritepos,236,8,4);}
if (isKeyPressed(KEY_NSPIRE_RIGHT)) {
sprite(scrbuf,marker,spritepos,236,8,4);
spritepos+=0.7;
sprite(scrbuf,marker,spritepos,236,8,4);}
sprite(scrbuf,marker,spritepos,236,8,4);
lengthchange--;
if (lengthchange==0) {length--;lengthchange=1000;}
scrollScreen(scrbuf,tempbuf,1);
horizontalline(scrbuf,0,leftx,ycord,0);
horizontalline(scrbuf,leftx,leftx+length,ycord,15);
horizontalline(scrbuf,leftx+length,319,ycord,0);
sprite(scrbuf,marker,spritepos,236,8,4);
refresh(scrbuf);
//if (getPixel(spritepos-1,ycord-3)||getPixel(spritepos+8,ycord-3)) {free(scrbuf);free(tempbuf);return 0;}
}
free(scrbuf);
free(tempbuf);
return 0;
}
Also, I don't have the code for the function horizontal line there but I am sure that is not the problem because it was defined and used well before I experienced this problem. This program was working fine earlier today, but I made a few small additons and now I have no idea what is causing this. Also, I made one small modification to the function "scrollScreen(". I changed the two signs in the function (+ to - and - to +) to make the screen go down instead of up.
-
Are you supposed to be able to use floats as arguments to the sprite routine?
-
Are you supposed to be able to use floats as arguments to the sprite routine?
No.
@apcalc: Post your modified scrollScreen().
-
bwang, that was the problem. I had SCREEN_BYTES_SIZE+bytesOffset, which probably made it larger that it could handle. Thank you so much for your help, I feel so stupid when it is a simple error like this. :) You might want to modify the utils.h/.c header to include functions for scrolling the screen up and down. Here are my (hopefully working :)) modified versions:
void scrollScreenDown(char* scrbuf, char* tmpbuf, int lines)
{
int bytesOffset = 160 * lines;
int cpysize = SCREEN_BYTES_SIZE - bytesOffset;
memcpy(tmpbuf, scrbuf - bytesOffset, cpysize);
memcpy(scrbuf, tmpbuf, cpysize);
memset(scrbuf + cpysize, 0xFF, bytesOffset);
}
void scrollScreenUp(char* scrbuf, char* tmpbuf, int lines)
{
int bytesOffset = 160 * lines;
int cpysize = SCREEN_BYTES_SIZE - bytesOffset;
memcpy(tmpbuf, scrbuf + bytesOffset, cpysize);
memcpy(scrbuf, tmpbuf, cpysize);
memset(scrbuf + cpysize, 0xFF, bytesOffset);
}
[\code]
-
Glad to hear its working :)
I should probably move the scroll functions to graphics.h.
-
Glad it's working. I wish you good luck in your projects, if any (Starcraft Nspire... j/k ;D )
-
We really need some documentation for these functions. I've started on it, and will post it when I'm done.
-
How do you convert an integer to a string? I wanted to display the score in a dialog box upon exiting my game.
Also, the documentation is almost complete for utils.h, except for fade, scrollscreen, and WAIT. What do all the arguments do in these functions?
-
Hmm, to convert an integer to a string, don't you do sprintf(string_ptr,"%i",score)
-
Unfortunately, sprintf hasn't been written yet. There was another, simpler function, itoa, but it depends on this standard library function.
-
I thought sprintf is part of the OS, and we are able to use it. Was I mistaken?
-
sprintf is part of the OS (at least it's defined in os.h).
scrollScreen() arguments:
scrollScreen(char* scrbuf, char* tmpbuf, int lines)
Scroll the screen buffer scrbuf up lines rows. tmpbuf is a temporary buffer of the same size as scrbuf used by the routine internally.
-
I never thought of looking there for sprintf. Thanks!
Also, at least on windows, the windows and linux makeTNS binaries can coexist peacefully, and I have a hunch it will be the same on linux, though someone should confirm it.
-
I updated the first post with a better graphics.h.
-
I found a small error in common.h.
The "?" key, named "KEY_NSPIRE_?" causes an error when compiling because of the ?.
I have attached a fixed version with this key named "KEY_NSPIRE_QUES"
-
Fixed in the first post :) Thanks for the bugfix!
Can someone verify whether the Linux and Windows versions of the tools can coexist in the same directory? That way I can merge the two skeletons.
-
I already said they can coexist on windows in a previous post here.
-
Right. I mis-read your post :(
-
This one is courtesy of calc84maniac:
void clear_buffer(char* buffer)
{
__asm__ __volatile__ (
"mov r1,#120\n\t"
"mvn r2,#0\n\t"
"mvn r3,#0\n\t"
"mvn r4,#0\n\t"
"mvn r5,#0\n\t"
"mvn r6,#0\n\t"
"mvn r7,#0\n\t"
"mvn r8,#0\n\t"
"mvn r9,#0\n\t"
"mvn r10,#0\n\t"
"mvn r11,#0\n\t"
"1:\n\t"
"stmia %0!,{r2-r11}\n\t"
"stmia %0!,{r2-r11}\n\t"
"stmia %0!,{r2-r11}\n\t"
"stmia %0!,{r2-r11}\n\t"
"stmia %0!,{r2-r11}\n\t"
"stmia %0!,{r2-r11}\n\t"
"stmia %0!,{r2-r11}\n\t"
"stmia %0!,{r2-r11}\n\t"
"subs r1,r1,#1\n\t"
"bne 1b\t"
:
: "r"(buffer)
: "r1","r2","r3","r4","r5","r6","r7","r8","r9","r10","r11"
);
}
It clears a screen buffer very, very quickly.
NOTE: It can only clear a screen buffer, not a buffer of arbitrary size.
Edit by calc84maniac: potentially harmful typo
-
Because of the release of Nleash and the ability to use Ndless on Touchpad Nspires, do we have the keypad mappings (or a new common.h file) for the touchpad. In this case, we could just compile four versions of our programs (Non CAS Clickpad, CAS Clickpad, Non CAS Touchpad, CAS Touchpad) to be used on any Nspire.
-
Actually, we wouldn't. You need a clickpad to run OS 1.1, no matter what hardware version.
-
Here are some text output routines. The character map is courtesy of Armael on United TI, and the routines are inspired by his, too. Right now, all I have is a function akin to TI-BASIC's text() function - pass it a string and some coordinates, and it will draw it to the designated screen buffer.
There used to be more, but no program loader -> no static variables -> a real console becomes incredibly unwieldy :( I thought about passing pointers to the cursor coordinates to the functions, but that's a bit too unwieldy.
File descriptions:
charmap_8x12.h: the character map.
screen.h: contains functions putChar and drawStr.
stdarg.h: variable-length argument list header.
string.h: some string functions
Do we have entry points for vsprintf()? That would make writing a printf() so much easier.
Enjoy! And remember, this is a very in-progress set of routines, so don't use them for anything fancy.
-
Thanks bwang! :)
These look very nice and it are a good start until we get a program loader!
-
Edited the first post and skeleton.zip to include the new text routines. I've found them rather useful, despite their limited abilities, so they've been integrated into skeleton.zip for the moment.
bsl and I (on United-TI) have found how to list files. This seems useful, so dirlist.h has been placed into skeleton.zip as well.
The syntax for dirlist() is:
int dirlist(char* path, char* pattern, char** result)
path: the folder you are looking in, e.g. "/documents/examples"
pattern: a search pattern, e.g. "*.tns"
result: a pointer to a char* (i.e. a list of strings) that will store the resulting filenames
return value: the number of files found
-
bwang, what about creating a static library for your useful functions?
-
That is a good idea. I presume Ndless supports such things at the moment, despite the lack of a program loader?
-
bwang, does the Makefile in skeleton.zip support YAGARTO 4.5.0? I was just looking at it (when I get my computer working again, I am going to start using the skeleton for my projects instead of the folder directly in Ndless), and I noticed that the prefix "arm-elf-..." is used. If I am not mistaken, YAGARTO 4.5.0 uses "arm-none-eabi-...".
-
Nope, the skeleton supports the arm-elf versions only. If you can modify it to work with 4.5.0 and post it, I'll attach it to the OP (I don't have a Windows machine to test on, so I can't update it).
-
Ok bwang, I try to modify it as soon as I can!
-
Updated the OP with a new skeleton.zip. filesize() should be useful for level loaders and the like.
apcalc, have you tested whether changing the Makefile works yet?
-
Nice to hear ^^
-
Easy ASCII input:
struct event {
unsigned int timestamp;
unsigned short type;
unsigned short ascii;
unsigned int key;
unsigned int unknown[3];
unsigned int control;
};
#ifdef CAS
#define get_event (_oscall(int, 0x100CBF78, struct event *))
#else
#define get_event (_oscall(int, 0x100CBF44, struct event *))
#endif
int getch() {
struct event event;
do {
get_event(&event);
} while (event.type != 8 || event.ascii == 0);
return event.ascii;
}
-
Wow...that is quite amazing.
It sure solves a lot of our problems :D
-
Nice :) So this is the event loop? There may be other interesting events to listen to, aren't there?
-
Event 0x8 is key down, 0x10 is key up. There's also event 0x20, appearing after 5 minutes of idleness, which perhaps is a timer used for automatic power down. I don't (yet) know if or how you can set your own timers.
Some other things of note:
- Most keys will only generate one key down event per press, but the arrow keys will repeat if held down long enough.
- The last word in the structure (the one I called "control", but now I see it's more general and would better be called "modifiers") describes what modifier keys are active after this event (Shift = 3, Ctrl = 4, Caps = 0x10).
- The "key" field is filled in incorrectly for some keys. For example, Q and U both give key code 0x62. Presumably U is supposed to be 0x61 (Shift-U does give 0x61, contrasting with Shift-Q which is still 0x62).
-
Very nice Goplat! Thank you for posting. :D
EDIT: I have been playing around with the Makefile included with Ndless 1.1 in order to make it compatible with including the headers from the skeleton. I have successfully made it include the header files in the "./headers" directory, but it dosen't like the "./system" directory, complaining of missing files which are incompatible when replaced. I have attached 1. An edited copy of the Makefile for Windows, 2. An edited copy of nspire-gcc for including the right headers, and 3. An edited copy of nspire-as for including the right headers. I am working on getting it to include the system files from the skeleton, but for now, it just uses the ones in Ndless (they are included from nspire-ld). The Makefile should replace the Makefile in the skeleton directory, and nspire-gcc and nspire-as should replace those in the Ndless /bin directory. All three of the needed files are included in the zip attached.
-
Is there a way to write a masked sprite routine that uses memcpy? I have a routine, but its based on the old routine.
-
@apcalc: if you'll post a known working version of the skeleton for Ndless 1.1, I'll attach it to the OP. Thanks in advance!
@fb39ca4: Hmm...can you explain what a masked sprite is? I'm not so good with sprites and such :(
-
Imo, it will write to the screen only what you say to. Such as, it will not overwrite the entire area of the sprite, it will only overwrite what you tell it to overwrite.
-
@bwang: A sprite mask determines which pixels in an image are transparent, so those pixels don't get copied to the screen. There is a more detailed explanation here (http://www.babek.info/libertybasicfiles/lbnews/nl143/sprite.htm). There are two ways to do this: create a second buffer with the mask data, or have one color in the image represent transparent.
-
Having one color represent transparency is probably the best way to go, because the Nspire can only display 15 shades of gray. And I doubt using memcpy would work (especially because there are two pixels per byte)
-
Well then, here's my masked sprite function:
void masksprite(char* scrbuf, char* sprite, int x, int y, int w, int h)
{
int i, j;
for (i = 0; i < w; i++) {
for (j = 0; j < h; j++) {
if (sprite[i + w * j] < 16) {
setPixelBuf(scrbuf, i + x, j + y, sprite[i + w * j]);
}
}
}
}Any value over 15 in the sprite will be treated as transparent.
-
I've attached skeleton-static-1.0.0.zip. This experimental version has all of the routines compiled into a static library. The Makefile links against this library, instead of compiling all those .c files. As such, the .c source for the libraries have been moved to the directory src/, and all of the .h files have been moved to the directory headers/.
Try it and see if it works!
-
Thanks bwang. I've been meaning to criticize some of the Nspire C code that's going around, having it all in one place makes that easier :)
console.c
Has no protection against writing past the end of buf. Also, I think scrbuf is unnecessary; drawing directly to A4000100 should be fine. It shouldn't flicker; flicker comes from drawing to the same part of the screen in multiple passes. For example, if you first draw a background and then draw a sprite on top of that, there's a brief period of time when the sprite isn't there. Since putChar works in a single pass, it's just fine to use it directly on the screen.
dirlist.c
This is a bad function even in concept - the caller has no way to know how big an array to allocate for result unless it has already enumerated the directory itself.
screen.c
Looks ok.
string.c
itoa, strlen, strcpy, strcmp: Looks ok.
atoi: Doesn't conform to the C standard. Should allow initial whitespace characters (i.e. space, tab, line feed, vertical tab, form feed, and carriage return), and should stop at the first non-digit. A standards-conforming implementation of atoi exists in the TI OS at address 1018DC44 (non-CAS) or 1018D94C (CAS).
syscalls.c
What the heck is this?
utils.c
rect_intersect, refresh, clearScreen, clearBuf, setPixel, setPixelBuf, getPixel, getPixelBuf, rand, showSimpleDialogBox: Looks ok.
fade: The loop is one byte too short. Should start with i = 0.
scrollScreen: Works, but there is no reason why such a function should require a temporary buffer. Just use memmove (address 1018606C in the non-CAS OS, 10185D74 in the CAS OS):
memmove(scrbuf, scrbuf + bytesOffset, cpysize);
memset(scrbuf + cpysize, 0xFF, bytesOffset);
scrollScreenDown: Doesn't work, probably will crash. This should be done as:
memmove(scrbuf + bytesOffset, scrbuf, cpysize);
memset(scrbuf, 0xFF, bytesOffset);
scrollScreenUp: Function is identical to scrollScreen. No reason both should exist.
filesize, getch: Looks ok.
-
I haven't a clue what syscalls.c is. It came with Ndless.
I didn't have memmove when I wrote scrollScreen(). I'll fix that in a bit.
I'll add the OS calls for memmove and atoi.
How do you suggest I check for overflow in dirlist and console? Right now when I use those functions I just allocate a really big buffer.
-
I actually think it might be advantageous to make our own optimized memcpy, mommove, and memset routines for the Ndless library, because the versions in the OS can be very slow (it does it byte-by-byte in all cases)
-
Fixed some stuff. New folder is attached.
-
Looks nice bwang!
Thanks for all of your hard work! :)
-
Thanks! Have you tested it? If it works with your projects, I think I'll replace the skeleton in the OP with it.
-
Yes, I have tested this and it seems to work fine!
The only complaint I have is that the compiled program, on the emulator, was 33K (this was the main.c with no actual code in it included in the library, not one of my programs). I assume this could be caused by my GCC/Makefile I am using (it is probably including functions not actually used by the program, say atoi(, for example). I am not good at all with coding Makefiles (I used the one that came with Ndless--not the one included with the library, which gave me an error message), so I really don't know if this is fixable. I do like how all of the functions are in one place, though! If nothing, I could just pick and choose the headers I want and just not build the .a file. Thanks again for your hard work on this :D!
-
Hmm...perhaps I should break the libraries into separate files, so the user does not need to link everything into his program.
Then again, 33K is not very large considering the fact that the Nspire has 32 MB of flash. Even accounting for the OS, it's still over 20 MB.
-
33K is not very large in itself, but that is just what you are starting with. I know that currently Trapped is 20K. If I added these files in, that might double the size. An extra, say 15-20K on every Ndless program you have on your calc can add up quickly. There has to be some way to have it not include the unused functions. I am almost sure TIGCC/GCC4TI dose it. You can include one file:
#include <tigcclib.h>
This includes all headers for use, but it does not start the program at the size of all of the headers plus your code, only your code and the functions used by it. I am not sure how it is done, but one of the maintainers of GCC4TI might know.
-
I haven't a clue what syscalls.c is. It came with Ndless.
syscalls.c contains OS stubs requires by "newlib" (the implementation of stdlib integrated with YAGARTO).
The stdlib is not really required in our case, because most of the functions can be found in the TI-Nspire OS, you just need to define them in Ndless headers.
And it appears that newlib is built without -fpic in YAGARTO (pc-relative instructions), so the stdlib functions may crash.
The stdlib should only be enabled if the program uses floating-point arithmetic, similarly to the Ndless's particles demo.
Most programs should be built with the -nostdlib option for nspire-ld.
There has to be some way to have it not include the unused functions. I am almost sure TIGCC/GCC4TI dose it.
Headers do not influence program size, the libraries does. The .a file should contain separate .o files (as it does). The granularity for inclusion is a .o file. So your problem is quite strange.
Could you try to build with the flag -nostdlib for nspire-ld? Could you check that the .tns doesn't contain series of zeros?
Could you try to run a "arm-none-eabi-objdump.exe -D <your_program.elf>" which disassemble the program, and see which symbols appear?
-
This is really strange, but I went back to compile the same exact file, and it compiled to 3K!
Even better, when I added the flag -nostdlib to the Makefile, the size went down to 1K (although this would only work for the blank file included with the skeleton; when I tried it on Trapped, it complained of undefined references to memset and memcpy)!!
I can't explain why it went down from 33K, as I made no edits at all, but at least it is working now!!
-
Did you change some files used for compiling? That seems a bit strange. I hope this doesn't mean data loss... x.x
-
when I tried it on Trapped, it complained of undefined references to memset and memcpy)!!
This is odd: this means you are using stdlib's memset/memcpy instead of the TI-Nspire OS's.
Does the .c which memsets/memcopies includes <os.h>?
-
Yes, the .c file includeds <os.h>
Even stranger, I went to test this by renaming all instances of memset and memcpy to _memset and _memcpy, respectively, and went into <os.h> and renamed memset and memcpy (the ti-os ones) to _memset and _memcpy, respectively, and it still complained memset and memcpy were undefined, despite the fact that they are not even used by the program at all.
What is confusing me even more is that it is complaining that these two functions are not defiend in a function that does not even use these functions at all. Here is the error I am getting:
Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$ make clean;make
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c main.c
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c utils.c
nspire-ld main.o utils.o -nostdlib -o Trapped.elf
utils.o: In function `setlevel':
utils.c:(.text+0x28): undefined reference to `memset'
utils.c:(.text+0x1f8): undefined reference to `memset'
utils.o: In function `setladder':
utils.c:(.text+0x504): undefined reference to `memset'
utils.c:(.text+0x540): undefined reference to `memset'
utils.o: In function `drawlevel':
utils.c:(.text+0x8f0): undefined reference to `memcpy'
utils.c:(.text+0x904): undefined reference to `memcpy'
utils.c:(.text+0x918): undefined reference to `memcpy'
utils.c:(.text+0x92c): undefined reference to `memcpy'
utils.c:(.text+0x944): undefined reference to `memcpy'
utils.o:utils.c:(.text+0x95c): more undefined references to `memcpy' follow
collect2: ld returned 1 exit status
make: *** [Trapped.tns] Error 1
Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$
The function "setlevel" does not call these functions at all; drawlevel only calls them in the form of the sprite function and to clear a buffer.
-
gcc will sometimes emit calls to memset or memcpy functions if you initialize or assign large structures. Having them as macros won't help. I think we need to have real memset and memcpy functions in the library (even if all they do is call the OS functions).
-
Yes, the .c file includeds <os.h>
Even stranger, I went to test this by renaming all instances of memset and memcpy to _memset and _memcpy, respectively, and went into <os.h> and renamed memset and memcpy (the ti-os ones) to _memset and _memcpy, respectively, and it still complained memset and memcpy were undefined, despite the fact that they are not even used by the program at all.
What is confusing me even more is that it is complaining that these two functions are not defiend in a function that does not even use these functions at all. Here is the error I am getting:
Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$ make clean;make
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c main.c
nspire-gcc -Os -Wall -W -fpic -fno-merge-constants -D NON_CAS -c utils.c
nspire-ld main.o utils.o -nostdlib -o Trapped.elf
utils.o: In function `setlevel':
utils.c:(.text+0x28): undefined reference to `memset'
utils.c:(.text+0x1f8): undefined reference to `memset'
utils.o: In function `setladder':
utils.c:(.text+0x504): undefined reference to `memset'
utils.c:(.text+0x540): undefined reference to `memset'
utils.o: In function `drawlevel':
utils.c:(.text+0x8f0): undefined reference to `memcpy'
utils.c:(.text+0x904): undefined reference to `memcpy'
utils.c:(.text+0x918): undefined reference to `memcpy'
utils.c:(.text+0x92c): undefined reference to `memcpy'
utils.c:(.text+0x944): undefined reference to `memcpy'
utils.o:utils.c:(.text+0x95c): more undefined references to `memcpy' follow
collect2: ld returned 1 exit status
make: *** [Trapped.tns] Error 1
Danny@DANNYCOMPUTER /c/users/danny/documents/ti-nspire/development/trapped
$
The function "setlevel" does not call these functions at all; drawlevel only calls them in the form of the sprite function and to clear a buffer.
Is this only a problem when you use the statically-linked library?
-
This is only a problem when the flag -nostdlib is added to the ld part of the makefile (I discovered it when ExtendeD suggested it as a fix to the "random" large file size).
When I remove the flag, everything is fine.
EDIT: Also, the program that gives that error (Trapped) does not even use the static library (I have been too lazy to change it over).
-
gcc will sometimes emit calls to memset or memcpy functions if you initialize or assign large structures. Having them as macros won't help. I think we need to have real memset and memcpy functions in the library (even if all they do is call the OS functions).
In the next release of Ndless, OS calls will be defined as static inline functions. I'm not sure how GCC will react in this case.
-
hmm, good to hear that ndless is being worked on still :P
-
Another problem with -nostdlib:
While playing around with the PTT LED, I was compiling my programs with this flag. The calculator would randomly reset on some occasions of running the program. When I removed it, everything was fine. I would definitely not recommend using this flag.
-
This is really weird. Would you be able to share a test case showing the problem, with its source code?
-
Here you go. The compilied version is attached. It should just turn the PTT LED yellow. For me, it did not reset the Nspire every time I ran it, but there was no clear pattern with the resets. Also, I don't think Ndless Version 1.1 works with Nspire Computer Link 1.4. I tried it last night; it worked perfectly with Link 1.3, but when I used Link 1.4, it said it could not send the loader. It did create the directory "ndless" on the calculator, though.
#include <os.h>
asm(".string \"PRG\"\n");
int main(void)
{
(*(volatile unsigned*) 0x90110B00)=0x00;
(*(volatile unsigned*) 0x90110B00)=0x30;
return 0;
}
-
i dont think it is wise to complain about people's slight punctuation and grammer errors bwang. like you should'nd poop make giant threads and trolls and poop poop poopinsults about pooping poop use of poops . don't show off you rgrammer skills.i dissaprove bwang
Edited for bad language
-
ah, but ndless does work with ti-nspire computer link 1.4. Ndless 1.1 that is. 1.0 doesn't work.
verdant too many f***. if you really have to, use f***. don't want to see that word. complaints by heaps of people will be made soon. you might even get kicked (banned) prepare to get a word of disapproval from dj omni anymoment
i use damn or crap - mild swear words - but that's about it
and don't disapprove bwang. he's one of the coders of tomorrow. he'll be angry when he sees this
i just looked at your respect. (i added -2 though) it's at -7. terrible!!!!
actually -12 now
-
It's one of bwang bro/sis I think, because the IP address is exactly the same as his home's. Now Bwang lives at his campus, though, so his bro/sis or whatever can use his computer whenever he wants, and he seems to hate this forum. I wonder where Bwang is, though. He normally shows up on IRC somewhere around this time.
Also Jhgenius0, swearing is allowed here, as long as it's not spam. If someone say "fuck" he'll not get punished for it. If his entire post is filled with them and totally unreadable he may end up getting warned/punished, though, due to the spam
-
ah, but ndless does work with ti-nspire computer link 1.4. Ndless 1.1 that is. 1.0 doesn't work.
I just tried it the other day. It did not work for me at all with 1.4 (mutiple tries and copies of Ndless from different sources). I downgraded to Link 1.3, and it worked fine.
-
i dont think it is wise to complain about people's slight punctuation and grammer errors bwang. like you should'nd poop make giant threads and trolls and poop poop poopinsults about pooping poop use of poops . don't show off you rgrammer skills.i dissaprove bwang
Edited for bad language
1. I dont think I like you...
2, Mild? I think thats an understatement
but, i dont think this should be a fight, lets start puttingo n some more routines
-
apcalc: Sorry for the annoyance for some of you. I prefer focusing on the next release which gets rid of the installer instead of trying to debug these issues.
-
Ok, thats fine ExtendeD!
I don't mind downgrading my link software, I just thought I would point out the bug.
Thank you for your hard work for the community! :)
-
ExtendeD, what do you mean by "get rid of the installer"? Now I am confused..
-
I assume it will run something like Nleash-you send it to the calc, run the document, and it does its stuff! :D
-
The installation procedure doesn't depend on a computer-side installer anymore.
-
as, ok, I get it
good work extendeD! Cant wait for 1.7 compatibility
(I would say 2.0, but I dislike 2.0)
-
i dont think it is wise to complain about people's slight punctuation and grammer errors bwang. like you should'nd poop make giant threads and trolls and poop poop poopinsults about pooping poop use of poops . don't show off you rgrammer skills.i dissaprove bwang
Edited for bad language
1. I dont think I like you...
2, Mild? I think thats an understatement
but, i dont think this should be a fight, lets start puttingo n some more routines
If you read the IRC logs, you'll see that verdant happens to be my brother trying to annoy me :P
-
Yup. What should happen is that your home's IP address should be banned unless you are logged in.
-
Yup. What should happen is that your home's IP address should be banned unless you are logged in.
This has been done already.
-
apcalc: Sorry for the annoyance for some of you. I prefer focusing on the next release which gets rid of the installer instead of trying to debug these issues.
By getting rid of the installer, do you mean we will just send a program like any other to the Nspire from now on?
Yup. What should happen is that your home's IP address should be banned unless you are logged in.
This has been done already.
Actually, the way it is set up, you would not even be able to browse the forums while logged in either from your parents home. I may lift it after a week or so due to the banning policies here, but if he does it again the IP would be banned whenever you don't have to go use the computer at your parents home.
-
]Actually, the way it is set up, you would not even be able to browse the forums while logged in either from your parents home. I may lift it after a week or so due to the banning policies here, but if he does it again the IP would be banned whenever you don't have to go use the computer at your parents home.
Better just keep it banned until I get home.
Just don't ban me from IRC so I can request to be unbanned.
-
DJ Omnimaga: you'll need an on-calc installation, only once after a reset.
-
So it's going to be a hook like the ones various 83+ apps installed that get erased every ram clear?
-
For the moment yes, but making it persistent could be possible in the future.
-
Something I would like to see is running a custom program on startup. This could be used by someone who makes a 83/84 emu, that could install a hook to run it everytime the calc is started with an 84 keypad.
-
DJ Omnimaga: you'll need an on-calc installation, only once after a reset.
Ok cool, thanks for the info :)
-
fb39ca4: sure, this is in the todo list.
-
Btw, I wrote a small random number generator
int SEED = 12345;
int myrandint(int low, int high)
{
int rand = *(volatile unsigned*) 0x900D000C;
rand = ((rand * SEED) % (high - low)) + low;
return rand;
}
-
What's in 0x900D000C?
And how would you get the seed to automatically change?
-
*(volatile unsigned*) 0x900D000C reads the current time from the RTC.
-
*(volatile unsigned*) 0x900D000C reads the current time from the RTC.
Actually, that is a 16-bit increasing counter that the OS has set up to increase 32768 times per second.
-
*(volatile unsigned*) 0x900D000C reads the current time from the RTC.
Actually, that is a 16-bit increasing counter that the OS has set up to increase 32768 times per second.
^ This.
Setting the seed won't really do much, but I figured I'd add it anyways :P I think I used this method for getting random numbers from BBC Basic on-calc.
-
Ah.
This would be better than the current function, where you'd have to make sure the seed is different each time the prog is run.
-
Here is a simple routine to set the LED a certain color. It does not support blinking. I know it is kinda useless, but I though I would post it anyway. Pass it 0 to turn the LED off, 1 to make it green, 2 to make it red, or 3 to make it yellow:
void set_led(int color) {
*(volatile unsigned*) 0x90110B00=0x00;
switch(color) {
case 0:
break;
case 1:
*(volatile unsigned*) 0x90110B00=0x10;
break;
case 2:
*(volatile unsigned*) 0x90110B00=0x20;
break;
case 3:
*(volatile unsigned*) 0x90110B00=0x30;
};
}
-
It's actually not necessary to write 0 first unless you are using the blinker. A simplified version of this routine would be
*(volatile unsigned*) 0x90110B00 = color << 4;
-
So I got the skeleton downloaded and set up under Ndless 1.7. However, using MinGW to compile it, it tells me "make: arg-elf-gcc: Command not found" and errors out.
Any idea why?
EDIT: Got that working, but now objcopy won't work.
"arm-elf-objcopy: Command not found"
-
If you are using Ndless 1.7, I don't think a skeleton is required anymore.
Are you using YAGARTO v4.5.1 or later? Then the GCC and binutils commands used in your Makefile should begin with "arm-none-" instead of "arm-elf-".
I also suggest you use the Makefile template provided in the samples/hello directory of Ndless v1.7. You can also try to begin with the step-by-step tutorial available on Hackspire: http://hackspire.unsads.com/wiki/index.php/C_and_assembly_development_introduction
-
Thanks, and I went through that tutorial, it works great :)
I want to get the libraries from the skeleton working, though, I'll post more specific errors in a few.
-
Aren't bwang's functions now packed as a static library? This is really the best way to make code available to other developers.
We can add tutorials on how to build and import static libraries to Hackspire if needed.
-
Well, not knowing what that means, I can't really answer it. I got it working, though.
-
There is a static version lurking somewhere on this thread. I probably should update the OP and change skeleton to just a set of libraries, since it is no longer necessary for Ndless 1.7.
-
Good idea. Right now I'm just using the libraries.
-
*NECROBUMP*
Is there a clipped sprite routine?
-
Have you looked in nRGBlib ?
-
Have you looked in nRGBlib ?
I didn't see a clipped sprite.
-
Isn't the normal sprite routine already clipped?
-
Isn't the normal sprite routine already clipped?
Yeah, it was one of its features :
https://tiplanet.org/forum/viewtopic.php?f=20&t=8597&p=123205&hilit=nRGBlib#p123205
-
Isn't the normal sprite routine already clipped?
Yeah, it was one of its features :
https://tiplanet.org/forum/viewtopic.php?f=20&t=8597&p=123205&hilit=nRGBlib#p123205
I don't see any sprite routines at all. D: The highest version uploaded is 0.2.
-
Isn't the normal sprite routine already clipped?
Yeah, it was one of its features :
https://tiplanet.org/forum/viewtopic.php?f=20&t=8597&p=123205&hilit=nRGBlib#p123205
I don't see any sprite routines at all. D: The highest version uploaded is 0.2.
Google .. https://bitbucket.org/totorigolo/nrgblib/overview
-
nSDL (http://hoffa.github.io/nSDL/) is the recommended graphics library and is provided with the Ndless SDK. Did you have a look at it?