
Teletext for Raspberry Pi - lawl
https://github.com/ali1234/raspi-teletext
======
Famicoman
My friend did something similar back in 2013,
[http://hackaday.com/2013/07/07/raspberry-pi-learns-the-
lost-...](http://hackaday.com/2013/07/07/raspberry-pi-learns-the-lost-art-of-
teletext/)

This project seems to have gotten around the hardware quirk though.

~~~
ali1234
I wrote the AVR code for that!

[http://github.com/ali1234/avr-teletext](http://github.com/ali1234/avr-
teletext)

------
alexkus
Mikefax anyone?

(Ha, seems I've mentioned Mikefax a while ago...
[https://news.ycombinator.com/item?id=4687527](https://news.ycombinator.com/item?id=4687527)
)

~~~
impomatic
alexkus: off topic, but would you mind sending me an email about RM380Z Robot
Arena? :-) gmail digital.wilderness

(sorry, I couldn't figure out how else to contact you)

------
lovelearning
From the code, BCM2835 peripherals pdf and [1], I gather that this is writing
to the pixelvalve1 region of the Videocore to change PAL resolution. But
there's nothing about this in the Videocore docs. Anybody here knows where
this is documented and what pixelvalve0 in [1] is?

[1]: [https://github.com/msperl/rpi-
registers/blob/master/md/READM...](https://github.com/msperl/rpi-
registers/blob/master/md/README.md)

~~~
ali1234
It isn't documented. I figured it out by looking at the github you linked and
then looking at register values and trying to guess what they mean.

About the pixel valves.

The chip has three pixel valves. One is for DSI0, one is for DSI1, and the
final one (pixel valve 2) is shared between HDMI and composite.

~~~
lovelearning
Thank you for the info, Alistair! Nice work.

------
rnhmjoj
Why new tv can't handle it?

~~~
mschuster91
They can, just set them to analog TV (only works if you're in Europe, though).

~~~
bestham
"UPDATE: This demo will also crash modern LCD TV's teletext decoder. It's
because the demo sends the same packet over and over and new TVs can't handle
it..."

It has nothing to do with digital or analog, it't that most modern TTV
decoders don't like the format that this app sends data in.

~~~
jamesbrownuhh
It's a bit more complicated than that - as with all matters pertaining to
agreed broadcast standards, the demo is sending data in the correct format but
in a way which you would be unlikely to see in 'normal' use, hence the code
drives a truck load of edge cases through the various TV manufacturers'
implementation of the spec, and some of them fall over and crash hard.

To explain it in a bit more detail:

Teletext works by sending 40-byte data packets in the unused screen lines of
an analogue television signal known as the 'vertical blanking interval' \-
basically a part of the TV signal where no picture is normally present,
included only for timing purposes and to allow an old-style CRT monitor to
drag the electron beam down from the bottom of the screen back up to the top
again. (Oldskool console programmers will know all about this, also known as
the flyback period.)

There are only so many usable screen lines in that period - say around 16. So
the maximum number of data packets that can be sent via teletext is 16 packets
per field, times 50 fields per second (PAL) = 800 packets.

A teletext page is usually 25 lines of these 40-byte data packets - although
it's not required to send every line, as a line that is not sent is assumed to
be blank - quite common between paragraphs. This will become important later.
But assume 27 packets per page, maybe a few more or less depending on page
content.

That means a typical VBI period, at absolute top speed, can carry maybe 1.3
pages per frame. (A page is roughly 1K in size - 25x40 bytes, remember.) So
this is all pretty low speed stuff, and the TV manufacturers generally have
plenty of time during the course of each picture field/frame to process these
pages and do whatever they want to do.

Something else which will become important later - the transmission protocol
of these pages is such that a page is only considered to have been completely
received, when the next page (or indeed any other page) begins transmission.
So for example, in some implementations, the process of starting a new page
will trigger some software in the set to start assembling the packets that
have been received to form the completed old page.

As I said, all pretty low speed. Nothing too taxing. So all the TV has to cope
with, on a typical broadcast teletext service, is responding to a stream of
packets along the lines of:

I am starting page 100. Here is line 1. Here is line 2. Here is line 3. Here
is line 4. Here is line 5. Here is line 6. Here is line 7. (one fiftieth of a
second goes by) Here is line 8. Here is line 9. Here is line 10. Here is line
11. Here is line 12. (another fiftieth of a second passes). Here is line 13.
Here is line 15. Here is line 16. Here is line 17. Here is line 21. Here is
line 22. Here is line 23. (Another fiftieth of a second passes). Here is line
24. I am starting page 101. Here is line 1... and so on.

Plenty of time to process all that, typically very low speed. (I've only used
eight lines per field there, to give a more realistic example of what a 'real'
teletext service transmits.)

So, clearly, a regular teletext service obviously takes a certain amount of
time to transmit each page, which gives a regular teletext receiver a good
amount of time to process it all. And teletext services in general don't
transmit blank pages. Not because they can't or shouldn't, but because there's
no point in doing so.

So here's where it gets interesting. This proof-of-concept code is ONLY
sending 'here is a page' commands (also known as headers, or row zero packets)
- and because no page content is being transmitted, that single 'here is a
page' command is all that is needed to describe a blank page.

TV sees 'Here is page 100. Here is page 100. Here is page 100. Here is page
100. Here is page 100. Here is page 100. Here is page 100. Here is page
100...' and so on.

So if these pages are being interpreted by a TV's code, rather than hard-wired
hardware, suddenly it has a whole lot less time to process what it perceives
as a completed page, than it had before. Where under normal conditions the TV
would expect to be seeing maybe 10 or 20 pages per second, NOW every single
line of the VBI is describing a new page, so it's now seeing (e.g. 16 lines x
50 fields) = 800 pages every second.

If the software in the TV can't turn all those pages around in a fraction of
the time that it would normally have - something which it was almost certainly
never designed to do, and never tested against - then soon the code has fallen
on the floor with its pants down. There's either a massive series of race
conditions and collisions going on, or there's a stack filling up and
overflowing instantly, or whatever kind of showstopping fault can occur in a
situation like this. In some TVs the decoding process will fail silently, in
others there'll be other effects, and in some the various watchdog processes
in the set will eventually shut the TV off completely.

It's a beautiful example from the olden days - your code might work against
the generally accepted and agreed real-world usage of a specification, but can
it stand up to legal inputs which 'nobody would ever send' ?

And of course in a modern context, it does raise interesting possibilities -
could you compromise a TV just by having it tune to a 'specially crafted'
video signal? It might not be as hard as you'd think.

~~~
Cort3z
Wonder if this can be used maliciously. Sounds like a major security issue to
me.

~~~
TazeTSchnitzel
If it's a simple stack overflow or buffer overrun, then given that they're
plain binary data packets, it should be pretty easy to exploit.

~~~
mschuster91
800 packets/sec x 40 byte/packet = 32 kByte/sec data throughput. Plenty of
space for a nice exploit.

Heh, I wonder what happens if one could modify a DOCSIS modem to transmit on a
DVB channel - in theory you could compromise an entire house, or worse, an
entire block (depending on where the DOCSIS concentrator filters out uplink
frequencies) by transmitting a fake DVB-C channel... it might even be better
to look for problems in the DVB EPG code, because TV PC software can be better
debugged.

------
hayksaakian
given that most TVs support this type of thing, I wonder if there's anything
useful that could be built with the software.

~~~
rasz_pl
sure, you could build minitel :)

[https://en.wikipedia.org/wiki/Minitel](https://en.wikipedia.org/wiki/Minitel)

Teletext was big in the nineties in my country, serving more Classified Ads
than any other newspaper.

