[Projet] Cartouche de développement Wonderswan - Page 2

Le code de madeleine, partant de la base de WonderMadeleine a completement changé, c'est une quasi complete réecriture.. :/

Raison de plus pour le tester

Oui et la version public tant qu'a faire, la version privé je me doute bien que tu l'a testé

Sinon pour le problème des LE on peut peut etre passer le max V en tqfp 100.

Si on reste sur une solution avec memoire flash donc sans sram et sans pile ca doit encore pouvoir tenir sur le pcb.

J ai encore une question ☺️
Vu que le pcb qu on cherche a faire ne possedera pas de sram, ne pourrais t on pas faire les optimisations suivantes :

-supprimer la partie qui clone le registre C1? Ca permettrai de gagner beaucoup de LE ( passage de 149 a 102), 47% de libre.

-Pour le registre C0 baisser sa capacités de 8 à 6 bits.

Si il n'ya pas de SRAM il ne me parait pas utile de laisser le registre qui contrôle ses banks.

Ça me semble raisonnable.

X-deathL J'ai une proposition si ca t’intéresse et si tu veux faire ce projet de manière collaborative, je suis prêt a travailler sur le code pour le CPLD
- ca permettra probablement d'aller plus vite vu que je connais mieux le hardware de la swan
- j'ai déjà du code qui réduit grandement le nombre de LE utilisé sans pertes de fonctionnalités, le code présent sur github est clairement mauvais (hint: c'est le promier "gros" projet sur lequel j'ai travaillé en VHDL, il marche mais n'est pas vraiment ce qu'on peux faire de mieux
- ca resouds un probleme avec la license de WonderMadeleine

