[WIP 100%] Projet BricoNeo - Entrées et sorties via le connecteur de la ROM système

[Bouz]

C'est incroyable ! Et l'usage est d'une facilité déconcertante ! Bouz, tu as fais une énorme réalisation pour le monde de la neo-geo.

Tu indiques dans la vidéo que l'on pourrait voir l'état des registres en temps réel ? Je pense que cette fonctionnalité pourrait énormément servir à debugger des puces custom HS non ?

Prévois-tu de publier le code en open source ?

Merci, en effet, c'est plus facile qu'avec la première version .

Ce que j'explique à moitié, c'est que...
- L'extension Memory Dump permet d'afficher le contenu de n'importe quelle zone de la memory map du 68000. On spécifie juste une adresse et une taille à récupérer
- La syntaxe "*ext" permet de lancer une extension en boucle
- La syntaxe "**ext" permet de faire la même chose, mais en rafraîchissant l'écran à chaque boucle, et seulement si le résultat change
Si on met tout ça bout bout, on peut demander en boucle l'affichage de l'adresse d'un "memory mapped register" et observer ses changements de valeur. C'est intéressant en l'occurrence pour les entrées (tout ce qui est NEO-C1), pour voir l'état des boutons, le type de slot détecté, les DIP, ...

Après, pour de la réparation, je ne sais pas à quel point ça peut être utile. Il faut plus probablement aller écrire dans les registres pour déclencher des écritures en VRAM, et aller les relire via les registres. Et ça, ça nécessite du code 68000.

Hop, tu m'as inspiré!
=>
Si on veut éviter de passer par la case 68000, je peux aussi écrire une nouvelle extension, qui permettent d'écrire un word à une adresse donnée! Le terminal permet actuellement de copier-coller un script depuis un notepad quelconque. Ca permettrait d'écrire une bête séquence d'écritures en mémoire et de lecture de résultats dans un fichier texte, et de le coller dans le terminal!

Copier-coller, et ça marche direct

Reste donc à faire...
- L'extension pour écrire un word en mémoire (pas trop compliqué).
- La syntaxe pour ignorer une commande. Histoire de pouvoir mettre des commentaires dans le script, sinon ça va être l'enfer!

Tiens, en bonus, vu que je pense en envoyer aux copains bricoleurs tôt ou tard pour faire des tests, j'ai ajouté une commande "BootSel" qui permet de passer la carte en mode MAJ du firmware sans avoir à mettre une pastille de 1mm² à la masse sur la carte. Comme ça, je pourrai envoyer des MAJ du firmware par e-mail ou autre.

Et pour répondre à ta question, oui, le code sera libre, sinon le projet n'a pas un grand intérêt. Pour le moment, je dois encore pas mal bosser sur le firmware. Ca n'empêche pas du tout de développer du code 68000, qui n'a rien de spécifique au BricoNeo (juste l'adresse du port de sortie en plus, finalement).

[ragefan]

Super top
J'ai plein de mvs avec des pannes différentes donc je peux t'aider à tester à l'occasion si tu le souhaites. Effectivement, mettre la partie 68k en open source pour commencer permettrait d'enrichir la bibliothèque des tests par la communauté !

[Bouz]

Doucement quand même avec l'opensource, on va déjà essayer de faire une base qui marche .

Voilà déjà les commentaires, avec la coloration syntaxique du pauvre. Mais je peux aller me coucher l'esprit libre!

[Bouz]

En tout cas, quand j'aurai fini de jouer avec les cartes MV1AX de Xrider, il me restera...
Ces 5 cartes 4 slots HS (4 en fait, une carte est réservée).
Je suis bien content d'en avoir enfin à moi pour bricoler dessus sans crainte de les rendre pire que quand on le me les a données!

[Xrider]

En tout cas, quand j'aurai fini de jouer avec les cartes MV1AX de Xrider, il me restera...
Ces 5 cartes 4 slots HS (4 en fait, une carte est réservée).
Je suis bien content d'en avoir enfin à moi pour bricoler dessus sans crainte de les rendre pire que quand on le me les a données!

WHouaaaa

[Bouz]

