I agree with Lincoln, the best way is to understand what you are doing. Figure out what is wrong, brainstorm and fix it. How I learned was starting very small asking questions and moved on from there. You might want to understand C a bit more before trying these things. Good luck.
So, now I know it's called a segfault, but I still don't know how to fix it. There is no errors when compiling. I have no clue what's wrong.
You must be familiar with the concepts of pointer and memory address.
It's simple, just read your code with brain turned on. If frames==0, you read a 160*160 bitmap at address NyanCat1. If frames==4 (maximum value in your code), you read a 160*160 bitmap at address 4*160*160+NyanCat1. Therefore NyanCat1 is an array of 5 bitmaps 160*160, 16bpp ? NyanCat1 is really an array of 256000 bytes ? If not, you inevitably obtain an error.
I saw you edited your post. Why do you wrote "frames%12" if frames can't be upper than 4 ?
It's simple, just read your code with brain turned on. If frames==0, you read a 160*160 bitmap at address NyanCat1. If frames==4 (maximum value in your code), you read a 160*160 bitmap at address 4*160*160+NyanCat1. Therefore NyanCat1 is an array of 5 bitmaps 160*160, 16bpp ? NyanCat1 is really an array of 256000 bytes ? If not, you inevitably obtain an error.
I saw you edited your post. Why do you wrote "frames%12" if frames can't be upper than 4 ?
Why do you need to do frames modulo anything if the max position in the frame variable is exactly equal to the number of frame animations?
% is the operator for Modulus Division, or a modulo operation. http://lmgtfy.com/?q=modulo will bring up some results if you don't know what the operator does. As far as I can tell, in your code, it's doing absolutely nothing.
Basically, Spence, that mod operator has no use there because you're also resetting the value of "frames" every time it hits 4. Since you're doing both, one of them can be taken out (I would say to take out the part where you reset it, since that frames variables will be useful to mod off of for different animations with different amounts of frames and speeds of animation)
Does anyone know what's wrong with this code?
Code:
It keeps giving me this:
Code:
Code:
#include "stdio.h"
#include "keyboard.hpp"
#include "display.h"
#include "keyboard_syscalls.h"
#include "stdlib.h"
FILE *fopen(const char *filename, const char *mode);
int PRGM_GetKey(){
unsigned char buffer[12];
PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
}
FILE *fp;
int fclose(FILE *a_file);
int main() {
while(1) {
int key = PRGM_GetKey();
if(key == KEY_PRGM_MENU) { GetKey(&key); }
Bdisp_EnableColor(1);
fp=fopen("test.txt", "r");
Bdisp_PutDisp_DD();
}
fclose(fp);
return 0;
}
It keeps giving me this:
Code:
main.o: In function `_main':
main.c:(.text.startup+0x78): undefined reference to `_fopen'
collect2: ld returned 1 exit status
make: *** [TxtEdit.bin] Error 1
We don't have much of anything from the standard library (yet). You'll either need to use the Bfile_* family of functions or live on the bleeding edge with the (largely untested) pycompat branch of libfxcg.
The latter choice is more desirable from my viewpoint (as it gets somebody using and testing this new code), but will involve chasing down bugs and some additional manual setup.
The latter choice is more desirable from my viewpoint (as it gets somebody using and testing this new code), but will involve chasing down bugs and some additional manual setup.
Okay. So I changed some of the stuff in the Nyan Cat addin again, but it still is crashing my calculator. It compiles perfectly though...
Code:
Code:
#include "keyboard.hpp"
#include "color.h"
#include "display.h"
#include "keyboard_syscalls.h"
#include "NyanCat.h"
void CopySprite(const void* datar, int x, int y, int width, int height) {
color_t*data = (color_t*) datar;
color_t* VRAM = (color_t*)0xA8000000;
VRAM += LCD_WIDTH_PX*y + x;
for(int j=y; j<y+height; j++) {
for(int i=x; i<x+width; i++) {
*(VRAM++) = *(data++);
}
VRAM += LCD_WIDTH_PX-width;
}
}
int PRGM_GetKey(){
unsigned char buffer[12];
PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
}
int f = 1;
int main() {
while(1) {
int key = PRGM_GetKey();
if(key == KEY_PRGM_MENU) { GetKey(&key); }
CopySprite(f%12*160*160+(color_t*)NyanCat1, 0, 0, 160, 160);
f++;
Bdisp_PutDisp_DD();
Bdisp_AllCr_VRAM();
}
return 0;
}
It crashes? You're probably going to need to be more specific. What exactly happens when you run the application?
LincolnB wrote:
It crashes? You're probably going to need to be more specific. What exactly happens when you run the application?
Seconded. You also need to learn to do some debugging on your own. For example, comment out the sprite-drawing routine and see if it still crashes. If so, comment out more stuff. When it stops crashing, you can then gradually add stuff back in until it starts crashing again. Voila. 
LincolnB wrote:
It crashes? You're probably going to need to be more specific. What exactly happens when you run the application?
Well, when I run the addin, it displays a white screen, then it displays the reboot menu.
KermMartian wrote:
LincolnB wrote:
It crashes? You're probably going to need to be more specific. What exactly happens when you run the application?
Seconded. You also need to learn to do some debugging on your own. For example, comment out the sprite-drawing routine and see if it still crashes. If so, comment out more stuff. When it stops crashing, you can then gradually add stuff back in until it starts crashing again. Voila.Comment it out? I'm not sure what you mean.
When you comment out code, it means you wrap it in /* */, or you put //s before it, turning it into comments so that it doesn't run that part of the program. By removing bits of the program, you can narrow down where bugs are occurring.
Okay. I might try that. I wish there were an easier way. Like running it though a program or something.
Spenceboy98 wrote:
Okay. I might try that. I wish there were an easier way. Like running it though a program or something.
If programs could fix programs, then we wouldn't need programmers. 
Actually, when you're testing on a more mature platform, there's a program called GDB (the GNU DeBugger). It will show you the exact line number where a segmentation fault occurred when you get a seg-fault, which makes debugging this kind of problem much, much easier. Sadly, we have no gdb for the Prizm yet.
Okay. It's the "CopySprite(f%12*160*160+(color_t*)NyanCat1, 0, 0, 160, 160);" line. I still don't understand what's wrong though.
A seg fault occurs when you try to access a memory location that doesn't exist. This means you have a pointer that went wrong somewhere. (You do know about pointers, right?) So, somewhere in that CopySprite line, you are trying to access a memory location that is somehow invalid (or nonexistent)
Register to Join the Conversation
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