Delta Island

Hello! J'aimerais vraiment régler ce problème sous Linux avant de commencer à laisser partir des cartes. Il me faut quasi 1h30 pour assembler une carte, amors si je m'aperçois d'un defaut de conception qui m'oblige à en.produire de nouvelles,je vais avoir bien les boules .
Je suis en train de boucler le projet de carte pour le GBS8100 et je reviens sur ce projet. Je crois que ie fais un peu trop de choses en parallèle (ou du moins j'essaie!).

Sinon, oui, merci de me suivre depuis longtemps, c'est donc toi . N'hésite pas à aller te présenter dans le topic dédié pour nous raconter un peu ce que tu fais et nousontrer tes oeuvres! Ca fait toujours plaisir de se faire de nouveaux copains!

Et un petit update de la situation pré-gastro...
Je le suis amusé avec le Raspberry Pi 400 de ma fille pour essayer de comprendre pourquoi il était acrobatique de copier une ROM sur le BricoNeo via le mass storage sous Linux / Mac OS (merci @Illusionrip), alors que tout roule depuis un PC Windows.
J'ai donc activé tout plein de traces de debug que j'avais codées lors de la mise au point du driver rigolo que j'avais codé via TinyUSB pour faire du FAT12, et j'ai fini par comprendre.
Il y a potentiellement un souci avec le cache OS qui ne s'occupe pas trop de l'état du mass storage. Je reviendrai dessus quand le reste marchera, il y a peut-être une ligne à ajouter dans le fstab.
Le souci immédiat est l'ordre de mise à jour des clusters, qui n'est pas le même sur les 2-3 OS.
Sous Windows, quand on copie un fichier sur la carte, l'OS écrit les métadonnées du fichiers dans le répertoire, puis réserve les clusters nécessaires dans la FAT, et enfin il remplit les clusters en séquence. Je me contente de compter les clusters en ajustant les adresses d'arrivée en RAM, et de finir le transfert quand le dernier cluster est écrit.
- Sous Linux, à creuser, mais en gros, on met à jour le répertoire, puis on alloue les clusters dans la FAT un par un durant le transfert. Donc ma feinte de compter les clusters ne marche pas.
En plus, il doit y avoir un souci dans l'identification du répertoire d'arrivée, parce que même avec ce bug, la ROM devrait être visible depuis le BricoNeo (les extensions), mais ce n'est pas le cas.

Windows et Linux cohabitent pour trouver les bugs dans la copie de ROM depuis Linux!
Une version potentiellement corrigée est partie chez l'ami @Illusionrip pour faire un petit test sur Mac!

... et ça ne fonctionne pas, il va falloir chercher encore un peu .

De toute façon , les utilisateurs de Mac c’est des loosers

Illusionrip a écrit : sam. 13 juil. 2024 18:33 De toute façon , les utilisateurs de Mac c’est des loosers

Je ne suis pas là pour juger (en plus, je crois que Xrider est sur Mac aussi et je ne veux pas avoir de problèmes)

Et m…. Je vais me faire ban

Bon alors les mac users c’est des loosers mais seulement en Pologne

Beau rattrapage, bonne chance!

Mdr
Je vous confirme que je suis sur Mac OSX, mais que j’ai toujours un Windows à proximité

La stabilité des Mac et loin devant les systèmes Windows.
OSX est développé autour des systèmes Apple avec des architectures dédiées, à cela on rajoute que OSX est basé sur Linux, et on obtient un cocktail de stabilité accrue

Windows, OSX, Linux… du moment que ça répond aux besoins et qu’on arrive à développer des choses intéressantes, alors on est tous gagnants

c'est ce que j'essaye d'expliquer a mon responsable informatique pro windows qui ne comprend pas mon chois pour OS X (je suis le seul dans la boite)
soit disant on peut pas develloper

C’est tout le problème…

L’innovation est souvent confrontée à une résistance initiale.

Arthur Schopenhauer, philosophe du 19e siècle, a formulé une observation pertinente :

« Toute vérité passe par trois étapes, d’abord elle est ridiculisée, ensuite elle est violemment combattue et enfin elle est acceptée comme une évidence. »

Vivra t’il assez longtemps pour arriver à la troisième phase