GP2X Frame Buffers?

[A_SN]

Since I'm making my own blitter I guess it's silly to bother with SDL to blit to the screen, instead I should write directly to the frame buffers.

Only there are two frame buffers, and I don't know how to deal with it, and the information on the wiki is kind of lacking..

What's even the use of having two frame buffers, and what do I need to know?

 

[xafier]

Follow the info here:
http://wiki.gp2x.org/wiki/Writing_to_the_framebuffer_device

More information can be figured out from Rlyeh's minilib:

http://www.emulnation.info/retrodev/forum/...topic.php?t=142

if you look at the method "gp2x_video_RGB_flip" what's basically happening here is that he's switching between the two framebuffers, whilst one is stored on the screen another is being written to by you... I believe the last two lines are setting the addresses to blit the bitmap to the screen, although I'm not sure of the significance of mask on the address and the shift on the second line...

To wait for vsync you need to do this: (this is the updated version that works with firmware 2.0):

static volatile unsigned long *gp2x_memregl=(unsigned long *)mmap(0, 0x10000, PROT_READ|PROT_WRITE, MAP_SHARED, gp2x_dev[2], 0xc0000000);

static volatile unsigned short *gp2x_memregs=(unsigned short *)gp2x_memregl;


void gp2x_video_waitvsync(void)
{
while(gp2x_memregs[0x1182>>1]&(1<<4));
while(!(gp2x_memregs[0x1182>>1]&(1<<4)));
}

I don't fully understand it all myself, I'm just trying to figure it all out because I need to steal it for my own simplified code... Rlyeh is the best person to ask, but the wiki needs updating when it can be explained better for definite.

 

[Daid]

Also if you want to use the hardware blitter, this topic:
http://www.gp32x.de/board/index.php?showtopic=23182&hl=
contains the discussion where they got it to work.

But also read up on the MMSP2 manual about the registers.

The use of having 2 framebuffers is that you can pageflip, you can write framebuffer1 while framebuffer2 is displayed, then when you're done writing buffer1 you make buffer1 displayed on a VSync and then draw on buffer2.

(I couldn't find how to change the display 'pointer' so I always draw on buffer2 and copy it to buffer1 on VSync when I'm done)

I'm planning to write alot about this on the wiki later, as the information is hard to find and splinterd.

 

[Squidge]

(I couldn't find how to change the display 'pointer' so I always draw on buffer2 and copy it to buffer1 on VSync when I'm done)

Have a look at regs 290E - 2914.

 

[Daid]

(I couldn't find how to change the display 'pointer' so I always draw on buffer2 and copy it to buffer1 on VSync when I'm done)

Have a look at regs 290E - 2914.

Thanks
(This video post processor is one complex thing, looks like it can do loads of things)

 

[Lint]

couldn't it be possible to write a simple procedure to page flip framebuffers on vsync for the second processor?

the code could be so small that would fit in the 4kb program cache, and after it's done the processor could put itself back into sleep (perhaps the processor could even run on a very low mhz rating)

so this would give a nice and easy way to avoid a wait_vsync loop in a page-flipped game and altough not getting everything from the second processor, it's still an easy way to gain some performance on -- for example -- mame

 

[dwelch]

couldn't it be possible to write a simple procedure to page flip framebuffers on vsync for the second processor?

the code could be so small that would fit in the 4kb program cache, and after it's done the processor could put itself back into sleep (perhaps the processor could even run on a very low mhz rating)

so this would give a nice and easy way to avoid a wait_vsync loop in a page-flipped game and altough not getting everything from the second processor, it's still an easy way to gain some performance on -- for example -- mame

Been there, done that, maybe I posted the code, maybe not. The code to flip pages is maybe a handful of instructions? If you set your page addresses right you save two register writes. Use the vsync interrupt, have your foreground app set a flag and the ISR uses the flag to determine to flip pages or not. This only saves you if the vsync interrupt rate is faster than your application can draw pages. If your application is faster than the vsync interrupt rate, then just poll for vsync and essentially synchronize with the video interrupt, otherwise you will just end up throwing away frames. The 940 has nothing to do with any of this, 920, 940, same same. The only place I see the 940 helping is that it is easier to set up the vsync interrupt on the 940 as there is no OS to mess up. but once you go 940 then you dont need interrupts you have nothing better to do than poll and you can easily live in the cache.

I have not used SDL in a long while, multiple video pages and page flipping are so simple on this platform I dont know why you would put a library in the middle...sigh...

 

[Squidge]

Polling the vblank on the 940 instead of using the interrupt will use the A/D bus heavily, and thus slow down the 920 just like having a program in there bigger than the cache.

 

[BradN]

Polling the vblank on the 940 instead of using the interrupt will use the A/D bus heavily, and thus slow down the 920 just like having a program in there bigger than the cache.

Not to mention burn extra power and scare small children. I think interrupt on the 940 is really the best solution, as it still leaves the 940 open for other tasks like ogg decoding or what have you, and you should be able to halt execution when there's nothing to do.

 

[Lint]

using an ISR routine would have to get kernel-sided. that's the bad thing.
unless someone developed a driver to handle vsync, but that should be not application specific (IMO)

also, one can easily save the bus by doing a simple dummy loop for like, 400hz (vsync won't toggle twice that fast) between each polling, and yeah, you'll have to take the bus for 1/400th of the time, gp2x is capable of doing that

also, processor can be set into lower frequency, but is a fact that it will waste some energy, that's the price to pay.

 

[Squidge]

using an ISR routine would have to get kernel-sided. that's the bad thing.
unless someone developed a driver to handle vsync, but that should be not application specific (IMO)

What? Only the 920 runs Linux, not the 940. So you can easily run interrupts on the 940 without worrying about Linux, as Linux doesn't even know the 940 exists.

 

[Lint]

that's my point squidge!

one side claim to use just one cpu by using that interrupt and save a lot of battery, but by this way you _must_ develop kernel-sided

the other side (mine) say to try using the second cpu, that can be ISR drived or by polling, don't matter at all...

even why I didn't knew that there was a working (not timer-based) vsync int

what I see so far is that most (if not all) programs use a simple dummy loop waiting for vsync, and that's what would be great to avoid ^_^

 

[Squidge]

You can do a interrupt baseed vblank on the 920 using a similar technique to my mmu hack - either hack the kernel (everything in one exe), or create a module (kernel sided, as you say)

 

[Lint]

yeap, your hack became a module, which in my opinion is much more clean than that hack that really deserves the name 'hack'

on the first release of squidge-hacked Drmd it was halting my gp2x all the time, and it halted the whole system not just the application, I was really suspecting about that hack (I think it's almost the only piece of kernel-sided code that Drmd runs) so a module for vsync int would be best.
Now all I need is a toolkit that's capable of building a single module in linux... what did you used to build that squidge-hack module?

 

[Squidge]

I think you need GCC 2.95 for kernel modules, as thats what the kernel was compiled with?

 

[Lint]

oh
this explains a lot of things
I'll try that (altough I'm quite sure I'm not the man for developing a page-flipping ISR module, but anyway..)