[WIP 60%] Hack SRAM du PCB Hyper Olympic

Après des heures de réflexion, la carte va être grosse et ressembler à ça...



Je prévois une EEPROM qui me permettra de stocker les scores et les performances de manière non volatile, sans pile de sauvegarde, et le tout pour chacune des configs possibles du PCB (via DIP switches).
Un mini écran et un rotary pour faire les réglages.
Le reste, c'est de la tuyauterie, de la logique et de la connectique.
J'anticipe un sacré paquet de fils, ça va être l'enfer à souder!
S'ajoutera la connectique pour le bandeau lumineux qui fait les annonces. Une fois que le reste fonctionnera ;-)

Heureusement que je lis tout, j'ai cru que tu avais lâché l'idée du panneau lumineux, ce que je trouve l'idée la plus funky.
Effectivement va pas falloir que les fils soient trop gros car risque d'être un joli paquet de spaghettis

Je pense avoir trouvé un agencement qui permet de tirer moins de fils. Mes buffers sont activables par paquets de 4 bits. Jevais donc utiliser chaque buffer 8 bits pour 4 bits du jeu et 4 bits à moi. Je switcherai d'un paquet de 4 bits à l'autre, et ça me permettra de connecter les 4 sorties 2 à 2 et de n'avoir que 4 fils qui repartent à la SRAM au lieu de 8.
Mais ça va laisser quand même du fil! Si le projet va au bout, il méritera son PCB custom made in China!
Oui, pour l'écran, aucun doute qu'il restera. C'était le but initial. À partir du moment où j'avais reussi à intégrer une pile de backup, la connexion à la SRAM n'avait plus vraiment d'utilité.
Ca permettrait aussi de faire du score board sur Internet, mais ce n'est pas un Pacman et je ne suis pas certain que ça intéresserait grand monde. Dommage, parce qu'avec un ESP32 et sa connexion Wifi, ça deviendrait plutôt facile.

... et comme prévu, ça commence à ressembler à un plan de spaghetti. J'ai câble les bus de données et d'adresses (et un peu de commandes) entre le support SRAM, le connecteur qui va au socket du PCB, et les buffers.
Je devrais donc bientôt être en mesure de vérifier que (/si) le jeu fonctionne toujours avec mes composants au milieu. Si ça ne marche pas, il faudra que je regarde du côté de la longueur des nappes entre le PCB et mon bricolage.



C'est quand même bien long, tout ça!

Oh le ouf !!
Fais voir le dessus de la PCB à l'occase !!

ça doit être long oui^^

Voilà la version du soir. Je pense avoir câblé tous les bus, à l'exception du circuit intégré de lecture qui reste seul dans son coin et qui doit être raccordé au bus de données.
Reste la commande des registres à décalage et le lien microcontrôleur / logique programmable.

Recto/verso:





Dans l'ordre de lecture, recto:
- le registre de lecture, qui sera collé au bus de données pour récupérer des valeurs sur le microcontrôleur
- les 2 connecteurs pour les nappes en provenance du socket SRAM sur le PCB
- le socket SRAM déporté sur mon PCB à moi
- le circuit intégré de logique programmable, qui va réagir à fond la caisse pour intercaler mes commandes et mes données sur le bus
- l'oscillateur à 20MHz
- les 6 buffers 8 bits, organisés en paquets de 4 bits: 4 pour le PCB, 4 pour moi. 2 pins contrôlés par la logique programmable permettent de connecter le PCB ou moi sur les différents bus
- les registres à décalage qui me permettent d'alimenter les bus de données et d'adresses avec le microcontrôleur en n'utilisant qu'un seul fil dédié de celui-ci.
- le microcontrôleur (un Arduino pro mini, pas cher!)
Et il reste un max de place pour l'écran, l'encodeur rotatif et l'EEPROM de backup des scores.

