WordPress

Category: Basic

  • Fut’Oric

    Fut’Oric est un jeu de chiffres de type Futoshiki ce qui veut dire “non égal” en japonais. Il est conçu pour Atmos (c’est-à-dire pour la Rom 1.1 + Sedoric).
    Le programme est au format dsk et peut être utilisé avec un Atmos réel + Microdisc ou avec un Atmos émulé par exemple avec Euphoric. Mais pas avec Oricutron à cause d’une double bogue :
    1) Oricutron retourne le code 166 (#A6) au lieu de 165 (#A5) lorsque la touche FUNCT est pressée.
    2) Le “stick mode” ne marche pas pour la touche FUNCT. Même en modifiant le programme pour qu’il détecte le code #A6 au lieu de #A5, cela ne marche toujours pas car le “stick mode” est indispensable. Il faut donc attendre qu’Oricutron soit débogué…

    L’objectif est de remplir toutes les cases d’une grille avec des chiffres, de telle manière que chaque ligne et chaque colonne soient remplie de chiffres différents. C’est donc un jeu du style Sudoku, mais avec trois différences majeures :
    1) Les chiffres indiqués initialement sont moins nombreux.
    2) Cette réduction du nombre d’indices a été compensée avec l’apparition de quelques signes “inférieur à” et “supérieur à” placés entre certaines cases. Ces symboles < et > indique la relation entre les cases adjacentes.
    3) Les dimensions de la grille peut aller de 4×4 à 9×9 cases (en théorie, car cela devient vite trop compliqué au-delà de 6×6 cases).

    Dans cette adaptation bilingue (Français et Anglais) pour Oric, trois niveaux de difficulté vous attendent :
    1) Fastoche : avec 16 grilles de 4×4 cases à remplir avec les chiffres de 1 à 4. Ce niveau est surtout pédagogique, car ces grilles peuvent être aisément résolues.
    2) Faisable : avec 32 grilles de 5×5 cases à remplir avec les chiffres de 1 à 5. Ces grilles sont les plus intéressantes, car elles sont bien équilibrées entre difficulté et intérêt.
    3) Fortiche : avec 16 grilles de 6×6 cases à remplir avec les chiffres de 1 à 6. Elles vous demanderont probablement beaucoup de patience et de matière grise… avant de parvenir à les résoudre ! Les commandes sont simples et réduites au minimum :
    1) Les 4 flèches pour vous déplacer dans la grille.
    2) Un chiffre (de 1 à 4, 1 à 5 ou 1 à 6 selon la taille de la grille).
    3) FUNCT + chiffre pour placer une hypothèse.
    4) Chiffre 0 pour effacer une case.
    5) La touche R (Reset) pour recommencer la grille en cours.
    6) La touche S (Save) pour sauvegarder la grille en cours.
    7) La touche L (Load) pour recharger la grille précédemment sauvegardée.
    8) La touche B (Bruit) pour valider ou arrêter le clic de la touche FUNCT.
    9) Et pour finir, la touche Q (Quitter).

    Toutes les grilles ont évidemment une solution et peuvent être résolues avec un peu d’observation et de logique, sans avoir besoin d’y “aller au pifomètre”. La possibilité de placer des hypothèses dans les cases devrait vous aider dans les cas complexes.

    PS. Ce programme est également disponible sur http://andre.cheramy.net/oric.htm  Ce site contient notamment une section téléchargement très étoffée. Vous y trouverez tous mes programmes, des trucs et astuces, quasiment tous les livres connus sur l’Oric et le 6502, tout ce qui concerne le Super-Oric, etc. Hélas, il y a aussi plein de choses périmées ou pas mises à jour (merci pour votre compréhension, selon la formule usuelle débile). J’entre dans un âge avancé et il se pourrait que mon site disparaisse sans prévenir. Je vous invite donc à récupérer tous ce qui pourrait vous intéresser.
    Bien cordialement à vous tous.

    FutOricTélécharger

  • Rapid’Oric

    Un jeu de puzzles logiques pour Rom 1.1 et Sedoric (Atmos réel, Euphoric ou Oricutron)

    par André C.

    Ce jeu a été inventé par Naoki Inaba sous le nom de “Nanba Burokku”. Par la suite, il a été renommé “Tectonics”, “Suguru” ou même “Number blocks”. La version Oric, adaptée aux possibilités de l’écran, bénéficie en outre d’une interface Français/Anglais.
    Le principe est simple : Le jeu se joue sur une grille. C’est la taille de la grille qui détermine la difficulté du jeu. Cette grille est divisée en zones de 1 à 5 cases, délimitées par des lignes épaisses. Le but du jeu est de remplir la grille avec des chiffres de 1 à 5 de telle manière que :
    1) Il n’y ait pas de chiffres identiques à l’intérieur d’une même zone.
    2) Il n’y ait pas de chiffres identiques dans les cases qui se touchent, même en diagonale.

    TROIS NIVEAUX DE DIFFICULTÉ POUR LA VERSION ORIC

    Les règles, qui sont simples, permettent au jeu d’être rapide, du moins pour le premier niveau de difficulté labellisé “Fastoche”. Ce niveau comporte 36 grilles de 4×5 cases pouvant être résolues en une à deux minutes chacune (ce qui vous occupera quand même pour un bon moment).

    Niveau “Fastoche”

    Les choses se compliquent avec le deuxième niveau “Faisable” dont les 24 grilles, comptent 9×5 cases. Ces grilles peuvent encore être résolues dans un temps raisonnable, mais le nom de “Rapid’Oric” que j’ai attribué à mon jeu commence à être un peu usurpé…

    Niveau “Faisable”

    Le troisième et dernier niveau “Fortiche” comporte 8 grilles de 11×9 cases et le jeu n’a plus rien de “Rapide”. Ces grilles sont réservées aux malades de la logique. Attention, vous risquez de vous arracher les cheveux (si vous en avez).

    Niveau “Fortiche”

    LES COMMANDES

    Pour résoudre ces grilles, vous disposez des commandes suivantes :
    -Les 4 flèches pour déplacer le curseur dans la grille.
    -FUNCT + flèche pour déplacer plus rapidement le curseur.
    -Touche de 1 à 5 pour placer un chiffre dans la case au curseur.
    -FUNCT + touche de 1 à 5 pour placer une hypothèse.
    -Touche 0 pour effacer la case au curseur.
    -Touche R pour Réinitialiser la grille en cours avec les valeurs de départ.
    -Touche S pour Sauver la grille en cours.
    -Touche L pour recharger (Load) la grille précédemment sauvée.

    UN PEU DE STRATÉGIE

    Il faut commencer par rechercher les zones ne comportant qu’une seule case, car elles ne peuvent contenir que le chiffre 1. Ensuite, vous pourrez peut-être trouver quelques chiffres dans les zones de 2 et 3 cases qui comptent forcément parmi les moins compliquées.
    Sinon, il faut rechercher les solutions les plus évidentes. Cette stratégie suffit en général pour les grilles “Fastoches”, c’est pourquoi elles sont si rapides à résoudre. Un peu plus de matière grise et de temps seront nécessaires pour les grilles plus grandes.

    Premier exemple, illustrant la progression des raisonnements logiques:

    Des extraits séquentiels d’une même grille sont rangés de gauche à droite

    On repère d’abord une zone mono-case et on y place le chiffre 1. Dans la zone située en dessous, une seule case peut recevoir le chiffre 2. Par suite, la place du chiffre 3 est évidente. Du coup, dans la case du dessus, le chiffre 3 ne peut aller qu’à un seul endroit. Les positions du 4, puis du 5 ne posent alors aucun problème. Et ainsi de suite, jusqu’à résolution de toute la grille…

    Deuxième exemple, emprunté à une grille plus complexe:

    Les extraits successifs de cette grille sont rangés de gauche à droite, puis de haut en bas.

    Ici encore on commence par une zone mono-case qui reçoit avec plaisir le chiffre 1. Dans la zone de 5 cases située au-dessus, le 1 ne peut être placé qu’à un seul endroit. On en profite pour renseigner la zone bi-cases située encore au-dessus en y plaçant les chiffres 1 et 2. Intéressons-nous à la zone de 5 cases en croix située au milieu de l’extrait, car le chiffre 4 ne peut aller qu’à un seul endroit. Par suite, plaçons le chiffre 5, puis le 2 et enfin le 1.
    La bonne stratégie consiste à tourner autour de ce bloc central de cases résolues. C’est ainsi qu’on trouve où mettre les chiffres 1 et 2 dans les zones adjacentes. J’attire votre attention sur le chiffre 2 ajouté dans le dernier extrait.
    La stratégie illustrée dans ce cas vous sera souvent très utile lorsque le jeu semblera bloqué. On effet, si on fait le bilan de ce que cette case pourrait contenir, on voit que les chiffres 1, 3, 4 et 5 sont interdits (règle n°2) et donc que seul le chiffre 2 peut y être placé.
    Il arrivera évidemment que plusieurs chiffres semblent possibles (à un moment donné) pour une même case. L’utilisation de la touche FUNCT vous permettra d’y placer des hypothèses. Ne perdez pas de vue que les hypothèses ne représentent pas seulement des possibilités, elles permettent aussi de statuer sur le contenu éventuel des cases adjacentes.
    Toutes les grilles ont bien sûr une solution, n’en doutez pas.
    En toute bonne logique… la logique finira par triompher !

    Rapid’Oric version corrigéeTé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

  • 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

  • Solomon’s Key

    Le dernier acte (connu à ce jour) de la programmation multi-ordinateurs en basic par Dan Cresp, et un coup de chapeau à Dom

    Informations générales

    Après presque quatre ans sans programmer sur l’ORIC, quand Dan reprend la création de soft avec «Averno», il est tellement satisfait du résultat qu’il s’engage dans un autre projet encore plus complexe.

    AVERNO a été le premier jeu que réalisé en BASIC par Dan où le protagoniste passe en arrière-plan sans défauts d’affichage. Pour ce faire, Dan a placé la totalité de la zone de jeu dans une matrice texte et déplace le fantôme en reconstituant l’arrière-plan à partir des données de cette matrice. Le résultat est bon mais le coût de cette routine, ainsi que la maintenance de la matrice sont élevés. Le processus prend environ 10 secondes. Sur le plan graphique, l’utilisation de 3×2 caractères lui permettait de réaliser des graphismes presque identiques à l’original … monochromes.

    Par la suite, Dom sur oric-concours.forumactif.org a amélioré l’apparence du jeu en utilisant une propriété des attributs de couleur de l’écran permettant d’afficher les couleurs complémentaires des couleurs principales. Il a également amélioré la composition du niveau en enregistrant les écrans. Et pour simplifier l’ensemble, il a transféré le logiciel sur une disquette. L’on doit admettre que la version s’est améliorée et que son apparence est meilleure. Bravo !!!

    Avec Solomon’s Key, Dan va un cran plus loin dans la conception de l’écran.

    Un écran titre alléchant !

    Sprites
    Cette fois, Dan a voulu expérimenter une utilisation améliorée des «sprites», sans avoir à monter l’usine à gaz de la matrice écran, et insérer directement des valeurs 16 bits dans la mémoire vidéo à l’aide de l’instruction DOKE, qui affecte l’adresse de mémoire indiquée et la suivante.

    Dan n’avait pas réussi à mettre en oeuvre ce processus auparavant même si au final, il est assez simple. Brièvement, chaque image-objet a une taille de 2×2 caractères. Avant de placer une image-objet à l’écran, Dan enregistre la valeur de 2×2 caractères où elle sera insérée dans deux variables numériques. Ceci est fait avec un DEEK, qui est un PEEK 16 bits (à l’image du DOKE qui est un POKE 16 bits). La position de l’image-objet est une adresse mémoire et non deux coordonnées. Avec deux DOKE, il copie rapidement le sprite sur l’écran. Avant de le déplacer, Dan remplace l’arrière-plan à la position correspondante à partir de la valeur stockée dans la variable numérique, modifie la position de l’image-objet, enregistre l’arrière-plan dans la variable, puis le place dans la nouvelle position à l’aide des deux clés. Le résultat est là, efficace.

    L’écran
    Sur ZX-Spectrum, le jeu original a une largeur d’écran de 32 caractères. Deux pour les marges et 15 blocs de 2×2 caractères. Pour que cette version ait le même aspect, Dan aurais dû utiliser des blocs 3×2, mais avec l’ORIC, il est limité à 38 colonnes, loin de son besoin de 47. De fait, Dan a été contraint à réduire la taille des sprites à 2×2. De plus, les caractères de l’Oric font 6 pixels au lieu des 8 habituels. L’aspect final est de fait moins fouillé, mais avec des graphiques rapides mis en oeuvre avec les 2 DOKE.

    Comme la largeur de l’écran comporte plus de caractères, Dan a placé une colonne de blocs des deux côtés de l’écran et une colonne inférieure. Cela l’a également aidé à contrôler le déplacement des éléments mobiles du jeu.

    Dans le code, sur les lignes 440 à 455, trois lignes calculent quel bloc de fond doit être placé dans une zone de l’écran quand un bloc bleu est supprimé, et lorsque l’on prend la clé ou une pièce de monnaie, ou encore quand un ennemi frappe.

    Graphiques
    Le jeu de caractères ORIC ne comporte que 128 caractères. Dan souhaitait conserver les lettres, les chiffres et certains caractères spéciaux, Il a donc redéfini le minimum de blocs graphiques possibles. L’utilisation de deux caractères en largeur de bloc au lieu de trois a contribué à cet objectif. L’impact principal de ces options a été la suppression du mouvement de jambes de notre personnage ; mais cela a également permis de simplifier quelque peu le code et à améliorer les performances. Dan peut toujours tout montrer avec deux simples DOKE.

    Et comme toujours avec les programmes développés par Dan sur ORIC, les graphiques ont dû être redessinés par rapport à la version initiale car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice 8×6 soit 12 pixels horizontaux au lieu des 16 habituels.

    Les couleurs … encore un problème !
    En raison de la façon dont l’Oric gère les attributs, Dan a choisi de créer Solomon’s Key en monochrome, avec un peu de couleur dans la présentation et dans les marqueurs. Pour mettre en évidence les briques que nous pouvons détruire, Dan a appliqué la technique consistant à utiliser les couleurs complémentaires des deux couleurs principales en ajoutant 128 au code ASCII du personnage (les caractères inversés). permettant d’afficher 4 couleurs sur l’écran de jeu.

    L’encodage des niveaux
    A ce stade, nous arrivons à la création de l’écran. Chaque écran est constitué d’une matrice de 12 lignes et de 15 colonnes. Dans chaque colonne se trouve un tableau de caractères 2×2, tel que des blocs de pierre, des portes, des clés ou des pièces de monnaie. Dan a choisi de coder les niveaux en utilisant un format similaire à «Averno» simplifié.
    La présentation du niveau prend environ 6 secondes et le codage est effectué comme suit:

    • Une lettre entre “A” et “Z” a une valeur comprise entre 1 et 26 et correspond aux blocs de pierre à afficher. Alternativement, ils apparaissent en jaune ou en bleu.
    • Un caractère “*” signifie qu’il modifie le type de bloc de pierre indiqué, bleu ou jaune.
    • Une lettre entre “a” et “z” a une valeur comprise entre 1 et 26 et correspond à des blocs vides de 2×2.
    • Un caractère “.” Désigne un bout de la ligne en sautant au suivant.
    • Un caractère numérique correspond à un objet:
      • 2 portes,
      • 3 clés,
      • 4 devises,
      • 6 têtes et
      • 7 canaux.
      • 1, et 5 correspondent aux blocs de pierre jaune et bleue.
    Un écran de jeu de Solomon’s Key, avec l’aperçu de son encodage graphique

    Le contrôle du personnage
    Une des premières difficultés à résoudre avant de commencer à développer le jeu était de savoir comment gérer les différents mouvements et actions que le joueur pouvait faire. La programmation du jeu en Basic prend en compte l’impossibilité d’appuyer sur plusieurs touches simultanément.

    • Appuyez sur “Z” et “X” pour déplacer le magicien à gauche ou à droite.
    • En appuyant sur “P” nous sautons. S’il y a un bloc au-dessus, nous le cassons. Sinon, nous pouvons augmenter la hauteur d’un bloc. Si pendant que nous sautons, nous appuyons sur une flèche, nous irons dans cette direction.
    • En appuyant sur “L” nous insérons ou supprimons un bloc bleu. Si nous sommes juste au-dessus d’un bloc, nous le placerons devant et si nous ne le plaçons pas au niveau du sol.

    Les Ennemis
    Contrairement au jeu “Averno”, dans ce “Solomon’s Key”, il y a des ennemis et ils bougent !
    Dan a mis en place une routine très basique qui permet de déplacer jusqu’à cinq ennemis avec deux vitesses différentes (des déplacements de un ou deux caractères), leur déplacement est horizontal ou vertical, et simule l’effet de rebond ou non lorsque vous touchez un mur, en détruisant les blocs bleus touchées. Le tout en sept lignes de code !

    Le type de mouvement de l’ennemi et sa position initiale sont définis dans les DATA de la ligne 9600. Chaque ennemi requiert trois caractères :

    • le premier indique le type
    • les deux autres la position initiale horizontale et verticale. Pour les positions, Dan utilise des lettres afin d’indiquer des valeurs supérieures à un chiffre avec un seul caractère.

    La routine de mouvement contrôle le nombre d’ennemis dans ce niveau. Moins il y a d’ennemis, plus ils se déplacent fréquemment et rapidement.

    Les sprites des ennemis se déplacent également sur le fond sans le supprimer. Comme pour le sprite du protagoniste, la technique de sauvegarde du personnage qui était à l’écran avant d’utiliser l’ennemi sur l’écran a été utilisée. Lorsqu’il se déplace, il reconstitue l’arrière-plan, sa nouvelle position est recalculée, puis le graphique de l’ennemi est placé.

    Résultat final
    En ce qui concerne la vitesse, l’ORIC BASIC pourrait être placé dans le milieu de gamme des ordinateurs 8 bits. C’est l’un des plus rapides en impression à l’écran, mais pour le reste, ce serait au niveau du MSX ou du ZX-Spectrum. Des ordinateurs tels que l’Amstrad CPC impriment très lentement à l’écran mais plus rapidement, en parallèle avec des ordinateurs tels que BBC Micro / Electron ou Lynx Camputers. La gamme basse reste pour le ZX-81 et surtout, le Texas Instruments TI / 99-4A qui mange séparément.

    Après toutes ces briques, je dois admettre que, malgré les limites imposées par ORIC BASIC, de par son apparence et ses performances, je suis très satisfait. Cela ressemble à un jeu commercial, mais c’est du BASIC pur et dur. Je pense que ce n’est pas habituel de regarder des programmes en BASIC comme celui-ci. Je pense que j’ai placé la barre très haut, mais avec l’expérimentation de ces techniques, je suis sûr que je ferai autre chose bientôt. En fait, au fond de moi, j’ai déjà l’idée d’adapter un classique qui n’existe pas dans ORIC.

    Eh bien, rien de plus, je ne peux qu’espérer que cela vous plaise …

    Je vous invite à l’essayer.

    Quelques éléments concernant le programme

    La routine principale du programme est divisée en 10 blocs:

    • Déclaration des variables et matrices et début du jeu.
    • Boucle principale de développement.
    • Mouvement des ennemis.
    • Mouvement du protagoniste.
    • Routines des actions du protagoniste.
    • Passer le niveau ou perdre une vie.
    • Routine pour montrer le niveau de jeu.
    • Présentation et début du jeu.
    • Charger UDG.
    • DATA avec les UDG du jeu et les valeurs de la matrice.

    L’ensemble du programme occupe 170 lignes dont vous trouverez ci-dessous les principales :

    • 5 – Nous définissons les variables du jeu.
    • 10 – Nous définissons les matrices du jeu.
    • 20 – Passez au sous-programme qui redéfinit les caractères et définit les variables globales.
    • 40 – Afficher le niveau à l’écran.
    • 100 – REPEAT indiquant le début de la boucle principale.
    • 105 – Vérifiez si nous sautons.
    • 110 – Si nous n’avons pas de terre sous nos pieds, le personnage tombe.
    • 115 – Prenez la touche appuyée.
    • 120 – Touche de saut.
    • 125 – Bloquer la touche marche / arrêt.
    • 130 – Touche de déplacement à droite.
    • 135 – Touche de déplacement gauche.
    • 140 – Vérifiez si le personnage frappe à la porte, à la clé ou à la pièce de monnaie.
    • 150 – Aller au sous-programme de mouvement ennemi.
    • 155 – Retournez à REPEAT si la variable U = 0.
    • 160 – Lorsque vous quittez la boucle, regardez la valeur de U. U = -1 niveau et U = 2 perd une vie.
    • 200 – Déplace le fantôme vers la droite.
    • 225 – Déplace le fantôme vers la gauche.
    • 300 – Contrôle la chute du personnage.
    • 320 – Détecte quel objet tu as sous le personnage.
    • 350 – Routine de saut.
    • 400 – Mettre / enlever le bloc.
    • 440 – Routine de remplacement en arrière-plan lors de la pose, de la suppression d’un bloc ou de la saisie d’un objet.
    • 500 – Routine pour passer un niveau.
    • 550 – Programme de perte de vie et fin du jeu.
    • 600 – Montre les marqueurs de points, de niveau et de vies.
    • 2000 – Routine qui montre le niveau. Les données sont encodées dans la matrice M $.
    • 2050 – Définissez le type, la vitesse et la direction des ennemis et placez-les à l’écran.
    • 2500 – Écran de présentation.
    • 3000 – Sélection des couleurs, effacement de l’écran, masquage du curseur et masquage des «CAPS» supérieurs.
    • 3005 – Lecture de données UDG.
    • 3010 – Définir des variables avec des bandes de caractères.
    • 9000 – DATA avec graphes, positions, blocs de graphes et codage de niveau UDG.
    • 9200 – Blocs graphiques utilisés par l’instruction DOKE.
    • 9300 – Position initiale du caractère en fonction de l’écran.
    • 9500 – Données de niveau.
    • 9600 – Données avec les types et la position des ennemis.

    Le Jeu !

    Solomon’s Key est un jeu publié par Tecmo en 1986 et concédé sous licence pour différents systèmes à partir de 1987. US Gold a commandé les versions 8 bits du jeu.

    Le jeu est de type plates-formes avec une pincée de jeu de stratégie. Nous y contrôlons un petit sorcier qui doit saisir une clé et sortir pour monter de niveau. Le magicien a la capacité de créer et de détruire des blocs bleus qui lui permettront d’atteindre la clé. Chaque niveau est plein d’ennemis qui te tueront au moindre contact. Le petit sorcier part avec 5 vies.

    La version développée par Dan utilise les mêmes mécanismes que le jeu original avec les 17 écrans de la version ZX-Spectrum, qui sont répétés indéfiniment. Le mouvement des ennemis est adapté aux limitations du BASIC.

    Contrôles :

    • Déplacez l’assistant à gauche ou à droite avec “Z” et “X”.
    • Appuyez sur “L” pour créer ou détruire un bloc bleu. Selon votre position, il sera créé devant vous à votre hauteur ou à une hauteur inférieure.
    • Appuyez sur “P” pour sauter, avec en plus la possibilité de contrôler la direction en appuyant sur “Z” ou “X”. Si vous avez un bloc en haut, vous le détruisez d’un coup de tête.

    Comparons …

    Comparaison des versions Oric-Atmos et ZX-Spectrum

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

  • PRINT@ et PLOT en mode HIRES

    par André C.

    Les commandes PRINT@ et PLOT sont rejetées en mode HIRES. On obtient le message d’erreur “?DISP TYPE MISMATCH ERROR“. C’est une limitation très fâcheuse pour utiliser la zone TEXT du bas de l’écran ! Et c’est un problème qui me titille depuis des années.
    Pour développer un jeu en mode HIRES, j’avais besoin d’exploiter les 3 lignes de la zone TEXT pour y afficher certains paramètres de l’évolution du jeu (messages, score etc.) et il fallait trouver une solution.

    Etat des lieux

    En mode HIRES, la zone TEXT fonctionne comme l’écran TEXT normal (mais hélas avec quelques limitations). Si les numéros de colonnes restent inchangés (X va de 0 à 39), par contre, les numéros de lignes sont restreints (Y va de 1 à 3). En mode HIRES, on peut observer ces valeurs en suivant le contenu des variables #0268 (numéro de ligne du curseur TEXT) et #0269 (numéro de colonne du curseur TEXT). Mais à quoi cela peut-il servir puisque les commandes PRINT@X,Y; et PLOTX,Y sont prohibées? C’est ce que nous allons voir.

    Pour la petite anecdote

    Il existe en RAM, entre la zone écran HIRES et la zone écran TEXT, une zone mémoire de 40 octets, inutilisée à l’écran, qui pourrait correspondre à une ligne numéro zéro (une sorte de ligne service inutilisée). Il s’agit peut-être d’un résidu de développement. Notons sur le plan pratique, qu’avec une routine appropriée, il serait possible de scroller la zone TEXT d’une ligne vers le haut (c’est à dire cacher la ligne numéro 1 en vue de la récupérer ultérieurement). Tout autre usage est également à recommander (par exemple stockage de variables ou d’un bout de code en langage machine). Comme en mode TEXT, le scrolling de l’écran vers le haut n’affecte pas cette “ligne 0”.

    Revenons à nos moutons

    Que faire pour afficher sélectivement au point X,Y ? Il n’y a pas 36000 solutions. Soit on arrive à repositionner le curseur en X,Y et le PRINT suivant se fera à partir de ce point. Soit on calcule l’adresse en RAM correspondant à ce point X,Y et on y POKE le code Ascii souhaité.
    La zone texte commence en #BF68. La formule est donc AD=#BF40+(#28*Y)+X avec Y de 1 à 3 et X de 0 à 39. Mais le problème n’est pas là. Pour afficher une chaîne de caractère, il faudra découper celle-ci avec la commande MID$ et en POKEr tous les code Ascii un à un. Idem pour les nombres qu’il faut d’abord transformer en chaine de caractères. Vous pouvez imaginer la lenteur de l’affichage !
    Reste donc la commande PRINT qui a la particularité d’afficher au curseur. Le problème est élémentaire mon cher Watson, il suffit de repositionner le curseur. En quelque sorte, la commande PRINT@X,Y; est scindée en deux :
    1) positionner le curseur en X,Y
    2) envoyer un PRINT.

    Positionner le curseur sur une ligne Y

    Je me suis demandé s’il ne serait pas possible de forcer la variable #0268 avec les valeurs 1, 2 ou 3 à l’aide d’un POKE. Zut, ça ne marche pas : l’affichage commence systématiquement sur la première ligne. Divers autres essais ne se sont pas révélés plus heureux.
    A la réflexion, ce n’est pas grave, car il suffit d’un PRINT pour passer à la ligne suivante et comme il n’y a que 3 lignes, c’est vite fait. Cette solution serait bien trop lourde en mode TEXT où il faudrait répéter 26 fois la commande PRINT pour placer le curseur sur la dernière ligne !
    Je rappelle en passant que PRINT”” (chaîne vide) ne fait rien sinon passer à la ligne suivante et que PRINT””; ne fait absolument rien (sinon valider des variables du système, mais c’est un autre sujet).
    Il est utile de se rappeler que la commande CLS nettoie la zone TEXT et repositionne le curseur au début de la première ligne. Elle peut être utilisée à tout moment, alors que les commandes PAPER et INK doivent être placées avant la commande HIRES si on veut affecter la zone TEXT. Sinon, elles affectent la zone HIRES.
    Attention, la zone TEXT est scrollée exactement comme en mode TEXT, mais comme ici on ne dispose que de 3 lignes, les infos fichent rapidement le camp vers le haut, notamment lors du retour au Ready. Seule solution pour contrôler ça : Utiliser un”;” à la fin des commandes PRINT.

    Positionner le curseur sur une colonne X

    Et que faut-il faire pour afficher à un endroit spécifique sur la ligne ?
    Ecartons tout de suite l’utilisation d’espaces pour atteindre la case ciblée, car ces espaces écrasent les informations situées à gauche de cette case.
    On pourrait évidemment remplacer ces espaces par des codes Ascii 9 (déplacement à droite). Mais imaginez-vous en train d’écrire PRINT CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9)CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9) CHR$(9)”OK” seulement pour afficher “OK” au milieu de la ligne !
    J’ai donc repris l’étude des variables du système.
    En page zéro, l’adresse #30 contient la position du curseur sur la ligne TEXT, mais la commande POKE#30,X ne modifie pas l’affichage.
    En page 2, la variable #0253 contient le numéro de la première colonne valide (et donc 0 ou 2), mais la commande POKE#0253,X ne modifie pas l’affichage. De toute façon, il me semblait farfelu de toucher à ce paramètre qui gère les 2 colonnes protégées.
    Après le #0268 qui n’avait pas marché, il me semblait peu probable que modifier la variable #0269 (numéro de colonne du curseur TEXT de 0 à 39) donne des résultats. Mais j’ai quand même testé.
    Divine surprise, un POKE#0269,10:PRINT”OK” affiche bien “OK” à la position X=10 de la première ligne de la zone TEXT. Un POKE#0269,12:PRINT”OK” envoie le “OK” sur la deuxième ligne. Enfin, avec un POKE#0269,14:PRINT”OK”; on voit apparaître le hoquet sur la troisième ligne (attention à ne pas oublier le “;” final). Ceci est illustré par la recopie du bas de l’écran ci-dessous et le programme correspondant.

    Affichage contrôlé dans la zone TEXT en mode HIRES
    Et le bout de programme qui permet de faire ça…

    Dernier point sensible, cette méthode ne permet pas la mise à jour automatique de l’affichage du curseur TEXT et mes essais laissent traîner des curseurs fantômes… Il est donc impératif de bloquer l’affichage du curseur en plaçant la commande suivante :
    POKE#26A,(PEEK(#26A)AND#FE):PRINT””:’ CURSEUR TEXT OFF dans le programme Basic, juste après la commande HIRES.
    NB. Cette commande éteint le curseur quelle que soit son statut antérieur, alors que : POKE#26A,(PEEK(#26A)OR#01):PRINT””:’ CURSEUR TEXT ON allume le curseur à coup sûr (dans un programme Basic complexe, l’utilisation répétée de la bascule PRINTCHR$(17) c’est-à-dire contrôle + Q est vite difficile à gérer, car on ne sait plus où on en est).
    La recopie du bas de l’écran ci-dessous et le programme correspondant donnent un exemple concret de pseudo PRINT@ en mode HIRES !

    Exemple d’application en situation réelle
    Et le bout de programme qui permet de faire ça…

    En conclusion

    N’importe laquelle des 120 cases de la zone TEXT est adressable individuellement. En fait, pas la 124e, qui n’est accessible qu’avec un POKE#BFDF,code Ascii sous peine de déclencher un scrolling.

    Coule, je vais pouvoir retourner au développent de mon jeu…

  • Averno

    Après une longue pause de programmation sur Oric, L’année 2019 démarre en fanfare avec ce nouveau jeu proposé par DanCresp, une pleine réussite qui a été traduite en Français quelque peu modifiée par Dom.

    Informations générales

    Dan a été presque quatre ans sans rien programmer pour l’ORIC. Comme le temps passe vite !
    Il est de retour, avec quelques nouvelles découvertes sur son système préféré.

    Cette fois, c’est une adaptation assez fidèle d’un jeu acheté pour MSX qu’il a apprécié, beaucoup aimé et qui a laissé chez Dan de bons souvenirs.

    Il existe des versions pour plusieurs systèmes, vous pouvez maintenant ajouter l’ORIC. Sur l’Oric, le jeu a un mécanisme identique à celui d’origine, mais avec quelques améliorations et quelques petites choses que Dan a laissées de côté. Il lui a fallu près d’une semaine pour réaliser une version jouable !

    Ecran titre de la version 2019 sur Oric

    Dan est très satisfait de cette version car le jeu a les mêmes niveaux que la version originale, la même résolution des niveaux et les performances du jeu sont identiques aux versions originales, voire un peu plus élevées … sauf pour la génération de l’écran.

    Les petites détails de la version ORIC
    Comme toujours pour la programmation dans l’ORIC, les graphismes ont dû être repensés car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice de 8×6. Comme les graphiques sont formés avec deux blocs de 1×2 caractères ou 2×2 caractères de 8×8 pixels, nous avons des blocs de 8×16 pixels ou 16×16 pixels.

    La solution choisie par Dan consiste à utiliser des blocs de 1 x 3 ou 2 x 3 caractères, de sorte que les blocs aient une largeur de 18 pixels et non de 16 pixels. Comme il ne pouvait pas utiliser de couleurs pour délimiter les blocs, l’auteur a laissé une bande de pixels vide au début. et à la fin de certains graphiques pour les rendre moins déroutants.
    Contrairement à la version d’origine, la porte et les clés ont toutes deux un masque pour mieux s’intégrer à l’arrière-plan.

    Lorsque sont placés les graphiques à l’écran, ils prennent presque toute la largeur de l’écran. Dan a donc supprimé certains marqueurs, le reste étant placé en haut, car l’ORIC comporte plus de lignes.

    Un autre problème a été le problème de la couleur, en raison de la façon dont il gère les attributs, Dan a dû produire un jeu en monochrome, en donnant toutefois un peu de couleur dans la présentation et dans les marqueurs. Dommage, mais très ORIC !

    L’écran du 1er niveau, en monochrome
    Le truc du mag, le fantôme ne peut monter que 2 marches à la fois … pensez y !

    A ce stade, nous arrivons à la création de l’écran. Chaque écran est constitué d’une matrice de 20 lignes et de 10 colonnes. Dans chacune des colonnes, il y a un graphique ou une partie de celui-ci, comme avec les portes et les clés. En codant de manière brute, une matrice de 13 (écrans) x 20 (lignes) x 10 (colonnes) aurait pu être créée. Au total, 260 lignes de code, avec la quantité de mémoire correspondante, de 600 octets par niveau. Au lieu de cela, l’auteur a choisi de coder les niveaux, chaque niveau étant compris entre 50 et 100 octets. La présentation du niveau prend environ 6 secondes et le codage est effectué comme suit, l’écran étant bleu:

    • Une lettre entre “A” et “Z” a une valeur comprise entre 1 et 26 et correspond aux blocs de briques de l’arrière-plan à afficher.
    • Une lettre entre “a” et “z” a une valeur comprise entre 1 et 26 et correspond aux blocs de pierre à afficher.
    • Un nombre compris entre 1 et 8 correspond à un bloc prédéfini stocké dans la matrice B $, en mettant ce qui entre dans la ligne correspondante.
    L’encodage des niveaux sur Oric

    Avec ce nouveau logiciel, Dan a découvert de nouvelles difficultés. Ainsi, c’est la première fois qu’en BASIC, il fait bouger le protagoniste sur le fond sans le supprimer. Pour ce faire, un deuxième processus doit être effectué, ce qui prend environ 10 secondes. Au cours d’une boucle double, Dan lit la mémoire d’écran et conserve les caractères à l’écran dans la matrice “S”. Pendant le processus de lecture de la mémoire vidéo, l’auteur crée un effet d’aveuglement qui change la couleur de la ligne en jaune final. Ce n’est pas du plus bel effet, mais c’est nécessaire pour déplacer le personnage rapidement.

    Le jeu original utilise des blocs cachés à plusieurs niveaux. Dan a découvert ce détail en regardant une vidéo alors que son adaptation du jeu était presque terminée et a choisi de les ignorer. Cela l’a obligé à faire quelques changements mineurs dans ces niveaux, car dans cette version, les blocs sont visibles. Cependant, ils n’affectent pas la résolution des niveaux.

    Pour contrôler le curseur, le clavier est lu à l’aide d’un «PEEK 520» ($208 pour les intimes), ce qui évite les problèmes de lettres majuscules / minuscules et vous garantit de toujours lire la dernière touche enfoncée, en accédant à la mémoire tampon du clavier.

    Et pour le son, une fois encore, Dan a utilisé les effets prédéfinis de l’ORIC, démontrant ainsi sa faiblesse dans ce domaine …

    Pour terminer, ayant respecté les niveaux d’origine, Dan trouve que la difficulté n’est pas linéaire et que les niveaux les plus simples se situent au début et à la fin de la partie. Mais comme le jeu original était comme ça, l’auteur l’ai laissé ainsi.

    Dan vous invite à l’essayer et espère que ce jeu vous plaira …

    Quelques informations à propos du programme

    Le programme est divisé en 10 blocs:

    • Déclaration de la matrice et début du jeu.
    • Boucle principale de développement.
    • Passer le niveau ou perdre une vie.
    • Mouvement fantôme.
    • Présentation et début du jeu.
    • Routine pour afficher le niveau.
    • Écran de victoire finale.
    • Préparez et montrez l’aire de jeu.
    • Charger UDG.
    • DATA avec les UDG du jeu et les valeurs de la matrice.

    L’ensemble du programme occupe 137 lignes.

    • 10 – Nous définissons les matrices du jeu.
    • 20 – Passez au sous-programme qui redéfinit les caractères et définit les variables globales.
    • 30 – Afficher l’écran de présentation.
    • 40 – Afficher le niveau.
    • 100 – Début de la boucle principale.
    • 105 – Prenez la touche appuyée. Si vous appuyez sur “Echap”, quittez la boucle et perdez une vie.
    • 110 – Mouvement fantôme selon la touche enfoncée.
    • 122 – Actualiser le repère temporel.
    • 125 – Voyez ce qu’il y a sous le fantôme, agissez en conséquence.
    • 135 – Mise à jour du temps, laissant la boucle si elle se termine.
    • 140 – Retournez à REPEAT si la variable U = 0.
    • 150 – Lorsque vous quittez la boucle, regardez la valeur de U. U = 1 pour passer le niveau ou U = 2 pour perdre une vie.
    • 155 – La routine de la mort
    • 200 – Déplace le fantôme vers la droite.
    • 250 – Déplace le fantôme vers la gauche.
    • 300 – Contrôle la chute du fantôme, surveillant s’il passe au-dessus d’une clé ou d’une porte.
    • 400 – Montre le fantôme. Avec D = 1, regardez à droite et D = -1, à gauche.
    • 420 – Routine de collecte de clés. Il met U = 1 si tous ont été collectés.
    • 450 – Actualiser le marqueur de temps.
    • 460 – Actualiser le marqueur de point.
    • 500 – Lancer un bloc de briques. Calculez la position du fantôme pour dire quel bloc devrait tomber.
    • 2000 – Écran de présentation.
    • 2100 – Routine qui montre le niveau. Les données sont encodées dans la matrice M $.
    • 2130 – Double boucle qui enregistre les caractères de chaque position sur l’écran dans la matrice D.
    • 2200 – Écran de fin de jeu à la fin du niveau 13.
    • 3000 – Sélection des couleurs, effacement de l’écran, masquage du curseur et masquage des «CAPS» supérieurs.
    • 3005 – Lecture de données UDG.
    • 3010 – Assemblez des matrices avec des bandes de caractères et des positions du fantôme.
    • 9000 – DATA avec graphes, positions, blocs de graphes et codage de niveau UDG.

    Le jeu

    Averno est un jeu publié pour plusieurs systèmes en 1989. C’est un jeu de réflexion dans lequel nous contrôlons un fantôme qui doit collecter toutes les clés du niveau pour ouvrir la porte. Vous devez ouvrir les 13 portes pour échapper aux dégâts. Nous devons éviter de manquer de temps ou de rester coincés.

    Le fantôme a la capacité de déposer des blocs de briques pour accéder à certaines parties du niveau ou de s’y placer, car il ne peut pas escalader les murs de plus de deux blocs de briques. Vous pouvez seulement déposer des blocs qui n’ont rien en dessous.

    Cette version suit exactement la même mécanique et les 13 écrans sont identiques au jeu original, sauf que les blocs invisibles ont été supprimés, ce qui n’affecte pas la résolution des niveaux.

    Contrôles :

    • Déplacez le fantôme vers la droite ou la gauche avec “Z” et “X”.
    • Appuyez sur “Entrée” pour déposer un bloc de briques, selon que vous êtes dessus ou partiellement dessus.
    • Appuyez sur “Echap” si vous êtes verrouillé. Vous allez perdre l’une de vos 5 vies.

    Une version française modifiée

    Dom, dont vous trouverez le post sur https://forums.oric.org/t694-enfer#8970 a amélioré le logiciel de Dancresp.

    • Utilisation de video inverse sur les tableaux
    • Ajout de l’enregistrement des High Scores
    • Ajout d’une ‘P’ Pause et d’une ‘S’ Sauvegarde (associées aux touches ‘1’ et ‘2’ de l’écran principal)
    • Transformation du .tap en .dsk
    • Corrections de bugs
    L’écran du 1er niveau, avec les graphismes en vidéo inversée
    L’écran de fin de jeu … qu’est ce que cela a été long d’attendre la fin des timers