Rockbox Development > New Ports

SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

<< < (153/386) > >>

Hillshum:

--- Quote from: mc2739 on April 07, 2009, 10:37:51 PM ---@funman

Here is an interesting observation for you.

The e200 screen is 176 wide and 220 tall compared to the Fuze which is 220 wide and 176 tall.

I reconfigured so that my e200 screen is rotated 90 degrees to match the Fuze and I get  the same screen corruption as seen on the Fuze.

I have not had any screen corruption in the standard configuration

--- End quote ---

Could this mean if we wrote to the controller sideways on the Fuze it would work?

wpyh:
Well, if I replace the backdrop with some other bitmap measuring 220x176, the corruptions don't happen. Therefore the corruption is very data-specific.

Could the corruptions be some kind of side-effect from CPU calculations? Such as registers being mapped to RAM, and we use that part of RAM to decode the bitmap?

saratoga:
Sounds like the buffer being used for the bitmap is being overwritten, either by a bad pointer or because we've double mapped a piece of memory.

calv:
Well this problem appears even without MMU enabled, so logical=hardware addresses. But on the hardware side the memory (and even I/O) could be mapped to multiple places and overlap in some places. Maybe we are using addresses, where memory and I/O overlap. It could even be, that we are using the correct I/O addresses, which are nonsense (hardware-wise): working because of hardware mapping, but at the same time overwriting RAM. The OF could even use the same addresses, but then mapped by the MMU to different hardware addresses, where RAM is not selected, and thus not overwritten.

Maybe finding out at what exact addresses in RAM the backdrop gets corrupted and comparing those addresses to our I/O addresses could bring some clue about this.

Only one of my usual wild guesses, though  ::)

kugel.:
The backdrop is corrupted without memory mapping too (in fact, not only the backdrop, but every bmp above ~190px wideness). And we're using the correct RAM addresses.

The loading is problematic, because the issue was revealed by a commit which changed the bmp loader to load a whole pixel row at once, instead of only 8px of a row at a time.

Navigation

[0] Message Index

[#] Next page

[*] Previous page