Il reste assez peu de boulot de soudure, mais il va falloir revérifier toutes les connexions, puis tester les buffers en situation réelle pour valider les nappes de 30cm de long et le sac de noeuds (risque d'interférences), avant de commencer à réaliser la partie programmation du microcontrôleur. Cette dernière partie est celle qui m'inquiète le moins. Avec tout le bordel de composants que j'embarque, il ne reste plus la moindre contrainte de performance du microcontrôleur, et aucun bug ne pourra cramer quoi que ce soit.

Toute la partie écriture en SRAM est câblée. Je vais devoir commencer un bout de code sur la microcontrôleur pour tester l'état des buffers.
J'ai fait un test de branchement, et c'est plutôt une bonne surprise: pas de consommation excessive, ça tourne autour des 100mA, ce qui est cohérent avec la techo des composants. En gros, pas de court-circuit. Et ça, c'est cool!
Du coup, jusqu'à ce que je rajoute les écrans et l'encodeur rotatif, il ne va rester qu'une dizaine de fils à ajouter (pour le circuit en haut à gauche, qui n'est pas encore branché, et qui va lire sur le bus), ça reste manipulable!
La suite bientôt, la connexion au PCB du jeu ne devrait plus trop tarder!

Après vérification des connexions, je me suis aperçu que j'avais soudé les nappes de travers sur le PCB.
Opération démontage du support, dessoudage et re-soudage des nappes.
Les premiers essais montrent une chute de tension à 2.5V au lieu de 5V attendus au niveau de mon PCB. La SRAM est normalement alimentée via un transistor sur le PCB d'origine, et celui-ci ne suffit peut-être pas à alimenter tout le bazar que j'ai mis sur ma plaquette.
Je tente donc une injection de courant via l'alim du microcontrôleur.
Ca me donne bien 5V, mais le PCB ne reconnait visiblement pas la SRAM.
Il me reste 4 fils dispo sur les nappes. Je pourrai m'en servir pour repiquer le +5V ailleurs sur le PCB.
Par contre, pour les soucis de lecture, ça peut venir de mes buffers qui sont mal configurés, ou de la bande passante de la nappe qui n'est pas suffisante.
Je vais devoir investiguer à coups d'oscillo!
En attendant, dodo!

Putain cette usine a gaz !!

Tu as bien 5v au jamma en fonctionnement ?

+1 pour le sticker NGP, tu vas passer modo bientôt

