Vertical blanking interrupt

[pawpoise]

Hi,
Many years ago when I used to program on a CBM 64 I used a technique that involved the vertical blanking interrupt (at least that's what I remember it was called). The idea being that when the visible part of the screen had been drawn an interrupt was triggered. This was an ideal time to trigger updates to the display buffer without any tearing of the moving graphics. It was also an ideal way of timing a game.

My question is: is there anything like this on a pocketpc? Is there any information about how the LCD displays are updated? Using a fast copy from a working buffer to display buffer (like easyCE) should reduce tearing but it's still likely and seems a shame when there is more than enough power in the machine to create very smooth graphics.

If there are other solutions, I'd love to hear about them. This is one of the many big holes in my knowledge of pocketpcs (and PCs in general) and I'd really like to understand more about it.

Thanks for your help,

Pawpoise

[Kzinti]

As far as I know, nobody has yet found a way to get this info.

Did anyone experimented something to find it? I remember discussions about updating the screen with certain patterns until the refresh rate was matched. But then... How do you know when the refresh starts?

I have the impression that this will be highly display-dependant and that there is no API to expose the functionality needed.

[Orpe]

Since there's no API for detecting when the refresh starts it's probably hard to use what I just tried, but it works for iPAQs (at least for the 3660 that I've tested on so far).

On this model (and probably most of the others) the LCD controller which comes "built in" with the processor is used. It uses DMA to transfer data from the internal DRAM buffer to a small internal buffer (something like 5 DWORDS in size). This data is then used to drive the display. So, basically it does many short DMA transfers and the start address of these transfers can be read from a memory mapped register. (This requires some tinkering).

But, by reading this register you will know the approximate line it's currently refreshing and when this counter wraps around, you know that the refresh restarts at the top of the screen.

The time it takes for a wraparound to occur (approx 16687 microseconds) on my device indicates that the refresh rate is probably 60Hz (if you do the computation based on that single number you get 59.92Hz).

However, I'm not sure that having the vsync helps anything when it comes to vertical tearing (as you get from rotating blits). On a CRT there is actually a pause after the last line has been refreshed during which the ray is moved back up to the top again. This probably isn't the case on LCDs, they may just start at the top again straight away... but I don't really know how they work.

OTOH, when you're playing around with hardware registers like this, you may as well do things properly. It's actually possible to change the location from where the LCD controller reads data which means that the blit can be removed altogether. I haven't tried this yet but I probably will tomorrow. It doesn't seem very difficult. In this case you can do a rotating blit to a backbuffer and then switch/flip to this backbuffer by changing where the LCD reads data from.

/Orpe

[James S]

I was pretty sure the PPC refresh rate was 24 Hz

[Kzinti]

If you can find out how to change the start address of the display, then there is indeed no need for vsync information.

Concerning rotation blits... Well I don't use any so this is not a concern for me...

[Orpe]

I was just browsing through some old discussions and saw that I never reported back to this one about what happened with my attempts to avoid blits altogether by programming the LCD controller directly.

Well.. It turned out to be very hard because of a limitation in WCE 3.0. Programming the LCD controller is actually very easy but since it uses DMA you need to allocate some contigous physical memory to use for the video data. You cannot do this on WCE3.0 however, so that's where the experiments ended.

If anyone knows how to allocate a suitable buffer for this purpose I would be very happy to know about it. From what I've read, the only way to reserve contigous physical memory is to write some statements in a special config file when you actually build the WCE platform for your particular device.

/Roland

[refractor]

[Rhino123]

[Orpe]

[refractor]

[Rhino123]

Okay,

I thought that the ARM processor didn't have a memorymanagement unit. I based that conclusion on the fact that CE doesn't support "memory mapped files". Or maybe that is because one of the other processors (sh3/mips) doesn't support it and it has to allow only the common denominator?

R

[Orpe]

[refractor]

[Rhino123]

[Orpe]