Systèmes de Télétexte : re-création du service BBC CEEFAX

Télévision/vidéo
1

Bonjour à tous,

Un jeune anglais d’Irlande du nord recrée un service de télétexte fonctionnel à la norme BBC CEEFAX.
Un nombre limité de pages (infos à la une, météo, résultats football…) sont extraits de services sur Internet puis encodés à la norme télétexte.

Merci ! à Hamid-1 forum UK-VRR.

Cordialement
jhalphen

Télétexte CEEFAX fonctionnel :
cliquez sur les N° de pages de la télécommande ou entrez les chiffres au clavier (sur PC).

Historique du projet :

Revues de presse à propos du projet :

1 « J'aime »
2

Intéressant, merci Jérôme pour cette trouvaille !
Du temps où je travaillais chez Philips Semiconductors, nous avions développé une carte ISA pour PC et un soft qui permettait de générer des pages de télétexte et de les insérer sur n’importe quel signal vidéo 625 lignes.
Dommage que je n’en ai pas gardé une (mais c’était pour des PC XT ou AT des années 80).

3

Dans les années 1980 , il existait des générateurs de télétexte à destinations des hôtels pour diffuser des pages d’ informations affichables sur les téléviseurs des chambres ( infos touristiques, menus, services proposés par l’ hôtel, etc )

J’ en avais mis un système en démonstration dans la toute jeune mairie de la ville nouvelle du Vaudreuil au début de années 1980 pour permettre à la municipalité de diffuser un canal d’ infos sur le réseau de télévision par câbles de la ville .

Ce matériel a bien entendu disparu depuis et je n’ en ai pas gardé la documentation .

4

C’était un des buts du système Philips Semiconductors dont je parlais.
En ce qui nous concernait en France on s’en servait pour faire des démos dans des salons ou lors d’autres évènements quand il n’y avait pas encore d’émissions régulières en France.
Ce qui nous a valu quelques reproches de la part des inconditionnels d’Antiope / Didon (pour lequel nous avons aussi développé des circuits).

5

Il y a aussi cette solution:

qui grâce a la contribution de 2 sites web permet de recréer un signal V/UHF avec télétexte.
J’ai testé sur un TV en PAL l’illusion est parfaite.
En numérique sur satellite la BBC diffuse toujours les sous titres en télétexte et VLC sait les
extraire en lecture d’une capture en *.TS .

6

Oui mais y a-t-il un soft d’édition de pages de télétexte sur PC ou autre machine ?

7

Concernant hackTV et le teletexte il y a ceci dans la doc :

Teletext

Teletext is a digital information service transmitted within the VBI lines of
the video signal. Developed in the UK in the 1970s, it was used throughout
much of Europe until the end of analogue TV in the 2010s.

hacktv supports TTI files. The path can be either a single file or a
directory. All files in the directory will be loaded.

Raw packet sources are also supported with the raw: path name.
The input is expected to be 42 byte teletext packets. Use - for stdin.

Lines 7-22 and 320-335 are used, 16 lines per field.

Teletext support in hacktv is only compatible with 625 line PAL modes.
NTSC and SECAM variations exist and may be supported in the future.

hackTV prend en entrée un fichier « TTI », qui lui permet d’injecter dans le VBI des informations teletexte,

--teletext <path> Enable teletext output. (625 line modes only)

il faut donc trouver un logiciel de création de fichiers TTI, il y a un fichier PDF qui explique le format TTI :

8

Voici un éditeur de fichiers teletexte, au format TTI, ça génère des fichiers TTI que l’on peut donner en ligne de commande à hackTV, afin qu’il insère du teletexte dans les lignes VBI :

https://www.tt-edit.com/

il y a aussi ce logiciel :
https://teletext.wiki.zxnet.co.uk/wiki/QTeletextMaker

Et enfin une version web qui s’utilise en ligne :
https://zxnet.co.uk/teletext/editor/

9

Télévision : Disparu en France, le télétexte va fêter ses 45 ans en Suède (et il y est gaillard) (msn.com)

10

Autre solution par le RaspBerry.
https://www.raspberrypi.com/news/create-your-own-teletext-service/

The web? A bit overrated if you ask us. What was wrong with the beautiful teletext pages that came into our homes in the 1980s? The latest news, pop gossip, holiday bargains, and of course Digitiser. Did you think teletext was gone forever? Well, not only have a small group of dedicated archivists been saving and transcribing old teletext signals, but they have produced Raspberry Pi software that can generate the signals required to deliver those pages to your TV. Teletext is back! Here, we’ll show you how to get a teletext service running and even create your own pages.

