Delta Island

J'ain un raspberry tout court et une machine linux si besoin

L'idée serait de tester l'émulation de stockage de masse que je suis en train de coder.
En gros, quand on branche le BricoNeo sur un ordinateur, il est vu comme une interface série et un disque. Si on droppe une ROM sur le disque, ça fait booter la NeoGeo dessus. Encore plus simple qu'avec un port série.
Ca, c'est la théorie.
Dans la pratique, je veux aller un peu au-delà de ça, et ça m'oblige à bricoler de la FAT à la main. Ma patience me surprend, c'est infernal .
Etant donné le bricolage, je voudrais être sûr de la séquence d'écriture sur le support par les differents OS.
Sous Windows, c'est:
- écriture dans le Root Directory
- écriture dans la FAT
- écriture des clusters
- mise à jour de la taille dans le Root Directory
Cet ordre me va très bien pour rerouter les écritures de clusters au bon endroit suivant le type de fichier copié. Mais pas sûr que ça fonctionne partout.
Encore du boulot en perspective.

Sous linux, tu devrais monter la partition quand tu branches le brico en USB en lui indiquant à la main de quel type elle est. Ensuite, il faudrait vérifier si l'écriture FAT bas niveau se fait de la même façon à travers l'os où s'il faut passer par des séquences additionnelles. Tu n'as pas une librairie de plus haut niveau pour faire ça plus facilement ?

j'ai oublie de préciser, moi c'est pico + Mac

je suis en france, et je serai de retour a la maison début de semaine prochaine

