[UAE] WinUAE 6.0 beta 29 (27/05/2025)

WinUAE 6.0 beta 1 (04/01/2025)

https://eab.abime.net/showthread.php?t=119496

 

REMARQUE IMPORTANTE

Cette version est actuellement optimisée pour la précision et la compatibilité, et non pour les modes rapides de l’unité centrale. Les modes CPU rapides fonctionnent, mais ils sont loin d’être aussi rapides qu’avant. La version actuelle n’est pas destinée à être utilisée uniquement en mode WB.

– Toutes les lignes du mode chipset natif sont toujours entièrement dessinées. L’optimisation qui saute les lignes non modifiées sera ajoutée plus tard. (Peut-être. Ce type d’optimisation nécessite beaucoup de variables de données dynamiques, ce qui n’est pas forcément très utile et peut même aggraver la situation). Le plan actuel est de dessiner des lignes sans effets secondaires (pas de cuivre actif, etc.) en utilisant le mode « direct from chipram » basé sur les lignes, ce qui devrait être suffisant pour une utilisation rapide de WB en mode natif. En d’autres termes : cette version est plus lente, en particulier dans les modes CPU rapides, du moins pour l’instant.

– Remove interlace artifacts ne fonctionne pas. Assurez-vous qu’il est désactivé.

– Le CPU hôte requis est passé à AVX2 (~2015+ CPUs). Il s’agit d’une décision arbitraire pour éliminer les CPU « trop vieux » jusqu’à ce que les choses s’améliorent. La vitesse n’est pas très importante à ce stade. La version non-AVX pourrait également être disponible lorsque/si des compilations automatisées sont ajoutées plus tard.

– La case à cocher Subpixel dans le panneau Chipset ne fait rien. Il est maintenant toujours émulé en interne.

– Estimation de la sortie de la version finale : été 2025 ou peut-être même plus tard.

 

MISES À JOUR

Chipset (commun) :

– Tous les hacks d’émulation de chipset personnalisés ont été supprimés, la plupart des anciens codes d’émulation personnalisés ont été supprimés et remplacés par un code entièrement nouveau qui est beaucoup plus simple et plus facile à comprendre, et qui fonctionne de manière plus proche du matériel réel. Certains signaux sont émulés presque au niveau de la porte logique. Basé sur les schémas d’Alice.

– Le pipeline RGA interne est entièrement émulé.

– Les émulations Agnus et Denise sont séparées, le transfert de données se fait via un bus RGA externe émulé. Les registres stroboscopiques sont utilisés pour la synchronisation des puces comme sur le vrai HW. Plus de raccourcis.

– La chaîne de registres à décalage pour la sélection des slots DMA câblés (rafraîchissement, disque, audio, sprites) est fidèlement émulée.

– Les conflits DMA sont émulés de manière précise, sans hacks.

Affichage/plans de bits/sprites/cuivre :

– La suppression horizontale et verticale et les impulsions de début/fin de synchronisation, de csync, d’égalisation de csync, etc. sont maintenant émulées de manière précise, à la fois câblées et programmées. Le mélange des impulsions câblées et programmées est également entièrement pris en charge. La partie générateur de synchronisation est presque émulée au niveau de la porte logique.

– Les modifications VPOSW/VHPOSW à la volée sont entièrement supportées, toutes les anciennes limites ont disparu. (Ross, modes d’écran spéciaux ! Par exemple, le mode écran où toutes les lignes affichables sont la même ligne verticale Agnus répétée autant de fois qu’il y a de lignes visibles ou le mode où le hardwired blanking est désactivé, ce qui permet un affichage beaucoup plus large que d’habitude tout en restant compatible PAL. Oui, comme sur le C64, les « frontières » câblées de l’Amiga peuvent également être ouvertes avec un timing CPU précis par cycle))

– Les compteurs verticaux et horizontaux « virtuels » et réels d’Agnus/Alice sont maintenant complètement séparés, l’émulation de l’affichage fonctionne maintenant correctement même si l’Agnus vertical ou horizontal est déplacé vers l’arrière ou vers l’avant ou n’importe où (même en dehors de la plage d’affichage normale), un nombre illimité de fois par ligne et/ou par champ.

– Tous les modes d’écran (y compris le « faux » mode NTSC ou similaire) comptent désormais le nombre total de lignes « virtuelles » et l’utilisent pour définir la hauteur d’affichage. Ces modes fonctionnent désormais même s’ils effectuent de multiples modifications du VPOSW.

– L’entrelacement est désormais détecté si les 4 derniers champs sont de type LONG/SHORT/LONG/SHORT ou SHORT/LONG/SHORT/LONG. Il faut vérifier les 4 derniers champs pour éviter qu’un changement de champ court à long soit détecté comme mode entrelacé lors d’un démarrage aléatoire ou par KS.

– Les bits matériels LOF ou LACE ne sont plus utilisés pour la détection des champs courts/longs entrelacés. La position de départ VSYNC (par rapport à HSYNC/HCENTER) est désormais utilisée pour détecter le type de trame LONG ou SHORT (comme pour les écrans réels). Il est possible de créer un mode entrelacé valide avec des écritures VPOSW délicates (ou moins délicates si ECS et en utilisant des registres de mode programmés) sans jamais modifier le bit LOF.

– Prise en charge complète de la granularité horizontale des plans de bits et des sprites AGA hires/shres. Le mode sous-pixel séparé n’existe plus.

– Emulation des slots ECS Agnus/AGA UHRES bitplane et sprite RGA DMA (0x78, 0x7a). (Fonctionnalité inutile mais parce qu’ils peuvent voler des cycles au cuivre, au blitter et au CPU, cela doit être émulé).

– COPJMP1/2 a chargé la nouvelle adresse 1 CCK trop tard. (Cela ne fait une différence que si quelque chose fait COPJMPx et écrit ensuite immédiatement dans COPxLCx).

– Le conflit COPJMP + blitter actif du cycle impair du CPU ne fonctionnait pas correctement si le COPJMP était immédiatement suivi d’un déplacement de cuivre demandé précédemment. (Ceci n’est pas encore tout à fait correct)

– Ajout des modèles A1000 (EHB Denise et non EHB Denise) au panneau Chipset. Les entrées existantes ont également été renommées.

