Win3x.Org

Quelle discussion très intéressante entre les différents types d'émulation. Je pense que cela méritait bien un sujet à part entière plutôt que d'être noyé ailleurs.

Pour ma part, je n'ai jamais vraiment compris pourquoi PCem était si exigeant, sachant que les instructions de la machine émulée et de la machine hôte sont les mêmes (x86). A de très rares exceptions près (le 8086 ne peut adresser que 1024 Ko de RAM en mode réel ; il y a 64 Ko supplémentaires pour le 286+), les instructions d'un programme pour PC écrit il y a plus de 35 ans sont toujours compréhensibles par un processeur x86 fabriqué en 2020, la rétrocompatibilité est le principe fondamental qui explique la pérennité du x86 sur quatre décennies. Si c'est un problème de vitesse, un ralentissement devrait pouvoir s'opérer de manière logicielle sans devoir pour autant émuler un vieux processeur x86 de A à Z comme s'il s'agissait d'un cpu non-x86. Pourquoi réinventer logiciellement ce qui existe encore matériellement sur un PC moderne ? PCem n'existe pas pour Android, le programme s'adresse à des gens qui vont l'utiliser sur un x86, comme le processeur émulé.

Si on vire l'émulation du processeur, cela doit déjà diminuer nettement les besoins en calculs, non ? Il faut bien sûr émuler les autres composants (carte son, carte vidéo, etc.) mais DOSBox et les programmes de virtualisation émulent également ces autres composants, sans que cela réclame autant de ressources. A moins que ce soit la seule émulation de ces composants périphériques qui demande autant de calculs, tant l'émulation se veut la plus fidèle possible. Mais PCem n'est pas un hyperviseur (virtualisation) à ma connaissance.

À priori ce n'est pas si simple et le but est d'émuler le 8088 aussi fidèlement que possible. Faire tourner nativement le code du 8088 sur un processeur moderne serait l'inverse d'une émulation de "bas niveau"
De plus il est possible de lancer PCem sur un raspberry pi par exemple, qui n'utilise pas de processeur x86.

Cela dit, je pense qu'avoir un émulateur pour un PC des années 80 est tout à fait censé. Pour un PC du milieu/fin des années 90, ça l'est déjà beaucoup moins. Le monde des PC était déjà bien moins spécifique (plusieurs fréquences, plusieurs chipsets avec plus ou moins de fonctionnalités, etc). Pour ces cas là et au vu des performances des émulateurs pour ce type de matériel, je pense qu'une machine virtuelle spécifique avec des périphériques émulés aurait beaucoup plus de sens.

Deksor a écrit : *

18 juin 2020 23:17

À priori ce n'est pas si simple et le but est d'émuler le 8088 aussi fidèlement que possible. Faire tourner nativement le code du 8088 sur un processeur moderne serait l'inverse d'une émulation de "bas niveau"

