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.
- 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)
- 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 )
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.