Thanks for the information! So, basically it's a 7730 CPG unit? In that case, the prizm cannot be further overclocked; it's already running at a PLL circuit mult. of 0b1111, or 32x. That's the highest value that can be used.
No it is in fact an SH7724 CPG which means the PLL cab be clocked higher then x32. It can go up to x48. tough on my device i found that makes the graphics go all screwy and the highest i could get it to go reliably was x36. Also if its not already set you might try adjusting the ICLK divisor to x1/2 and get a bit more speed that way as well
Valid PLL multipliers:
to the OP of the new FRQCR info, why did you write those routines in assembly? I think that writing them in C will lead to more optimized code, since you do some strange things like "mov #0x80, r0 \ shll16 r0 \ shll8 r0", where I think that simply loading a longword 0x80000000 into r0 with an offset data longword would be faster (and smaller). And, why not optimize that final "mov r2, @r1" to be after the RTS, and take out the NOP?
Yes I could optimize things things a bit more then I did when I was originally typing that out such as doing things like as you said doing the mov post rts. However if I let GCC compile this it usually produces a longer function since at the very least GCC will add a function prolog and epilog and usually move the parameters passed to the function onto the stack.
Ooh, very good stuff! This information is crucially important to me and the rest here -- I had checked every model but the 7724, actually, because for one there was no 7724 documentation from all the Renesas info I scoured for, so I assumed it either wasn't a real model or something along those lines I will look into the screwy graphics you speak about, first at 36x and then 48x. I also have a feeling that Bdisp_PutDisp_DD is the next thing I should look into, since after realizing functions like Bdisp_AllCr_VRAM can be written to be more than twice as fast by hand, that the screen update time bottleneck can be much removed, and may fix this graphical glitching you speak of.
Would you mind if I put this information you shared on Cemetech's Prizm Wiki? Of course, with all credit given for your wonderful findings
As for the function epilogue and prologue with GCC, under speed optimizations those are sometimes demolished, but your point is very good indeed and I had forgotten about that TBH.