Bonsoir.
Suite de ce WIP.
La dernière fois, j'avais réussi à changer la bouillie de blocs en un truc moins moche, mais tout aussi buggé.
Avec un peu d'imagination, on pouvait voir un ersatz de balle vaguement gigoter à l'écran...
Je me suis donc intéressé cette fois à la gestion de cette balle.
Grâce aux schémas électroniques, j'identifie immédiatement la partie du PCB qui gère l'affichage de la balle.
Il y a 2 registres 8 bits 74LS273, chacun contrôlé par un signal /BHD et /BVD.
On va dire que ça veut dire "Ball Horizontal/Vertical Data" ou un truc dans ce sens.
Le registre de position verticale est comparé par rapport au numéro de scan-line et génère un simple signal qui va bloquer ou laisser passer le signal en provenance de la partie horizontale.
Le registre horizontal, lui, est chargé dans 2 compteurs 74LS161 à chaque début de ligne.
Les compteurs sont clockés à 6 MHz (fréquence pixel) et le tout génère le signal horizontal de la balle mais avec un retard égal à la valeur chargée dans les compteurs.
C'est assez simple dans son principe et très efficace par raport à une gestion lourde de l'affichage qui pourrait être faite par le CPU...
A l'oscillo, je détecte assez vite qu'un des compteurs de la gestion de la partie horizontale déconne plein pot.
Coup de chance, il est sur un support :
Compteur 74LS161 malade
Grâce à mon habitude d'acheter à chaque fois quelques composants de plus que mon besoin, j'ai ce composant en stock chez moi...
Le changement s'est fait en 5 secondes chrono !
Nouveau composant en place
Allez, on teste le résultat :
Et la balle fut !
Bon, maintenant j'ai la balle qui se déplace...
Des fois elle disparait (?). Des fois elle réapparait (!). Des fois je suis obligé de reseter le PCB pour qu'elle revienne.
Bon, ça ne respire pas trop la fiabilité pour le moment.
Je vais m'attaquer maintenant au générateur de caractères.
Ce truc, c'est l'ancêtre des "tilemap" (
lien Wiki).
Avec les sprites, je crois que les tilemap font parties des principes de programmation les plus utilisés dans l'histoire des jeux vidéos...
Le principe est extrêmement simple et puissant.
Soit une image de jeu vidéo de 320 x 200 par exemple.
Elle peut être divisée arbitrairement en petits blocs de 8 x 8 par exemple. Dans ce cas, j'ai 40 x 25 blocs à l'écran, soit en tout 1000 blocs.
Imaginons que je dispose d'une armada de petits blocs différents, stockés dans des EPROMs, chacun constituant un petit bout d'un décor.
Si je numérote tous mes blocs de 1 à N, je peux décrire un décor de fond uniquement avec les numéros des blocs à afficher :
1ère ligne : bloc n°3, puis bloc n°7, etc jusqu'au 40° bloc de la 1ère ligne
2e ligne : même principe.
Et ainsi de suite jusqu'à la 25e ligne de blocs...
Voilà, c'est ça le principe d'une tilemap. On peut ajouter à ça des infos genre le perso peut passer à travers ou pas, etc...
Ce PCB Gee Bee utilise une tilemap pour son décor de fond.
Le numéro de chaque bloc est stocké dans une RAM. Cet index permet d'aller chercher dans une EPROM (appelée pour l'occasion "CGROM" = character generator ROM) les graphismes d'un bloc.
Les données en sortie de la ROM servent à générer le signal vidéo.
C'est ce qu'on voit quand un PCB déconne et qu'il y a plein de blocs à l'écran.
La présence de ces blocs indique déjà que le générateur basé sur une tilemap fonctionne !
Avantages :
- ultra simple électroniquement
- ultra simple à utiliser d'un point de vue logiciel
Inconvénients :
- graphismes limités au nombre de blocs présents dans la ROM
Sur le PCB Gee Bee, la réalisation de la tilemap est assez simple.
Grâce à l'oscillo, je vois que la ROM est bien accédée et sort bien quelque chose.
Je n'ai pas la preuve que ce quelque chose soit correct, mais je devrais au moins avoir mieux qu'un écran gris.
J'examine la circuiterie en aval de l'EPROM. Il y a 2 registres à décalage clockés à la fréquence pixel.
Bingo ! Le 1er déconne complètement et sort sur une de ses sorties directement la même chose que la clock en entrée. Ca explique donc pourquoi j'ai du gris à l'écran !
Registre à décalage mourru
Dessoudage
Le remplaçant
Je crois que je peux à nouveau re-tester le PCB...
Bon, ce n'est pas fini...
Le jeu déconne à mort.
Il ne démarre que sur une certaine configuration de DIP-switches (?), la balle fait vraiment n'imp, des fois l'image clignote à mort, il ne crédite pas, etc...
A suivre !
