J'avais pas mal réfléchi à un convertisseur GB vers ti68k, et j'en étais arrivé à la conclusion qu'un convertisseur brutal ne serait pas possible à réaliser faute de mémoire disponible.
Le raisonnement est le suivant:
hypothèses:
- Une instruction GB (z80 modifié) fait au moins un octet.
- Une instruction 68k fait au moins 2 octets.
- Il n'est pas trivial (pour autant que je sache) de différencier le code exécutable des données brutes qui doivent pourtant représenter très largement la plus grande partie de la mémoire des cartouches GB.
- Un binaire GB brut fait entre 32ko et 1.5Mo.
- Le z80 modifié possède des instructions de saut vers l'adresse contenue par un registre, aussi les branchements ne sont pas décodables
a priori.
En conséquence:
- Un programme recompilé sans suppression des blocs de données brutes ferait au moins entre 64Ko et 3Mo.
- Puisqu'il n'est pas possible de déterminer en temps de compilation la destination de tous les branchements, il faut utiliser une méthode pour déterminer les sauts à effectuer, pour moi ça passe par un tableau de correspondance adresse z80/adresse 68k, et ça prendrait 4*n, où n est la taille totale adressable (bon on peut compresser, optimiser, etc, mais ça resterait de l'ordre de grandeur de la taille de l'espace "branchable").
Bon après, plusieurs solutions pour l'émulation:
- Emuler brutalement: optimal en taille, pas de prétraitement des données (outre la conversion au format ti oncalc). Après, on peut utiliser diverses techniques pour accélérer le décodage des instructions.
- Recompiler brutalement: probablement le plus rapide, mais à mon avis impossible à cause des contraintes de tailles citées au dessus (enfin si, possible, mais limité aux petites roms, sauf si il existe un bon moyen de supprimer les données non exécutables du binaire). A noter en plus qu'à cause de la présence de données brutes, il faudra conserver le binaire d'origine dans le programme recompilé.
- Combo émulation+recompilation: le code est précompilé comme au dessus, et on passe du mode "exécution de code précompilé" au mode "exécution de code interprété" lors de sauts relatifs à un registre, et inversement lors de branchements en valeurs immédiates. On économise ici la table de sauts, mais si on ne sait pas éviter l'inclusion de code non exécutable, on restera toujours au final avec un résultat très gros.
- Recompilation partielle: la gb possède un espace de mémoire paginé (pour palier à l'adressage sur 16 bits), et sur l'espace d'adressage de la cartouche, seuls 16Ko sont adressables en permanence, les autres peuvent être échangés en utilisant un registre du contrôleur d'adresse. L'idée que j'avais alors retenue était de précompiler seulement le bloc présent en permanence qui contient sûrement le code le plus souvent exécuté.
(oui, je m'étais lancé dans un recompilo game boy avant de tomber sur ces problèmes, c'est pas dit que le résultat voie le jour, vous me connaissez peut-être
)
Pour les tiz80, j'ai pas été voir si une précompilation était effectuée oncalc ou si c'était fait sur PC, mais une chose est sûre: les contraintes de taille doivent être moindres.
Bel effort cependant
edit: cross
edit2: en fait ça parle un peu de ce genre de problèmes dans l'article de la Wikipedia posté au dessus
)
:
