Leading the way to the Future
Welcome Guest, Login!
03 Apr 2012 01:51:24 pm by Ashbad Quote
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);
}
03 Apr 2012 06:57:21 pm by AHelper Quote
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...
03 Apr 2012 07:58:58 pm by Ashbad Quote
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
03 Apr 2012 09:13:55 pm by KermMartian Quote
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.
04 Apr 2012 06:42:53 am by Ashbad Quote
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.
04 Apr 2012 10:08:52 am by AHelper Quote
Overclocking to around 98MHz is also ok from what I tested
04 Apr 2012 10:26:18 am by Ashbad Quote
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.
04 Apr 2012 10:27:46 am by KermMartian Quote
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.
04 Apr 2012 10:30:18 am by Ashbad Quote
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
04 Apr 2012 10:37:06 am by AHelper Quote
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
04 Apr 2012 12:35:45 pm by Eiyeron Quote
'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?
04 Apr 2012 12:41:55 pm by Ashbad Quote
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.
04 Apr 2012 12:43:00 pm by Eiyeron Quote
Thanks! That becomes more clear in my head! Wink
21 Apr 2012 02:11:24 pm by Ashbad Quote
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.
29 Apr 2012 03:33:25 pm by calc84maniac Quote
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.
29 Apr 2012 07:58:23 pm by zeldaking Quote
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?
29 Apr 2012 08:20:39 pm by KermMartian Quote
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.
29 Apr 2012 08:25:14 pm by calc84maniac Quote
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.
04 May 2012 04:11:30 pm by helder7 Quote
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
04 May 2012 04:14:23 pm by KermMartian Quote
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