how does FRQA really works with Video drivers?

oliverde

Hello all.
I am trying to do my own video driveer for VGA. I read all datasheets, propeller manual, I already saw other drivers but looks like nobody does what the datasheet says...
this is what I am doing right now. I tryed to do a simple program to make one single line of video first, so there is no monitor connected, no vertical signal yet, just an oscilloscope to see the times and figure how and where do the other's drivers got their weird numbers for FRQA, VSCL, PIXELS and COLORS and , so I first setup the video generator in two color mode and other registrs like this:

_FRQA = 40000000;
_CTRA = 0b00001 <<26 | 0b101 <<23;
/******Config VIDEO*******/
_VCFG = 0b01 <<29 | 0b0 <<28 | 0b010 <<9 | 0xFF ;
_VSCL = 1<<12 | 32;
while (1)
{
//Hsync and back porch
__builtin_propeller_waitvid( 0x00000200, 0xFC1FFFFF);
//display pixels
for(i = 0; i < 16; i++)
{
__builtin_propeller_waitvid( 0x0000c202, 0xAAAAAAAA);
}
}

You can see the behavior of this small portion of code in the attached image, so I was very happy since it looks like is too simple to make a video driver, the problem started when, I increased the register to "calibrate" the times by changing the FRQA to adjust my line of video to comply the VGA standars and there is what I got.

there is the Horizontal sync signal and a color bit. it has everything, just need to comply with the times

I have seen other drivers which works perfectly with FRQA adjusted to _FRQA = 0x1C000000; so I changed in the code above for this value and the signals gone with a mess in the whole port, see the attached image...

don't know why all port pins starts to do unexpected behavior.

I want to ask what happens there? I was incrementing this FRQA litle by litle and the times of my Hsync and pixels signals get narrower as expected but sudenly it stops to do the proper behavior, so I cannot get how the other driver came with this value??

Can somebody help me?

kuroneko

It's really not that difficult. frqa controls an NCO which generates a frequency of clkfreq*frqa/2^32. Said frequency has to be within 4..8MHz (used as PLL input). With clkfreq usually at 80MHz and frqa being e.g. $1000_0000 we get a 5MHz PLL feed. This input frequency is then multiplied (internally) by 16 and then subdivided by the PLL divider which sits in bits 23..25 providing you with the video clock.

You probably know this but when you can't keep up feeding the video h/w (too much time between waitvid calls) you will get undefined output. I'm not saying that it shouldn't/can't be done in C but there is a point when high level convenience gets in the way.

oliverde wrote: »

... but looks like nobody does what the datasheet says ...

Out of curiosity, can you provide some examples?

potatohead

You need to use PASM for the driver, unless you are only interested in very low screen resolutions, like say 32 pixels / scanline.

Eric Ball made a TV driver in SPIN for fun once. We were all musing about whether or not SPIN could do the job. Turns out it can, but not in a way that can deliver higher numbers of pixels per line.

VGA has a higher sweep frequency as well, which may well put it beyond SPIN, even with blank scanlines.

Moderate resolution VGA is a pretty easy task for a Prop chip, in PASM. I would take the VGA.spin driver you got with the Propeller tool along with other drivers and start to understand how they work.

Often, a simple driver can serve as a template for what you want to do. Good first tasks are to have one draw a low resolution bitmap for testing, or do color bars, etc...

You can also tell us what you are wanting the display to do. It may be we have a driver close too.

Edit: You can also ask about COG mode C programs, whic can do video drivers. One of the GCC experts wrote a little pong game in COG mode C code.

You may also find you can unroll your video loop to code each scanline and have it be fast enough. If you attempt this, work with low numbers of pixels per line and the lowest horizontal sweep frequency you can. A 640x400 interlaced mode has been shown to work on most monitors. The 320 pixel modes are no longer supported. TV only. And you could consider using TV for it's low sweep frequency.

In any case, you start with a raw signal, just empty scanlines and the sync. Then you work up from there, and as mentioned, waitvid needs data regularly. The higher the pixel clock, the higher the horizontal sweep frequency, the less time you have between waitvids.

I was not looking closely, and thought you were attempting SPIN.

oliverde

Thanks for your reply kuroneko.
I am new programming the propeller. So there are a bunch of questions I have, but now I am working with the video generation block.
in the same code posted I changed FRQA to 60000000 which is 0x03938700 and the "video line" I am generating is this:

which looks fine, and here is the detailes times for the pixel

measured with time cursors you can see the pixel is 240ns wide,
that makes 4.16Mhz of pixel rate.

So the equation clkfreq*frqa/2^32 = 80M*60M/2^32 = 1.1175Mhz them multiply by 16 and divide by 4(PLL configuration) and I have 4.44Mhz of pixel rate which looks like I have but the jump of the cursor when I took the photo is not quite fine so here is the new photo:

and looks great with 230ns ~4.34Mhz but still cursor not fine enough but lets assume it´s fine.

THE PROBLEM is whan I start to get a faster pixel rate because it is not working for VGA standard. if you can see the cursors of the first photo Hsync is 113us apart and I have to achieve 16.66us, so if you look at the code I am trying to display a single line of 16 columns with 16*32 pixels = 512 bit of resolution per line. So that is what I have there, is there in the for cycle so much time between the waitvid calls?

