[WIP 60%] Hack SRAM du PCB Hyper Olympic

En fait, je pensais plus à une matrice de LED. J'ai acheté 3 bandes comme ça, je me disais que ça pourrait être rigolo de faire tourner les records dessus, façon piste de bowling. Mais je suis ouvert aux suggestions, parce que je suis loin d'en avoir fini avec ce projet!

Ha oui tout aussi fun et retro ce bandeau, je n'y avais pas pensé. Je ne sais pas si c'est faisable mais avoir d'ecrit au dessus de soi le record de l'épreuve c'est sympa et New WR quand il est dépassé ça aurait de la geule. A voir niveau extraction des données dans quelle ordre c'est rangé

Je peux lire les données uniquement quand le PCB n'est pas alimenté. Comme je disais plus haut, si je veux lire, je dois mettre du jus sur les 13 lignes d'adresses. Or elles so t partagées par tous les chips du PCB
Du coup, si j'essaie de lire, je vais forcément foirer le bus d'adresses pour quelqu'un d'autre. Seul le CPU sait ce qui se passe sur le bus.
Du coup, ma solution passera par un autre bricolage, avec un microcontrôleur plus puissant et avec plus de pattes: en plus de lire sur le bus de données, il faudra lire sur le bus d'adresses et sur les lignes de commande, pour savoir si le CPU est en train de lire ou écrire en SRAM, quoi, et à quelle adresse.
S'il charge à l'adresse des records de saut, alors je sais qu'on est sur l'épreuve de saut. J'en profite pour enregistrer les records à la volée.
S'il écrit à ces adresses, alors je sais que le record est battu, et par qui...
J'espère qu'il stocke le nom des joueurs quelque part, pour pouvoir aller les chercher. Ça va être plus dur à trouver, ça :-).
Bref, de l'électronique appliquée, je m'amuse bien

Des idées qui changent des poncifs, je trouve ça hyper bien. Le genre de truc, sur ce type de jeux qui donnent envie de remettre une pièce pour écrire son nom... comme dans un flipper.

J'essaie de trouver des choses qu'on ne voit pas tous les jours, tout en m'amusant techniquement
Et tiens, je viens de trouver pourquoi mes écritures ne fonctionnaient pas bien à l'endroit, en lisant la doc de la puce de SRAM. Un problème de timing, je lâchais les lignes de données trop tôt, le circuit n'avait pas le temps d'intégrer les nouvelles valeurs.
Je reprends le boulot ce soir avec un petit protocole d'échange avec la puce, qui me permettra d'établir la map de la mémoire sans recompiler du code à chaque test.

Eh ben j'ai mis en place un outil qui me permet de remonter des zones mémoire, et d'aller écrire des nombres ou des caractères encodés à la sauce Hyper Olympic dedans.
Ca m'a permis de trouver:
- comment sont encodés les noms
- où et comment sont codés les records de chaque épreuve
- où sont enregistrés les noms des (4?) joueurs en lice
- où sont enregistrés les temps / distances des 3 tentatives pour chaque épreuve.
Ce que je n'ai pas trouvé, c'est où et comment sont stockés les 200 meilleurs scores!

Du couo, si je m'en tiens à ce que je voulais faire, à savoir scruter tout ce qui se passe sur le bus, eh ben il va falloir que je fasse de sérieux tests de perf avec les microcontrôleurs! J'aurais aimé utiliser un ESP32 parce qu'il a 2 coeurs à 240 MHz (et il ne coûte rien). Un pour lire les bus, et l'autre pour gérer le ou les afficheurs. Malheureusement, il ne propose pas assez de pins! Je vais voir si je peux me débrouiller quand même, et si des circuits logiques pourraient m'aider (et seraient assez rapides).
Sinon, il reste le STM32 Blue Pill. Il aurait assez de pins, mais il n'a qu'un coeur et tourne à 72 MHz.
Un coup d'oscillo devrait déjà me donner une idée de la cadence d'accès à la SRAM par le CPU...

