X-death (./13) :
Effectivement , celui-ci est différent il n'utilise pas le mode proprio FT1248 mais va écrire dans une FIFO.
J'ai lu la datasheet et je le trouve bien plus pratique que l'autre car de ce que j'ai compris l'accès à la FIFO se fait de la même manière qu'une mémoire parallèle classique et ça , ça peu vraiment nous arranger .
Il ya également deux pins RXF# et TXF# qui peuvent servir pour le contrôle de Flux.

Oui, après avoir lu la doc, ça semble bien adapté à ce qu'on veut faire.

X-death (./13) :
Je pense qu'il va falloir se contenter d'un accès en 4bit et utiliser les lignes de data restantes pour les pins de contrôle de la FIFO.
L'accès à la FIFO pourrait se faire en utilisant la pin de la SRAM du CPLD ( /CE_SRAM vers /RESET FIFO) ce qui fait qu'on aurait rien deplus à écrire sur le code du CPLD .

Pourquoi se limiter à 4 bits ? On peut connecter directement D0 à D7 au bus de données de la Wonderswan.
Attention, /RESET n'est pas un Chip Select, c'est un vrai reset du composant. En fait il ne semble ne y en avoir de Chip Select (étrangement), du coup il faudra synthétiser des signaux /RD et /WR pour la FIFO à partir des signaux /RD et /WR de la Wonderswan et du décodage d'adresses ; le CPLD peut faire ça facilement. Il faudra aussi relier les signaux /TXE, /RXF, /SIWU et /PWREN au CPLD (on peut mapper ça simplement sur un port I/O inutilisé).
Dommage qu'on ne puisse pas lire le nombre d'octets en attente dans la FIFO. Du coup il faudra tester avant de lire chaque octet, alors que sinon on aurait pu utiliser rep movsb ou rep insb pour faire des transferts rapides.

X-death (./13) :
Dans cette gamme de FTDI il ya deux références très proches FT240 et FT245 vendu 2x plus cher.
Ce dernier utilise une mémoire EEPROM au lieu d'une MTP ce qui permet un cycle de réecriture beaucoup plus importante pour la zone user mais la taille de la FIFO est plus faible ( 128 RX /256 TX au lieu de 512/512 pour le FT240).
Finalement je trouve la version moins chère plus pratique dommage que la mémoire MTP est un cycle aussi faible de réecriture ( 2000 cycles ) sinon on aurait pu laissé les 940 bytes de mémoire pour l'utilisateur (mieu que rien ).

Je pense que la MTP n'est accessible que via USB, donc sans intérêt pour nous. Donc autant prendre un FT240.

X-death (./13) :
Je pense qu’une fois que c'est reconnu par Windows ça doit pouvoir s’accéder directement comme n'importe quel périphérique série.

Oui c'est ça. En fait on peut utiliser soit les fonctions standard pour les ports série, soit une API propriétaire. Il y a un peu plus de boulot si on utilise l'émulation de port série (surtout si on veut que ce soit asynchrone), mais ça se fait.

X-death (./13) :
SI le FT240 est conforme sa zone memory user peut aussi être utilisé vu que ça sera qu'en lecture.

Voir ci-dessus : je ne pense pas que ce soit accessible depuis la Wonderswan.

X-death (./13) :
C'est vrai mais c'est un problème difficile à résoudre sans de lourde modification.

1) On peut séparer les mémoires , une pour le Loader ( amovible ? ) et une pour la ROM mais ça complexifie le routage , nécessite un système de Bankswitch pour le CPLD et augmente les couts.

Le seul format amovible pratique c'est du DIP, et je vois mal comment tu vas faire rentrer ça dans une cartouche de WS vu le peu de place qu'il y a

X-death (./13) :
2) On peut tenté de trouver un connecteur à 48 broches avec une nappe et l'ajouté sur le PCB , ceux qui veulent reflasher la mémoire devront avoir un PCB custom ( sans parlé du routage )

Ça va prendre de la place et compliquer le routage à mort...

X-death (./13) :
3)On passe sur un plus gros CPLD ( TQFP100 , BGA ? ) , on relie toutes les broches de la mémoire au CPLD et on pourras programmer la mémoire de manière indirect par JTAG mais pas sur d'avoir assez de place pour ajouter l'usb derrière

Pas bête, mais gros impact sur la complexité.

X-death (./13) :
4) On considère qu'une cartouche de Dev wonderswan s'adresse à un public quand même assez restreint, est-ce vraiment nécessaire d'ajouter cette fonctionnalitée ?

En fait ça n'a pas d'intérêt même pour les développeurs "ordinaires".
C'est surtout pour éviter le problème de la poule et de l'œuf pour ceux qui fabriquent la cartouche eux-même. Mais bon, tu peux toujours filer le code et les laisser se débrouiller pour le flasher, ce serait pas la première fois pour de l'open-source
En plus ça permettrait à Godzil de vendre des WonderLyzer pour servir de breakout boards
S'il y a peu de demande pour ça (ce qui sera probablement le cas : entre ceux qui demandent de l'open-source et ceux qui vont vraiment en tirer partie, il y a un gouffre), c'est l'option qui me semble la plus viable. S'il y en a davantage, on peut organiser l'achat d'un lot de mémoire préprogrammées et les revendre.