CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support
On-Screen Display

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Jeprox
Guest
On-Screen Display
PostPosted: Wed Jul 21, 2004 6:19 pm     Reply with quote
As far as video goes, I'm a novice.

I'm looking at designing an On-screen Display OSD). I've seen on the wed PIC-based products for sale. It talks about this board overlaying some data "onto incoming PAL or NTSC video source."

Pardon me with this silly question, but if I have a monitor, what equipment does provide this video source? How is this video source connected and also, how is the OSD connected to the monitor? Which of the connectors at the back of the monitor does it go? Basically, which unit connects to which?

Those who have designed a PIC-based OSD, perhaps share your expert advice.

Thanks.
Ttelmah
Guest
Re: On-Screen Display
PostPosted: Thu Jul 22, 2004 3:22 am     Reply with quote
Jeprox wrote:
As far as video goes, I'm a novice.

I'm looking at designing an On-screen Display OSD). I've seen on the wed PIC-based products for sale. It talks about this board overlaying some data "onto incoming PAL or NTSC video source."

Pardon me with this silly question, but if I have a monitor, what equipment does provide this video source? How is this video source connected and also, how is the OSD connected to the monitor? Which of the connectors at the back of the monitor does it go? Basically, which unit connects to which?

Those who have designed a PIC-based OSD, perhaps share your expert advice.

Thanks.

The OSD discussions you have seen, referring to PAL, and NTSC, are dealing with 'composite video'.
Basically there are a number different methods of talking to displays in common use, according to how far 'away' from the core electronics of the display you go. The display itself, has a scan, moving the dot across the screen, a second analog scan moving the line vertically, after each pass across the screen, and an 'intensity' signal sent to the tube, that modulates the brightness of the dot as it moves. Thn stepping one stage 'away' from this, you have the low level 'video' signal, which has the dot intensity data, and seperately two 'timing' signals, which instead of ramping analog signals, are just digital pulses to synchronise the 'scans' inside the tube (colour has three sperate intensity signals, one for 'red', one for 'green', and one for 'blue'). Then moving another stage away, these signals can be combined into a 'composite' video signal. On this, the same timing pulses are present, but now as special 'levels' on a single signal. Then for colour, a specific time interval after the sync signal at the start of each line, there is a short burst of a tone (the 'colour burst'), which can be gated into a phase locked loop oscillator, so that this can be precisely synchronised with the oscillator in the source. Then the signal as sent, is a combined 'intensity' signal (effectively the luminance of a traditional black and white picture), with 'on top', a phase shifting 'tone', which is used to encode the colour to be applied. Effectively the phase represents a colour 'round' a chart of different rainbow colours, and the luminance signal how bright it all is.
Now putting a picture on screen, involves intercepting these signals, and switching your own signal 'in' to replace them at a specific point along the line, and down the rows. When dealing with a composite signal, it is normal to use a proprietary chip to seperate the signals back to RGB video, and then recombine these when the job is complete. In the past, Phillips did a chipset for this, as part of their stuff for teletext.
For a system using seperated video (which is what you seem to be talking about), this is no longer necessary. All(!), that is needed, to (for instance), create a 'dot' on a screen at a particular point, is to have two timers. One you reset when the 'frame sync' pulse, signals that the signal should return to the top of the tube, counting the 'line sync' pulses that occur. The second you reset on each line sync pulse, and count from an oscillator using your own 'dot clock' frequency. Then if you want a dot 100 lines down, and 100 of your 'dots' across, when both counters reach this value, you switch the RGB video signals, from being connected to the incoming signal, and instead connect it to your own signal.
So the unit ould need to receive the incoming RGB, Hsync, and Vsync signals, from the cable that normally connects to the monitor, and output the same signals to the monitor. The sync signals go to the counters, and then the RGB signals feed 'through' a high speed switching circuit. When required, the switch is operated, and the signal connected to display what you require.
In the past, the CMOS 4066 quad bi-lateral switch, was commonly used to do this. However you then have the problem of bandwidth. A 'normal' TV signal, only has the signal changing at perhaps 10Mhz (generally broadcast TV, is worse than this, while the teletext signals used inside the sets, gets to about 14MHz). However a computer monitor, may be operating at _much_ faster rates. As an example, the monitor I am typing this on, is running 1600*1200*85Hz = 163MHz. Now taking such a signal, switching it, and not introducing signalling problems (ghosting etc.), is much harder. A lot of RF design is needed to get a good impedance match, and the switching elements used, are going to need to operate very quickly. Also the system generating the picture itself, is going to need to be faster. You can (fortunately), put a low resolution picture 'over' a higher resolution one, provided you have the counters able to handle the faster rates, and design the circuitry to avoid the signalling problems mentioned.
So, if you are happy to work with pictures running at 'CGA' display resoltions, then look again at the work you have seen on OSD's, and see if you can work out where the video first appears in it's 'decoded' state. This corresponds to the incoming signal that is present on the monitor cable. Then see where this goes back into the circuitry to be turned back into a composite video signal. This is the point where the signal would have to feed out to the monitor.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group