Rockbox Technical Forums

Rockbox Development => Starting Development and Compiling => Topic started by: salival on November 06, 2006, 04:58:14 PM

Title: display corruption. previous workaround doesn't work as expected anymore.
Post by: salival on November 06, 2006, 04:58:14 PM

(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?

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: Llorean on November 06, 2006, 05:01:05 PM

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?

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: salival on November 07, 2006, 02:46:23 PM

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.

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: Llorean on November 07, 2006, 02:47:38 PM

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.

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: Blackbooks on November 09, 2006, 04:46:24 PM

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!

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: salival on November 10, 2006, 05:38:22 PM

I had a chat on IRC with Amiconn and this almost solved my problem. To prevent a large amount of text in this thread I suggest you take a look in the IRC log of 11-10 (month-day) starting at 21.58

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: Blackbooks on November 11, 2006, 07:54:26 AM

Hmmm... so  0, 5, and 15 are the waitstates your using now I take it? I'll give em a go I guess. Thanks

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: salival on November 12, 2006, 01:02:37 PM

I think you can use (much) lower values as mine is a pretty severe case

Title: Re: display corruption. previous workaround doesn't work as expected anymore.
Post by: salival on December 01, 2006, 03:03:31 PM

on another note: I have opened my player. The board says it's a H300 M3 with the date july 10 2004. The M4 is from sept. 04, so it could be that they changed the display controller.

For those interested: I have made some half decent photo's. You can pm me if I should post these here or on the H3xx components page.