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);
}
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...
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
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.
Overclocking to around 98MHz is also ok from what I tested
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.
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
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
'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.
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.
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?
If the CPU actually did have an FPU, it would turn the FPU on and off. Since Calc84 ascertained that we already have it in the setting that would turn on the FPU if it was present, we can deduce that there is not in fact an FPU physically present within this CPU.
It actually doesn't turn it on and off, but rather generates exceptions when you try to use it. Since FPU instructions generate exceptions even though these particular exceptions are disabled, we can deduce that the FPU instructions are not present in the processor.
lots of information about syscalls, cpu, hardware, comm ports, lcd, bfile, etc... are available in fx_calculators_SuperH_based docs by SimonLothar (updated this week).

docs available here:
http://www.casio-scene.com/downloads.php?do=file&id=270
helder7 wrote:
lots of information about syscalls, cpu, hardware, comm ports, lcd, bfile, etc... are available in fx_calculators_SuperH_based docs by SimonLothar (updated this week).
Indeed, I've poked him to remember to update it here in the Cemetech archives as well. Smile
  
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
» Goto page Previous  1, 2, 3 ... 9, 10, 11, 12, 13  Next
» View previous topic :: View next topic  
Page 10 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