[UAE] WinUAE 6.1.0 beta 1 (11/04/2026)

WinUAE 6.1.0 beta 1 (11/04/2026)

https://eab.abime.net/showpost.php?p=1792847&postcount=1

– L’émulation Copper a été réécrite pour s’aligner sur la logique de bas niveau (machine à états à 3 niveaux relativement simple basée sur les schémas d’Alice). Cela est nécessaire pour prendre en charge les cas particuliers complexes d’écriture VHPOSW. Le code d’émulation est désormais beaucoup plus court et plus simple ; tous les « hacks » liés aux cas particuliers COPxJMP ont été supprimés.

– Le positionnement de l’affichage a été unifié entre le mode natif et le mode programmé. Par exemple, le positionnement en mode PAL natif et en mode programmé, qui définit les paramètres PAL correspondants, est désormais identique. Cela inclut également le réglage de l’overscan ; auparavant, les modes programmés ignoraient les paramètres du mode TV.

– Le positionnement de l’affichage utilise désormais uniquement la synchronisation générée par Agnus/Alice et, en option, les signaux de suppression (comme sur les écrans réels ; synchronisation + suppression est la valeur par défaut, compatible avec les versions antérieures), ce qui permet un positionnement correct même si le mode est très inhabituel. Auparavant, le positionnement utilisait des positions de synchronisation/suppression PAL/NTSC fixes ou le contenu des registres de synchronisation/suppression du mode programmé ; ce mode ne fonctionne que si le mode n’est pas trop inhabituel.

– La hauteur de l’affichage va de la fin de la suppression verticale au début. Si la suppression verticale est complètement absente (ce n’est pas nécessaire dans la réalité, il suffit d’avoir du noir dans la zone de suppression verticale pour ne pas perturber l’étalonnage du niveau de noir de l’écran), la taille verticale va du début de la synchronisation verticale (plus quelques lignes) au début de la synchronisation verticale suivante. La largeur horizontale utilise la suppression horizontale (ou, si elle est absente, va de la synchronisation horizontale + quelques CCK au début de la synchronisation horizontale suivante).

– L’option « Source de synchronisation du moniteur » du panneau « Chipset » a été renommée « Mode de synchronisation / positionnement du moniteur ». Les trois premières options permettent de sélectionner le mode de positionnement/taille basé sur la suppression (par défaut, mêmes options que dans les versions précédentes) ; les trois nouvelles options permettent de sélectionner le mode de positionnement/taille basé sur la synchronisation. C’est essentiellement ainsi que fonctionnaient à l’origine les écrans CRT ; les modèles plus récents disposaient d’une logique de contrôle numérique et pouvaient également utiliser la suppression pour le positionnement.

– Le mode « Overscan extrême » correspond désormais à la sélection du mode de positionnement/taille basé sur la synchronisation.

– Le centrage horizontal du panneau d’affichage devrait fonctionner (au moins un peu mieux) en modes à double balayage.

– Les options de centrage horizontal et vertical du panneau d’affichage sont désactivées et effacées si le mode de surbalayage est « Overscan+ » ou supérieur (et restaurées automatiquement si le surbalayage est réinitialisé à sa valeur d’origine au cours de la même session). Auparavant, le centrage était déjà ignoré en mode « Overscan+ », mais les options de l’interface graphique n’étaient pas effacées.

– La mise à l’échelle en nombres entiers était incorrecte si, par exemple, la verticale était doublée mais que l’horizontale était en mode lores ou shres sans double balayage.

– Ajout de l’option de rapport d’aspect « Mise à l’échelle entière automatique » au panneau Affichage. Si elle est cochée, toutes les combinaisons de résolution/mode de ligne, y compris les modes à double balayage, ont toujours un rapport d’aspect entier correct. Sans cette option, certains modes programmés sont très hauts et étroits ou vice versa. L’option est automatiquement activée sauf si la configuration chargée comporte déjà une nouvelle entrée de configuration, si la configuration du filtre a des facteurs de zoom horizontaux et verticaux différents, si la résolution n’est pas haute définition ou si le doublement vertical n’est pas activé.

– La détection du mode « Doublescan » (qui active le redoublement horizontal interne) est désormais plus précise. Cette fonction sert à ajouter un redoublement horizontal 2x/4x afin de conserver le bon format d’image (nouvelle option ci-dessus). Les modes « Doublescan » consistent en des lignes de balayage de demi-largeur dont le nombre est doublé, ce qui donnerait un format d’image inesthétique sans redoublement horizontal. Tous les modes programmés devraient désormais présenter un format d’image correct si l’option « Mise à l’échelle entière automatique » est également cochée (correct, c’est-à-dire ni trop haut et étroit, ni trop court et large)

– La mise à l’échelle automatique et l’échelle entière automatique devraient désormais fonctionner pleinement dans tous les modes programmés.