Réduire le nombre de bit: oui il faut le faire, de toute manière ta flash n'as probablement pas assez de bit adresses pour que les registres soient utilisé a leur utilisation maximum, mais ce n'est pas la ou il faut optimiser en premier de toute maniere (il faudra mais ca n'a de sens que quand le hardware est finalisé. Tu peux laisser l'optimiser supprimer les bits inutiles par juste ne pas mapper ceux-ci vers des broches. L'avantage c'est que tu ne touche pas au code (ok on peux utiliser des generic pour ca mais crotte XD )

Il faut absolument pouvoir mapper la flash a 0010:xxxx, et ne pas le faire de manière permanente (ce qu'on ne peux pas faire pour des raisons techniques)

J'ai le code pour gérer la transition de la flash, mais n'est pas du tout dans le code que tu as dans les main.

Et surtout ca ne me derange pas du tout de bosser dessus, au contraire a m'amuse!
Par contre je te laisse voir avec zero pour tout le reste

Godzil (./37) :
X-deathL J'ai une proposition si ca t’intéresse et si tu veux faire ce projet de manière collaborative, je suis prêt a travailler sur le code pour le CPLD

Ce projet est collaboratif , Je pense que les 2 pages de ce topic est un bon exemple .
J'accepte volontiers les remarques / suggestions et l'aide de ce jeux qui veulent prendre le temps de faire avancer ce projet.
D'ailleurs je suis en train de regarder pour le connecteur mini USB et quelle épaisseur de PCB prendre.

Godzil (./37) :
- ca permettra probablement d'aller plus vite vu que je connais mieux le hardware de la swan

Oui clairement

Godzil (./37) :
- j'ai déjà du code qui réduit grandement le nombre de LE utilisé sans pertes de fonctionnalités, le code présent sur github est clairement mauvais (hint: c'est le promier "gros" projet sur lequel j'ai travaillé en VHDL, il marche mais n'est pas vraiment ce qu'on peux faire de mieux
- ca resouds un probleme avec la license de WonderMadeleine

Donc le code public fonctionne , ça c'est une bonne chose.
Comme mentionnée au début du premier topic , je souhaite dans tout les cas travailler en open source et donc publier le code du CPLD , je pensai donc que ça ne posai pas de problème avec la licence de la Wondermadeleine ?

Godzil (./37) :
Réduire le nombre de bit: oui il faut le faire, de toute manière ta flash n'as probablement pas assez de bit adresses pour que les registres soient utilisé a leur utilisation maximum, mais ce n'est pas la ou il faut optimiser en premier de toute maniere (il faudra mais ca n'a de sens que quand le hardware est finalisé. Tu peux laisser l'optimiser supprimer les bits inutiles par juste ne pas mapper ceux-ci vers des broches. L'avantage c'est que tu ne touche pas au code (ok on peux utiliser des generic pour ca mais crotte XD )
Il faut absolument pouvoir mapper la flash a 0010:xxxx, et ne pas le faire de manière permanente (ce qu'on ne peux pas faire pour des raisons techniques)

Oui clairement la gestion Flash ne sera pas utilisé à son maximum ( surtout si on reste dans l'idée de diviser la taille utile par deux pour déclencher le Loader par contrôle sur A21 ).
Pour l'optimisation, si la suppression complète du registre de la SRAM est possible sans incidence alors on récupère déjà pas mal de LE.
Elles pourront servir à assurer le contrôle de la Flash et pour la gestion de l' USB et peut être pour l' EEPROM.

Godzil (./37) :
J'ai le code pour gérer la transition de la flash, mais n'est pas du tout dans le code que tu as dans les main.

Oui j'avais remarqué ce point

Godzil (./37) :
Et surtout ca ne me dérange pas du tout de bosser dessus, au contraire a m'amuse!

Merci , J'accepte volontiers ton aide, si les bases du projet te convienne notamment si tu es d'accords de rester en open-source pour le code du CPLD et aussi si tu n'exclue pas d’emblée la gestion de l' EEPROM.
Moi aussi ça m'amuse de bricoler la dessus et j'apprends aussi

Godzil (./37) :
Par contre je te laisse voir avec zero pour tout le reste

J'ai envie d'ouvrir un projet sur Github ( ou autre ? ) parce que entre le schéma , le code du Loader , le code côté PC et le code du CPLD il serai bien d'avoir un endroit qui centralise tout.
Surtout si il y a plusieurs personnes qui travaillent.

Le code wondermadeleine est CC BY-NC-ND

J'ai mes raison d'avoir choisis cette licence et ne compte pas changer la licence pour ce dépôt (WonderMadeleine est un clone "all in" des chip 2001-2003 et n'est pas fait pour être intégré dans d'autre projets, d’où cette licence.)


Pour ton projet, tout ce que je demande c'est que la licence force d'une manière ou d'une autre l'attribution (donc que quelqu'un ne peux pas réutiliser le code en son propre nom)
Le problème avec le VHDL et autre HDLs, il est, sur un produit fini, difficile de dire si tel ou tel code est utilisé contrairement au soft classique.

Une clause non commerciale pour éviter les vampires serait peut être aussi un bonne idée (vampires chinois ou autre)
Aka si quelqu'un fabrique les cartouche que ça soit avec notre accord et conditions.

Pour GitHub ce n'est pas une mauvaise idée, mais il est potentiellement préférable d'avoir des sous dépôts pour chaque parties, Hardware, Software et Hardsoft

Et pour gerer le projet a plusieurs, il faut clairement definir ce qui va sur la carte, les choses peuvent evoluer bien sur, mais c'est surtout ne pas changer tout le concept tous les jours, juste parce que

Franchement bon courage à celui qui pense s'enrichir en vendant des cartouches de Wonderswan ^^
Du coup je te laisse mettre ce que tu veu pour la licence du code CPLD, je peu encore rien décider pour le reste car il est fort possible qu'on utilise une lib déjà existante pour la partie communication PC USB.

Godzil (./39) :
Pour GitHub ce n'est pas une mauvaise idée, mais il est potentiellement préférable d'avoir des sous dépôts pour chaque parties, Hardware, Software et Hardsoft
Et pour gerer le projet a plusieurs, il faut clairement definir ce qui va sur la carte, les choses peuvent évoluer bien sur, mais c'est surtout ne pas changer tout le concept tous les jours, juste parce que

J'ai mis à jour la schématique dans le premier post.
Au niveau du choix et du nombre de composants , ça ne devrai plus trop bouger sauf optimisation de quelques IO et des composants passif.

Pour résumer les fonctions que j'aimerai pour le CPLD ( les fonctions * sont optionnelles seulement si c est possible ):

-Code <= 160 LE
-Simulation du Bandai 2001/2003 sans SRAM , sans RTC et sans GPIO
-Communication avec le FTDI
-Bankswitch de la Flash + contrôle de /WE_ROM
-Activation désactivation du Loader / Loader de secours
-*Gestion de la mise en veille du FTDI ( pour limiter la consommation)
-*Gestion de l' EEPROM

La j'attends de recevoir le FT245 pour commencer à écrire un code et finaliser les IO nécessaires.

Pour la licence je suis d'accord (sauf peut-être pour le "ND", quelqu'un pourrait proposer un truc dérivé intéressant - mais bon, il peut aussi nous contacter dans ce cas), autant mettre tout le projet sous cette licence pour simplifier les choses.
Même si pour les éventuels chinois aux dents longues, je pense malheureusement pas que ce soit le choix de licence qui les arrête

Je ne parle pas de ND pour le projet de X-Death, just "NC" le ND est sur WonderMadeleine parceque je veux pas que le code soit utilisé pour autre chose que faire un clone du bandai (raisons de support principalement)

Certes pour les chinois, mais ca donne toujours un point de discussion/attaque.

Ceci dit je pensais plutot a certains d'europe de l'est que des chinois.... XD

Godzil (./42) :
Je ne parle pas de ND pour le projet de X-Death, just "NC" le ND est sur WonderMadeleine parceque je veux pas que le code soit utilisé pour autre chose que faire un clone du bandai (raisons de support principalement)

Godzil j'aimerai qu'on clarifie ce point sur le NC.
Alors c'est vrai que quand je relie mon premier topic je n'ai pas été très clair sur l'aspect "commerce" , déjà parceque je n'y ai pas trop réfléchi et que j'attends déjà d'avoir un truc qui marche.
Comme dit plus haut je ne cherche pas à me faire du fric mais uniquement à éventuellement vendre le reste du batch à prix que je juge attractif pour ce genre de produit ( <= 30 € ).

Donc si j'ai bien compris tu propose ton aide mais uniquement dans le cadre de la réalisation d'un projet ouvert sous licence et pas à des fins commerciales ?

Non le Non Commercial, ne s'applique pas aux auteurs mais a d'autres. L'idée est que le projet reste Open Source, mais pour que quelqu'un lance une usine de fabrication il (légalement) ne puisse le faire que avec notre autorisation.

Je doute que tu ai envie qu'une usine chinoise ou autre s'approprie le projet et le vende en se faisant des bénéfices et que toi tu ne touche absolument rien sur ces bénéfices.

L'idée est juste que si quelqu'un veux faire une fab massive il le fasse sous license. Si le projet est completement open source sans restriction, le premier venu peux prendre les plans et soft, et fabriquer et vendre sans aucun soucis.

Ce n'est pas une obligation, mais je pense qu'on aurais tout interet a choisir un tel modele.

Ok, j'avais le doute et je préférais confirmer.
ça me dérange pas de publier sous licence , faudra trouver celle qui s'applique à notre cas et voir en fonction du code qu'on réutilise.

Mais concrètement, tu vas faire quoi si quelqu'un utilise de manière commercial la solution sans licence ?

Concrètement on parle de la Wonderswan et on projette de faire une cartouche pour d'éventuels développeur avec une faible compatibilités sur les jeux commerciaux.
Si on arrive déjà à en vendre plus de 20 c'est un exploit

J'ai du mal à voir ou est le risque sur cette console, mais encore une fois je veu bien travailler sous licence pour les raisons exposées plus haut.

scpd: en théorie un procès, en pratique tu pleures.

Tu en vendras plus de 20 crois-moi ^^ surtout à bas prix.
Sauf si vous ne voulez pas qu’on communique sur le projet. Mais à mon avis avec des articles MO5-Rom Games et cie + Twitter ça va très vite (et certains sont au taquet concernant la Wonderswan).

Attention, ce n'est PAS une cartouche utilisable pour les jeux.


PS: MO5 n'a jamais parlé de mon projet (qui au final n'a pas une si grande visibilité)

Tu sous estimes le nombre de collectionneur Wonderswan !
Oui, mais si tu le finis et le mets à la vente ils en parleront

Ok on va voir

Bonsoir,
Quelques news ( pas trop tôt ).

1) J'ai bien reçu le FT245 que j'avais commandé il ya quelques mois.



Le but de l'achat était de comprendre comment fonctionne ce composant en mettant au point deux codes:
-Code transfert côté PC
-Code de réception côté console avec envoi de commandes spéciales pour intéragir simplement avec le PC

Côté PC je me suis servi de la librairie Open Source libftdi https://www.intra2net.com/en/developer/libftdi/ qui permet de commander directement sans utiliser les fonctions standard du port série.
Le soft pourras être réutilisé en l'état (avec quelques améliorations/optimisations).

Côté Bus : Ne pouvant pas ( encore ) testé de code sur la Wonderswan j'ai utilisé mon Raspberry pour piloté le bus et écrire un code simple en C qui devra être porté en ASM X86.

Je me suis amusé à faire une petite vidéo qui montre le téléchargement d'une ROM Wonderswan par le Raspberry en commandant le FTDI

2) Maintenant que j'ai un code qui fonctionne j'ai maj la schématique ( lien dans le premier post) du projet avec les IO nécessaires pour le FTDI.

Finalement on a pas besoin de beaucoup d'extra IO pour le pilotage du FTDI :

-Les deux contrôles de Flux /RXF et /TXE comme entrée
-Sortie SIWUA ( je me demande si il est vraiment nécessaire , il n'est pas sur le FT245 , pour moi ce n'est qu'un flush manuel )
-/RD et /WR pourront être reliée directement au pin de la Wonderswan ( à vérifier pour la portée de /WR cf post Godzil sur la gestion de la Flash )

-Entrée USB Sense
Pour que le Loader se déclanche seulement quand l'usb est actif ( sinon ça sera le jeu ) j'ai fait un pont diviseur sur la branche VCC du port USB et la sortie " USb Sense" sera reliée au CPLD et servira de déclancheur.
Il y'a peut être une méthode plus propre.


3)
Côté code du loader ça progresse bien aussi.
Principalement car j'ai réutilisé les fonctions de l'ancien projet de Orion_ et Zerosquare pour l'init et la gestion des fonts
le code détecte la Wonderswan ( Mono ou Color pour le moment) et renvoie vers un Loader approprié

Barmaleikin du discord de Godzil m'a aidé à fixé un bug dans ma routine d'affichage, merci à lui
J'ai fait cet écran test ( non définitif ) pour la version mono.



Il reste encore des bugs et sans surprise je rame bien avec l ASM X86 ^^


Je pense qu'à ce stade il est nécessaire de validé/verrouiller la schématique afin que je puisse poursuivre avec la conception du PCB

Ça me rappelle que ça fait des mois que l'eval board pour FT245 traîne sur mon bureau...

Au fait... verra-t-on X-Death à l'AC 2019 ? C'est l'anniversaire de la sortie de la Wonderswan et Godzil a prévu un stand thématique

Plop,
Le PCB de la cartouche est routé , il est actuellement en cours de relecture et de corrections mineures suite aux remarques de Zerosqaure :

Zerosquare (./56) :
Au fait... verra-t-on X-Death à l'AC 2019 ? C'est l'anniversaire de la sortie de la Wonderswan et Godzil a prévu un stand thématique

Oui 2019 c'est l'année de la WonderSwan
Venir à l'AC je ne suis pas contre mais Congis d'un point de vue logistique ça m'arrange pas trop et le timing risque d'être vraiment court pour avoir une cartouche souder début avril..
Je préfèrerais, si possible faire un stand à la RGC 2019.

Bon prochaine étape après la relecture c'est d'envoyer le premier prototype en fabrication

De toute façon il me semble qu'il y aura aussi un stand Wonderswan de Godzil à la RGC 2019 non ? ^^

Tu es sur d’utiliser KiCAD en mode OpenGL? On dirais le rendu des vielles versions

Sinon attention avec tes plans (de masse?) si tu le fait descendre en dessous des broche du connecteur, si ça remplis la c’est pas terrible. Pour être sur fait en sorte que le plan sur le top se termine plus haut que le connecteur

c'est peut être cairo et pas opengl.