WordPress

Category: TAP file

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

    3 – ZAP et OUPS

    Introduction

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

    LA COMMANDE ZAP

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

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

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

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

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

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

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

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

    Variantes

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

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

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

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

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

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

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

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

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

    Quelques remarques :

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

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

    LA COMMANDE OUPS

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

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

    Variantes

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

    Le programme OUPS1.BAS

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

    Le programme OUPS2.BAS

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

    LA COMMANDE ZAAP

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

    Listing modifié :

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

    Le programme ZAAP1.BAS

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

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

    Le programme ZAAP2.BAS

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

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

    SonsPreprogr3.zipTélécharger

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

    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

  • 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

  • Récupérez les caractères redéfinis de tous les logiciels : 1 – Méthode

    par André C.

    Dans les deux articles précédents (“Récupérez les écrans des logiciels protégés : 1 – Méthode” et ” 2 – Application : Démo Talisman”) nous avons vu comment mettre à profit le dump de la mémoire généré par les émulateurs. Cela s’applique aussi à la récupération des polices de caractères. A priori, on pourrait croire que la procédure ne présente aucun intérêt pour les programmes non-protégés, puisqu’on peut déjà accéder au contenu de la mémoire. Mais, comme vous le verrez, il peut être indispensable d’établir un rapport entre ce qu’on voit à l’écran et ce qu’il y a en mémoire. D’où l’intérêt du dump.

    Limites et difficultés

    Souvent, les caractères ont été redéfinis en vue de créer une police de caractères (par exemple pour faire un écran-titre). Mais ce n’est pas toujours le cas et même si vous parvenez très facilement à récupérer les jeux 0 et/ou 1, vous ne serez pas forcément au bout de  vos peines :

    1. En effet, les caractères sont souvent redéfinis en vue d’être assemblés pour former des sprites. Il faut donc savoir comment ça s’organise. Solution : Le débogueur de votre émulateur Oric (touche F11 avec Euphoric) vous permet d’examiner l’écran et de comprendre comment sont formés les sprites (avec quels caractères et quelle disposition).
    2. Autre difficulté, les programmes redéfinissent souvent les caractères au fur et à mesure des tableaux du jeu. Un bon exemple est donné par “The Hellion” (voir les articles “Les 101 écrans de The Hellion” de Simon G. (CEO-mag n°240 à 274). Il faut donc déclencher un dump de la mémoire au moment où les nouveaux caractères à récupérer apparaissent à l’écran (touche F9 avec Euphoric).
    3. Enfin, si en général tout va bien avec les programmes Basic, les choses se compliquent souvent avec les programmes écrits en langage machine. En effet, les auteurs optimisent forcément leur code et sont amenés à stocker les caractères/sprites dans un format différent du format habituel et d’utiliser des routines d’affichage spécifiques. Il va sans dire que dans ces cas-là, il faudrait beaucoup investir dans la matière grise…

    La méthode de récupération

    C’est exactement la même procédure que pour les écrans. Seules les adresses changent.

    Comme vous le savez, l’Oric comporte deux jeux de caractères :

    1. Le jeu 0 dit “normal”, situé de #B500 à #B7FF (3 pages de #100 octets), qui compte 96 caractères du code Ascii 32 (espace) au code Ascii 127 (rectangle noir de 6×8 pixels utilisé pour le curseur).
    2. Le jeu 1 dit “semi-graphique”, situé de #B900 à #BAFF (2 pages de #100 octets), qui ne compte que 64 caractères du code Ascii 32 (espace) au code Ascii 95 (rectangle noir de 6×8 pixels, identique au code Ascii 127 du jeu 0).

    Attention, il s’agit des adresses initiales, au boot, c’est-à-dire en mode TEXT. Si le programme passe en mode HIRES, les deux jeux sont déplacés respectivement vers la zone  #9900 à #9BFF pour le jeu 0 et vers la zone #9D00 à #9EFF pour le jeu 1 (voir les tableaux ci-après).

    Fabriquez les en-têtes appropriés

    Pour les 2 jeux de caractères et pour les 2 modes d’écran, il faudra donc prévoir 4 modèles d’en-tête, par exemple avec le petit programme SAUVJEUX suivant (voir le fichier .zip joint à cet article) :

    100 TEXT
110 CSAVE"SAVJ0TXT",A#B500,E#B7FF
120 CSAVE"SAVJ1TXT",A#B900,E#BAFF
130 HIRES
140 CSAVE"SAVJ0HRS",A#9900,E#9BFF
150 CSAVE"SAVJ1HRS",A#9D00,E#9EFF
160 PING
    En-tête de fichier cassette pour le jeu des caractères normaux en mode text
    En-tête de fichier cassette pour le jeu des caractères semi-graphiques en mode text
    En-tête de fichier cassette pour le jeu des caractères normaux en mode hires
    En-tête de fichier cassette pour le jeu des caractères semi-graphiques en mode hires

    Pour avoir un en-tête proprement dit, récupérez les octets du début du fichier .tap, allant du #16 initial au #00 (inclus) situé juste après le nom du fichier. Dans les conditions décrites, chaque en-tête aura au final une longueur de 23 octets. A l’issue de ce petit travail, vous disposerez donc de 4 modèles d’en-tête (voir les 4 figures ci-dessus) que vous garderez précieusement. Les 4 fichiers .tap correspondants sont dans le zip joint à cet article.

    RecupCaract1Télécharger

    Récupérez les DUMPs

    La procédure de récupération des jeux de caractères est très simple. Les consignes qui suivent concernent Euphoric, mais des fonctions analogues sont disponibles avec les autres émulateurs.

    1. Lancez Euphoric et chargez le logiciel à traiter. Si besoin, lancez l’exécution.
    2. Guettez le moment où les initialisations semblent terminées et où les caractères à récupérer apparaissent à l’écran et pressez la touche F9 pour générer un dump mémoire.
    3. Pressez immédiatement la touche F11 pour figer l’exécution du logiciel et renommez le fichier DUMP généré (sinon il serait écrasé au prochain appui sur F9).
    4. Eventuellement pressez à nouveau la touche F11 pour relancer l’exécution et guettez le tableau suivant. Etc.

    Note : Il pourrait aussi être utile de garder des recopies d’écran afin de pouvoir identifier s’il s’agit d’un écran TEXT ou HIRES (pas toujours évident). Profitez également de l’appui sur F11 pour examiner le contenu des zones #BB80-#BFDF (écran TEXT) ou #A000-#BFDF (écran HIRES).

    Et enfin, récupérez les jeux de caractères

    Il n’est pas toujours facile de déterminer si ce sont les caractères du jeu 0 ou du jeu 1 (ou des 2) qui ont été redéfinis, ni si le programme tourne en mode TEXT ou en mode HIRES. Dans l’expectative, on sera parfois conduit à récupérer plusieurs jeux à l’aveuglette et à juger ensuite des résultats.

    Dans votre éditeur hexadécimal :

    1. Ouvrez le modèle d’en-tête correspondant à la zone à récupérer. CTRL+A puis CTRL+C pour copier les 23 octets du fichier.
    2. Ouvrez un nouveau document. CTRL+V pour y coller l’en-tête. Editez les 8 caractères de forme “SAVJxxxx” pour renommer votre fichier .tap
    3. Ouvrez le fichier DUMP à traiter. Sélectionnez les #0300 (jeu 0) ou #0200 (jeu 1) octets correspondant au jeu ciblé à partir de l’adresse de ce jeu (voir le tableau ci-dessous), puis tapez CTRL+C pour copier la zone sélectionnée.
    4. Pour vous éviter de sauvegarder inutilement un jeu de caractères qui n’a pas été redéfini, demandez à votre éditeur hexadécimal de calculer la checksum de la zone sélectionnée et comparez avec la valeur indiquée dans le tableau ci-dessous (valeurs pour les jeux natifs d’origine Oric).
    5. Allez dans le nouveau document, à la fin de l’en-tête, CTRL+V, pour y coller le jeu.
    6. Sauvegarder votre jeu au format .TAP par exemple sous le nom TOTOJ0.TAP.
    7. Examinez le jeu sauvegardé à l’aide de l’un des nombreux programmes de redéfinition ou de visualisation pour Oric ou à l’aide du programme OricExplorer de Scott Davies.

    Configuration Atmos ou Atmos+Microdisc+Sedoric

    Type de jeu Mode écran Aller à l’offset Octets à sélectionner Checksum Atmos Checksum Sedoric
    Jeu 0 TEXT #B500 #300 #3F70 #4026
    Jeu 1 TEXT #B900 #200 #3F00 #3F00
    Jeu 0 HIRES #9900 #300 #3F70 #4026
    Jeu 1 HIRES #9D00 #200 #3F00 #3F00

    La checksum du jeu 0 sous Sedoric est différente car 6 caractères ont été redéfinis :    à ç é ù è et ê.

    Dans la deuxième partie de cet article, je prendrai deux exemples, “Rush Hour” et “The Hellion”, pour illustrer pas à pas la procédure de récupération des jeux de caractères.

    à suivre…

  • Récupérez les écrans des logiciels protégés : 1 – Méthode

    par André C.

    Exemple d’écran-titre d’un logiciel protégé par C-SAFE

    Constatation

    Les cassettes et les disquettes 3″ vieillissent mal, de même que leurs lecteurs respectifs. Le transfert des logiciels Oric sur des supports modernes est donc crucial. C’est grâce à ces transferts et à divers émulateurs que nous pouvons profiter, encore aujourd’hui, des programmes achetés dans les années 80. Simon G., Dominique P., Fabrice F. et bien d’autres ont réussi à transférer au format .tap la plupart des logiciels du commerce, notamment ceux qui comptent parmi les mieux protégés. La complexité des moyens de protection mis en œuvre est parfois surprenante au vu de leur valeur économique somme toute limitée.

    Un florilège de protections

    Les passionnés de casse-têtes pourront découvrir ou relire les nombreux articles passionnants parus dans le CEO-mag à ce sujet. Pas loin d’une centaine d’articles ont été publiés qui décortiquent les divers procédés de protection rencontrés. Parmi les plus spectaculaires, citons C-SAFE, utilisé pour Titan, Logor et Talisman de chez Infogrames et pour Vortex de chez Loriciels (voir articles “C-SAFE et .TAP” par Simon G. et Dominique P., CEO-mag n°261, pages 14 et 15, ainsi que “Cassettes, un florilège de formats exotiques (2) ” par Dominique P., CEO-mag 262, pages 18 et 19. Mais il existe tout une panoplie d’autres systèmes de protection et de formats exotiques…

    Bilan des transferts au format .tap ou .dsk

    Un très grand nombre de logiciels sont maintenant disponibles dans ces formats. Pour lever les protections, il a parfois été nécessaire de modifier un minimum d’octets, mais  toujours avec le souci de coller au plus près à l’original.

    Les procédures utilisées pour contourner certaines protections sont si complexes, qu’il est souvent beaucoup plus simple de lire les cassettes audio, d’enregistrer la “musique” au format classique .wav. Le fichier obtenu peut alors être placé sur une bande magnétique ou un CD et réinjecté dans un Oric réel ou être rechargé dans un émulateur. Mais bien sûr ce fichier .wav inclut toujours la protection. Le logiciel est utilisable, mais on ne peut pas “regarder dedans”. Au moins 25 fichiers au format .wav sont aujourd’hui disponibles sur oric.org et concernent évidemment les logiciels les plus réticents.

    Ecrans versus recopie d’écrans

    Certes, les émulateurs permettent d’effectuer des recopies d’écrans, mais les fichiers obtenus sont aux formats .BMP, .GIF, etc. Il serait intéressant de récupérer les écrans TEXT ou HIRES aux formats Oric .SCR et .HRS sur un support .tap ou .dsk. Dans le même genre d’idée, ce serait chouette de récupérer les caractères redéfinis, les musiques, etc. Or, comme écrit plus haut, on ne peut pas “regarder dedans”. Mais est-ce bien sûr?

    Exploration de la Ram

    Non seulement c’est tout à fait possible, mais en plus c’est très simple. En effet, les émulateurs permettent d’effectuer un dump de la mémoire. Ainsi avec Euphoric, un simple appui sur la touche F9 sauve un fichier DUMP de 64 Ko correspondant à l’intégralité de la mémoire de l’Oric émulé. Il ne reste plus qu’à explorer ce fichier DUMP à l’aide d’un éditeur hexadécimal et d’en extraire les parties intéressantes par exemple les écrans.

    Les divers types d’écrans

    Trois types d’écrans peuvent être récupérés :

    1. Ecrans basse résolution (TEXT, LORES0 et LORES1) situés de #BB80 à #BFDF en Ram (soit #0460 octets ou 1120 en décimal ce qui correspond bien à 28 lignes de 40 caractères).
    2. Ecrans haute résolution seuls (sans les 3 lignes de texte) situés de #A000 à #BF3F (soit #1F40 octets ou 8000 en décimal pour 200 lignes de 40 tirets de 6 pixels).
    3. Ecrans haute résolution avec les 3 lignes de texte en dessous, situés de #A000 à #BFDF (soit #1FE0 octets ou 8160 en décimal. On remarquera une petite curiosité : la Ram comporte 4 lignes de texte sous l’écran Hires (d’où les 160 octets supplémentaires) mais la première des quatre n’est pas affichée et les 40 octets correspondants restent donc inutilisés!

    Puisqu’on connait les adresses de début et de fin de ces écrans, rien ne sera plus facile que de les récupérer, puisqu’ils ont la même adresse en Ram et dans le fichier DUMP, et de les copier derrière un en-tête cassette. Les en-têtes cassettes ont été décrits dans le CEO-mag n°153 page 17. Mais il est plus simple (et plus sûr) de sauver un écran bidon et d’en récupérer l’en-tête, plutôt que de construire celui-ci octet par octet.

    Fabriquez les en-têtes appropriés

    Pour ces 3 types de d’écran, il vous faudra faire 3 modèles d’en-tête avec le petit programme SAUVENT.COM suivant (voir le fichier .zip joint à cet article) :

    100 HIRES

    110 CSAVE”MODLHRS1″,A#A000,E#BF3F

    120 CSAVE”MODLHRS2″,A#A000,E#BFDF

    130 TEXT

    140 CSAVE”MODLTEXT”,A#BB80,E#BFDF

    150 PING

    Pour avoir les 3 en-têtes, récupérez les octets du début du fichier .tap, allant du #16 initial au #00 (inclus) situé juste après le nom du fichier. Dans les conditions décrites, les 3 en-têtes auront au final une longueur de 23 octets (ou 22 si le début du fichier ne comporte que 3 fois l’octet #16 au lieu de 4, selon la version d’émulateur utilisé). A l’issue de ce petit travail, vous disposerez donc de 3 modèles d’en-tête que vous garderez précieusement [figures MODLHRS1, MODLHRS2 et MODLTEXT.GIF]. Les fichiers .tap correpondant à ces 3 en-têtes sont dans le zip joint à cet article.

    Récupérez les DUMPs

    La procédure de récupération des écrans est maintenant simple :

    1. Lancez Euphoric en mode Atmos, pressez F1, validez “Hardware tape” et indiquez le nom du fichier .wav à traiter, (par ex. LOGOR.WAV qui n’existe pas en version .tap). Pressez F1 pour revenir à l’Atmos.
    2. Tapez CLOAD”” et chargez le fichier .wav. Tiens cela n’a pas changé : C’est toujours très long ! Sauf que 2 appuis sur la touche F4 et ça charge 4 fois plus vite ! Retour à la vitesse normale par un appui sur la touche F5.
    3. Le programme se lance. Guettez le moment où s’affiche l’écran que vous désirez sauver et pressez la touche F9 (dump mémoire) puis sur F11 (débogueur). En mode débogueur l’exécution se fige, ce qui vous laisse le temps de renommer le fichier DUMP obtenu (par ex DUMP01 etc.), sinon il sera écrasé au prochain appui sur la touche F9. Nouvel appui sur la touche F11 pour sortir du débogueur. Guettez le prochain écran intéressant (s’il y en a), F9 puis F11, etc.
    4. Notez qu’il est possible de recharger un des états ainsi sauvé pour reprendre l’exécution du programme là où elle en était, en relançant Euphoric avec “Euphoric -a –r” (attention le nom du fichier utilisé par Euphoric sera DUMP tout court).

    Petite difficulté dans mon système : Euphoric sauvegarde le fichier DUMP dans le répertoire “Tapes”, mais si on relance avec “Euphoric -a –r”, Euphoric cherche DUMP dans le répertoire “Euphoric”. Mais c’est sans doute un problème de configuration.

    Et enfin, récupérez les écrans

    Vous vous trouvez maintenant en possession d’un ou plusieurs fichiers DUMPxx. Il faut en extraire la zone écran qui vous intéresse et lui coller un en-tête ad hoc par devant. Prenons par exemple le format Hires long (avec les 3 lignes de texte en dessous) situé en Ram de #A000 à #BFDF.

    Dans votre éditeur hexadécimal :

    1. Ouvrez le modèle d’en-tête correspondant, soit MODLHRS2. CTRL+A puis CTRL+C pour copier les 23 octets du fichier.
    2. Ouvrez un nouveau document. CTRL+V pour y coller l’en-tête. Editez les 8 caractères “MODLHRS2” pour renommer votre fichier .tap
    3. Ouvrez le fichier DUMPxx à traiter. Sélectionnez les #1FE0 octets correspondant à l’écran Hires. Par exemple Goto #A000 puis Select bloc #1FE0, puis CTRL+C.
    4. Allez dans le nouveau document, à la fin de l’en-tête, CTRL+V, pour y coller l’écran.
    5. Sauvegardez votre écran au format .tap par exemple sous le nom ECRANxx.tap. C’est fait.
    RecupEcrans1Télécharger

    A suivre…