– L’écriture BPL1DAT active les plans de bits 1 pixel plus tôt que la copie BPLxDAT (OCS/ECS). AGA le fait 1 hires pixel plus tôt.

– En milieu d’écran, le changement BPLCON0 lores->hires met à jour le compteur horizontal BPLCON1 Denise après un délai supplémentaire de 0,5 CCK (ECS Denise) ou de 1 CCK (OCS Denise). Le changement de lores à lires n’a pas de délai supplémentaire. L’AGA n’a pas de délai supplémentaire. Ceci n’est pas entièrement émulé. Les effets secondaires du shifter interne entrelacé ne sont pas émulés. (Il semble presque impossible de les mettre en oeuvre sans les schémas de Denise, les glitches qui peuvent se produire sont vraiment étranges).

NTSC/STRLONG : (Cette fonction a été pénible à émuler, elle est normalement invisible et n’a pas vraiment besoin d’être émulée, même en NTSC, mais vous pouvez écrire dans STRLONG en mode PAL et obtenir un décalage horizontal de 1 pixel loresque et quelques glitches sur le bord droit de l’écran, il a donc fallu l’émuler également).

– L’état LOL (long line) du NTSC est émulé avec précision. Une mauvaise correspondance entre le stroboscope STRLONG et l’état LOL entraîne désormais un décalage horizontal correct de 1 pixel de long. (Inadéquation = par exemple écriture manuelle sur STRLONG alors que la ligne n’est pas longue)

– Les versions NTSC A1000 et OCS Agnus ont une fonction non documentée : tout accès au VPOSW réinitialise le bit LOL (interne caché). Les versions ECS/AGA ont la même fonction mais le bit LOL n’est plus interne.

– Le comportement de STRLONG a légèrement changé entre toutes les versions de puces (A1000/OCS/ECS/AGA). A1000/OCS Denise le fait au début de hblank, provoquant un motif en dents de scie visible au début de hblank (A1000 et OCS ont une différence de 1 pixel de lores dans le motif en dents de scie), ECS Denise le fait 2 pixels de lores plus tôt, provoquant un motif alternant pixel de lores doublé/pixel de lores manquant juste avant hblank. AGA : est similaire à ECS mais avec un décalage d’un pixel shres. (AGA et ses décalages ennuyeux d’un pixel shres ici et là. Argh !)

Blitter :

– Le séquenceur de canaux de Blitter devrait être maintenant 100% précis (à l’exception d’un possible changement de ligne à non ligne en cours d’opération). Les timings des « micro-opérations » de Blitter ne sont pas encore 100% = quand exactement appliquer le décalage A, quand le décalage B, quand A/B/C doit être géré en interne, etc. Cela sera testé et mis en œuvre à l’avenir. (N’affecte le résultat du blitter que si BLTxDAT/décalages/etc sont modifiés au milieu du blitter. Les modifications de l’activation du canal, du mode de remplissage, du descriptif et de l’intermède devraient déjà être parfaitement exactes).

– La logique de l’ordonnanceur du canal D en mode bloc de mélange correspond maintenant au comportement réel (D est « armé » 2 CCK après la sortie du bit de mélangeur, puis tout cycle de mélangeur libre suivant est utilisé pour D, il n’y a pas d’état unique et simple « D SÉLECTIONNÉ »). L’ordonnancement de l’écriture de « Final D » est maintenant également émulé avec précision. Une condition précédemment inconnue est également émulée : avec 2 bits ou plus dans le shifter de l’ordonnanceur, il peut y avoir une seconde écriture « Final D » supplémentaire après que le blit s’est déjà terminé.

– Lorsque le blitter a plus d’un bit tournant dans le registre de décalage de l’ordonnanceur (les bits d’activation du canal BLTCON0 ont été modifiés pendant que le blitter fonctionnait) et que plusieurs canaux sont sélectionnés en même temps, le canal résultant est l’AND de l’adresse RGA (ABC uniquement, D n’est autorisé que si tous les autres canaux ne sont pas actifs en même temps et le bit ne doit pas être en position A même si A est désactivé). Auparavant, la sélection était basée sur l’ordre des canaux, ce qui était erroné, et le mode ligne ne permettait pas de gérer les sélections multiples en même temps.

– Si l’écriture BLTxMOD ou BLTCON1 DESC est basculée et qu’elle est immédiatement suivie d’un transfert DMA sur le même canal, le transfert utilise l’ancienne valeur modulo. (Comme le font les plans de bits, mais le blitter n’a pas été mis à jour pour le gérer). BLTxPT écrit 1 CCK avant le transfert DMA du même canal (l’écriture est ignorée), ce cas spécial n’était pas fiable non plus.

– BLTZERO est activé lorsque le blitter obtient le prochain cycle libre après l’écriture de BLTSIZE. Le timing est le même que celui du bit A1000 BLTBUSY.

CIA :

– Si la direction des données du port série CIA est modifiée (CRA OUTMODE basculé), l’état du port série est réinitialisé, une éventuelle transmission ou réception en attente est immédiatement interrompue.

Divers :

– L’exigence du CPU hôte est passée à AVX2 (~2015+ CPUs). Cela pourrait être abaissé dans le futur mais AVX2 a des instructions très utiles pour les optimisations futures.

– Le changement de type de chipset à la volée a été amélioré (par exemple les couleurs AGA sont maintenant préservées, tous les registres n’étaient pas entièrement préservés auparavant).

– Les collisions entre plans de bits pairs et impairs sont maintenant très simples et peu coûteuses à émuler. Le mode de collision par défaut est maintenant la collision totale.

– Le mode de débogage ultra extrême montre maintenant les pixels des plans de bits et des sprites entièrement à l’intérieur des masques horizontaux et verticaux. Auparavant, seule la couleur de fond était visible.

– Le débogueur DMA peut maintenant être visualisé avec des lignes Agnus ou des lignes virtuelles (« v » = ligne agnus auparavant, « vv » = ligne virtuelle). La première ligne virtuelle est la ligne de démarrage vsync.

– Le débogueur DMA affiche désormais l’état du compteur horizontal Denise (1 CCK = 2 horloges Denise, une horloge Denise équivaut à un pixel lores).

– Le débogueur DMA affiche maintenant l’état actuel des signaux liés à l’affichage (synchro, blancs, etc., voir ci-dessous).

