Résumons ce qu'il faudrait à mon avis pour avancer sur ce projet :
- du temps libre (assez difficile à trouver pour moi comme pour Vince, malheureusement)
- la Lynx modifiée de Rygar, ou au moins une Lynx "bricolable" et le relevé des connexions qui vont vers la petit PCB rajouté
- idéalement, l'adaptateur d'Atari. Cependant, vu son poids et sa valeur considérable, ça me semble difficile de faire voyager ça par la Poste. Mais je pense qu'on peut peut-être s'en sortir rien qu'en analysant les signaux qui sortent de la Lynx. Ça me semble même être une piste à privilégier, vu qu'essayer de refaire le schéma de l'adaptateur prendrait énormément de temps.
- un bon oscillo, ou mieux, un analyseur logique (SCPCD en a un) pour voir à quoi ressemblent les signaux
- une carte FPGA pour pouvoir tester le code VHDL qu'on va écrire, avec de la mémoire embarquée. Ça j'ai pas
En ce qui concerne la partie technique (essentiellement pour Vince ^^), voilà ce que je pressens en vrac et "au feeling" :
- il y a 11 résistances sur le petit PCB rajouté dans la Lynx, en supposant que ce sont des résistances séries d'adaptation d'impédance pour driver la nappe, ça fait 11 signaux distincts. Je dirais : 8 bits de données, horloge, Vsync et Hsync. En sachant le numéro des broches et avec les schémas de la Lynx, y'a moyen de confirmer/infirmer.
- si le LCD marche comme ceux que je connais, les pixels sont transmis sériellement les uns à la suite des autres pendant la durée d'une trame. L'adaptateur doit simplement stocker l'écran généré par Mickey dans de la RAM (un framebuffer quoi), au rythme où il est généré.
- parallèlement, le même framebuffer doit être balayé pour générer l'image TV (d'où l'utilisation de la RAM multiport), sachant que les 2 mécanismes ne sont pas synchrones entre eux. Si on ne veut pas utiliser de RAM multiport, on peut utiliser plusieurs RAM (ça aurait l'avantage d'éliminer le phénomène de tearing, au passage), mais ça suppose d'avoir assez de broches libres pour câbler les bus d'adresse et de données, sachant qu'il faut 3 framebuffers (donc 3 RAMs) vu que la fréquence de rafraîchissement verticale de la Lynx peut être plus élevée que celle de la TV
- 102 lignes c'est pas assez pour remplir une image TV (ça ferait des marges noires énormes), donc elles sont probablement dédoublées en temps réel (ça donne 320x204, quasiment pareil qu'un ST en mode basse résolution), ce qui complique un poil la génération du signal vidéo de sortie. Il doit aussi y avoir un peu de logique pour générer les marges vu que même comme ça, l'image ne prend pas tout l'écran. Il ne doit pas y avoir d'entrelacement : ça ne sert à rien vu la faible résolution, c'est plus complexe, et on n'aurait que 25 ou 30 fps au lieu de 50 ou 60.
- la partie numérique doit occuper le plus gros du boulot, le reste c'est une bête conversion N/A de la vidéo (surdimensionnée sur l'adaptateur d'origine, pour 4 bits par canal on peut utiliser un simple réseau de résistances, comme sur les ST), et pour la conversion RGB->composite suffit de câbler un circuit fait exprès pour.
Bon sur ce, je vais dormir
