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!)
 
	
