Programmation du C-64: tutoriaux

Excellent ! Merci pour ton partage 

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 

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 !

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 

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

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 
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

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.

PZAWA wrote:

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.

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

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. 

Sinon je pense que ton humilité te perdra un jour 

PZAWA wrote:

Salut Nounours

Encore un fois tout mes félicitations pour ton code

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 (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 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.

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.

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.

PZAWA wrote:

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 @jim: Merci moi c’est la partie 2-2 qui n’avance pas

Merci beaucoup PZAWA !!!!!

Tout devient vraiment plus beaucoup plus clair !

Je teste tout çà aujourd’hui, je m’astreint à ne pas rester plus de 6 jours sans toucher au coding sur c64, car j’ai bien l’intention de maîtriser la programmation graphique (dans un premier temps) puis musicale (sans un second temps). J’ai été trop frustré dans mon enfance de ne pas savoir où trouver la connaissance nécessaire. Là j’ai pas mal de ressources, tes tutoriaux ayant à mes yeux une qualité essentielle, celle d’initier rapidement par l’exemple, sans noyer dans les détails. Je pense sincèrement me mettre à faire des tutos également lorsque j’aurai maîtrisé l’utilisation des interruptions.

Du coup pour en revenir aux rasters, je me pose une question tout bête : Comment accélérer le déplacement de la raster bar ?

Il y a pour moi comme une forme de contradiction, mais je n’ai sans doute pas encore saisi toutes les subtilités du code : La raster bar s’affiche instantanément. Du coup, je ne comprends pas pourquoi le déplacement n’est pas plus rapide  . On n’introduit pourtant aucune temporisation, et j’ai vue des démos où les rasters bar s’animent beaucoup plus rapidement. J’ai testé un incrément de +2 pour le déplacement et si effectivement cela accélère le déplacement, ce n’est pas ce qui est le plus satisfaisant d’un point de vue fluidité. Aurais-tu une idée ?

Bref, je sens qu’il va me falloir de la patience, mais je suis aussi aidé par un demo maker à temps partiel  qui connaît déjà bien la programmation des effets graphiques. Par contre, ce qui n’aide pas c’est qu’il habite à tel aviv  (rencontré sur des groupes Facebook dédiés à la programmation sur c64) et qu’il n’est pas forcément très didactique  . Bon il a quand même réussi au bout de 5 fois à m’expliquer l’utilisation de la ZP 

pour en revenir à l’IT (en général), je ne sais pas si je vais te rassurer, mais je suis passé par pas moins de 7 sociétés au cours de ma vie professionnelle, et je peux te garantir que c’est partout pareil. Je suis dans l’expertise et le conseil sur les bases de données oracle, et de la merde, j’en vois tous les jours, c’est juste hallucinant. Tu passes ta vie à apprendre et maîtriser des choses complexes, et dans 99% des cas concrets, tu as l’impression de passer sur un champs de ruines  . çà permet de crouter, mais c’est tout sauf stimulant d’un point de vue intellectuel …. 

Comme j’ai dit à mon chef, au moins sur c64 et qui plus est en assembleur, soit çà fonctionne, soit çà merde, entre les deux c’est rarement jouable 

Je passe pour un malade lorsque j’explique que je me remet à la programmation en assembleur, mais y’a un paquet de mecs qui auraient dû passer par là pour comprendre comment fonctionne un ordinateur avant d’envisager de poser les mains sur un système professionnel pour ensuite le défigurer 

A très bientôt avec la suite de mes aventures sur C64 ;)

Et j’attends avec impatience une éventuelle prochaine publication de ta part !

A+

N.