– L’action « LOCATE OBJECT » du système de fichiers (dos/Lock() crée un paquet « LOCATE OBJECT » du système de fichiers) vérifie désormais si le fichier ou le répertoire existe physiquement et renvoie une erreur « introuvable » s’il était mis en cache mais introuvable ; le nœud de cache obsolète est également vidé. Auparavant, si le fichier/répertoire était déjà en cache puis supprimé côté hôte, Lock() réussissait quand même.

– Les couleurs du curseur de souris sprite matériel uaegfx ne s’actualisaient pas tant que la forme du sprite n’était pas également modifiée. Cela n’était normalement pas visible car la forme était toujours mise à jour après le changement de couleur. (WinUAE 6.0.4 ?)

– Le SDMAC de l’A3000 utilise désormais des transferts DMA de type « word » ou « long » (selon la version de RAMSEY) et supprime le dernier octet impair (WORD) ou 1 à 3 octets supplémentaires (LONG), conformément au matériel réel. Le bug du pilote qui ne transfère pas les 1 à 3 derniers octets restants se produit désormais également en émulation.

– Le DMAC DMA A2091/A590 utilise désormais des opérations de lecture/écriture DMA par mot et ne transfère plus le dernier octet impair, conformément au matériel réel. (Cela devrait également corriger le bug du pilote mentionné plus haut, mais cela n’a pas encore été confirmé)

– La synchronisation de l’horloge hôte a été déplacée du processus du système de fichiers de répertoires vers la tâche d’assistance de la ROM de démarrage UAE, qui s’exécute en permanence lorsque la ROM de démarrage UAE est activée. La synchronisation de l’horloge ne nécessite plus la présence d’au moins un système de fichiers de répertoires.

– Les adaptateurs de port d’affichage (après avoir été mis à jour pour fonctionner avec la nouvelle émulation d’affichage) fonctionneront en modes Overscan/Overscan+/Extreme. Actuellement, l’A2024 est le seul qui fonctionne. (Mais pas entièrement en mode Extreme). Les adaptateurs de port d’affichage/CD32FMV/Genlock sont désormais toujours désactivés en mode Ultra extreme overscan.

– Le débogueur ? prend désormais en charge les paramètres décimaux et les formats à virgule flottante 6888x (simple = $xxxxxxxx.S, double = $xxxxxxxxyyyyyyyy.D, étendu = $xxxx.yyyyyyyyyyyyyyyy.X). « ?. » active/désactive l’affichage des valeurs à virgule flottante ; désactivé par défaut, les valeurs à virgule flottante sont toujours affichées si la valeur d’entrée n’est pas un entier. Registres à virgule flottante pris en charge (RFP0 = utiliser le contenu actuel de FP0). REMARQUE : si des valeurs à virgule flottante sont utilisées dans les calculs, ceux-ci sont effectués en utilisant le format double de l’hôte. (Sera remplacé par un softfloat 80 bits à l’avenir)

– Quelques corrections et ajustements du débogueur.

– Ajout de *.hda au filtre de fichiers de la boîte de dialogue des fichiers durs. (WinUAE 6.0.4 ?)

– Si les sprites étaient en mode AGA 64 bits et que les registres de données contenaient des valeurs non nulles, le mode sprite passait alors en mode non 64 bits, puis le registre de données était mis à jour (Copper/CPU) ; seule la variable interne de données de sprite non 64 bits était mise à jour et les graphismes antérieurs à la mise à jour s’affichaient si le sprite repassait en mode 64 bits. (Virtual Karting 2) (WinUAE 6.0.4 ?)

– Le paramètre de filtrage basse résolution n’était pas implémenté dans la routine de dessin générique et lente (utilisée uniquement lorsque des effets sous-pixel doivent être émulés). (Virtual Karting 2 présentait une seule ligne de pixels non filtrés)

– Correction d’un problème où les fichiers d’état 68000/10 cycles exacts étaient aléatoirement corrompus si le CPU était en cours d’instruction et effectuait une lecture du bus de la puce au moment de l’enregistrement du fichier d’état (6.0.x). Ajout d’une solution de contournement partielle permettant à certains fichiers d’état déjà corrompus de se charger correctement. (Bug très stupide : une variable a été temporairement remplacée par la constante zéro lors de la refonte de la version 5.x vers la 6.x, mais elle n’a jamais été restaurée) (WinUAE 6.0.4 ?)

– L’interruption de synchronisation de mots du disque n’était autorisée que lorsque DSKLEN WRITE=0, mais elle n’est inhibée que lorsque l’écriture sur le disque est active. Cela ne fonctionnait plus depuis quelques versions. (Global Trash / Silents) (WinUAE 6.0.4 ?)

– Les lignes masquées par le réglage d’overscan du téléviseur ignoraient également la détection de collision entre les plans de bits et les sprites.

– La commande SCSI REZERO UNIT de uaescsi.device devrait arrêter la lecture d’un CD audio. (WinUAE 6.0.4 ?)