WinUAE 4.4.0 Beta 1 - 32 Bits et 64 Bits... Benjamin Siskoo - 23/04/20 - 2 Commentaire(s)
Freddy m'a envoyé la traduction française pour la dernière beta de WinUAE. Rappelons que cette émulateur Amiga, doit être le plus complet et le plus précis du marché.  J'ai pas mis toutes les nouveautés car trop nombreuses, de plus, j'ai pas pris le temps de tout traduire, j'ai utilisé un traducteur auto, donc la traduction sera approximative :
  • L'émulation 68000 est maintenant entièrement(*) précise, fonctionnellement et au niveau du cycle, y compris les effets secondaires des exceptions (drapeaux et contenus de registre non définis, etc.). Les comptes de cycles sont également corrects en mode de pré-extraction (plus compatible) si rien ne vole les cycles du CPU.
  • Les instructions du 68000 courantes sans plus compatibles sont également précises, sauf si l'instruction a un nombre de cycles variable (comme MUL/DIV et autres).
  • * = le temps d'échantillonnage de l'IPL pour interrompre la détection de changement de niveau n'est pas précis à 100%.
  • L'émulation 68010 est maintenant précise au niveau du cycle, y compris en mode boucle. (Les temps d'exception/effets secondaires, principalement les drapeaux d'erreur de bus non définis sont erronés. Les erreurs d'adresse sont correctes)
  • Le support de base du FPU a été ajouté à mon testeur de CPU. Les instructions arithmétiques de base du FPU ont été testées et leur bon fonctionnement a été confirmé. Aucune exception n'a encore été testée car le réglage du FPSR lorsque le FPU génère une exception semble présenter des différences spécifiques au CPU/FPU.
  • Mises à jour de l'émulation des erreurs d'adresse 68000 et des erreurs de bus, tous les effets secondaires/les comportements non documentés sont maintenant émulés. Les erreurs de bus générées par les prélèvements sont maintenant précises à 100% sur le plan fonctionnel (y compris les drapeaux éventuellement partiellement modifiés, les registres partiellement modifiés, etc. Exemple de cas particulier : TRAPV, si la prérecherche provoque une erreur de bus et que V est défini : le champ SR empilé d'erreurs de bus a toujours un S-bit défini et T est toujours effacé. Si V n'a pas été défini : le contenu du champ SR empilé est conforme aux attentes. Autre résultat plus courant : si un long mot est en cours de lecture ou d'écriture et que l'accès provoque une erreur de bus ou d'adresse : Les drapeaux CCR Z et N sont définis en utilisant seulement les 16 bits inférieurs du mot long. Ajout d'un mode de test d'erreur de bus pour le testeur de l'unité centrale.
  • 68010 émulation du mode boucle (prefetch et ce uniquement) NOTE : lorsque l'on passe en mode boucle dans le débogueur UAE, l'instruction bouclée semble être ignorée car en mode boucle elle est fusionnée avec l'exécution DBcc.
  • Le mode boucle du 68010 est précis au niveau du cycle. Les totaux des cycles sont corrects mais l'ordre des cycles en attente peut ne pas être entièrement correct. (TODO : faire quelques contrôles de l'analyseur logique)
  • 68010 erreurs d'adresse précises et émulation de trame de pile d'exception (seulement une partie documentée de la trame de pile, elle a beaucoup de champs non définis, comme l'erreur de bus/adresse 68020/030 pour permettre la poursuite de l'instruction après la réessai de défaut/erreur avec RTE. Ce n'est pas émulé). Prefetch/ce seulement.
  • 68010 erreur de lecture de bus émulée avec précision. (Sauf support RTE comme ci-dessus)
  • 68010 ajustements du comptage des cycles. La plupart des cycles de comptage 68010 sont maintenant corrects. (A FAIRE : revérifier plus tard)
  • MOVES était une instruction de 68020+. Elle a été introduite en 68010.
  • BKPT était l'instruction 68020+. Elle a été introduite en 68010. C'est une instruction illégale (au moins sans débogage du matériel), la seule différence est qu'elle exécute le cycle d'accès au point d'arrêt qui retarde l'instruction illégale de 4 cycles par rapport à l'instruction illégale normale.
  • L'émulation MMU 68030 a été simplifiée et optimisée.
  • La 68030 MMU semble faire l'ajustement -(an)/(an)+ avant que l'erreur de bus ne soit détectée et que le contenu du registre original ne soit pas restauré lorsque l'exception d'erreur de bus commence. Il est maintenant émulé. Aucun programme ne devrait s'en soucier.
  • gencpu indente maintenant automatiquement et correctement les fichiers cpuemu_xxx.cpp générés.
  • 68000-010 Le timing de détection des changements IPL internes du CPU est maintenant plus précis (mais pas à 100%) et plus optimal.
  • 68000-010 La synchronisation de la détection des modifications de l'IPL interne du processeur est désormais émulée en mode de pré-extraction sans cycle-exact. (Le son IK+, Warhead, etc. fonctionne désormais sans cycle-exact)
  • 68010 L'exception d'erreur de format RTE n'efface pas le drapeau de trace. 68020+ L'exception d'erreur de format RTE l'efface.
  • 68000/010 Exception étrange : le vecteur généré par la pile d'erreur d'adresse est maintenant correct. Ajout de la prise en charge des testeurs. Une erreur de bus ou un vecteur d'erreur d'adresse impair arrête le CPU.
  • L'utilisation du cycle d'exception 68000 (y compris les interruptions) est également validée.
  • 68000 BTST Dn,#x était 2 cycles trop rapide.
  • 68000 DIVU/DIVS diviser par zéro le traitement des exceptions commence après 4 cycles (était zéro).
  • 68000 JMP et JSR contrôle d'erreur d'adresse était avant le calcul de l'EA, 2-6 cycles trop tôt.
  • 68000 ADDX.L -(an),-(an) et SUBX.L -(an),-(an) avaient un mauvais ordre de cycle : c'est reada+2,reada+0,readb+2,readb+0,writec+2,prefetch,writec+0 (was prefetch,writec+2,writec+0)
  • Beaucoup de corrections approximatives (avec ou sans pré-recherche) du nombre total de cycles d'instructions du mode 68000. Les comptages de cycles sont maintenant corrects à 100%.
  • 68010 est maintenant précis au niveau des cycles.
  • 68010 MOVES.W an,-(an)/(an)+ et les deux sources et destinations an sont le même registre : le contenu modifié du registre est stocké si la taille est un mot. MOVES.L stocke le contenu original du registre.
  • 68000 MOVE cause une erreur d'adresse en écriture : l'erreur d'adresse a été vérifiée trop tôt, après la lecture, même si elle a été suivie d'une prélecture avant l'écriture.
  • Tous les CPU : La plupart des erreurs d'adresse dues à des sauts/branches d'adresse impairs sont maintenant correctement émulées en mode non-prélèvement.
  • 68020 MUL et DIV utilisent des comptages de cycles statiques (tout comme 68010. Seuls 68000 comptages de cycles MUL/DIV dépendent des valeurs d'entrée). Ajout d'un délai légèrement plus court que celui documenté pour les modes de prérecherche et de ce non prérecherche les plus rapides possibles. (MUL.L et DIV.L n'ont probablement pas de comptage de cycles entièrement statique)
>>> Télécharger : WinUAE 4.4.0 Beta 1 - 32 Bits
>>> Télécharger : WinUAE 4.4.0 Beta 1 - 64 Bits



Message de Siskoo le 25/04/20 09:01PM

Ha bonne nouvelle alors pour le 68 :) Vu tous les processeurs il en a encore pour 20 ans ^^

Merci pour ta présence comme d'hab et le traducteur que j'ai utilisé est plutôt performant :)

Message de Crashdisk le 24/04/20 10:27PM

Champagne! Merci les amis!
Un nouveau cycle commence, l'émulation du 68000 est visiblement optimal, qui sait vers quoi Toni va travailler maintenant? Le 680x0 très probablement mais bon ... on verra bien!
Encore merci pour la trad et la news (les traducteurs auto ont fait des progrès hein! ^^)
Ajouter un Commentaire


:angry: :flowers: :blink: :pinch: :blushing: :crying: :ermm: :getlost: :grin: :happy: :hug: :kiss: :laugh: :blah: :smile: :sad: :tongue: :wink:


Site Hébergé
Emulateur
Partenaires