Casio Prizm Technical Documentation
» > >
» Goto page Previous  1, 2, 3 ... 8, 9, 10, 11, 12, 13  Next
» View previous topic :: View next topic  
very, very excellent work, calc84 (and Tari!) Shall I go put the documentation on the wiki?
R O F L M A O
O
F
L
M
A
O
Time for me to make SourceCoder allow images up to 396x224 now, I guess. Very Happy And we also now have way more than the TI-Nspire's 320x240 pixels to work with. Wink
Interesting funny routine: draw VRAM to the LCD upside down (exact same speed as Bdisp_PutDisp_DD):


Code:
void flip_upside_down(void) {
   WriteLCDReg(LCD_GRAM_X, 0);
   WriteLCDReg(LCD_GRAM_Y, 0);
   
   SelectLCDReg(LCD_GRAM);
   unsigned i = 384*216;
   while(i--)
      LCDC = *((color_t*)0xA8000000 + i);
}


Anyways, seems we actually didn't get a speed increase from this. Oh well, we got more pixels and LCD control. Smile
R O F L M A O
O
F
L
M
A
O
Have we tried doing it int-wise instead of short-wise (color_t-wise) and seeing if that makes any framerate difference?
KermMartian wrote:
Have we tried doing it int-wise instead of short-wise (color_t-wise) and seeing if that makes any framerate difference?


Literally just tried it, and got a funny result: it drew the VRAM upside down, scaled by 1/2x on both the left and right sides (two identical VRAM renders). The bottom was unchanged.


Code:
void flip(void) {
   WriteLCDReg(LCD_GRAM_X, 0);
   WriteLCDReg(LCD_GRAM_Y, 0);
   
   SelectLCDReg(LCD_GRAM);
   unsigned i = 384*216/2;
   while(i--)
      LCDC = *((unsigned int*)0xA8000000 + i);
}
R O F L M A O
O
F
L
M
A
O
Just thought I should throw this here:

https://github.com/torvalds/linux/blob/master/arch/sh/kernel/cpu/sh4a/clock-sh7724.c

I see that it uses the divisors struct as the multiplier also. Not sure if this is just a spare number, but:
Code:
static int divisors[] = { 2, 3, 4, 6, 8, 12, 16, 0, 24, 32, 36, 48, 0, 72 };
Note the 72 there as I am not sure what to make of it...
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
AHelper wrote:
Just thought I should throw this here:

https://github.com/torvalds/linux/blob/master/arch/sh/kernel/cpu/sh4a/clock-sh7724.c

I see that it uses the divisors struct as the multiplier also. Not sure if this is just a spare number, but:
Code:
static int divisors[] = { 2, 3, 4, 6, 8, 12, 16, 0, 24, 32, 36, 48, 0, 72 };
Note the 72 there as I am not sure what to make of it...


That's interesting, though I could swear I've already tried a multiplier of 72... hmm, let me try some more values, then, and see if we can go even faster than 87MHz. And, might I add, that C file you gave me is extraordinarily painful to read Razz

EDIT: I might also note that I found a currently considered "INVALID" multiplication rate for the PLL circuit earlier today, since I accidentally wrote bits [5:0] to [29:24] of the FRQCR. Seemed about the same as 18x (~65MHz), it could have possibly been 20x multiplier. I'll also check that out and get back with everyone.


EDIT2: Found another PLL circuit multiplier. Not faster than 87MHz, but rather 72.5 MHz. It's the 20x multiplier I stumbled upon earlier.

