Jonas (./30):Décidemment il y en a certains qui sont plus productifs que moi le dimanche

Tu veux dire qu'on est censé bosser en semaine et glander le w-e ? J'ai tout inversé encore

@Godzil m'en avait parlé il y a 120 ans oui, je m'en souviens bien !

Post à rallonge ici plutôt qu'un article sur mon site car je pense que Yaronet tiendra plus longtemps, puis ça fait moins "appropriation".

C'est une variante de ce qu'avait fait Costis pour extraire la ROM de la Gameboy Color, à savoir: faire glitcher le CPU pendant un court instant afin de lui faire sauter l'étape qui désactive l'accès à la ROM interne.
Trap15 (et peut être d'autres) ont documenté le fait que la désactivation se faisait certainement comme sur la Gameboy: en soft, en changeant un bit dans un registre juste avant de passer la main au jeu.
Pas moyen de refaire passer le bit à son état initial à moins de balancer un reset, donc lecture impossible depuis le programme en cartouche.
Protection de PI ? Courtoisie pour laisser le jeu prendre tout l'espace mémoire ? Who knows.

Comme sur la GB Color, les accès dans la ROM interne n’apparaissent pas sur le bus cartouche, donc pas moyen de savoir exactement quand la désactivation se fait.
Pas bien grave puisque ça doit théoriquement se produire juste avant les premiers accès à la cartouche, qui eux sont bien sur visibles.

Avec un bout de logique dans le FPGA pour simuler le "ok signal" du mapper nécessaire au boot (et la vérif supplémentaire des registres 0xC2 et 0xC3 que la Wonderswan Color fait... grrr), j'ai utilisé un compteur sur les fronts de CLK (master clock / 32) pour ignorer les quelques accès cartouche qui se produisent pendant que la ROM interne récupère des infos/flags du jeu.

Après ce délai, il reste quelques µs avant que le jeu démarre. La logique passe dans un autre mode, où la master clock passe de 12.5MHz à 100MHZ (yolo !) tant que le bus d'adresse est au dessus de $F0000 (segment $F, où la ROM doit forcément être mappée, du moins en partie).
Dès que l'adresse est en dehors, c'est qu'on a passé l'étape de désactivation donc plus la peine de pousser le CPU aux fesses.

Avec un petit bout de code "servi" par le FPGA, j'ai pu vérifier si le CPU fonctionnait toujours et si la désactivation se faisait ou non en affichant l'état du bit via les icones de l'écran.
Ça prend quelques octets, pas chiant à copier.

Comme j'avais mal au doigt à force d'éteindre et d'allumer la console pour chaque essai, j'ai collé un FET récupéré sur une carte mère de laptop (vive l'e-waste...) pour piloter l'alimentation depuis le FPGA.
Direct le 3.3V sans passer par le petit module d'alim. Pas de tensions pour l'écran mais bizarrement les icônes fonctionnaient toujours.

Après pas mal d'ajustements sur la valeur limite du compteur et le switch de fréquence, joie: les icônes fixes s'allument mais l'icone correspondant au bit de verrouillage ne s'allume plus. C-à-d le code a été exécuté et la ROM interne n'a pas été désactivée.

A partir de là c'est allé bien plus vite: j'ai changé le "payload" pour balancer le contenu de $FF000~$FFFFF sur le port link. Je lui ai collé un câble USB-série reprogrammé pour inverser RXD, log dans Teraterm et hop.
J'ai misé sur une taille de 4ko en commençant le dump à $FF000. Coup de bol c'était bien ça, toutes les adresses en dehors (mis à part celles pour la RAM) retournaient mon programme.


Pour la Wonderswan Color, même recette sauf que j'ai bêtement calé sur le module d'alim différent et sa capacité à se couper sur commande du CPU.
Après avoir essayé de le contrôler "proprement" via le FPGA, je l'ai dégagé pour fournir directement le 3.3V et le reset. Je n'ai pas pu le laisser comme sur la WS car il n'aimait pas le 3.3V à sa sortie alors qu'il n'était pas en marche -> court circuit à la masse.

Passé ça, je vérifie que ma "cartouche" démarre à vitesse normale comme précédemment: c'est pas le cas. Je me rends compte après trop de temps qu'il y a des vérifs supplémentaires sur WS Color (d'où le grrr plus haut), je met les réponses attendues en dur et ça finit par se lancer. Toutes les icônes sont allumées, normal.

Nouvelle phase d'ajustements pour trouver le bon moment où commencer l'overclock. Les résultats se font attendre, jusqu'à ce que je me rende compte que la console continuait de tourner même après avoir coupé le FET. Il restait un joli 2.5V sur le rail 3.3V, stable, pas une décharge de condo lente. Pour cause, le FPGA qui forçait à 1 quelques bits du bus de données cartouche car il voyait le signal nRD (read) bas. Le 3.3V des bits passait dans les diodes de protection et finissait par maintenir le rail d'alim suffisamment haut pour que le CPU continue de tourner ! C'est dingue, ce truc consomme RIEN o_o

Bref, j'ai corrigé la logique pour que le FPGA se taise tant que nRESET n'est pas haut et ça a fini par fonctionner. L'alim tombait bien à 0V entre les essais et le reset se faisait correctement.
Dump à partir de $FF000, le premier saut indique que l'entry point est en fait à $FE000. Re-dump à partir de $FE000 cette fois et voilà, une ROM de 8ko.

Full disclosure: j'ai dit à Byuu que je n'allais pas accepter l'intégralité de la somme proposée. Ne me tapez pas merci.

Pas encore trop gore:


Gore avec la Wonderswan Color:


Le transistor pour l'alim et le cable série soudé sur le connecteur ext façon goret:


Oscillateur remplacé par le FPGA (condo 100pF en série):


Quelqu'un en Allemagne va me prêter une Crystal pour faire pareil
Byuu s'attend à ce que ce soit pratiquement la même ROM que sur Color.