– Les cycles de blitter et de bitlane modulo add du débogueur DMA sont marqués d’un ‘M’.

– Ignorer tous les points d’arrêt du débogueur pendant la séquence de sortie/redémarrage.

– Si le CPU lit un octet dans l’espace du chipset personnalisé, le mot complet de 16 bits est affiché dans le débogueur DMA.

– Le dump CIA du débogueur inclut maintenant aussi les contenus PRA et PRB qui incluent l’état disque/série/bouton de feu/etc. (valeurs à l’intérieur des [])

– Le débogueur visuel DMA utilise toujours des lignes virtuelles.

– Sauter complètement le rendu des images D3D en mode warp si l’image est sautée.

– Ajout du nombre et du type de ligne à la ligne d’état de la bordure inférieure (par exemple 313p ou 625i), prise en charge complète de tous les modes bizarres.

– Suppression de l’option couleur 16 bits.

– Le mode TCP/IP du port série utilise maintenant le drapeau TCP_NODELAY pour réduire la latence.

– Correction du type de configuration de la RAM embarquée TekMagic.

– Le délai de redémarrage d’une seconde ne s’activait pas lorsque la réinitialisation était effectuée après le démarrage de l’émulation (cela fonctionnait peut-être il y a quelques versions).

– Si le mode de canal sonore WASAPI sélectionné n’est pas supporté, essayez tous les modes de canaux possibles jusqu’à ce qu’il soit supporté, ou jusqu’à ce que toutes les combinaisons aient été testées. De même, si le nombre de canaux doit être modifié pour passer d’un mode stéréo à un mode supérieur (par exemple, le dispositif sonore ne supporte que les modes 6 ou 8 canaux en interne), utilisez la variante stéréo clonée 6/8 canaux car l’utilisateur peut n’avoir que des haut-parleurs stéréo.

– La suppression à la volée du dernier périphérique sonore (par exemple une carte son USB sans périphérique sonore intégré activé) a provoqué un crash en mode WASAPI.

– Fichier de configuration uniquement statefile_path= peut être utilisé pour avoir des chemins d’accès au fichier de configuration par fichier de configuration. Remplace (mais n’écrase pas) l’entrée Paths-panel.

– Ajout de la prise en charge du type de partition GPT Amiga (GUID={3F82EEBC-87C9-4097-8165-89D6540557C0}). Fonctionne de la même manière que le type de partition 0x76 avec les disques partitionnés MBR.

– L’assembleur du débogueur n’acceptait pas toutes les variantes de MOVEM.

– Ajout de l’émulation du contrôleur IDE RIPPLE par Matt Harlum.

Emulation du clavier de bas niveau :

– Émulation optionnelle du clavier au niveau matériel ! (*). Le clignotement du CAPS LOCK de l’Odyssey / Alcatraz est enfin supporté.

– Trois variantes émulées (toutes connues ?), CSG 6570-036 (utilisé dans presque tous les modèles sauf les premiers claviers A1000 et A1200), 68HC05C (utilisé seulement dans A1200) et D8039HLC qui a été utilisé dans certains claviers A2000. Ces trois microcontrôleurs 8 bits différents disposent d’une petite quantité de ROM et de RAM, de quelques ports d’E/S, d’un timer unique et d’autres fonctions d’E/S.

– 6570-036 est basé sur 6502, utilise l’émulateur de CPU https://github.com/gianlucag/mos6502. ROM de 2048 octets. Les premiers claviers A1000 ont le même MCU mais un code plus ancien qui n’empêche pas la rémanence des touches et qui ne semble pas avoir été supprimé.

– 68HC05C est basé sur 6800, utilise l’émulateur de CPU https://github.com/philpem/m68emu. La ROM fait environ 8000 octets. (Une partie de la RAM est cachée par IO/ROM)

– D8039HLC est basé sur 8048, utilise l’émulateur 8048 inclus dans l’émulateur Altirra (Atari 8 bits et expansions). ROM externe de 2048 octets (EP).

– Le comportement du clavier est maintenant totalement précis, les touches de l’hôte sont converties en matrice de clavier simulé, le code MCU émulé lit la matrice et envoie le code en série au port série CIA.

– Le clavier fonctionne maintenant comme un vrai clavier, l’avertissement de réinitialisation, l’absence possible de retournement de n-touches et d’autres effets secondaires si les programmes font de mauvaises choses avec le handshake des touches fonctionnent correctement. Il est évident que le clavier de votre PC hôte doit être doté d’une capacité de rotation complète des touches n pour obtenir des résultats précis en matière de brouillage et de fantômes de touches du clavier émulé.

– Un effet spécial est le clignotement du verrouillage des majuscules, par exemple Odyssey / Alcatraz le fait vers le début de la démo. Il inonde le pauvre MCU d’un grand nombre d’impulsions de handshake, chaque impulsion provoque une demande d’interruption, ce qui fait que le CPU n’a pas le temps de faire autre chose que de gérer des interruptions inutiles. Après environ 40 ms, le chien de garde externe réinitialise le CPU et le code de réinitialisation fait clignoter le voyant de verrouillage des majuscules. L’astuce du clignotement du verrou des majuscules ne fonctionne pas sur le D8039HLC car il n’a pas de chien de garde. Notez que l’A1200 68HC05C se réinitialise lorsque le code de réinitialisation est activé.

– Si l’avertissement de réinitialisation du clavier du panneau Advanced chipset est coché, le MCU KB gère la séquence de réinitialisation et la réinitialisation est détectée en vérifiant si le MCU maintient la ligne KCLK basse >500ms (comme les Amigas de grande taille avec 6570-036 et D8039HLC) ou si la broche TCMP est tirée vers le bas (A1200, 68HC05C). Si cette option n’est pas cochée, la réinitialisation est générée immédiatement lorsque les touches de réinitialisation sont pressées (comme le font les claviers A500 et A600).

– Ajout d’une led OSD pour le verrouillage des majuscules (couleur rougeâtre/jaunâtre). Note : le verrouillage des majuscules n’est pas synchronisé avec l’état du verrouillage des majuscules de l’hôte en mode d’émulation de clavier matériel.

– Support des fichiers d’état implémenté. (La ROM n’est pas sauvegardée avec le fichier d’état)

