| ★ CODING ★ Fréquence du Z80 sur CPC ★ |
| Z80frequence |
Pourquoi dit-on dans certaines documentations que le Z80 du CPC est cadencé à 4MHz, et dans d'autres qu'il est à 3,33 MHz ? Les deux fréquences sont correctes ! Tout dépend du point de vue : Le CPC possède un quartz à 16 MHz dont la fréquence est divisée par 4 avant d'arriver au Z80. On a donc bien quatre Mhz. Cependant la RAM du CPC est utilisée à la fois par le CPU et le processeur vidéo (il faut bien qu'il lise les octets pour les afficher à l'écran). Pour des raisons techniques, le Z80 et le CRTC6845 ne peuvent accéder à la mémoire en même temps. Il a donc fallu faire un arbitrage : On a préféré privilégier l'affichage, le CRTC a donc la priorité sur le Z80. Si on avait choisi de privilégier le CPU par rapport au processeur vidéo, on aurait eu des clignotements d'affichage ou des point noirs, du genre de ceux qui se produisent sur le TRS-80. Comme sur CPC c'est le CRTC qui a la priorité, il peut lire les données au moment où il en a besoin. Le Z80 sera obligé d'attendre que le 6845 lui laisse le champ libre. Ainsi, la fréquence de 3,33 MHz est une moyenne calculée à partir des ralentissements que subit le Z80 à cause du CRTC. Epilogue La vitesse des programmes sur CPC sont mesuré en NOP, et non pas en cycles comme c'est le cas sur d'autres machines. Un NOP dure une microseconde, ce qui correspond à la largeur d'un caractère au point de vue du CRTC. Il y a 64 NOPs par ligne, et 312.5 lignes. On a donc 20000 NOPs par frame, et un million par seconde. Selon MadRam (Alias le Dieu du CPC), seules certaines instructions sont ralenties par le 6845. Il est donc possible de faire des programmes tournant réellement à 4 MHz. Cet article a été rédigé par CSKi, d'après des indications de MadRam. ---- Sauf sur certains rares CPC (CRTC2?), pas de possibilité de faire du réel entrelacé, et donc le 312,5 est évidemment FAUX en mode standart, et IMPOSSIBLE sur la plupart des CPC même en bidouillant. Il n'y a que 312 lignes pile poil (un nombe entier), et pas 20000 NOPs par frame mais 64*312=19968 NOPs. Anecdote intéressante d'ailleurs, la fonction TIME et autre moyen de décompter les secondes sur Amstrad CPC est... erronée! ca tourne plus vite, à 0,155% près. M'enfin, tout cela est chipoter, car le quartz utilisé dans le CPC n'est pas très très précis... Un test simple à faire: deux LONGs programmes lancés en même temps sur 2 CPCs différents ont de grande chances de ne pas finir en même temps. Bon, tout ceci a été discuté en meeting avec Madram, il peut confirmer, tout est vrai. Et il me semble qu'il y a quelque chose à ce sujet sur la ML, non? Signé: anonyme, mais on me reconnaîtra, pas arf! --- Je sais plus trop les termes techniques, désolé (suffit de prendre une doc sur le Z80 et hop!) mais voilà en petit français pourquoi certaines instructions sont ralenties et d'autres pas. Au cours d'une instruction, il y a plusieurs phases (ou T-cycle?), en gros pour lire les octets de l'instruction, pour exécuter le code proprement dit, et pour stocker éventuellement le résultat de l'instruction (on dit, en vrac, à confirmer FETCH LOAD EXECUTE STORE???). Calculons... si 4 T-Cycles, arrondi à 4, + 0% En supposant que les instructions sont équitablement réparti sur ces 8 catégories (arbitraire!!!), çà fait déjà en moyenne 20% de temps en plus. Soit en inversant pas 4 Mhz mais au max 4/(100+20%)= 3,33 Mhz. Héhé, comment arriver avec plein d'approximation à qqch de proche à ce qui se dit. Y'a d'autres calculs de fait, cf ceux de FutureOS. Globiboulga. --- Tu as raison pour les 312 lignes. Cependant j'ai beau réfléchir aux explications de MadRam, je n'arrive toujours pas à comprendre POURQUOI c'est impossible de générer cette demi ligne supplémentaire. Avec quelques outs bien placés on peut générer un écran de 313 lignes, dont la dernière ne mesure que 32 NOPs au lieu de 64 ! On pourrait aussi générer un écran de 312 lignes, dont la dernière ferait 98 NOPs. Faudra que je teste ça à l'occasion. Sinon tes remarques sont très intéressantes. Je peux les ajouter à l'article ? --- (Je pense que tu seras déçu quand tu sauras qui je suis. Par avance désolé.) Ce que tu décris (par bidouille créer une 313ème ligne de 32 ms), c'est joli, ça peut marcher, qu'en penses Madram? Sans cette bidouille cependant, en hard donc, c'est par le registre 8 du CRTC qu'on est censé mettre en route l'entrelacé. Un test simple (c'est Yves qui me l'a fait de visu en meeting, merci à lui) c'est de comparer les débuts des 2 VBLs sur un même écran (reg4 (à confirmer) y'a vraiment de l'entrelacé que sur CRTC2, c'est à dire que les 2 (débuts des) VBLs sont décalées de 32ms (alors que sur CRTC "normal" les 2 VBLs commence à la même position horinzontale). Toujours de mémoire (c'est qu'il m'en a appris des choses Madram) cette feature (l'entrelacé) est en théorie une caractéristique "standart" du CRTC, ce qui permettrait de conclure que les CRTC0 ou 1 ou 3 ou 4 ne sont que de pâles imitations/copies/mal copiés, que seul le CRTC2 répond au cahier des charges d'un CRTC 6845 avec toutes ses fonctions dont l'entrelacé.:)
|
