Omnimaga
Calculator Community => Casio Calculators => Topic started by: fb39ca4 on August 31, 2011, 12:40:40 am
-
I am totally overwhelmed with the prizm mini SDK documentation. Right now all I need to know is: How do I draw pixels, both directly to the screen and to a back buffer, and how do I read keypresses?
-
You could use the following syscalls:
write a pixel to VRAM:
0x0263
void Bdisp_SetPoint_VRAM( int x, int y, unsigned short color );
directly draw a pixel:
0x026B
void Bdisp_SetPoint_DD( int x, int y, unsigned short color );
read the keyboard (blocking):
0x0EAB
int GetKey( int*key );
read the keyboard (non-blocking):
0x12BF
int GetKeyWait_OS(int*column, int*row, int type_of_waiting, int timeout_period, int menu, unsigned short*keycode );
These are only examples for a start.
It is possible to read the keyboard-registers directly, to gain speed, if necessary.
Or you can write to VRAM by simple memory-write-operations.
I recommend the use of syscalls as much as possible.
Especially there are some drawing-syscalls, which save a lot of source code and coding time.
-
How fast are they? An inline function would be better, I could make one if i knew the addresses.
-
How fast are they? An inline function would be better, I could make one if i knew the addresses.
Well, for graphics drawing, I've been doing it all either inline with just managing pixels with simple memory management within VRAM, or wrote some application specific (mostly size-constant and sprite offset address-constant) graphics routines instead of using the graphics syscalls.
For GetKey routines, I use this routine by Kerm:
int PRGM_GetKey(){
unsigned char buffer[12];
PRGM_GetKey_OS( buffer );
return ( buffer[1] & 0x0F ) * 10 + ( ( buffer[2] & 0xF0 ) >> 4 );
}
-
Is that one considerably faster or is it like BASIC getkey speed? The other day Eiyeron was trying various getkey routines and kept reporting that anything he was trying was as slow as BASIC. Maybe I missed something, though.
Also it is in the wrong forum section. Technically people aren't even supposed to be able to post in here, but there is a permission issue on the forums it seems. X.x
-
It actually works very well -- I'd compare it to the GetKey routine Axe has.
-
Ok that's good then. I was a bit worried X.x
-
Ok that's good then. I was a bit worried X.x
on a side note, it does sometimes act weird for reasons I'm not sure about (sometimes it will not register a keypress), but I only noticed that problem once; it should be good.
-
So what address is the VRAM located at? (Is it memory mapped?) I'd like to make a screen buffer and copy stuff to the VRAM. Also, what does blocking and non blocking mean?
-
Blocking means it waits for a key, non blocking means it checks for any currently pressed keys and returns which one is pressed.
VRAM is situated at the address 0xA8000000, but I suggest using something like this to make sure you will always use VRAM if the address changes in OS versions:
#define D_VRAM GetVRAMAddress();
GetVRAMAddress() I believe is in either system.h, or one of the display headers.
Another thing, VRAM is *very* large; larger than the amount of memory you're allowed to allocate. So, you're rather forced to have just one buffer at this moment.
-
Thanks, though it would be faster to create a pointer that has the address rather than calling the function every time the address is needed. I guess the large space needed is one of the downsides of having a 16 bit color screen :P 384*216*2 bytes = 165888 bytes. Is there a way to stop the screen from updating while graphics are drawn to the VRAM to eliminate flicker? (Come to think of it, that is actually a lot more efficient than using a screen buffer.)
-
Thanks, though it would be faster to create a pointer that has the address rather than calling the function every time the address is needed. I guess the large space needed is one of the downsides of having a 16 bit color screen :P 384*216*2 bytes = 165888 bytes. Is there a way to stop the screen from updating while graphics are drawn to the VRAM to eliminate flicker? (Come to think of it, that is actually a lot more efficient than using a screen buffer.)
The VRAM is not connected directly to the screen, there is an OS function to transfer to the screen (like on the TI-83+, except the LCD controller doesn't suck)
-
Oh, so the screen on the Prizm is more similar to the 8x calcs rather than the Nspire? What LCD controller does it use?
-
What LCD controller does it use?
Obviously a customized one, but similar to some renesas LCD controllers:
http://ourl.ca/8207/232704
Some additional information is gathered in
fx_calculators_SuperH_based_10.chm
-
Why don't we have access to screen border?
-
Why don't we have access to screen border?
Do you mean in BASIC because that's pretty common in any calc basic language but in C you have full access to the 216*384 screen.
-
Why don't we have access to screen border?
You have. See syscalls 0x02A4 to ox02AA (especially 0x02AA).