– si l’émulation complète est activée, que le fichier d’état est chargé et que le fichier d’état ne contient pas l’état MCU du clavier, le code MCU est exécuté en premier dans une boucle serrée jusqu’à ce que le clavier soit en état d’inactivité (codes de touche init et init envoyés) pour ne pas causer de confusion possible. Le programme chargé dans le fichier d’état n’a probablement pas besoin de codes de touches supplémentaires.

– Ajout du « Keyboard » aux extensions intégrées. Il a deux objectifs (jusqu’à présent), permettre la sélection d’une image rom personnalisée et l’option d’émuler les défauts du clavier (RAM/ROM/Watchdog) que le MCU du clavier détecte et fait clignoter la led capslock.

– La case à cocher « Keyboard connected » du panneau du chipset a été remplacée par le mode clavier (« Disconnected », « UAE keyboard » et la liste des différents modèles de claviers émulés de bas niveau).

*) Il y a une histoire derrière tout ça. Ross a accidentellement perturbé le handshake du clavier dans l’un de ses tests ross(tm) et cela a fait que le clavier de l’A500 a partiellement cessé de répondre. Je ne m’en suis pas vraiment préoccupé à ce moment-là, mais quelques mois plus tard, il a été testé à nouveau et le comportement bizarre du clavier a été réduit à une simple impulsion « trop longue » du handshake. Le dump ROM du MCU a été désassemblé et examiné. Ma décision a été de l’émuler complètement parce que ce comportement, le timing du transfert du code des touches (et le clignotement du verrouillage des majuscules) est pratiquement impossible à émuler avec précision en haut niveau. J’ai trouvé un émulateur de 6502 très facile à utiliser et il m’a fallu environ 2 jours pour l’implémenter. (D’autres MCUs ont été implémentés quelques semaines plus tard)

 

NOTES DIVERSES :

Débogueur DMA nouvelles lignes Denise/Lisa et Agnus/Alice :

Denise/Lisa : WHVUB (W=Horizontal DIW, H = Horizontal blanking, V = Vertical blanking, U = Burst, B = BPL1DAT HDIW). REMARQUE : Ces champs ne sont remplis que lorsque la ligne de balayage est entièrement émulée. Les lignes de balayage partielles ne comportent que des points d’interrogation.

Agnus/Alice : WBEE HVCHVCB (W=Vertical DIW, B = BPRUN interne [devient D si DDFSTOP passe la condition], E = VE interne, E = P_VE interne (ECS/AGA uniquement), HVC = Hardwired HSYNC/VSYNC/CSYNC suivi par HS/VS/CS programmé, B = HBLANK programmé)

A1000 PAL Agnus est pseudo-PAL : le nombre de lignes et la ligne de fin VB ont été modifiés en valeurs PAL (262/263 -> 312/313, 20->25), la bascule LOL a été désactivée mais tous les autres timings utilisent les valeurs NTSC. Cela affecte la sortie CSYNC (positions de changement d’état vsync impaires/paires erronées, impulsions d’égalisation/serration erronées), mais la plupart des téléviseurs PAL « modernes » des années 1980 le gèrent sans problème. Ceci est maintenant émulé dans Ultra extreme debug (C).

Seules les modifications de A1000 à OCS Agnus semblent l’être :

– Correction du bit occupé du Blitter. (L’écriture de BLTSIZE met BUSY immédiatement, à l’origine BUSY était mis en place quand le blitter avait le premier slot DMA libre).

– Le début du vblank vertical câblé a été déplacé de la ligne 0 à la dernière ligne. C’est ce qui a déplacé l’interruption VERTB de la ligne 1 à la ligne 0, mais comme la solution était un simple changement de ligne interne de déclenchement VB (l’Agnus A1000 avait déjà des signaux internes pour les deux conditions), cela a aussi causé un nouvel effet secondaire : le strobe de la ligne 0 est devenu STRVBL (c’était STRHOR dans l’A1000. L’Agnus ECS l’a corrigé et il est devenu STREQU), mais comme l’OCS Denise ignore STRVBL (Oui, c’est illogique, n’est-ce pas ? STREQU active VB, STRHOR désactive VB. STREQU et STRVBL activent tous deux VB si ECS Denise ou AGA), la ligne 0 est toujours la dernière ligne visible si elle est combinée avec A1000 ou OCS Agnus. La dernière ligne est la dernière ligne visible si ECS Agnus/AGA.

 

EXEMPLES DE TESTS :

– Anciens fichiers d’état. Presque tous devraient encore fonctionner (quelques rares cas spéciaux de blitter ne peuvent plus être gérés).

– Toutes les démos habituelles mal codées (modifications de blitter, mid blit etc) devraient toutes fonctionner.

– Les collisions sprite à sprite/sprite à plan de bits/plan de bits à plan de bits devraient (encore) toutes fonctionner.

NOTE : Redémarrez toujours l’émulation entière entre les tests. Parfois, tous les états ne sont pas complètement réinitialisés lors d’un changement de configuration. Ceci sera corrigé plus tard.

Sujet

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 14 (10/03/2025)

https://eab.abime.net/showpost.php?p=1735553&postcount=222

REMARQUE : de nombreux changements dans la manipulation des graphiques internes peuvent provoquer des ruptures inattendues.

– Le côté gauche de l’écran était corrompu si la résolution horizontale était suffisamment faible.

– S’assurer que le thread de dessin est terminé avant de quitter ou de modifier la configuration.

– Correction des mauvaises fonctions de verrouillage/déverrouillage des surfaces D3D.

– La réinitialisation du clavier sans émulation de bas niveau du clavier ne forçait pas le CPU à réinitialiser l’état lorsque les touches de réinitialisation étaient maintenues enfoncées. Le CPU continuait à exécuter des instructions, probablement aléatoires, parce que la ROM overlay était déjà active et que les cartes d’autoconfiguration étaient désactivées, ce qui pouvait entraîner l’enregistrement d’accès mémoire illégaux aléatoires.

– La prise en charge du fil d’arrière-plan du blitter d’émulation Matrox a été réactivée.

– La prise en charge des filtres logiciels restants a été supprimée.

– Correction du bogue slirp (depuis qu’il a été ajouté) qui ne semblait pas affecter WinUAE mais affectait d’autres ports UAE.

– Le mode GDI ne libérait pas toutes les ressources lors du passage du mode natif<>RTG.

