Test Card / Teletext Generator - Phase 1

[Parabola]

Hello All,

Business is slow (surprise, surprise!), so I've been spending some time on projects I never normally seem to get around to. One of those being a solid state, multistandard, colour, test card generator with the added ability to also put out a few teletext pages. With analogue teletext on the way out fast, I definitely need something to kick aging teletext decoders into life when running some of my old sets.

So, I envisaged doing this in 3 phases - each one creating something that worked and was useful. Here's the masterplan -

Phase 1 - Single Frame (2 fields), Multistandard (405/441/625/819), Monochrome - Pre-programmed content - changable by chip swap.

Phase 2 - As above, but now in colour (4 frame / 8 fields) and including at least 4 teletext pages.

Phase 3 - As above, but now with added USB connectivity to allow re-programming via a host computer.

The astute will now be saying, "Ah, you've now created the RT Russell generator all over again". Well, yes - but you can't buy an RT Russell anymore! There is also a similar (405 line) device in the projects section of Duke_Nukem's site. However, that's a little under spec'd for 625 colour and teletext. My point is, I make no claim to the operational concept of this device - this is my attempt at creating a practical unit to my own design.

Today I've got Phase 1 completed - please see the attached pictures.

The unit is shown generating 625 Test Card F in monochrome, feeding video directly into a very el-cheapo 80's mono monitor intended for low end home computer (with TV out) use.

Continuing with 625 as an example; The output is full bandwidth as the pixel clock is running at 12MHz. That equates to 720 pixels per active horizontal line. As the syncs are also coded as pixels, the total line, including syncs and portches, comes out at 768 pixels in total. Therefore, the total byte count for one frame (2 interlaced fields) is 768 x 625 - 480,000. This 'image' is stored in a 4M Bit Flash EPROM (70ns) to meet the required clock speed (U/V erasable EPROMs are, largely, too slow).

Because the entire frame, including syncs, is contained in the ROM 'image', it's a small matter to switch standards to 405, for example, or any other required format. In the same way, teletext coding can be inserted into the vertical blanking interval lines.

As you will see from the pics, I managed to achieve Phase 1 using less chips than I first envisaged, hence the 3 empty sockets! The empty area in the middle of the board is for the addition of more PROMs for adding colour and increasing the number of text pages. I also need to stick a buffer (op-amp or transistors) on the output of the DAC, but overall I'm pleased with progress so far.

Comments / suggestions welcomed from the smarter folk than me on here (you know who you are!).

Parabola

[oldticktock]

I'm certainly not one of the smarter folk, but fantastic work and when it goes into limited production I will be a customer

[Tazman1966]

Facinating stuff mister! I imagine that, say, BBC type VITS could be inserted too?

[Steve_P]

Put me down for one!

There were 2 lots of signals at the BBC. There were VITS - Video Insertion Test Signals and SITS - Studio Insertion Test Signals. The Transmission Internal Test Signals were stopped by the Director General's Wife.

How about including PLUGE as well? It does have it's uses.

Cheers,

Steve P.

[ppppenguin]

Well done! The concept is pretty simple. A large-ish flash memory which stores the whole image or sequence of images as literal data; a counter to read out the data; a DAC. Then something a bit clever to interface this lot to a PC in order to write the data. Also needs software to format the data and download it though that may well be done by the FML test card maker.

Though the concept is simple the problems are all in the detail. There's quite a lot of that to get right.

What sampling frequency are you using? 12MHz like the RT Russell or something a bit higher? What have you used for the USB interface?

[Parabola]

Thanks for the positive responses. It's certainly possible that I may consider some limited production if I get to the point where it's a further developed product. I'd just need to get my a*se in gear and get some PCBs fabricated commercially.

Originally Posted by Tazman1966

Facinating stuff mister! I imagine that, say, BBC type VITS could be inserted too?

Yep, no reason why not.

Originally Posted by ppppenguin

Well done!

Thanks! You know only too well I'm not a 'natural' when it comes to logic design!

Originally Posted by ppppenguin

Though the concept is simple the problems are all in the detail. There's quite a lot of that to get right.

