{"id":1192,"date":"2019-11-16T20:57:03","date_gmt":"2019-11-16T19:57:03","guid":{"rendered":"https:\/\/ceobeta.oric.org\/?p=1192"},"modified":"2019-11-16T20:57:03","modified_gmt":"2019-11-16T19:57:03","slug":"retour-sur-la-mise-en-oeuvre-du-psg-ay3-8912","status":"publish","type":"post","link":"https:\/\/oric.bqtt.net\/index.php\/2019\/11\/16\/retour-sur-la-mise-en-oeuvre-du-psg-ay3-8912\/","title":{"rendered":"Retour sur la mise en \u0153uvre du PSG AY3-8912"},"content":{"rendered":"\n

par Andre C.<\/em><\/p>\n\n\n\n

Dans certaines de mes exp\u00e9rimentations musicales r\u00e9centes (par exemple MereMichel2, qui utilise la commande SOUND), j’ai \u00e9t\u00e9 amen\u00e9 \u00e0 ajouter un CALL#C4B7 en fin de programme. Il s’agit d’une sorte de pseudo END qui permet de sortir du programme en \u00e9vitant le “Ready” et surtout le parasite sonore qui l’accompagne (une sorte de “PEUP”). Impossible de trouver la cause de ce parasite.<\/p>\n\n\n\n

En cherchant autre chose, je suis tomb\u00e9 sur la citation suivante : “Le fait crucial suivant ne figure dans aucun manuel : Au boot et lors de chaque retour \u00e0 l’interpr\u00e9teur BASIC, le canal 1 est valid\u00e9 (mais ni le 2, ni le 3, ni le bruit). C’est comme si un PLAY 1,0,0,0 \u00e9tait ex\u00e9cut\u00e9. Ceci explique pourquoi les essais que l’on peut faire sur le canal 1 ne marchent pas toujours lors de leur mise en application ult\u00e9rieure. Par exemple au “Ready”, un MUSIC 2,3,10,9 ne produit rien, alors que MUSIC 1,3,10,9 produit bien un LA de l’octave 3. Si le bit 3 de #26A est \u00e0 z\u00e9ro (bruit clavier actif) alors PLAY 1,0,0,0 est envoy\u00e9 \u00e0 chaque \u201cReady\u201d. Si le bit 3 est \u00e0 un (clavier muet) alors c\u2019est le dernier PLAY qui reste valide (comme en mode programme) tant qu\u2019on n\u2019envoie pas un nouveau PLAY ou qu\u2019on ne coupe pas l\u2019alimentation \u00e9lectrique du PSG.<\/em>“<\/p>\n\n\n\n

Ceci se trouve dans l\u2019article “PLAY, MUSIC, SOUND, une mise au point effectu\u00e9e par Andr\u00e9 C., Dominique P. et Claude S.” (CEO-mag n\u00b0119, pages 25-39). En fait, Dominique est le p\u00e8re de cette observation \u00e9tonnante, ce qui explique peut-\u00eatre que je ne l’avais pas gard\u00e9e en m\u00e9moire.<\/p>\n\n\n\n

“Le fait crucial suivant ne figure dans aucun manuel : Au boot et lors de chaque retour \u00e0 l’interpr\u00e9teur BASIC, le canal 1 est valid\u00e9 (mais ni le 2, ni le 3, ni le bruit). C’est comme si un PLAY 1,0,0,0 \u00e9tait ex\u00e9cut\u00e9. Ceci explique pourquoi les essais que l’on peut faire sur le canal 1 ne marchent pas toujours lors de leur mise en application ult\u00e9rieure. Par exemple au “Ready”, un MUSIC 2,3,10,9 ne produit rien, alors que MUSIC 1,3,10,9 produit bien un LA de l’octave 3. Si le bit 3 de #26A est \u00e0 z\u00e9ro (bruit clavier actif) alors PLAY 1,0,0,0 est envoy\u00e9 \u00e0 chaque \u201cReady\u201d. Si le bit 3 est \u00e0 un (clavier muet) alors c\u2019est le dernier PLAY qui reste valide (comme en mode programme) tant qu\u2019on n\u2019envoie pas un nouveau PLAY ou qu\u2019on ne coupe pas l\u2019alimentation \u00e9lectrique du PSG.<\/em>“
Ceci se trouve dans l\u2019article “PLAY, MUSIC, SOUND, une mise au point effectu\u00e9e par Andr\u00e9 C., Dominique P. et Claude S.” (CEO-mag n\u00b0119, pages 25-39). En fait, Dominique est le p\u00e8re de cette observation \u00e9tonnante, ce qui explique peut-\u00eatre que je ne l’avais pas gard\u00e9e en m\u00e9moire.<\/p>\n\n\n\n


Comme ce ph\u00e9nom\u00e8ne me chiffonnait toujours, j’ai effectu\u00e9 quelques recherches. Voici les observations que j’ai pu faire :
1) Les sons parasites produits d\u00e9pendent de la configuration<\/strong>. On peut bien s\u00fbr les entendre avec un Atmos seul (configuration 1), mais ils sont plus importants dans la configuration Atmos+Microdisc+Sedoric (configuration 2). Ainsi, dans la configuration 2, si l’on remplace le CALL#C4B7 final par un END, le programme modifi\u00e9 produit un “PEUP” en rendant la main. Par contre avec la configuration 1, le m\u00eame programme modifi\u00e9 de la m\u00eame mani\u00e8re rend la main sans produire de parasite sonore. Curieux non?
2) Les sons parasites produits d\u00e9pendent des commandes utilis\u00e9es<\/strong>. Par exemple, les deux programmes MereMichel1 et MereMichel2 sont quasi identiques et produisent les m\u00eames sons, sauf que le premier utilise la commande MUSIC et reste silencieux apr\u00e8s le retour au “Ready” (configuration 2), alors que le second utilise la commande SOUND et n\u00e9cessite l’ajout du fameux CALL#C4B7 pour bloquer le disgracieux “PEUP”(toujours avec la configuration 2).
3) La mani\u00e8re dont on termine le programme joue aussi<\/strong>. Curieusement, ajouter une commande END en fin de programme est souvent toxique. Si n\u00e9cessaire, mieux vaut sortir avec un CALL#C4B7 ou alors effectuer un reset des registres du PSG (voir plus loin la routine RSETPSG).
4) Si on utilise un Oric r\u00e9\u00e9l ou un \u00e9mulateur<\/strong>.
Je ne suis pas all\u00e9 plus loin dans la recherche des causes du ph\u00e9nom\u00e8ne, d\u00e9courag\u00e9 par l’h\u00e9t\u00e9rog\u00e9n\u00e9it\u00e9 des conditions dans lesquelles il se produit.
Mais le probl\u00e8me vient sans doute en grande partie du fait que les 14 registres du PSG sont latch\u00e9s (verrouill\u00e9s), ce qui veut dire que la valeur qu’on y \u00e9crit y reste jusqu’\u00e0 ce qu’on en \u00e9crive une autre ou que l’on coupe le courant.
Selon la configuration, les commandes musicales utilis\u00e9es et la mani\u00e8re dont on termine le programme, il est difficile de savoir ce qu’il y a dans ces 14 registres. Certes un PLAY 0,0,0,0 semble tout couper, mais en apparence seulement car seul le registre 7 est mis \u00e0 jour, sans nettoyage des 13 autres registres. Ce registre 7 sert \u00e0 valider les canaux actifs. Les bits 0, 1 et 2 contr\u00f4lent respectivement les canaux 1, 2 et 3 ; les bits 3, 4 et 5 mixent le bruit blanc aux canaux 1, 2 et 3. Attention, pour valider un canal, il faut mettre le bit correspondant \u00e0 0. Par cons\u00e9quent la commande PLAY 0,0,0,0 envoie la valeur #3F (111111 en binaire) dans le registre 7 ce qui bloque toutes les sorties ! Je ne suis pas \u00e0 l’origine de cette conception tordue et j’esp\u00e8re que vous avez suivi !
Quand on revalide un canal (ou quand on retourne au “Ready”, ce qui revalide le canal 1), on peut alors entendre s’exprimer ce que le PSG a dans le ventre, m\u00eame si ce n\u2019est ni voulu, ni agr\u00e9able !
Je ne vois qu’une seule solution \u00e0 ce probl\u00e8me : neutraliser tous les registres du PSG !<\/p>\n\n\n\n