Oui, j'ai 5V au JAMMA (ce n'est pas du JAMMA, d'ailleurs, c'est le truc de Konami). Mais j'ai soudé les nappes sur le connecteur de la SRAM, et elle est alimentée par une alim séparée (via un transistor). J'imagine que c'est pour que l'accu de sauvegarde n'alimente pas tout le board quand on coupe l'alim :-).
Je vais repiquer un +5V sur un autre chip pas loin, du coup, et je serai fixé!
Il est frais, mon sticker, il est frais! (Vu qu'il n'y a pas moyen d'avoir un T-shirt... ).

Allez croisons les doigts. Pour le 5V c’est plus clean de repiquer le 5V direct à la source.

Après avoir fait une tonne de tests, j'ai dû commencer à réfléchir...
J'ai fini par m'apercevoir qu'en mode lecture par le PCB, je suis censé renvoyer l'information vers le connecteur. Or tous mes buffers sont orientés en Direction de ma SRAM, et jamais DEPUIS la SRAM.
J'ai donc gagné le droit d'ajouter un buffer de plus (seulement 1, pour les 8 bits à lire dans ma SRAM).
Et pour piloter ce buffer et celui qui tourne dans le mauvaises sens, il me faut 2 nouvelles équations dans le GAL. Or je suis venu à vout des 8 pins disponibles en sortie du GAL.
Je pourrais utiliser des portes NOT pour gagner 2 pins sur le GAL, mais le temps de propagation dans ces portes va ruiner mes timings, au risque de provoquer des court-circuits sur le PCB (de quelques nanosecondes à chaque cycle).
Je vais donc utiliser un autre modèle de GAL que j'avais commandé en même temps que le GAL 8 bits. C'est un GAL à 10 sorties (et 12 entrées). Ca tombe bien, il me fallait 2 signaux de plus!
Au gré de mes observations, je suis tombé sur des cas où les accès SRAM se succèdent avec 330 nanosecondes d'intervalle (je tablais plutôt sur 600!). Ca devrait rentrer, mais ça va pousser !

La programmation du nouveau GAL plus gros est faite.
On se récupère 2 lignes en plus pour piloter le buffer supplémentaire nécessaire à la lecture de la SRAM par le PCB (ça peut servir!)...



L'occasion de voir qu'une lecture peut prendre au pire 300ns avec ce système. L'espace que j'au mesuré étant à 330, en théorie, ça passe encore!
Si j'observe des instabilités parce que mes cycles croisent ceux du PCB, j'envisagerai u quartz à 24MHz au lieu de 20. Ca passera mieux dans l'intervalle, mais avec un risque que la SRAM ne suive pas le rythme (reste la possibilité de changer la SRAM pour une plus rapide ).

Plus qu'à modifier le circuit pour intégrer le nouveau GAL et le nouveau buffer... Soudure party!

Pour le quartz tu n'aurais pas meilleur compte de prendre un multiple de celui d'origine histoire de ne pas trop foutre le bordel.

Bonne question. En fait, le principe est d'aller le plus vite possible pour détourner l'utilisation de la puce de SRAM entre deux accès. Pendant ce laps de temps, je bascule la puce sur mon propre bus et j'en fais ce que je veux, indépendamment du PCB.
Le but étant d'aller au plus vite, je me calque sur les timings max de la SRAM. Si je lis les specs, je vois qu'elle a un temps d'accès de 150ns. Sauf qu'il faut préparer les données 35ns à l'avance.
Avec un oscillateur à 20MHz, j'ai des cycles de 50ns. Ca me permet de temporiser respectivelent 50 et 150ns assez facilement en câblant un compteur dans le GAL.
C'est en l'occurrence un compteur intelligent, qui sait attendre le bon moment pour faire ce qu'on lui a demandé en un laps de temps qui colle au timing de la SRAM.
J'adore les GAL, c'est la révélation de ce projet. Je sens que mon bricolage de synchro va prendre un nouvel essor .
Bon, bref, en résumé, pas besoin de coller à la fréquence du CPU, il faut s'aligner sur celle de la SRAM. C'est pour ça que je disais qu'en cas de souci, je pourrais dénicher une SRAM plus rapide et augmenter la fréquence.
Les GAL que j'ai achetés montent à 60MHz, j'ai de la marge!

Et pendant ce temps, j'ai supprimé le socket du circuit de lecture (il faudra en remettre un plus tard quand même), j'ai remplacé le slot du GAL par un plus grand, j'ai posé un slot pour mon nouveau buffer (ça en fait 7!), et j'ai câblé le buffer et le GAL.
Résultat: un sacré sac de noeuds!



J'ai vérifié les branchements, programmé le nouveau GAL, et repeuplé la carte.

Il va falloir attendre demain pour tester ça sur le PCB...

Tu es fou ! C'est vraiment intéressant même si j'ai pas tout compris...
T'es pas loin de lui faire une borne dédiée à ta pcb.

Bon courage !

Merci
En fait, je cherche pour le moment à ajouter de la fonctionnalité au PCB d'origine. Ce n'est qu'une étape facultative avant de passer à la réalisation d'un meuble d'arcade dédié. Qui serait probablement une borne cocktail, histoire de faire dans l'originalité. Je suis fan des causes compliquées

Bon, le passage du 16v8 au 22v10 ne se fait pas en douceur.
Toute la partie équations logiques asynchrones fonctionne parfaitement, mais ce n'est plus le cas des équations synchrones. Ce sont celles qui me permettent de gérer des états et des temporisations.
J'ai passé la soirée à essayer de comprendre pourquoi, sans rien trouver d'intéressant. En plus, avec ces outils des années 90, on ne me facilite pas la tâche.
Je ne désespère pas, mais c'est bien casse-bonbons quand même!
Retour à la plaque lab pleine de mauvais contacts, pour du debugage de l'extrême :-/

Bouz t'es fou...
Fabrique toi une nouvelle PCB ça ira plus vite !!

Sinon le jeu est vraiment amusant à 2, JeySpindizzy la possède en Jap et c'est marrant de bourriner les boutons pour gagner !

theWave a écrit:Bouz t'es fou...
Fabrique toi une nouvelle PCB ça ira plus vite !!

Sinon le jeu est vraiment amusant à 2, JeySpindizzy la possède en Jap et c'est marrant de bourriner les boutons pour gagner !

Avant de fabriquer un beau PCB tout neuf, il faut que je finisse de le mettre au point! Et ça, ça passe par l'étude, le câblage, la programmation de la logique programmable, et la programmation du microcontrôleur. Avec des tests dans tous les sens.
... sachant bien-sûr que je fais un truc que je n'ai vu nulle part ailleurs, et donc suivant une technique totalement improvisée!
Si tout fonctionne, par contre, le PCB tout beau sera de mise!

Je ne sais pas qui est JeySpindizzy, mais il a bon goût. J'ai beaucoup joué à ce jeu en émulation sur ma borne avec un ami avant de l'acquérir. C'était aussi un bon test pour mon panel en Sanwa.
Quand j'ai essayé de jouer à ça avec mon Twin Stick maison et ses boutons Amazon chinois, j'ai pété un bouton quasiment tout de suite!

Mais revenons à nos moutons. 2 heures de debuggage supplémentaires plus tard, j'ai fini par découvrir que le compilo gratuit de Microchip pour les PLD a une saloperie de bug (convention?) qui inverse l'état des pins d'I/O quand ils sont déclarés en logique négative!
Après l'avoir insulté copieusement et avoir adapté le code, j'ai fait les tests d'usage. Je ne constate plus de conflits de bus (qui se manifestent par un court-circuit qui fait chauffer les buffers!). J'ai pu tout rebrancher, youpi!

Etape suivante: test du fonctionnement en mode "non hack": est-ce que ce tas de fils est capable de router les signaux correctement et assez vite?
Après ça, il faudra passer au code du microcontrôleur, et peut-être souder le registre d"entrée pour lire les données sur le bus de données.

Bref, c'est pas fini!

En attendant, ça ne prend pas feu avec toutes les puces en place...

Bon ça avance bien cette affaire.
Chaud à trouver le bug sur le logiciel, c'est référencé sur le net ou tu as trouvé ça suite à diagnostic ?

J'ai debuggé toutes les équations une par une. En gris, j'ai modifié ma machine à états pour en faire un chenillard, j'ai mis des LED dessus, j'ai vu que ça marchait (ouf!), et j'ai ajouté petit à petit les conditions de sortie d'état. J'avais un bouton qui permet de simuler une demande d'accès par le microcontrôleur. J'ai vu qu'il faisait changer l'état quand il n'était pas enfoncé. J'ai inversé la déclaration de son pin, et tout est rentré dans l'ordre.
Du coup, j'ai réinversé tous mes pins (qui étaient tous en logique négative). C'est pas par esprit de contradiction, mais les puces que je pilote ont toutes des fonctions qui s'activent sur un niveau logique bas (0V).
C'est peut-être une subtilité du langage, mais c'est clairement pas intuitif parce que ça fait des équations fausses!

Hop, un chenillard à 20MHz observable avec un oscillo . J'ai aussi câblé une horloge manuelle, mais le rebond me faisait sauter des états.

Logique à manque, on a principalement ça au boulot aussi.
Les schémas sont beaucoup plus simples par contre

Il va te falloir une alim dédiée de 500 watts pour cette seule pcb bouz...

Du coup, je repique du 5V à 3 endroits différents. Pas de chute de tension à signaler, mais c'est vrai que les GAL, ça consomme (et à cette vitesse, çachauffe). Le reste, pas trop. Sur ce jeu, tout consomme et chauffe, ça passe inaperçu!

Bon, je viens de faire le test sur le PCB. Le but du test est de voir si mon bricolage permet d'acheliner correctement les bus.
Le bus d'adresses passe par3 bascules commandés par le GAL.
Le bus de données pareil, mais avec 2 bascules à moitié actives, qui swappent via le GAL sur la bascule de lecture du jeu.
Je ne fais aucune tentative de lecture (impliquant une écriture sur le bus d'adresses) ou écriture (idem + lecture bus de données).
Je démarre, ça plante. Je fais de relevés à l'oscillo, c'est tout moche. Le bus de données oscille à bloc:



Le coup classique: j'ai laissé des pins en l'air sur le GAL. Et ça, c'est la recette des instabilités de la mort. Je relie dont les quelques entrées inutilisées à la masse.
Problème réglé.

Je démarre, ça plante. J'arrête, je fais des revelés, je lève les yeux, et...



Bon, ça ne saute pas aux yeux, mais ça marche!

Après quelques essais, on dirait que c'est plutôt instable. Je perturbe très probablement les bus avec mes câbles de 30cm et mes tas de noeuds.

Je vais continuer à avancer pour voir si j'arrive à lire les records de saut en longueur dans le timing, puis à les écrire, sans tout planter.
Si j'y parviens, j'aurai fait un grand pas et je pourrai envisager la conception d'un PCB digne de ce nom, qui ne m'injectera pas des parasites de malade!
Avant ça, il faut que j'ajoute à mon gros tas de noeuds un registre parallèle/série pour lire le bus de données avec le microcontrôleur. Il sera piloté en acquisition par l'un des états du GAL. J'ai soudé la partie commande, il me reste les 8 fils de données mais je fatigue, on erra demain!
Et il faut encore écrire le code du microcontrôleur pour attaquer les bus en lecture et écriture!

Semaine de grosse fatigue et grenier à 40°C => pas beaucoup avancé, sinon que j'ai fini toutes les soudures.
Je m'y suis remis un peu ce soir, et j'ai fait quelques analyses sur la qualité des signaux, pour essayer de comprendre les aberrations observées ci-dessus.
A force de trifouillage, j'ai fini par observer un truc intéressant au niveau du connecteur de nappes, sur ma carte: autant les signaux de data sont un peu déformés du point de vue des niveaux bas, autant les les signaux d'adresses sont carrément dégueulasses.
Or... Les signaux de données sont émis en alternance par le jeu ou par la SRAM, suivant qu'on fait de la lecture ou de l'écriture sur la puce.
Côté signaux d'adresses, pour le moment, je ne mets aucune adresse sur le bus. Les signaux sont donc ceux qui arrivent du jeu.
Quand je dis que c'est dégueu, je veux parler de ça:



Qui peut me dire si c'est un état haut, ou une tentative d'état bas?!

Une fois que tout ça arrive sur les buffers, c'est transformé en joli signal (tout est relatif), mais en interprétant le signal d'entrée comme une valeur logique (binaire, donc). Donc si le buffer reconnait un signal haut, il renvoie un signal haut tout beau. S'il reconnait un signal bas, il renvoie un signal bas tout beau.
On se retrouve alors avec un beau signal parsemé de cochonneries, comme ça:



Histoire de rigoler un peu, parce que j'ai un humour particulier, j'ai sondé simultanément l'entrée du buffer, alimentée par une ligne du bus d'adresses provenant du PCB, et la sortie du buffer, qui en est l'interprétation.



En bleu, le signal (entrée de buffer, connecteur), en rouge, son interprétation (sortie de buffer) Qui a dit que l'informatique était une science exacte...?

J'ai clairement un souci de transport du signal entre le PCB du jeu et le mien. Il va falloir regarder du côté de la longueur du câble, mais ça peut aussi être un souci d'adaptation d’impédance avec un rebond du signal dans le fil (et je n'y connais rien), ou du couplage capacitif entre les lignes de la nappe (le signal saute d'un fil à l'autre).

Je vais essayer de me renseigner un peu, mais il semble tout de même assez clair que tout fonctionnerait mieux si je pouvais coller mon PCB direct sur le PCB du jeu. Malheureusement, c'est un peu serré pour le moment...



Resterait la possibilité de surélever le PCB du haut pour faire de la place et à trouver un moyen de me connecter sur le support de la SRAM.
Dans tous les cas, passer en direct nécessiterait de refaire la partie connecteur de mon PCB, et là tout de suite, je n'ai pas envie de repositionner sur le circuit les 24 fils correspondants!

Gros gros progrès même si, comme d’habitude, c’est la finition qui va prendre le plus de temps.
Avec ce niveau de précision, je ne suis pas surpris de la pollution des signaux, ce sera long à nettoyer je pense.