WinUAE 6.0.0 Beta xx

[Benjamin Siskoo]

Beta 20 :

Le mode rapide de dessin + HAM + partie masquée à gauche en overscan TV causait des artefacts HAM.

En mode rapide, le HAM en super-haute résolution dans une image en haute résolution, ou le HAM en haute résolution dans une image en basse résolution, n'incluait pas les pixels ignorés dans le calcul des couleurs HAM.

Le mode rapide de dessin n'appliquait pas le masque d'adresse de la mémoire chip aux adresses des bitplanes.

Les artefacts de défilement dus à la suppression de l'entrelacement en mode rapide sont en grande partie corrigés.

Des artefacts pouvaient apparaître dans la bordure droite si les bitplanes se terminaient avant HDIW. Mode rapide uniquement.

Les paramètres de filtre ne doivent pas limiter la largeur ou la hauteur de l'affichage en mode overscan extrême (ou supérieur), ces modes doivent toujours afficher toute la zone d'image.

Les cartes RTG émulées matériellement n'avaient pas de synchronisation verticale (vsync) (b21).

La restauration de l'état DIWHIGH était peu fiable.

Le redimensionnement automatique (et les filtres associés) fonctionne maintenant correctement même si la fin de HDIW ne correspond jamais.

L'option "filtered lores" est à nouveau prise en charge. (Si la résolution du mode Amiga est supérieure à celle du panneau d'affichage : normalement, un pixel sur deux est ignoré, le mode "filtered lores" prend la moyenne des couleurs de deux pixels).

Les changements de fréquence de rafraîchissement via les écritures VPOS(H)W fonctionnent à nouveau. (Par exemple dans Wings of Death, DynaBlaster qui simulent du 60 Hz). Les modes non cycle-exacts n'acceptent que des déplacements VPOS vers l'avant et pas de valeurs hors plage.

Positionnement de l'affichage corrigé pour le RTG avec les réglages par défaut (les 4 cases décochées dans le panneau RTG).

Légers ajustements de la position de l'image à l'écran et des captures d'écran pour mieux correspondre aux anciennes versions.

[Benjamin Siskoo]

Beta 24 :

• Si le DMA des bitplanes était actif pendant le masquage vertical (vertical blanking), il était utilisé à tort pour détecter automatiquement les positions de début/fin horizontales du redimensionnement automatique.
• Ajustements supplémentaires du début/fin horizontal pour correspondre exactement au comportement manuel du filtre dans la version 5.3.1.
• Les modes overscan TV sont désormais presque identiques à ceux des anciennes versions. Le mode étroit (Narrow) est légèrement plus large.
• Taille du tampon de la file d'attente d'événements augmentée : plusieurs canaux audio avec AUDxLEN=1 pouvaient le faire déborder.
• Lorsqu'un mode de filtre comme le redimensionnement automatique détecte un changement de mode, un redessin complet est forcé (sans cela, les lignes en mode rapide ne sont pas garanties d'être redessinées avec la bonne position ou le bon masquage).
• L'émulation de fin anticipée d'un pixel en super-haute résolution avec Borderblank 1 s'appliquait incorrectement aussi à la zone de bordure. Dans certaines situations, lorsque la position HDIW et/ou l'état de Borderblank étaient modifiés pendant la bordure, cela pouvait provoquer des artefacts d'un pixel mal coloré.
• Correction de données corrompues dans les bitplanes sur le côté droit de l'écran dans certaines conditions en mode de dessin rapide (généralement en haute ou super-haute résolution lorsque la fin HDIW dépassait la fin des bitplanes).
• Les écritures inutiles dans VHPOSW (comme le fait AR3) sans mode cycle-exact provoquaient des artefacts graphiques en modes rapides.
• L'OSD du nombre de lignes (313p, etc.) affiche maintenant « ---- » (comme le compteur de FPS) quand la synchronisation d'affichage n'est pas stable. Cela évite d'afficher des valeurs aléatoires dans des situations étranges.
• Chargement direct de la ROM Kickstart sur A1000 (sans passer par la ROM de boot + disquette KS) corrigé.

[Benjamin Siskoo]

