Useful Prizm Routines - Cemetech | Forum | Casio Development & Programming [Topic]

KermMartian
Site Admin (Posts: 63789)

17 May 2011 05:49:45 pm

The short is indeed always 16 bits on the Prizm, and I think there are very few platforms that would be awkward enough to have a short that is not 16 bits wide, I hope. Smile

christop
Power User (Posts: 385)

17 May 2011 06:21:28 pm

KermMartian wrote:

The short is indeed always 16 bits on the Prizm, and I think there are very few platforms that would be awkward enough to have a short that is not 16 bits wide, I hope. Smile

The one platform that I am most familiar with that doesn't use 16-bit shorts is the PDP series of minicomputers. Some of those used 18-bit shorts and 9-bit chars. Very Happy

But even that shouldn't be too awkward to use in C unless you do a lot of heavy bit twiddling. As a bonus, you get 36-bit longs, which have 16 times the range as 32-bit longs (±32 billion).

KermMartian
Site Admin (Posts: 63789)

18 May 2011 01:06:30 am
Last edited by KermMartian on 22 May 2011 12:22:32 pm; edited 1 time in total

Ah yes, the infamous 9-bit byte PDPs. Smile

Sadly, it seems that an inordinate number of mt programs do end up doing odd bit-twiddling tricks; maybe I'm (too) used to working in low-level languages. Anyway, getting this show back on-topic, I have a CopySpriteMasked routine that treats one specified color as "transparent":

CopySpriteMasked

Code:

void CopySpriteMasked(const char* data, int x, int y, int width, int height, int maskcolor) {


   char* VRAM = (char*)0xA8000000;


   VRAM += 2*(LCD_WIDTH_PX*y + x);


   for(int j=y; j<y+height; j++) {


      for(int i=x; i<x+width;  i++) {


         if ((((((int)(*data))&0x000000FF)<<8) | ((((int)(*(data+1))))&0x000000FF)) != maskcolor) {


            *(VRAM++) = *(data++);


            *(VRAM++) = *(data++);


         } else { VRAM += 2; data += 2; }


      }


      VRAM += 2*(LCD_WIDTH_PX-width);


   }


}

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 11:46:21 am

Generate pseudo-random number

input - 32bit integer for upper and lower bounds

this is based on the famous '128bit shifting' technique, and is considered highly random enough.

Code:

int Rand32(int lower, int upper) {


  static int a = 123456789;


  static int b = 362436069;


  static int c = 521288629;


  static int d = 88675123;


  int t;


 


  t = a ^ (a << 11);


  a = b;


  b = c;


  c = d;


  return (d = d ^ (d >> 19) ^ (t ^ (t >> 8)))%upper + lower;


}

KermMartian
Site Admin (Posts: 63789)

22 May 2011 12:23:17 pm

What's the source for your algorithm for that, Ashbad?

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 12:30:45 pm

it is based on this: http://en.wikipedia.org/wiki/Xorshift

also,

Test a pixel of CURRENTLY rendered VRAM image

inputs: X and Y position
outputs: short holding color value

Code:

short GetPXColor(short x, short y) {


   char* VRAM = (char*)0xA8000000;


   char a = *(y * LCD_WIDTH_PX + x * 2);


   char b = *(y * LCD_WIDTH_PX + x * 2 + 1);


   short c = a << 8 + b


   return c;


}

KermMartian
Site Admin (Posts: 63789)

22 May 2011 12:31:41 pm

Not bad. My getpoint looks like this:

Code:

//gets color of point (x0, y0)


int getpoint(int x0, int y0) {


   char* VRAM = (char*)0xA8000000;


   VRAM += 2*(y0*LCD_WIDTH_PX + x0);


   return ((((int)*(VRAM)) << 8) & 0x0000FF00) | (((int)*(VRAM+1)) & 0x000000FF);


}

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 12:35:42 pm

hmm -- would the addition I do have any difference when compared to your or-ing? could it possibly interfere with the topmost 8 bits?

Tari
1
Systems Wrangler (Posts: 3366)

22 May 2011 12:45:11 pm

More importantly, I fail to see why you're both using char* when accessing 16-bit chunks in the native byte order. Provided there's no odd alignment requirement on VRAM (which seems unlikely, given that GetVRAMAddress returns a void*), this would be a little faster:

Code:

unsigned short getpixel(int x, int y) {


    unsigned short *VRAM = (unsigned short *)0xA8000000;


    return *(VRAM + (y * LCD_WIDTH_PX) + x);


}

And maybe if you want to extract color channels from a pixel..

Code:

typedef struct {


    unsigned r : 5;


    unsigned g : 6;


    unsigned b : 5;


} color_t;





color_t getpixel(int x, int y) {


    ...


    return (color_t)*(VRAM + (y * LCD_WIDTH_PX) + x);


}

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 12:52:33 pm
Last edited by Ashbad on 22 May 2011 05:25:31 pm; edited 1 time in total

well you can't blame me, I'm a C newbie, I wasn't really aware you could do that Razz

*turns to Kerm*

also in that case, new routine:

Invert Colors in Rectangular Area

inputs: shorts for x position, y position, length, and width
outputs: look at your screen! Cool

