Posté le 17/08/2017 11:35
)
Planète Casio v4.3 © créé par Neuronix et Muelsaco 2004 - 2024 | Il y a 85 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
Citer : Posté le 17/08/2017 12:17 | #
C'est la même ISA que sur les Graph 25+Pro/35+USB/35+E/75/75+E modernes : un SH-4A (rétrocompatible SH-3, aussi). C'est le microcontrôleur qui change (donc les modules périphériques, leur adresse, etc). Les syscalls changent beaucoup, notamment pour tout ce qui touche à l'écran : jette donc un œil à la libfxcg. On peut remplacer le header, mais c'est dangereux, et y a moyen que tu oublies de remplacer quelque chose et que tu brickes la calto.
J'avais sort of commencé un émulateur de g1a au runtime (au moins dans la théorie), en implémentant un gestionnaire d'exceptions qui catcherait les erreurs de type accès à de la mémoire interdite (P0 non mappé, ou P1/P2/P3/P4), et :
- si l'exception est apparue à une instruction de jump (bsrf, ...), on regarde si c'est une routine connue, et on l'émule (on fait l'équivalent des actions qu'elle est sensée faire, et on retourne le résultat attendu) ;
- sinon, on cherche à lire pour stocker ou calculer (typiquement, jsr @r1, donc il faudrait émuler 0x80010070).
Le truc c'est que ça implique aussi pas mal de choses, notamment concernant le mapping (les add-ins ne sont pas mappés aux mêmes endroits, il me semble, et c'est dû entre autres à la taille du header). Et aussi, mais c'est de l'optimisation, tout syscall à émuler qui renvoie une adresse (typiquement, la VRAM), ce serait cool qu'elle renvoie quelque chose mappé vers la fin de P0, histoire de ne pas avoir à émuler chaque lecture/écriture vers l'adresse d'origine.
Pour ce qui est de la vitesse, le proco de la G90 tourne à une vitesse plus grande que la G75, donc il ne devrait pas y avoir de souci de ce côté-là a priori.
Je suis rapidement passé à autre chose, et même si c'est très risqué pour les caltos sur lesquelles tu testes (puisqu'il faut toucher au MMU) et que c'est plutôt technique, c'est possible.
Mon blog ⋅ Mes autres projets
Citer : Posté le 17/08/2017 12:34 | #
Du coup il faudrait mapper les syscalls qui ne touchent pas au hardware (écran/clavier) avec leur adresse sur la G90, et c'tout ?
Pour tout ce qui touche à la vram, je sais pas trop comment procéder, vu qu'il y a des fonctions qui touchent directement à la vram avec une adresse hardcodée. Ce serait possible de faire une vram virtuelle, puis de la mettre périodiquement sur la vraie vram ?
(ou sinon on fait le truc de modifier fxlib+monochromelib pour la prizm, et on aurait qu'à recompiler les addins en changeant les syscalls ?)
À noter que je souhaiterais faire un port plutôt qu'un émulateur (à moins qu'un émulateur ne gêne pas trop la vitesse).
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 17/08/2017 12:39 | #
Il faut aussi faire les syscalls qui ne touchent pas au hardware, pour "convertir" ce que dit le matériel de la G90 en ce que dirait le matériel de la G75. Et tu sembles oublier les add-ins qui touchent directement au matériel, je pense à ceux qui utilisent gint par exemple.
Mais si "c'est tout", je t'en prie, essaies. C'est la meilleure façon de réaliser ce qui t'attend
Mon blog ⋅ Mes autres projets
Citer : Posté le 17/08/2017 17:18 | #
Le MPU doit être 90% compatible, les adresses ne changent certainement pas vu que c'est un SH7305 - ou alors aucun des add-ins Prizm testés n'utilise de fonctionnalités bas niveau.
Pour l'écran, il faut émuler le driver, donc soit attraper les TLB errors sur le registre de l'écran (qui par chance se trouve en P3, une zone utilisée par strictement rien d'autre), ce qui nécessite gint (ou un équivalent, mais c'est l'idée) ; soit réécrire la partie du g1a qui contient le driver de l'écran. Si vous émulez les syscalls, vous échouerez lamentablement à détecter proprement les appels aux anciens syscalls et à convertir les routines proprement (et le format de la VRAM).
L'idéal serait un truc comme le convertisseur SH4 où on peut directement modifier le binaire, mais on pourrait se contenter par exemple d'une version modifiée de fxlib + monochromelib qui servirait à recompiler les sources. (je pense que pour gint, c'est mort
Eh bien détrompe-toi, de tout la matériel de Graph 85 qui existe actuellement (et donc pas le Prizm SDK et la lib associée qui sont bien évidemment en première position), le système qui sera le plus simple à porter sur la Graph 90+E est probablement gint. Le fx-9860G SDK donne trop peu de contrôle pour que ça marche.