WordPress

Blog

  • Interview: Hervé Lange, auteur du Secret de Kaïpur

    Le Secret de Kaïpur est probablement l’un des plus gros jeux d’aventure Oric sortis sur cassette. Il n’a pas connu un grand écho à l’époque, mais des années plus tard le soin apporté aux graphismes a retenu l’attention des Oriciens. Et c’est là que l’on découvre que son auteur n’est autre que Hervé Lange, auteur des succès Fer et Flamme sur Amstrad, et B.A.T. sur Atari ST et Amiga. Interview !

    – 8 août 2020 –
    CEO- Bonjour M. Lange. Pouvez-vous vous présenter en quelques mots ?

    Salut Simon, je m’appelle Hervé Lange. Je suis Français d’origine mais je vis actuellement au Canada où j’ai acquis la double citoyenneté, et je suis le papa heureux de trois enfants. Doué pour le dessin, passionné par les machines, j’ai toujours été intéressé par les possibilités de relier ces deux univers: le jeu vidéo m’est apparu tout naturellement comme un terreau propice d’une part à nourrir ce désir de mariage, et d’autre part pour pouvoir mettre en oeuvre mes propres histoires et réalisations. J’ai donc très tôt eu la chance de développer des histoires interactives et ce dès le début des années 1980 lorsque les micro-ordinateurs sont devenus accessibles au grand public, ce qui fait de moi une sorte de pionnier dans ce domaine. Par la suite, mon histoire est jalonnée de plus de 40 années de projets de jeux vidéo publiés ou abandonnés et d’outils numériques pour aider à la création numérique sur toutes sortes de systèmes, et la passion ne m’a jamais quittée !

    CEO- Quelle est votre histoire informatique, comment avez-vous décidé de vous lancer dans les jeux vidéo ?

    La découverte des micro-ordinateurs pour moi a commencé chez un ami dont le père avait pu se payer un TRS-80 avec lequel nous avons commencé à apprendre le BASIC. Il y a eu aussi le Centre Mondial Informatique à Paris ou j’ai pu m’essayer sur des ordinateurs Goupil ou Apple II en BASIC et en Logo. Puis en 1982 mes parents ont acheté un Oric 1 a mon frère que j’ai pu récupérer. J’ai rapidement commencé à coder des petits jeux par exemple pour amuser ma grande soeur. Mes programmes grossissaient et j’avais besoin d’une imprimante, alors je me suis rendu au magasin Vismo à Paris ou j’ai rencontré Philippe Derambure qui montait sa boite de jeux vidéo France Logiciel. Il cherchait des programmes de jeu et le courant a passé de suite dès qu’il m’a fait une ristourne sur le prix de l’imprimante :-), bref et je lui ai dit que je reviendrai avec un jeu en septembre sans savoir dans quoi je m’engageais. J’ai travaillé comme un fou pendant mes vacances scolaires sur ce programme: c’était le Secret de Kaïpur! De septembre à décembre 1984 j’ai terminé le programme avec l’aide de Philippe pour le publier.

    Jaquette du Secret de Kaïpur

    CEO- Outre « Le Secret de Kaïpur » qui nous a permis d’entrer en contact, êtes-vous l’auteur d’autres programmes sur Oric ?

    Ce jeu fut mon seul programme commercial sur Oric. J’adorai l’Atmos mais Philippe ayant fleuré l’ascension inéluctable de l’Amstrad CPC, il m’a procuré un 464 en me commandant un nouveau jeu pour cette machine et au plus vite – ce fut mon second jeu commercial: Le Bagne de Nepharia. A noter que Nepharia avait été pensé pour que je puisse le porter sur l’Atmos mais comme l’Oric déclinait, c’est malheureusement tombé à l’eau car France Logiciel ne pouvait pas engager des frais de duplication sans une garantie minimum de revenus.

    CEO- Même des programmes non commercialisés ?

    Pour des programmes non commerciaux, je me rappelle par exemple d’un programme de visualisation de la navette spatiale (genre CAO) et ou l’on pouvait faire apparaître ou animer vectoriellement différentes parties de la navette en appuyant sur différentes touches du clavier de l’Oric. J’avais aussi écrit un petit jeu d’arcade du doux nom de “Ant eater” ou le joueur incarnait une petite fourmi noire devant traverser des lignes de fourmis rouges voraces, un peu a la Froggy.

    CEO- Pouvez-vous nous raconter la genèse du Secret de Kaïpur ?

    Lorsque j’ai rencontré Philippe, j’avais déjà en tête l’idée de faire un jeu d’aventure qui s’inspirait des romans noirs. Mais les influences sont venues d’une part du film Indiana Jones et d’autre part du jeu Time Zone sur Apple II, et donc de combiner un aventurier au chapeau et des voyages dans le temps. D’ailleurs cette idée de voyage dans le temps a sûrement contribuée à la grosseur du jeu: c’était plusieurs jeux d’aventure pour chacune des époques qu’il fallait réaliser !

    CEO- Le jeu est crédité Hervé et Thierry Lange. Quelle a été la part de chacun ?

    Thierry m’a principalement aidé pour le texte du manuel; c’est moi qui ai conçu seul le jeu, le programme et réalisé tous les graphismes. Mais j’utilisais sa machine, alors en bon grand frère il m’avait donné un bon coup de pouce !

    CEO- Comment avez-vous conçu les superbes écrans graphiques, depuis l’idée jusqu’à leur concrétisation sur l’Oric ?

    Je faisais beaucoup d’esquisses au crayon puis directement en programmant les dessins un à un en BASIC, ligne après ligne! Mon choix de faire du vectoriel me permettait cependant de combiner des sous-routines du programme pour composer des scènes (par exemple avec les poses du héros), et en fonction également des interactions précédentes (objets pris ou pas, etc.), et l’utilisation mémoire mais probablement au détriment de la vitesse d’affichage. A noter que chez moi je ne disposais que d’une vieille télévision noir et blanc qui me faisait office de moniteur, et que c’est chez Philippe que j’ai pu disposer d’une télévision couleur pour ajouter un peu de couleur à mes dessins.

    CEO- Avez-vous souvenir de difficultés ou d’anecdotes particulières liées à la création du jeu ?

    Je me rappelle que l’Atmos est sorti alors que les cassettes venaient juste d’être dupliquées, et qu’il a donc fallu adapter le manuel pour régler un petite problème de compatibilité, heureusement réglable en écrivant un petit programme avant de lancer le jeu. C’est assez cocasse et ca montre bien le côté amateur de l’époque: vous vous imaginez maintenant devoir taper un petit programme avant de lancer un jeu !

    CEO- Comment avez-vous réussi à l’époque à faire éditer le jeu ? France Logiciel a-t-elle publié d’autres jeux Oric ?

    Une autre petite anecdote est que quand j’ai rencontré Philippe a Vismo, il a sorti son calepin pour prendre mon adresse et m’a montré les dizaines de jeux que des développeurs amateurs comme moi lui avaient promis, il y avait apparemment pas mal de compétition! En septembre on s’est revus dans une cafétéria (mon premier rendez-vous d’affaire !) et je lui avais amené le gros listing du jeu, pour lui montrer que j’avais fait le travail et fait bon usage de son imprimante. Philippe était super content car j’étais en fait le seul de son calepin à être revenu avec quelque chose, et il avait un programme de jeu à publier ! France Logiciel n’a publié que deux programmes Oric: le mien et un quizz de cinéma si je me rappelle bien, Philippe s’en rappellerait surement mieux.

    CEO- Combien de temps aura duré le développement du Secret de Kaïpur ?

    Le développement s’est étalé sur cinq mois de juillet à novembre 1984: deux mois à plein temps pendant les vacances scolaires où 80% du jeu a été écrit, puis les week-ends et les soirées pendant les trois mois restant vu que j’étais toujours étudiant – donc je dirais un gros trois mois à temps plein.

    CEO- Avez-vous conscience d’avoir écrit ce qui reste sans doute le plus imposant jeu cassette sur Oric ? (216Ko !)

    Pas du tout, c’est toi Simon qui me l’apprends !

    CEO- Le jeu a-t-il connu un grand succès, ou du moins le succès escompté ? (une idée du nombre d’exemplaires produits et vendus ?)

    Pas vraiment de succès mais France Logiciels était une petite structure et ne pouvait même pas se payer un petit encart de publicité dans les magazines de l’époque. Alors on comptait sur le bouche à oreille. Le Secret de Kaïpur s’est vendu à plusieurs centaines d’exemplaires, mais moi j’étais très content car je pouvais enfin me payer un moniteur couleur pour mes prochains jeux, et montrer a mes parents que mes nombreuses heures passées sur l’Oric produisaient quelque chose de tangible!

    CEO- Avez-vous eu des retours de joueurs à l’époque ?

    Pas du tout, on avait très peu d’informations une fois le jeu sorti, et c’est vrai même plus tard pour mes jeux CPC (à part les articles de presse bien sûr). Paradoxalement d’ailleurs et des décennies plus tard grâce à l’internet, j’ai plus de retours avec les retrogamers qui me posent des questions et me livrent leurs impressions!

    CEO- Avez-vous été ennuyé à l’époque par des problèmes de fiabilité des cassettes ? Aviez-vous envisagé une version sur disquette ?

    Oui souvent et c’était toujours un risque, et il me semble que l’on avait essayé divers types de magnétophones et de marques de cassettes pour trouver ce qui donnerait une garantie plus fiable à chaque sauvegarde. Il y avait une blague que Philippe faisait genre “t’es sûr que tu as bien enregistré avant que j’éteigne le bouzin ?”, ce à quoi je répondais “oui, oui c’est fait !”, et Philippe de dire: “ré-enregistre une fois de plus dessus, histoire que les bits soient bien bien incrustés…”, c’était récurrent et on en riait. On travaillait de chez nous et ma hantise c’était la panne d’électricité avant que le programme ne soit enregistré (on enregistrait peu car celà prenait du temps). Une fois à la campagne, ça m’est arrivé: une coupure de courant très brève qui avait avait laissé mon programme visible sur l’écran mais je ne pouvais plus rien sauvegarder – l’enfer – j’ai dû recopier ce que je voyais sur des feuilles de papier avant de redémarrer l’Oric et de retaper le programme en entier! A la fin du développement, Philippe avait acheté un lecteur de disquette Jasmin pour l’Atmos si je me rappelle bien, mais nous n’avons jamais envisagé de vendre le jeu sur disquette car peu de gens en avaient un.

    CEO- Le jeu contient quelques fautes d’orthographe (“Mommie”, “Jetter”). Est-ce qu’une version corrigée a existé ? (comme pour “Le Mystère de Kikekankoi” par exemple)

    Non pas de version corrigée à ma connaissance! D’ailleurs si j’avais pu faire ces correctifs, j’aurais sûrement voulu trouver un moyen d’ajouter des accents.

    CEO- Vous souvenez-vous de la logique de déplacement dans le Secret de Kaïpur, assez déroutante, où faire “nord” puis “sud” vous ramène parfois dans un lieu différent ?

    Je me rappelle que le jeu a été critiqué pour ça. En fait je pense que c’est mon erreur qui a mélangé certaines fois directions cardinales et directions relatives au personnage lors du codage du jeu, probablement pour réconcilier des incohérences de carte et de graphisme. A l’époque, on n’avait pas de testeurs, et donc la famille ou des copains curieux testaient les jeux sans oser contredire la logique parfois tordue de son créateur 🙂 Bref ce n’était sûrement pas le meilleur service de test !

    CEO- Pouvez-vous nous décrire un peu la société France Logiciel ? Y avait-il des salariés, des locaux ?

    Une toute petite compagnie, pas de locaux au départ et juste Philippe qui de son domicile s’occupait un peu de tout mais je crois était aidé par sa femme côté gestion financière. Des copains pour aider comme le dessin des jaquettes.

    CEO- Avez-vous gardé des contacts avec d’autres auteurs sur Oric ou avec des dirigeants de sociétés ?

    Pas sur la période Oric, mais plus mes anciens compagnons de Computer’s Dream avec qui nous avons fait les jeux BAT ou les anciens d’Haïku Studio. Sur Oric je me rappelle que j’avais rencontré avec bonheur Patrice Guerlais, l’auteur de l’excellent Lorigraph mais je ne l’ai pas revu depuis!

    CEO- Utilisez-vous encore un Oric (ou émulateur) de temps en temps, ou avez-vous tourné la page depuis longtemps ?

    J’ai un Oric 1, un Atmos et de nombreux jeux y compris des originaux mais j’ai perdu les câbles alors je ne peux plus les utiliser. J’ai le projet bien sûr de récupérer des câbles pour les refaire tourner et montrer ça aux enfants lorsque je trouverai un peu de temps libre pour ca!

    CEO- Gardez-vous un souvenir particulier de cette machine ?

    En réalité je n’étais pas super fan de l’Oric 1 avec ses 16 KB et son clavier de calculatrice. Quand l’Atmos est apparu disposant de plus de mémoire et surtout d’un clavier mécanique plus ergonomique à mon goût, je l’ai tout de suite adopté en espérant que tout le monde allait passer à ce modèle! Il y avait tout de même beaucoup de limitations sur ces petits 8-bits (pas uniquement l’Oric) comme le colour-clash de 8 pixels, mais comme c’est sur ces machines que j’ai réalisé mes premiers programmes, elles ont une place toute particulière dans mon coeur.

    CEO- Quel regard portez-vous aujourd’hui sur cette période ?

    C’était une période bénie de création ou l’on devait tout débroussailler ce qui nous donnait des opportunités d’innovation inouïe! On était les premiers auteurs d’un monde nouveau et on voulait juste faire des jeux, éventuellement gagner un peu d’argent pour pouvoir toujours continuer. Par ailleurs, la limitation des machines poussait les créateurs vers l’abstraction, le pixel-art, ce qui a produit selon mon opinion une diversité de styles riche et amusante… Loin des canons photoréalistes modernes.

    CEO- Avez-vous des réticences sur la diffusion (gratuite bien sûr) de vos softs Oric par le Club Europe Oric, ou sur Internet ?

    Aucune réticence, je suis plutôt flatté que vous portiez encore un peu d’intérêt à mon premier jeu commercial, alors c’est plutôt un grand merci à vous le Club Oric!

    CEO- Vos armoires renferment-elles des softs non diffusés, des sources, des cassettes oubliées, des photos de l’époque ?

    Peu de choses de l’époque Oric, mais un peu plus d’archives et des versions bêta de jeux non publiés par exemple sur PC CD-ROM de l’époque Haïku Studio. J’ai tout de même un original du Secret de Kaïpur, comme de mes autres jeux.

    CEO- Pouvez-vous nous en dire un peu plus sur votre parcours depuis ? Vous êtes célèbre notamment pour le jeu B.A.T.

    Par la suite j’ai réalisé plusieurs jeux sur Amstrad, Atari ST et Amiga sous le label Ubi Soft, dont les plus connus sont les RPG “Fer & Flamme” sur CPC et les jeux B.A.T. sur Atari et Amiga. En 1993 j’ai été cofondateur du studio Haiku Studio où nous avons produit des jeux sur PC et consoles pour différents éditeurs internationaux, avant sa fermeture en 1997. Puis j’ai travaillé sur différents projets innovateurs de storyboarder 3D exploitant les techniques plus accessibles du jeux vidéo pour le film, notamment pour la société Duran Duboi, puis en collaboration avec le réalisateur Marc Caro. Je suis revenu aux jeux vidéo lors de mon installation au Canada pour le compte de la société Behaviour Interactive où j’ai participé à la mise en oeuvre de jeux consoles et de jeux en ligne MMO, mobile et Facebook. En 2006 j’ai co-fondé xtranormal.com, une start-up de storytelling en ligne qui n’a pas résistée à la crise de 2008. Finalement je travaille depuis plusieurs années pour la société Autodesk sur des outils de modélisation et d’animation 3D pour les jeux et les films.

    CEO- Quelle période de votre carrière vous a rendu le plus heureux, ou vous rend aujourd’hui le plus nostalgique ?

    S’il faut n’en choisir qu’une c’est assurément la période juste après BAT1 où je n’avais plus d’obligations (plus d’école, plus d’armée) et je pouvais me consacrer à 100% sur mes créations. L’équipe de BAT venait de fonder un petit label du nom de Computer’s dream soutenu par Ubi soft, et je découvrais l’Amiga qui fût sans aucun doute la machine que j’ai préféré programmer toutes périodes confondues. On travaillait sur un nouveau jeu très original du nom de Xanathan pour l’Amiga, dont les premiers prototypes étaient superbes, et je commençais à implémenter des routines d’IA bien plus complexes, et ce pendant qu’une autre équipe développait BAT2 a partir de mon game design. Ce fût de courte durée et nous avons dû abandonner Xanathan à la demande d’Ubi pour nous porter au secours de BAT2 qui n’avançait pas.

    Cette photo résume très bien cette période:

    CEO- A quels hobbies vous consacrez-vous aujourd’hui ?

    Lorsque mes enfants me donnent un peu de temps, je continue à expérimenter de nouvelles techniques en faisant des petits programmes et surtout sur ce qui permettrait de résoudre la quadrature du cercle entre gameplay et storytelling. Comme dit précédemment, la passion ne m’a jamais quittée!

    CEO- Avez-vous des projets actuels dont vous souhaiteriez dire un mot ?

    Oui mais c’est trop tôt pour en parler 🙂 disons que je mets toujours un point d’honneur à finir ce que j’ai commencé et qu’il y a certains chantiers que j’aimerai bien boucler avant de n’en être vraiment plus capable!

    CEO- Quelque chose de particulier à ajouter ?

    J’aimerais en profiter pour remercier tous les retrogamers qui par passion continuent à faire vivre ou revivre nos vieilles machines et leurs logiciels. Bravo et chapeau bas a vous tous!

    Fin de l’interview.
    Un grand merci à Hervé, qui malgré ses nombreuses activités a pris le temps de répondre à nos questions !

  • Guide de mise à jour de la partie software de www.oric.org

    La mise à jour d’oric.org n’est pas restreinte à certaines personnes, chacun peut le demander afin de mettre à jour oric.org ou de mettre un nouveau soft. Voici un mini manuel de la mise à jour d’une fiche jeu. www.oric.org c’est 20 ans d’existence avec plusieurs contributeurs pour enrichir la base de données de soft oric.org. Si votre logiciel n’y est pas, c’est que soit nous n’en avons pas connaissance, soit c’est dans l’énorme TODO list

    Passer en mode administrateur

    Dans le bandeau rouge, quand on est authentifié, il y a un : Mode Admin : off

    Sur une fiche, un clic sur off permet de passer en mode administrateur pour modification et le formulaire s’affiche

    Sauvegarde des modifications

    Quand les modifs sont faites, il suffit de cliquer sur save.

    Sortir du mode administrateur

    Un clic sur ‘on’ du mode admin, on revient au mode normal, ce qui permet de voir les modifs.

    Création d’un nouveau soft

    Pour créer un soft, il faut bien s’assurer que le soft n’est pas déjà en doublon (cela peut arriver avec parfois des apostrophes dans le nom, le moteur de recherche ne trouvera pas categoric, mais en tapant categ, on le trouvera2)

    Upload de fichiers .tap ou dsk

    Il n’est possible d’uploader que 2 fichiers .tap dans la section download, le reste doit être uploadé dans stuff en bas

    Ces 2 uploads sont en général utilisés pour gérer le .Tap atmos et le .tap oric-1,

    Chaque download a besoin de flags pour définir ce que contient le .tap, cela fonctionne avec le tableau platform qui connait les flags, ensuite il suffit de le mettre dans chaque champ : “Flags du download”.

    Ainsi si la valeur est AKX, cela veut dire que c’est pour atmos, c’est une cassette, et fonctionne en 48K.

    Le champ ‘platform’ définit ce que le logiciel gère globalement (il a été sorti sur oric-1, atmos sedoric et jasmin par exemple). Ensuite, pour chaque download, une case “flags” existe pour bien définir à quoi correspond ce download.

    Les .tap doivent être dézippés s’ils ne contiennent qu’un fichier. Idem pour les dsk. Si le soft dispose de plusieurs parties en .tap, il est préférable de faire qu’un seul fichier tap, sinon il faudra zipper. Cette partie est importante parce que c'est celle ci qui fait foi pour la construction des bases de données locales du loader Orix. Se référer à : https://oric.bqtt.net/rom-atmos-pour-twilighte-board-demystification/

    Mapping des joysticks

    Pour la partie joysticks, ce sont les codes ascii des touches pour les joysticks. La plupart des jeux ne gèrent pas les joysticks, mais avec orix, la twilighte board et la rom basic11 permettent de jouer à ces jeux avec des joysticks : https://orix.oric.org/twilighte-board-v0-6-user-manual/. Ces champs permettent de faire le mapping entre les directions des joysticks et le clavier. Ces champs ont une action directe sur la génération des configurations de la rom basic11 de la twilighte board. une modification se répercute donc dans les releases des binaires Orix sur la définition de ces soft.

    Mapping des roms

    La partie ROM affichée est aussi liée à la twilighte board, il faut définir quelle ROM doit être prise en compte. En théorie, il n’est pas nécessaire d’y toucher.

    See Also

    Le “see also” peut faire “planter” la fiche du logiciel courant si on ne respecte pas la norme id1#id2. Cela permet par exemple de lier tous les traitements de textes entre eux pour passer de l’un à l’autre si on cherche un traitement de texte, idem pour les jeux “kong” ou chess etc

    Vidéo youtube

    Il est possible de mettre un lien vers youtube pour voir le jeu en vidéo. Il suffit de mettre le hash de la vidéo qui est sur youtube

    Screenshots

    Les screenshots ne doivent être qu’en PNG (ou gif).

    Le format bmp ne doit pas être utilisé à cause de sa lourdeur et surtout car le système ne sera pas capable de générer des vignettes du screenshot avec un fichier bmp.

    Le format jpg doit être évité à cause de son algorithme destructif.

    Le png est idéal pour des images de type Oric.

  • 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

  • SOUND GENERATOR

    Remplacement d’un AY-3-8912 par son grand frère : un AY-3-8910.
    No problem sur la carte Mammouth !

    Le remplacement in situ est à l’étude :

    En déplaçant deux composants, le “grand” générateur de sons pourrait s’installer près de l’ancien… Il y a assez de place.

    Une petite plaque double face, quelques soudures, et…

    Testé ! Ça fonctionne !

    Le hic, c’est que le boîtier ne se ferme plus. C’est un peu trop encombrant.
    Il va falloir amincir l’ensemble…

    Mais le concept est validé. On peut remplacer sans trop de problème un AY-3-8912 par son grand frère.
    Reste à lui faire subir une petite cure d’amaigrissement (qui ne saurait tarder)…


    A+

  • 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