Videogenerator mystery [turned out to be no mystery - just wrong code]

Andrey Demenev · 2011-03-27 21:25

I have the following piece of code (the actual code is bigger, but it is generated and not very readable):

                    mov     counter, #10
:loop               mov     VSCL, vsc
                    waitvid colors, pixels
                    djnz    counter, #:loop
' ................
' ................
' ................

colors              long    $FF
pixels              long    $0
counter             long    0
vsc                 long    1 << 12 | 64

The intention is to generate 10 groups of pixels, each 64 pixels wide, white color, with sync outputs held high. This code is sorrounded by a loop that repeats the line 480 times, and generates vsync and hsync pulses. This works just fine, and I see nice white screen. Sync pulses look fine

Now I want to draw a screen showing vertical 1-pixel lines across black screen, and change the code:

                    mov     counter, #10
:loop               mov     VSCL, vsc
                    waitvid colors, pixels
                    djnz    counter, #:loop
' ................
' ................
' ................

colors              long    [b]$03FF[/b]
pixels              long    [b]$FFFFFFFE[/b]
counter             long    0
vsc                 long    1 << 12 | 64

This destroys sync pulses - both vsync and hsync are garbage.

VCFG is initialized as following - VGA mode, 2 colors:

                    movi    VCFG, # 1 << 6 ' | 1 << 5
                    movs    VCFG, #$FF
                    movd    VCFG, #%010

What I am doing wrong?

Andrey Demenev · 2011-03-27 21:51

This turns out to work

                    mov     counter, #10
:loop               mov     VSCL, vsc
                    waitvid colors, pixels
                    djnz    counter, #:loop
' ................
' ................
' ................

colors              long    $03FF
pixels              long    $C0000000
counter             long    0
vsc                 long    1 << 12 | 64

shows groups of 30 white pixels followed by 34 black. Have no clue what is happening

kuroneko · 2011-03-27 22:08

Most odd. How far can you get down from $C0000000 (i.e. $E0000000, $F0000000, $F8000000) before it breaks?

potatohead · 2011-03-27 22:27

Interesting...

How come the frame size is so big??

vsc long 1 << 12 | 64

Seems to me, that's asking for 64 pixels, where the waitvid pixel argument only contains 32 pixels worth max. Have you tried 2 << 12 | 64, and or 1 << | 32, with changes to PLLA to account for that in the timing? Edit: Or changes in your pixel loop.

When the frame size exceeds the number of pixels, I'm not sure that behavior has been well characterized.

potatohead · 2011-03-27 22:41

Yeah, there is this:

From the data-sheet:

When the FrameClocks value is greater than 16 times the PixelClocks value and 4-color mode is specified, the two most significant bits are repeated until FrameClocks PLLA cycles have occurred. When FrameClocks value is greater than 32 times PixelClocks value and 2-color mode is specified, the most significant bit is repeated until FrameClocks PLLA cycles have occurred. When FrameClocks cycles occur and the cog is not in a WAITVID instruction, whatever data is on the source and destination busses at the time will be fetched and used. So it is important to be in a WAITVID instruction before this occurs.

I don't quite get what your program is doing, but it seems to me, duplicating the most significant bits is not the desired behavior... Could that be hosing up the sync, because of the odd frame size?

So it is characterized. Not sure that's what you were after though.

Andrey Demenev · 2011-03-27 22:42

Even more odd :

00000000, 80000000, C0000000, E0000000, F0000000, F8000000, FC000000, FE000000, FF000000, FF800000, FFC00000, FFE00000, FFF00000, FFF80000, FFFC0000, FFFE0000, FFFF0000 work fine.

FFFF8000

FFFFC000

FFFFE000

FFFFF000

FFFFF800

FFFFFC00

FFFFFE00 breaks hsync, vsync stays nice, 59.9 Hz pulses. Starting from FFFFFF00 - both sync pulses are garbage

Andrey Demenev · 2011-03-27 22:53

potatohead wrote: »

I don't quite get what your program is doing, but it seems to me, duplicating the most significant bits is not the desired behavior... Could that be hosing up the sync, because of the odd frame size?

Repeating the higher bit is actually desired behavior here, since it allows to emit long frames, and as result - work at higher pixel rates.

potatohead · 2011-03-27 22:58

Ok. What kind of display are you shooting for? Just curious about that.

Andrey Demenev · 2011-03-27 23:12

I am trying to generate VGA test patterns at different resolutions, frame rates and sync polarities. To accommodate all possible combinations, the code is generated from numeric descriptions of video modes (pixel clock, rfont porch, sync etc) and patterns. So far I successfuly generated up to 1920x1200 in one cog, but only when pixels is zero. Needless to say that at such resolutions frames longer than 32 pixels are required if you want 1-pixel resolution (vertical lines for example).

Also, long frames are not likely the problem here - I observe similar things with 32-pixel frames

Andrey Demenev · 2011-03-27 23:29

Observation from the pictures above - as ones are moved right through pixels, first red is affected, then green, then blue, then comes the turn of hsync and vsync

potatohead · 2011-03-28 00:08

I see that now, and agreed. It's not the frame size.

What clock are you running? And is it common to more than one Propeller?

Andrey Demenev · 2011-03-28 00:13

I only have one board. 5 MHz crystal with PLLx16. Nothing changes when chip is replaced

Andrey Demenev · 2011-03-28 00:49

There is no problem with video generator, it is my code generator that made wrong code. When generating WAITVID instruction, it set WR bit to 1, so after first WAITVID the colors were modified. Now I have nice 1-pixel lines. Sorry for the noise.

kuroneko · 2011-03-28 00:51

Ahh, as usual. The bits we didn't get to see ...

Videogenerator mystery [turned out to be no mystery - just wrong code]

Comments