Golborne Vintage Radio

SECAM to PAL conversion can work, but it's far from ideal. There's no equivalent to a comb filter decoder for SECAM. If any of the FM subcarrier gets into the PAL output it causes nasty artefacts. So the only way is to brutally filter the input luminance. From my own limited experience the decoder chips make as good a job of it as possible. In other words, not very. Going the other way, from PAL to SECAM, works better.

SECAM is utterly vile in the studio because you can't directly mix or fade it. So in France they often produced in PAL and converted to SECAM for transmission. It's not surprising that France was a leader in the move to use analogue components for production. One day, if I'm in the mood, I'll relate some stories about the Moscow Olympics and SECAM.

Basic 50<>60 conversion (by droppiing or repeating fields) will always look jerky. Though it's not too bad on much material. Been there, done that.

Hi Jeffrey
I didn't know that about SECAM to PAL conversion.
Looking online there is no problem getting a box to convert from SECAM to PAL but probably not do it so well. But I cant find anything that converts from PAL to SECAM. There must be no call for them.

Frank

The only people who might need a SECAM output these days would be enthusiasts running old French or Soviet bloc sets which were SECAM only. Most of the coder chips, for making PAL/NTSC from digital components, couldn't do SECAM. Presumably because it wasn't a common requirement even a decade or more ago. Remember that most European sets that could receive SECAM could also receive PAL.

c1999 I designed a SECAM output add-on for a client because we though there might be a demand. Never went into production.

When I worked for Michael Cox Electronics in the early 1980s we did quite a bit of SECAM. Mike Cox spoke French fluently (with a very English accent) and loved all things French. It was still a vile colour system. Its only advantages were that you could record it on an unmodified monochrome Quadruplex VTR (soon nullified by the colour versions) and it would survive better on long and mucky distribution links. I'm not sure why the Russians adopted it. Possibly due to not having access to the high technology of colour capable VTRs. Possibly due to very long distribution chains. Possibly due to some French political skulduggery. Or a mixture of all three.

AFAIK, BBC and ITV engineers hated SECAM and would willingly have gone for NTSC, adapted for 625 or even 405 lines. They weren't 100% happy with NTSC but they knew they could make it work well. Then PAL came along just in time.

Hi Jeffrey
Thanks for that explanation. I understand SECAM's place in the world now which I didn't before.

Frank

To operate a TV studio in SECAM was a nightmare. You could cut between cameras but a simple fade or mix was horrendous. At Cox we made SECAM mixers, for the few masochists, usually from Eastern Europe, who wanted the ideological "purity" of full SECAM.

As well as the direct path through the vision mixer you had an alternative route. A partial decoder demodulated the alternating Dr/Db chroma and brutally filtered off the Y signal. Twin video paths allowed you to mix, fade etc the signal. Then through a partial encoder to get back to SECAM. As the fader came off the endstop the picture quality would visibly change to soft and horrible. Jumping back to normal as you got to the other end.

The French soon realised that you produced in PAL and transcoded to SECAM before sending to the transmitters. As I said earlier, they were very enthusiastic about analogue components, made possible by the first Betacam professional VCRs. The fact you needed 3 times the amount of kit to switch, fade, mix the YCbCr signals was just a fact of life until digits arrived.

Can this converter do NTSC 405 From PAL 625?

I'm sure Frank will give a fuller answer but the requirements are:

1: Enough memory to hold both luminance and colour difference signals
2: Enough logic in the FPGA to build a coder

The coder is fairly simple in principle. I've designed PAL/NTSC coders and am happy to give Frank my VHDL for them.

I don't think Frank has provided enough storage to do a colour framestore. Might be possible to do a linestore based converter for PAL625 to NTSC405 if there are enough memory blocks available in the FPGA.

In my experimental converter testbed I've got ample memory but I'd probably be struggling for FPGA resources as the device I'm using is old enough not to have dedicated multiplier blocks.

Jeffrey is correct. There is not enough memory for a colour frame store.
I don't think there is enough memory to do a linestore based converter.

I have used quite a lot of the available memory. It is used for line stores. But also the AL422 had not enough memory to be used as a frame store. So I used a chunk of BRAM to supplement the AL422 to get frame store.
I have only 1 multiplier left.

One thing that I need to fit in is some form of a test card even something very basic will do. I had a 625 test card similar to the Hedghog one done up before I started on the NTSC input.
I had to remove it to do the NTSC as it has almost all the resources eat up. The one in the Hedghog wouldn't do as it is 405. The one for this converter need to be 625 or 525 so it can be inserted in the input to the converter.

This converter uses a EP4CE6. To up the resources I looked at the EP4CE10 and the EP4CE15. The EP4CE15 would require a new PCB but the EP4CE10 looks like it is pin comparable and would drop in place of the EP4CE6.
I haven't tried but it looks possible.

Frank

What a difference 0.03Hz can make!

I had disabled the syncing of the output to the input while working on the NTSC input.
So it was time to reconnect this. It would be synced while converting from a 25Hz frame to 25 Hz frame of from a 30Hz frame to 30 Hz frame and left free running at other times.
So when reconnected the 25 Hz to 25 Hz worked well as it did before. But when going from 30 Hz to 30 Hz it wasn't syncing properly.
See photo below. There is bad hooking on one field.
The way the output clock is calculated is.

frame frequency * No. of lines * cycles in a line = output clock frequency.
This is calculated in the microcontroller and is passed to the FPGA where it is multiplied by a coefficient. The result is used as the coefficient for the output clock DTO. The clock driving the DTO is derived from the video decoders video clock.

All pretty straight forward and I couldn't see at first what was going on. Then it occurred to me that the frame frequency was in fact 29.97 Hz and not 30 that I was using.
Changing 30 to 29.97 in the calculation in the microcontroller could be done but instead I adjusted the coefficient in the FPGA if the input was a 30 Hz frame. As it was easier to implement.

This has also explained another problem that I noticed.
While connected to a 525 signal it could occasionally be seen to lose frame lock.
The Hedghog PSC that I am using as a 525 signal source had a 30 Hz frame and not 29.97. Regardless of this the video decoder was implementing a 29.97 frame on its output.
Because the two frame rates were slightly out there phase was forever drifting apart. When they drifted far enough apart lock was lost and the decoder had to then regain lock. This would show up on the picture as a brief loss of frame lock.

After changing both Hedghogs to 29.97 proper sync has been restored and there is no more loss of frame lock

Frank

While the 29.97Hz frame rate of NTSC is a great nuisance in TV production it allowed the early digital TV standards to work rather well. With a 13.5MHz pixel clock you get 864 pixels per line in PAL and 858 in NTSC. Exactly. This simplified a lot of digital kit, very valuable in the early days when it was difficult.

The price for this is that the pixels aren't square in either standard, something that's a problem when interfacing with computer systems. The later HD standards all use square pixels. As a result the clocks for 25Hz and 29.97Hz are in the ratio 1000/1001. So for 1080/50i the pixel clock is 74.25MHz. For 1080/59.94i it's 74.5 * (1000/1001).