– La fermeture du dernier nœud ouvert de l’arbre de configuration ne mettait pas à jour le registre/ini.

– La prise en charge de la liste des commandes du débogueur H DMA est de retour. Maintenant seulement listé si D est ajouté (HD).

– Les accès CPU KS ROM sont listés dans le débogueur DMA. 68000/010 seulement parce que le 68020+ peut avoir un temps d’accès à la ROM plus rapide que le chipset. Utilise la ligne de débogage DMA de la CIA, mais comme il n’y a pas assez d’espace, seuls l’état R/W, la taille et l’adresse sont affichés.

– La gestion du chevauchement début/fin de la mémoire tampon RGA a été omise, par exemple les écritures de couleur cuivre près du début de la ligne de balayage ont été omises.

– L’affichage Genlock avait un effet d’oscillation verticale en mode threadé. Genlock, niveaux de gris et CD32FMV fonctionnent. Les autres adaptateurs de port d’affichage ne doivent pas encore être utilisés.

– Correction du défilement sous-pixel en mode rapide non CE. (Peut ne pas être encore parfait)

– Les modes de surbalayage TV n’affectent pas la suppression horizontale en mode rapide.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 15 (17/03/2025)

https://eab.abime.net/showpost.php?p=1736757&postcount=238

– L’état de vide vertical était pris à partir d’une mauvaise variable en mode programmé, ce qui obligeait à ne pas utiliser le mode rapide lors de l’élaboration de graphiques bitplane en mode programmé.

– Le registre CIA SDR a été ajouté au dump CIA (commande c du débogueur).

– Le délai de changement de valeur XOR du plan binaire BPLCON4 n’était pas correct.

– Correction de la logique de la seconde fenêtre du 1200TX et implémentation de la restriction de la seconde fenêtre : les 3 bits supérieurs de la fenêtre 2 sont pris sur la position de la fenêtre 1.

– Quelques modifications pour prendre en charge les futures cartes PCI multiples et la réorganisation des cartes PCI.

– Cacher la case à cocher « autoboot disabled » du périphérique d’extension lorsque le périphérique n’a pas de cavalier d’autoboot. (ou n’ont rien à voir avec le stockage)

– « Ajouter un disque dur » avec un périphérique de stockage à partition MBR et plusieurs partitions : le premier élément était un mélange des propriétés du disque entier/de la première partition. (b1)

– Ajout de https://aminet.net/package/docs/hard/512kWOM A1000 512k WOM expansion emulation. Option dans Expansions->Built-in expansions.

– Le dernier cycle RGA de Denise de la nouvelle ligne « rapide » a été sauté. S’il y avait une écriture dans le registre personnalisé, elle n’était pas vue par le côté Denise.

– Correction des lignes de balayage du panneau d’affichage du mode rapide.

– Vérifier les changements d’écran en mode natif lorsque vsync démarre (lorsque toute l’image est terminée), et non pas lorsque le compteur vertical d’Agnus se réinitialise. Les glitches des dernières lignes lors du changement de mode devraient avoir disparu.

– Certaines opérations FPU pouvaient être légèrement plus lentes en mode non-JIT alors que le FPU JIT était activé. Forcer la désactivation du FPU JIT lorsque le JIT est désactivé.

– Mise à jour du timing CPU/chipset. Les modes non JIT les plus rapides possibles sont presque aussi rapides que la version 5.3.1.

– L’optimisation du plan de bits en mode rapide qui détecte si la ligne du plan de bits a changé ou non est maintenant désactivée. Cela semble être plus lent que de toujours redessiner la ligne de plan de bits en mode rapide car cela déplace le travail du CPU de l’hôte du thread principal vers le thread de dessin et réduit les copies de mémoire du thread principal et les comparaisons qui étaient nécessaires pour vérifier si le plan de bits avait changé.

– NOTE : L’émulation du port série de Paula peut ne pas fonctionner, elle est en cours de réécriture (le lien série de Stunt Car Racer a des problèmes…).

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 16 (22/03/2025)

https://eab.abime.net/showpost.php?p=1737656&postcount=261

– EHB a été interrompu dans les modes ECS Denise et AGA. KILLEHB était toujours détecté comme actif.

– La sélection de la dernière partition pour l’ajout d’un disque dur ne fonctionnait pas correctement. Les partitions autres que 0x30/0x76 peuvent désormais être sélectionnées.

– Lorsque le mode d’écran change (PAL/NTSC/VPOSW trick etc), le changement côté hôte est retardé jusqu’à ce qu’au moins 2 cadres dos à dos aient la même largeur et la même hauteur afin d’éviter des changements de taille de cadre bizarres (par exemple pendant le démarrage lorsque le bit VPOSW LOF est modifié dans une position aléatoire de zéro à un, ce qui entraîne un changement temporaire de la hauteur du cadre).

– Désactivation du scintillement trop gênant de la led OSD CD audio.

– Correction possible du fait que l’échelle automatique ne détecte pas toujours les bordures supérieure et inférieure.

– Nettoyage de la mise à l’échelle et du positionnement internes du filtre. Simplification des calculs de coordonnées et de taille, etc. Cela ne devrait pas avoir d’effet visible mais pourrait casser certaines configurations de filtres.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 17 (25/03/2025)

https://eab.abime.net/showpost.php?p=1738218&postcount=277

– L’option de suppression des artefacts entrelacés ne fonctionnait pas complètement dans les modes non-ce. (les lignes en mode rapide n’étaient pas « scandées »)

– Le filtre d’entrelacement était ignoré (il avait disparu lors de la réécriture du chipset)

– Correction des modes de filtrage par défaut et sans mise à l’échelle (b16)

– Nouvelle validation de l’état de verrouillage du buffer de sortie causant un écran RTG vide dans certaines situations (la validation est plus stricte maintenant pour détecter les bogues. C’était un bogue.)

– Suppression de l’option de profondeur de couleur de l’interface graphique et des vérifications internes de la profondeur de couleur. La profondeur d’hôte 32 bits est la seule profondeur de couleur supportée. (Déjà partiellement supprimé dans la version 1)

– Le bit vide du tampon de transmission du port série n’était pas activé lorsque le port série était en mode « non précis ». (68030+, JIT etc. où la précision du cycle n’est pas importante). La mise à jour du port série n’est pas encore terminée.

