Golborne Vintage Radio

You wouldn't need a different decoder for 16:9 - the picture (in 625 format) is still 720 x 576 pixels. You would end up taking the middle chunk of pixels out and expanding them out to fit the line.

There was a specific standard for 16:9 standard definition but it was never widely used. The studio SDI was 360MHz instead of the usual 270MHz. Otherwise Cardigan is quite right, it's just a matter of how you intepret the 720x576 picture.

Ah!, thanks for clearing that up I was getting mixed up with HD. In that case it might get looked at when everything else is done but will be very dependent on resources, not least of which would be enthusiasm, it could be running low at that stage.

Frank

Just a quick update.
It was getting to the point that I was going to tackle improving the interpolater but over the past few weeks I had come to the decision that I would try and use the internal memory of the FPGA and as the interpolation would be done in a different manner when using the internal memory as opposed to the frame stores now seamed a good time to make the move to the internal memory before I started on the interpolater.

I have chucked out the microcontroller and the two frame stores.
The old setup had got bushy and over grown with flying leads all over the place, so I took this opportunity to tidy things up. As the powerpad was not connected on the video decoder board that I had, I decided to build a new one and connect the powerpad. The PCB that I got made up can be split leaving the video decoder and the FIFO sections separate. Both section can work autonomously as each have there own power supplies, so now I am only using the decoder section. A crystal oscillator is providing the start up clock that the microcontroller was generating.

I have started back at basics again and have got a simple line dropper going. The results are promising. The glitches are gone and the circuit is much more stable. On the old set up switching anything (Isolation transformer, lamp, soldering iron) on or off caused the video decoder to crash. This had got progressively worse as the number of flying leads grew. Now so far at least, I cannot get it to crash no matter what is switched on or off.

Photos below of the new setup and of the line dropper.

Frank

Good work. Long and spidery wiring is really not good news at 27MHz. Gets worse as you go faster still.

Absolutely fascinating Frank.
I wish I had half of your skills.

Thanks Jeffrey and Trevor.
I think I was asking too much from the video decoder as well. I cant find any figures for the TVP5146 but similar decoders I have seen have a maximum output load capacitance per pin of around 15pF. The data output of the decoder was driving both FIFO's which each had input capacitance of 7pF. This together with the track capacitance would easily take it over 15pF. Worse again was the data clock which was driving the FIFO's and the FPGA.

I was looking at the Intersil TW9910 decoder and the crystal/clock that it requires is 27MHz.
I was thinking that if I was to use this decoder that I could replace the 50MHz clock on the FPGA with a 27MHz one and drive the Decoders clock input from the FPGA. I could run the PLL from this 27MHz clock to produce the 405 clocks and it would also remove the need for a start up oscillator that I have at present.

BUT this would only work if the 27MHz data clock that the decoder produces is the exact same frequency as the Decoders 27MHz crystal/clock.
I suspect that the data clock would have to be locked to incoming video signal and drift with it, so therefore would be slightly different to the clock frequency. If that is the case it wont work as the 405 clocks would not be locked to the data clock which they need to be.

Frank

The decoder's clock requirement depends on the type of decoder. Some simply need a stable frequency, others may involve the xtal in a phaselock. For example the TVP5150 used in the SCRF uses a 14.318MHz xtal. I rather doubt that is being "pulled" in a PLL. The reason for doubting the need for phaselock is that it wouldn't be able to follow VHS replay. The decoder then produces a 27MHz clock to drive the rest of the logic that runs at input clock speed. I dimly remember using the Techwell TW2804 quadruple decoder in a design. Again dim memory suggests that it used system stable 27MHz clock and locked the video to that. I think it coped with VHS replay etcby varying the output line length. I think that was coped with by subsequent memory in the overall design.

If you can guarantee presence of clock from anywhere such as a decoder at startup time then use it by all means. Otherwise you've sawn off yopur own branch.

If you're using linestore then you must derive the 405 clock from the decoder's 27MHz output. With framestores you're free to choose to do that or have a separate clock.

Typically a decoder will drive a FPGA or other LSI chip and nothing else. Via short-ish tracks. The capacitative loading is usually fairly non-critical. The values on the data sheet are just those used for test conditions.

Hi Jeffrey
Thanks for explaining that I had wondered how they dealt with VHS replay. It might be worthwhile to try using a 27 MHz clock on the FPGA to drive a TW9910 decoder, there isn't a lot to loose anyways.

Frank

Busy house clearing at the moment but I came across an article about the development of standards converters in the January 1987 WW - ironically the first issue of WW that is not available on the ARH site.

I haven't got a working scanner* here so I'll make sure I take it back to Hykeham with me next month and scan it.

* More correctly, one that works with post xP operating systems! It is a nice strong Canon unit which will take lots of downward pressure if you are trying to keep a book page flat on the binding edge wheras its replacement - also a Canon - is so flimsy that the mechanism jams when you apply even moderate pressure! So much for progress ...