quelques questions sur le timing

elpapy

Hello !

Repri la bricole sur CPC, et j'ai quelques points qui me questionnent.

D'abord les timings sur z80. J'utilise rasm et TICKER pour calculer les synchros, ça marche très bien. Mais j'ai constaté que les cycles indiqués dans le "Z80 User Manual" de Zilog (édition 2016, http://z80.info/zip/z80cpu_um.pdf) n'étaient pas bon. Idem avec "The Undocumented Z80 Documented" de Sean Young (http://www.z80.info/zip/z80-documented.pdf). Par exemple, il est indiqué qu'un out (c),c prend 3 cycles machines, alors qu'il en prend en réalité 4 sur un CPC.

Le z80 est régulièrement interrompu par le Gate Array (READY connecté à la broche WAIT*) pour les accès en RAM du CRTC. J'ai lu dans "La bible du programmeur de l'Amstrad CPC" que c'était tous les 4 cycles d'horloge. Les instructions sont donc a priori interrompues en cours d'exécution. En principe cela n'altère pas le nombre de cycles M ou T, simplement la durée de certains cycles... du coup je ne vois pas bien d'où vient la différence entre les documents et ce qu'on constate sur CPC. Quelqu'un connaît la raison de cette spécificité ?

Autre chose, si on utilise habituellement l'équivalent nop (ce qui marche très bien), j'ai testé à des fins de compréhension des synchros avec les cycles d'horloge. Idem, les calculs ne sont pas justes. Si on ne peut pas se fier au document de Zilog pour les cycles M et T sur l'Amstrad, aurait-on dans un coin les cycles spécifiques au CPC ?

Dernière question, j'ai constaté que le premier halt après ei (dans une boucle qui interdit les interruptions) se produit plus tôt (presque immédiatement dans mon test) que le même halt dans une boucle où les interruptions sont autorisées. Je n'ai pas le souvenir que les INT soient mises en file sur z80...

Merci pour vos éclairages !

marcel · **Inscription :** 26 Juil 2016, 13:06 **Message(s) :** 485

le Z80 a bien un flag "pending" quand tu coupes les interruptions

si tu coupes les INT et qu'une se déclenche, tu la récupères APRES l'instruction qui SUIT le EI

cela permet, avec EI:RET, de revenir où tu étais et d'être sûr de ne jamais empiler à l'infini

si deux interruptions passent quand tu es en EI, tu n'en auras qu'une en sortie

elpapy

marcel a écrit :

le Z80 a bien un flag "pending" quand tu coupes les interruptions

si tu coupes les INT et qu'une se déclenche, tu la récupères APRES l'instruction qui SUIT le EI

cela permet, avec EI:RET, de revenir où tu étais et d'être sûr de ne jamais empiler à l'infini

si deux interruptions passent quand tu es en EI, tu n'en auras qu'une en sortie

Ok, je vois le truc.
Pourtant dans mon code de test, j'ai un résultat différent :

Code :

di
...
ei:halt  ; une INT est récupérée immédiatement
halt:di  ; une 2nde INT est attendue

Et :

Code :

di
...
ei:nop   ; aucune INT n'est récupérée
halt:di  ; la 2nde INT est attendue

... comme si l'interruption empilée était récupérée juste après le ei, avec un signal de courte durée (<= 4 cycles d'horloge) :-|

marcel · **Inscription :** 26 Juil 2016, 13:06 **Message(s) :** 485

Relis bien ce que j'ai écrit et mis en majuscule

Il n'y aura jamais d'interruption sur le NOP de EI:NOP:HALT

si tu coupes les INT et qu'une se déclenche, tu la récupères APRES l'instruction qui SUIT le EI => Le nop SUIT le ei et l'int arrivera APRES

elpapy

Je vois bien ce que tu veux dire et je comprends bien que ce soit une sécurité pour le ei:ret des routines d'interruption. Je récupère bien une interruption sur ei:halt, celle précédemment levée mais interdite pendant le code en amont (je la récupère très vite après ei). Ça s'explique sûrement par le fait que halt fait des nop et que le cycle d'instruction supplémentaire nécessaire est joué.

Mais dans le second cas, je n'ai pas l'impression que ce soit l'INT levée pendant le code en amont que je récupère sur le halt en deuxième ligne, mais une nouvelle (il y a une attente visible et classique de la position des halt, ce n'est pas immédiat). Il n'y a que dans le 1er cas que je la récupère, d'où ma perplexité...

Mes confuses si je suis pas clair, il y a peut-être aussi un artefact dans mon code de test qui crée la confusion.

