Rockbox

Here's my patch with the same idea, a lot simpler and probably slightly slower. I get about 30% speedup from this on my clip (haven't tested it on fuze, because I don't have one).

   ams_dbop_fifo.patch (1.2 KiB)

Here is kugels patch with e200v2: also 90 fps unboosted, but not more than 100.0 fps boosted. I have also blue bars when boosted like kugel wrote, but I have  FS#10048  applied, too.

   lcd-speedup_with_e200v2.diff (4.9 KiB)

Interesting. So I'd say with 100fps we really hit the limit of the hardware. A bit sad, 100fps isn't that much.

2832 (585 grey) 3543.5 (1600 grey) with my patch on my clip.

No blue bars :) No apparent display corruption.

I tried it on my e250v2 without  FS#10048  and could not see any blue bars, so it seems related to the mmu stuff.

What are the exact numbers?

I am getting the blue bars also on my e280v2; I applied this patch first, then the latest ams-caching.diff patch (posted: by Rafaël Carré (funman) - Wednesday, 03 June 2009, 13:15 GMT+2) the blue bars only show up when changing songs or doing 'system intensive' things

I noticed that if I apply this patch first (to a clean checkout) then the ams-caching, there is no error (but blue bars) but when applying the caching patch and then this patch, there was some error about one of the files already being patched (yes I know it would be helpful to know what files but the log has already past that part, sorry)… using r21184

- "when applying the caching patch and then this patch, there was some error about one of the files already being patched"

Right, there was one change in system_as3525.c (#include mmu.h) which is in both patches, here is a patch without it as it is related to  FS#10048  .

   lcd-speedup_with_e200v2_b.diff (4.7 KiB)

- "What are the exact numbers?"

Sorry, I missed the comment. Without mmu I get 61.5 fps unboosted and 94.0 fps boosted.

I committed the simple DBOP FIFO fix for clip. Even though the frame-per-second for clip is not really a problem, this gives a nice speedup with low complexity.

The interrupts bits don't need to be cleared in the isr (according to the datasheet)

Also I think it would be nice to have each bits defined with their names

Bertrik, I just tried your patch again after the MMU patch commit.

Unboosted, my patch is by far faster. 64.5fps vs 90fps
Boosted, both patches reach 100fps, and both show blue bars.

Can some e200v2 owner test this?

   lcd-speedup.diff (2.4 KiB)

and this one too please.

   e200v2-only-speedup-.diff (4.3 KiB)

Just test this, it's a sync of the lcd-speedup.diff. e200v2-only-speedup-.diff has been committed.

   lcd-speedup.diff (1.7 KiB)

On my e200v2, I am seeing very intermittent blue pixels with latest svn (r22588).

Also, the splashes are sometimes skewed. This is most notable when using a larger font than the one with the default cabbiev2 theme (I use the widecabbie theme). It is very reproducible with the opening splash for the doom plugin.

Can you try if reverting to r22577 fixes anything?

I have not seen any blue pixels with r21577, but I still see the skewed splashes as described above. The splashes are correct if I revert back to r22574.

The blue pixels (btw, I explicitely asked you about those in IRC :p ) probably go away if you increase the button_delay (a #define in button-e200v2-fuze.c) a bit.

I have also noticed distortion in mpegplayer progress bar. To reproduce, start a video, pause the video, resume the video. As with the splash distortion, the started with r22575 and was fine with r22574.

After further testing, I have determined that the skew/distortion is happening in lcd_update_rect(). This was verified by bypassing the lcd_update_rect() code with a call to lcd_update().

I've fixed it on the fuze (r22627), please have a look into porting the fixes to the e200v2 and post a patch.

Here is a patch to fix the e200v2.

   lcd-e200v2-fix.diff (1.2 KiB)