Aujourd'hui, j'ai passé un peu de temps à étudier quelques possibilités pour récupérer les données des bus à la volée.
Le souci des microcontrôleurs, c'est qu'ils ont principalement des interfaces série. Et là, il faut super vite récupérer les valeurs d'une vingtaine de lignes à la fois...
Etant donné le nombre élevé de lignes, je suis a priori contraint d'utiliser un micro-contrôleur rapide. Il doit arriver à lire 20 lignes en série pendant un seul cycle de lecture du CPU du PCB...
Pour savoir avec quoi je dois lutter, j'équipe la puce de SRAM de sondes logiques...



Je récupère une séquence d'une seconde (ça fait déjà énormément d'échanges!), et je mesure les écarts minimums entre les lectures ou écritures.



L'occasion de voir que la puce est toujours active (la ligne CS est toujours en état bas), et elle est pilotée par les lignes OE et WE (donc lecture et écriture).
Le plus petit écart tourne autour des 660ns (nanosecondes). C'est méga rapide, il va falloir courir!

Pour lire tout ça, j'utilise un ESP32. Il tourne à 240MHz, c'est cool. J'utilise avec lui un multiplexeur et deux registres à décalage pour faire passer les données de 16 lignes sur un seul fil.
Le souci, c'est que ce contrôleur tourne en 3.3V. Et ça, ça implique d'injecter un buffer intermédiaire, qui va faire la conversion des signaux TTL de la SRAM (5V) vers du niveau 3.3V.
Ca fait une installation comme ça:



Je fais des essais de transferts en boucle pour voir combien de temps il faut pour sérialiser les 16 lignes.
Ca donne ça:



=> 3,9 microsecondes! 7 fois trop lent.
Je pourrais gagner en vitesse en augmentant la fréquence de la sérialisation. Mais malheureusement, à cause des composants intermédiaires de conversion de niveau de tension, je suis bloqué à 10MHz!
Je vire le buffer, et je le remplace par un level shifter (un transistor à effet de champ), qui devrait être plus rapide => je peux pousser jusqu'à 12MHz. Pas plus. Ca sent le sapin, cette affaire.
Je passe au plan B, le STM32. Lui, il ne court qu'à 72MHz, mais il a un énorme avantage sur l'ESP32: au moins la moitié de ses entrées est tolérante aux signaux TTL (5V). Je vais donc pouvoir gicler les composants de conversion de niveau.
Et donc pour le moment, j'en suis là. Il va falloir attendre un peu, parce que ce machin est un peu plus compliqué à programmer et je galère un peu pour le flasher...

Ha merde le coup du 3,3V c'est balo ! Pourtant à 240MHz, j'étais pourtant persuadé que tu avait de la place mais au final la transformation te fait un énorme goulet d'étranglement, je n'aurais jamais pensé.
Tu es sûr d'avoir fait le tour de tous les matériels dispo pour faire ça, tu n'as pas le truc idéal pour ça avec plein d'entrées en 5V et qui galope vite ?

