GP2X A Simple Test App Needed


MadDog

Member
Joined
Mar 4, 2006
Messages
262
Age
54
Location
UK
Website
www.maddoggames.com
Sorry to revisit this but i've still got this odd bug. So I wondered if anyone has an app thats using the 940 to do the vsync?

In a nut shell, in my code if the 940 waits for a vsync and the usb cable is connected the usb stops working, requires a reboot.

If I disconnect the usb, run my app then exit it, then reconnect the usb it works ok.
If I run the app with the usb, exit the app I will have lost the usb, removing and reinserting the usb will not correct the problem.

If I take out the vsync code on the 940 all works fine.

So, a test app from someone else will at least let me exclude an OS bug.

[on nees begging]
Please guys this would be a great help. :)
 
Did you read my last post on the previous topic ?

Have you tried inserting a delay between your read at vsync register ?
For me it works (I inserted a while loop counting down from 100 to 0).
 
Ok, its hard coded for FW 2.0 at the mo, its better but I still loose it after about 2500 frames.

asm volatile(
"mov r0,%0 \n"
"ldr r1,=0x1182 \n"
"check_again: \n"
"ldrh r2,[r0,r1] \n"
""
"mov r3,#0xff \n"
"wait: \n"
"subs r3,r3,#1 \n"
"bne wait \n"
"ands r2,r2,#16 \n"
"beq check_again \n"//Result is zero, bit not set, wait sometime.
:
:"r"(reg.regs16)
:"r0","r1","r1","r2","r3");

Bumping the stall loop from 256 to 4080 ( 0xff0 ) it lasts much longer but i'm getting flip errors as its missing the start of the vblank, a posible 8160 loops before it drops out because the vblank is in progress.
I really don't want to be doing the wait on the main CPU as I want that to start the next frame whilst the 940 is rendering the current one.

Does anyone know if its posible to setup an interupt on the vblank for the 940? I've looked but get lost in the docs, I find them a bit hard reading.
 
MadDog posted on May 23 2006 at 03:10 PM said:
Ok at its hard coded for FW 2.0 at the mo at its better but I still loose it after about 2500 frames.

asm volatile(
"mov r0 at %0 \n"
"ldr r1,=0x1182 \n"
"check_again: \n"
"ldrh r2,[r0,r1] \n"
""
"mov r3,#0xff \n"
"wait: \n"
"subs r3,r3,#1 \n"
"bne wait \n"
"ands r2,r2,#16 \n"
"beq check_again \n"//Result is zero, bit not set, wait sometime.
:
:"r"(reg.regs16)
:"r0","r1","r1","r2","r3");

Bumping the stall loop from 256 to 4080 ( 0xff0 ) it lasts much longer but i'm getting flip errors as its missing the start of the vblank, a posible 8160 loops before it drops out because the vblank is in progress.
I really don't want to be doing the wait on the main CPU as I want that to start the next frame whilst the 940 is rendering the current one.

Does anyone know if its posible to setup an interupt on the vblank for the 940? I've looked but get lost in the docs, I find them a bit hard reading.

Hmm, a stall loop of 4080 iterations should complete in WAY less than a millisecond and I think the standard vsync pulse size is three milliseconds.

I think it should be possible to get an interrupt for this working, but you're way out on the bleeding edge for that (by which I mean, I have no idea how to go about doing it)
 
Last edited by a moderator:
Yes, but as i'm testing (and being a bit cheeky) the read of the register i'm not waiting whilst there is a vsync to start with, so it could enter the loop with the vsync almost finished. Mind you that could happen how ever long the loop takes, but the longer it takes the more likely its going to show.

What I had planed to do was put the 940 to sleep whilst waiting for the vsync in the hope that would prolong the batteries. On some Pocket PC stuff I did a few years ago sleeping a little every frame was a big gain for the battery.
 
Be careful with toggling the clock enable bit for the 940. When I was messing with it (in the hope of saving battery life), the 940 seemed to lock up quite regularly :( It seems to only work well if you reset it after enabling the clock, or have it in reset whilst enabling the clock.

Or maybe it was the fact the 940 itself could turn its own clock off that it didn't like... (When it had finished all it's jobs, it turned off its own clock)
 
Squidge posted on May 23 2006 at 10:59 PM said:
Be careful with toggling the clock enable bit for the 940. When I was messing with it (in the hope of saving battery life), the 940 seemed to lock up quite regularly :( It seems to only work well if you reset it after enabling the clock, or have it in reset whilst enabling the clock.

Or maybe it was the fact the 940 itself could turn its own clock off that it didn't like... (When it had finished all it's jobs, it turned off its own clock)
Turning it's clock off when it's in the middle of doing something could easily be the cause of problems, unless it's built with a fully static internal state memory and designed to be stopped and started at will - which CPUs rarely are.
 
Last edited by a moderator:
I thought there was a sleep mode for the 940 instead of just turning it off. I would have thought if its turned off it can't recive interrupts.

For starters when I need to wait for the vblank i'm going set a flag to 1, enable the interrupt, spin on the on the flag (non cached). The interupt handler will clear the flag. Well thats the idea, going well so far almost got the handler coded up. Here is a link on the arm web site.

http://www.arm.com/support/faqdev/1456.html

I'll post my code to the demo thread so Dzz can add it if he wants, this vblank wait problem will keep biting peaple till we have a reliable solution.
 
MadDog posted on May 23 2006 at 11:10 PM said:
Does anyone know if its posible to setup an interupt on the vblank for the 940? I've looked but get lost in the docs, I find them a bit hard reading.

Im planning to use the vsync IRQ myself (see the thread in the other forum).
I had it working this morning.

Basically, like it was said, the 940 interrupt controler is at 0xC0004500 (instead of 0xC0000800).
You have to set it up : unmask DISPINT, make it an IRQ or FIQ as you want. kernel also write -1 on both
PENDINT, SRCINT and PRIORITY registers, but Im not sure if it's usefull yet.

Then, configure the display controler to enable vsync IRQ (don't remember the register).

While in the IRQ handler, logical or bit 0 of both PENDINT and SRCINT (in the specified order, again I don't remember) _and_ into the display controler register.

Then, it should rocks.

There is a perhaps a problem since linux on the 920 also uses this IRQ, so Im not sure the 940 will get its irq if the 920 irq handler clear the vsync int bit in the display controler before yours. Preventively, I masked this IRQ in the 920 interrupt controler. Im unsure if this is necessary, but it seams harmless.

This evening I will fix my code and commit to my little 'gpu940' projects on gna.org, so that you will (hopefully) have a working example.
 
Last edited by a moderator:
Back
Top