Registre 0 et 1 : Tonalit\u00e9 canal 1 (de #00 \u00e0 #0FFF) mettre \u00e0 #0000
Registre 2 et 3 : Tonalit\u00e9 canal 2 (de #00 \u00e0 #0FFF) mettre \u00e0 #0000
Registre 4 et 5 : Tonalit\u00e9 canal 3 (de #00 \u00e0 #0FFF) mettre \u00e0 #0000
Registre 6 : Tonalite bruit blanc (de 0 a $1F) mettre \u00e0 #00
Registre 7 : Contr\u00f4le des canaux en service (de #00 \u00e0 #3F) mettre \u00e0 #3F
Registre 8 : Volume canal 1 (de #00 \u00e0 #10) mettre \u00e0 #00
Registre 9 : Volume canal 2 (de #00 \u00e0 #10) mettre \u00e0 #00
Registre 10 : Volume canal 3 (de #00 \u00e0 #10) mettre \u00e0 #00
Registre 11 et 12 : Dur\u00e9e du son (de #00 \u00e0 $FFFF) mettre \u00e0 #0000
Registre 13 : Forme de l’enveloppe (de #00 \u00e0 #0F) mettre \u00e0 #00<\/p>\n\n\n\n

Ceci peut se faire \u00e0 l’aide de la petite routine en assembleur RSETPSG ci-dessous :<\/p>\n\n\n\n

<\/strong>; Routine RSETPSG pour neutraliser les 14 registres du PSG AY3-8912
; Cette routine sera appel\u00e9e par CALL STP (soit #980E si la routine est implant\u00e9e en #9800)
org $9800 ; Exemple d'adresse d'implantation de la routine
DATA db $00, $00, $00, $00, $00, $00 ; Tonalite canaux A, B et C (de 0 a $0FFF)
db $00 ; Tonalite bruit blanc (de 0 a $1F)
db $3F ; Canaux C+br, B+br, A+br, C, B, A)
db $00, $00, $00 ; Volume canaux A, B et (0 a $0F, -> enveloppe si $10)
db $00, $00 ; Dur\u00e9e du son (de 0 a $FFFF)
db $00 ; Forme de l'enveloppe (de 0 \u00e0 7)
STP ldx #LOW DATA ; Adresse des 14 valeurs
ldy #HIGH DATA ; \u00e0 envoyer au PSG
jmp $FA86 ; Routine en Rom \"\u00e9crire dans les 14 registres du PSG\"
EOF<\/code><\/p>\n\n\n\n


Il est \u00e9videmment possible de POKEr les octets correspondants avec un programme Basic :<\/p>\n\n\n\n

100 FOR K=#9800 TO #9814:READ V:POKE K,V:NEXT
200 DATA 0,0,0,0,0,0,0,#3F,0,0,0, 0,0,0,#A2,#00,#A0,#98,#4C,#86,#FA
300 SAVE\"RSETPSG\",A#9800,E#9814<\/code><\/p>\n\n\n\n

La routine est relogeable si on assemble le programme source \u00e0 une autre adresse ou si on met \u00e0 jour manuellement les octets du LDX #00 (ici #A2,#00) et ceux du LDY#98 (ici #A0,#98) afin de cibler la nouvelle adresse d’implantation.
La diff\u00e9rence entre ces 2 CALL est que le CALL#C4B7 (routine de la Rom) rend la main (sans afficher le “Ready”), alors que le CALL#980E (routine RSETPSG en Ram) permet de rester dans le programme et \u00e9ventuellement d’en sortir plus proprement. Ces deux rem\u00e8des devraient r\u00e9soudre vos \u00e9ventuels probl\u00e8mes. N’h\u00e9sitez pas \u00e0 faire conna\u00eetre vos tribulations musicales\u2026<\/p>\n","protected":false},"excerpt":{"rendered":"

par Andre C. Dans certaines de mes exp\u00e9rimentations musicales r\u00e9centes (par exemple MereMichel2, qui utilise la commande SOUND), j’ai \u00e9t\u00e9 amen\u00e9 \u00e0 ajouter un CALL#C4B7 en fin de programme. Il s’agit d’une sorte de pseudo END qui permet de sortir du programme en \u00e9vitant le “Ready” et surtout le parasite sonore qui l’accompagne (une sorte […]<\/p>\n","protected":false},"author":1,"featured_media":1206,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[338,22,302],"tags":[387,666,855],"class_list":["post-1192","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-338","category-ceomag","category-hardware","tag-ay3-8912","tag-ceomag357","tag-psg"],"_links":{"self":[{"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/posts\/1192","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/comments?post=1192"}],"version-history":[{"count":0,"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/posts\/1192\/revisions"}],"wp:attachment":[{"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/media?parent=1192"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/categories?post=1192"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/oric.bqtt.net\/index.php\/wp-json\/wp\/v2\/tags?post=1192"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}