Problem Processing RGB888 Data

To open, I would like to say that the output format of the VPBE is independent of the format you are using internally in your memory buffers, that is, the VPBE will do all the appropriate conversions for you as long as you give it a buffer that has a format matching what you have a particular vid or osd window configured for. Basically you do not need RGB888 data in memory to output to a RGB888 display, you can use any of the formats supported by the OSD such as YCbCr 4:2:2, RGB565, or even RGB888.

beerock said:

The display that I am using is 400x240 pixels. My static buffer is 320 bytes x 240 bytes (padded to 32-byte boundary) - 300 bytes = 400 pixels in RGB888 format. Unfortunately, I cannot get all 400 bytes of each line to be transmitted. It appears to be only 2/3 of the line is getting sent (~266 pixels as opposed to all 400).

I am not sure about your format here, RGB888 implies that each pixel needs three bytes (format given in section 4.3.3.2 of SPRU952a) so the buffer should be 400x240x3 bytes in size to fill the whole display. However leaving this aside, if you are only seeing 2/3 of a line than you may be looking at a display configuration issue, you might check your register settings relating to the display frame size, in particular figure 25 of SPRU952a may be of some help.

beerock said:

Another oddity is that the pixel values are not consistent for each burst. In other words, I am using the black vertical line buffer for this test. I would expect the black pixels to land in the exact same spot for each line burst. However, the location of the black pixels changes from line burst to line burst. What gives? Our theory is that the OSD module requires a conversion from RGB888 to YUV422 before converting back to RGB888 for transmission, and resolution is lost in this conversion (from table 27 in the VPBE manual). Did I miss (or incorrectly set) a register?

The OSD does convert to YCbCr 4:2:2 internally for the blending step, so there will be some loss of color depth during this process, however I am not sure how this would effect the location of pixels, perhaps I am misunderstanding the phenomenon you are trying to describe (a screenshot may help). If the vertical black line is not aligned on every line properly than you may have a pixel pitch issue, where your buffer does not align with what the OSD is expecting, which could be related to misunderstanding of the RGB888 format, in which case you may want to try using a different OSD format like YCbCr 4:2:2 that has an even bytes per pixel setting, at least for testing.

Bernie Thompson said:

I am not sure about your format here, RGB888 implies that each pixel needs three bytes (format given in section 4.3.3.2 of SPRU952a) so the buffer should be 400x240x3 bytes in size to fill the whole display. However leaving this aside, if you are only seeing 2/3 of a line than you may be looking at a display configuration issue, you might check your register settings relating to the display frame size, in particular figure 25 of SPRU952a may be of some help.

The RGB888 buffer is actually 320 x 240 words (~427 pixels). I apologize for the confusion. The format that I used to create my static buffer is per section 4.3.3.2 of the VPBE manual. I am looking at the HSYNC, VSYNC, DCLK, and a data line on a scope. I want to make sure that what is getting sent to the flat panel processor is correct before trouble shooting those issues.

Since posting this, I think I have figured out why I am not getting all 400 pixels. That was related to the fact that I did not configure the OSD clock correctly (actually, I had not tended to it at all) - regs: OSDCLK0, OSDCLK1. This is now corrected. However, data is still not coming out correctly. I would expect the black pixel swath to occur in the exact spot for each line burst. However, that is not happening. In addition, the width of the black pixel swath should only be 4 pixels. It is coming out as 6 (6 DCLKs). Maybe you are on to something when you mention pitch. How can I troubleshoot my potential "pitch" problem?Are you talking about VIDWIN0XL and VIDWIN0YL? They are set to 400 and 240, respectively.

I attached my VENC and OSD register settings. I have also attached 2 scope traces. Channel 1 is my DCLK (9 MHz), channel 2 is HSYNC, channel 3 is VSYNC, and channel 4 is a data line. The zoomed trace shows that the black pixel swath is coming out 6 pixels wide - as opposed to 4.

beerock said:

The RGB888 buffer is actually 320 x 240 words (~427 pixels).

This now makes more sense, I don't work in RGB888 much myself so this threw me off a bit too easily.

beerock said:

Since posting this, I think I have figured out why I am not getting all 400 pixels. That was related to the fact that I did not configure the OSD clock correctly (actually, I had not tended to it at all) - regs: OSDCLK0, OSDCLK1. This is now corrected.

This could explain some odd operation, and is easy to miss since the default assumes interlaced NTSC output, though I have never tried it myself to see what happens. Though it is still not coming out entirely correct, did this have an impact on  your output for the better?

beerock said:

However, data is still not coming out correctly. I would expect the black pixel swath to occur in the exact spot for each line burst. However, that is not happening.

When you say the black pixels are not in the same spot for each line, how far off are they, and is an every other line difference (like interlacing), or is it continuously sliding to the left or right (like a pitch problem). Do you have an image of the output on your LCD to take a look at? Often with these types of display issues it is easier to get a grasp of the problem by looking at the whole output image.

beerock said:

In addition, the width of the black pixel swath should only be 4 pixels. It is coming out as 6 (6 DCLKs). Maybe you are on to something when you mention pitch. How can I troubleshoot my potential "pitch" problem?Are you talking about VIDWIN0XL and VIDWIN0YL? They are set to 400 and 240, respectively.

It is quite odd that you would end up with 6 clocks of black when it should only be four wide, this sounds more like it could be an artifact of the conversions in the VPBE than a pitch issue (since it goes to YCbCr 4:2:2 every pixel pair shares chroma values which might lead to something like this in LSBs of a vertical line), if you could send a more complicated image through the display and examine the image on the LCD itself that may give a better idea of what is happening here. As to the pitch problem, this would mean each line is offset horizontally from the last, and would stem from the window sizes you suggest not matching the data in your buffer, so it would manifest as your vertical line being torn horizontally across the display at an angle that is relative to how different your buffer is from what the OSD is expecting.

In general you may want to try a couple other data patterns to see what sort of output you get on the LCD itself if possible, looking at individual scan lines with the scope can be valuable for tuning and debugging but viewing how the overall image reacts to changes can tell you a lot more easily. I assume your LCD is already syncing to some extent with the VPBE output?