– Le débogueur visuel DMA et les autres fonctions de débogage à l’écran fonctionnent à nouveau. Fonctionne également avec un genlock actif (par exemple lorsque le jeu ALG est en cours d’exécution).

– Le bit KILLEHB BPLCON2 fonctionne maintenant correctement.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 18 (25/03/2025)

https://eab.abime.net/showpost.php?p=1738769&postcount=285

– L’autoconfiguration du pont PCI n’était pas fiable, du moins avec les médiateurs, le premier démarrage fonctionnait, le redémarrage suivant pouvait ne pas fonctionner. (cassé il y a quelques bêtas)

– L’OSD en mode D3D11 n’était pas dessiné et avait généralement une seule image dans la mauvaise position pendant les changements de mode.

– L’option Wait for blitter pouvait provoquer des appels récursifs (et dans le pire des cas un crash dû à un débordement de pile) si le callback du pipeline du chipset était actif.

– Quelques mises à jour pour le dessin en mode rapide. (était accidentellement désactivé dans b17, le support du genlock est corrigé, les collisions entre les plans de bits pairs et impairs (CLXDAT bit 0) sont supportées et quelques autres ajustements)

– Le second cycle de rafraîchissement n’a pas été traité dans le pipeline RGA parce que la vérification NTSC STRLONG inactive a incorrectement sauté une partie du traitement du pipeline. Ce que le cuivre a écrit dans le cycle précédent n’a pas été écrit dans le registre personnalisé de Denise, ce qui a provoqué des effets secondaires étranges.

– Le sprite OCS/ECS derrière le plan de bits de hires a dessiné le plan de bits dans les lores. (Il dessinait également dans les lores lorsque le sprite était au-dessus du bitplane mais ce n’était pas visible car les pixels des lores du sprite cachaient les deux pixels des hires du bitplane)

– ECS Superhires fast mode drawing supported (sauf si le panneau d’affichage est configuré de manière à ce que le sprite soit visible). (Sauf si le panneau d’affichage est réglé sur lores mais c’est une combinaison inutile de toute façon)

– Le mouvement horizontal du pilote de la souris virtuelle fonctionne à nouveau.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 19 (02/04/2025)

https://eab.abime.net/showpost.php?p=1739410&postcount=305

– Les lores d’affichage combinés avec le mode natif des superhires ne sont plus pris en charge (cela ne fonctionnait pas très bien dans les versions précédentes). Rien n’est dessiné dans cette combinaison.

– Les ajustements du panneau de filtre affectent également le mode GDI en temps réel. Il y a toujours un scintillement horrible. A n’utiliser que si D3D9/D3D11 n’est pas disponible.

– La texture de sortie D3D9/D3D11 était toujours verrouillée lors du rendu. Les anciens pilotes D3D9 n’aimaient pas cela (et c’était de toute façon une erreur)

– La correction du rapport d’aspect des superhires par mise à l’échelle des nombres entiers ne fonctionnait pas.

– Si l’API graphique sélectionnée n’est pas prise en charge, testez toutes les autres options. D3D9, qui échouait auparavant, passait à GDI, même si D3D11 était disponible.

– Modes entrelacé + TV overscan : une ligne noire supplémentaire était visible près de la fin de l’affichage. (les modes optimisés rapides ne sont pas encore corrigés)

– Correction des sprites attachés (seuls les sprites impairs affectent l’état de l’attachement)

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 20 (08/04/2025)

https://eab.abime.net/showpost.php?p=1740267&postcount=330

– Le changement de mode de champ long/court (changement unique de LOF, pas de basculement continu entrelacé) ne recalculait pas la configuration interne du mode d’écran. Comme effet secondaire, la dernière ligne aléatoire n’était pas mise à jour correctement lors du passage du mode long au mode court.

– Correction du dessin en mode rapide et des lignes supérieure et inférieure du mode TV overscan qui n’étaient pas toujours mises à jour correctement.

– Le hack audio qui empêche une utilisation élevée du CPU si le programme règle (inutilement) AUDxPER à une valeur très basse est maintenant plus agressif mais pas assez pour casser Spaceport. (R-Type II, émulateur ReadySoft 64)

– La transmission par port série fonctionne à nouveau dans les modes non-ce.

– La correction du rapport d’aspect de la résolution horizontale/verticale à l’aide d’une échelle entière devrait maintenant fonctionner de manière plus sensée (par exemple, si superhires + doublage vertical, le résultat est toujours doublé verticalement en premier, après quoi le rapport d’échelle entier est sélectionné). Prend également en charge les modes de double balayage programmés.

– En mode AGA, les lectures de registres en écriture seule sont maintenant plus proches du comportement de la version 5.3.1 et des versions antérieures. (Artificial Paradise / NGC)

– Si la résolution/le nombre de plans était défini avant la mise à jour du FMODE et que le FMODE original était trop petit pour le nouveau mode, le mode de dessin était réinitialisé à la normale (HAM et EHB étaient dessinés en mode normal). Les embauches et les shres AGA des modes HAM et EHB ont été affectés.

– Le mode CPU non précis et l’écriture dans le registre de temporisation élevé de la CIA ne chargeaient pas immédiatement la temporisation du latch en mode one-short lorsque la temporisation était déjà en cours d’exécution. (Introduit dans certaines versions 4.9.x)

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 21 (13/04/2025)

https://eab.abime.net/showpost.php?p=1741024&postcount=349

– Les modes TV du panneau filtre et la suppression de l’overscan du filtre fonctionnent à nouveau correctement (ce qui n’était pas le cas depuis la version 1). La gestion de la suppression horizontale et verticale supplémentaire a de nouveau été modifiée, ce qui pourrait entraîner des effets secondaires.

– Les artefacts de lignes horizontales longues/courtes NTSC ont disparu dans les modes TV overscan. NOTE : NTSC a encore des problèmes avec certains modes de filtrage.

– Les couleurs des marqueurs de débogage ultra extrêmes ont été modifiées.

– La mise à l’échelle automatique utilisait également des plans non binaires pour détecter le début/la fin de l’horizontale. Cela correspond maintenant à la version 5.3.1.

– Mise à l’échelle automatique + mode de dessin rapide : la ligne supérieure était détectée comme étant trop grande d’une ligne.

