Delta Island

Et voilà le début de la suite. Pour varier les plaisirs, ce sera KOF97 plutôt que Puzzle Bobble (une chance sur 2).
En résumé: ça marche!

C'est parti pour la partie écriture, maintenant!

L’upload d’un bios valide déjà beaucoup de chose ! Congratulations pour cette validation !
Impatient de voir les prochaines features

Bravo !

Bouz, tu es juste incroyable ! J'adorerais avoir le niveau pour t'aider.

Merci merci!

Et les nouvelles avant d'aller au lit: l'écriture fonctionne aussi, maintenant!

Sur l'ancienne carte, j'utilisais une adresse codée dans un GAL et 8 portes logiques pour décoder l'adresse du port de sortie.
Là, j'utilise une dizaines d'instructions de l'assembleur PIO du Pico, et je peux donner l'adresse que je veux dynamiquement!
Bon, ça ne sert à rien, alors ça va être tout le temps 0xffff . En tout cas, ce machin est puissant.

Sur l'ancienne carte, j'avais aussi un port d'entrée. Je pouvais lire word par word (16 bits), et je devais me synchroniser avec le port de sortie pour gérer le flux de données word par word. Ca compliquait le code microcontrôleur, et le code 68000.
Ici, vu que je peux écrire dans la mémoire en live sans interrompre le 68000, je n'ai plus besoin de port d'entrée. Je peux streamer du contenu les doigts dans le nez.

Conclusion: les choses vont être plus simples à appréhender niveau code avec cette carte.

Par contre, ça veut dire que je dois réécrire tout le code microcontrôleur et le code PC.
Je vais voir si je continue à galérer avec l'USB natif du Pico ou si je m'amuse avec son portage TinyUSB.

En tout cas, l'électronique est OK. La suite, ce sera le code PC à revoir, a minima pour pouvoir envoyer facilement des images de ROM dans le Pico, pouvoir les basculer dans l'un des 8 slots réservés dans la mémoire flash, et les swapper à chaud.