J'ai un Arduino Mega qui traîne. C'est blindé d'entrées (une cinquantaine?), mais ça tourne à 16MHz. Ca risque d'être limite pour gérer autre chose en même temps (l'afficheur ).
Je vais faire des tests avec. Dans le doute, j'ai commandé à l'instant en Chine la version compacte de la carte qui, elle, peut être soudée sur un circuit imprimé (je découvre, je ne savais pas que ça existait et j'ai toujours mis le 2560 de côté à cause de ça).
Si tu vois autre chose de pas trop exotique, je prends!

Here comes a challenger!



Soudure party pour faire un adaptateur!

Bon, je viens de perdre une soirée de ma vie, mais j'aurai appris des choses (j'essaie de m'en convaincre).

J'ai commencé par étudier le meilleur endroit pour me câbler, afin de lire les données par paquets de 8 bits (un port par paquet de 8 bits). Puis j'ai prépare un adaptateur pendant 2h parce que c'est super serré pour souder...



Et puis je me suis dit tiens, je vais quand même vérifier les temps de réponse, histoire d'en avoir le coeur net... (mais un peu tard). J'ai monté tout ça et j'ai branché un fil sur un bouton. J'appuie, ça simule une lecture sur le bus.




De l'autre côté, un gestionnaire d'interruption qui descend une ligne quand il détecte une impulsion.
A l'oscillo on voit dont 2 lignes descendre l'une après l'autre: l'impulsion, et la réponse. La distance entre les deux donne le temps de réponse.



Eh pif, 3 microsecondes. Pour rappel, l'objectif est de pouvoir lire toutes les 0,6 microsecondes. Donc 5 fois trop lent. Et pourtant, on ne peut pas dire que je fasse du gros traitement...



On fait difficilement plus court: un vecteur d'interruption avec une seule instruction en assembleur derrière. Vu qu'il y a un accès mémoire, on va dire qu'elle dure 2 cycles. à 16MHz, ça doit faire 125 nanosecondes. Clairement, on n'y est pas.

Pour en avoir le coeur net, je tente une petite fantaisie: dans le traitement d'interruption, je bascule plusieurs fois l'état de la ligne, et je chronomètre à l'oscillo...



On peut mesurer 250 nanosecondes pour une alternance complète, soit 125 nanosecondes par alternance. C'est bien ça. Par contre, on note que la première alternance arrive vraiment longtemps après l'impulsion.

Conclusions:
- C'est la mécanique même de l'interruption qui prend des cycles (26 cycles, a priori). Le traitement d'une interruption nécessite de backuper les registres du microcontrôleur. Ca, c'est la couche C qui le fait pour nous en standard. On s'en passerait bien, pour le coup.
- Avec ce timing, ça va être tendu pour faire quelque chose!

Vu que je me suis bien enquiquiné la vie à faire l'adaptateur, je vais quand même creuser un peu pour voir si je peux faire un gestionnaire d'interruptions 100% en assembleur. Ca permettrait de ne pas backuper autant de registres. Il y aura toujours le coup du saut avant-arrière, ça laissera peu d'instructions pour faire quelque chose, mais ça se tente. Au pire, j'aurai vraiment appris un truc!

J'ai avancé/reculé un peu hier, avec des tests de traitement des interruptions en assembleur inline.
Une fois décompilé, on voit bien qu'il n'y a pas grand chose dans la routine d'interrution: juste l'instruction qui fait le front descendant de réponse.



Eh ben le résultat est....



10x plus rapide. Mais ça ne suffit pas, malheureusement.

Après une soirée passée à souder un ESP32 sur un support qui me permet de câbler juste assez de pattes pour toutes les raccorder, et donc éviter d'utiliser un registre à décalage chronophage en entrée, je me décide à faire un test que j'aurais pu faire dès le départ (comme d'habitude).
Je colle un interrupteur sur une patte, je sors un signal sur une autre, et je regarde le délai de traitement du signal.
Et c'est tout pourri, pire que sur l'Arduino Mega. En fait, l'ESP32 embarque un mini OS qui induit des latences. On peut bricoler un peu pour essayer de gagner en performance, mais je n'attends pas de miracles. Sans compter que je devrai quand même me farcir les adaptations de niveaux pour les 19 lignes!

Je réfléchis très sérieusement à un plan B qui va tourner avec un Arduino Pro Mini, mais qui va utiliser pas mal d'électronique pour l'épauler. Pour le moment, je compte:
- Une douzaine de quadruples portes NAND
- Deux quadruples portes NOT
- Deux doubles bascules RS
- 3 registres à décalage série->Parallèle
- 1 registre à décalage parallèle->Série
Soit une vingtaine de circuits intégrés. Ca va prendre un peu de place!

L'idée est de ne plus essayer de lire les données à la volée, mais de profiter de l'instant entre deux lectures / écritures pour mettre mes propres adresses sur le bus d'adresses, et de balancer instantanément les données dans un registre à décalage, puis de rendre les bus au système jusqu'à la prochaine fin d'accès officiel aux bus, pendant que je lis tranquillement le contenu du registre à décalage.
Sur le papier, ça fonctionne, mais la logique pour décider de ce qui va transiter sur les bus, et quand, est assez intense!
Je vais voir si je ne peux pas trouver des circuits intégrés qui me feraient économiser 1m² de circuit et 12km de fils, mais la stratégie me plait bien.

Je viens de commander sur eBay quelques circuits intégrés qui devraient me faire économiser pas mal d'espace. Il s'agit de différents types de buffers et bascules 8 bits, le tout en 3 state (haut, bas, déconnecté). Ce dernier point est capital quand on écrit sur un bus (et surtout quand on n'écrit pas dessus!).
Plus qu'à attendre. Ca arrive de France, c'est déjà ça.

Y'a plus qu'à attendre du coup.

Je peux déjà avancer sur la modélisation, parce que c'est costaud

En attendant, le facteur est passé, et je vais déjà présenter ces deux-là, histoire de pouvoir tester tout ça sur une "vraie" borne

Bon, tout le monde s'inquiétait, je sais, alors voilà des nouvelles...

J'ai fait l'adaptateur avec un peu de grattage de tête:



Il fonctionne plutôt bien, j'ai pu me faire une partie avec mon stick maison



L'occasion de voir qu'il y a quand même un souci quelque part avec les scores. Ils sont bien sauvegardés, mais la routine de reset ne semble pas fonctionner correctement. Elle met en mémoire des scores inatteignables humainement. Il va falloir que j'aille patcher ça avec mes outils maison

Après, j'ai essayé de balancer ça dans ma borne avec son alim ATX, et pas moyen de la faire partir. Un point normal: la tension, comme prévu, chute à 4V quand le PCB démarre. N'étant pas réglable sur les alim ATX (pas sur les miennes en tout cas), je l'ai un peu dans l'os. Du coup, j'ai commandé une alim arcade réglable (que j'ai reçue aujourd'hui), je me garde l'ancienne pour mes essais!
Le point bizarre, c'est que la consommation semble varier en fonction de l'angle du PCB (!). J'ai fait une vidéo amusante où on entend le multimètre qui bippe quand j'incline ou soulève le PCB. Il doit y avoir du condo de régulation bien en forme!

Et la bonne nouvelle du jour: j'ai reçu mes circuits intégrés pour gérer le hack de bus d'adresse et de données. Les choses sérieuses vont pouvoir commencer!!!

Mais d'abord, je vais en finir avec le recâblage de ma borne. J'ai sorti tout ce qui n'était pas "arcade" (le PC trafiqué, les cartes de conversion vidéo et tout e qui allait avec) pour faire place à ma nouvelle carte de contrôle / supergun (celle avec une sécurité sur la tension si je bascule de Hyper Olympic à autre chose qui ne bouffe pas 5 ampères).



Il me reste à changer les câbles d'alim en 5V et masse pour du plus gros (moins de pertes) sur le connecteur JAMMA et sur l'alim. J'en profiterai pour câbler le fil de retour de tension pour la sécurité.
Si je suis en forme, j'essaierai d'asservir le potar de l'alim à la tension lue sur ce fil de retour. Ce serait ultime, ça :-)

A gauche, l'alim temporaire (elle dont j me sers pour bricoler) en attendant la prochaine (que j'ai reçue). Au milieu, le supergun de la mort avec le check de tension sur le connecteur JAMMA (et les réglages de couleur, la base ). Et à droite, la carte fille pour le pilotage de la cartouche MVS 138in1 qui, à son tour, contrôle le supergun (elle coupe l'alim et la remet quand on change de jeu). Au premier plan, un paquet de fils qui descend du panel, et qui sera probablement remplacé par 4 fils quand je câblerai le panel avec le même système que dans mon twin stick (en mieux, avec reconfiguration des contrôles).



Bref, il y a des projets dans les tuyaux...

Et voilà la nouvelle alim dans la place, et le slot MVS fait son retour triomphal (et le code du 138in1 a été adapté).



Mais ce qui est vraiment important,c'est ça:



Maintenant, on va pouvoir attaquer les choses sérieuses avec cette NVRAM, youpi!

C'est vraiment un taf de fou, mais on sent que tu t'éclates à faire tout ça

shadowfox a écrit:C'est vraiment un taf de fou, mais on sent que tu t'éclates à faire tout ça

Carrément, oui! Mais ça ne m'a pas empêché de passer 2h à jouer à Hyper Olympic aujourd'hui. Et j'ai enfin réussi à sauter en hauteur, épreuve que je n'avais jamais réussie en émulation (pas une fois).
Le timing du lancer de marteau me semble plus sympa aussi sur le vrai PCB. En fait, ça n'a rien à voir!
Et quand il y a de la ventilation dans la borne, la carte ne chauffe quasiment plus. Par contre, elle bouffe toujours du courant!

Et pour faciliter mes tests à venir, je passe une soirée réparation de petite télé. Si elle pouvait tenir sur mon bureau, tout serait beaucoup plus simple!
Vu qu'elle marchait il n'y a pas si longtemps, et qu'elle s'est arrêtée d'un coup après l'avoir manipulée, j'ai refait toutes les soudures THT, neck board et connecteurs. La suite très vite!

Ok, la télé ne fonctionne pas mieux (pour le moment), retour à nos oetites affaires.
Il s'agit ici de faire du vol de cycles CPU pour aller taper la SRAM en cachette.
Ce modèle de SRAM a des temps d'accès de 150 nanosecondes (1 ns = 1/1000 de microseconde). Entre deux lectures/écritures sur le bus, je n'ai pas relevé plus de 660ns. La préparation de lecture prenant 15ns, on va dire que toute ma bidouille doit tenir dans 600ns. Pour avoir une idée de pourquoi j'utilise ici des portes logiques et pas un microcontrôleur, cela représente 10 cycles d'horloge à 16MHz, donc environ 5 instructions en langage machine!
En prenant un peu de marge, je pense pouvoir boucler la boucle en environ 300ns.
Pour ordonnancer les opérations, il me faudrait un oscillateur à 20MHz et un diviseur d'horloge / compteur.
Pour compliquer les choses, je ne dispose pas d'un oscillateur, mais directement de quartz de 20MHz.
J'ai passé un bon moment à mettre en place un oscillateur à quartz avec des portes logiques inverseuses, et le résultat est une sinusoïde à 20MHz entre -2V et 6.8V, alors que je sors d'une porte TTL (je devrais avoir une onde carrée entre 0 et 5V). Je suis dubitatif. Le quartz entrant en raisonnance provoque naturellement une explosion d'amplitude, et j'ai un peu peur pour les circuits qui vont suivre. Ayant un oscilloscope avec une bande passante de 50MHz, il est possible qu'un carré apparaisse arrondi, si les harmoniques du signal sont hors bande passante. Ajoutons à cela qu'à ces fréquences, il commence à y avoir des phénomènes parasites liés au fait que je travaille sur une bread board toute pourrie.
Côté diviseur, j'ai des circuits compteurs base 10 qui me plaisaient bien, mais je m'aperçois qu'ils ont une fréquence d'opération maximum de 5MHz. Raté.
Du coup, je fais un test avec une bascule RS, beaucoup plus rapide (beaucoup beaucoup). Une bascule peut facilement diviser une fréquence par 2. Avec 2 bascules, on divise par 4. Ca le permet d'obtenir un top à 50ns (mise à disposition des données sur le bus), et un à 200ns (150ns écoulées, temps de réponse de la SRAM).
Sur le papier, c'est parfait. Dans la vraie vie, j'ai une oscillation instable à 10MHz. Il lui arrive de sauter à 20MHz sans que je comprenne pourquoi.
Je pense que c'est lié au signal d'horloge de la bascule, qui atteint des valeurs hors limites des specs de la bascule.
Je vais voir si je ne trouverais pas un oscillateur 20MHz tput prêt, ce serait sûrement plus fiable et ça prendrait moins de place!

Salut bouz je viens de lire ton dernier post (j’ai rien bité) puis j’ai lu l’intégralité de ton topic que je trouve intéressant et impressionnant. Je me demandais du coup ce que tu fais dans la vie et qu’elle formation tu as suivi pour te débrouiller de la sorte.

Hello, c'est gentil. Désolé du fait que tu n'aies rien compris. J'étais parti dans une démarche plus didactique pour mes travaux sur le signal de synchro vidéo, mais vu le peu d'attrait pour le sujet, je suis passé en mode rapide :-/.
Pour ce bricolage en particulier, je vais essayer de faire un effort de présentation pour montrer comment se fait un accès à la SRAM par le PCB, à quel moment je vais caser mes propres accès, et comment je compte m'y prendre.
Concernant ma formation, c'est de l'informatique, télécom, réseaux et services. Dans les faits, je n'ai jamais bossé là-dedans, et aujorud'hui je fais plutôt du management.
Pour ce qui est de l'électronique, je m'y suis mis il y a 3 ans avec un kit Arduino, et je me suis ouvert à plein d'autres trucs, en prenant les jeux vidéo comme fil conducteur. Je suis pas mal de chaînes YouTube sur l'électronique, et j'essaie d'expérimenter pas mal autour des circuits intégrés (portes logiques, buffers, ...), connectés à des microcontrôleurs.
Les puristes diront que ce n'est pas de l'électronique, mais de l'informatique (c'est de l'électronique numérique). C'est plus simple à appréhender que l'électronique analogique, il y a beaucoup moins de calculs, et il faut juste connaître quelques principes de base pour ne pas tout faire péter .
En résumé: il faut être curieux, avoir un fil conducteur, essayer des choses, et on progresse assez vite.

Bouz a écrit:Hello, c'est gentil. Désolé du fait que tu n'aies rien compris. J'étais parti dans une démarche plus didactique pour mes travaux sur le signal de synchro vidéo, mais vu le peu d'attrait pour le sujet, je suis passé en mode rapide :-/.

Non non je suis toujours à la lecture. Forcément je prends mon temps pour tout comprendre car forcément c'est pas quotidien. Il est vrai que ces derniers temps c'est un poil moins détaillé mais faut réviser avec les posts précédents pour bien se remettre dedans.
Keep up the fight !

Ok, super, je vais faire des efforts, alors

Alors pour info, pour cadencer tout mon bazar, il me faut un oscillateur à 20MHz.
Pour ça, j'ai 3 solutions sous le coude:

- faire vibrer un quartz de 20MHz, en le couplant à deux portes logiques NOT. C'est ce que j'ai essayé de faire, parce que j'avais justement des quartz de 20MHz. Résultat: de belles oscillations, mais pas d'une stabilité extrême: à la moindre perturbation, la vibration s'arrête et ça me gonfle. Ici: on peut voir le montage. A droite les 2 portes (il y en a 4 dans le boîtier) et le quartz. A gauche, un diviseur d'horloge fait à partir d'un bascule RS pour obtenir un signal à 10MHz (et au milieu, un trou de quand j'ai fait cramer quelque chose.



- Commander un oscillateur autonome: on met du 5V d'un côté, ça sort un beau signal carré à 20MHz de l'autre. J'ai commandé ça, ça prendra peu de place (beaucoup de temps), et ce sera facile à utiliser. Ca ressemble à ça:



- Temporairement, bricoler un oscillateur à 10MHz avec un microcontrôleur ATTiny85. L'idée est d'utiliser le PLL interne pour monter la fréquence d'horloge autour de 20MHz, et de sortir les coups d'horloge sous forme d'alternances sur un pin du microcontrôleur. Ca ne prend pas de place, c'est stable, et surtout, j'ai ce qu'il faut....



Ca permet de générer une horloge en théorie carrée. Je crois que j'atteins encore une fois les limites de mon oscilloscope. On voit notamment ici aussi que je dépasse allègrement les 5V, mais je pense que c'est un souci de compensation sur mes sondes.



Je n'ai que 10MHz au lieu de 20 pour le moment, mais ça devrait me permettre de mettre en place tout le reste du circuit et la logique d'enchaînement des étapes. Vu le temps qu'il va me falloir pour la suite, je devrais recevoir ma commande dans les temps