11

Le télétexte existe toujours sur la SSR. Même via Hot Bird. Non crypté malgré l" écran noir.

12

Bonjour tous …

Je viens de faire le tour de « tout ce qui se dit sur le sujet », en commençant par les sources Britanniques (NMS, VBIT, Peterkvt80, SAAtruc etc) avant de finir par atterrir sur ce bon vieux forum !

A la base, je cherchais à clarifier les différences entre CEPT2 et CEPT3, fin d’améliorer la transcription d’un affichage initialement destiné à un terminal « Prestel » sur un Minitel … De fil en aiguille, je me retrouve à dérouler de nouveau cette pelote jusqu’à arriver à … Antiope.

J’ai toujours un décodeur Antiope Thomson (Decan 2002 TH ? cf https://www.tvnt.net/forum/antiope-et-didon-t21367-140.html ce sont grosso-modo les mêmes participants que sur ce thread !) pour lequel je ne désespère pas d’être capable, un jour, de fournir un signal vidéo qu’il pourrait éventuellement décoder.

J’avais bien vu, il y a quelque temps, que des farfelus bricolaient des décodeurs Ceefax, mais je n’avais pas trop creusé. Visiblement, leurs projets sont maintenant plutôt aboutis. D’après vous, les ‹ injecteurs › de type Raspi-Teletext ou VBit-pi3 pourraient-ils être en mesure de produire un signal approprié ? Je présume que des légères modifications sont à envisager (cadence du signal ?), mais, sur le principe, qu’en pensez-vous en première approche ?

Ou, si je le formule autrement, savez-vous comment produire, en 2024, un signal vidéo exploitable par un décodeur Antiope [sachant que l’option « extraction du signal depuis une VHS enregistrée sur une chaine Française antérieurement à 1995 » semble plus ou moins sans espoir de réussite] ?

13

Une piste serait d’utiliser le logiciel hacktv, qui est capable d’insérer dans les lignes VBI des données type téletexte, il faudrait demander à l’auteur de ce logiciel si l’insertion de données Antiope pourrait fonctionner

plus précisément dans la rubrique « issues », en postant un message en anglais pour faire cette suggestion de nouvelle fonctionnalité Antiope.

Teletext

Teletext is a digital information service transmitted within the VBI lines of
the video signal. Developed in the UK in the 1970s, it was used throughout
much of Europe until the end of analogue TV in the 2010s.

hacktv supports TTI files. The path can be either a single file or a
directory. All files in the directory will be loaded.

Raw packet sources are also supported with the raw: path name.
The input is expected to be 42 byte teletext packets. Use - for stdin.

Lines 7-22 and 320-335 are used, 16 lines per field.

Teletext support in hacktv is only compatible with 625 line PAL modes.
NTSC and SECAM variations exist and may be supported in the future.

Hacktv est capable de générer un signal vidéo analogique (PAL, SECAM, NTSC, noir et blanc), avec possiblité d’insérer du teletexte dans la zone VBI (en fournissant un fichier de données en paramètres du programme), le résultat peut être sauvegardé sur disque dur ou envoyé vers un périphérique SDR (radio logiciel), comme le hackRF ou un adaptateur USB3 vers VGA équipé d’une puce Fresco2000 (FL2000).

Si le développeur de hacktv possède un décodeur Antiope et qu’il est motivé alors ça devrait être possible.

Mais cela suppose d’être capable de générer en amont un fichier de pages Antiope, pouvant ensuite être passé en paramètre à hacktv, pour les insérer dans les lignes VBI.

La fiche wikipédia d’Antiope qui résume le procédé :

Antiope est défini en tant que « CCIR Teletext System A » dans ces documents :

14

On peut aussi lire la fiche wikipédia sur le vidéotex, car Antiope et minitel sont liés :

Des projets de serveurs minitel pour faire revivre un minitel existent.

15

Donc, 2 pistes à creuser pour le moment : HackTV et Raspi-Teletext. Après analyse, la solution hardware VBit-pi3 n’est pas applicable tant que l’on n’a pas identifiés un CI capable de générer un bit-rate à 6.2Mhz pour les 320 bits/ligne (les Anglais sont à 6.9Mhz pour 360bits/ligne) … tous ceux dont j’ai pu trouver le datasheet sont British-only.

==> Saurait-on provisionner un quartz à 6.203125 MHz (ou un multiple) pour faire une horloge adéquate ?

16

J’ai essayé d’explorer plus précisément l’actuel état de l’art afin d’envisager de pouvoir produire un affichage Antiope. Ci-dessous, schématiquement, ma compréhension.

  1. L’insertion d’un flux de données binaires dans un flux vidéo composite PAL

Antiope-HardI2C.pdf (938,4 Ko)
==> [Page 4] Cette solution, techniquement idéale, n’est pas applicable pour Antiope, les composants disponibles, à ma connaissance, ne peuvent fonctionner à la fréquence de bits de 6.2Mhz, seulement 6.9Mhz sont possibles.[J’ai recherché chez Phillips, mais pas chez Texas]

Antiope-HackTV_HackRF.pdf (937,7 Ko)
==> [Page 2] Cette solution serait la solution la plus approchante de celle d’époque. Elle est couteuse, complexe, et nécessite une TV.

Antiope-HackTV_FL2000.pdf (935,9 Ko)
==> [Page 1] Cette solution est plutôt de l’ordre de la bidouille, reposant sur la disponibilité d’un dongle USB/VGA avec un chipset FL2000. Je ne la privilégie pas pour le moment.

Antiope-RPi_PAL.pdf (937,6 Ko)
==> [Page 3] Cette solution, pour le moment exclusivement applicable sur RaspberryPI jusqu’au 4 inclus, est légère. Je vais la privilégier pour le moment.

==> D’autres solutions à base de microcontrôleurs/SOC modernes pourraient être envisageables pour traiter/manipuler en temps réel l’insertion sur le signal PAL (RPi Pico/RP2040, AT xx0y ou AT xx1y)

  1. Constitution du flux de données binaires « Antiope »

Antiope-TTI_VBIT2_T42.pdf (936,9 Ko)

[Page 5]

Les options d’insertion décrites acceptent un flux de données « T42 ». Un flux de données « T42 » est constitué de paquets de 42 octets contenant les données utiles à transmettre (pas d’octets de synchronisation ni de définition « système teletexte ».

Ce flux est produit par VBIT2 à partir de pages au format TTI contenant les données télétexte ainsi que des méta-données, décrit ici : fipspub121.pdf (7,8 Mo)

Les formats T42 et TTI ne sont, à ma compréhension, pas directement applicables à Antiope (320 bits/lignes VS 360 bits/ligne).

Pour le moment, seul le document en ma possession comportant un minimum de description du contenu d’un paquet Antiope est la table 1A du fichier « [R-REC-BT.653-3-199802-I!!PDF-F.pdf] ». C’est un peu léger …

(PS : J’ai un peu merdé avec mes/mon PDF, les 5 pages sont dans le même fichier présent 5 fois :exclamation: )

Pour le moment, je pense avoir à peu près compris le fonctionnement de la couche 1 [en mode ‹ télétext système A › (Antiope) et en comparaison avec le mode ‹ télétext système B › (Ceefax/Oracle)] et partiellement la couche 2.

  • Points communs
    • Lignes : N’importe quelle ligne de balayage entre 7 et 6YY (revoir les docs, c’est écrit !) sont susceptibles de transporter des données télétext.
    • Transmission série (bit le moins significatif en premier, pas de start/stop). En conséquence, la synchronisation par rapport au moment du 1er bit et l’exactitude du cadencement sont absolument indispensables à la capacité de recevoir les données.
    • Encodage des bits : NRZ (1=1, 0=0 ; pas d’encodage style ‹ Manchester ›)
    • Bit 1 : « Plutôt blanc » >66% pour « Système B »
    • Bit 0 : « Plutôt noir » (je ne comprends pas trop les notions « D » et « A » dans D/S, A/S [« S » serait le niveau synchro ?] et « modulation positive » vs « modulation négative » [transition 0=>1 et 1=0 ?]
    • Temps de référence : Front descendant de la synchro ligne
    • « Sync Bits » : Octets 1 et 2 contenant une succession de 0 et 1 [Je n’ai pas vraiment trouvé de détail pour ‹ Système A › mais c’est très clair pour ‹ Système B ›] - Cf fig 6 du doc - Permet d’assurer la synchronisation ‹ bits ›.
    • « Sync Byte » : Octet 3 identifiant le type de paquet teletext (différent pour chaque système)
  • Système A : (Antiope)
    • Nombre de bits/ligne : 320 incluant les 3 octets « sync bits » + « sync byte »
    • Bit rate : 6.203125 Mhz
    • « Sync Byte » = 0xE7
    • Taille du data unit = 38 octets (n’inclus pas les 3 octets de sync)
    • Référence du 1er bit : « Temps de référence » + 10.5µs
  • Système B : (Ceefax/Oracle)
    • Nombre de bits/ligne : 360 incluant les 3 octets « sync bits » + « sync byte »
    • Bit rate : 6.9375Mhz
    • « Sync Byte » = 0xE4
    • Taille du data unit = 43 octets (n’inclus pas les 3 octets de sync)
    • Référence du 13eme bit : « Temps de référence » + 12.5µs ==> [Calculer la référence du 1er bit en µs - désolé, je suis mauvais là dedans!]

Concernant le « Système A », je sèche sur l’interprétation des octets 4/5 ou 4/5/6/7/8 - Il y a 2 formats : court et long … et aucune explication hormis que leur intégrité est assurée/vérifiée/corrigée par un code de haming.

17

La différence principale entre Antiope et Ceefax c’est qu’en Ceefax une ligne de données correspond à une ligne de texte avec des attributs dits « série » (ce qui signifie que pour changer par exemple de couleur ou de taille de caractère il faut envoyer un code qui occupe la place d’un caractère espaçant (non visualisé), ce qui en pratique veut dire qu’on ne peut en changer qu’entre deux mots si on ne veut pas d’espace entre chaque caractère.
En Antiope on utilise des paquets qui ne sont pas liés à la position du texte sur la ligne, on peut donc avoir des attributs dits « parallèles » qui permettent de changer de couleur à chaque caractère, au prix d’une complexité de décodage et d’un débit plus élevés.
En fait en Antiope les fonctions de transmission de données et d’affichage sont indépendantes (cf Minitel) alors qu’en Ceefax (plus ancien) elles sont intimement liées, au départ pour simplifier l’électronique au moment où le système a été lancé (2ème moitié des années 70).
A noter que le Télétexte tel qu’on le connait résulte de la fusion de deux systèmes anglais initialement différents mais voisins (Ceefax de la BBC et Oracle de ITV).

1 « J'aime »
18

Oui … On peut dire que je connais « assez bien » ce qui est de l’encodage type CEPT2, attributs série ou pas, tout ça … La couche présentation ne m’inquiète pas.

J’ai (à peu près) bien compris aussi la manière dont sont encodées les données en « Système B » - C’est tout con, un octet/colonne; 40 octets forment 1 paquet (+2 de CRC) et par conséquent 1 ligne, il n’y a que 24 lignes (plus le header qui est un peu plus tordu).

En « Système A », c’est moins clair pour moi.

Ce qui est clair :

  • Les données sont codées sur 7 bits, parité impaire, pas de CRC.
  • Un « groupe de données » commence par la séquence 0x01/0x14 et se termine par la séquence 0x03/0x04. Il a une longueur variable de taille maximale de 1920 octets. Il est constitué d’un ensemble de « blocs de données ».
  • Le préfixe, précédant un « bloc de données », peut comporter 2 ou 5 octets, et son intégrité est assuré par un codage de haming.

Ce qui n’est pas clair (et je ne sais pas où trouver des précisions) :

  • Organisation des bits du préfixe et taille [Niveau 3/Réseau]
  • Assemblage de « blocs de données » en « groupe
    de données » [IE:Niveau 3/Réseau=>4/Transport]
  • Notion d’enregistrement …[Niveau 5/Session] et données associées C/L/Y

Ce qui me manque :

  • Le positionnement
  • Les méta-données …
19

Ne serait-ce pas dans la spec de Didon2 ?

NB: Le système de téletexte A s’appelait Antiope/Didon.
DIDON était un abrégé de DIffusion de DONnées).

20

Les spécifications de Didon-Videotex sont accesibles mais il faut payer :

Des infos ici sur le minitel, en page 48, ça parle un peu du protocole :

Un document de 1979 sur les systèmes de vidéotexte :

Philips avait créé une puce SAA5250 pour décoder Antiope, le NABTS et CEEFAX :

Interface for data acquisition and control (for multi-standard teletext systems)

SAA5250

GENERAL DESCRIPTION

The SAA5250 is a CMOS Interface for Data Acquisition and Control (CIDAC) designed for use in conjunction with the Video Input Processor (SAA5230) in a multi-standard teletext decoder. The device retrieves data from a user selected channel (channel demultiplexer), as well as providing control signals and consecutive addressing space necessary to drive a 2 K bytes buffer memory.

The system operates in accordance with the following transmission standards:

• French Didon Antiope specification D2 A4-2 (DIDON)

• North American Broadcast Teletext specification (NABTS)

• U.K. teletext (CEEFAX)