Teletext Revival, Part 2: Making It Work [Updated]


This article is a continuation of my series on my attempts to bring teletext back to my TV, you can find the previous part here.

Update: PCB files now available at the bottom of this article.

Update 2: Project depreciated, but see bottom of this article for a replacement project which requires no hardware.

I left off last time not knowing quite how to make things work, given my utter inability to write any assembly code or build from scratch anything resembling a complex analogue circuit able to work with PAL TV signals. Here’s what happened next…

Enter Alistair Buxton and his github account, and subsequently phoyd from Hackerspace Bremen, and the “avr-teletext” project. Finally! Something I could use! Minimal assembly code which appears to work correctly and sensible, readable AVR C code which despite my inexperience I can just about muster the grey matter to understand and a circuit which is both simple and good fun to build. As I stumbled across these guys, during one of my often and numerous searches for information on how to accomplish this stuff, I scrambled to obtain the necessary parts. I chose phoyd’s schematic as it’s marginally more simple, using an LED rather than an inverter for the output stage. But what does it look like? What does it do? Well…

breadprotocropPrototype 1: The breadboard. Messy, but functional.

PiTextPrototype 2: Humble Pi board. Less messy, more functional.

In the first picture, you can see my first attempt. It was breadboard based and it was a pain to debug because wires were loose and the main chip, the AVR (an Atmega328p to be specific) was difficult to remove without disturbing everything and it was too prone to breaking. It worked, however, so that was a good start. It’s at this point I should mention that my very first tests with this thing were pretty much a bust. Why? Not the circuit or the firmware, but what I was trying to view the results on. One of these…

ezcapEzCap/EasyCap USB 2.0 capture stick.

Apparently mine is a fake. But real or not, this device doesn’t seem to be able to pick up the output from this teletext inserter, and I don’t think it’s the inserter’s fault. Regardless, I knew I’d have to get something more suited to the job, so I trawled eBay for something a bit more upmarket. Mistake number two. I ordered myself what appeared to be the bargain of the century, a triple tuner card which supports analogue TV, digital DVB-T and digital DVB-S for satellite. Not that I needed them for this task, but who knows? It never hurts to have more features than you need right now. Alas, what seemed to be a perfectly normal PCI card was, in fact, a special PCI card designed for “Blue Magic” PCI slots from the early 2000s, which have multiple PCI lanes wired to a single slot. This means that only one part of the card can function in a normal PCI slot. Thankfully, though my purchase wasn’t nearly the bargain I’d hoped for, the part which worked just so happened to be the analogue capture. Brilliant. I hacked up a cable from an old CDROM audio cable, for you see the composite connector is internal, and I set to work.

Rather handily, this particular card is boasting a Philips SAA7134 chipset, which although it doesn’t seem to enjoy working in Windows 7, in 64bit at least, is supported in DScaler and actually comes with a neat little debugging feature which really made itself useful in making this work. A VBI debugging display. What this means is that whilst the VBI data this teletext inserter outputs to is normally above the picture and therefore invisible to a casual viewer, the driver will conveniently place a copy of the VBI within the viewable area, like so:

vbiCapture card VBI debugging display.

Without this, I’d have very little idea whether the circuit was working, or not working, or half working, or working in some way that I hadn’t anticipated because it would be above the visible display (in terms of how it would appear on a TV screen, which is replicated in the capture). I’d actually managed to sort of make this happen with the EzCap stick by running the circuit at 3.3v instead of the normal 5v, but in doing so I might’ve been causing some other problem such as causing the output voltage to be too low for the signal to be decoded on the TV.

vlcsnap-2013-04-16-21h38m59s182Barely visible at the very top of the screen, the bottom of the VBI pokes out.

So now I’ve figured out how to make it actually do something, what can it do? Being a teletext inserter, that’s what it’s good at, but let’s see some pictures. A couple of test pages…

TNXT-Test1Test page 100.

TNXT-Test2Test page 101. Experimenting with multiple pages.

I2C-Data-TestAfter assembly on the Humble Pi board, immediately before my SD card gave up on life.

Raspberry Pi I2C control test. Displayed in “mix” mode, the Python script can be seen running behind the teletext.

PiPyTextTestPureThe same page, but without mix mode, this is how teletext pages were usually viewed.

Now, up until this point, I’ve only been able to make one of the two modes in Alistair and phoyd’s code work. There are two modes, one is a “console” mode which acts very much like a terminal console. You write things to it via I2C and they show up on screen. This is a nice feature to have, but it wasn’t really used much in real teletext services because there were so many pages to transmit and to prevent all of the other pages becoming too slow to load, you could only send a single page a certain number of times within a given period. Features like subtitles, “Now and Next” TV listings and news/sports score bulletins did work like this though, updating far more often than any other page would need to update.

The problem, however, is that for some reason (which, in fairness, is likely to be a fault of my own), I can’t get the more traditional mode to work. This mode would be fed by a sequence of pages from the Pi, or other connected device, which would appear as a complete teletext service, containing many magazines, pages within those magazines, and subpages within those pages. I have some thoughts on how to make this work, but more experimentation is required.

