== tldr == Tools: edit.tf raspi-teletext Python Raspberry Pi 1 & 2 Spec: http://www.etsi.org/deliver/etsi_i_ets/300700_300799/300706/01_60/ets_300706e01p.pdf Teletext character reference: http://www.galax.xyz/TELETEXT/CHARSET.HTM == Theory == Wikipedia: "A teletext page comprises one or more frames, each containing a screen-full of text. The pages are sent out one after the other in a continual loop. When the user requests a particular page the decoder simply waits for it to be sent, and then captures it for display. In order to keep the delays reasonably short, services typically only transmit a few hundred frames in total. Even with this limited number, waits can be up to 30 seconds, although teletext broadcasters can control the speed and priority with which various pages are broadcast." -> If it's one-page loop, we should get FPS instead of SPF. Do we have a demo-platform? == Early history == I had been doing idle research on generating teletext for maybe a year. There have been RPi-based solutions like http://hackaday.com/2013/07/07/raspberry-pi-learns-the-lost-art-of-teletext/, but it involved a bit more soldering and buying parts so it's not really my thing. Then there was http://al.robotfuzz.com/generating-teletext-in-software/ which uses regular GPU. I was kinda prepared to do stuff this way, even bought VGA and SCART-cables to wait for soldering, but never got around to it. I didn't have TV at the time, so I thought about buying an old analog TV-card. And I did, but never installed it. Few days after ASM'15 I found https://github.com/ali1234/raspi-teletext, which requires no extra hardware. Everything is good, time to code. == Drawing teletext == At first we found Cebratext via Helsingin Sanomat newsarticle about teletext art (http://www.hs.fi/kulttuuri/a1439258941294?jako=36cd375d69b347be256f5738ac312098&ref=irc). But few months before ASM we found out that it's actually Win16 software and it didn't work on 64bit Windows (it was fine-ish on WINE). There were alternatives, like wxTED, but edit.tf was HTML5 so we settled with that. Also, wxTED doesn't export raw-ish teletext-data, but slightly more human-readable stuff. Edit.tf has better outputs and url2raw.pl. == Generating teletext == raspi-teletext has it's own "it's working"-screen (https://www.modeemi.fi/~ninnnu/raspi-tele.jpg), and out-of-the box it supports receiving deliverable data from outside via stdin (./teletext -) so that's what I went with. But before all that I added a framecounter to the out-of-the-box demo to measure FPS. At first it looked like 9-10 but eventually I went with 7. Spec says that 12 would be maximum, 24 if we manage to use all specced bandwidth (see "future"). Since the FPS was already low and I like Python, I chose Python as the demo-language (unlike the rest of the group, I still don't prefer JS). However, as we can see with the snake-sine, I still had performance issues. For some reason converting PyGame-surface to my internal "bitmap" was too slow. It was the last week, didn't bother. Plasma was also ready, but it was 7 seconds per frame. Also ugly. It just doesn't work with 7 colors. Maybe when (if) we upgrade to level 3.5... The resolution* isn't an issue as such with teletext, but the control characters are a bit of hassle. You can only either draw a character xor change foreground color (and switch from alphanumeric to graphics, or vice versa) xor set background color as foreground color per character. With hold graphics mode on (default is release), the most recent character stays when color changes. Rimina says that spoofing MTV3's page 100 (credits) sucked... In generated effects I didn't bother with any fancy background color tricks in effects, so they were used only for manual graphics. Also a minor fun issue was inserting parity bit to each character. Trivial stuff but it caused fun issues when forgotten or ignored (I thought edit.tf url2raw would insert parity. It didn't). Examples: http://koti.kapsi.fi/rimina/tests/scrot/telegroup.jpg https://modeemi.fi/~ninnnu/delfiini.jpg == Future == This was Teletext level 1. Level 2 is kinda boring (more charsets), but Level 3 and 3.5 are fun (higher resolution, redefineable palette). Level 4 and 5 would be fun (320x200 graphics), but Wikipedia claims that no TV supports them. Even level 3 is from 2000... Also, since Assembly Sunday 3AM is best time to get new ideas, I opened the spec again and it seems that teletext-data can be delivered also at the bottom of the video signal, bringing the bandwidth from 16 packets/frame to 31 packets/frame, upping the FPS, too, since one page requires at least 25 packets. If we add features from Level 3.5, 29 packets. However, at least with raspi-teletext using the bottom VBI-lines is at the very least tricky. And 6 hours after recording the video (thanks, Exca), I skimmed the sources of raspi-teletext for last bit of finetuning, and found curious usleeps (0.02sec), although they may be for technical reasons. Maybe there's space for optimization... Also, the delivery-layer has cache that delays stuff by few seconds. Part of the reason why I didn't bother with sync. *) Btw, the demo has misinformation. The text resolution is 40x23 + header, had off-by-one fail when looking up the resolution from edit.tf. Resolution for graphics resolution should be correct since one character is wasted to setting the gfx-mode. Anyway, close 'nuf. "Resolution is low".