[UAE] WinUAE 6.0 beta 5 (16/01/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

[stephbb75 Level 11Messages : 1399]

Salut,

Il semble que se soit un gros on refait tout

Moi je resterais (pour le moment) à la version 5 puisque mon CPU ne supporte pas le AVX2
et que cela fait bien longtemps que je ne teste plus les beta.
Faudrait que pense tout de même à changer mon PC un jour, le I5 2300 commence a dater…

https://youtube.com/@stephbb75

[sink Level 6Messages : 252]

excellent, merci pour la trad, je la test depuis 20 minutes et je vois des différences effectivement, l’année commence bien ;)

[Staff Zarnal Level 22Messages : 7753]

J’aurais bien testé rapidement mais impossible ( aujourd’hui ) faute d’AVX2.

A1200 Commodore mutant " FrankenAmiga" + 68040 + 8MO + SD 8go - A1200 ESCOM. HD 20MO. Mon meilleur et seul A500 : WinUae. CPC 6128-CPC 464.

[Staff Aladin Level 25Messages : 15138]

WinUAE 6.0 beta 2 (05/01/2025)

https://eab.abime.net/showpost.php?p=1724317&postcount=29

– Correction de l’image doublée horizontalement des sprites AGA de 32 bits de large.

– Correction de la mise à l’échelle automatique dans les modes AGA.

– Correction du mode « HAM » avec 4 plans ou moins. La variable de couleur du pixel précédent du mode HAM n’était pas réinitialisée correctement.

– L’artefact du bord droit NTSC était incorrectement visible sur le bord gauche en mode overscan normal. Il n’est désormais visible qu’en mode Overscan+ et supérieur.

– Les modes double balayage que le VGA commute automatiquement en superhires avaient un décalage horizontal aléatoire.

– L’écriture de BLTCON1 ne mettait pas à jour le bit DESC interne, ce qui faisait que l’écriture suivante de BLTBDAT pouvait utiliser la valeur de direction du blit précédent lors du décalage initial.

– Correction du débordement du tampon du fichier d’état du blitter lors de la sauvegarde.

– Correction d’un mouvement étrange de la fenêtre lorsque l’on clique sur la barre de titre et que l’on la maintient enfoncée et que l’option « Capturer automatiquement la souris lorsque la fenêtre est activée » est activée.

– La hauteur du tampon d’affichage interne était trop grande de quelques pixels, si la hauteur de la fenêtre était exactement la même que celle de l’affichage visible, le bas de la fenêtre avait une ligne noire et la ligne supérieure était manquante.

[Staff Aladin Level 25Messages : 15138]

WinUAE 6.0 beta 3 (07/01/2025)

https://eab.abime.net/showpost.php?p=1724765&postcount=34

– Ajout d’un délai plus long avant que le bit BPLCON0 ERSY=1 sans genlock n’arrête les compteurs horizontaux/verticaux.

– Deux autres corrections de conflits cuivre/blitter. (Le cuivre arrêté à cause d’un registre dangereux ne comptait pas comme le cuivre n’ayant pas de requêtes actives, la séquence COPJMP suivie du dernier cycle de MOVE « sauté » ne « sautait » pas l’écriture).

– Correction d’un autre débordement du fichier d’état.

– Les modes CPU plus rapides ont maintenant un pipeline RGA séparé plus long qui permet au CPU rapide d’écrire plusieurs registres Denise/Lisa dans un seul CCK sans causer de débordements et d’écritures de registres perdues.

– L’effet « SWIV scorebord » (BPLCON2>=5 et 5 ou 6 plans) ne fonctionnait pas en mode 6 plans.

– Réimplémentation des options TV Overscan.

[Staff Aladin Level 25Messages : 15138]

WinUAE 6.0 beta 4 (11/01/2025)

https://eab.abime.net/showpost.php?p=1725468&postcount=43

– Copper DMA est désactivé et vblank strobe : le cuivre charge le nouveau pointeur immédiatement, et non pas lorsqu’il obtient le premier slot DMA.

– ERSY=1 sans genlock arrête maintenant réellement les compteurs horizontaux/verticaux au lieu de faire semblant. Ancien hack supprimé.

– La lecture du contenu du registre de couleur AGA (RDRAM=1) lisait l’ancienne valeur de la ligne de balayage précédente à cause de la mise en mémoire tampon du bus RGA.

– Certains modes ECS Denise avaient des déchets visibles à gauche et/ou à droite et l’affichage se terminait 1 pixel trop tôt.

– Le champ de révision par défaut (non modifiable) du chipset avancé Agnus n’incluait pas toujours le drapeau du bit ECS. Bogue visuel uniquement. (Très vieux bogue).

– Les modes TV Overscan fonctionnent maintenant, y compris les modes genlock.

– Mise à jour de la largeur d’écran et de la position horizontale en mode programmé.

[Staff Aladin Level 25Messages : 15138]

WinUAE 6.0 beta 5 (16/01/2025)

https://eab.abime.net/showpost.php?p=1726437&postcount=60

– Le filtre Autoscale est à nouveau corrigé.

– BPLCON4 était effacé lors du passage à la volée de OCS/ECS à AGA, ce qui provoquait des couleurs de sprites erronées.

– L’option « Wait for blitter » fonctionne à nouveau.

– L’option « Remove interlace artifacts » fonctionne à nouveau (avec un scintillement de la dernière ligne, ceci sera corrigé plus tard). Elle utilise maintenant une logique différente qui pourrait mieux fonctionner lorsque le mode entrelacé est « non standard ».

– La taille de l’espace PCI IO de Prometheus FireStorm est de 2M, seuls les 1M les plus bas ont été mappés et ils ne l’ont pas été correctement.

– Ne pas enregistrer la lecture longue de l’état de Prometheus FireStorm en tant qu’accès à l’espace de configuration.

– Fusion de quelques mises à jour mineures de l’émulation Voodoo depuis 86box.

– Ajout d’une fonctionnalité matérielle précédemment manquante : Le comptage des lignes longues PAL/NTSC provoque toujours la fin du champ, même si LOF=0 (seulement important lorsque l’on fait des trucs VPOSW). La ligne longue horizontale NTSC est également toujours prise en compte, même si LOL=0.

– Ajout de l’adresse et de la longueur aux noms des fichiers d’échantillonnage.

– Interroger l’état du lecteur PC/du lecteur réseau/du lecteur amovible uniquement après avoir confirmé le type de lecteur. (Par exemple, si « Add PC drives at startup » ou « CDFS automount » est seulement coché, ne pas demander l’état des éventuels lecteurs réseau qui pourraient répondre lentement).

[Auteur]

Réponses