Je vais debugger cet enfer, et je vous enverrai une image à mettre sur le Pico pour tester (c'est juste un copier-coller sur le Pico démarré en mode mass storage avec le bouton). Il va rebooter en mode mass storage de moi et pn pourra tenter quelques trucs .

Et sinon, non, je ne peux pas utiliser de bibliothèques de plus haut niveau.
Le système FAT est géré totalement pas le système hôte (le PC). Je ne reçois que des commandes de lecture et d'écriture de blocs, que j'interprète à la volée. Ca me permet de virtualiser le disque et d'aller, par exemple, écrire directement à l'emplacement de la ROM lue par la NeoGeo par la suite.
L'alternative serait de gérer un disque assez gros pour écrire une ROM complète, mais... ça me prendrait seulement pour les clusters de données 128ko en plus des 128ko déjà alloués à la ROM. Le RP2040 ne dispose que de 256ko de RAM, donc ça ne rentre pas .

Il faut que je debugge mon code, puis je testerai ça avec une NeoGeo allumée à côté. Ne serait-ce que pour voir si elle reste stable pendant que le système accède au disque (ce qu'il fait joyeusement, même quand on ne lui demande rien). Je veux m'assurer que le bus n'est pas bloqué je ne sais comment et que les canaux DMA continuent de tourner correctement.

Après ça, je pense que je vais pouvoir (enfin) commencer à coder utile pour essayer de réparer le slot de Xrider .

Felicitations Aurélien

Bouz a écrit : mar. 2 avr. 2024 22:34

Après ça, je pense que je vais pouvoir (enfin) commencer à coder utile pour essayer de réparer le slot de Xrider .

Impatient de voir la bête en action sur mes 2 slots en PLS

OK, on dirait que j'ai enfin compris comment fonctionne la déclaration de l'occupation des clusters dans la FAT12. J'ai trouvé plusieurs docs qui se contredisent, et j'ai fini par faire des expériences. C'était bien éprouvant.
L'avantage, c'est que j'ai pu poser une couche d'abstraction entre la FAT et ce que j'appelle la VFAT. Sur le principe de la VRAM, je vais avoir
- une partie des clusters dans la RAM "conventionnelle", réservée aux petits fichiers (de logs) et aux arborescences
- et une partie des clusters dans la RAM "ROM", réservée à l'image utilisée par la NeoGeo

J'ai fait sauter le code de décodage pendant mes longues séances de debug, mais je vais maintenant pouvoir le remettre!
En attendant, c'est rigolo, je sais enfin écrire sur ce disque!

On t’as déjà dit que t’étais un ouf

Illusionrip a écrit : ven. 5 avr. 2024 07:54 On t’as déjà dit que t’étais un ouf

Rétrospectivement, c'est vrai que c'est arrivé .

Progrès du jour, bonjour!
Voilà la tête du lecteur qui est automatiquement monté quand on connecte la carte au port USB.
En parallèle, on peut toujours utiliser Putty ou n'importe quel terminal série pour parler avec la carte.
On a toutes les fonctionnalités d'avant, mais maintenant, en plus, quand on copie une ROM dans le répertoire CURRENT.ROM, elle est injectée dans la section de la RAM qui est accédée directement par la NeoGeo. Plus besoin de se déconnecter du terminal pour transférer une image de ROM!
J'en ai profité pour ajouter quelques rafinements. Voilà globalement ce que ça permet de faire dans l'immédiat (il y aura peut-être plus un peu plus tard, mais c'est moins prioritaire):
- Ouvrir un joli fichier README.TXT qui indique comment ça marche (limité à 512 octets, il va falloir être concis!)
- Injecter une image de ROM dans le simulateur d'EPROM => on peut booter la NeoGeo sur une ROM juste en la copiant dans un répertoire
- Injecter une image de ROM dans l'une des 8 banques supplémentaires, persistées dans la mémoire flash de la carte. On peut ensuite basculer d'un banc à l'autre avec le terminal. La banque 0 est rechargée automatiquement à la mise sous tension de la carte
- Faire du byteswap (ou non, comme on veut) au moment de l'injection. Sur NeoGeo, il faut inverser les octets pairs et impairs des ROMs (endianness, ROM 16 bits, ...). On peut balancer les ROM officielles directement. Pour les ROM compilées "maison", il suffit de remplacer l'extension ".bin" en ".nib" pour que ça réalise le byteswap tout seul en fin de copie.
- Résultat des courses, pour développer des tests ou autre chose sur NeoGeo, il suffit d'ouvrir un terminal pour piloter le lancement des tests, et de faire pointer la sortie de build 68000 vers le répertoire CURRENT.ROM de la carte.
Dans le reste à faire, j'aimerais juste ajouter un fichier "RESULT.TXT" à la racine (ou quelque chose qui ressemble) qui renvoie l'état de la dernière opération (image byteswappée, transférée dans telle banque, de telle taille, ...).
Dans les trucs qui m'embêtent, je dois virer l'image ROM du répertoire après l'upload pour ne pas faire n'importe quoi avec la virtualisation du contenu du disque. La mécanique pour forcer un refresh côté hote USB n'est pas câblée dans TinyUSB. Je dois donc éjecter et réinsérer virtuellement le disque à chaque copie. Sous Windows, ça veut dire que la fenêtre se ferme et se réouvre à chaque copie. Je l'ai mise dans un coin et ça ne me dérange pas, mais ça peut être pénible sur d'autres plateformes.

J'adore le clin d'oeil : COUCOU - DELTA - ISLAND

Ne lache rien, super avancée

Xrider a écrit : sam. 6 avr. 2024 14:43 Ne lache rien, super avancée

J'ai corrigé un bug, viré les fuites mémoire et ajouté une commande ee reset.
Pour cette dernière, vu que je ne tire plus de fil entre la carte et le gestionnaire d'alimentation des MVS, je me contenterai d'un "watchdog reset" pour voir. En gros, c'est une temporisation de blocage des PIO pour que le système plante....

Je ne vais plus tarder à tester ça sur le vrai matériel pour voir ce que ca apporte.
Je me tâte à coder une petite extension de test des contrôleurs. Ca me permettrait de faire une suite à la petite vidéo de démo de la première version de la carte.

Mais j'ai aussi des tests de GBS8100 à faire, et le week-end n'est pas extensible .

Ahah, impatient de voir un de mes slots sur le billard