Je viens de passer 2h intéressantes...
- 1h15 pour assembler une nouvelle carte BricoNeo (c'est long, il y a du monde à souder)
- 45 minutes à comprendre pourquoi la carte ne voulait démarrer que via le debugger.

Je n'ai pas vraiment tout compris, mais il s'avère que les 4 autres PCB ne semblent fonctionner qu'en overclock 200MHz là où le mien tournait sans problème à 250MHz.
Etant donné que les buffers étaient aux fraises et ne répondaient qu'en 20ns, j'avais de toute manière mis une temporisation de 5 cycles au moment de l'accès au bus d'adresses. J'ai réduit la remporisation et je peux faire tourner une NeoGeo avec un Metal Slug sous UniBios à 200MHz.
Ce sera probablement plus stable pour tout le monde, alors tant mieux. Voilà donc la nouvelle vitesse officielle: 200MHz .

[Illusionrip]

Hâte de tester tout ça

[Bouz]

Aujourd'hui, j'ai fait quelques travaux nécessaires pour simplifier le boulot par la suite.
Voilà le bilan (pour le moment, mais il faudrait que je fasse autre chose de ma journée!):

- Intégration automatique des "extensions" (les commandes intégrées à la ROM, côté 68000) à la liste des commandes disponibles dans le BricoNeo, avec un alias (et plus un numéro, comme avant). L'idée étant de pouvoir élargir le "vocabulaire" du BricoNeo super facilement et de rendre d'éventuels scripts plus clairs.
- Ajout d'une macro de déclaration des extensions côté 68000 (démo plus loin!). On fournit l'adresse de la nouvelle fonction, son type de retour, son alias et sa description, et la macro s'occupe d'aménager proprement la mémoire pour stocker tout ça proprement.
- Par effet de bord, j'ai corrigé les soucis d'alignement mémoire quand les descriptions d'extensions avaient un nombre pair de caractères (ce qui faisait un nombre impair avec le 0 final). C'est la macro qui gère.
- Le type de retour étant intégré au moment de la déclaration de l'extension (macro), il n'est plus nécessaire pour l'extension de le retourner au BricoNeo, donc plus de code 68000 pour faire ça.
- Anecdotique: la commande ReadWords retourne l'intégralité du buffer d'entrée, plus besoin de passer une taille en paramètre. Ca ne servait à rien et ça bloquait potentiellement le microcontrôleur si le buffer n'était pas assez plein. Pas sûr que cette fonction serve encore à quelque chose maintenant que le système d'extensions génériques est codé, par contre!
- Revue de la mécanique de listage et d'instanciation des commandes. Ca m'a permis de fusionner les commandes buildin et les extensions, mais aussi de simplifier la déclaration de nouvelles commandes builtin, qui nécessitait un gros switch/case tout pénible à maintenir. Vive le C++...

Pour vous donner une idée, j'ai mis 2 minutes à créer l'extension permettant d'écrire un word dans la mémoire de la Neo à l'adresse voulue.
Le code 68000 est devenu minimaliste:

Voilà le code

Voilà la manière de déclarer l'extention, toujours côté 68000:

Pensez à remplir votre déclaration

Avec cette nouvelle extension et la possibilité de coller du script on peut coder n'importe quel test en écrivant n'importe où dans l'espace d'adressage et en allant lire ailleurs (ou en regardant l'écran).
Ca, c'est si on n'a pas envie d'écrire une ligne d'assembleur 68000 .

Du script (avec des fautes de frappe),

[Xrider]

Belle consolidation, ca sent la release !

[Bouz]

Belle consolidation, ca sent la release !

Release du code, non, pas tout de suite. Mais je vais en envoyer une à @Illusionrip pour test. Il répare de la NeoGeo à tour de bras, et c'est un ancien codeur 68000 sur Amiga. De bons critères pour démarrer!

Côté firmware du BricoNeo, il est pleinement opérationnel. Pas de besoin immédiat de libérer du code.
Côté ROM 68000, il y a du boulot pour développer des tests, ou adapter la ROM NeoDiag pour la faire sortir sur la console série. Je ne suis pas bien fort pour fournir un environnement 68000, alors on va devoir commencer en faisant un peu de bricolage.

Par contre, en l'état, la ROM que j'ai développée devrait pouvoir permettre de tester à peu près n'importe quoi en balançant du script dans la console série! C'est ce que je considère comme un MVP .

Les prochaines étapes sont donc...
- réception de la carte par IllusionRip
- tests de son côté
- préparation du repo GitHub qui recevra le code assembleur 68000
- préparation du code C++ BricoNeo pour le RP2040 pour l'envoyer aussi sur GitHub?

Et je pense qu'il faudra un minimum de documentation si on veut embarquer du monde sur cette carte (un Readme.md sur GitHub?) et peut-être un topic dédié pour les échanges et l'assistance sur un forum?

[Bouz]

Un premier proto a quitté le nid, l'aventure commence pour lui

[Illusionrip]

petit proto deviendra grand