Exophase
Nothing good will ever come of Exophase.
I started this topic so we can possibly try to figure out exactly why the screen tearing issue occurs in "landscape mode" and if anything can be done to fix or diminish it.
I don't know yet if I should post the datasheets for the OLED controller and OLED panel itself used in the Wiz (I don't think the latter is relevant). For now I'll just talk about a few things that I've found in it that I think might be causing it.
The OLED controller has a 240x320 framebuffer. You have to write to this every frame. It seems the way it performs rotation is in the addressing of how this framebuffer is filled. You can set the writes to this framebuffer to increment line by line then pixel by pixel instead of pixel by pixel then line by line. Actually, there are 8 ways you can do this, depending on whether or not you want to go left to right or top to bottom in either portrait or landscape mode. It seems like there may also be another way to do rotation, the documents are not clear.
The controller only has one framebuffer. What this means is that you have to race the display so that you only write over areas that have already been read from for that frame. Normally, if the interface to the OLED controller is faster than the OLED's dot clock (it usually is) then you start writing at the beginning of vsync, giving you some lines before the display starts, and by the time the framebuffer is being read from it'll be well behind the areas you modified, and it'll never catch up.
This is fine if you're writing in the same order the screen is reading from. But if you're writing in a different order then you may be writing to areas that have already been displayed for that frame. I think that this is the cause of the tearing problem.
Operating in portrait should fix this, as reported. And yet, EvilDragon claims that there are still tearing issues in some circumstances. In fact, from what he described, it sounds like the "tearing line" may have been rotated. This suggests that the setup may still not be correct, or that the timing is off (not starting at vblank).
There'd be no issues if the vblank period (only back porch, although front porch + back porch would be nicer) was long enough to copy the entire screen. Unfortunately, this doesn't appear to be the case, as vblank can only be 16-20 lines, suggesting that the display is 360 lines tall internally. The Pollux documents suggest that a 40MHz dot clock is used, and 240 * 320 pixel need to be transferred. Maybe if it were capable of maxing out the DDR interface, ie 266MHz, then it could be just about fast enough. I doubt it could go this high though. I don't know if it can go higher than 40, and I don't know yet what the limitations on the controller are.
I don't know yet if I should post the datasheets for the OLED controller and OLED panel itself used in the Wiz (I don't think the latter is relevant). For now I'll just talk about a few things that I've found in it that I think might be causing it.
The OLED controller has a 240x320 framebuffer. You have to write to this every frame. It seems the way it performs rotation is in the addressing of how this framebuffer is filled. You can set the writes to this framebuffer to increment line by line then pixel by pixel instead of pixel by pixel then line by line. Actually, there are 8 ways you can do this, depending on whether or not you want to go left to right or top to bottom in either portrait or landscape mode. It seems like there may also be another way to do rotation, the documents are not clear.
The controller only has one framebuffer. What this means is that you have to race the display so that you only write over areas that have already been read from for that frame. Normally, if the interface to the OLED controller is faster than the OLED's dot clock (it usually is) then you start writing at the beginning of vsync, giving you some lines before the display starts, and by the time the framebuffer is being read from it'll be well behind the areas you modified, and it'll never catch up.
This is fine if you're writing in the same order the screen is reading from. But if you're writing in a different order then you may be writing to areas that have already been displayed for that frame. I think that this is the cause of the tearing problem.
Operating in portrait should fix this, as reported. And yet, EvilDragon claims that there are still tearing issues in some circumstances. In fact, from what he described, it sounds like the "tearing line" may have been rotated. This suggests that the setup may still not be correct, or that the timing is off (not starting at vblank).
There'd be no issues if the vblank period (only back porch, although front porch + back porch would be nicer) was long enough to copy the entire screen. Unfortunately, this doesn't appear to be the case, as vblank can only be 16-20 lines, suggesting that the display is 360 lines tall internally. The Pollux documents suggest that a 40MHz dot clock is used, and 240 * 320 pixel need to be transferred. Maybe if it were capable of maxing out the DDR interface, ie 266MHz, then it could be just about fast enough. I doubt it could go this high though. I don't know if it can go higher than 40, and I don't know yet what the limitations on the controller are.
