PAL Video
craig
Brian Fairchild
This description is a general one and doesn't necessarily relate directly to the FigNition. Let's start with the basics…
a complete video line, in PAL, lasts 64usecs. At 20MHz that means we have 1280 CPU clock cycles in every line.
A line is made up as follows…
4.7usec of line sync
5.8usec of blank video
51.95usec of active video
1.55usec of blank video
…turning those into the number of CPU clock cycles we have…
94 clocks
116 clocks
1039 clocks
31 clocks
We are going to use our CPU to generate the video so there must be a relationship between the CPU clock rate and the pixel rate.
Now pick your desired horizontal video resolution.
Lets imagine we want a 32 character display and that each character is 8 pixels wide. So we have a total of 256 pixels per line.
Those 256pixels need to fit into our 1039 CPU clocks.
It's not going to fit nicely so lets say that each pixel will last 4 CPU clocks. That means our character display will last for 1024 CPU clocks. What about the odd 1039-1024 = 15 CPU clocks? Well, we simply make our blank video sections a bit wider. This means that the generated video will not completely fill the possible screen width. It doesn't matter; we will simply see a bit more black down the left and right hand edges. As far as the video signal, and monitor, is concerned it's just video that happens to be black.
So, how to convert those pixels into video?
There are several ways, you can bit bang them onto an I/O line or use the SPI module. The SPI module is nothing more than a shift register. You parallel load it with 8 bits, supply it with a clock signal, and the pixels get shifted out onto a single pin one bit at a time.
So for our example we supply the SPI module with a clock signal every 4 CPU clocks and reload it with 8 pixels very 32 CPU clocks. Voila, our pixels appear at the correct rate on a pin.
For our sync signal we can use counters. Set a counter with the desired amount and clock it at CPU rate. Every time the counter eaches zero we set the sync output pin to the right state.
Take the signal from our pixel pin and from our syns pin, mix them in the right proportions with a couple of resistors and we have a composite video signal.
Right, time for dinner.
Brian Fairchild
minium limited
www.minium.co.uk
phone +44 (0) 1353 749101
fax +44 (0) 1353 749099
Julian Skidmore
That's a very simple and excellent explanation of generating video scans. FIGnition does it pretty much like that. There are a couple of differences,
Practically there's less than 51.95µs visible on most screens; and so to fit within the safe region and also provide a border I limit the screen to 200 pixels, 40µs. There's also the Internal RAM limitation for text mode; an AtMega 168 only has 1Kb of RAM and I've only allowed 600b for video; which gives us a 200x192 pixel image (25 x 24 characters) and 16 User-Definable Graphics.
Secondly, the normal SPI port has problems if you output video on it, because it stops whenever a byte has been transmitted; outputting at least one extra 'bright' pixel. This is the problem the Batsocks Telly Mate has (which is 'masked' ingeniously).
So FIGnition uses the serial port which is double-buffered so it never needs to stop. And can run in SPI mode so it doesn't add spurious pixels between every image byte.
You can see from the information so far why there's real constraints on the image that can be produced. The SPI port (or UART in this case) can only generate bits at every (2+2n) cycles. The choices are pixels every 2 or 4 or 6 etc cycles. So there's not a lot of options available. For bitmapped mode we use 160x160 again at one pixel every 4 clocks, partly because the Serial Ram (which contains the image in bitmapped mode) can only read one byte every 18 cycles and so can't keep up if I try to output a pixel every 2 cycles.
It's also the explanation for why FIGnition doesn't output colour and doesn't output to VGA (or HMDI), it simply doesn't have the performance. VGA leaves < 37µs per scan and HDMI is a more demanding standard AFAIK. Besides I don't yet know if there are even HMDI connectors which can be easily soldered.
Brian's explanation covers a single scan. To handle a full image we need to generate 312 scans. the first 8 scans are what's called vertical sync scans: a special sequence of sync scans so that a TV can work out it's the start of a new frame.
Then comes a top margin on a FIGnition display of 56 scans. Then the image itself (192 scans); and finally a bottom margin of 56 scans before we start the frame again.
Here, FIGnition does a couple of things which most (or all AFAIK) other software video systems don't, it generates sync pulses automatically using the built-in timer hardware. This means that the computer is only interrupted to generate video when the sync pulses need to change, or in the part of the screen where the image appears, thus improving FIGnition's performance.
Hope this helps!
-cheers from julz
The DIY 8-bit computer from nichemachines™
Julian Skidmore
Finally, someone recently asked why there's a white stripe on the left edge. It's because the UART always outputs a single 'bright' bit before outputting any real data.
-cheers from julz
JonB
That was me :)
I also asked if the flickering on flat panels could be addressed in a
future firmware upgrade...
JonB
FIGGY 00123 FOREVER!!
On Dec 14, 10:25 pm, Julian Skidmore <theoriginalsn...@gmail.com>
wrote:
> >> to the FigNition. Let's start with the basics…****
>
> >> ** **
>
> >> a complete video line, in PAL, lasts 64usecs. At 20MHz that means we have
> >> 1280 CPU clock cycles in every line.****
>
> >> ** **
>
> >> A line is made up as follows…****
>
> >> ** **
>
> >> 4.7usec of line sync****
>
> >> 5.8usec of blank video****
>
> >> 51.95usec of active video****
>
> >> 1.55usec of blank video****
>
> >> ** **
>
> >> …turning those into the number of CPU clock cycles we have…****
>
> >> ** **
>
> >> 94 clocks****
>
> >> 116 clocks****
>
> >> 1039 clocks****
>
> >> 31 clocks****
>
> >> ** **
>
> >> We are going to use our CPU to generate the video so there must be a
> >> relationship between the CPU clock rate and the pixel rate.****
>
> >> ** **
>
> >> Now pick your desired horizontal video resolution.****
>
> >> ** **
>
> >> Lets imagine we want a 32 character display and that each character is 8
> >> pixels wide. So we have a total of 256 pixels per line.****
>
> >> ** **
>
> >> Those 256pixels need to fit into our 1039 CPU clocks.****
>
> >> ** **
>
> >> It's not going to fit nicely so lets say that each pixel will last 4 CPU
> >> clocks. That means our character display will last for 1024 CPU clocks.
> >> What about the odd 1039-1024 = 15 CPU clocks? Well, we simply make our
> >> blank video sections a bit wider. This means that the generated video will
> >> not completely fill the possible screen width. It doesn't matter; we will
> >> simply see a bit more black down the left and right hand edges. As far as
> >> the video signal, and monitor, is concerned it's just video that happens to
> >> be black.****
>
> >> ** **
>
> >> So, how to convert those pixels into video?****
>
> >> ** **
>
> >> There are several ways, you can bit bang them onto an I/O line or use the
> >> SPI module. The SPI module is nothing more than a shift register. You
> >> parallel load it with 8 bits, supply it with a clock signal, and the pixels
> >> get shifted out onto a single pin one bit at a time.****
>
> >> ** **
>
> >> So for our example we supply the SPI module with a clock signal every 4
> >> CPU clocks and reload it with 8 pixels very 32 CPU clocks. Voila, our
> >> pixels appear at the correct rate on a pin.****
>
> >> ** **
>
> >> For our sync signal we can use counters. Set a counter with the desired
> >> amount and clock it at CPU rate. Every time the counter eaches zero we set
> >> the sync output pin to the right state.****
>
> >> ** **
>
> >> Take the signal from our pixel pin and from our syns pin, mix them in the
> >> right proportions with a couple of resistors and we have a composite video
> >> signal.****
>
> >> ** **
>
> >> Right, time for dinner.****
>
> >> ** **
>
> >> Brian Fairchild
> >> minium limited
> >>www.minium.co.uk
> >> phone +44 (0) 1353 749101
> >> fax +44 (0) 1353 749099****
>
> >> ** **
>
> >> ** **
>
> >> ** **
>
> >> *From:* fign...@googlegroups.com [mailto:fign...@googlegroups.com] *On
> >> Behalf Of *craig
> >> *Sent:* 14 December 2011 19:20
> >> *To:* fign...@googlegroups.com
> >> *Subject:* PAL Video****
>
> >> ** **
>
> >> I've had my Fignition for quite a while and I'm trying to understand how
> >> it works. I've already looked at the Understand it section on the main site
> >> but I'm looking for more information on how the PAL video is generated on
> >> the chip. I've read the Fignition code and sources such as:****
>
> >>http://www.rickard.gunee.com/projects/video/pic/howto.php****
>
> >>http://www.batsocks.co.uk/readme/art_SerialVideo_1.htm****
>
> >>http://martin.hinner.info/vga/pal.html****
>
> >> ** **
>
> >> Can anyone point me to more detailed information or give any information
> >> here. I don't understand the relation of the AVR clock to the timing of a
> >> video signal, many PAL projects I've seen use various clock frequency with
> >> 16MHz being the most common but Fignition uses 20MHz. Syncs are a tricky
> >> subject for me as well so really I'm stuck on the most crucial parts of PAL
> >> video generation.****
>
> >> ** **
>
> >> Any Help appreciated and Thanks in Advance,****
>
> >> Craig****
>
> > --
>
> > The DIY 8-bit computer from nichemachines™
>
> --
>
> The DIY 8-bit computer from nichemachines™
>
> FIG - black on whiteMini.jpg
> 13KViewDownload
>
> NmLogoMini.jpg
> 4KViewDownload
craig
The format for field 1 (starting at line 623.. ends at line 5 inclusive):
- 6 Pre-equalizing pulses.. 5 long sync pulses... 5 Post-equalizing pulses.
The format for field 2 (starting at line 311.. ends at line 317 inclusive):
- 5 Pre-equalizing pulses.. 5 long sync pulses... 4 Post-equalizing pulses.
Julian Skidmore
Flat panel flickering has been improved, but they're more exacting you know. However, now the source code is available for the video, people can recompile with slightly different settings to see if it can be improved (I don't have an LCD tv, amazingly, so I can't test it).
-cheers from julz
Brian Fairchild
The text quoted is wrong.
For PAL it is *always* 5 + 5 + 5 (source: Specification of Television Standards for 625-line System I Transmissions)
As far as the first field goes - it doesn't really matter as it will sort itself out next time around. Although if you wanted to be absolutely spot-on you'd start on Line 1 which is the start of the Broad Pulses (aka long sync pulses).
And yes, the delay is a high level for 30us. The '5 + 5 + 5' vertical sync sequence runs at twice the normal sync rate so that you get a falling edge every 32us. Note that it's the falling edge which is used as the timing reference point.
A quick web search brings up an amazing number of pages where the information on video sync is just plain wrong.
Brian Fairchild
minium limited
www.minium.co.uk
phone +44 (0) 1353 749101
Julian Skidmore
Thanks for that! Seems like I'm not the only culprit:
http://www.batsocks.co.uk/readme/art_SerialVideo_5.htm
-cheers from julz