Derrière, j'ai plusieurs options sympa:
- Ecrire du code de diag qui remonte les résultats au PC via le port USB
- Forker le code du NeoDiag pour remonter les résultats au PC via le port USB
- La surprise du chef: l'un ou l'autre des deux premières options, mais avec un affichage sur un écran OLED connecté à la carte (j'ai prévu une connectique I2C)

A suivre, mais ça ne va pas casser des briques côté démos tant que je n'ai pas assez avancé. Je suis preneur d'avis concernant les options, par contre .

Derrière, j'ai plusieurs options sympa:
- Ecrire du code de diag qui remonte les résultats au PC via le port USB
- Forker le code du NeoDiag pour remonter les résultats au PC via le port USB
- La surprise du chef: l'un ou l'autre des deux premières options, mais avec un affichage sur un écran OLED connecté à la carte (j'ai prévu une connectique I2C)

Excellent !

J’aurais ajouté une fonction wifi avec un pico W ou autre dispositif wifi connecté à ta board (esp8266 ?)
L’esp8266 est compatible I2C

Tu disposes de combien d’espace sur ta flash dédier au stockage du bios ?

Moi je vote pour l'écran en I2C!
Avoir ton propre code de diag serait intéressant s'il complète celui du neodiag. On aurait un combo énorme !

Xrider a écrit : sam. 3 févr. 2024 06:47 J’aurais ajouté une fonction wifi avec un pico W ou autre dispositif wifi connecté à ta board (esp8266 ?)
L’esp8266 est compatible I2C

Tu disposes de combien d’espace sur ta flash dédier au stockage du bios ?

Je me suis posé la question pour le WIFI, mais je n'ai pas trouvé d'usage intéressant. Cela dit, en effet, avec du I2C, on peut brancher à peu près n'importe quoi (y compris un module Bluetooth / Wifi?).
On peut même imaginer connecter des manettes sans fil directement sur la ROM avec un patch sur la ROM système .

En termes de mémoire flash, on a 2 Mo en tout sur l'EPROM que j'ai choisie. Le code fera quelques ko, ce qui laisse pas mal de place pour mettre des choses. Sachant qu'une ROM fait 128Ko, j'ai écrit un peu de code pour flasher des ROM dans 8 slots potentiels, soit 1Mo. La carte copie par défaut le premier slot au démarrage.

ragefan a écrit : sam. 3 févr. 2024 08:54 Moi je vote pour l'écran en I2C!
Avoir ton propre code de diag serait intéressant s'il complète celui du neodiag. On aurait un combo énorme !

L'écran I2C pourrait être cool pour faire sortir le résultat des diag sans avoir besoin d'un PC à à côté. Et ça évite d'avoir une appli à installer / compiler sur le PC, ce qui peut faire peur à juste titre.
On peut aussi envisager de se passer d'appli et de parler directement à la carte via un terminal série, tout est envisageable! (je viens d'y penser)
Ca ne facilite pas l'envoi de ROM dans les tuyaux, par contre.
Il faut que j'y réfléchisse un peu plus...

Dans l'immédiat, je vais voir ce qu'on peut faire d'intéressant avec TinyUSB...

Ppur l'interface, après moult réflexions, je vais virer l'outil que j'avais fait sur PC.
Vu que j'ai un microcontrôleur digne de ce nom, j'ai décidé d'utiliser un terminal à la place! C'est le microcontrôleur qui va dépatouiller les paramètres et afficher une interface. Ce sera BEAUCOUP plus simple à la sortie!

Nous voilà donc avec n'importe quel terminal (celui de l'Arduino, celui de VS Code, Putty, ...
Pour l'envoi de ROM, ça pourra se faire par bête oigne de commande (type fichier.rom > COM4).
Je verrai s'il faut càbler du XModem ou autre, mais pour accompagner du dev de BIOS depuis VS Code, ça devrait bien faire l'affaire.

On avance...
L'envoi d'images ROM est câblée. J'ai perdu ENORMEMENT de temps à cause de cette cochonnerie de gestion des ports COM par Windows.
La stack USB du Pico est basée sur TinyUSB. Elle utilise la ligne DTR pour détecter la présence d'un host en face de la liaison série virtuelle.
Aucun problème dans un terminal (Putty, VS Code, Arduino, ...). Par contre, pour pousser du fichier en ligne de commande, quelle que soit la manière dont le port est configuré, on peut oublier le DTR.
J'arrivais donc à ouvrir la ligne pour échanger avec le terminal, mais pas pour envoyer des fichiers.
Je suis allé voir comment ça se passait quelques niveaux en-dessous, et j'ai fait en sorte que l'appli embarquée puisse fonctionner sans DTR (elle considère alors qu'elle est alimentée par une ligne de commande).
Ca me permet de faire des mini scripts de 2 lignes pour envoyer des images de ROM et les stocker dans les banks flash du microcontrôleur.

Je viens de tester un petit batch qui permet de:
- Envoyer une commande SendROM
- Envoyer le contenu de la ROM derrière
- Stocker la ROM dans un banc flash
- Et faire ça 4 fois en tout pour stocker 4 ROMs

Le tout tourne en 10 secondes (soit 2,5 secondes par ROM).
Je vais me détendre avec un peu de boulot sur la visu de l'activité sur la LED embarquée, en jouant avec les timers et les interruptions.
Après, ce sera le moment de gérer un ring buffer pour les données qui remontent du slot vers le microcontrôleur.
Et après, il faudra retourner à l'assembleur 68000 . J'aimerais monter un environnement qui permette d'assembler la ROM de diag et faire des tests avec. Apparemment, on utilise le même assembleur.

Et les nouvelles du jour (et d'hier, du coup)...

- La LED indique bien des trucs via les timers du microcontrôleur, c'est... élégant .
- Le ring buffer est en place. La NeoGeo pourra exporter des données à fond les manettes. J'ai fait un mix de PIO et de DMA pour alimenter un ring buffer de 4ko pour stocker tout ce qu'elle essaiera de m'envoyer. Ca ne fait pas intervenir le CPU, alors ça dépote et on ne rate rien. Dans la version précédente, il fallait envoyer 16 bits et répondre dans l'autre port qu'on les avait bien récupérés.
- Une nouvelle commande pour récupérer un mot de 16 bits (il faut que j'en fasse une pour en récupérer n)

Et à côté de ça, j'ai récupéré l'environnement pour compiler le NeoDiag nouvelle version, je l'ai modifié pour compiler sous Windows (la galère), et j'ai modifié le Makefile pour pouvoir envoyer le résultat de la compilation directement sur le BricoNeo.
Ce soir, je vais passer un petit moment pour voir si je peux activer un "mode debug", qui permettrait d'enregistrer dans le ring buffer un log de 2048 adresses appelées sur la ROM par le 68000.
Ca peut être intéressant, par exemple, pour savoir par où le code est passé après un crash, pour debuffer une séquence louche ou pour hacker un jeu .

Après ça, il faudra que je me résigne à remonter me geler dans mon grenier et à attaquer la partie 68000!
Comme avec la version précédente, je pense attaquer les sujets suivants dans l'ordre:
- Test de la WRAM (pour pouvoir l'utiliser après)
- Moniteur mémoire pour pouvoir se balader de partout dans l'espace d'adressage du 68000 (de manière interactive, avec cette nouvelle manière d'interagir avec le BricoNeo)
- Test des contrôleurs

Après ça, on verra pour de nouveaux tests, ou pour m'interfacer avec le NeoDiag, je ne sais pas encore.

Incroyable !
Tu saurais par exemple dire où le 68k s'est arrêté dans le cas d'un click of death afin de debugger plus facilement ?