– Capture d’écran en mode non PAL/NTSC : accès à la mémoire hors limites corrigé, ce qui provoquait des plantages aléatoires également lors de l’entrée dans l’interface graphique.

– Correction d’un plantage possible dans le code de dessin en mode rapide si le nombre de plans change soudainement.

– L’interruption uaegfx vertical blank pouvait être dupliquée ou perdue dans certaines situations (très vieux bogue), en fonction du réglage du taux de rafraîchissement du panneau RTG.

– Ignorer les écritures V(H)POSW en mode non-ce. Les écritures KS V(H)POSW lors des changements de mode d’écran provoquaient des effets secondaires étranges, y compris des changements de mode RTG/natif peu fiables.

– Correction de l’impression passthrough pour les pilotes d’imprimante Windows v4+ (non testé)

Ceci corrige la commutation native/RTG de SysSpeed.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 22 (19/04/2025)

https://eab.abime.net/showpost.php?p=1741945&postcount=374

– Le dessin en mode rapide + le HAM + l’overscan du téléviseur gauche masquant une partie de l’écran provoquaient des artefacts HAM.

– Le mode rapide shres HAM in hires ou hires HAM in lores n’incluait pas les pixels sautés dans le calcul de la couleur HAM.

– Le dessin en mode rapide ne masquait pas les adresses des plans de bits avec le masque d’adresse de la mémoire vive.

– Les artefacts de défilement entrelacés du mode rapide Remove ont été en grande partie corrigés.

– Des déchets étaient possibles dans le bord droit si le plan de bits se terminait avant le HDIW. Mode rapide uniquement.

– Les paramètres du filtre ne devraient pas limiter la largeur ou la hauteur de l’affichage dans les modes d’overscan extrêmes ou supérieurs, les modes extrêmes (et supérieurs) devraient toujours afficher la totalité de la zone d’affichage.

– Les cartes RTG émulées matériellement n’avaient pas de timing vsync (b21)

– La restauration de l’état DIWHIGH n’était pas fiable.

– La mise à l’échelle automatique (et les filtres associés) fonctionne maintenant aussi correctement si la fin du HDIW ne correspond jamais.

– L’option des lores filtrés est à nouveau supportée. (Si la résolution du mode Amiga est supérieure à celle du mode écran : normalement un pixel sur deux est supprimé, le mode lores filtrés prend la couleur moyenne de deux pixels)

– Les changements de taux de rafraîchissement de l’écriture VPOS(H)W fonctionnent à nouveau. (Par exemple Wings of Death, DynaBlaster fake 60Hz). Les modes non CE n’acceptent que les mouvements vpos vers l’avant et pas les valeurs hors limites.

– RTG avec les paramètres par défaut (les 4 cases à cocher dans la partie gauche du panneau RTG ne sont pas cochées), la position de l’affichage est corrigée.

– Ajustement de la position de l’affichage et de la position/taille des captures d’écran pour mieux correspondre aux anciennes versions.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 23 (25/04/2025)

https://eab.abime.net/showpost.php?p=1742789&postcount=390

– Correction du mode de filtrage central automatique.

– Lores filtrés ECS superhires implémentés. Les données de genlock des lores filtrés impairs/pairs sont maintenant également « filtrées ».

– Dans certaines situations, la bordure droite avait une différence de 1 pixel de lores entre la bordure et l’espace vide en fonction du mode de dessin.

– Correction du crash de l’enregistrement AVI.

– Mode de dessin rapide + NTSC : les problèmes de bordure gauche et droite devraient être enfin résolus.

– Correction du changement de la dernière ligne du mode de dessin rapide entre le blanc et la bordure lorsque la souris se trouvait près de la bordure.

– Lorsque la réinitialisation était exécutée, la nouvelle largeur d’écran incluait l’ancien état court/long. En mode NTSC, la nouvelle largeur d’écran était aléatoirement plus large de 2 lores pixels.

– En mode rapide non CE, en passant du RTG au chipset et si la mémoire tampon du RGA rapide est pleine, il est possible que les écritures du chipset CPU arrivent du côté Denise dans un ordre différent, ce qui provoque d’étranges effets de bord. (Écran noir à la frontière)

– Correction partielle de l’émulation A2024. (Tous les moniteurs display port ont besoin d’une mise à jour)

– Correction du bug « slirp use after free » (Andreas Grabher)

– Ajout (fichier de configuration uniquement pour le moment, « rtg_noautomodes=true ») d’une option qui désactive les modes d’écran générés automatiquement par uaegfx. Avec Picasso96 v3.4+ et P96Prefs, de nouveaux modes peuvent être créés manuellement, comme avec du vrai matériel. Note : L’ancien Picasso96 et/ou l’utilitaire PicassoMode ne supportent pas les modes uaegfx manuels.

– Ajout de 3840×1080 à la liste des résolutions uaegfx connues (« connues » = obtient l’identifiant statique du mode s’il est autogénéré).

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 24 (01/05/2025)

https://eab.abime.net/showpost.php?p=1743539&postcount=411

– Si le DMA du plan de bits était actif derrière la suppression verticale, il était incorrectement utilisé pour la détection automatique du début/fin de la mise à l’échelle horizontale.

– Plus d’ajustements du début/fin horizontal pour correspondre exactement au comportement du filtre manuel de la version 5.3.1.

– Les modes d’overscan TV sont maintenant presque les mêmes que dans les anciennes versions. Le mode étroit est légèrement plus large.

– Augmentation de la taille du tampon de la file d’attente des événements, plusieurs canaux audio avec AUDxLEN=1 pouvaient la déborder.

– Lorsque le mode filtre comme autoscale détecte un changement de mode, il force le redessin complet (sans ce mode rapide, les lignes ne sont pas garanties d’être redessinées avec la bonne position ou le blanking).

– L’émulation de la fin précoce du pixel Borderblank 1 shres était incorrectement émulée également dans la zone de bordure. Dans certaines situations, lorsque la position du HDIW et/ou l’état du borderblank étaient modifiés pendant le border, cela pouvait provoquer des glitches de pixels colorés erronés.

– Correction des déchets du plan de bit dans le côté droit de l’écran dans certaines conditions du mode de dessin rapide (généralement des hires ou des shres et l’extrémité du HDIW était plus grande que l’extrémité du plan de bit).

