Rockbox Development > Starting Development and Compiling

display corruption. previous workaround doesn't work as expected anymore.

(1/2) > >>

salival:
(a shoot-off from http://forums.rockbox.org/index.php?topic=2481.0, since it's more of a programming issue than a hardware issue this time)

In the newer builds (since 2 nov 20.50) the display timing is handled different than before. With these changes simply adjusting the CSCR1 vars (the workaround until now) isn't enough to get around the corrupted/distorted display output.

I previously got clean display contents (i.e. very little to no distortion) when I set the values of CSCR1 to 0x00003980, 0x00000980 and 0x00000580 for CPUFREQ_MAX, CPUFREQ_NORMAL and default respectivly.

How do those settings translate to the new situation?

Llorean:
Since the DMA LCD update change, have you tried just using an official CVS build without ANY workarounds, or did you skip straight to still using them?

salival:
No, I tried without the changes. To no avail.
If the iRiver is doing nothing the screen is 'clean', so to speak. Whenever it tries to do something, i.e. spin the disk up or highlighting the next object in the filelist the screen becomes unreadable because of the distortion which manifests itself in random colored lines on screen. The displayed colors are all present in the screen that is supposed to be displayed.

Those setting I mentioned worked to prevent that. I know mine is a pretty severe case, but it worked.

To be clear, this is not Rockbox's fault, since the player (h320) has the same problem (be it less severe) with the later, video enabled, versions of the original firmware.

Llorean:
Ah, you may have to get on IRC and try to catch Amiconn, he wrote the new DMA method, so he may know what you need to tweak now for your special case.

Blackbooks:
Any update on this or a new workaround? Im in that minority who have the same problem. I miss being able to play solitaire and listen to music at the same time!

Navigation

[0] Message Index

[#] Next page