Absolutely. The biggest problem has been creating a 19 bit counter that's completely glitch free, syncronous (rather than ripple) and can have all the bits reset at exactly the same instant. This resulted in not needing any data latching on the PROM output. It's fair to say some of the counter IC data sheets are not altogether accurate!

Originally Posted by ppppenguin

What sampling frequency are you using? 12MHz like the RT Russell or something a bit higher?

12MHz sampling. I started thinking I'd use 12.5MHz, but if 12 was good enough for Richard Russell it's good enough for me. I also needed to try not to go faster than 70ns or it gets difficult and more expensive to source memory that my PROM programmer can use!

Originally Posted by ppppenguin

What have you used for the USB interface?

Aha! Well, I have a plan for that one if I get to Phase 3, but as I'm going to try and make it all work without any kind of micro or PIC I'm keeping quiet for the time being for fear of total ridicule until I've given it a go. If I should fail with Phase 3, or it becomes too complex to implement, I may adopt a system of plug in 'cartridges' containing PROMs with different images / pages - or even investigate using compact flash cards instead of PROMs / RAM

Finally, as all the parts are available in surface mount versions, it could be built a lot smaller!

Parabola

[ppppenguin]

Originally Posted by Parabola

Absolutely. The biggest problem has been creating a 19 bit counter that's completely glitch free, syncronous (rather than ripple) and can have all the bits reset at exactly the same instant. This resulted in not needing any data latching on the PROM output. It's fair to say some of the counter IC data sheets are not altogether accurate

Designing 100% reliable fully synchronous counters is very easy if you know the tricks of the trade. Happy to do the synchronous logic tutorial but open forum is not the right place for that. Best done in person, especially as you're not far from me. There's no maths byond addition and subtraction.

What you really want is a small CPLD. A synchronous 19 bit counter is then expressed in VHDL as follows. I've omitted the declarations for simplicity. This beats soldering every time. Sorry about lack of indents. Can't seem to get them to work in the forum.

process (CK) begin
if rising_edge(CK) then

if RESET then MYCOUNT <= "000000000000000000";
else MYCOUNT<= MYCOUNT + 1;
end if;

end if;
end process;

Should be possible to get a Xilinx Coolrunner evaluation kit quite cheaply.

Alternatively in CMOS etc the only sensible way to do it is with '163 chips. As usual there's a couple of right and many wrong ways to use them. I cringe when I look back at some of my early digital logic design attempts, relying on accurately matched propagation delays and the odd capacitor to slug spikes.

Originally Posted by Parabola

12MHz sampling. I started thinking I'd use 12.5MHz, but if 12 was good enough for Richard Russell it's good enough for me. I also needed to try not to go faster than 70ns or it gets difficult and more expensive to source memory that my PROM programmer can use!

I think RR used 12MHz because it allowed a convenient size PROM and ran a speed that was friendly to the PROM. It's pretty marginal for full bandwidth TV. 13.5MHz is the international standard for SDTV. Accurate filtering after the DAC is difficult at these frequencies. There are simple methods to use a pair of slower PROMs to work effectively as one higher speed unit. Again I'm happy to show you the tricks of the trade.

Amazingly I didn't learn these simple methods at uni and struggled with logic design for a year or so after graduating. Then a very talented engineer from New Zealand joined the company I was working for. He showed me the tricks and it was a true revelation.

[Duke_Nukem]

When designing this, bear in mind who you intend to build it. If it were something I'd be building just for me I'd certainly use programmable logic ... darn I feel old, tis over 10 years since I used a CPLD or Xlinx (in a PC-ISA-to-6812 processor bridge , anyone remember ISA!) and the GUI based S/W it came with was a doddle to use. However if it is for others to build too then you need to stick as much as possible to "dumber" devices that don't require costly programmers (since this is likely to be a one-off for them) and which may also be difficult to source. Also there is the issue with finding non-surface-mount versions.

If intention is for building by others I'd be tempted to go no further than a PIC micro. There are cheap and I think can be programmed via the USB port; I reckon it could do the teletext part (you could download pages on the fly from a PC), program an external flash for the testcard(s) and handle the sync generation side of things. Remember, the ZX80 used its Z80 processor as part of the display refresh and a PIC micro these days is way more powerful.

