Je pense qu’il a tout fait lui même, un copain Igor voulait des infos :
Tu peux nous refaire un topo rapide sur le blitter instant ?
Voici ce que le dev a répondu :
Il était une fois le blitter ! 😀
Faut voir le blitter comme un 2eme CPU qui bosse normalement en // du 68k et de l’affichage
Pour le démarrer il faut ecrire la taille du blit à effectuer Largeur x Hauteur.
Blitter instant:
C’est pour simplifier le codage de l’emulateur, le blitter fait tout le boulot en une instruction du 68k.
Mais des fois dans les demos, ca lance le blitter pour tout effacer au 2/3 de l’écran et se disant que le temps que le blitter arrive au 2/3, l’affichage aura terminé le dernier 1/3
Du coup si c’est instant, ca efface tout d’un coup et ca clignotte sur le dernier 1/3 … (Démo Hunt for Seventh October est un bon exemple)
Blitter non instant (c’est comme le vrai ou presque):
Moi j’ai fait un blitter par ligne, mais c’est deja mieux que le blitter instant !
En gros je répartis les 226 cycles mémoire par ligne en une fois (X+Y+Z=226)
do {
X cycles d’affichage = 1 ligne
Y cycles de blitter
Z cycles de CPU
} while
Mais il faut bien partager ces 226 cycles pour les 3 sachant que affichage est prioritaire puis le blitter puis le CPU ! (sauf avec un mode optionnel où le CPU recupére quelques cycles quand meme…)
Et le blitter a aussi des trous dans ces cycles mémoire dans certains modes que le CPU peut utiliser !
Et c’est la que c’est le bordel 😀
(En plus j’ai simplifié un peu car il faut ajouter le copper, les DMA audio, les refresh mem, les sprites qui bouffent des cycles aussi ! et le copper peut aussi lancer le blitter et attendre la fin du blit, etc.)
Vrai blitter
do {
1 cycle de blitter ou 1 cycle de CPU ou 1 cycle d’affichage
} while
Mais c’est bcp plus gourmand à émuler !
Igor : Quel boulot, merci pour ces détails !
Est-ce qu’ils arrivaient vraiment à planifier ces comportements synchro des puces en construisant l’Amiga ou bien c’était un peu « on met tout ça et on verra après comment ça tourne » ?
Réponse du dev :
Oui c’était tout prévu aux p’tits oignons ! En fait, c’est encore plus fort sur les 226 cycles, le 68k a besoin de 113 cycles acces mémoire pour fonctionner à 100% car le CPU ne fait pas que des acces mémoire à chaque cycle. Du coup ca permettait de partager la chip mem entre le 68k et les autres ! Mais si les autres consomment plus de 113 cycles, ca commence à ralentir le 68k, jusqu’à l’arreter complétement si les 226 cycles sont utilisés
ChromeBook ASUS - A1260/64 - http://mikedafunk.over-blog.org