They do in this vgademo of the demos like this:
static _NATIVE videoLine(uint32_t *lineptr)
{
int i;

uint32_t pixels;



_VSCL = visibleScale;

for (i = 0; i < DISPLAY_WIDTH_LONGS; i++)

{

pixels = *lineptr++;

__builtin_propeller_waitvid(pixels, ConstPixels);

}

_VSCL = invisibleScale;

__builtin_propeller_waitvid(HSyncColors, syncPixels);

}

where DISPLAY_WIDTH_LONGS = 40 (but pixels are chars) by the way, here is where I say "nobody does what the datasheet says" all drivers that I have seen, they update the pixels in the field of colors of the waitvid instruction, and left the pixels field like a constant, in this case ConstPixels = 0xE4, why they update a char size color in the pixel field of the instruction? when it supose should be 32 bits... and what happens to the pixels being constant?

Anyway, this last driver works perfect in C, and they have configured in FRQA this: (what a hell is that?)

testval = (25175000 + 1600) / 4;

frequency = 1;

for (i = 0; i < 32; i++) {

testval = testval << 1;

frequency = (frequency << 1) | (frequency >> 31);

if (testval >= clkfreq) {

testval -= clkfreq;

frequency++;

}

}

_FRQA = frequency;


this portion of code update the FRQA with 340875120 in decimal wich will not work in my code. Why it works for them and not for me? is something "hide" in the configuration? I have been looking in all blogs, reading and there is not more information about the video configuration than the Hydra book which I have, Everybody copy and paste what somebody said that Video Streaming Unit is just a serialyzer and haev nothing to do with video signals... blablabla.

My code starts doing wrong stuff when I increase the FRQA by 75000000

and get worst if higher, like here with 80000000

and see the detail

where the Hsync bit is corrupted with a value that I don´t know where it come from and worst ans worst

...

Thanks for your time and hope someone can help me.

Ariba

Updateing the color part of WAITVID and having a constant for the pixel part is a trick to get a 256 color mode. The constant 0xE4 is the same as %%3210 in Spin/PASM which means you output 4 pixels per WAITVID and every pixel uses amother of the 4 possible color bytes in the color long-word.

But there are also many existing drivers that use the intended way with updating the pixel long. They mostly work with 2 or 4 colors per tile or line.

The best example for you may be Chips 512x384 bitmap driver in the OBEX.
It has a short PASM code that can relativly easy be modified for other resolutions.
You really should consider to use Assembly for Video drivers, it's the only way to get control over every single clock cycle which is necessary if you go at the limits of the Video hardware (Kuronekos VGA drivers are the best example) .

Andy

oliverde

It is really difficult for me to do assembler programming.

Is there any way to use the Chip's driver (the 512x384 that is the one I need) in assembler and do other parts of my complete project in C? How can I do that?

kuroneko

oliverde wrote: »

... is there in the for cycle so much time between the waitvid calls?

The first driver you mention is specifically written to run in a cog as is:

120              	[COLOR="#FF0000"].L3[/COLOR]
  47:vga.cogc      ****         pixels = *lineptr++;
 121              		.loc 1 47 0
 122 00b8 0000BC08 		[COLOR="#FF0000"]rdlong	r7, r5[/COLOR]
 123              	.LVL11
  48:vga.cogc      ****         pixels |= HVSyncColors;
 124              		.loc 1 48 0
 125 00bc 0000BC68 		[COLOR="#FF0000"]or	r7, r8[/COLOR]
  47:vga.cogc      ****         pixels = *lineptr++;
 126              		.loc 1 47 0
 127 00c0 0400FC80 		[COLOR="#FF0000"]add	r5, #4[/COLOR]
 128              	.LVL12
  49:vga.cogc      ****         __builtin_propeller_waitvid(pixels, ConstPixels);
 129              		.loc 1 49 0
 130 00c4 E4007CFC 		[COLOR="#FF0000"]waitvid	r7,#228[/COLOR]
  45:vga.cogc      ****     for (i = 0; i < DISPLAY_WIDTH_LONGS; i++)
 131              		.loc 1 45 0
 132 00c8 0000FCE4 		[COLOR="#FF0000"]djnz	r6,#.L3[/COLOR]

This loop is short enough for what it's trying to achieve (160x120 full colour). The other driver (used in vgademo) uses PASM for the heavy lifting and C for the frontend which IIRC is [thread=152730]spin2cpp[/thread] output. So it looks like running the 512x384 driver through spin2cpp will be your best option for now.

As Andy already pointed out, the constant pixel pattern is usually used for full colour mode. That said, I've seen and used all four combinations of static/dynamic colour+pixel pairs (not necessarily for video generation).

oliverde

Thanks a lot, I will work on trying to use Chip's driver.

Thanks again

surixurient

what makes only 4 pixels used instead of all 32 bits worth(16)?
is that what FrameClocks of VSCL controls? how many pixels to do per waitvid?


__builtin_propeller_waitvid(pixels, ConstPixels);

kuroneko

surixurient wrote: »

is that what FrameClocks of VSCL controls? how many pixels to do per waitvid?

vscl[11..0] defines how long it (waitvid) lasts, vscl[19..12] how many clocks are spent on one pixel.