• Le filtre de redimensionnement automatique ajoutait deux fois le multiplicateur de taille dans certaines situations.
• Les lectures du registre de collision CLXDAT sont désormais également basées sur les cycles horizontaux (mais ne sont pas encore parfaitement précises au pixel près). Les lectures CLXDAT restent basées sur les lignes si la configuration ne dispose pas d'un timing mémoire précis par cycle ou si le CPU est en mode le plus rapide possible. Aucun programme réel ne s'en soucie et les collisions sont aussi très rarement utilisées.
• Le mode programmé qui activait HBLANK et HSYNC programmés (BEAMCON0 VARHSYEN et/ou VARCSYEN) sans VARBEAMEN utilisait un 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 dans l'émulation du contrôleur de clavier 68HC05 ne fonctionnait pas.
• Correction d'un bug où la dernière ligne en mode de dessin rapide avait une mauvaise couleur, surtout dans les modes programmés. (Changement de la couleur de la dernière ligne en noir lorsque la souris est proche du bas de l'écran, puis retour à la couleur de bordure en remontant la souris.)
• L'instruction FPU FMOVEM vers/depuis le format étendu utilise le code "original" lorsque le JIT est activé. Ceci est un correctif de test pour les changements "aléatoires" de valeur FPU signalés en mode JIT FPU.
• Le bug de bordure/blanc de la dernière ligne était le dernier défaut connu du mode rapide. Merci de signaler s'il reste encore des anomalies.

[Benjamin Siskoo]

   

• Les modes TV Overscan du panneau d'affichage n'avaient aucun effet si le mode de filtrage "Aucun redimensionnement" était sélectionné.
•     Correction du scintillement de la dernière ligne lié à la suppression des artefacts d'entrelacement dans certains modes overscan, ainsi que de la ligne "hors synchronisation" lors du passage du mode de dessin précis au mode rapide.
•     Suppression de la case à cocher "Émulation sous-pixel" dans le panneau Chipset. L'émulation v6 est toujours parfaitement précise au niveau des sous-pixels en modes précis. Le support dans le fichier de configuration est conservé (compatibilité rétroactive).
•     Il semble que la seule ROM de démarrage connue pour les Apollo 500/2000 ne prenne en charge que la variante AT500/AT2000. Le pilote ne s'initialise pas si le bit de configuration matériel SCSI est activé. Le SCSI est désormais désactivé par défaut (ce qui le rend compatible AT500/AT2000), une option a été ajoutée au panneau "Extensions". Ce comportement a peut-être été altéré lors de l'ajout ou de la mise à jour de la prise en charge des accélérateurs Apollo, qui utilisent exactement le même matériel SCSI.
• Le problème de défilement horizontal sur le bord droit n'a toujours pas été corrigé. C'est un cas problématique car je pensais que le système d'exploitation ne permettait jamais que ce bug se produise, mais apparemment c'est possible, et j'ai conçu le mode rapide sans prendre en compte ce cas particulier... Une solution sera trouvée. Peut-être...
• Le V-Sync sans latence nécessite également une mise à jour de l'émulation du chipset v6.

[Benjamin Siskoo]

Le mode de dessin rapide masquait toujours les adresses de la mémoire Chip aux tailles normales de la mémoire Chip, ce qui causait des graphismes corrompus si une mémoire Chip 32 bits était activée.

Le problème de défilement horizontal du bord droit est désormais émulé correctement (c'est-à-dire avec les bons artefacts) uniquement dans les modes d'émulation précis. Les modes processeur rapide « corrigent » le bug. Je n'aime généralement pas « corriger » les défauts de conception matérielle, mais je n'ai pas trouvé d'autre solution simple pour résoudre ce problème sans de gros changements dans les modes de dessin rapides. Cela pourrait mieux fonctionner dans une future version. Normalement, cette situation (très grand dépassement horizontal à droite + défilement horizontal) est rarement visible car elle donne un rendu très moche.

Suppression des artefacts d'entrelacement — le défilement très défectueux a été corrigé (b28). Il peut encore y avoir une ligne unique avec des graphismes incorrects avant qu'elle ne soit redessinée dans l'image suivante, mais comme cela survient en même temps qu'un autre bug courant (qui affecte toutes les lignes lorsque les pointeurs de bitplans sont mis à jour pendant le défilement), ce n'est pas un problème important.

Si la seule différence entre les valeurs de défilement des champs pairs et impairs dans BPLCON1 concernait uniquement les bits AGA haute résolution ou super-haute résolution, le mode d'émulation qui émule séparément les plans pairs et impairs n'était pas sélectionné et les plans impairs utilisaient la même valeur de défilement que les plans pairs.

Correction d'un crash lors du double-clic sur la racine de l'arborescence de configuration.

Le changement d'entrelacement de la version b25 ne fonctionnait pas complètement, il était encore possible d'obtenir, par exemple, un saut de hauteur d'image entre champs longs et courts en mode de filtrage auto-échelle.

L'émulation du délai "borderblank 1 shres" a été partiellement cassée dans la mise à jour b24. (Supportée uniquement dans les modes d'émulation précis.)