I can see a difficulty in generating a colour burst though - wouldn't it would force a design based around 8.87xxxMHz which would conflict with trying to make 5.5MHz test card bars?

-------
As an aside, a PIC micro could also do a simple test card - I doubt it could do something detailed like Test Card C but definitely something with blocks in different shades, vertical bars as well as an audio tone - a simple tiny battery powered test generator that'd be more than enough whilst basically getting a set up and running.
With the addition of one or two switches you could make a tweakable test card (for example switching on/off a white vertical bar at the left of the image which if the tv's video bandwidth isn't up to scratch can affect the leading edge of the line sync causing picture shift)
(Perhaps a subject for a separate thread)
-------

TTFN,
Jon

[Parabola]

Originally Posted by ppppenguin

What you really want is a small CPLD.

I knew you'd say that! I know you find my adhesion to TTL/CMOS unfathomable

Originally Posted by ppppenguin

Should be possible to get a Xilinx Coolrunner evaluation kit quite cheaply.

But then I'd have to learn how to program it, and I'm monumentally lazy. I also think that would make any future 'production' cost more. At the moment, all the bits I've used really are bargain basement.

Originally Posted by ppppenguin

Alternatively in CMOS etc the only sensible way to do it is with '163 chips.

Nah! On this one I'm going to dare to fail to concur with your assertion! There was a reason I ruled out '163s at an early stage.

Originally Posted by ppppenguin

I think RR used 12MHz because it allowed a convenient size PROM and ran a speed that was friendly to the PROM. It's pretty marginal for full bandwidth TV. 13.5MHz is the international standard for SDTV.

I know what you're saying, but I reasoned that 720 pixels at 625 was fine for a still image. All the resolution bars are produced correctly. I could push it up to 13.5 (may need 55ns PROMs) if you think it would add a certain something I've overlooked

Parabola

[Parabola]

Originally Posted by Duke_Nukem

When designing this, bear in mind who you intend to build it....

Absolutley agree with what you say. Also need to bear in mind what the device ultimately needs to achieve and the final cost. The aim being cheap and as functional as it needs to be. If it were for generating HDTV formats or Digital then obviously it would be Xilinx time and messing with TTL/CMOS would be completely foolhardy.

Originally Posted by Duke_Nukem

If intention is for building by others I'd be tempted to go no further than a PIC micro.

Again, agreed. However, I'm trying to avoid even getting as complex as a PIC, as my reticence to learn how to program it will kick in again! If I can do it in hardware alone and avoid firmware I'll always tend to migrate that way.

Originally Posted by Duke_Nukem

I can see a difficulty in generating a colour burst though - wouldn't it would force a design based around 8.87xxxMHz which would conflict with trying to make 5.5MHz test card bars?

Dunno. But, RR 'encoded' the whole lot into (or onto) the image, Burst and U V components. Therefore, I think that get's around that particular issue.

Parabola

[ppppenguin]

Originally Posted by Parabola

Dunno. But, RR 'encoded' the whole lot into (or onto) the image, Burst and U V components. Therefore, I think that get's around that particular issue.

RR coded 8 full fields of PAL as literal values and read them out of a PROM. Clock frequency not important, provided you allow for it when coding the data.

[Duke_Nukem]

What I was meaning is that to generate the 4.43361875MHz colour burst signal - which needs to be accurate - a design based on a counter driving a ROM/flash would need to clock at 2x, 4x, etc that frequency.

... but I reasoned that 720 pixels at 625 was fine...

It certainly is. Thats DVD resolution.

TTFN,
Jon

[Parabola]

Actually, I'm wrong (as usual). Having just been trying to bash my various scribbled notes together into something for future reference and sorting out the multitude of different sized TCF images that have been through Photoshop on the way to the final ROM image, I realise that my quoted 720 pixel figure for the active line at 625 was part of earlier calculations for a theoretical faster clock speed The active line pixel count with 625 lines at 12MHz is 625 pixels (square pixels). However, the total count of 768 for the entire line (64uS) is correct. Sorry

Maybe I will up the clock speed a bit then. Thanks to all for the input.

Parabola

[Boom]

Excellent. I'm jumping the gun I know but are there any problems envisaged stitching a modulator on. Especially for System A?

