Hi all,
I was wondering if anyone has looked at the kernel code and can explain exactly what it's doing when it waits for VSync.
There is a kernel disassembly here:
http://www.cs.helsinki.fi/u/jikorhon/conde.../doc/fw157e.txt
...I think the relevant code is at 0x1bf0 - the official SDK hooks its GpSurfaceFlip() function into this code (or a RAM copy of it):
(please excuse the naff formatting)
So I just don't get why it would read the scanline number twice in quick succession, and yet not appear to be waiting for it to change? Am I missing some detail to do with this turning off of interrupts?
Mr Mirko's SDK is brilliant and clear, and a fantastic reference, but I was just trying to discover whether it was necessary for his VSync routine to be idling for as long as it does:
Is there some reason why this...
...isn't sufficient?
Cheers,
Rich (trying to squeeze every last bit out of the CPU!)
I was wondering if anyone has looked at the kernel code and can explain exactly what it's doing when it waits for VSync.
There is a kernel disassembly here:
http://www.cs.helsinki.fi/u/jikorhon/conde.../doc/fw157e.txt
...I think the relevant code is at 0x1bf0 - the official SDK hooks its GpSurfaceFlip() function into this code (or a RAM copy of it):
Code:
00001C64: E10F5000 mrs r5, CPSR
00001C68: E38540C0 orr r4, r5, #192; this will turn off interrupts if written to CPSR
00001C6C: E5963000 ldr r3, [r6] ; r6 is LCDCON1 register
00001C70: E1A03923 mov r3, r3, lsr #18 ; get current scanline
00001C74: E3530000 cmp r3, #0; is it 0?
00001C78: C12FF004 msrgt CPSR_fsxc, r4 ; if >0, turn off interrupts
00001C7C: E5963000 ldr r3, [r6] ; read from LCDCON1 again
00001C80: E1A03923 mov r3, r3, lsr #18 ; get current scanline (again??)
00001C84: E3530000 cmp r3, #0; is it 0?
00001C88: CA000001 bgt 00001c94 ; if >0, branch out of this polling loop
00001C8C: E12FF005 msr CPSR_fsxc, r5 ; otherwise reenable interrupts
00001C90: EAFFFFF5 b 00001c6c ; and reloop
00001C94: E2864014 add r4, r6, #20; Actually set the framebuffer address
00001C98: E8840006 stmia r4, {r1, r2} ; (interrupts are reenabled a bit later)
So I just don't get why it would read the scanline number twice in quick succession, and yet not appear to be waiting for it to change? Am I missing some detail to do with this turning off of interrupts?
Mr Mirko's SDK is brilliant and clear, and a fantastic reference, but I was just trying to discover whether it was necessary for his VSync routine to be idling for as long as it does:
Code:
static
void gp_waitVsync() {
// The LINECNT is downcount from 319 to 0
while ((rLCDCON1 >> 18) != 1);
// changeing Framebuffer
while ((rLCDCON1 >> 18) != 319);
// Framebuffer is changed
}
Is there some reason why this...
Code:
while ((rLCDCON1 >> 18) != 0);
while ((rLCDCON1 >> 18) == 0);
Cheers,
Rich (trying to squeeze every last bit out of the CPU!)