I couldn’t let this stop me from doing something, though, so I took a look at the hardware and how to make it a little more befitting of our data-transmission veteran. I decided that it would be nice to create an actual thing, a proper teletext insertion device, one which wasn’t a mangled mess of wires and bits on what was still essentially a piece of stripboard, albeit one in the shape of a Raspberry Pi. I’d always wanted to create a PCB of my own, so I tried to refresh my memory on what I’d learnt back in school about how to etch one myself. Having reminded myself, I decided it was too much of a faff and I wanted a more professional end product, so I began to research potential PCB manufacturers. Turns out, having a PCB made is expensive. Very expensive, if you go about it the traditional way, where you pay setup fees which eventually become insignificant if you’re planning to have hundreds, thousands or even millions of boards etched for you. However, some enterprising PCB makers have worked out that they can provide hobbyists with small runs of project boards for bargain basement prices. I believe they add your designs to leftover areas in other jobs, but I’m not certain. Nevertheless, the services exist, and for that I’m thankful. There are several popular ones, I chose ITEAD Studio, who will do the works for an incredibly cheap price. My design takes up less than 5x5cm, so it’s just $1 per board for a quantity of 10! They’ll do coloured boards, double-sided, with silkscreen, even stuff like vias, it’s ridiculous, but very very awesome. It took them about 2 weeks to send me my finished boards, it’ll vary from country to country and probably by their workload, but given the price I really can’t argue with that.

Now, having decided where to buy, I needed to actually create the board layout. I tried a couple of different PCB design applications and I settled on Fritzing. I had planned to purchase my PCBs from them, there’s even a handy little order button in the designer, but given that I’m skint and ITEAD were cheaper and more flexible, I chose to go with them instead. Before I had, though, I’d got used to finding my way around the Fritzing designer, so I stuck with it. It’s a little limited on the parts available within it to draw out your design with, but you can get by with simple projects. It also exports to standard Gerber files, which is an industry standard, so you don’t have to order from Fritzing. It’s a cool little application, you can design in three modes; breadboard, schematic and PCB, so you can get started at whichever level you feel comfortable with. I should point out that although it’s supposed to be able to translate your design from one mode to the other automatically, it does a terrible job of it, so you’ll have to be prepared to remodel your design in several modes if you don’t skip right to the PCB level and ignore the other two modes like I did. It’s been a little while since we’ve had any pictures, so here’s one of the Fritzing application with my design in it:


It looks more complex than it is, don’t be put off by appearances, it’s almost cathartic designing a PCB. There some things you have to watch out for, like routing traces around things, it’s a fun puzzle (until you realise you need to put one last trace in, right at the end, and you have no room for it so you either have to rework half your board or just skip the trace, even if it means losing a feature). Fritzing will try and help you out here, there are built in checks you can run to make sure your design isn’t hideously unsuitable for production. They’re not flawless, but they do give you a pretty good clue if something’s horribly wrong with your design. What they won’t do, though, is tell you if your circuit is going to work, only whether you’ve put pins and traces too close together or if several traces are crossing paths when they shouldn’t be, so do make sure you check your circuit’s working before you translate it and commit it to PCB. There are a couple of bugs in my design which you might spot in the image, I’ll leave that as a fun little “spot the mistake” game for anybody who cares to have a gander.

But enough waffle, let’s see what all this actually produced! I got my boards a few weeks ago, they look great, at first glance I haven’t spotted any glaring faults with them, everything is pretty much exactly as I specified in my Gerber files. The silkscreen is sharp and accurate (even including a misplaced silkscreen marker I forgot to delete right under J3), the holes were drilled just as they should be, the pads were tinned and everything was nice and clean. So I present to you TNXT v1.0!



Pretty, ain’t it? I get to check it off my bucket list, too. You’ll notice they do actually print a batch number on the board, that wasn’t part of my design, but they were nice enough to put it underneath the AVR, so it won’t be visible when assembled. I can live with that for a dollar a board.

There are services which for a fee will assemble boards for your too, but that seemed like an unnecessary and extravagant expense, and more trouble than I needed to go to for my very small run of boards, so I opted to assemble them myself. I’d sourced the components before, for my earlier prototypes, so I already had those, all I had to do was solder them to the board. My soldering skills are not what you would expect from an expert and 40 year veteran of electronics engineering, primarily because I’m neither an expert, nor 40 years experienced, but I got along just fine. It’s all based on large through-hole components, so it’s no big deal if you know which end of a soldering iron to hold. Here’s what it looks like finished:


Here’s what it looks like finished and connected to a host Raspberry Pi:


Oh, I love it when a plan comes together. I assembled it only today, in fact, my very first one, and to my surprise, relief and no small measure of excitement, the damn thing works! Apparently I don’t fail at basic PCB design, so that’s encouraging. This design actually has a programming header on it, so I can solder the microprocessor to the board, no more prying out chips with screwdrivers, needles and whatever else on my desk that’ll fit. That’s actually quite an important thing to add, both in general and for this particular project, because I don’t have a “final” version of the firmware yet. In fact, after I assembled this one, I realised that I’d installed a chip with a very broken firmware on it, and after a moment of panic I remembered that I’d had the foresight to include an ISP header. Yay for planning ahead. One quick flash later, using an Arduino as an ISP programmer, and I was in business. It’s only a test firmware I’m running at the moment, but it does enough to show me that it’s working.