Dave

[ppppenguin]

Originally Posted by Duke_Nukem

What I was meaning is that to generate the 4.43361875MHz colour burst signal - which needs to be accurate - a design based on a counter driving a ROM/flash would need to clock at 2x, 4x, etc that frequency.

No need to do that at all. You just store the whole waveform, subcarrier and all. Unfortunately PAL needs 8 fields of storage to get an integer number of subcarrier cycles. NTSC needs only 4 fields.

If you are doing a general purpose PAL/NTSC coder it's very simple to make subcarrier from any arbitrary clock frequency using a discrete time oscillator. It takes a little fangling to get a DTO to do a relationship that isn't exactly x/2^n but that isn't too hard. I usually use a 32 bit adder/accumulator with reset to zero every 8 fields. This gives a phase jump of well under 0.1 degrees.

[VideoJunkyard]

I've only just picked up this thread and you can put me down for one too. BUT - how about adding a 525 NTSC option too..? Is that feasable in your design?

[Duke_Nukem]

No need to do that at all.

I'm still not quite getting it. Attached image shows 4.43MHz "analog" signal and above it an attempt to generate the same waveform by encoding the signal at 12MHz. OK, the sampled version would be subsequently filtered to some degree but would would be the effect on the colour on a TV?

Anyhow, colour is the work of the devil, I'm sticking with proper (i.e B&W) tellies

@Paranola, don't worry about needing "square" pixels. The sample rate mearly needs to be a multiple of the frame rate times the line def. The final display is 4:3 but typical digital streams are 5:4 (DV, DVD's etc) and in the cases of channels such as ITV4 16:9 widescreen is broadcast as a dreadful 540(ish) by 576 pixels!

TTFN,
Jon

[Hybrid tellies]

Looks interesting. Is it possible to include accurate timing pulses ones which VCR's can sync up to. All three of our VCR's are now without these teletext timing signals now analogue has been switched off in this area and the clock has to be set manually everytime you want to do a timed recording of the Freeview box. Sorry if this is taken things a little off topic.

[ppppenguin]

Originally Posted by Hybrid tellies

Looks interesting. Is it possible to include accurate timing pulses ones which VCR's can sync up to.

That's a whole different game. The original prject is for a static image hence the teletext will also be static. Generating full teletext, with a clock running etc, is a more complex job. Undoubtedly possible but a lot more work. The work done by Fabrice Bellard and others using a PC VGA output as an arbitrary waveform generator might well be useful. He has achieved, for example, a full spec DVB modulated signal this way.

I'm still not quite getting it. Attached image shows 4.43MHz "analog" signal and above it an attempt to generate the same waveform by encoding the signal at 12MHz. OK, the sampled version would be subsequently filtered to some degree but would would be the effect on the colour on a TV?

The reconstruction filter after the DAC puts the signal back together. When the sampling frequency is only just over the Nyquist limit (say 13.5MHz sampling a 4.43MHz SC) the sample sequence will usually look very odd.

Doing a colour coder at 13.5MHz is a bit tricky. For one thing when you do the multiplications for U and V modulators you almost inevitably get signals that go over the Nyquist limit. It's much easier at 27MHz.

[Parabola]

Originally Posted by Boom

.....are there any problems envisaged stitching a modulator on....

Shouldn't be, it's only standard baseband video out.

Originally Posted by VideoJunkyard

.....how about adding a 525 NTSC option too..? Is that feasable in your design?

If I get it generating PAL, then it's certainly feasible to do NTSC. However, for me, personally, that's not a priority because I have nothing that needs an NTSC signal, nor do I plan to have in future. There are several paths this project could now take, with a lot depending on whether I'm working on something strictly for my own use (as when this thread began), or whether I'm aiming for something with any market potential based an apparent demand. The addition of 525 NTSC, for instance, would almost certainly fall into the latter scenario.

People run such different sets and equipment and have varying needs for different standards, even mono only vs (Jon's work of the devil) colour, that it would be a shame to end up with something that does everything but sweep the floor and conseqently comes with a matchingly large price tag! Everyone that knows me knows I'm a cheapskate and so tend to start from that perspective

Ok, back to the pile of data sheets...

Parabola