Tradu-France, le site de la traduction d'émulateurs et plugins

WinUAE 5.0.0 Beta 6 - 32/64 Bits... Benjamin Siskoo - 20/04/23 - 1 Commentaire(s)

Nouvelle bêta qui apporte quelques corrections. Voici les nouveautés :

Passage à la version 5.0. Plus de versions 4.10.x.
Le mode de commutation automatique du joystick gauche/droite est de retour, désactivé par défaut, ajoutez input.autoswitchleftright=true pour l'activer.
Ajout de l'entrée de configuration input.advancedmultiinput qui permet actuellement d'insérer le même périphérique d'entrée dans plusieurs ports (panneau des ports de jeu) et qui permettra à l'avenir de supporter l'interface graphique de plusieurs périphériques d'entrée dans le même port de jeu.
Activation du FPU JIT lorsque la case JIT est cochée et que l'émulation FPU (avec le mode CPU hôte) est déjà activée.
Correction d'un plantage possible en quittant l'émulation lorsque le mode RTG avec sprite matériel est actif (bêta 5).
L'insertion d'une image disque non formatée Amiga (par exemple une image formatée PC DOS) dans un lecteur Amiga 3.5" DD standard était rejetée, la vérification de la compatibilité du lecteur n'acceptait pas le lecteur 3.5" DD standard. L'image était acceptée si le lecteur était un lecteur HD 3,5" (Ce problème a probablement été résolu lorsque le support des lecteurs Bridgeboard a été amélioré).
La fenêtre d'analyse initiale de la ROM était invisible (Je ne sais pas quand cela a été supprimé ou si cela dépend de la version de Windows).
Ajout d'une configuration personnalisée du chemin d'accès aux données dans le panneau Chemins. Chemin de données = chemin par défaut où les fichiers de configuration, les logs, les fichiers d'état, etc. sont chargés et sauvegardés. Ceci était supposé avoir été ajouté il y a des années... (précédemment disponible via le paramètre -datapath de la ligne de commande). Le panneau Chemins affiche également le chemin de données actuellement actif.
Les modes générés en interne par uaegfx n'avaient pas de drapeau actif et les paramètres d'affichage (total vertical/horizontal et longueurs de synchronisation, valeurs ignorées par uaegfx) étaient techniquement invalides. Mise en place du drapeau actif, totaux hor/ver légèrement plus grands que la résolution visible et ajustement des valeurs de synchronisation. Le type de carte n'était pas réglé sur uaegfx (il a été réglé correctement, puis écrasé par une valeur erronée).
La mise à jour des sprites matériels RTG dans la version 5 a ajouté une mise en cache qui n'était pas correctement vidée lors de la mise à jour de la forme du curseur.
Si l'événement de synchronisation du chipset était mis en file d'attente dans le même cycle que l'événement hsync, l'événement hsync était exécuté en dernier. L'événement hsync devrait toujours être prioritaire. Cela a été "optimisé" il y a quelque temps mais c'était une erreur (L'écriture de BPL1DAT pendant le même cycle n'activait pas les sprites dans la configuration ECS Denise).
Très tôt, l'écriture de BPL1DAT n'a pas mis à jour correctement la position horizontale minimale visible du sprite, et dans certaines situations, le sprite qui était "caché" derrière la bordure n'est pas devenu entièrement visible.
Si BPL1DAT active le(s) sprite(s) et que la condition "borderprite" était possible (ECS Denise ou AGA), les sprites activés activaient l'état border sprite même si le nouveau pixel visible du sprite aurait été caché par le démarrage du HDIW. AGA 0.5 pixel lores condition "borderprite" + borderblank activé : Le pixel complet du "borderprite" (1 lore) devient visible.
L'accès DMA BPL1DAT au plan de bits n'ouvre plus la bordure si OCS Denise et la position BPL1DAT étaient avant la fin de HBLANK (Fonction OCS Denise non documentée, n'existe pas dans ECS Denise ou AGA qui permet l'ouverture de la bordure après le début HSYNC). L'écriture manuelle de BPL1DAT le faisait déjà. L'accès le plus précoce possible à BPL1DAT de ECS Denise qui ouvre la frontière était 2 cycles trop tard.
Emulation du sprite superhires ECS Denise plus précise de la sélection des couleurs (accès "brouillé" à la palette paire/impaire). Les sprites attachés ne sont pas encore corrects (ils font quelque chose dans ce mode mais cela ne peut pas être ce que fait l'attachement qui fonctionne normalement). Il apparaît également que la première colonne de pixels du sprite ECS superhires est invisible (pas transparente, apparaît comme COLOR0, pas le plan de bit de fond), ce qui n'est pas encore émulé. Les sprites 4 à 7 ne fonctionnent pas (rien n'apparaît à l'écran) en mode ECS superhires (Agnus continue à écrire normalement SPRxPOS/CTL et SPRxDATA/B).