List of new PLL multiplier I discovered so far (I'll edit in any more I find later tonight):


Code:
#define PLL_20x 0b010011 // 72.5 MHz
#define PLL_26x 0b011001 // 94.3 MHz
#define PLL_28x 0b011011 // 101.5 MHz
R O F L M A O
O
F
L
M
A
O
Remind me again what's wrong with 101.5 MHz? As long as we set the speed back before the [MENU] can take over, I see no problem.
KermMartian wrote:
Remind me again what's wrong with 101.5 MHz? As long as we set the speed back before the [MENU] can take over, I see no problem.


I tested it many times last night; no matter where I used it (within RainbowDashAttack, Pover, or PONG), it only worked 10% of the time. The other 90% of the time, it crashed miserably (I noticed memory read errors; some pixels on the screen were drawn incorrectly, and the screen only got partially updated before stalling completely). So, until further notice, don't use 101.5MHz mode. I'm going to have to tweak with some of the other division ratios on the other clocks before it'll work, methinks. Will post findings later.

EDIT: that being said, feel free to clock to 94.3 MHz, I had zero problems with that.
R O F L M A O
O
F
L
M
A
O
Overclocking to around 98MHz is also ok from what I tested
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
AHelper wrote:
Overclocking to around 98MHz is also ok from what I tested


98MHz? I assumed you used a PLL multiplication of 0b011010 successfully? If so, O_o unexpected.
R O F L M A O
O
F
L
M
A
O
Ashbad wrote:
AHelper wrote:
Overclocking to around 98MHz is also ok from what I tested


98MHz? I assumed you used a PLL multiplication of 0b011010 successfully? If so, O_o unexpected.
AHelper was saying last night on IRC that he thinks you've incorrectly calculated some of the target MHz speeds that you're achieving. I'll leave it to him to explain what exactly he thinks you were / are doing incorrectly, though.
KermMartian wrote:
Ashbad wrote:
AHelper wrote:
Overclocking to around 98MHz is also ok from what I tested


98MHz? I assumed you used a PLL multiplication of 0b011010 successfully? If so, O_o unexpected.
AHelper was saying last night on IRC that he thinks you've incorrectly calculated some of the target MHz speeds that you're achieving. I'll leave it to him to explain what exactly he thinks you were / are doing incorrectly, though.


Ah, fair deal; I've being using the constant of 58 MHz to correspond to a PLL multiplication ratio of 16x, I assume that I'm off by a few hairs then, because I used such a vague number. I guess AHelper will either confirm or deny my assumption Smile
R O F L M A O
O
F
L
M
A
O
Nope, I use the FLL multiplier at x1024 instead of the default x900.

Please look at my previous post (a bit back) as the linux kernel documents the port usage
[nikky] the free market will decide who gets to be on the channel and who isn't
Array(16).join("wat" - 1) + " Batman!"
CC20: Air
'Kay for example: I want to use the Full Screen of the Prizm? How could I turn on the FS? How could I write on the FS? Shoud I change all my routines?
Eiyeron wrote:
'Kay for example: I want to use the Full Screen of the Prizm? How could I turn on the FS? How could I write on the FS? Shoud I change all my routines?


Here's two routines I (now) use, fullscreen sets the screen to FS, flip is like Bdisp_SetDisp_DD, etc.


Code:
void fullscreen(void) {
   WriteLCDReg(LCD_WINDOW_LEFT, 0);
   WriteLCDReg(LCD_WINDOW_RIGHT, 395);
   WriteLCDReg(LCD_WINDOW_TOP, 0);
   WriteLCDReg(LCD_WINDOW_BOTTOM, 223);
}

void flip(color_t*buffer) {
   WriteLCDReg(LCD_GRAM_X, 0);
   WriteLCDReg(LCD_GRAM_Y, 0);
   
   SelectLCDReg(LCD_GRAM);
   unsigned i = 384*216;
   for(int i = 0; i < 396*224; i++) {
      LCDC = *((color_t*)buffer + i);
        }
}


But for now, don't use them. I'm making a bunch of easier to use routines, that let you use a certain part of the add-in stack as new VRAM; this means old VRAM is now open for whatever you want to use it for. I'll try to post those routines today or tomorrow.
R O F L M A O
O
F
L
M
A
O
Thanks! That becomes more clear in my head! Wink
Well, it seems that ReadLCDReg() used with LCD_WINDOW_[LEFT|RIGHT|TOP|BOTTOM] does not return any value at all, as opposed to returning the LCD controller register values that correspond. Throwing extra SYNCO() statements doesn't help at all.
R O F L M A O
O
F
L
M
A
O
So I was reading the SH4A manual, and I noticed that the Status Register has an FPU Disable bit. I thought this might be the reason why FPU instructions don't work on the Prizm, but I checked the value of SR in an add-in and that bit is actually not set. So, it seems that the Prizm really doesn't have an FPU after all.
calc84maniac wrote:
So I was reading the SH4A manual, and I noticed that the Status Register has an FPU Disable bit. I thought this might be the reason why FPU instructions don't work on the Prizm, but I checked the value of SR in an add-in and that bit is actually not set. So, it seems that the Prizm really doesn't have an FPU after all.

Does this effect any system functions or anything we are aware of?
  
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
Casio Prizm Technical Documentation
» Goto page Previous  1, 2, 3 ... 8, 9, 10, 11, 12, 13  Next
» View previous topic :: View next topic  
Page 9 of 13
» All times are UTC - 5 Hours
 
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

 

Advertisement