Je n'ai pas indiqué qu'une émulation de haut niveau (= l'inverse du "bas niveau") était plus indiquée pour qu'un processeur x86 récent puisse simuler un 8088. J'ai plutôt écrit que l'idée même d'émulation du processeur me semble incongrue dans ce cas de figure.

Faisons une analogie avec les langages humains. Postulons que le 8088 comprendrait l'espagnol, tandis que le x86 plus moderne serait parfaitement bilingue espagnol/italien. L'espagnol étant l'unique langage compris par le 8088 (les instructions x86 historiques) tandis que l'italien serait ce que comprend en plus l'autre processeur (instructions MMX, SSE2, etc.). L'émulation consisterait à traduire un programme de l'espagnol vers l'italien. Mais quel serait l'intérêt d'un tel processus, puisque le destinataire de la traduction comprend très bien la langue d'origine ? Ce serait gaspiller son temps et son énergie à produire une traduction qui n'est pas nécessaire.

Dans le monde du x86, la norme étant qu'un processeur ultérieure comprenne toutes les instructions gérées par ses prédécesseurs. Il est extrêmement rare que le support d'un jeu d'instructions soit abandonné. En fait, le seul cas que je connaisse est le 3Dnow! chez AMD. Rien de tel chez Intel. Jusqu'à preuve du contraire, le dernier Core ix peut exécuter toutes les instructions de son vénérable ancêtre, le 8088.

Aucune émulation n'est nécessaire pour simuler le processeur 8088 sur un x86 plus récent (je ne fais pas allusion aux autres composants comme la carte graphique, etc.). Le recours au mode virtuel 8086 introduit par le 80386 (ou à une virtualisation plus évoluée si le processeur est utilisé en mode 64 bit) suffit. Au sein de la machine virtuelle, on doit pouvoir ralentir l'exécution comme le font les programmes conçus uniquement à cet effet. Pour les programmes les plus récalcitrants, l'émulation du chipset peut comprendre ce qu'avait ajouté IBM dans son PC/AT, pour éviter que les programmes en mode réel accèdent "involontairement" à la zone HMA (les 64 premiers Kilo-octets au-delà du premier Mo) alors qu'ils veulent accéder à la mémoire basse (les 64 premiers Kilo-octets, au sein du premier Mo) : http://en.wikipedia.org/wiki/A20_line

Ton analogie avec les langues est mauvaise, car le fait de "comprendre" les instructions ne fait pas tout pour ce type de machine. Certains programmes de cette époque bénéficient des particularités architecturales, des "hacks" qui ne sont aucunement réplicables sur un processeur moderne quand bien même il "comprend" le code.
C'est un tout. Le 8088 est l'un des composants clé, mais ce n'est pas le seul. Et ses performances pour chacune des instructions (voire même des instructions non documentées) doivent être exécutées précisément avec le nombre de cycle que prendrait un 8088 pour répliquer correctement certaines particularités.

Bref, c'est un mode à part. Les premiers programmes pour PC étaient dédiés à quelques PC précisément, et pas vraiment aux clones (ou bien un clone en particulier).
Un programme développé à 100% pour un IBM PC 5150 en utilisant toutes les particularités de cette machine ne fonctionnera pas sur un clone, un émulateur "haut niveau" ou une machine virtuelle (D'ailleurs le fait d'exécuter nativement certaines instructions plutôt que d'émuler c'est du "haut niveau").

Par exemple cette démo ne fonctionne correctement que sur un IBM PC avec une carte CGA de chez IBM. Seuls les premiers IBM et quelques clones sont capables de la faire fonctionner correctement (notamment les premiers compaqs https://www.youtube.com/watch?v=yHXx3orN35Y). Ton 486, ni tes pentiums 4, ni même mes nombreux PC rétro y parviendront.

Alors oui ce programme a été codé spécialement pour l'IBM PC (et pour avoir discuté avec l'un de ses auteurs, c'était aussi pour donner un élan pour améliorer les émulateurs : https://scalibq.wordpress.com/2020/05/1 ... emulators/), mais il existe d'autres programmes qui ne fonctionnent pas bien dans un émulateur ou un clone qui prends trop de libertés.

Il existe même un virus qui ne fonctionne que sur les 8088/8086 ! https://www.f-secure.com/v-descs/pingpong.shtml

Pour reprendre ton analogie sur les langues, c'est plus comme si tu te retrouvais devant un français du 18ème siècle qui tient une bombe à retardement avec un code extrêmement compliqué et que lui seul peut désamorcer. Sauf qu'il ne sais pas résoudre la combinaison. Toi en revanche tu as les instructions et tu dois l'aider. Vous deux parlez une langue comparable et la plupart du temps compatible, mais tu dois lui parler de manière extrêmement spécifique en faisant très attention à tous les détails de la langue qu'il parle car une fausse manip et tout le monde saute ( = crash ou problème).


Enfin, coder son émulateur comme une machine virtuelle qui exécute une partie du code en natif, cela condamne son code à une seule et unique architecture, c'est à dire le PC. Hors il existe bien des cas de figure où l'on voudrait pouvoir porter son émulateur sur une autre plate-forme (peut-être pas en premier lieu, mais pourquoi pas plus tard ?). Après tout on voit bien DOSBox être utilisé sur raspberry pi, la Wii ou même des téléphones android pour jouer à des jeux DOS sur ces derniers. Que PCem ne soit pas disponible sur toutes ces plateformes (sauf le raspberry pi) ne l'empêchera pas d'y apparaître un jour.

Merci Deksor pour toutes ces explications. J'avoue ne pas bien connaître l'informatique de 1981 (le site que j'administre se focalise sur la décennie suivante).

Il est regrettable que certaines pratiques du début des années 1980, mauvaises a posteriori, aient rendu pertinente une émulation plus poussée, car c'est bien ce que je retiens de tes explications. Comme il n'y avait pas beaucoup de modèles différents, certains développeurs PC ont écrit des programmes de la même manière qu'un développeur pour console de jeux peut se permettre : coder pour un matériel bien spécifique, et c'est le crash assuré si la machine n'est pas rigoureusement conforme à la configuration prévue. Un programme pour PC bien conçu ne doit pas poser de tels soucis. Un processeur x86 moderne peut exécuter nativement MS-DOS 6.22 alors que c'est pourtant un système compatible avec le 8088 (même si certaines fonctionnalités réclament d'avoir au moins un 80286 ou un 80386).

Les pratiques décrites ci-dessus ont dû être rapidement délaissées dans le monde du PC, car le besoin de rétrocompatibilité est apparu très tôt. En 1984, les ingénieurs de la firme IBM ont fait en sorte de garantir au maximum la rétrocompatibilité de son PC/AT, malgré que celui-ci était animé par un 80286 au lieu du 8088 comme le PC/XT. En 1985, Intel a sorti le 80386, dont son mode protégé avait une compatibilité satisfaisante avec les programmes écrits pour le 8088 (avec le 80286, il faut quitter le mode protégé, impliquant pour ce cpu d'être réinitialisé). Sans oublier les clones ; les développeurs n'avaient donc plus aucun d'intérêt de concevoir un logiciel pour une machine spécifique.

Néanmoins, PCem ne se contente pas d'émuler les processeurs des premiers PC (pour lesquels il a existé des programmes spécifiquement conçus pour eux), donc l'intérêt de l'émulation me laisse interrogatif pour les processeurs plus évolués ; seule la portabilité (rendre l'émulateur disponible sur ARM) semble le justifier.

Deksor a écrit : *

20 juin 2020 01:57

Il existe même un virus qui ne fonctionne que sur les 8088/8086 ! https://www.f-secure.com/v-descs/pingpong.shtml

F-Secure a écrit :

There is one small bug in the virus code, which causes a crash on '286 machines (and also V20, '386 and '486). The reason is that the author used the "MOV CS,AX" instruction, which only exists on '88 and '86 processors.

M'aurait-on menti sur la rétrocompatibilité ? Il est vrai que le 80286 est connu pour ne pas être parfaitement rétrocompatible et les processeurs ultérieurs ont repris certains de ses défauts car exploités avantageusement (accès à 1088 au lieu de 1024 Ko en mode réel) .

En effet, tous les PC n’étaient pas parfaitement, du moins 100% compatibles, avec le modèle original d’IBM. La preuve en est, que les magazines informatiques de l’époque donnaient un indice de compatibilité des clones testés.

J’ai lu récemment un article sur l’Amstrad PC1512 et qui précisait que ce clone était un excellent compatible, meilleur que l’original sur de nombreux point, mais malheureusement pas compatible à 100%. La liste des rares logiciels d’époques non-compatibles (ou du moins ne réagissant pas de la même manière que sur IBM PC était indiqué dans l’article).

Il en était ainsi pour chaque machine testée.
Toutefois, il me semble, que ces problèmes de compatibilité, n’étaient pas liés au microprocesseur puisque les clones utilisaient tous des 8088, 8086 ou leurs équivalents NEC, mais plus à une histoire de qualité de rétroingénierie pour imiter le BIOS IBM qui était protégé par des brevets.

Cordialement,

Je ne dirais pas que ces programmes sont nécessairement mal conçus, il était coutume de programmer pour un matériel spécifique même sur d'autres ordinateurs. Dans le contexte de son époque ça avait beaucoup de sens ! (En plus je ne sais pas s'il était prévu à la base que le pc ait des successeurs, et encore moins des clones !).

Ensuite ces techniques n'étaient souvent pas utilisée juste pour nous embêter, c'était bien souvent pour gagner des performances, des couleurs, etc.

Par exemple on peut penser au "composite artifacting" utilisé sur les cartes CGA via la sortie composite. Le cga en mode graphique est limité à 4 couleurs laides ... Mais en utilisant les défauts du composite et de la carte cga d'IBM, on peut monter jusqu'à 16 couleurs ! C'est beaucoup plus intéressant

Cette technique n'est d'ailleurs pas unique au PC, l'Apple II avait subi le même genre de hack pour décupler ses capacités graphiques.

Il y a juste un gros problème ... Il faut avoir une sortie composite, et une carte cga IBM. Très peu de cartes cga de clones sont parvenues à répliquer correctement ce hack ... Par exemple mes ATi smallwonder ont une sortie composite et ce sont des cartes cga, mais si j'essaie des programmes qui utilisent cette technique ça marchera, sauf que les couleurs seront à l'ouest (en plus il faut une TV compatible NTSC, car le composite des cartes CGA est en NTSC)


Il y a aussi des clones qui ont apporté des nouvelles choses qui ont pu avoir du succès en leur temps mais qui ont vu leur fonctionnalités disparaître plus tard au profit de d'autres technologies.
On peut par exemple penser à l'IBM pc jr ou son clone le Tandy 1000. Ces deux machines étaient des compatible PC, mais apportaient leur lot de technologies. Ces deux machines peuvent afficher en 16 couleurs en mode graphique et ce bien avant l'ega, et ont une puce audio trois voies.

Tout ça rends ces machines un peu plus taillées pour les jeux que les PC et XT contemporains. Et il n'y a pas vraiment eu d'autres clones qui furent compatibles.
Ni les cartes ega, ni les cartes VGA ne sont compatibles avec les modes graphiques pc jr/tandy 1000. Et les cartes son ne sont pas compatibles avec la puce audio trois voies.

Comment faire du coup ? ^^ bah on émule tout (parce qu'en plus ces machines pouvaient avoir une gestion de la mémoire un peu différente)

@64Knum
C'est vrai mais c'était surtout pour les applications pro. Pour les jeux et les applications un peu plus obscures, c'est un autre monde.

Bonjour à tous !

Toutes ces discussions sont effectivement très intéressantes, le monde de l'émulation me passionne depuis que je l'ai découvert, malheureusement mes connaissances sont inexistantes en terme de programmation, je suis un simple utilisateur bien que certaines fois, émuler une machine demande pas mal de connaissances, comme pour le NEC PC-9801 qui reste bien compliquée !

Citation :

Que PCem ne soit pas disponible sur toutes ces plateformes (sauf le raspberry pi) ne l'empêchera pas d'y apparaître un jour.

Petite rectification, PCem existe bel & bien sur Linux également, je l'ai essayé sur Mint.

Salutations !

La question que je posais se focalisait sur le processeur, Deksor, alors que tu évoques ici les cartes graphiques. Cela n'en reste pas moins intéressant, mais je n'ai jamais douté de l'utilité d'émuler les autres composants. Mis à part le support de quelques standards d'affichage, les GPU plus récents n'ont pas pour vocation d'avoir la rétrocompatibilité des processeurs x86 vis-à-vis de leurs ancêtres. Dans la vidéo dont tu as donné le lien, https://www.youtube.com/watch?v=yHXx3orN35Y, ce n'est pas un mode standard CGA qui est utilisé, mais une combine spécifique à un modèle de carte bien précis. Niveau compatibilité, on est proche du zéro absolu. Cela n'aurait aucun inconvénient pour une console de jeu, mais ce n'est pas pareil pour un PC.

Deksor a écrit : *

20 juin 2020 14:23

Je ne dirais pas que ces programmes sont nécessairement mal conçus

A posteriori si, ça peut être considéré comme une mauvaise conception. Le problème de compatibilité ne se posait évidemment pas lorsqu'il n'y avait pas encore de clone ou de successeur à l'IBM PC mais, comme je l'ai écrit, ce besoin d’inter-compatibilité entre les différents clones et de rétrocompatibilité s'est fait vite ressentir ; le PC original ayant été - en quelque sorte - "victime" de son succès puisque des clones et des successeurs ont été fabriqués. Ou alors, on peut dire que ce sont les ordinateurs ultérieurs qui ont été mal conçus puisqu'ils sont imparfaitement compatibles avec le modèle de référence (c'est une autre façon de voir les choses).

Imagines la situation de nos jours : tu remplaces ton PC le plus moderne et constates avec amertume que tes programmes favoris ne fonctionnent pas sur ton nouvel appareil à cause d'une différence de processeur : le recours à la virtualisation ne permet pas de les réutiliser, parce que ce n'est pas lié à une différence de système d'exploitation ou d'un autre composant matériel ; tu dois alors tout émuler, et te contenter probablement de performances laborieuses alors que c'était super fluide sur ton ancien PC.

Deksor a écrit : *

20 juin 2020 14:23

Comment faire du coup ? ^^ bah on émule tout (parce qu'en plus ces machines pouvaient avoir une gestion de la mémoire un peu différente)

Si le PC jr et le tandy 1000 ont une gestion de la mémoire qui ne respecte pas les règles imposées par l'IBM PC original, alors MS-DOS et PC DOS ne pourraient pas fonctionner dessus ! Pour rappel, il n'y a pas seulement les restrictions liées au processeur 8086/8088 (1024 Ko de RAM), il y aussi la manière de répartir la mémoire (640 Ko pour les applis, 384 Ko pour les périphériques, dont une partie pour la vidéo, une autre pour les ROM et le BIOS, etc.) qui elle est propre à l'IBM PC et ses compatibles. Rien n'empêche un 8088 d'allouer plus de 640 Ko pour une application, c'est IBM qui a défini ce seuil pour son PC, et non pas Intel. Je sais qu'il existe des hacks pour avoir plus de mémoire conventionnelle sur un PC, mais tu dois alors renoncer aux blocs de mémoire prévus pour la vidéo (qui se situent juste après les 640 premiers Ko) car l'allocation des derniers blocs doit manifestement rester inchangée (BIOS, autres ROMs).

Si, les tandy/PC jr utilisent une gestion de la mémoire différente. Mais elle est suffisamment similaire pour être compatible avec le PC. En revanche elle est liée à la carte vidéo (ce pourquoi j'en parlais). En gros, la mémoire du PC jr était à l'origine de 128Ko. Mais ces 128Ko pouvaient être partagés à volonté entre le processeur et la carte vidéo !

Ensuite il existe des effets graphiques qui dépendent d'horloges internes à l'ordinateur.

Comme par exemple celui-là : https://www.youtube.com/watch?v=8tZe5Go0jz0
Ce jeu, sur un écran CGA avec une carte CGA, est capable d'afficher plus de 4 couleurs en mode graphique ! Sa technique ? Il change la palette graphique en plein milieu de l'affichage. Sauf que pour savoir quand changer la palette, il faut être parfaitement synchronisé, et ça c'est lié à des horloges internes de l'ordinateur.

Il y a encore "pire" ; cet effet là : https://www.youtube.com/watch?v=mZSepcma948
Pour celui-là il faut activer/désactiver la fonction de "couleur de fond" rapidement, à la bonne vitesse, en fonction de ce quoi est capable le processeur ET la carte graphique.

Comme je disais, c'est un tout. Dans les ordinateurs de cette époque tu ne peux pas juste émuler les périphériques et exécuter nativement sur le processeur. Chaque composant est dépendant des autres surtout quand on essaie d'exploiter ces composants au mieux.

Évidemment les programmes qui sont dans ce genre de cas sont minoritaires, mais ils existent.


Quand aux programmes mal conçus à posteriori, d'accord. Mais ça n'a aucun sens de dire qu'ils ont été mal conçus à leur époque.

Tiens d'ailleurs

Citation :

Un processeur x86 moderne peut exécuter nativement MS-DOS 6.22 alors que c'est pourtant un système compatible avec le 8088 (même si certaines fonctionnalités réclament d'avoir au moins un 80286 ou un 80386).

C'est plus tout à fait vrai depuis que Intel a décidé d'abandonner le BIOS ... Cela veut dire que l'ère des "compatible PC" touche à sa fin.
D'ailleurs qu'est-ce qui nous garantis que les ordinateurs du futur seront même basés sur du x86 comme ils le sont actuellement ? D'ici que ça arrive, ce type de raccourci ne sera plus possible.