WordPress

Category: 2020

  • Les sons préprogrammés de l’Oric (fin)

    3 – ZAP et OUPS

    Introduction

    Ces deux derniers sons ont une structure différente de celle des 5 sons préprogrammés précédents. Ils n’utilisent pas d’enveloppe, mais font appel à des boucles de temporisation pour contrôler l’évolution du son.

    LA COMMANDE ZAP

    Voici la routine copiée et adaptée de la Rom :

    Voici ce que révèle le bloc des 14 paramètres :

    -Contrôle des canaux en service : R7 = #3E, soit 0011 1110. Seul le canal 1 est activé.

    -Période du canal 1 : R0/R1 = #0000. Soit une fréquence infinie que le PSG 9812 ne peut générer !

    -Aucun bruit blanc n’est généré car R6 = #00.

    -Volume du son du canal 1 : R8 = #0F (le maximum). Aucune enveloppe n’est mise en jeu.

    Au premier abord, les paramètres de ZAP sont surprenants ! Le PSG est initialement mis en position de générer des ultra-sons, ce qu’il ne sait pas faire. Mais dans le code qui suit le chargement des 14 paramètres, une boucle est générée, comprenant une temporisation de 1,28 ms et une incrémentation de la période du 1er canal. Cette boucle tourne jusqu’à ce que la période atteigne #0070 ce qui correspond à 554 Hz : Le PSG génère donc un son de plus en plus grave. Le processus se termine alors on envoyant #00 (volume sonore nul) dans le registre R8.

    Si on augmente la temporisation par un facteur 10, afin de mieux percevoir ce qui sort du PSG au début de ZAP, on se rend compte que des criailleries atroces sont générées, comme si on était en train d’assassiner votre Oric ! Heureusement, avec la temporisation normale de ZAP, elles sont trop brèves pour être perçues. Mais il aurait été plus propre d’initialiser la période de départ du canal 1 avec une valeur un peu plus haute que  #0000 !

    Variantes

    La plus évidente est de réduire le volume sonore qui est actuellement au maximum. Un POKE # 982E suivit d’une valeur de #00 à #0F permet de l’ajuster finement.

    Ceci mis à part, les autres possibilités de modifications sont infinies grâce au concept de temporisation permettant d’introduire une modification des paramètres du PSG9812. Rien n’empêche de compliquer le profil du son produit. ZAP est de loin le son préprogrammé le plus intéressant de l’Oric.

    Pour l’heure, nous serons plus modestes et fixerons une période de départ autre que #0000 et une période d’arrivée autre que #0070. Nous pourrons aussi modifier la temporisation, c’est-à-dire la durée de chaque fréquence générée, et par suite la durée totale du son produit.

    Comme précédemment, la procédure consistera à charger ZAPLM en Ram et à POKEr les valeurs à modifier. Cette routine est localisée de #9800 à #9833 et les adresses à POKEr sont les suivantes :

    En #982E : Paramètre R8. Le volume du son du canal 1.

    En #9808 : Octet de poids faible de la période de départ (limitée à #FF, car un seul octet est pris en compte).

    En #981C : Octet de poids faible de la période finale (idem un seul octet pris en compte).

    En #9813 : Le nombre de tours de la boucle de temporisation. Dans l’état actuel de la routine (une boucle de 256 réitérations), il est seulement possible de réduire cette durée. Pour l’augmenter, il faudra mettre en place une deuxième boucle.

    Le programme ZAP1.BAS offre quelques échantillons tout prêts tandis que ZAP2.BAS permet d’expérimenter soi-même de nouveaux sons, en ajustant le volume sonore, la temporisation, les périodes de départ et de fin.

    Quelques remarques :

    -La durée des sons produits est très variable compte tenu de la gamme des fréquences à parcourir.

    -Les sons produits vont de l’aigu vers le grave. Or les sons aigus semblent moins audibles que les graves (à moins que ce ne soit un problème personnel). Il s’en suit que toutes les variantes se ressemblent car elles finissent par des sons graves mieux perçus.

    LA COMMANDE OUPS

    Voici le code d’OUPS transposé et adapté pour l’Atmos à partir du code original d’OUPS pour Telestrat :

    Voici ce que révèle le bloc des 14 paramètres :
    -Contrôle des canaux en service : R7 = #3E, soit 0011 1110. Seul le canal 1 est activé.
    -Période du canal 1 : R0/R1 = #0046 (environ un LA de l’octave 4).
    -Aucun bruit blanc n’est généré car R6 = #00.
    -Volume du son du canal 1 : R8 = #0F (le maximum). Aucune enveloppe n’est mise en jeu.
    Le PSG 9812 génère un LA de l’octave 4 avec un volume sonore maximum suivit d’une temporisation de 0,12 s avant que finalement le canal 1 soit inactivé. Simple non ?

    Variantes

    OUPS repose sur 3 paramètres : Période et volume du son, durée de la temporisation. La période du canal 1 (R0/R1) peut être comprise entre #0000 et #0FFF. Le volume sonore (R8) est ajustable de #00 à #0F. La durée du son peut varier de 1,28 ms (avec Y=1) et 0,33 s (avec Y=#FF). On peut évidemment générer une infinité de sons en combinant ces 3 paramètres.
    Après avoir chargé OUPSLM en Ram, il suffit de poker les valeurs à modifier. Compte tenu de l’adresse d’implantation d’OUPS en Ram (de #9800 à #9827), les adresses à poker sont :
    En # 981A-#981B : Période du canal 1 (R0/R1).
    En #9809 : Nombre de tours de la boucle externe Y.
    En #9822 : Volume sonore du canal 1 (R8)
    Comme pour les autres sons, je vous propose deux petits programmes Basic: Le premier OUPS1.BAS propose divers échantillons de variantes d’OUPS et le second OUPS2.BAS permet d’expérimenter soi-même toutes les combinaisons possibles des 3 paramètres d’OUPS.

    Le programme OUPS1.BAS

    Le menu propose 20 périodes correspondant à la fréquence des notes de DO de l’octave 1 au DO de l’octave 6, puis du LA de l’octave 1 au LA de l’octave 6 et enfin toute la gamme de l’octave 4. Les deux autres paramètres (durée et volume du son) n’ont pas été modifiés et sont ceux du OUPS d’origine.

    Le programme OUPS2.BAS

    Le menu vous propose de tester vous-même tous les sons de votre choix. On peut fixer indépendamment période, volume et durée et écouter ce que cela donne.

    LA COMMANDE ZAAP

    Voici une nouvelle famille de sons, les “ZAAP”, basés sur la routine ZAP, mais dont la durée serait augmentée grâce à une boucle supplémentaire. Non seulement cela permettra d’obtenir des sons plus longs, mais aussi de “normaliser” leur durée, qui varie selon le nombre de périodes balayées. Au final, avec cette “normalisation”, des sons de durée similaire pourront plus facilement être comparés.

    Listing modifié :

    Le nouveau listing ZAAPLM.ASM peut être obtenu à partir du listing ZAPLM.ASM en remplaçant la section située entre les lignes “;Début de la temporisation” et “;Fin de la temporisation” par la même section prise dans OUPSLM.ASM. Cette boucle supplémentaire permet des temporisations de 1,23 ms (pour Y=#01) à 315 ms (pour Y=#00, c’est-à-dire #100 en réalité).
    La temporisation comporte une partie fixe (boucle interne de 1,28 ms environ) et une partie ajustable, la 2e boucle ou boucle externe, qui joue un rôle multiplicateur. La durée totale théorique en ms d’un ZAAP est égale à 1,28 x(période finale – période initiale) x(nombre de tours de 2e boucle). La brièveté des sons ne permet pas de vérifier les valeurs réelles obtenues.

    Le programme ZAAP1.BAS

    Il montre ce que ça donne avec les octaves 3 à 7 lorsque la temporisation a été ajustée pour obtenir des sons de durée totale de 160, 320, 640 et 1300 ms. Voici  les périodes de départ et de fin utilisées pour chaque octave :

    Résultats On observe une nette progressivité dans les résultats obtenus avec les octaves 7 à 3 et pour chacune avec les durées croissantes. C’est l’octave 7 (la plus aiguë)  qui est la moins satisfaisante : La durée 640 ms et surtout la durée 1300 ms révèlent des distorsions peu agréables. Mais dans l’ensemble, cela représente une belle bibliothèque de sons cohérents dérivés de ZAP.

    Le programme ZAAP2.BAS

    Il vous permettra de procéder à vos propres tests en modifiant, les périodes de départ et de fin, ainsi que le nombre de boucles Y et le volume sonore. Le tableau ci-dessus vous sera probablement de quelque aide.

    Vous trouverez tous les programmes produits au cours de ce travail dans le fichier SonsPreprogr3.zip qui accompagne cet article.

    SonsPreprogr3.zipTélécharger

  • Les sons préprogrammés de l’Oric

    2e partie : PING, SHOOT, EXPLODE, TOUCON et TOUNOR

    Introduction

    Dans la première partie, nous avons vu comment modifier en Ram les sons préprogrammés dans la Rom, afin de pouvoir les adapter à nos besoins. Dans  cette 2e partie, nous verrons PING, SHOOT, EXPLODE, TOUCON (son des touches contrôles) et TOUNOR (son des touches normales). Ces cinq commandes ont toutes le même code : LDX LL, LDY HH et JSR #FA86. Seule diffère l’adresse LLHH ciblant le bloc des 14 paramètres que la routine #FA86 doit envoyer au PSG 8912.

    Pendant que je suis dans les généralités, remarquons que ces 5 sons utilisent une seule et même enveloppe, la n°0 \, mais avec une durée différente pour chacun d’eux.

    Ils se répartissent ensuite en 2 groupes : D’une part PING, TOUCON et TOUNOR qui utilisent un seul canal, le n°1 et pas de bruit blanc et d’autre part SHOOT et EXPLODE qui n’utilisent QUE du bruit blanc, mais mixé aux canaux 1,2 et 3.

    Pour le groupe PING, TOUCON et TOUNOR, c’est la période de ce canal 1 (paramètres R0/R1) qui fait la différence.  Pour le groupe SHOOT et EXPLODE, c’est la période du bruit blanc (paramètre R6) qui fait la différence. Vous savez déjà quasiment tout ! Les 2 commandes restantes, ZAP et OUPS, ont une structure différente et seront traitées dans la troisième et dernière partie de cette étude.

    La commande PING

    Contenu du bloc des 14 paramètres (voir le fichier source PINGLM.ASM) :

    #18, #00, #00, #00, #00, #00, #00               pour R0 à R6

    #3E, #10, #00, #00, #00, #0F, #00               pour R7 à R13.

    Prêtons attention aux valeurs différentes de zéro (sauf pour R7). Que fait PING ?

    -Contrôle des canaux en service : R7 = #3E = 0011 1110. Seul le canal 1 est actif.

    -Période du canal 1 : R0/R1 = #0018. Le son produit est proche du MI de l’octave 6.

    -Volume du son pour le canal 1 : R8 = #10. Le volume est contrôlé par une enveloppe.

    -Durée de cette enveloppe : R11/R12 : #0F00. On a #0F00x256=983040 µs soit environ 1s.

    -Numéro de l’enveloppe : R13 = #00. Il s’agit de la rampe descendante de forme \.

    PING envoie sur le canal 1 un son proche du MI de l’octave 6. Ce son attaque directement au volume maximal puis décroit jusqu’au niveau zéro, ce qui prend  environ 1s. La production de bruit blanc est inactivée. Les variables que nous pouvons ajuster sont la période et la durée du son.

    Variantes

    Je vous propose deux programmes, PING1.BAS qui offre quelques exemples de variantes et PING2.BAS qui permet d’expérimenter soi-même des sons basés sur PING en ajustant à volonté la période et la durée de l’enveloppe.

    Ces 2 programmes chargent PINGLM en Ram et de DOKEnt les valeurs à modifier selon les choix offerts par un menu. Compte tenu de l’adresse d’implantation de PINGLM en Ram (de #9800 à #9814), les adresses à DOKEr sont :

    En #9807- #9808 : La période du canal 1.

    En #9812- #9813 : La durée de la rampe. PING1.BAS propose 20 variantes de PING qui illustrent les possibilités (figure de gauche page précédente), que je vous laisse approfondir avec PING2.BAS en jouant simultanément sur la période et sur la durée.

    Les commandes TOUCON et TOUNOR

    Voici ce que révèle le bloc des 14 paramètres :

    Pour TOUCON :

    #2F, #00, #00, #00, #00, #00, #00               pour R0 à R6

    #3E, #10, #00, #00, #1F, #00, #00               pour R7 à R13.

    Pour TOUNOR :

    #1F, #00, #00, #00, #00, #00, #00               pour R0 à R6

    #3E, #10, #00, #00, #1F, #00, #00               pour R7 à R13.

    Ces deux commandes ne diffèrent que par la période du canal 1.

    -Contrôle des canaux en service : R7 = #3E = 0011 1110. Seul le canal 1 est actif.

    -La période du canal 1 (R0/R1) vaut :

     #002F pour TOUCON (MI de l’octave 5) et

     #001F pour TOUNOR (SI de l’octave 5).

    -Volume du son pour le canal 1 : R8 = #10. Le volume est contrôlé par une enveloppe.

    -La durée de l’enveloppe (R11/R12) est de #001F (environ 8 ms). C’est la différence majeure avec PING : Si PING est bref, TOUCON et TOUNOR sont ultra-brefs !

    -Numéro de l’enveloppe : R13 = #00. Il s’agit de la rampe descendante de forme \.

    Comme pour PING, les variables que nous pouvons ajuster sont la période et la durée du son. En fait, le fonctionnement des commandes TOUCON et TOUNOR est tout à fait semblable à celui de PING.

    Variantes

    Comme pour PING, je vous propose deux programmes :

    -TOUCON1.BAS propose 18 variantes de TOUCON/TOUNOR qui illustrent les possibilités (figure de droite page précédente) et que je vous laisse approfondir avec

    -TOUCON2.BAS en jouant simultanément sur la période et sur la durée.

    Ces 2 programmes s’appliquent aussi bien à TOUCON qu’à TOUNOR. Les adresse d’implantation de TOUCONLM en Ram et les adresses à DOKEr sont les mêmes que pour PING.

    Les commandes SHOOT et EXPLODE

    Voici ce que révèle le bloc des 14 paramètres :

    Pour SHOOT :

    #00, #00, #00, #00, #00, #00, #0F               pour R0 à R6

    #07, #10, #10, #10, #00, #08, #00               R7 à R13.

    Pour EXPLODE :

    #00, #00, #00, #00, #00, #00, #1F               pour R0 à R6

    #07, #10, #10, #10, #00, #18, #00               R7 à R13.

    On peut observer les paramètres :

    -Contrôle des canaux en service : R7 = #07 = 0000 0111. Les canaux 1, 2 et 3 ne délivrent que du bruit blanc.

    -Ce bruit blanc a pour période R6 = #0F pour SHOOT et R6 = #1F pour EXPLODE.

    -Pour les 2 commandes, le volume du son sur les 3 canaux est contrôlé par une enveloppe : R8 à R10 valent #10.

    -La durée de cette enveloppe (R11/R12) est #0800  (0,5 s environ) pour SHOOT et  #1800 (1,6 s environ) pour EXPLODE.

    -Numéro de l’enveloppe : R13 = #00. Il s’agit de la rampe descendante de forme \. Ces deux commandes sont très proches l’une de l’autre. Elles ne diffèrent que par la durée de l’enveloppe et la période du bruit blanc. La particularité de ces 2 sons est de reposer uniquement sur la production de bruit blanc ! Par définition, un bruit blanc est un signal aléatoire (voir https://fr.wikipedia.org/wiki/Bruit_blanc) et la notion de “période du bruit blanc” est surprenante, mais bon, voyons ce que ça donne en pratique…

    Variantes

    Ici encore les possibilités de modulation sont évidentes : Soit on modifie la période du bruit blanc, soit on joue sur la durée de l’enveloppe.

    Comme précédemment, la procédure consistera à charger SHOOTLM ou EXPLODELM en Ram et à POKEr les valeurs à modifier. Ces 2 routines ont la même adresse d’implantation en Ram (de #9800 à #9814) et les mêmes adresses à POKEr :

    En #980D :                         La période du bruit blanc.

    En #9812- #9813 :            La durée de la rampe.

    Les programmes SHOOT1.BAS (figure de gauche page précédente) et EXPLODE1.BAS (figure de droite page précédente) offrent quelques échantillons à écouter. Dans SHOOT1.BAS, la période du bruit blanc et la durée de l’enveloppe varient séparément, tandis que dans EXPLODE1.BAS les variations de ces 2 paramètres sont combinées. Les programmes SHOOT2.BAS et EXPLOD2.BAS vous permettrons d’expérimenter vos propres idées, en ajustant à volonté la période du bruit blanc et la durée de l’enveloppe. En fait ces 2 programmes s’appliquent aussi bien à SHOOT qu’à EXPLODE. Avec un peu de chance vous aurez la surprise de retrouver EXPLODE avec SHOOT2.BAS et SHOOT avec EXPLODE2.BAS !

    Petite douceur

    Après tout ce travail, il est temps de s’offrir une petite gâterie. Tous les sons examinés jusqu’ici étaient basés sur l’enveloppe n°0 \. Juste pour voir, j’ai fait quelques essais avec les enveloppes /, ////, / ͞   et /\/\/ , ceci pour les 5 sons PING, SHOOT, EXPLODE, TOUCON et TOUNOR. Pour chacun de ces sons, un seul paramètre diffère des paramètres d’origine : R13, qui est respectivement mis à #04 (/), #0C (////), #0D (/ ͞  ) et #0E (/\/\/) (figure ci-dessus).

    Comme on pouvait s’y attendre, les sons produits avec les enveloppes ////, / ͞   et /\/\ continuent à l’infini  (mais j’ai coupé !).

    Pour PING, SHOOT, EXPLODE, TOUCON et TOUNOR avec enveloppe /, les résultats sont assez surprenants, car ces 5 sons fonctionnent à l’envers de ce qu’on a habituellement dans l’oreille ! Les sons TOUCON et TOUTNOR inversés sont particulièrement intéressants.

    Avec l’enveloppe //// (c’est à dire les sons précédents mais répétés à l’infini), on découvre des bruits surprenants de machines ou de sonneries.

    L’enveloppe / ͞   est moins intéressante car le volume du son est maintenu au niveau haut à l’infini.

    Enfin l’enveloppe /\/\/, couplée à PING, SHOOT et EXPLODE nous emmène au bord de la mer (avec beaucoup d’imagination). A nouveau TOUCON et TOUTNOR donnent des résultats plutôt rigolos que je vous laisse les découvrir.

    Vous trouverez tous les fichiers de ces expérimentations et une mine d’idées pour agrémenter le bruitage de vos programmes dans le fichier SonsPreprogr2.zip qui accompagne cet article.

    A suivre…

    SonsPreprogr2.zipTélécharger

  • Les sons préprogrammés de l’Oric

    1e partie : Récupération et adaptation du code source

    par André C.

    Les 3 articles précédents “Musique, Note, Octave, Fréquence et Période“, “Les enveloppes du PSG 8912” et “Temporisation en langage machine” vous ont fourni quelques éléments de compréhension des sons de l’Oric. Nous allons voir comment exploiter au mieux les sons préprogrammés grâce à une nouvelle série de 3 articles. Afin d’éviter les redites, j’ai zappé les bases déjà décrites et vous invite à vous reporter aux articles précédents en cas de besoin.

    Liste des sons préprogrammés

    Aux commandes usuelles PING, SHOOT, EXPLODE et ZAP, il faut ajouter TOUCON (bruit clavier des touches contrôles), TOUNOR (idem touches normales) et OUPS, le petit dernier du Telestrat.

    Tous les sons préprogrammés ont le même inconvénient : il n’est pas possible d’en moduler le volume sonore (d’où divers petits gadgets hardware apparus pour atténuer le son pendant la nuit !). La raison en est simple : Tous ces sons sont figés en Rom et on peut difficilement intervenir.

    Il est quand même possible de s’inspirer de leur code pour le mettre en Ram et le modifier. Pour OUPS par exemple, le volume sonore est figé plein pot, mais il est facile de rendre ce paramètre ajustable dans une version en Ram. Malheureusement, pour les sons préprogrammés utilisant une enveloppe, on est bien obligé de garder celle-ci, sous peine de faire autre chose. Il est toutefois possible de modifier la hauteur de la note, sa durée etc.

    Structure des sons préprogrammés

    Tous ces sons sont basés sur 2 routines en Rom :

    • La routine #F590 envoie un seul des 14 paramètres au PSG (les registres A et Y du 6502 contenant respectivement le paramètre à envoyer et le numéro du registre cible).
    • La routine #FA86 envoie 14 paramètres au PSG (les registres X et Y du 6502 contenant l’adresse où se trouvent les 14 paramètres).

    En outre ZAP et OUPS font appel à une temporisation à boucle pour gérer la durée du son produit.

    Récupération des sources en langage machine

    Le plus simple est donc de recopier le code présent en Rom dans un fichier source en langage machine. Il faut aussi modifier les adresses des blocs de paramètres pour les diriger vers la Ram. Enfin, dans le cas d’OUPS, il faut remplacer les adresses Telestrat par les adresses Atmos pour les 2 routines citées ci-dessus.

    C’est ainsi que j’ai obtenus les 8 fichiers source suivants : PINGLM.ASM, SHOOTLM.ASM, EXPLODLM.ASM, TOUCONLM.ASM, TOUNORLM.ASM, ZAPLM.ASM, OUPSLM.ASM et même PREDEFLM.ASM qui regroupe le code des 7 sons préprogrammés (voir le fichier SonsPreprogr1.zip qui accompagne cet article).

    Mise en œuvre des sons préprogrammés

    Après compilation, j’ai obtenu 8 fichiers exécutables .TAP qui sans surprise reproduisent fidèlement les 7 sons d’origine. Il ne reste plus qu’à étudier le mécanisme de chaque son et éventuellement à modifier certains paramètres.

    Les commandes PING, SHOOT, EXPLODE, TOUCON et TOUNOR utilisent une enveloppe pour contrôler le volume sonore alors que ZAP et OUPS fixent celui-ci au maximum. Le code de tous ces sons envoie un bloc de 14 paramètres au PSG 8912. Mais en outre, le code de ZAP et OUPS met en place des boucles de temporisation pour contrôler le son produit.

    L’analyse du bloc de 14 paramètres est facile car tous les paramètres sont à zéro par défaut (sauf R7 qui contrôle les canaux en service et qui est mis à #3F pour tout inhiber). Voir éventuellement “Retour sur la mise en œuvre du PSG AY3-8912” dans le CEO-mag de Janvier 2020.  Les paramètres spécifiques d’un son donné sont donc immédiatement apparents ce qui permet de comprendre ce que fait ce son. Attention toutefois au paramètre R13 dont la valeur #00 peut désigner l’enveloppe de n°0 lorsque le contrôle du volume sonore fait appel à une enveloppe.

    A suivre…

    SonsPreprogr1.zipTélécharger

  • Créer des écrans texte à partir de fichiers Markdown

    md2hlp est un outil programmé en python qui permet de générer des écrans textes Oric à partir de fichier Markdown (.md). L’outil est très utile pour faire par exemple des man pages sur Orix.

    Il fonctionne avec un script python, un fichier de conf et un fichier markdown en entrée. Ci dessous une image générée avec un markdown en entrée.

    Le résultat

    Le but de l’outil est d’avoir un écran texte généré par un fichier mark down tout en se basant sur un fichier de conf qui définira la mise en forme de l’écran, sans avoir à faire la mise en forme manuellement.

    Commençons

    Nous allons faire un écran avec un exemple de base (il vous faudra python3. Pour python2, il y a aussi la version du script python dans src/)

    $ git clone https://github.com/assinie/md2hlp.git
$ cd md2hlp/src/
$ python md2hlp.py3 -f ../examples/basic11.md -o basic11.hlp

    A ce stade, vous obtenez un fichier .hlp. C’est juste un écran texte.

    Maintenant, ajoutons un header pour qu’il se charge en $BB80. Il faudra osdk avec le binaire header et spécifier l’adresse $bb80 pour charger le .tap à la bonne adresse texte

    Allons plus loin

    Nous avons affiché la page avec la configuration par défaut qui est contenue ici : https://github.com/assinie/md2hlp/blob/master/src/md2hlp.cfg

    Cette configuration définit comment le programme python doit convertir le fichier .md (c’est une sorte de template)

    Cherchons la ligne contenant [Heading1] et remplaçons cette ligne :

    Head = __^J ^Q_ORIX 1.0 ^P___

    par

    Head = __^J ^Q_POUET POUET ^P___

    Notez les ^J ^Q etc : Cela correspond aux attributs définis dans le fichier de conf. Si vous cherchez ^J, vous tomberez sur : double_height = ^J

    Nous avons défini que le double_height est le contrôle ^J. Ainsi, le titre sera en double hauteur.

    paper_red = ^Q indique que ^Q sera le paper en rouge. Ainsi, notre POUET POUET sera également sur fond rouge. Je vous laisse trouver à quoi sert le ^P

    Pour finir, il suffit de définir un template qui déterminera ensuite l’apparence de votre fichier .md en sortie sur l’écran texte.

    L’outil md2hlp est utilisé pour faire les man pages sur Orix. Nous avons juste à mettre à jour les fichiers md, puis nous lançons md2hlp qui fera le reste. Par exemple, pour Orix, le fichier .hlp doit être placé dans /usr/share/man.

    Au lancement de man, il suffira de spécifier en paramètre le fichier hlp déposé dans le répertoire sans le .hlp

  • Initiation à la Twilighte board v0.6 (sdcard, joysticks, souris usb, RAM, ROMs)

    Début du projet et objectifs

    Cela fait quelques années que je travaille sur ce projet. L’objectif était d’avoir un atmos qui puisse tout démarrer (que cela soit les softs telestrat, mais aussi les softs sedoric, jasmin, les taps etc). Techniquement, beaucoup de choses sont possibles car la carte a différents hardwares permettant de faire des choses qui ne pouvaient pas être fait sur atmos ou telestrat

    Il manque le software pour plusieurs cas, mais maintenant que le hard est là, le soft peut se faire plus simplement.

    Le hardware aurait pu sortir plus rapidement si je m’étais limité à ne faire que le chargement sur sdcard, mais j’ai voulu apporter bien plus : Ajout de RAM, ROMs en banking, de ports joysticks, la gestion USB pour souris USB, la programmation sur réel des banques, et un OS commun (telestrat/Oric-1/Atmos pour tout articuler). La partie qui m’a pris le plus de temps a été sans doute les problèmes de timings avec le 6502.

    Cet article ne représente pas tout ce que la carte fait. Cet article est rédigé comme une sorte d’introduction à la carte.

    Au début du projet, j’ai travaillé avec des CPCistes car ils avaient déjà fait des choses similaires. Puis, Assinie a proposé son aide, et l’évolution à la fois de la carte et du soft a pris un coup de boost puisque la plupart des trucs soft les plus marquants viennent d’Assinie 🙂

    Le projet n’est pas fermé, chacun peut venir se greffer (au soft et au hard). Néanmoins, pour le hardware, j’ai une sorte de feuille de route que j’essaie de suivre car d’autres versions du hard sortiront dans le futur pour améliorer la carte avec des nouvelles fonctionnalités.

    Pour le software, il est possible de faire un jeu en .tap avec les joysticks. Ou Alors il est possible de faire un jeu sur Orix pour profiter de primitives d’ouvertures de fichiers, de lecture, d’affichage etc. Il est techniquement possible de faire un .tap qui pourrait profiter de toutes les banques RAM et ROMs, mais à mon avis, il serait plus simple de faire fonctionner le soft en natif Orix.

    Contenu de la carte

    • Fonctionne avec le 6502 de base uniquement
    • Deux ports joysticks utilisables simultanément si on veut. 1 port avec 3 boutons, le 2ème port avec 1 bouton (la souris AMX marche à partir du moment où on apporte le 5V car l’AMX version CPC n’a pas le 5V de cablé sur le port)
    • Un connecteur sdcard pour charger à partir de la sdcard (FAT 32 et carte à 32GO maximum)
    • Un connecteur USB pour connecter tous les devices usb possibles sur usb, mais il faut écrire les drivers ! 🙂 La liaison série au niveau USB est possible mais il faut aussi écrire les drivers ! La souris USB fonctionne à condition d’écrire le code (qui est ici assez simple, il peut s’écrire en basic), une clé USB de stockage fonctionne aussi.
    • 32 banques de 16KB en ROM
    • 32 banque de 16KB en RAM

    Transformer un Oric-1 en atmos, un atmos en Oric-1, ou un atmos en telestrat !

    Techniquement, il est possible de charger des jeux atmos et de jouer avec des joysticks sans modification du jeu.

    Il n’est pas possible de démarrer des soft sur dsk pour l’instant. Mais il sera possible de démarrer sur les jeux oric-1 only.

    Néanmoins, avec la carte, il serait possible d’avoir la logithèque telestrat.

    Démarrer les .tap Atmos et jouer aux joysticks

    La carte permet de charger la rom atmos modifiée (ou tout autre rom) et de démarrer les .tap sur une sdcard ou sur une clé USB. Pour être franc, la carte n’a pas eu pour objectifs de démarrer les .tap sur sdcard. C’était techniquement possible, mais ce n’était pas la partie qui m’intéressait le plus. L’idée était surtout de pouvoir tout démarrer et d’étendre l’oric

    Cette rom basic11 peut charger le multitap. Certains jeux sont récalcitrants, mais Assinie réussit progressivement à faire tourner les jeux sans patch du jeu

    Ceci est une limite software qui peut être levée grâce à la mise à jour des roms !

    Mise à jour des roms

    La carte a été prévue pour pouvoir se reprogrammer au niveau des roms et de la RAM sans avoir besoin d’aucun équipement, ce qui donne une certaine souplesse d’utilisation et de mise à jour. La carte n’est pas figée, elle vit 🙂

    Un bouton reset qui pourrait être magique !

    Un bouton reset est présent, mais il serait possible de conditionner le démarrage après le reset en appuyant sur une touche, en même temps que l’on reset. Ce n’est pas une idée révolutionnaire, c’est ce qui existait déjà un peu sur telestrat avec la touche del et le reset.

    Disponibilité

    La carte est disponible maintenant, mais les pcb sont déjà réservés (il n’y avait que 10 exemplaires disponibles). Si vous en voulez une, il faudra me contacter par mp sur ce site ou par mail afin que je vous mette en liste d’attente. La carte a un coût de 100 euros, et est un peu longue à assembler (et les composants sont de 3 fournisseurs, ce qui rend compliqué la production). Enfin, je fais cela sur mon peu de temps disponible mais cela avance tout de même 🙂

    Pour en savoir plus : https://orix.oric.org

  • Musique, Note, Octave, Fréquence et Période

    Rappels et précisions

    par André C.

    CE QU’IL Y A DERRIÈRE LE HAUT-PARLEUR

    Le PSG 8912, circuit intégré complexe, génère des sons sur la base de 14 paramètres qu’il faut lui fournir. Ce sont surtout les 6 premiers paramètres (en fait 3 paramètres sur 2 octets chacun) qui nous intéressent aujourd’hui. Ils définissent la période des sons qui seront respectivement générés par les canaux 1, 2 et 3.
    Lorsqu’on veut programmer des sons en langage machine, il faut envoyer ces 14 paramètres aux 14 registres du PSG 8912 à l’aide de la routine #FA86 (Atmos), après avoir renseigné X et Y pour qu’ils pointent sur l’adresse où se trouve le bloc des 14 paramètres. Heureusement ces 14 registres sont latchés (verrouillés) et gardent leur valeur tant qu’on ne la remplace pas par une autre. La plupart du temps il y a donc peu de changements et il est possible de modifier un seul registre à l’aide de la routine #F590 (Atmos), après avoir renseigné A avec le n° de registre (de 0 à 13) et X avec la valeur à y placer (A, X et Y sont les registres du microprocesseur 6502).

    VOUS PRÉFÉREZ LE BASIC ?

    Il n’empêche que le PSG 8912, ce n’est pas de la tarte, avec ses 14 paramètres dont certains sont complexes ! Mais les commandes PLAY, MUSIC et SOUND simplifient la vie de ceux qui sont effrayés par le langage machine. Le bel effort, qui a été fait pour programmer les commandes PLAY, MUSIC et SOUND, est handicapé par la pauvreté des manuels. A ce propos, je vous renvoie à l’excellent article “PLAY, MUSIC, SOUND”, paru dans le CEO-mag d’avril 2000, n°119-120, pages 35 à 39.
    Toujours est-il que ces 3 commandes Basic permettent de mettre en œuvre assez facilement les paramètres du PSG 8912.

    MUSIC

    Dans le cas de MUSIC, par exemple, il suffit d’indiquer le canal à activer (1 à 3), l’octave (0 à 7), la note (1 à 12) et le volume (1 à 15 pour le volume sonore ou 0 pour passer la main au contrôle par une enveloppe). Quoi de plus simple ? Soit dit en passant, la syntaxe de ce dernier paramètre est regrettable. Pourquoi ne pas avoir repris les valeurs qu’accepte directement le PSG 8912, à savoir 0 à 15 pour le volume et 16 (#10) pour le passage de contrôle à une enveloppe ?

    SOUND

    Mais MUSIC a les inconvénients (les limites) de son avantage (la simplicité) : Cette commande ne sait produire aucun son en dehors des notes standards. Pour ce genre de sons, il existe la commande SOUND, pour laquelle il faut indiquer le canal (1 à 6 avec 1 à 3 pour le canal et 4 à 6 pour ajouter du bruit blanc aux canaux 1 à 3), la période (de 0 à 65535) et le volume (idem MUSIC).
    Pas top la syntaxe du 3e paramètre (période). En français la hauteur d’une note est définie par sa fréquence. On ne parle jamais de la période d’une note. L’utilisation de la période était probablement plus simple d’un point de vue programmation, mais elle est contre culturelle et pas du tout intuitive (plus une note est haute plus sa période diminue).
    Toute valeur entre #0000 et #FFFF (0 et 65535) est acceptée et la valeur que l’on indique est directement envoyée au PSG 8912. Mais celui-ci ne prend pas en compte les 4 bits supérieurs de l’octet de poids fort. Les valeurs réellement injectées dans le PSG sont ra menées à l’espace #0000 à #0FFF (0 à 4095 en décimal). L’intervalle de 0 à 65535 est donc illusoire (mais les capacités du PSG 8912 et celles de l’oreille humaine sont quand même largement couvertes).

    PERIODE

    La période (en secondes) est l’inverse de la fréquence (en Hertz). En pratique, pour avoir des valeurs manipulables, on exprime la période en µs. Pour ce faire, il faut diviser 1 000 000 par la fréquence (il y a un million de µs dans une seconde). Par exemple pour le LA de l’octave 3 (le diapason qui sert de référence en musique), la fréquence officielle est 440 Hz. La période correspondante est de 1 000 000 / 440 = 2 272,73 µs, une valeur qui n’est jamais mentionnée, ni utilisée.

    LE TRUC INVISIBLE

    Le truc qui n’est pas explicité dans les divers documents disponibles (et il y en a un paquet !) est que dans le cas du PSG 8912, la période n’est pas exprimée en µs, mais en unités de 16 µs (ça sent le système binaire là-dessous). Il faut donc appliquer un facteur de conversion de 62 480 (car 1 000 000 / 62 480 = 16,00512164). Dans le cas du LA de l’octave 3 (440 Hz) la période exprimée en unité de 16 µs est de 62480 / 440 = 142 (soit #008E en hexadécimal). Les amateurs de langage machine pourront vérifier que #008E est bien la valeur indiquée dans la Rom par les tables de conversion en #FC5E (octet de poids fort) et #FC6B (octet de poids faible). Et c’est bien la valeur 142 qu’il faut indiquer à la commande SOUND pour obtenir un LA de l’octave 3.

    POUR EN REVENIR AU PSG 8912

    C’est bien sûr #008E qu’il faut aussi indiquer au PSG pour obtenir ce même LA de l’octave 3. Par exemple, pour obtenir ce son sur le canal 1, il faudra placer #8E dans le premier registre et #00 dans le second. D’une manière générale, pour produire un son de fréquence F, il faudra placer dans les registres du PSG une valeur de période P = 62480 / F. Ce n’est pas si compliqué, encore fallait-il le dire clairement. En complément pour ceux qui seraient intéressé, une table de conversion “Note-Frequence-periode.pdf” accompagne cet article.

    Note-Frequence-periode.pdfTélécharger

  • Les enveloppes du PSG 8912

    par André C.

    Cet article fait suite à “PLAY, MUSIC, SOUND”, paru en avril 2000, dans le CEO-mag n°119-120 page 35 à 39. Mais il est plus particulièrement consacré aux enveloppes du PSG 8912.

    L’Oric permet de générer deux sortes de sons : Soit des sons continus dont on peut fixer (entre autre) le volume sonore, soit des sons complexes dont le volume évolue avec le temps selon un profil appelé “enveloppe”. Par exemple, l’enveloppe du fameux PING est une rampe descendante allant du volume maximum à zéro : \

    Problèmes de n° d’enveloppe

    Pour le registre “Numéro de l’enveloppe”, le PSG 8912 accepte des valeurs de #00 à #0F soit 16 possibilités (voir “L’Oric à nu” de Fabrice Broche, page 23). Mais certaines valeurs donnent des résultats identiques : d’une part #00, #01, #02, #03, #9 et d’autre part #04, #05, #06, #07, #0F. Cela ramène le nombre réel d’enveloppes à 8 (voir tableau page suivante).
    Mais 7 enveloppes seulement sont décrites dans le manuel de l’Oric-1 (page 111) et dans celui de l’Atmos (page 124). En fait les concepteurs de la commande PLAY ont fait un mauvais choix : La table pour de conversion des valeurs de 0 à 7 de la commande PLAY en valeurs de #00 à #FF à envoyer au PSG (soit : #00, #00, #04, #08, #0A, 0B, #0C et #0D) fait l’impasse sur l’enveloppe #0E, tandis que l’enveloppe #00 y figure (inutilement) deux fois ! (cf. “L’Oric à nu”, page 380).

    Problèmes de profils

    La forme de ces 16 enveloppes est un peu délicate à comprendre. Comme déjà indiqué, leur numéro va de #00 à #0F, soit en binaire, de 0000 0000 à 0000 1111. Ce numéro pilote en fait 4 paramètres correspondants aux bits b0 à b3 (actif lorsqu’ils sont mis à un) :
    ● Bit0 (HOLD) : Si 0 = répète indéfiniment le profil initial, si 1 = maintient (HOLD) indéfiniment le dernier son.
    ● Bit1 (ALT) : Si 0 = garde profil initial, si 1 = ALTerne front montant et front descendant.
    ● Bit2 (ATT) : Si 0 = ATTaque avec un front initial descendant, si 1 = ATTaque avec un front initial montant.
    ● Bit3 (CONT) : Si 0 = son limité dans la durée, si 1 = son CONTinu.
    En fait il n’y a que deux profils de base : Rampe descendante (ATT = 0, soit \) et rampe montante (ATT = 1, soit /). Le profil peut alors en rester là (CONT = 0) ou le son être prolongé (CONT = 1). Il y a deux manières de le prolonger : soit le dernier son est maintenu (HOLD = 1), soit le profil est répété (HOLD = 0). Enfin, si le profil est répété, il peut soit garder sa forme initiale (ALT = 0, la forme est répétée telle quelle et on a alors un résultat en dents de scie (//// ou \\\\), soit la forme est alternée (ALT = 1) et on a alors un résultat en \/\/\/ ou en /\/\/\ selon que l’on commence par un front descendant ou un front montant.
    Certaines enveloppes me laissent songeur (par exemple l’enveloppe #0B : rampe descendante qui se termine par un niveau sonore nul mais dont le niveau maintenu est haut ou à l’inverse l’enveloppe #0F : la rampe monte jusqu’au volume maximum, suivi par un niveau maintenu bas ! En fait ce niveau bas est inaudible et on est ramené à l’enveloppe #04 Le fichier ENVELOP.TAP qui accompagne cet article vous permettra d’étudier vous-même ce que cela donne. Dans cette démo, le PSG 8912 acceptant des valeurs de #00 à #0F j’ai retenu ces valeurs pour tester les 16 enveloppes. C’est le moment de vous faire l’oreille…
    Pour ma part, je suis arrivé à la conclusion suivante :

    n° pour
    le PSG    		n° pour PLAYDescription et profil
    #00 *0 & 1Rampe descendante puis arrêt \
    #04 *2Rampe montante puis arrêt /
    #083Répétition de la rampe descendante \\\\
    #0A4Rampe descendante, puis rampes alternées \/\/\
    #0B5Rampe descendante, puis plateau haut continu\ ͞
    #0C6Répétition de la rampe montante ////
    #0D7Rampe montante, puis plateau haut continu / ͞
    #0E **.Rampe montante, puis rampes alternées /\/\/
    Les différentes enveloppes gérée par le PSG 8912

    Note : Dans ce tableau, les numéros d’enveloppe à envoyer au PSG figurent en hexadécimal, tandis que les numéros destinés à la commande Basic PLAY figurent en décimal. Il s’agit seulement d’un artifice de présentation.
    Note *: Pour le PSG, les numéros d’enveloppe #00, #01, #02, #03 et #9 sont identiques. Idem pour les numéros #04, #05, #06, #07 et #15. Les enveloppes #09 \ _ et #0F /_ se terminent par un niveau bas continu donc inaudible et on est ramené aux enveloppes #00 et #04 respectivement.
    Note **: Cette enveloppe n’est pas accessible avec PLAY.

    Durée de l’enveloppe

    Dernière ombre au sujet des enveloppes : Le registre “Période de l’enveloppe” du PSG 8912. Ce terme de “période” entraîne une confusion avec le même terme utilisé pour la commande SOUND pour désigner la hauteur du son à générer.
    En fait, ce paramètre fixe la durée des enveloppes. Mais son usage n’est pas évident car sur les 8 enveloppes existantes, seules 2 ont une durée déterminée, les 6 autres durent sans fin (jusqu’à ce qu’on envoie de nouveaux paramètres au PSG).
    J’ai écrit plus haut “il n’y a que deux profils de base : Rampe descendante \ et rampe montante /” et justement le paramètre “durée” fixe la durée de ces rampes. Dans le cas où les rampes sont répétées sans fin, leur durée individuelle est celle indiquée par le paramètre “durée”.
    Dans “L’oric à nu” page 23, Fabrice Broche indique que ce paramètre “va de #0000 à #FFFF et qu’il faut multiplier par 16 pour avoir la période en µs, soit de 0 à 1 seconde environ”. En réalité, c’est par 256 qu’il faut multiplier. Comme tout un chacun peut le vérifier, la durée des enveloppes va de 0 à 16 secondes environ. Avec la durée maximum #FFFF, on a 65535×256 = 16776960 µs, soit un peu plus de 16 secondes. Et c’est bien cela qu’on obtient en pratique lorsqu’on envoie #FFFF au PSG 8912.
    C’est encore différent avec la commande Basic PLAY, qui permet (entre autres) de fixer la durée l’enveloppe à utiliser. PLAY accepte des valeurs de 0 à #7FFF (32767), ce qui génère des sons durant environ 16 s. Pour toute valeur supérieure à #7FFF, le PSG ne prend pas en compte le bit de poids le plus fort. Ainsi #8000 est ramené à #0000 et #FFFF est ramené à #7FFF, c’est-à-dire environ 16 s.

    Conclusion

    J’espère que cet article vous donne toutes les clefs pour utiliser des enveloppes dans la production de sons avec votre Oric. Il n’en reste pas moins que l’usage de ces enveloppes n’est pas évident et il faut tâtonner avant d’obtenir ce que l’on désire. Mais quel plaisir de combiner plusieurs enveloppes à la suite les unes des autres pour produire un son complexe, comme par exemple le lancement d’un missile, le sifflement de sa trajectoire et son explosion au contact de la cible ! Le PSG 8912 est un beau jouet, pour peu que l’on soit patient…

    Envelop.zipTélécharger

  • Temporisation en langage machine

    par André C. avec l’aide de Christian L.

    Cet article a été corrigé grâce aux indications précieuses de Christian L. “Assinie” concernant l’interférence des interruptions dans la routine TEMPOB. Qu’il en soit cordialement remercié.

    La commande Basic WAIT est une petite merveille de simplicité d’utilisation. Il suffit d’indiquer une valeur de temporisation en centièmes de secondes et pourvu que les IRQ ne soient pas inhibées, l’exécution du programme se fige pendant le délai indiqué. La valeur du délai indiqué doit être comprise entre 0 et 65535 (en pratique entre 1 à 65535), ce qui permet des temporisations de 0,1 à 655 secondes (presque 11 min donc). C’est plus qu’il n’est utile.
    La précision de WAIT est étonnamment bonne. Mais il n’est pas possible d’obtenir des délais très brefs, car la valeur minimale est de 100 µs, ce qui est beaucoup comparé aux 2 µs qu’il est possible d’obtenir en langage machine, en insérant un NOP dans un programme. En effet NOP (No OPeration) ne fait rien, mais ça prend 2 cycles de microprocesseur, soit 2 µs dans le cas de l’Oric. Moi quand je ne fais rien, ça prend quand même plus de temps, heureusement ça n’arrive pas souvent !

    Temporisation à boucle

    Dans la plupart des programmes LM ainsi que dans les routines de la Rom, les temporisations sont basées sur des boucles. Mais vous verrez qu’il y a peut-être mieux à faire.
    Voici le principe d’une temporisation à boucle :

    C’est simple non ? Mais si on veut calculer le délai correspondant à cette valeur 5, ce n’est pas si facile. En effet, il faut tenir compte du nombre de cycles de microprocesseur que prend chaque instruction.
    De plus, très souvent ce nombre de cycle n’est pas une valeur fixe, mais dépend du contexte. Ainsi si LDX et DEX sont des cas simples car nécessitant toujours 2 cycles chacun, c’est plus compliqué avec BNE où trois cas peuvent se présenter :
    ● 2 cycles si le branchement n’a pas lieu.
    ● 3 cycles si le branchement a lieu (cas normal pendant la boucle).
    ● 4 cycles si le branchement a lieu avec un changement de page mémoire.
    Si on fait un bilan pour l’exemple ci-dessus, on a 2 cycles pour LDX, plus 4 fois 2+3 cycles (2 pour DEY + 3 pour BNE avec branchement) plus 1 fois 2+2 cycles (2 pour DEY + 2 pour BNE sans branchement) on arrive à un total de 26 cycles, soit 26 µs pour l’Oric, qui tourne à 1 MHz. Le calcul précédent peut se formuler ainsi : Le délai vaut D = 5Y -1 + 2 ( 1 pour le dernier BNE sans branchement et +2 pour le LDX initial).
    Le délai maximum pour une simple boucle est obtenu avec Y=#FF et se limite à environ 1,3 ms. (D = 256×5 -1 + 2 = 1281 µs). C’est exactement ce code que l’on trouve dans la Rom en #FAE1 pour la durée de ZAP.

    Temporisation à 2 boucles

    Si on veut obtenir un délai plus long, il faut imbriquer deux boucles. C’est ce qu’a fait Fabrice Broche pour OUPS, le nouveau son préprogrammé du Telestrat :

    Essayons de calculer le délai produit par l’exécution de cette routine :
    ● Pour les LDY et LDX d’initialisation : 4 cycles.
    ● Pour la 1e boucle : D = 256×5 – 1 = 1279 cycles (-1 pour le dernier BNE de la 1e boucle). Notez que cette 1e boucle se termine avec X=0 donc X est régénéré à sa valeur initiale pour la suite.
    ● Pour la 2e boucle : D= 96(1279+5) -1 = 123263 cycles (avec 1279 pour l’exécution de la 1e boucle et -1 pour le dernier BNE sans branchement de la 2e boucle). Notez que le temps d’exécution d’un tour de la 2e boucle inclus celui de l’exécution totale de la 1e boucle.
    Au total on a donc 123267 cycles, soit 123267 µs pour l’Oric. La durée théorique finale de OUPS est donc de 0,123 s (sauf si je me suis planté). On voit aussi que l’on peut simplifier ce calcul car il y a quelques cycles négligeables, par exemple les LDY et LDX initiaux et la réduction de 1 cycle pour BNE sans branchement. On arrive alors à un délai D = 96(1280+5) = 123360 µs, soit une approximation de +0,08%.
    Le délai maximum que l’on puisse obtenir avec 2 boucles avec X=#FF et Y=#FF est d’environ 0,33 ms.
    Le calcul simplifié donne D = 256(1280+5)=328960 µs. Ça risque de n’être pas assez dans certains cas. On pourrait ajouter quelques NOPs (2 cycles à chaque fois) dans la 1e boucle qui est exécutée 256×256=65536 fois. L’exécution s’allongerait alors de 65536×2=131072 cycles par NOP ajouté, c’est-à-dire 0,13 s, ce qui n’est pas négligeable. Mais, par exemple, pour atteindre un délai total de 1 s, il faudrait 5 NOP (131072 x 5 = 655360 cycles supplémentaires plus 328960 cycles initiaux = 984320 cycles, soit environ 0,98 s). Mais il ne serait pas raisonnable d’aller plus loin en accumulant les NOP.

    Temporisation à 3 boucles

    Si 1 s ne vous suffit pas, il faut ajouter une 3e boucle en utilisant le 3e registre du 6502 : L’accumulateur A (il n’existe pas de DEA pour décrémenter A, mais c’est facilement contournable). La temporisation maximale possible est tellement grande que l’on peut ajuster finement les valeurs respectives de A, Y et X pour obtenir un délai en chiffre rond. En voici un exemple pour obtenir un délai de 40 s. J’ai choisi cette durée afin de chronométrer la durée obtenue.

    Cette structure des boucles est nécessitée par la réinitialisation des compteurs au début de chaque boucle. A l’issue de la 1e boucle, X est automatiquement réinitialisé à zéro. Toutefois, cette remise à zéro est perdue dans le cas de l’exécution de la 3e boucle et doit être repositionnée. D’autre part, l’exécution de la 2e boucle se termine avec Y = zéro. Si l’on veut utiliser une valeur initiale de Y différente de zéro, il faut également repositionner Y. C’est pourquoi la 3e boucle ne se termine pas par un BNE BOUCL1, mais avec un BNE BOUCL3.
    En faisant abstraction de la durée réduite des BNE de fin de boucle et de 6 cycles pour les LDA, LDY et LDX initiaux, on peut faire le calcul simplifié suivant :
    ● L’exécution de la boule X dure D = 256×5 = 1280 µs.
    ● L’exécution de la boucle Y dure D = 156(1280+5) = 200460 µs soit environ 0,20 s
    ● L’exécution de la boucle A dure D = 200(200460+9) = 40093800 µs soit environ 40 s.
    En ajustant les valeurs de Y et A il est possible d’obtenir la durée dont on a besoin. Il suffit de faire quelques calculs avec les formules ci-dessus.
    Durée maximale possible avec une temporisation à 3 boucles (hors ajout de NOPs) : 84 s
    ● L’exécution de la boule X dure D = 256×5 = 1280 µs.
    ● L’exécution de la boucle Y dure D = 256(1280+5) = 328960 µs soit environ 0,32 s
    ● L’exécution de la boucle A dure D = 256(328960+9) = 84216064 µs soit environ 84 s.

    Temporisation avec le Timer 2

    Vous vous rappelez la simplicité de mise en œuvre de la commande Basic WAIT ? Si on consulte “L’Oric à nu” page 186, on peut examiner ce que fait cette routine. Le paramètre qui suit WAIT (nombre de centièmes de secondes de délai) est analysé, puis placé en page zéro aux adresses #33 (LL de a valeur) et #34 (HH de la valeur). Le registre A est initialisé avec #02 (n° du timer à utiliser), puis le registre Y reçoit le contenu de la mémoire #33 et X celui de #34. La routine #EEAB écrit la valeur YX dans le timer 2, lequel est décrémenté tous les centièmes de secondes. On lit l’état du timer 2 avec la routine #EE9D et on sort quand il tombe à zéro.
    Voici un exemple qui permet d’obtenir un délai de 40 s :

    Quelques mesures

    Pour vérifier les exemples, j’ai comparé ce que donnent WAIT 4000, TEMPOB et TEMPOT avec un Atmos réel, un Atmos sous Euphoric+DosBox et un Atmos sous Oricutron 1.2. Voici les résultats :

    Atmos réelEuphoricOricutron
    WAIT 400040s42s41s
    TEMPOB40s42s41s
    TEMPOT40s42s41s
    Temporisations mesurées

    L’Atmos donne les valeurs escomptées pour WAIT 4000, TEMPOB et TEMPOT. Par contre Oricutron donne des valeurs légèrement plus élevées, mais qui restent dans la limite de la précision de mon chronométrage. Pour Euphoric, c’est encore plus marqué, mais peut-être est-ce dû à DosBox. J’ai déjà remarqué ce défaut de réactivité avec DosBox dans d’autres situations.

    Conclusion

    La temporisation avec le timer 2 est plus facile à mettre en œuvre que les temporisations à boucles et devrait être utilisée préférentiellement pour les délais de 0,1 à 655 s (comme WAIT). Il n’en reste pas moins que pour les petits délais une simple boucle permet de temporiser jusqu’à 1281 µs (et éventuellement deux boucles pour aller jusqu’à 0,33 s). Il n’y donc que l’embarras du choix quant à la méthode à utiliser !

    Disquette TEMPORIS.DSKTélécharger

  • Radar Oric 2

    Une seconde version quelque peu améliorée

    par André C.

    Comme indiqué dans le sous-titre, il s’agit d’une version améliorée de Radar Oric (voir le CEO-mag n°358, pages 4 & 5 et RadarOric.dsk dans le fichier 358.zip). Outre de nouvelles commandes, cette version comporte 48 nouvelles grilles réparties en 3 niveaux de difficulté (1 Fastoche, 2 Faisable et 3 Fortiche). Autre petit plus : Le jeu est maintenant bilingue Anglais et Français.

    Rappel du synopsis

    Votre QG est attaqué par une flotte ennemie et pour vous défendre, vous disposez d’un tout nouveau radar couplé à un ordinateur dernier cri : l’Oric. Votre tâche est de localiser exactement la position de tous les bateaux ennemis, puis de déclencher un feu apocalyptique qui les anéantira.

    Vitesse de déplacement du curseur

    A l’usage, il est apparu que Radar Oric pouvait être amélioré.

    Tout d’abord, le déplacement du curseur trainait beaucoup trop lentement dans les 100 cases de la grille. J’ai donc un peu revu l’algorithme du jeu afin de perdre le moins de temps possible. Cela a entraîné une redéfinition des labels à attribuer aux cases. Ces labels, sont maintenant passés de 1 à 9 :

    1 – Case vide

    2 –  De l’eau (et sans sous-marin par-dessous !)

    3 – Élément de bateau présent mais indéterminé ou hypothèse de présence d’un élément

    4 – Sous-marin

    5 – Extrémité “gauche” d’un navire

    6 – Extrémité “droite” d’un navire

    7 – Extrémité du “haut” d’un navire

    8 – Extrémité du “bas” d’un navire

    9 – Élément du corps d’un navire

    La nouveauté importante est l’ajout du label 3 qui permet de placer des hypothèses, ce qui n’est pas du luxe pour les grilles de “Fortiches”.

    Autre innovation pour accélérer les déplacements : les mystérieuses commandes H et V. En fait, elles n’ont rien de mystérieux. C’est plutôt que je n’arrivais pas à décrire ces commandes de manière concise dans mon écran d’instructions ! Les commandes H ou V éditent la ligne Horizontale ou la colonne Verticale où se trouve le curseur. Cette édition consiste à marquer toutes les cases de la ligne ou de la colonne avec le label 2 (de l’eau), sauf si une hypothèse ou un élément de bateau est déjà présent. Cerise sur le bateau, le compteur des coups joués n’est pas incrémenté : non seulement vous gagnez du temps dans le déplacement du curseur, mais vous améliorez  vos performances, qui je le rappelle sont la combinaison d’un score maximum ET d’un nombre minimal de déplacements.  En outre, vous réduirez vos déplacements  car le curseur reste à la position initiale, ce qui vous permet d’atteindre des cases distantes sans perdre de temps pour vous y rendre et pour revenir !

    Nouvelles commandes

    Le jeu comporte maintenant 7 commandes au lieu de 4.

    Outre le commandes H et V décrites ci-dessus et les commandes déjà présentes dans la première version (flèches de déplacement, numéros de label pour les cases, R pour reprendre au début la grille en cours et S pour sauver la partie en cours afin d’aller faire dodo), la nouvelle version offre la commande L qui permet de charger (Load) la partie précédemment sauvegardée. Dans la première version de Radar Oric, on ne pouvait choisir cette option que lors du lancement du jeu. Recharger la partie sauvegardée sort donc maintenant de son rôle initial (reprise de la partie le lendemain).

    En effet, au cours de la résolution d’une grille complexe, lorsque plusieurs possibilités s’offrent à vous, il est intéressant d’effectuer une sorte de point de restauration avec la commande S. Si la voie dans laquelle vous vous étiez engagée se révèle erronée, il vous suffit de restaurer l’état précédent avec la commande L et de tester une autre hypothèse. La commande R au contraire régénère la grille à son point de départ. Cette commande sert en principe à repartir sur un bon pied lorsque la situation est devenue trop embrouillée. Le score affiché est alors celui qui était présent lors du chargement initial de cette grille et non celui qui était acquis au moment “du point de restauration”. J’espère que vous apprécierez la meilleure jouabilité de Radar Oric 2 et que ce petit jeu de réflexion vous apportera quelques moments agréables…

    RADAR2.DSKTélécharger

  • Des programmes pour votre Oric

    de Michel Piot, Cedic/Fernand Nathan (1983)

    Des nouvelles de la Librairie Oric de CEO

    Notre Librairie Oric compte environ 80 livres en Français, Anglais et Espagnol, mais malheureusement, à ma connaissance, aucun en Allemand, ce qui est fâcheux pour nos cousins germains. Les ouvrages  les plus importants y figurent, grâce au dévouement de Jérôme et de Didier, sans oublier ceux qui ont envoyé des livres ou des scans. Mais il en manque encore pas mal et nous comptons sur vous pour contribuer à enrichir cette collection. L’ouvrage présenté aujourd’hui m’a été transmis par quelqu’un ayant appris indirectement que je m’intéressais à l’Oric. Comme quoi toutes les voies sont bonnes ! Je l’ai donc scanné et OCRisé et il est maintenant disponible en téléchargement :

    Des-programmes-pour-votre-Oric-OCR.pdfTélécharger

    Comment accéder à la Librairie du CEO?

    L’url https://oric.bqtt.net/doku.php?id=private:librairie n’est plus valable, mais la page https://ceobeta.oric.org/doku.php?id=private:librairie est encore active. Je suppose que son équivalent définitif sera bientôt mis en ligne. En effet, La refonte en cours du site oric.org et de la page du CEO est un énorme travail et vous comprendrez qu’il entraîne forcément quelques inconvénients. En cas d’urgence, vous trouverez tous ces livres sur mon site.

    Des programmes pour votre Oric

    Il s’agit d’un livre d’initiation à l’Oric-1 comportant 24 petits programmes d’application.

    Pratiquement tous les éditeurs ont publié ce type de bouquin et même souvent plusieurs (avec les mêmes auteurs ou avec des auteurs différents). A l’époque, il devait donc s’agir d’un marché juteux. La plupart du temps ces livres ont été publiés dans l’urgence lors de la sortie d’un nouvel ordinateur. La concurrence entre les maisons d’édition était féroce. Il en a hélas résulté que nombre de ces livres ne sont pas d’une qualité transcendante. Cependant, la bibliothèque du CEO se veut d’être exhaustive, autant que possible, et il fallait donc faire une petite place pour le livre de Michel Piot.

    Le contenu de ce livre

    Il est maigre : 120 petites pages, dont en annexe, les codes Ascii et les attributs ! Ces deux annexes font grise mine à côté de celles, abondantes et bien faites, du manuel de John Scriven, livré avec l’Oric-1 (téléchargeable dans la librairie du CEO).

    Le coté initiation se fait au fur et à mesure des programmes proposés. L’auteur a cherché à utiliser un maximum de commandes Basic pour en illustrer l’emploi. Etant donné la faible épaisseur du livre, Michel Piot aurait pu développer un peu le chapitre 15 “Le Basic de l’Oric” du manuel de John Scriven.

    Pendant que j’en suis aux récriminations, les illustrations (des photos de l’écran réel) sont souvent illisibles. Enfin, les listings sont issus d’une imprimante à aiguilles et certaines lignes sont réfractaires à toute OCRisation. Je doute qu’il soit possible de récupérer un listing utilisable. En règle générale, on est toujours obligé d’apporter des retouches aux listings issus d’une OCRisation, mais là, ça ne me semble pas rentable.

    Je vais être plus positif avec les 24 programmes proposés qui sortent souvent des sentiers battus habituels (chenille, pendu etc.) et on peut y trouver quelques belles idées qui pourraient servir de point de départ pour un développement plus conséquent… Je vous laisse le soin de les explorer…