GB68K - Page 2

ah oui c'est vrai que le code généré risque pas d'etre sous GPL, donc on peut pas le linker a pedrom... qd est-ce que tu vires cette limitation débile ?

PpHd :
>On ne pourrait pas faire du JIT et laisser les lectures en mémoire toujours pointer dans le code original pour tout ce qui est donnée ?
Memoire pas assez grande.

Pourquoi ? Pour une recompilation dynamique, il n'y a qu'un peu de cache d'instructions traduites en plus par rapport à une émulation standard.

Pollux :
- (dans le cas de self-modifying code) de pouvoir voir quand les écritures posent pb

Sur PC, la page est placée en read-only et le code est regénéré en cas SEGV. (si seulement...)

tel endroit n'est jamais exécuté donc c'est des données et pas la peine de le convertir en code 68k

Impossible à deviner avec les calculs d'adresses dynamiques (dont jump tables) ?

ExtendeD
:

Pollux :
- (dans le cas de self-modifying code) de pouvoir voir quand les écritures posent pb

Sur PC, la page est placée en read-only et le code est regénéré en cas SEGV. (si seulement...)

Ben oui, et meme encore plus pour les I/O, ca doit vachement aider d'avoir un MMU... Sans MMU si on veut pas des grosses pénalités il faut vraiment analyser le code avant (ou le faire dynamiquement, mais c'est chaud a fine-tuner ^^)

tel endroit n'est jamais exécuté donc c'est des données et pas la peine de le convertir en code 68k

Impossible à deviner avec les calculs d'adresses dynamiques (dont jump tables) ?

Le probleme c'est qu'effectivement comme le code n'est pas readonly on ne sait pas a priori si tel opcode sera modifié par la suite ou pas, et donc n'importe quel opcode pourrait etre transformé en saut... Y a deux solutions, soit faire une analyse assez poussée pour dissocier entierement code et données (mais ca veut dire sans doute pas mal de hints manuels, c pour ca que je parle de conversion semi-automatique), soit un gros hack du style "tout ce qui n'est pas détecté comme nécessairement du code automodifiant par l'analyse est supposé constant", avec des vérifications runtime par la suite dans les versions de debug, ce qui est franchement moche mais veut dire qu'il n'y a plus qu'a examiner une classe tres restreinte de valeurs qui risque d'etre plutot bien analysée statiquement (jumps tables). Mais les vérifications runtime c'est pas terrible, j'aimerais pas arriver au boss de fin d'un jeu et me taper un "error: assertion failed" (enfin remarque on peut tjs sauvegarder l'état du jeu sans y toucher et faire un edit-and-continue, mais c'est un peu délicat )

pour la gb le smc n'est jamais utilisé (rom toussa)

le code n'est jamais copié en ram ? (ou seulement rarement ?)

heu, sur la NES je n'ai rencontré qu'un seul jeu qui faisait ça (copier du code en ram) et ce code n'est la uniquement pour faire "patienter" le prog pendant les page swap, et le code n'a pas interet a faire du SMC, mais rien n'empecherais un fou de le faire.

Donc le seul problème restant est les ports I/O ? (qui n'est pas un si gros problème, on peut détecter les instructions y écrivant/lisant et remplacer par des traps par exemple).

comment tu comptes les détecter ? vérification a chaque écriture/lecture ? l'idéal serait de pouvoir détecter qd une meme adresse va etre lue plusieurs fois et ne vérifier qu'une fois, mais je ne vois pas comment faire une analyse plus poussée sans analyse globale du programme...

Pollux :
comment tu comptes les détecter ? vérification a chaque écriture/lecture ? l'idéal serait de pouvoir détecter qd une meme adresse va etre lue plusieurs fois et ne vérifier qu'une fois, mais je ne vois pas comment faire une analyse plus poussée sans analyse globale du programme...

Les IO sur une GB sont well known quand meme, ya que pour les mappers ou ça peut poser pbm

comment ca ? c'est pas parce qu'on sait qu'il faut traduire telle adresse GB en telle adresse 68k que la traduction se fera rapidement...

Ben (sur la nes) par les port io de la consoles sont en $2000-$2028 (de mémoire), et ce quelque soit le jeu, par contre, pour les jeux demandant plus de mémoire que le 6502 peut addresser on utilise les MMC (memory mapper controler) qui (suivant le MMC et le jeu) on un fonctionnement assez complexe (genre IRQ utilisant l'addressage mémoire video comme timer, etc..) et généralement les accés se font sur la zone ROM ($8000 ->$FFFF) en ecriture.
Meme pire, ya un mapper qui fonctionne suivant l'addresse mémoire qui est demandé ()

enfin c'est le bordel la dessus

ben oui, c'est ce que je dis, il faut a chaque fois regarder si on lit/écrit en ROM, en RAM, etc... (sachant qu'il y a plusieurs banques de ROM/RAM switchables) Pas mal de ports I/O doivent etre implémentables simplement comme de la RAM qu'on vérifie/met a jour périodiquement, mais pas tous (cf $600017 sur TI)

Je ne comprend pas très bien tout ce que vous avez écrit lol ! Mais je voulais savoir : il y a une chance pour que pleins de jeux tournent à une vitesse normale sur cette emulateur???

sinon, ca serait pas possible de faire un fichier avec 2 fois la rom:
une rom completement transcrite en 68k, et l'autre telle quelle ou on irait chercher les données quand y'en a besoin (qu'on aurait meme pas besoin de dearchiver du coup.

Certe, ca prendrait 2 fois plus de place, mais au moins, on pourrait tout automatiser, et ca pourrait toujours etre une solution

Bon je sais pas si c'est dans l'ordre du faisable vu que je connais rien en z80, c'est juste une idee comme ca.

C'est règle toujours pas les problèmes des messages précédents.

sinon, ca serait pas possible de faire un fichier avec 2 fois la rom:
une rom completement transcrite en 68k, et l'autre telle quelle ou on irait chercher les données quand y'en a besoin (qu'on aurait meme pas besoin de dearchiver du coup.

Certe, ca prendrait 2 fois plus de place, mais au moins, on pourrait tout automatiser, et ca pourrait toujours etre une solution
Bon je sais pas si c'est dans l'ordre du faisable vu que je connais rien en z80, c'est juste une idee comme ca.

C'est carrément tout le jeu à reprogrammer et c'est pas du tout viable

ExtendeD :
Ca ne règle toujours pas les problèmes des messages précédents.

Une nouvelle version est sortie et elle est un peut plus rapide de 10% environ

Euh, ça fait une semaine...

Encore une nouvelle version est sortie : la 0.3.1 mais le lien marche pas !
Si ça continue à ce trin là on va pas tarder à avoir un super emulateur GB !

Nouvelle version : 0.4
- Émulation du timer
- Plus d'options
- L'affichage est plus rapide (et prend moins de place)

Bon jeu !

Toujours le même lien ?

Sur www.ti-news.net

OK

---

[edit]Putain elle poutre cette version

Comment on met un jeu Gameboy sur sa 89 en utilisant GB68k ?

Avec DOS et GameboyConvert.exe dans le répertoire tools de gb68k.

Mais il faut avoir une ROM du jeu ??
Moi j'ai des jeux gameboy en cartouches !!!
Comment je fais pour les mettre sur mon ordi ??

tu enleves les piles de ta 89 et tu forces pour mettre la cartouche a leur place (la cartouche inclut une pile)

Peio>
si c'est pour dire des conneries, tu peux t'abstenir, hein...