(if you actually render it)

Code:

void InvArea(short x, short y, short height, short width)


   unsigned short *VRAM = (unsigned short *)0xA8000000;


   for(short a = 1; a>width; a++) {


      for(short b = 1; b>height; b++) {


         *(b + y * LCD_WIDTH_PX + a + x + (VRAM++)) ^= 0xFFFF;


      }


   }


}

Qwerty.55
Expert (Posts: 617)

22 May 2011 01:39:55 pm

Tari wrote:

More importantly, I fail to see why you're both using char* when accessing 16-bit chunks in the native byte order. Provided there's no odd alignment requirement on VRAM (which seems unlikely, given that GetVRAMAddress returns a void*), this would be a little faster:

Code:

unsigned short getpixel(int x, int y) {


    unsigned short *VRAM = (unsigned short *)0xA8000000;


    return *(VRAM + (y * LCD_WIDTH_PX) + x);


}

And maybe if you want to extract color channels from a pixel..

Code:

typedef struct {


    unsigned r : 5;


    unsigned g : 6;


    unsigned b : 5;


} color_t;





color_t getpixel(int x, int y) {


    ...


    return (color_t)*(VRAM + (y * LCD_WIDTH_PX) + x);


}

What's with the Getpixel syscall? You could just read the word straight from memory.

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 01:53:30 pm

Qwerty.55 wrote:

What's with the Getpixel syscall? You could just read the word straight from memory.

That's exactly what we're doing Razz

Qwerty.55
Expert (Posts: 617)

22 May 2011 01:57:24 pm

Um, then you might want to change the name to avoid confusion with the real Getpixel syscall.

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 01:58:32 pm

that's why ours are called 'GetPXColor' and 'getpoint' Razz

and Tari's was just an example he made in ~30 seconds, to show us a point.

Qwerty.55
Expert (Posts: 617)

22 May 2011 02:03:42 pm

Okay. Shouldn't that be: Return (384*Y+2*X+0xA8000000)?

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 02:05:56 pm

GCC will optimize it for us. Plus, the way you did it doesn't specify it as a pointer, or size of return.

Qwerty.55
Expert (Posts: 617)

22 May 2011 02:36:30 pm

Well, the point is that (0xA8000000+(384*Y)+X) won't point to the proper word. You have to account for the 16 bit color size, which requires ROTL X (or X*2).

Tari
1
Systems Wrangler (Posts: 3366)

22 May 2011 03:45:31 pm

But it does when I make VRAM a unsigned short*, since that's how C pointer arithmetic works.

Qwerty.55
Expert (Posts: 617)

22 May 2011 04:12:21 pm

Ah, so C expands the arithmetic?

It seems unnecessarily complicated to force to programmer to remember types, but it's convenient for source size I suppose.

EDIT: Since Ashbad posted his RNG, here's an LCRNG in [partially] optimized Assembly.

Code:

SH3 Assembly:


   MOV R2,R3


   SUB R0,R3


   MOV $20,R4


   DIV0U R0,R1


Startdiv:


   ADD $FF,R4


   DIV1 R0,R1


   TST R4,R4


   BT/S Startdiv


   ROTCL R2


   DMULU.L R2,R3


   STS MACL,R3





   ROTR R0


   BF/S LoadX


   MOV $17,R3            // Load A


rngStart:   


   DMULU.L R1,R4


   MOV.L @(dd*4+PC), R0   // Load M


   STS MACH, R2


   


   MOV R2,R3


   SUB R0,R3


   MOV $20,R4


   DIV0U R0,R1


Startdiv2:


   ADD $FF,R4


   DIV1 R0,R1


   TST R4,R4


   BT/S Startdiv2


   ROTCL R2


   DMULU.L R2,R3


   STS MACL,R2


      


   RTS


   $05F5 E101


LoadX:


   MOV @(dd*4+PC),R1      // Load X_0


   BRA rngStart


   NOP


   $02D6 3A86

The answer is in R2, if you care to extract it.

Ashbad
1
Guru-in-Training (Posts: 2497)

22 May 2011 05:59:43 pm

first custom test routine here Smile

Print Custom Character

inputs: an x position, a y position, a bit mapped image of the character, color to draw the character, if it is to draw white in non-mapped spaces, and the dimensions of the character
EXAMPLE BIT MAPPED CHARACTER (the letter A):
[0,0,1,0,0]
[0,1,0,1,0]
[0,1,1,1,0]
[0,1,0,1,0]
[0,1,0,1,0]
outputs: look at your screen Smile

(unless you don't render it)

Code:

void PutCustC(*bool map, short x, short y, short width, short height, short color, bool DrawWhite) {


     short* VRAM = (short*)0xA8000000; 


     VRAM += (LCD_WIDTH_PX * y) + x;


     for(short a = 0; a>width; a++) {


               for(short b = 0; b>height; b++) {


                         if(*(y + b * width + x + a + map)) { *(VRAM++) = color; }


                         elseif(DrawWhite) { *(VRAM++) = color; }


                         else { VRAM++; }


               }


               VRAM += (LCD_WIDTH_PX-width);


     }


}