marcel · **Inscription :** 26 Juil 2016, 13:06 **Message(s) :** 485

ok

ben j'comprends pas ta surprise

dans un cas tu fais 1 HALT, dans l'autre tu fais 2 HALT, il semble évident que tu vas attendre 1 INT dans un cas et 2 INT dans l'autre, rien n'est anormal

il faudrait qu'on en sache un peu plus sur le code qui est avant, est-il en temps fixe, es-tu sur un cas limite, etc?

elpapy

marcel a écrit :

ok

ben j'comprends pas ta surprise

dans un cas tu fais 1 HALT, dans l'autre tu fais 2 HALT, il semble évident que tu vas attendre 1 INT dans un cas et 2 INT dans l'autre, rien n'est anormal

Je m'attendais à ce que l'INT empilée soit récupérée dans les deux cas. À ce que je comprends ei:halt et ei:nop:halt devrait récupérer cette INT, c'est-à-dire qu'on devrait voir dans les deux cas un halt très court, quasi immédiat.

marcel a écrit :

il faudrait qu'on en sache un peu plus sur le code qui est avant, est-il en temps fixe, es-tu sur un cas limite, etc?

C'est en temps constant, pas grand chose, une attente de VBL, une attente supplémentaire durant laquelle des INT arrivent normalement mais sont interdites, et le test avec des encres pour voir ce qui se passe. Je pose le code dès que j'ai un petit moment...

marcel · **Inscription :** 26 Juil 2016, 13:06 **Message(s) :** 485

elchoco a écrit :

Je m'attendais à ce que l'INT empilée soit récupérée dans les deux cas. À ce que je comprends ei:halt et ei:nop:halt devrait récupérer cette INT, c'est-à-dire qu'on devrait voir dans les deux cas un halt très court, quasi immédiat.

Oui, que tu mettes un NOP ou non, le premier HALT récupère la première INT à récupérer

Si tu mets deux nop, l'INT passe sous le nez du HALT et il attendra la suivante

elpapy

marcel a écrit :

Oui, que tu mettes un NOP ou non, le premier HALT récupère la première INT à récupérer

Si tu mets deux nop, l'INT passe sous le nez du HALT et il attendra la suivante

Oui, c'est ce que je comprends aussi... mais dans le code le ei:nop:halt zappe la INT empilée, et attends la suivante direct...
Le code coupable (bon t'es pas obligé de t'embêter non plus !) :

Code :

TEST1   EQU 1

macro GA_INKR_SET couleur
        ; 7M
        ld bc,#7f00+64+{couleur}
        out (c),c
mend
macro WAIT_NLINE n,m
        push bc
        ld b,{n}-1
        push bc
        ld b,13:djnz $
        pop bc
        djnz $-6 ; 64 per loop
        pop bc
        defs 64-8-{m},0
mend

        org #2000

start
        di
        im 1
        ld hl,#c9fb
        ld (#0038),hl
        ld bc,#7f00+128+%1101   ; mode 1
        out (c),c
        ld bc,#7f00             ; PENR ink 0
        out (c),c
;===========================================================
; main
;
main
        ld b,#f5
.wvbl
        in a,(c)
        rra
        jr nc,.wvbl
        ei:halt:di
        defs 40,0               ; align
        WAIT_NLINE 130,0
        GA_INKR_SET 10          ; jaune

IFDEF TEST1
        ei:nop:halt:di
        GA_INKR_SET 0           ; gris

        ei:halt:di
        GA_INKR_SET 10          ; jaune

        ei:halt:di
ELSE
        ei:halt:di              ; halt immédiat (INT empilée)
        GA_INKR_SET 0           ; gris

        ei:halt:di
        GA_INKR_SET 10          ; jaune

        ei:halt:di
        GA_INKR_SET 0           ; gris

        ei:halt:di
ENDIF
        GA_INKR_SET 11          ; blanc
        jp main

end
run start
save './_build/tstint.bin',start,end-start,DSK,'./_build/tstint.dsk'

marcel · **Inscription :** 26 Juil 2016, 13:06 **Message(s) :** 485

Heu, j'ai dit une connerie à propos du NOP ou non, c'est bien la règle énoncée précédemment qui s'applique!

EI:NOP <INT> puis le HALT attend une nouvelle INT

L'int est après l'instruction qui suit le NOP, mais avant l'instruction qui suit le NOP

elpapy

Ok... j'en sais un peu plus. Merci pour ton temps

quelques questions sur le timing

Qui est en ligne ?