Ah zut, l'analyse des différentes manettes DC n'a pas du tout continué alors
Bon, beh tant pis hein, la docu compilée ici était déjà hyper impressionnante comme ça.
L'analyse des différentes manettes est devenue inutile avec
cette mine d'or, tout est bien détaillé dans ce document original :
Et à force de proposer des mots clef issus du glossaire DreamCast/Maple Bus, j'ai enfin pu localiser une vraie mine d'or.
Que n'aie je pas trouvé cette archive plutôt, elle m'aurait épargné quelques heures de travail ! En tout cas, ces documents confirment ce que j'ai déjà observé ou déduit de mes expérimentations précédentes.
Cette archive contient deux répertoires spécifiquement dédiés au Maple Bus :
- Un répertoire "E_MapleBus_FT_Spec" avec :
- Un document word "Maple Bus Standard Specification"
- Une douzaine de documents "Maple Bus Function Type Specifications", soit un fichier word par type de fonction.
- Un répertoire "E_MapleBus_Peri_HW_Spec" avec plus d'une quinzaine de documents word "Maple Bus Peripheral Hardware Specifications", chacun décrivant un accessoire différent : pad standard, pad arcade, twinstick, canne à pêche ...
J'ai en définitive mis de coté
cette expérimentation à cause du nombre de cycles important absorbé par la réponse aux interruptions du micro-contrôleur SX28 qui aurait pu faire louper la prise en compte de certains bits.
Mais je n'ai pas encore jeté l'éponge, une des solutions serait l'emploi d'un CPLD pour désérialiser le flux rapide de données émises par la DC, comme dans ce boîtier interface DC2Saturn :
Le CPLD utilisé dans cette interface est ici un
XC9536XL Xilinx comportant 36 macro-cellules :
Il me reste plus qu'à m'initier au langage VHDL pour reprendre cette expérimentation !