Bad pixel in 16bpp QVGA driver

Rayman

Working again on OV2640 camera and having some better luck.

For testing, I have the camera outputting 16bpp QVGA (320x240) data.
I have this driver here that shows this image on VGA monitor.

The driver cuts the regular VGA pixel rate in half and then shows every line twice.
In this way, monitor thinks it is full VGA image, even though only QVGA.

Only problem that I have is that the top right pixel in the image is always black, when it shouldn't be.
Not seeing what is causing this...

Here's a test program that shows a static bird image with that bad pixel:

Rayman

Dug up an old 8bpp example of this. Seems didn't notice problem before because image was not full screen.
Interestingly, it is not the top-right pixel that is bad here, it's the pixel to the left of it.

pik33

May be rdfast+xcont timing problem. I had glitches with these instruction in my video drivers too. What if move these rdfast to add time between rdfast and xcont?

field2

                mov     x,TopBlanks                   'top blanks
                call    #blank
                mov     m_buf,ptrb
               ------> ' add rdfast here
               rdfast  ##640*1/64,m_buf


                mov     x,AsmVisible                  'set visible lines
line            call    #hsync                  'do horizontal sync
               ' -----> remove rdfast from here
                xcont   m_rf,#0                 'visible line
                call    #hsync                  'do horizontal sync
                xcont   m_rf,#0                 'visible line
                add     m_buf,##320*2
               '------->  add rdfast here
                rdfast  ##640*1/64,m_buf
                djnz    x,#line                 'another line?

                mov     x,BottomBlanks                  'bottom blanks
                call    #blank


                drvnot  vsync                  'sync on
                mov     x,#2                    'sync blanks
                call    #blank
                drvnot  vsync                  'sync off

                jmp     #field1                  'loop

Rayman

Fix was to replace:
rdfast ##640*1/64,m_buf
with:
rdfast #0,m_buf

No idea why that should make any difference though...

rogloh

Because the ## needs an extra 2 clock AUGD overhead perhaps?

Wuerfel_21

Maybe your buffer wasn't long-aligned?

Wuerfel_21

Looking at your code, indeed. IIRC the DAT block is inherently long aligned, but you're adding an offset of 54 that isn't divisible by four to get past the BMP header (why? just use actual raw data)

Rayman

@Wuerfel_21 Thanks, that might help explain some of this. I find this in the docs:

If you intend to use wrapping, your hub start address must be long-aligned (address ends in %00), since there won't be an extra cycle in which to read/write a portion of a long in an extra hub RAM slice. In cases where you don't want wrapping, just use 0 for the block count, so that wrapping won't occur until the entire 1MB hub map is sequenced through.

I guess I can move the bitmap data to be long aligned at see what happens then.

Wuerfel_21

Just add a word 0 before the file into the dat block...

Rayman

@Wuerfel_21 You were right, adding the word 0 fixed it.