Programmation du C-64: tutoriaux

Forum Commodore Commodore 64 / 128 / VIC 20 / … Programmation du C-64: tutoriaux

Ce sujet a 16 réponses, 3 participants et a été mis à jour par  PZAWA, il y a 1 semaine.

15 sujets de 1 à 15 (sur un total de 17)

Partager sur vos réseaux sociaux préférés :
Facebooktwittergoogle_plusredditpinterestlinkedintumblrmail

  • Auteur
    Messages
  • #3360

    PZAWA
    • 67 Messages

    Étant donné que j’ai quelques articles (à la base pour le site commodorecoverhd qui n’est plus actif) concernant la programmation du C-64 je me permet de vous les faire partager.

    http://pzawa.alwaysdata.net/Retro-Programmation/C64/



    #3385
    Staff
    Jim
    Jim
    • 1 068 Messages

    Excellent ! Merci pour ton partage  B-)

    My beast : A500 Plus - 2Mo de Chip - 128Mo Fast - 8Gb CF - 68080@78Mhz (Vampire V2+ inside)

    #3390

    PZAWA
    • 67 Messages

    Merci Jim pour ton commentaire :-)

    J’avoue avoir pas mal de brouillon d’articles comme ceux-la mais j’éprouve les pires difficulté à les finalisées. :wacko:

    #12224
    nounours
    nounours
    • 6 Messages

    Franchement Merci beaucoup !

    Je me suis remis à la programmation en assembleur sur C64, J’ai trouvé d’excellents sites où les routines de base ainsi que les astuces et les trucs de demomakers sont succintement expliqués, mais des articles de cette qualité (les tiens), Franchement pour moi c’est du jamais vu !

    Et on en sent que tu en as sous le pied ! Je me prends même à rêver qu’il pourrait y avoir une suite …. J’imagine que l’intérêt du public est forcément restreint (surtout si c’est en français), mais je peux te garantir que sur les forums dans la langue de shakespear, tes articles feraient sensation tant ils sont d’une rare qualité.

    Je me disais même qu’un livre avec ce type de contenu (et sa suite) ferait juste un tabac 20 ans en arrière  :lol:

    Ce serait tellement cool que tu puisses continuer :)

    PS : Je viens de ré-acheter deux C64, dont un que je vais probablement équiper de la nouvelle carte mère de Gideon : http://1541ultimate.net/content/index.php?option=com_content&view=article&id=74&catid=9

    Encore Merci !

    #12328

    PZAWA
    • 67 Messages

    Merci pour ton message. Je suis vraiment très content que cela puisse plaire :-) Et en plus, que cela te donne envie de (re)programmer … je suis aux anges :-)

    Et n’hésite pas à donner quelques retours ou critiques

    Pour ce qui est des suites, il est prévue tout une série qui sera justement publiée sur AmigaFrance. Cela prendra seulement un peu de temps: moi pour finalisé (surtout en ce moment :-( ) et Jim pour la mise-en page et publication.

    J’ai beaucoup de brouillons dans ce genre sur pas mal de sujets (mais principalement de la programmation “bas-niveau”) que j’aurais bien aimé avoir lorsque j’étais enfant et que je voulais apprendre à programmer et comprendre comment un micro fonctionne ;-)

     

     

    #13245
    nounours
    nounours
    • 6 Messages

    Salut !

    Avant que ton site ne soit à nouveau en construction j’ai pu accéder à ton article sur la programmation d’effets graphiques. J’ai passé beaucoup de temps (et appris beaucoup de choses) en exploitant ton code sur l’affichage et le déplacement d’une raster bar. J’en ai profité pour le modifier et rajouter un défilement des raster lines au sein de la raster bar : Quand la raster bar descend, les raster lines se déplacent vers le bas et inversement. Je suis dubitatif sur mon approche, mais celà fonctionne  :yahoo:

    (Capture à l’arrache donc ce n’est pas très fluide  :lol: )

    Je mettrai le code source après mes commentaires, mais j’ai en fait quelques question existentielles à te poser:

    – A quoi sert la désactivation du fond d’écran ? J’ai lu que chaque bit stoqué à l’adresse $D011 intervient dans le contrôle de plusieurs éléments du VIC. Dans le cas de ton code tu le met à 0, et à part l’ouverture des bords latéraux, j’avoue de pas comprendre pourquoi tu positionnes la valeur à 0 (Tous les bits sont donc passés à 0) . Quel est l’objectif visé par l’exécution de cette commande ?

    ldx #$00
    stx $D011

    – Je comprend parfaitement que cette façon de générer une raster bar repose sur la modification (contôlée) de la couleur de fond d’écran lorsque l’on se trouve sur une ligne précise, et je comprends que la ligne change de couleur du fait de la modification de la couleur du fond d’écran. Par contre, je ne comprends pas ce qui intervient pour éviter que plus d’une ligne consécutive ne soit affichée avec la couleur modifiée. Une seule ligne exactement est affichée avec la couleur sélectionnée. Est-ce que celà signifie que le code est suffisamment rapide pour aller aussi vite que le déplacement du raster beam ? J’ai comme un doute car je sais bien que le changement de couleur du fond d’écran est quelque chose d’instantané et s’applique à l’ensemble des lignes en une fraction de seconde, donc qu’est-ce qui permet dans le code de n’avoir qu’une seule ligne affichée avec la couleur modifiée ?

    Il y a un truc mais je ne saisis pas  :unsure:
    EDIT :
    =================================================
    Possible que ce soit cette portion dans la boucle qui repositionne le fond d’écran en noir,
    //
    begin:
    ldy #$40
    ldx #$00
    stx $D020
    //
    En effet, c’est exécuté indépendamment de la position de la raster line. Le changement de couleur étant dicté par la position de la raster line, il est tout à fait possible que l’effet produit résulte d’un effet d’optique (Noir quelque que soit la raster line, Autre couleur spécifique à une position de raster line).
    =================================================

    En lien direct, J’ai noté plusieurs choses :

    1) La dernier couleur de la raster bar est $00 (donc noir) et en expérimentant je me suis rendu compte que celà permettait (avec un fond noir) de stabiliser l’affichage de la raster bar. Si la dernière couleur n’est pas noir (comme le fond d’écran) on observe un artefact à la fin de la raster bar. Est-ce que tu confirmes ?

    2) Je me demande également comment il est possible d’accélérer le déplacement de la raster bar avec cette technique d’affichage/d’animation. Je ne vois pas comment le code pourrait être plus rapide. Est-ce que la vitesse de déplacement est intrinsèquement liée à la méthode d’affichage/animation de la raster bar ?

    Si tu peux éclaircir tous ces points je t’en serai fort reconnaissant !

    – Passons aux modifications que j’ai effectuées. Je ne suis pas certain que le code copié/collé soit bien lisible posté sous cette forme. J’ai uniquement commenté ce que j’ai rajouté pour introduire le déplacement des raster lines au sein de la raster bar. En gros, je déplace une fenêtre de 32 lignes au sein de 64 lignes de données (j’ai dupliqué les données de la raster bar, mais remplacé la dernière couleur noir). Je détecte si on est en phase de déplacement vers le bas ou vers le haut et en fonction j’incrémente ou décrémente la position de départ de la fenêtre (que je stocke à une adresse mémoire spécifique). La position de la fenêtre (stoquée dans une adresse spécifique) est ensuite stoquée à l’emplacement de la valeur avec laquelle X est comparé. La valeur 31 n’est donc pas fixe mais évolue pendant l’exécution du code.

    Si tu vois une meilleure solution pour produire cet effet je suis preneur.

    Tu noteras que du fait de la non utilisation de la couleur noir, j’ai un artefact à la fin de la raster bar … je pense que c’est facilement contournable mais je n’ai pas eu le temps.

     

    :BasicUpstart2(main)

    .pc = 2500
    main:
    ldx $D011
    stx savevic
    ldx $D020
    stx savevic+1
    sei
    ldx #$00
    stx $D011
    stx rast_bar_wind_pos // initialise la position de la fenêtre à 0
    begin:
    ldy #$40
    ldx #$00
    stx $D020
    lda move // On récupère la direction du déplacement stoquées à l’adress “move”
    cmp #$EE // On vérifie si le déplacement se fait vers le bas
    beq mov_up_rast_bar_wind_pos // Si oui alors on déplace la fenêtre vers le Haut
    mov_down_rast_bar_wind_pos: // Sinon on déplace la fenêtre vers le bas
    lda rast_bar_wind_pos // On charge la position courante de la fenêtre
    cmp #32 // la position courante de la fenêtre est-elle à mi-chemin de la fin
    // des données de la double raster bar
    beq rst_rast_bar_wind_pos1 // Si oui alors il faut positionner la fenêtre au début des données
    // de la double raster bar
    inc rast_bar_wind_pos // Sinon alors on déplace la fenêtre vers le bas
    jmp pos
    rst_rast_bar_wind_pos1:
    lda #$00 // repositionne la fenêtre au début de la zone de données
    // de la double raster bar
    sta rast_bar_wind_pos
    jmp pos
    mov_up_rast_bar_wind_pos:
    lda rast_bar_wind_pos // On charge la position courante de la fenêtre
    cmp #$00 // la position courante de la fenêtre est-elle
    // au début des données de la double raster bar
    beq rst_rast_bar_wind_pos2 // Si oui alors il faut positionner la fenêtre au milieu de
    // la zone de données de la double raster bar
    dec rast_bar_wind_pos // Sinon alors on déplace la fenêtre vers le haut
    jmp pos
    rst_rast_bar_wind_pos2:
    lda #32 // repositionne la fenêtre au milieu de la zone de données
    // de la double raster bar
    sta rast_bar_wind_pos
    pos:
    lda rast_bar_wind_pos // on charge la position de la fenêtre
    adc #31 // on ajoute 31
    sta compare+1 // on stoque la valeur obtenue (modification dynamique) en lieu et place
    // de la valeur #31 dans l’instruction “cpx #31”
    // ceci permet une double indexation
    // On aura toujours 32 lignes à dessiner.
    ldx rast_bar_wind_pos
    loop:

    lda raster_bar_data,x
    chk_raster_pos:
    cpy $D012
    bne chk_raster_pos
    sta $D020
    compare:
    cpx #31
    beq chk_stop_raster_bar
    inx
    iny
    jmp loop
    chk_stop_raster_bar:
    lda $DC01
    cmp #$FF
    bne end
    move:
    inc begin+1
    lda begin+1
    cmp #$D0
    bcs move_up
    cmp #$3F
    bcc move_down
    jmp begin
    move_up:
    lda #$CE
    sta move
    jmp begin
    move_down:
    lda #$EE
    sta move
    jmp begin
    end:
    cli
    brk
    raster_bar_data:
    .byte $06,$0E,$06,$0E,$06,$0E,$06,$0E
    .byte $03,$0E,$03,$0E,$03,$01,$03,$01
    .byte $03,$01,$03,$01,$03,$0E,$03,$0E
    .byte $06,$0E,$06,$0E,$06,$0E,$06,$0E
    .byte $06,$0E,$06,$0E,$06,$0E,$06,$0E // Données de la raster base
    .byte $03,$0E,$03,$0E,$03,$01,$03,$01 // répétées pour disposer d’une
    .byte $03,$01,$03,$01,$03,$0E,$03,$0E // fenêtre “glissante” de 32 lignes
    .byte $06,$0E,$06,$0E,$06,$0E,$06,$0E // dont la position se déplace entre la première valeur et la 32ème valeur
    savevic:
    .byte $00,$00
    rast_bar_wind_pos: // Position de la fenêtre “glissante” de 32 lignes
    .byte $00

    #13256
    Staff
    Jim
    Jim
    • 1 068 Messages

    Jolie boulot nounours on va voir ce qu’en dit maitre Pzawa.  :good:

    My beast : A500 Plus - 2Mo de Chip - 128Mo Fast - 8Gb CF - 68080@78Mhz (Vampire V2+ inside)

    #13275
    nounours
    nounours
    • 6 Messages

    Merci Jim !
    Merci avant tout pour ce site francophone et pour continuer à faire vivre l’esprit de ces machines d’exception. Je redécouvre le C64 pour une raison assez simple : Je bosse dans l’informatique, et j’éprouve un frustration récurrente à bosser sur du “quick and dirty”. En retournant sur une machine 8 bits véritablement non tolérante à l’à peu près, je retrouve non seulement le plaisir des choses bien faites (ou qui ne fonctionnent pas tout court) mais surtout je peux enfin accéder à des ressources qui m’étaient inaccessibles lorsque j’avais 12 ans. J’ai commencé la programmation à 8 ans sur un ti994A avec le basic, et 4 ans plus tards, j’ai eu un c64 avec lequel j’ai commencé l’apprentissage de l’assembleur (en écrivant mes opcodes sur du papier pour ensuite les retranscrire en poke :D).
    J’attend le retour du maître, qui je l’espère aura le temps un jour d’aborder d’autres sujets. Son sens de la didactique est tout bonnement impressionnant ! Rarement vu une explication aussi claire du self modifying code, et l’approche proposée est vraiment sympa car elle permet de rapidement voir le résultat du code écrit.

    #13339
    Staff
    Jim
    Jim
    • 1 068 Messages

    Je te comprend ! Quick and Dirty est le thème approprié je crois :yes:

    Le maitre est en méditation pour la suite  :lol:

    My beast : A500 Plus - 2Mo de Chip - 128Mo Fast - 8Gb CF - 68080@78Mhz (Vampire V2+ inside)

    #13361

    PZAWA
    • 67 Messages

    Excellent Nounours ! :good: Avec ton approche, je n’aurai pas fait mieux :good:

    réponse très rapide (car au boulot.. ): toujours terminer le raster par la couleur de fond (ici le noir) sinon ca va scintiller en bas car la mise en couleur de fond n’est pas synchro (c’est la faute de mon code d’origine ;-) ) c’est pourquoi j’écrivais “toujours terminer par la couleur noir” mais cela méritera plus de précision dans l’article final.

    Quick fix:

    chk_stop_raster_bar:
    ;FIX START
    iny
    lda #$00
    FIX_LP1:
    cpy $d012
    bne FIX_LP1
    sta $d020
    ;FIX END
    lda $DC01
    cmp #$FF
    bne end

    réponse plus développée ce soir (si mes bestioles me le permettent :lol: ) …



    #13419

    PZAWA
    • 67 Messages

    Salut Nounours :-)

    Encore un fois tout mes félicitations pour ton code :good:

    J’ai exactement les même motivations que toi en ce qui concerne la programmation du C-64  :-)   et tes compliment me vont droit au coeur :-)

    Mais sinon attention, je suis loin d’être un Gourou en la matière :lol:   (j’ai par exemple jamais rien produit officiellement et je pense qu’une personne comme Majikeyric est sans doute plus compétent que moi) et je continue d’apprendre. Seulement lorsque j’écris un tuto, j’utilise toujours l’approche “rappel toi de ce que tu savais et ne savais pas lorsque tu as compris ce point et réexplique”.

    Je vais tenter de répondre à tes questions.

    Il y a un truc mais je ne saisis pas
    EDIT :
    =================================================
    Possible que ce soit cette portion dans la boucle qui repositionne le fond d’écran en noir,
    //
    begin:
    ldy #$40
    ldx #$00
    stx $D020
    //
    En effet, c’est exécuté indépendamment de la position de la raster line. Le changement de couleur étant dicté par la position de la raster line, il est tout à fait possible que l’effet produit résulte d’un effet d’optique (Noir quelque que soit la raster line, Autre couleur spécifique à une position de raster line).
    =================================================

    En fait ici c’est le code ldx 0;stx $d020 qui est superflu et qui induit en erreur et en bug: tu peux le supprimer sans problème.  Pour n’avoir aucun artefact de ligne il faut systématiquement changer la couleur de fond juste après la synchro cpy $d012;bne *-5. C’est la dernier couleur charger dans $d020 qui définira la couleur de fonds (puisque celle ci sera afficher au prochain démarrage du ‘raster’). Et si on s’arrange pour que la prochaine ligne du raster soit la couleur de fond on aura un truc stable.

    – A quoi sert la désactivation du fond d’écran ? J’ai lu que chaque bit stoqué à l’adresse $D011 intervient dans le contrôle de plusieurs éléments du VIC. Dans le cas de ton code tu le met à 0, et à part l’ouverture des bords latéraux, j’avoue de pas comprendre pourquoi tu positionnes la valeur à 0 (Tous les bits sont donc passés à 0) . Quel est l’objectif visé par l’exécution de cette commande ?

    ldx #$00
    stx $D011

    En fait le seul bit que nous voulons mettre a zero c’est le bit 4.  Comme tu le dis lorsque le bit est désactiver quasiment tout le VIC est hors fonction: il ne peut afficher ni de sprite, ni de bitmap.. enfin rien mis a par la couleur de fond. Une fois le bit 4 a 0 les autres n’ont plus d’importance c’est pourquoi il est plus simple d’écrire 0 directement.

    En mettant le VIC HS, la synchronisation est plus facile car le processeur possède, sur chaque ligne vertical, 63 cycles disponible.Il faut juste respecter le code de synchro (cpy $d012;bne *-5) pour n’avoir aucun problème. Pour ce qui est de la vitesse d’execution, un truc marrant a faire est d’alterner juste apres une synchor u

    Mais le problème c’est que lorsqu’on met ce bit a 0 on ne peut “reactiver” le VIC en plein milieu de l’écran :negative: Il faut attendre le prochain retour vertical pour que l’écriture sur le bit 4 prenne effet… Voila pourquoi on se trouve très vite limité avec ce mode.

    Les rasters avec un VIC actif est autrement plus difficile et fait partie de la fameuse quête des “raster stables” qu’ont mené les demomakers. B-)

    Sinon je prévois (en tout cas si Jim est d’accord ;-) ) plutôt que mes tutos soient hébergées par Amiga-france et pas vraiment sur mon site qui est plus un buffer.

    :bye:

    #13422
    Staff
    Jim
    Jim
    • 1 068 Messages

    Sinon je prévois (en tout cas si Jim est d’accord ;-) ) plutôt que mes tutos soient hébergées par Amiga-france et pas vraiment sur mon site qui est plus un buffer. :bye:

    J’aurais du mal à ne pas être d’accord !  :lol:

    Je suis en retard sur la mise en page. Le retard que j’ai pris avec mon absence du mois de septembre m’a mis complètement dans le jus.  :scratch:

    Sinon je pense que ton humilité te perdra un jour  :-p

    My beast : A500 Plus - 2Mo de Chip - 128Mo Fast - 8Gb CF - 68080@78Mhz (Vampire V2+ inside)

    #13511
    nounours
    nounours
    • 6 Messages

    Excellent Nounours ! :good: Avec ton approche, je n’aurai pas fait mieux :good:

    réponse très rapide (car au boulot.. ): toujours terminer le raster par la couleur de fond (ici le noir) sinon ca va scintiller en bas car la mise en couleur de fond n’est pas synchro (c’est la faute de mon code d’origine ;-) ) c’est pourquoi j’écrivais “toujours terminer par la couleur noir” mais cela méritera plus de précision dans l’article final.

    Quick fix:

    chk_stop_raster_bar:
    ;FIX START
    iny
    lda #$00
    FIX_LP1:
    cpy $d012
    bne FIX_LP1
    sta $d020
    ;FIX END
    lda $DC01
    cmp #$FF
    bne end

    réponse plus développée ce soir (si mes bestioles me le permettent :lol: ) …

    Merci beaucoup pour le quick fix, je vais tâcher de le tester ce week-end. Désolé pour le retour tardif, mais j’ai un boulot très prenant (dans l’IT…. on ne se refait pas), et j’avoue que je n’ai plus beaucoup d’énergie pour me mettre le soir derrière un écran tant mon ciboulot a fumé dans la journée … A 46 balais ce n’est pas toujours évident :) quelques questions supplémentaires dans ta réponse plus longue ;)

    #13512
    nounours
    nounours
    • 6 Messages

    Salut Nounours :-)

    Encore un fois tout mes félicitations pour ton code :good:

    J’ai exactement les même motivations que toi en ce qui concerne la programmation du C-64 :-) et tes compliment me vont droit au coeur :-)

    Mais sinon attention, je suis loin d’être un Gourou en la matière :lol: (j’ai par exemple jamais rien produit officiellement et je pense qu’une personne comme Majikeyric est sans doute plus compétent que moi) et je continue d’apprendre. Seulement lorsque j’écris un tuto, j’utilise toujours l’approche “rappel toi de ce que tu savais et ne savais pas lorsque tu as compris ce point et réexplique”.

    Je vais tenter de répondre à tes questions.

    Il y a un truc mais je ne saisis pas
    EDIT :
    =================================================
    Possible que ce soit cette portion dans la boucle qui repositionne le fond d’écran en noir,
    //
    begin:
    ldy #$40
    ldx #$00
    stx $D020
    //
    En effet, c’est exécuté indépendamment de la position de la raster line. Le changement de couleur étant dicté par la position de la raster line, il est tout à fait possible que l’effet produit résulte d’un effet d’optique (Noir quelque que soit la raster line, Autre couleur spécifique à une position de raster line).
    =================================================

    En fait ici c’est le code ldx 0;stx $d020 qui est superflu et qui induit en erreur et en bug: tu peux le supprimer sans problème. Pour n’avoir aucun artefact de ligne il faut systématiquement changer la couleur de fond juste après la synchro cpy $d012;bne *-5. C’est la dernier couleur charger dans $d020 qui définira la couleur de fonds (puisque celle ci sera afficher au prochain démarrage du ‘raster’). Et si on s’arrange pour que la prochaine ligne du raster soit la couleur de fond on aura un truc stable.

    – A quoi sert la désactivation du fond d’écran ? J’ai lu que chaque bit stoqué à l’adresse $D011 intervient dans le contrôle de plusieurs éléments du VIC. Dans le cas de ton code tu le met à 0, et à part l’ouverture des bords latéraux, j’avoue de pas comprendre pourquoi tu positionnes la valeur à 0 (Tous les bits sont donc passés à 0) . Quel est l’objectif visé par l’exécution de cette commande ?

    ldx #$00
    stx $D011

    En fait le seul bit que nous voulons mettre a zero c’est le bit 4. Comme tu le dis lorsque le bit est désactiver quasiment tout le VIC est hors fonction: il ne peut afficher ni de sprite, ni de bitmap.. enfin rien mis a par la couleur de fond. Une fois le bit 4 a 0 les autres n’ont plus d’importance c’est pourquoi il est plus simple d’écrire 0 directement.

    En mettant le VIC HS, la synchronisation est plus facile car le processeur possède, sur chaque ligne vertical, 63 cycles disponible.Il faut juste respecter le code de synchro (cpy $d012;bne *-5) pour n’avoir aucun problème. Pour ce qui est de la vitesse d’execution, un truc marrant a faire est d’alterner juste apres une synchor u

    Mais le problème c’est que lorsqu’on met ce bit a 0 on ne peut “reactiver” le VIC en plein milieu de l’écran :negative: Il faut attendre le prochain retour vertical pour que l’écriture sur le bit 4 prenne effet… Voila pourquoi on se trouve très vite limité avec ce mode.

    Les rasters avec un VIC actif est autrement plus difficile et fait partie de la fameuse quête des “raster stables” qu’ont mené les demomakers. B-)

    Sinon je prévois (en tout cas si Jim est d’accord ;-) ) plutôt que mes tutos soient hébergées par Amiga-france et pas vraiment sur mon site qui est plus un buffer.

    :bye:

    Effectivement, si la dernière ligne de la raster bar est noire alors “ldx 0;stx $d020” est superflu. Mais je l’ai laissée car ayant souhaité faire défiler les raster lines, j’étais obligé de ne pas avoir de ligne noire. et du coup en l’absence de ligne noire, si “ldx 0;stx $d020” n’est pas présente alors le comportement est aléatoire : le fond d’écran peut changer de couleur sans prévenir. Mais je vais tester ton fix qui doit permettre de résoudre les deux problèmes.

    Par contre une chose que je ne comprends toujours pas:
    1) est on d’accord que le changement de couleur dans $d020 a pour conséquence de changer la couleur de fond d’écran ? Oui à priori.
    2) Du coup, même si on attend d’être sur une raster line particulière pour changer la couleur, comment expliquer que la couleur du fond d’écran ne change pas dans sa globalité, mais seulement sur la ligne pour laquelle on a attendu ? Car à moins que le code soit d’une rapidité exceptionnelle, il n’est pas aussi rapide que le balayage de l’écran, donc du coup je suppose que l’écran est balayé plusieurs fois avant l’exécution de la prochaine commande de comparaison de la raster line. Et par conséquent, le fond d’écran devrait être re-dessiné avec la même couleur non ? C’est çà que je ne comprends pas. Si tu as une explication elle est la bienvenue.

    Ce que je veux dire c’est çà : J’attend d’être sur la ligne l => quand j’y suis je modifie la couleur du fond d’écran. Ok, mais cette couleur n’est elle pas supposée s’appliquer aux lignes suivantes si l’écran est balayé plusieurs fois ?
    On est sur la ligne l => on change la couleur => le balayage dessine avec la nouvelle couleur, et à moins que mon code boucle à une vitesse exceptionnelle, le balayage a largement eu le temps de parcourir le reste de l’écran pour revenir au début de celui-ci, et ce sans doute plusieurs fois avec la même couleur que celle positionnée par la dernière instruction stx $d020. Donc pourquoi ne le voit-on pas. Est-ce simplement lié au fait que les changements étant effectués avec une forme de timing régulier, on finit par obtenir une raster bar correcte ?

    Mon questionnement doit paraître saugrenu, mais j’essaie vainement de comprendre comment la raster bar peut être dessinée par un simple changement de couleur d’écran lorsqu’on se trouve sur une ligne spécifique, tout en sachant que lorsque le balayage de l’écran se produit, si je ne m’abuse, il est dessiné de manière régulière avec la couleur de fond d’écran qui a été positionnée ….

    Bref, prochaines étapes : Me pencher sur les raster interrupts car j’ai vu qu’on pouvait non seulement contrôler de manière très précise l’affichage en évitant les problèmes de timing mais que celà ouvre la possibilité d’enchaîner plusieurs effets, ce qui n’est pas possible avec l’approche utilisée ici. Je sens que je n’ai pas fini de fumer de la tête :)

    Si je peux aider à l’enrichissement de cette section ce sera avec plaisir, mais seulement sur le temps du week-end car à l’instant présent, j’écris avec les yeux à demi clos :D

    A très bientôt et Merci pour vos encouragements et votre sympathie !
    N.

    #13590

    PZAWA
    • 67 Messages

    Salut Nounours :-)

    Par contre une chose que je ne comprends toujours pas:
    1) est on d’accord que le changement de couleur dans $d020 a pour conséquence de changer la couleur de fond d’écran ? Oui à priori.
    2) Du coup, même si on attend d’être sur une raster line particulière pour changer la couleur, comment expliquer que la couleur du fond d’écran ne change pas dans sa globalité, mais seulement sur la ligne pour laquelle on a attendu ? Car à moins que le code soit d’une rapidité exceptionnelle, il n’est pas aussi rapide que le balayage de l’écran, donc du coup je suppose que l’écran est balayé plusieurs fois avant l’exécution de la prochaine commande de comparaison de la raster line. Et par conséquent, le fond d’écran devrait être re-dessiné avec la même couleur non ? C’est çà que je ne comprends pas. Si tu as une explication elle est la bienvenue.

    Ce que je veux dire c’est çà : J’attend d’être sur la ligne l => quand j’y suis je modifie la couleur du fond d’écran. Ok, mais cette couleur n’est elle pas supposée s’appliquer aux lignes suivantes si l’écran est balayé plusieurs fois ?
    On est sur la ligne l => on change la couleur => le balayage dessine avec la nouvelle couleur, et à moins que mon code boucle à une vitesse exceptionnelle, le balayage a largement eu le temps de parcourir le reste de l’écran pour revenir au début de celui-ci, et ce sans doute plusieurs fois avec la même couleur que celle positionnée par la dernière instruction stx $d020. Donc pourquoi ne le voit-on pas. Est-ce simplement lié au fait que les changements étant effectués avec une forme de timing régulier, on finit par obtenir une raster bar correcte ?

    Attention, quand le VIC est HS, le processeur possèdent 63 cycles par lignes horizontal de balayage. Tu vois bien qu’il suffisamment rapide pour modifier plusieurs fois la couleur au sein d’une même ligne. La boucle du programme s’exécute toujours sur la ligne où démarre le raster. Le programme suit l’état horizontal du balayage pour changer la couleur de fond !

    Pour aller plus en détail le registre $D012 qui est un registre du VIC indique la valeur sur 8 bits de la position horizontal du balayage de l’écran. Il peut le faire car c’est lui qui génère le signal vidéo (Je sais bien sur PC et le standard VGA c’est un truc qui n’existe pas la seul info qu’on avait c’est le retour vertical).

    Essaye le petit bout suivant:

    ;SUPPOSE VIC-HS EST INTERRUPTION DESACTIVE
    MAIN:
      LDA #$01 ; COULEUR BLANCHE
      LDY #$44 ; NOTRE RASTERBAR DEMMARRE EN LIGNE 68
    RAS1:
      CPY $D012
      BNE RAS1
      STA $D020
     RAS2:
      CPY $D012
      BNE RAS2
      STX $D020 ; NOIR SI OMIS TOUT L’ECRAN SERA BLANC
      BNE MAIN ; JMP MAIN
      BRK

    Le programme dessine bien une ligne blanche. Maintenant pour te convaincre que le processeur est suffisamment rapide pour modifier la couleur au sein d’une ligne modifie comme ceci:

    RAS1:
      CPY $D012
      BNE RAS1
      STA $D020 ;BLANC
      NOP : NOP : NOP :NOP ;8 cycles d’attente
    STY $D020 ; VIOLET CAR Y=#$44
    NOP:NOP:NOP:NOP ;8cycles d’attente
    STA $D020 ; BLANC
    RAS2:
    CPY $D012
    BEQ RAS2

    etc.

    Le problème est que notre violet n’est jamais dessiner au même moment. Je n’ai pas le courage d’expliquer ce problème de “non-synchronisation horizontal” et comment le résoudre grâce au interruption (car c’est pas évident du tout). L’essentiel est que tu comprennent bien que le processeur est suffisamment rapide pour suivre l’état horizontal de l’écran et modifier le registre $D020 à la volée (ce qui crée justement ces rasters).

    Sinon j’ai le même problème que toi concernant le boulot, (surtout en ce moment d’ailleurs me demande si je ne devrais pas le faire partager dans la section “les pires bourdes info” car dans le domaine de la conneries j’ai rarement vu un truc comme ça) et je ne peut me consacrer à mes hobbies comme je le voudrais, même le weekend :cry:

    @jim: Merci ;-)   moi c’est la partie 2-2 qui n’avance pas  :-p

    :bye:

     

Partager sur vos réseaux sociaux préférés :
Facebooktwittergoogle_plusredditpinterestlinkedintumblrmail
15 sujets de 1 à 15 (sur un total de 17)

Vous devez être connecté pour répondre à ce sujet.