– L’écriture (inutile) de VHPOSW (comme le fait AR3) sans CE provoquait des glitches graphiques dans les modes rapides.

– L’OSD de comptage de lignes (313p, etc.) affiche désormais « —- » (comme le compteur de FPS) lorsque la synchronisation de l’affichage n’est pas stable. Il n’est pas très utile d’afficher des valeurs aléatoires dans des situations bizarres.

– Correction du chargement direct de la KS ROM de l’A1000 (sans utiliser la ROM de démarrage + le disque KS).

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 25 (04/05/2025)

https://eab.abime.net/showpost.php?p=1744003&postcount=433

– Correction d’un possible débordement du tampon de dessin lors du dessin de lignes vierges.

– L’état de HAM était réinitialisé lorsque le démarrage de HDIW correspondait même si HDIW était déjà ouvert.

– La désactivation de BPLCON3 BRDSPRT au milieu de l’écran ne recalculait pas immédiatement la visibilité des sprites.

– Le mode rapide arrêtait de dessiner le plan de bits plus tôt si l’affichage nécessitait un défilement horizontal (DDFSTRT et/ou BPLCON1 « mal alignés »). Cela devrait permettre de résoudre les problèmes de graphisme manquant en mode rapide près du bord droit de l’écran. (Habituellement, ces problèmes ne sont visibles que si le HDIW s’est terminé après le plan de bits).

– Le panneau d’affichage « Resolution autoswitch » fonctionne à nouveau. (Disparu lors de la réécriture de la v6)

– L’émulation de la puce SVGA de Cirrus Logic ne supporte plus que le VGA planaire lors de l’utilisation du mode texte, des modes graphiques 4 couleurs ou 16 couleurs. Cela peut augmenter les performances dans les modes SVGA normaux.

– Le mode entrelacé double (pas champs ou champs+) en mode de mise à l’échelle/redimensionnement/etc. automatique ne recalculait jamais la taille/position lors du passage en mode entrelacé. (Il attendait les champs pairs et impairs, mais maintenant seules les images complètes sont dessinées en mode entrelacé double).

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 26 (10/05/2025)

https://eab.abime.net/showpost.php?p=1744728&postcount=437

– Le filtre de redimensionnement automatique ajoutait un multiplicateur de taille deux fois dans certaines situations.

– Les lectures des registres CLXDAT de collision sont maintenant basées sur le cycle horizontal (mais pas encore parfaites en termes de pixels). Les lectures CLXDAT sont toujours basées sur les lignes si la configuration n’a pas au moins un cycle de mémoire exact ou si le CPU est en mode le plus rapide possible. Aucun programme réel ne s’en préoccupe et les collisions sont très rarement utilisées.

– Le mode programmé qui activait le HBLANK programmé et le HSYNC programmé (BEAMCON0 VARHSYEN et/ou VARCSYEN) sans VARBEAMEN utilisait le positionnement PAL/NTSC par défaut au lieu d’utiliser les valeurs HBLANK programmées pour un positionnement plus précis.

– La dernière ligne de la matrice du clavier de l’émulation du contrôleur de clavier 68HC05 ne fonctionnait pas.

– Correction de la dernière ligne du mode de dessin rapide qui avait une couleur incorrecte, principalement dans les modes programmés. (La couleur de la dernière ligne passe au noir lorsque la souris est proche du bas de l’écran et revient à la couleur de la bordure lorsque l’on déplace la souris vers le haut).

– FPU FMOVEM vers/depuis extended utilise le code « original » lorsque JIT est activé. Il s’agit d’un correctif de test pour les changements de valeur FPU « aléatoires » signalés en mode FPU JIT.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 27 (12/05/2025)

https://eab.abime.net/showpost.php?p=1745111&postcount=447

– La synchronisation entrelacée était rompue, les calculs du mode de dessin rapide affectaient les modes non rapides. (b26)

– La suppression des artefacts d’entrelacement fonctionne à nouveau (b26)

– Le mode de filtrage « par défaut » s’ajuste maintenant à la sélection de l’overscan de l’écran d’affichage.

– Les superhires en mode rapide + la résolution du panneau d’affichage réglée sur hires présentaient des problèmes de défilement horizontal.

– Add Harddrive listait certaines cartes CF (peut-être d’autres aussi) comme inaccessibles MBR partitionnées avec une seule partition même si elles avaient RDB (ou rien). Brisé dans certaines versions bêta antérieures.

– Les MCUs 65HC05 et 8039 du clavier n’étaient pas complètement réinitialisés lors de la reconnexion du clavier à la volée.

[Staff Aladin Level 25Messages : 15341]

WinUAE 6.0 beta 28 (21/05/2025)

https://eab.abime.net/showpost.php?p=1746299&postcount=458

– Les modes TV overscan du panneau d’affichage ne faisaient rien si le mode de filtrage « Pas de mise à l’échelle » était sélectionné.

– Correction de la suppression des artefacts d’entrelacement, du scintillement de la dernière ligne dans certains modes overscan et de la ligne « désynchronisée » lorsque le mode de dessin passe du mode précis au mode rapide.

– Suppression de l’émulation subpixel du panneau Chipset checbox. L’émulation v6 est toujours parfaite en subpixel dans les modes précis. Le support des fichiers de configuration n’est pas supprimé. (compatibilité ascendante)

– La seule ROM de démarrage Apollo 500/2000 connue semble ne supporter que la variante AT500/AT2000, le pilote ne s’initialise pas si le bit de configuration SCSI matériel est activé. Le SCSI est maintenant désactivé par défaut (ce qui le rend AT500/AT2000), une option a été ajoutée au panneau Expansions. Il est possible qu’il y ait eu un problème lorsque les accélérateurs Apollo, qui utilisent exactement le même matériel SCSI, ont été pris en charge ou mis à jour.

Le problème de défilement horizontal du bord droit n’a toujours pas été résolu. C’est un cas particulier car je pensais que le système d’exploitation ne permettait jamais à ce problème de se produire mais apparemment c’est possible et j’ai conçu le mode rapide pour qu’il ne se préoccupe pas de ce cas particulier. Une solution sera trouvée. Peut-être…

Le vsync sans lag nécessite également une mise à jour de l’émulation du chipset v6.

[Auteur]

Réponses