That is, it shows me that it’s working on my capture card. I tested on a Samsung LCD TV and it doesn’t actually appear to behave how I’d expect it to. This could be a function of the TV’s teletext decoder, however, perhaps there’s an issue with how and when it expects to get a given page, or maybe there’s something it’s not getting that it expects. Still, I can fix that in due course. It’s a vast improvement from the “No teletext service” or some similar error it had given me previously, when it point blank refused to acknowledge that there was a signal and as a result absolutely refused to enter teletext mode at all. Progress!

This is the point at which I’m going to have to grit my teeth and return to the uncomfortable, desolate, unforgiving world of software. There are no longer any hardware tasks to complete. It’s done, it’s there, it’s waiting for me to actually make it do things. I’ll give it my best shot, but I can’t guarantee it’ll be pretty. Another day, though. For now I shall bask in the warm afterglow of a properly completed piece of hardware.

Taking stock, it’s pretty exciting that this device is cheap and really quite easy to build, fairly easy to debug and modify, and it can add teletext to literally anything with a composite output. As in the pictures above, I’ve used a Dreamcast and a Raspberry Pi, but it could be anything from a Commodore 64 or ZX Spectrum to a full PC, perhaps a DVD player or a satellite tuner box. Anything which produces a composite video signal is enough to provide this circuit with a sync signal to lock on to and modify, inserting the teletext within the video signal. Of course, you’ll need some data for it to display, but this could be provided by a separate device, even just an Arduino with a network board, it doesn’t have to have video as long as there’s a video signal somewhere nearby to sync with. It could bring life back to the millions of TV sets which support teletext but may never have seen such a thing again. Best of all, it gives us another way to preserve a historic and indeed iconic piece of technology which served many, many millions of people very well throughout its lifespan.

cheefax goodbyeGoodbye Ceefax, a farewell spoof by @gralefit

Still, that’s why we’re here, to make sure it doesn’t die forever, so I’m going to continue bashing away at this thing until it does stuff properly. I’ll release the files so that you can build your own board now that I know it works properly, I’m not sure exactly when, but hopefully soon, I’ll try and work out a few mistakes, almost-mistakes and bugs and whatnot, and then I’ll upload them for all to share. Until then, let’s all take a moment to offer thanks and pay our respects.

Cheers Mr Buxton and phoyd, without your work, this wouldn’t have happened.

Teletext is dead, long live teletext!

Update: I’ve rejigged my PCB files, and I think they’re ready for public consumption! You can get them here. I have to say that I have not yet ordered boards with this slightly reworked design, but I’m not aware of any reason why it should be electrically broken, it looks fine, but do double check if you intend to etch boards based on it. I’ve added some extra silkscreen, it’s perhaps a little crowded, but I thought it’d be a little less cryptic. The breadboard view isn’t complete, it was just too much of a pain to connect it all up in the Fritzing editor, but the schematic is complete, and the PCB view is what I’ve put the most work into. Hope you all find these files useful.

Update 2: The link to the PCB files is now broken, but this project is no longer necessary, because the original designer of the circuit has released code to generate the necessary signals directly on the Pi’s composite output. For more info, see and its sister project for feeding in teletext magazine data Happy preservation!


About Author


  1. Pingback: Raspberry Pi learns the lost art of Teletext

  2. Pingback: Raspberry Pi learns the lost art of Teletext - RaspberryPiBoards

  3. Pingback: rndm(mod) » Raspberry Pi learns the lost art of Teletext

  4. Pingback: Raspberry Pi learns the lost art of Teletext | Blog of MPRosa

  5. Pingback: Reviving Teletext with a #RaspberryPi | Raspberry PiPod

  6. Pingback: Raspberry Pi learns the lost art of Teletext | Make, Electronics projects, electronic Circuits, DIY projects, Microcontroller Projects -

  7. Pingback: Raspberry Pi aprende el arte perdido de teletexto - | Indagadores |Seguridad informatica |Seguridad en internet

  8. Pingback: Raspberry Pi TeleText Hack #piday #raspberrypi @Raspberry_Pi « adafruit industries blog

  9. Pingback: ส่ง Teletext ไปที่โทรทัศน์ | Raspberry Pi Thailand

  10. I have made a circuit myself that uses an FPGA to generate teletext, it reads the pages off an SD card into an SRAM. I used a clock multiplier/divider/PLL chip to create the 6.9375MHz clock. I also have created some level 2.5 teletext pages (which took 2 weeks of studing the spec!) and it all works great!

  11. Please could I have the source code and files? The link doesn’t work, I know, and I also realise that there is a zero parts version (I’m using it) but I would like to make a ‘proper’ teletext inserter. I can leave my email address

Leave A Reply

Welcome, guest maybe you should register or login