Comment faire un émulateur hector
Modérateur : Politburo
- Fabrice Montupet
- Administrateur
- Messages : 11106
- Enregistré le : 17 mai 2002 11:39
- Localisation : Nevers - France
-
- Fonctionne à 2400 bauds
- Messages : 1806
- Enregistré le : 03 mai 2003 02:24
- Localisation : Nonglard (Annecy)
- Contact :
Re: Comment faire un émulateur hector
Hehe, tres bon document : j'y ait retrouve pas mal des interrogations que je m'etais pose lorque j'avais fait mon emulateur pour Pocket Sharp et souvent t'utilise des solutions totalement differentes de ce que j'ai fait ce qui est tres interessant (meme si je ne suis pas toujours d'accord avec ce que tu dis, comme le coup du tableau de flags en fonction de la valeur de l'accus)yvesffr a écrit :Salut!
C'est tout chaud, à l'adresse ci-dessous, je raconte comment je m'y prend pour réaliser un émulateur:
http://hectorvictor.free.fr/index.php?p ... o595YVb1BF
En tout cas, du tres bon boulo !
Lolo
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
- Stéphane Vanlierde
- Fonctionne à 9600 bauds
- Messages : 2567
- Enregistré le : 09 oct. 2002 16:10
- Localisation : Marne la Vallée, Seine & Marne, France
- Contact :
Bravo Yves ! toutes mes ficelles de caleçon !
Bon, ben je n'ai plus qu'à me mettre au boulot !
EN attendant => bookmark !
Bon, ben je n'ai plus qu'à me mettre au boulot !
EN attendant => bookmark !
-- Stef --
perso: http://www.vanlierde.org
perso: http://stephane.vanlierde.org
vg5000: http://vg5k.free.fr
perso: http://www.vanlierde.org
perso: http://stephane.vanlierde.org
vg5000: http://vg5k.free.fr
- Carl
- Fonctionne à 9600 bauds
- Messages : 2542
- Enregistré le : 03 janv. 2003 23:47
- Localisation : www.dole.org
- Contact :
- yvesffr
- Fonctionne à 2400 bauds
- Messages : 2127
- Enregistré le : 03 juin 2002 22:07
- Localisation : 77
- Contact :
Re: Comment faire un émulateur hector
Justement, ces opinions m'intéressent pour trois raisons: 1. Je me suis peut-etre trompé, 2. Je me suis peut-être mal exprimé (Romu pourra confirmer que ça m'arrive souvent ) 3. Je n'ai pas vu toute une partie du problème.destroyedlolo a écrit : meme si je ne suis pas toujours d'accord avec ce que tu dis, comme le coup du tableau de flags en fonction de la valeur de l'accus)
Bref, tout ca pour améliorer le document et mes connaissances
Passes un coup sur irc #silicium , dans tous les cas je t'envoie un pm
Merci
Yves
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
-
- Fonctionne à 2400 bauds
- Messages : 1806
- Enregistré le : 03 mai 2003 02:24
- Localisation : Nonglard (Annecy)
- Contact :
Ok, je n'avais pas eu le temp de vraiment m'approfondir hier donc plus de commentaires maintenant.
Avant toute chose, l'emulateur que j'ai fait concerne les pocket sharp donc y'a qq trucs qui sont fait totalement differement (genre la gestion du clavier). De plus, ce ne sont que mes commentaires et c'est evidement que je ne pense pas avoir la science infuse donc tous commentaires / debats et corrections sont les bienvenu
J'ai aussi rajoute qq infos sur ce que j'ai du faire pour les sharp des fois que ca interesse qq'un
Au Chap 1 J'ai bien aime la note sur la vitesse : c'est vrais que j'ai completement squizer ce point car mon but etait d'avoir qq chose de fonctionnel sur la machine tres lente que j'utilise au taf (station HP 712@80 Mhz). Et c'est vrais que lorsque j'utilise mon emulateur sur ma station SUN a la maison, les jeux comme ChangerMkII sont presque injouable
Au Chap 2, je ne suis pas tous a fait d'accord lorsque tu dis qu'il faut se focalise sur une seule machine. Au debut, je ne m'etais aussi concentre que sur le 1350. Mais au fur et a mesure que mon projet avancait, je me suis dit que c'etait domage car il faudrait tout refaire pour emuler par exemple un 1401 alors que l'archi n'est pas si differente que ca ...
Bref, j'ai decoupe mon code pour separe ce qui est independant au model de ce qui est vraiment specifiques. Emuler une nouvelle machine proche se resume donc qu'a modifier qu'une petite partie.
J'ai donc modifier mon code ce qui nous amene au point suivant.
Chap 4.2 Comme je l'avais dit, la rapidite etait le point primordiale de mon emulation. Et vu la rapidite de ma machine, la moindre perte de temp inutile etait super prejudiciable ... J'ai donc fait des tests sur une machine encore plus lente que ma station !
Ben, je ne suis pas d'accord avec tes conclusions sur le C et le C++. Meme si l'utilisation de classes abstraites amene une legere perte de perf (utilisation de table de fonction pour les methode virtuelles), c'est plus que negligeable. Par contre, ca facilite grandement la programmation.
Dans mon exemple, j'ai une classe de base qui emule le CPU et qui est donc le coeur de l'emulation. Pour emuler un model particulier, je n'ai qu'a deriver cette classe en surchargeant les methodes d'I/O (lecture/ecrite memoire, gestion du clavier, ... ) et zou, ca fonctionne.
(bon, j'ai fait qq teste en emulant un 1401 mais je ne l'ai pas encore mis dans mon archive car je n'ai pas encore eu le temp de traiter correctement le clavier, vu le nombre de touches de la machine).
Evidement, tu peux faire la meme chose en C classique, mais c'est a toi de tous gerer et tu n'as plus les checks que fait automatiquement le C++.
Pour la portabilite (4.1 et 4.3) : Arg, j'ai eu plein de galere avec X, surtout pour la gestion du clavier car chaque vendeurs semble s'amuser a gerer la chose d'une maniere differente de son voisin. Je n'ai pris en compte que Nunux, Solaris et HP-UX et j'ai ete oblige de faire plein de bidouilles
Par contre, comme toi, j'ai utiliser Motif car c'est aussi l'aventure de compiler Gtk ou KDE sur HP-UX Pis bon, c'etait pas si complique que ca meme si je n'y connaissait rien au debut de mon projet.
Chap 5.1 le fameux l'accu. Je ne partage pas ton opinion lorsque tu dis :
ben la c'est pas optimiser car ca implique une addition (ptr_base_tableau + val_Accus) et un test logique.
De mon cote, j'aurait plutot fait qqchose du genre :
Si ton compilo est bien optimiser, ca va plus vite (pas besoin de faire le (!val) car cette condition est deja 'teste' lors du Accu = val, et pour le second test, ce n'est qu'un simple test logique. En plus, avec le inline du C++, y'a meme pas de perte de temps du a l'appel de la fonction.
Ce qui me chiffonne aussi, c'est :
seul l'accus est capable de modifier ces flags ? (sur les sharp, y'a plein de fonction de test qui n'utilisent pas forcement l'accu),
il n'y a pas de Carry (flags qui est mis lorsque tu fais par exemple de 255 +1 -> 0 ou de 0 - 1 -> 255 ?
Pour le switch() geant, j'y avais pense dans un premier temps, mais j'ai preferer faire un tableau de pointeur de fonctions. Dans mon cas, je ne fais pas qu'emuler, je desassemble aussi et donc j'ai une tableau pour l'emulation, un autre pour le dessasemblage et j'ai donc trouve ca plus propre car ces 2 tables sont dans le meme fichier de mon code. Mais bon, le switch() est aussi une option interessante ...
Chap 5.2 comme toi, j'ai utilise 2 fonctions pour lire et ecrire la memoire. Par contre, elle fait partie de ma classe CPU et sont donc redefini pour chacun des models que j'emule, en fonction de leur memory map.
Chap 5.3 Ai ai ai : c'etait la que mon emulation perdait plus de temp. La, il y a 2 solutions :
soit tu remet a jour l'ecran en fonction de la memoire video a interval reguilier : c'est ce qu'est fait dans POEM qui est un autre emulateur de pocket. Ben, le bleme, c'est que ca fait perdre un temp pas possible car X n'a rien de leger.
soit tu ne met a jour que la partie de l'ecran touche lorsque tu modifie la memoire (je pense c'est ce que tu fais). J'ai meme fait encore mieu : je ne modifie l'ecran que si la nouvelle valeur que je met en memoire est differente de la precedente.
Ben, mine de rien, ca a vachement speeder mon emulation sur mes brouettes.
Chap 5.5 je n'ai pas emuler la lecture sur K7 (c'est aussi un des point bloquant pour l'emulation d'un PC-1401) par manque d'infos sur le format utilise et par manque de temps pour le faire.
De mon cote,
soit je charge le programme en memoire avant l'emulation,
soit j'utilise la RS-232.
J'ai mis une instruction INVALIDE aux point d'entree des routines qui font SIOGetChar() et SIOPutChar(). Ca redirige l'emulation vers une fonction de mon programme qui lit ou ecrit un caractere depuis un fichier.
Voila, je me suis un peu etendu mais j'espere que ca reste comprehensible
A+
Lolo
Avant toute chose, l'emulateur que j'ai fait concerne les pocket sharp donc y'a qq trucs qui sont fait totalement differement (genre la gestion du clavier). De plus, ce ne sont que mes commentaires et c'est evidement que je ne pense pas avoir la science infuse donc tous commentaires / debats et corrections sont les bienvenu
J'ai aussi rajoute qq infos sur ce que j'ai du faire pour les sharp des fois que ca interesse qq'un
Au Chap 1 J'ai bien aime la note sur la vitesse : c'est vrais que j'ai completement squizer ce point car mon but etait d'avoir qq chose de fonctionnel sur la machine tres lente que j'utilise au taf (station HP 712@80 Mhz). Et c'est vrais que lorsque j'utilise mon emulateur sur ma station SUN a la maison, les jeux comme ChangerMkII sont presque injouable
Au Chap 2, je ne suis pas tous a fait d'accord lorsque tu dis qu'il faut se focalise sur une seule machine. Au debut, je ne m'etais aussi concentre que sur le 1350. Mais au fur et a mesure que mon projet avancait, je me suis dit que c'etait domage car il faudrait tout refaire pour emuler par exemple un 1401 alors que l'archi n'est pas si differente que ca ...
Bref, j'ai decoupe mon code pour separe ce qui est independant au model de ce qui est vraiment specifiques. Emuler une nouvelle machine proche se resume donc qu'a modifier qu'une petite partie.
J'ai donc modifier mon code ce qui nous amene au point suivant.
Chap 4.2 Comme je l'avais dit, la rapidite etait le point primordiale de mon emulation. Et vu la rapidite de ma machine, la moindre perte de temp inutile etait super prejudiciable ... J'ai donc fait des tests sur une machine encore plus lente que ma station !
Ben, je ne suis pas d'accord avec tes conclusions sur le C et le C++. Meme si l'utilisation de classes abstraites amene une legere perte de perf (utilisation de table de fonction pour les methode virtuelles), c'est plus que negligeable. Par contre, ca facilite grandement la programmation.
Dans mon exemple, j'ai une classe de base qui emule le CPU et qui est donc le coeur de l'emulation. Pour emuler un model particulier, je n'ai qu'a deriver cette classe en surchargeant les methodes d'I/O (lecture/ecrite memoire, gestion du clavier, ... ) et zou, ca fonctionne.
(bon, j'ai fait qq teste en emulant un 1401 mais je ne l'ai pas encore mis dans mon archive car je n'ai pas encore eu le temp de traiter correctement le clavier, vu le nombre de touches de la machine).
Evidement, tu peux faire la meme chose en C classique, mais c'est a toi de tous gerer et tu n'as plus les checks que fait automatiquement le C++.
Pour la portabilite (4.1 et 4.3) : Arg, j'ai eu plein de galere avec X, surtout pour la gestion du clavier car chaque vendeurs semble s'amuser a gerer la chose d'une maniere differente de son voisin. Je n'ai pris en compte que Nunux, Solaris et HP-UX et j'ai ete oblige de faire plein de bidouilles
Par contre, comme toi, j'ai utiliser Motif car c'est aussi l'aventure de compiler Gtk ou KDE sur HP-UX Pis bon, c'etait pas si complique que ca meme si je n'y connaissait rien au debut de mon projet.
Chap 5.1 le fameux l'accu. Je ne partage pas ton opinion lorsque tu dis :
Pourquoi ca ne serait pas optimiser ? Si lorsque tu veux avoir la valeur de Z, tu dois faireCertaines de ces instructions positionnent des flags dans le registre F lorsque elles sont exécutées par exemple le flag de signe ou le flag Zéro lorsque le résultat de l'opération est 0, on pourrait créer une routine qui en fonction du résultat stocké dans A, retourne ou positionne les bon flags, mais ce ne serait pas très optimisé ! Le plus simple est de créer un tableau de la taille du nombre de valeurs que peut prendre le registre A et d'y mettre les flags Zero et Signe correspondants à chaque valeur:
Code : Tout sélectionner
ZSTable[Accus] & Z_FLAG
De mon cote, j'aurait plutot fait qqchose du genre :
Code : Tout sélectionner
inline cpu::setA(unsigned char val){
Accu = val;
flags = ((!val) ? Z_FLAG : 0) | ((val & 0x80) ? S_FLAG :0);
}
Ce qui me chiffonne aussi, c'est :
seul l'accus est capable de modifier ces flags ? (sur les sharp, y'a plein de fonction de test qui n'utilisent pas forcement l'accu),
il n'y a pas de Carry (flags qui est mis lorsque tu fais par exemple de 255 +1 -> 0 ou de 0 - 1 -> 255 ?
Pour le switch() geant, j'y avais pense dans un premier temps, mais j'ai preferer faire un tableau de pointeur de fonctions. Dans mon cas, je ne fais pas qu'emuler, je desassemble aussi et donc j'ai une tableau pour l'emulation, un autre pour le dessasemblage et j'ai donc trouve ca plus propre car ces 2 tables sont dans le meme fichier de mon code. Mais bon, le switch() est aussi une option interessante ...
Chap 5.2 comme toi, j'ai utilise 2 fonctions pour lire et ecrire la memoire. Par contre, elle fait partie de ma classe CPU et sont donc redefini pour chacun des models que j'emule, en fonction de leur memory map.
Chap 5.3 Ai ai ai : c'etait la que mon emulation perdait plus de temp. La, il y a 2 solutions :
soit tu remet a jour l'ecran en fonction de la memoire video a interval reguilier : c'est ce qu'est fait dans POEM qui est un autre emulateur de pocket. Ben, le bleme, c'est que ca fait perdre un temp pas possible car X n'a rien de leger.
soit tu ne met a jour que la partie de l'ecran touche lorsque tu modifie la memoire (je pense c'est ce que tu fais). J'ai meme fait encore mieu : je ne modifie l'ecran que si la nouvelle valeur que je met en memoire est differente de la precedente.
Ben, mine de rien, ca a vachement speeder mon emulation sur mes brouettes.
Chap 5.5 je n'ai pas emuler la lecture sur K7 (c'est aussi un des point bloquant pour l'emulation d'un PC-1401) par manque d'infos sur le format utilise et par manque de temps pour le faire.
De mon cote,
soit je charge le programme en memoire avant l'emulation,
soit j'utilise la RS-232.
J'ai mis une instruction INVALIDE aux point d'entree des routines qui font SIOGetChar() et SIOPutChar(). Ca redirige l'emulation vers une fonction de mon programme qui lit ou ecrit un caractere depuis un fichier.
Voila, je me suis un peu etendu mais j'espere que ca reste comprehensible
A+
Lolo
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
- romualdl
- Fonctionne à 2400 bauds
- Messages : 1986
- Enregistré le : 23 mai 2002 15:44
- Localisation : Beaumont Sur Oise (95)
- Contact :
hehe
SAlut,
Pour la partie video, je sais Yves on en a parlé sur IRC mais je pense qu'il faut vraiment se rapprocher au maximum de la technique d'affichage de la machine d'origine afin d'éviter les problèmes futurs (le problème des borders par exemple). Par problème j'entends tout simplement le gars qui a trouvé une petite astuce en codant pour passer à travers les contraintes hardware, o a reussi a utilisé un truc non prevu... Si l'emulo oric n'avait pas été blindé au niveau de l'émulation (meme s'il reste quelques petits details) jamais certains trucs n'auraient pu etre faisables. Donc je ne dis pas que la communauté hector est aussi nombreuse (ou sera) que la communauté oric mais bon (je sais je suis chiant)...
Pour la partie video, je sais Yves on en a parlé sur IRC mais je pense qu'il faut vraiment se rapprocher au maximum de la technique d'affichage de la machine d'origine afin d'éviter les problèmes futurs (le problème des borders par exemple). Par problème j'entends tout simplement le gars qui a trouvé une petite astuce en codant pour passer à travers les contraintes hardware, o a reussi a utilisé un truc non prevu... Si l'emulo oric n'avait pas été blindé au niveau de l'émulation (meme s'il reste quelques petits details) jamais certains trucs n'auraient pu etre faisables. Donc je ne dis pas que la communauté hector est aussi nombreuse (ou sera) que la communauté oric mais bon (je sais je suis chiant)...
Modifié en dernier par romualdl le 11 mars 2004 13:30, modifié 1 fois.
<Pocket>la striole en a un et il me le montre quand j'ai envie (irc-25/09/2008)
- yvesffr
- Fonctionne à 2400 bauds
- Messages : 2127
- Enregistré le : 03 juin 2002 22:07
- Localisation : 77
- Contact :
Re: hehe
Oui, j'émule bien la partie non visible de l'écran le bitmap affiché est bien distinct de l'espace adresse que voit le z80, donc tous les pixels caché sont bien présentsromualdl a écrit :Pour la partie video,
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
- yvesffr
- Fonctionne à 2400 bauds
- Messages : 2127
- Enregistré le : 03 juin 2002 22:07
- Localisation : 77
- Contact :
J'ai fait l'inverse: essayer de prendre toute la gamme en compte dès le départ. En fait c'est bien et pas bien: bien, car ton code est correctement agencé pour prendre en compte toutes les machines, pas bien car tu te disperses, tu n'arrives pas à te focaliser sur une machine en particulier et tu te retrouves avec des machines pas émulées pas 100% identiques aux originales. Donc c'était surtout pour ça que je marquais cela.destroyedlolo a écrit : Au Chap 2, je ne suis pas tous a fait d'accord lorsque tu dis qu'il faut se focalise sur une seule machine. Au debut, je ne m'etais aussi concentre que sur le 1350. Mais au fur et a mesure que mon projet avancait, je me suis dit que c'etait domage car il faudrait tout refaire pour emuler par exemple un 1401 alors que l'archi n'est pas si differente que ca ...
Bref, j'ai decoupe mon code pour separe ce qui est independant au model de ce qui est vraiment specifiques. Emuler une nouvelle machine proche se resume donc qu'a modifier qu'une petite partie.
J'ai donc modifier mon code ce qui nous amene au point suivant.
Mais oui pour la premiere raison, c'est bien de le prendre en compte, mais ne focaliser que sur une seule machine à la fois (surtout quand tu débutes comme moi et que tu veux tout faire en même temps )
J'avais commencé l'émulateur hector1 en C++ sur AIX (oui pour faire style "je me la pète" je développe d'abord sur AIX ) avec un g++ 2.95 non recompilé. Et en C++ c'est vrai que la programmation en sympa, mais ca se trainait pitoyablement sur un F50 une fois tout converti en C, et compilé avec gcc 2.95 ça n'avait plus rien à voir, pourtant le C++ que j'utilisais n'était pas un code super compliqué.destroyedlolo a écrit : Chap 4.2 Comme je l'avais dit, la rapidite etait le point primordiale de mon emulation. Et vu la rapidite de ma machine, la moindre perte de temp inutile etait super prejudiciable ... J'ai donc fait des tests sur une machine encore plus lente que ma station !
Ben, je ne suis pas d'accord avec tes conclusions sur le C et le C++. Meme si l'utilisation de classes abstraites amene une legere perte de perf (utilisation de table de fonction pour les methode virtuelles), c'est plus que negligeable. Par contre, ca facilite grandement la programmation.
Ah curieux ça de mon coté j'ai compilé sur AIX 4.3.3ML11, Solaris 2.8 et Linux Debian v3.0r2 i386 et je n'ai eu aucun souci (et c'est le meme code qui est utilisé pour les 3 O/S).destroyedlolo a écrit : Pour la portabilite (4.1 et 4.3) : Arg, j'ai eu plein de galere avec X, surtout pour la gestion du clavier car chaque vendeurs semble s'amuser a gerer la chose d'une maniere differente de son voisin. Je n'ai pris en compte que Nunux, Solaris et HP-UX et j'ai ete oblige de faire plein de bidouilles
C'est vrai, sur ce coup la j'ai pas testé les 2 méthodesdestroyedlolo a écrit : Chap 5.1 le fameux l'accu. Je ne partage pas ton opinion lorsque tu dis :
ben la c'est pas optimiser car ca implique une addition (ptr_base_tableau + val_Accus) et un test logique.Code : Tout sélectionner
ZSTable[Accus] & Z_FLAG
De mon cote, j'aurait plutot fait qqchose du genre :Si ton compilo est bien optimiser, ca va plus vite (pas besoin de faire le (!val) car cette condition est deja 'teste' lors du Accu = val, et pour le second test, ce n'est qu'un simple test logique. En plus, avec le inline du C++, y'a meme pas de perte de temps du a l'appel de la fonction.Code : Tout sélectionner
inline cpu::setA(unsigned char val){ Accu = val; flags = ((!val) ? Z_FLAG : 0) | ((val & 0x80) ? S_FLAG :0); }
Non non hérésie ! tu as raison je vais modifier le texte, j'aurais du le mentionner.destroyedlolo a écrit : seul l'accus est capable de modifier ces flags ? (sur les sharp, y'a plein de fonction de test qui n'utilisent pas forcement l'accu),
Si si, mais j'ai un autre tableau pour les instructions qui n'affectent pas le registre A et/ou qui modifient d'autres flags. mais bon je n'en ai pas parlé pour ne pas surcharger Mais je vais rajouter du texte pour dire que ca existe et que ce n'est pas le seul tableau ou chose à faire pour émuler la gestion des flags du CPU.destroyedlolo a écrit : il n'y a pas de Carry (flags qui est mis lorsque tu fais par exemple de 255 +1 -> 0 ou de 0 - 1 -> 255 ?
C'est vrai que c'est élégant comme solutiondestroyedlolo a écrit : Pour le switch() geant, j'y avais pense dans un premier temps, mais j'ai preferer faire un tableau de pointeur de fonctions. Dans mon cas, je ne fais pas qu'emuler, je desassemble aussi et donc j'ai une tableau pour l'emulation, un autre pour le dessasemblage et j'ai donc trouve ca plus propre car ces 2 tables sont dans le meme fichier de mon code. Mais bon, le switch() est aussi une option interessante ...
Oui ! Super facile en C++, cool.destroyedlolo a écrit : Chap 5.2 comme toi, j'ai utilise 2 fonctions pour lire et ecrire la memoire. Par contre, elle fait partie de ma classe CPU et sont donc redefini pour chacun des models que j'emule, en fonction de leur memory map.
Personnellement je procède comme suit: pour coller au plus près au matériel: tous les 1/freq je regarde si l'écran a été modifié, si oui, je rafraichis.destroyedlolo a écrit : Chap 5.3 Ai ai ai : c'etait la que mon emulation perdait plus de temp. La, il y a 2 solutions :
soit tu remet a jour l'ecran en fonction de la memoire video a interval reguilier : c'est ce qu'est fait dans POEM qui est un autre emulateur de pocket. Ben, le bleme, c'est que ca fait perdre un temp pas possible car X n'a rien de leger.
Ca c'est carrément cool, je vais rajouter ca dans ma routine c'est vrai que ca va booster le tout !!!destroyedlolo a écrit : soit tu ne met a jour que la partie de l'ecran touche lorsque tu modifie la memoire (je pense c'est ce que tu fais). J'ai meme fait encore mieu : je ne modifie l'ecran que si la nouvelle valeur que je met en memoire est differente de la precedente.
Ben, mine de rien, ca a vachement speeder mon emulation sur mes brouettes.
Le lecteur de cassettes et les entrées/sorties en règle générale sur hector son encore plus compliquées que ce que je raconte dans mon document, je ne viens d'ailleurs de complètement comprendre le mécanisme qu'aujourd'hui ! Il faut que je mette la page à jour !destroyedlolo a écrit : Chap 5.5 je n'ai pas emuler la lecture sur K7 (c'est aussi un des point bloquant pour l'emulation d'un PC-1401) par manque d'infos sur le format utilise et par manque de temps pour le faire.
De mon cote,
soit je charge le programme en memoire avant l'emulation,
soit j'utilise la RS-232.
J'ai mis une instruction INVALIDE aux point d'entree des routines qui font SIOGetChar() et SIOPutChar(). Ca redirige l'emulation vers une fonction de mon programme qui lit ou ecrit un caractere depuis un fichier.
Impec !!! Merci beaucoup !destroyedlolo a écrit : Voila, je me suis un peu etendu mais j'espere que ca reste comprehensible
Yves
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
- yvesffr
- Fonctionne à 2400 bauds
- Messages : 2127
- Enregistré le : 03 juin 2002 22:07
- Localisation : 77
- Contact :
Bon ben ca m'intriguait tellement que j'ai essayé:destroyedlolo a écrit : Chap 5.1 le fameux l'accu. Je ne partage pas ton opinion lorsque tu dis :
Code:
ZSTable[Accus] & Z_FLAG
ben la c'est pas optimiser car ca implique une addition (ptr_base_tableau + val_Accus) et un test logique.
De mon cote, j'aurait plutot fait qqchose du genre :
Code:
inline cpu::setA(unsigned char val){
Accu = val;
flags = ((!val) ? Z_FLAG : 0) | ((val & 0x80) ? S_FLAG :0);
}
Si ton compilo est bien optimiser, ca va plus vite (pas besoin de faire le (!val) car cette condition est deja 'teste' lors du Accu = val, et pour le second test, ce n'est qu'un simple test logique. En plus, avec le inline du C++, y'a meme pas de perte de temps du a l'appel de la fonction.
Deux programmes:
prog1.c: (ta solution)
Code : Tout sélectionner
#define Z_FLAG 0x40
#define S_FLAG 0x80
void main()
{
int flags;
int val=4;
flags = ((!val)?Z_FLAG:0)|((val & 0x80) ? S_FLAG :0);
}
prog2.c (ma solution)
Code : Tout sélectionner
unsigned char ZSTable[256];
void main()
{
int flags;
int val=4;
flags = ZSTable[val];
}
Où X est le numero de fichier.
Gcc est la version 3.2.3 sous linux i386.
C'est marrant car on obtient pour les 2 le code:
Code : Tout sélectionner
pushl %ebp
movl %esp, %ebp
subl $8, %esp
andl $-16, %esp
leave
ret
"Je vous aime" (© Pocket 1969)
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
"et moi je suis la vierge marie" (© Stamba 2009)
"Resistance is futile (if < 1 Ohm)"
"Un velux est un linux portugais"
"j'en vois encore un bout, yves" (© 2010 SbM)
"In minitel we trust" - Silicium
-
- Fonctionne à 2400 bauds
- Messages : 1806
- Enregistré le : 03 mai 2003 02:24
- Localisation : Nonglard (Annecy)
- Contact :
Tiens, c'est marrant paske de mon cote, j'ai debute aussi avec GCC 2.95 mais sur mon ancienne station HP 715 (25 Mhz il me semble et beaucoup beaucoup plus lente que ma 712 actuelle). Enfin, c'etait surtout que je m'emerdait comme un rat mort a mon tafyvesffr a écrit :J'avais commencé l'émulateur hector1 en C++ sur AIX (oui pour faire style "je me la pète" je développe d'abord sur AIX ) avec un g++ 2.95 non recompilé. Et en C++ c'est vrai que la programmation en sympa, mais ca se trainait pitoyablement sur un F50 une fois tout converti en C, et compilé avec gcc 2.95 ça n'avait plus rien à voir, pourtant le C++ que j'utilisais n'était pas un code super compliqué.
Hum, c'est peut etre a cause de la programmation : c'est vrais que pousser la vision objet a font fait souvent ramer de chez ramer. En fait mon code est mal programmer dans le sens ou c'est un remix entre du procedurale et de l'Objet : je n'utilise l'objet reelement que ou ca me sert a qq chose (oulala, si mes profs entendaient ca ).
Ben, ca reste portable tant que tu reste sur le clavier classic mais ca part vite live des que tu utilise les touches de fonction ou le pave numerique. Par exemple, pour le pave numerique justement, suivant l'OS les codes de transcodage (code interne -> code ASCII) ne se trouve pas dans la meme table suivant que tu es sous Solaris ou HP-UX.yvesffr a écrit :Ah curieux ça de mon coté j'ai compilé sur AIX 4.3.3ML11, Solaris 2.8 et Linux Debian v3.0r2 i386 et je n'ai eu aucun souci (et c'est le meme code qui est utilisé pour les 3 O/S).destroyedlolo a écrit : Pour la portabilite (4.1 et 4.3) : Arg, j'ai eu plein de galere avec X, surtout pour la gestion du clavier car chaque vendeurs semble s'amuser a gerer la chose d'une maniere differente de son voisin. Je n'ai pris en compte que Nunux, Solaris et HP-UX et j'ai ete oblige de faire plein de bidouilles
Bon, ceci dit, c'etait mon premier truc sous X donc je suis loin de maitriser reelement la chose et j'ai peu etre fait n'importe quoi
Hum, je ne connais pas l'assembleur i386 ... mais je parrirai que l'optimiseur s'est rendu compte que le code ne servait a rien (rien n'utilise 'flags') et ... a donc tous virer.yvesffr a écrit : C'est marrant car on obtient pour les 2 le code:MarrantCode : Tout sélectionner
pushl %ebp movl %esp, %ebp subl $8, %esp andl $-16, %esp leave [ ret
Ce qui reste ne doit etre que sa soupe pour sauvegarder le contexte.
A+
Lolo
Amiga, UNIX
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word
Sharp, NetBSD http://destroyedlolo.info/
Apache, PHP 100 % dictionnary free
Vacances, Voyages 1 mispelling by word