WordPress

Category: Modèle

Catégorie regroupant les différents modèles d’Oric

  • Les enveloppes du PSG 8912

    par André C.

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

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

    Problèmes de n° d’enveloppe

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

    Problèmes de profils

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

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

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

    Durée de l’enveloppe

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

    Conclusion

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

    Envelop.zipTélécharger

  • Temporisation en langage machine

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

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

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

    Temporisation à boucle

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

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

    Temporisation à 2 boucles

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

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

    Temporisation à 3 boucles

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

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

    Temporisation avec le Timer 2

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

    Quelques mesures

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

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

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

    Conclusion

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

    Disquette TEMPORIS.DSKTélécharger

  • Radar Oric 2

    Une seconde version quelque peu améliorée

    par André C.

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

    Rappel du synopsis

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

    Vitesse de déplacement du curseur

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

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

    1 – Case vide

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

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

    4 – Sous-marin

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

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

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

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

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

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

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

    Nouvelles commandes

    Le jeu comporte maintenant 7 commandes au lieu de 4.

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

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

    RADAR2.DSKTélécharger

  • Des programmes pour votre Oric

    de Michel Piot, Cedic/Fernand Nathan (1983)

    Des nouvelles de la Librairie Oric de CEO

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

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

    Comment accéder à la Librairie du CEO?

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

    Des programmes pour votre Oric

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

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

    Le contenu de ce livre

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

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

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

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

  • Récupérez les caractères redéfinis de tous les logiciels : 2 – Deux exemples “Rush Hour” et “The Hellion”

    par André C.

    Comme nous l’avons vu dans l’article précédent, peu importe que le logiciel à traiter soit protégé ou non, l’essentiel est qu’il soit possible de le faire tourner sur un émulateur et de pouvoir réaliser un dump de la mémoire.

    Disons que si le logiciel n’est pas protégé (ou s’il a été déverrouillé), il est plus facile de savoir s’il est écrit en Basic ou en langage machine, s’il tourne en mode TEXT ou HIRES, s’il utilise les zones normales de stockage des caractères et les procédures normales d’affichage.

    Il y a trois grandes catégories de logiciels :

    1.      Ceux dont les caractères sont redéfinis uniquement lors du lancement.

    2.      Ceux dont les redéfinitions évoluent au fil de l’exécution.

    3.      Ceux dont les caractères ne sont pas redéfinis (oups !).

    1) Logiciels dont les caractères sont redéfinis uniquement lors du lancement

    Dans cette catégorie, j’ai pris comme exemple “Rush Hour” de Fabrice F. En effet ce logiciel est particulièrement astucieux.

    Pour contourner les difficultés d’un cahier des charges très lourd, Fabrice a recopié les caractères utiles du jeu 0 dit “normal” dans le jeu 1 dit “semi-graphique” (dont les caractères d’origine sont évidemment écrasés). Pour l’affichage de texte standard, il faudra désormais utiliser le mode “semi-graphique” ! Les 96 caractères du jeu 0 étant “disponibles” ont été redéfinis pour afficher les sprites de divers véhicules. Notez que ce programme n’est pas protégé et que son listing est bien documenté.

    Procédure dans Euphoric :

    1. Lancez Euphoric, chargez “Rush Hour” (RUSHHOUR.TAP) et lancez-le.
    2. Avancez dans le jeu, dans mon exemple, jusqu’au “Level 11” (choix “Harder”).
    3. Pressez la touche F9 pour générer un dump mémoire. Renommez par exemple en DumpRH.BIN
    4. Pressez F12 pour générer une recopie d’écran au format .BMP. Renommez par exemple en RushHourLevel11.BMP
    5. Laissez Euphoric en attente.

    Procédure dans votre éditeur hexadécimal :

    1.      Ouvrez le modèle d’en-tête SAVJ0TXT.TAP (voir article précédent). 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. Modifiez cet en-tête uniquement pour le renommer (par exemple RHJ0TXT).

    3.      Ouvrez le fichier DumpRH.BIN de “Rush Hour”. Allez à l’offset #B500 et sélectionnez les #0300 octets du jeu 0, puis tapez CTRL+C pour copier cette zone.

    4.      Allez à la fin de l’en-tête dans le nouveau document. CTRL+V, pour y coller le jeu 0.

    5.      Sauvegardez votre jeu sous le nom RHJ0TXT.TAP (Rush Hour, Jeu 0, mode TEXT).

    6.      Faites la même chose pour le jeu 1 (SAVJ1TXT.TAP, RHJ1TXT, #B900, #0200 octets, RHJ1TXT.TAP).

    7.      Toujours dans votre éditeur hexadécimal, réglez l’affichage pour 40 octets par ligne, afin qu’une ligne dans l’éditeur corresponde à une ligne de l’écran Oric et allez en #BB80 (début de l’écran TEXT).

    8.      Reprenez la fenêtre d’Euphoric qui était restée en attente et placez là immédiatement à gauche de la zone d’affichage des codes Ascii de votre éditeur (voir la figure ci-dessous). Vous avez maintenant la correspondance entre les véhicules de “Rush Hour” à gauche et les codes Ascii utilisés pour l’assemblage des sprites !

    RecupCaract2Télécharger

    2) Logiciels dont la redéfinition des caractères évolue au fil de l’exécution

    Cette catégorie est semblable à la précédente, sauf que les caractères sont redéfinis pour chaque phase du jeu !

    L’exemple le plus frappant est “The Hellion” avec 101 écrans où se meuvent les sprites d’objets très différents en quantité invraisemblable. En fait, les 101 tableaux de “The Hellion” représentent un cas extrême de redéfinitions à répétition.

    Ce logiciel fonctionne en mode TEXT et les 2 jeux de caractères sont partiellement redéfinis. Vous trouverez le programme (HELLION.WAV, HELLION.TAP & HELLION.DSK au choix), ainsi que les fichiers utilisés ou produits dans cet exemple dans le zip qui accompagne cet article.

    Procédure dans Euphoric

    Il faut traiter “The Hellion” comme s’il s’agissait d’une série de 101 programmes indépendants, mais réunis à la queue-leu-leu. La procédure suivante devra donc être répétée pour chaque tableau :

    1.      Pressez la touche F9 (sauvegarde d’un dump de la mémoire) au début de chaque tableau.

    2.      Puis, le plus vite possible, pressez la touche F12 pour avoir une recopie de l’écran correspondant à ce dump (le plus rapidement possible car les sprites se déplacent très vite).

    3.           Et enfin pressez F11 pour geler la série de tableaux, le temps de renommer le fichier “DUMP” en “DumpH-xx.bin” ainsi que la recopie d’écran en “Hellion-xx.bmp”, xx étant le n° du tableau.

    Procédure dans votre éditeur hexadécimal :

    Chacun des fichiers “DumpHxx.bin” sera traité dans votre éditeur Hexadécimal pour en extraire les deux jeux de caractères et afficher la zone d’écran TEXT. Prenons par exemple le fichier DumpH04.bin :

    1. Ouvrez le modèle d’en-tête SAVJ0TXT.TAP. 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. Modifiez cet en-tête pour le renommer (par exemple “H04J0TXT”).
    3. Ouvrez le fichier “DumpH04.bin”. Allez à l’offset #B500 et sélectionnez les #0300 octets du jeu 0, puis tapez CTRL+C pour copier cette zone.
    4. Allez à la fin de l’en-tête dans le nouveau document. CTRL+V, pour y coller le jeu 0.
    5. Sauvegardez votre jeu 0 par exemple sous le nom H04J0TXT.TAP (Hellion, tableau “Wave 4”, Jeu 0, mode TEXT).
    6. Faites la même chose pour le jeu 1 avec le modèle SAVJ1TXT.TAP et sauvegarder le jeu 1 par exemple sous le nom H04J1TXT.TAP (Hellion, tableau “Wave 4”, Jeu 1, mode TEXT).
    7. Toujours dans votre éditeur hexadécimal, réglez l’affichage pour 40 octets par ligne, afin qu’une ligne dans l’éditeur corresponde à une ligne de l’écran Oric et allez en #BB80 (début de l’écran TEXT).
    8. Reprenez la fenêtre d’Euphoric qui était restée en attente et placez là immédiatement à gauche de la zone d’affichage des codes Ascii de votre éditeur (voir la figure ci-dessous). Vous avez maintenant la correspondance entre les “feux tricolores” de “The Hellion” à gauche et les codes Ascii utilisés pour l’assemblage de ces sprites à droite !

    Si on compare le jeu 0 obtenu à partir de ce tableau  “Wave 4” avec le jeu 0 natif de l’Oric, on constate que deux caractères seulement sont redéfinis : { (Ascii 123) et } (Ascii 125) (et cette redéfinition varie d’ailleurs d’un tableau à l’autre).

    Pour le reste, les sprites affichés sont formés avec des caractères du jeu 1 (un attribut #09 est placé au début de chaque ligne d’écran).

    Dans le tableau “Wave 4” (voir la figure ci-dessus), les objets volants (des feux tricolores) sont redéfinis avec les caractères 1 2 3 4 ou 5 6 7 8 ou 9 : ; < disposés verticalement.

    C’est plus compliqué pour l’oiseau du bas de l’écran, car celui-ci vole et plusieurs sprites se succèdent pour réaliser cette animation. J’ai détecté des images redéfinies avec = > ? sur une 1e ligne et @ A B en dessous, ou C D E et F G H ou I J K et L M N ou O P Q et R S T ou U V W et X Y Z. L’animation est donc réalisée avec 5 images. Avec 6 caractères redéfinis par image, cela fait 30 caractères redéfinis rien que pour l’oiseau !

    Dans tous les cas (feux tricolores ou oiseau) un attribut de couleur est placé juste à gauche de chacune des lignes des sprites, ce qui permet d’obtenir des sprites multicolores.

    Pour ne pas alourdir cet article, je ne montre que ce tableau “Wave 4”. Mais dans le tableau suivant “Wave 5”, chaque sprite est défini par les mêmes 4 caractères 1 2 3 4 ou 5 6 7 8 ou 9 : ; < disposés sur deux lignes. Or ces caractères ont été redéfinis entre temps puisque les dessins affichés sont différents. L’oiseau qui ressemble comme deux gouttes au précédent est affiché à partir des même 5 jeux de redéfinitions que précédemment ! Je ne suis pas allé plus loin dans mon analyse des 101 tableaux de “The Hellion”. Mais si certains sprites vous intéressent, vous devriez pouvoir les récupérer sans difficulté en suivant mes indications.

    3) Logiciels dont les caractères ne sont pas redéfinis

    Avant de vouloir récupérer des caractères redéfinis, il serait sage de s’assurer qu’il y en a. La présence de sprites sur l’écran ne signifie pas que des caractères ont été redéfinis. C’est, la plupart du temps, le cas pour les programmes qui tournent en mode Hires et qui sont, quasiment à coup sûr, écrits en langage machine. En effet, le Basic n’est pas assez rapide pour faire évoluer des sprites sur l’écran (ni même des caractères via la commande CHAR).

    Pour cette catégorie de logiciels, il s’agira plutôt de récupérer des sprites. Mon prochain article :

     “Récupérez les sprites de tous les logiciels en HIRES” montrera comment s’y prendre sans avoir à désosser le langage machine.

    A bientôt…

  • Carte mère Oric

    J’ai reçu (un peu de façon inattendue par ces temps-ci) la carte mère d’Oric que j’avais commandée (et pour une fois, pas miC…) :

    Et oui ! On peut acheter un PCB nu de carte mère d’Oric…
    Les pastilles ont l’air de bonne qualité, les pistes aussi.

    Mais elle nécessite d’être testée. Déjà, on remarque que R26 a une patte en l’air…
    Peut-être faudra-t’il un câble de jonction pour d’autres composants ?
    Ce topic permettra d’en suivre les évolutions.

    Premières modifications : R26 doit être reliée déjà masse et les pattes 1 des deux 74LS257 doivent être reliées ensemble.

    Suite (mai 2020) : implantation des résistances et problème au niveau de RP1

    Le but étant de reproduire une carte fonctionnelle mais incomplète (pas de partie UHF), destinée à remplacer une carte Oric originale, l’implantation des composants se fera en plusieurs temps.

    Tout d’abord, pour tester le fonctionnement minimum de la carte mère, seront mis en place les circuits suivants: 6502, 6522, ULA, EPROM, AY3-8912, les huit DRAM, les deux 74Ls257, le 74LS04 et le 74LS365, tous montés sur supports (ça aide pour la maintenance !). Quelques résistances et condensateurs, un Quartz, un transistor, un connecteur pour le clavier et un pour la partie vidéo accompagneront le lot.
    Plus tard viendront les autres connecteurs, le 7905 (ou 7805 ?), l’ampli LM386, le LM358 pour les entrées-sorties Son Cassette, le relais, le haut-parleur, le bouton poussoir de Reset, une deuxième Eprom avec sélecteur.


    Pour commencer, il est bon de placer en premier les composants qui ont le moins de hauteur sur la carte. On peut penser aux résistances ou aux diodes. Puis viendront les supports de CI, les condensateurs, le quartz, les connecteurs…

    La référence est le schéma de Fred72.
    Voici donc les résistances nécessaires :

    De gauche à droite,
    – les deux 1 KOhm (pour Quartz et 74LS04),
    – les quatre 220 Ohm (pour sortie vidéo),
    – la 2,2 KOhm (pour la patte 2 du 74LS365),
    – les deux 47 KOhm (pour gestion clavier),
    – la 220 KOhm (pour Reset au démarrage),
    – les cinq 2,2 KOhm (pour jouer le rôle de RP1).

    RP1 ? Kézako ?
    Il s’agit d’un réseau de résistances de 2,2 KOhm à 8 pattes.

    Sept résistances reliées à un point commun (dont l’emplacement est marqué avec un point noir). Dans l’ORIC, ce point commun est branché au + 5 Volt. On peut nommer les résistances de R1 à R7 :

    Sept résistances… Oui, mais il ne nous en faut que cinq ?

    Un coup d’œil à la nouvelle carte :
    (ou c’est ici que ça se passe…)

    Voici l’implantation de RP1 :

    Il est aisé de constater que R4 à R7 sont reliées sur le connecteur 34 broches de l’ORIC, avec les Pins P2, P4, P6 et P8 :

    P2 pour ROMDIS, P4 pour RESET, P6 pour I/O CTRL, P8 pour IRQ

    Et R3 est reliée à P1 :

    P1 pour MAP

    C’est conforme au plan ! Ouf…
    Mais quid de R1 et de R2 ? Une fois la carte retournée :

    Ces résistances sont reliées à P5 et P7 :

    P5 pour I/O et P7 pour R/W

    Ah…
    Comparaison avec une carte mère originale d’ORIC (Issue 3) :

    R1 et R2 ne servent pas au fonctionnement et n’ont qu’un petit boulot décoratif !

    Question :
    Pourquoi avoir relié ainsi ces deux résistances sur la nouvelle carte ?
    Si l’on force les lignes R/W et I/O au niveau haut en permanence, cela va t’il jouer sur le fonctionnement ?
    Les Pros pourront répondre à cette “angoissante” question…
    Sur le Net, la majorité des montages à base de 6502 ne possèdent pas de résistances de tirage vers le haut sur ces lignes…

    Pour respecter le schéma de la carte originale, ces deux résistances seront omises… D’où l’utilité de remplacer le réseau de résistances RP1 par des résistances classiques…

    Pour les supports de CI, on peut aussi utiliser des barrettes sécables, moins chères :

    Les voici à la bonne taille et prêtes à l’emploi :

    Les résistances à plat sont déjà soudées

    Et après 382 points de soudures pour les supports…

    Le support de la deuxième EPROM (IC10) sera installé plus tard, car cela nécessite quelques petits travaux au préalable qui permettront la sélection d’une EPROM ou l’autre…

    Pour les condensateurs, il est difficile de trouver les mêmes originaux. Ici la taille n’a rien à voir, il suffit de plier un peu les pattes pour avoir le même écartement.

    De même pour le Quartz de 12 MHz…

    Ne pas oublier de relier R26 à la masse : par exemple sur la patte de C10…

    Et de relier les deux pattes numéro 1 des 74LS257 :

    Pour RP1 (voir plus haut), voici la solution retenue :

    Ne pas traiter RP2 de la même façon.

    Même s’il lui ressemble, celui-ci n’est que la juxtaposition de quatre résistances de 220 Ohm dans le même emballage…

    On peut le remplacer donc par quatre résistances dites normales…

    Et on obtient :

    Et voici la carte un peu plus habillée…

    Comme il n’y a pas de connecteur d’alimentation ni de 7905, il va falloir créer deux points d’alimentation temporaires qui fourniront du 5 Volt pour les tests. Le choix peut se porter sur l’emplacement de C9, un condensateur de découplage de 47 nF situé au dessus de IC24 :

    Pour bénéficier du filtrage de C8, il faudra temporairement le relier à la masse de la carte :

    Ainsi, la carte sera prête pour les premiers essais en réel !
    Aussitôt dit, aussitôt fait…

    Alors, il est grand temps de tester la tension sur la carte :

    OK !

    Mise en place d’un 74LS04 (ici, un 74HC04) pour test de la fréquence :

    Mise sous tension et test de la fréquence sur la patte 7 de l’ULA (qui devrait recevoir du 12 MHz) :

    Encore OK !

    En attendant (Sœur Anne, ne vois-tu rien venir ?) la livraison des connecteurs DIN pas en stock, il suffit de relier des fils temporaires sur les résistances de 220 Ohm en sortie du 74LS365 :

    Reg Green Blue, Yellow as Synchro, Black as Ground

    Puis enfin, le premier test de boot après avoir installé les circuits et un fil de jonction sur les deux pastilles reférencées LK, on obtient :

    Premier boot réussi !

    Manquent encore le clavier, le son et la gestion Cassette…
    A suivre !

    A+

  • PRINT@ et PLOT en mode HIRES

    par André C.

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

    Etat des lieux

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

    Pour la petite anecdote

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

    Revenons à nos moutons

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

    Positionner le curseur sur une ligne Y

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

    Positionner le curseur sur une colonne X

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

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

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

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

    En conclusion

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

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

  • Manuel développeur du telestrat

  • Initiation à Orix

    Qui travaille sur Orix

    Actuellement, Assinie et moi travaillons dessus. Des tests ont été fait pour faire tourner glOric. Il y a beaucoup de choses de faites, mais elles sont surtout en béta.

    Que permet Orix ?

    Orix est un ensemble de binaires/kernel qui permet de gérer un shell et des routines d’accès au hardware de la carte twilighte. L’objectif est de faire tourner tout ce qu’on veut sur l’oric quelques soit l’OS initial, ou le support (tap/dsk etc).

    Une première démo est sortie il y a en 2017. Cette démo était plus un proof of concept car beaucoup de choses étaient faites par bidouilles.

    Certaines ROM en plus du shell sont disponibles avec leur programme associé :

    • un basic 1.1 modifié pour charger des .tap à partir de la sdcard. Une version existe pour charger sur le port USB avec une clé USB. Il suffirait de charger cette ROM en ROM ou en RAM (car la twilighte board pourrait charger n’importe quelle ROM dans ses 64 banques.
    • le forth modifié pour accéder à la SDCARD, ce n’est ni plus ni moins que teleforth
    • Monitor est un moniteur qui est en réalité teleass en version light car il n’y a pas l’assembleur embarqué pour l’instant

    Quelques commandes linux/unix sont présentes :

    • ls : affiche la liste des fichiers
    • man : affiche la doc d’une commande
    • ./ : lancement d’une commande du répertoire courant
    • cp : copie un fichier
    • mv : déplace un fichier
    • env : permet de voir quelques variables d’environnement
    • sh : qui permet de lancer des script shell minimalistes
    • meminfo : affiche la quantité de mémoire disponible et la quantité de mémoire restante
    • lsmem : affiche l’occupation de la mémoire par les process
    • ps : affiche la liste des process
    • exec : permet de lancer des commandes
    • touch : créé un fichier

    Plusieurs binaires sont disponibles en plus des commandes type linux/unix qui sont propre à Orix

    • bank : affiche les banques disponibles et leur signature
    • help : affiche les commandes en bash et en ROM (avec un paramètre -b pour afficher les commandes de la banque passée en paramètre)
    • viewhrs : permet de voir des images en hires
    • bootfd : démarre le bootsector d’une disquette : ne fonctionne que sur telestrat.
    • twil : permet de piloter la carte twilighte (swap du jeu de banking, passage en SRAM ou en ROM sur les 4 dernières banques de 16KB chacune, affichage du firmware de la carte)
    • vidplay : affiche des vidéos en streamant à partir de la sdcard
    • gunzip : binaire pour décompresser
    • kernupd : pour mettre à jour la rom en direct sur atmos.

    Où en est on sur Orix ?

    Beaucoup de choses sont faites, mais il y a beaucoup de bugs. Tout le monde peut participer, le code est disponible sur github. Le hardware n’est pas ouvert, mais le code oui. Il est possible de faire des ROMs simplement, de rajouter des binaires, travailler sur les process, la mémoire, les drivers.

    Premiers pas sur Orix

    A partir du moment, où vous avez le prompt (sur réel ou Oricutron), commençons par lister les ROM dispos :

    # bank

    Ok mais je n’ai que 7 banques d’affichées ! On me disait que j’avais 32 banques !

    Le choix a été fait de n’afficher que 7 banques tout le temps, mais de jouer sur les banques 4,3,2,1 pour afficher les banques supplémentaires. Ceci afin de garder le fonctionnement iso entre le Telestrat et atmos.

    Basculons de jeu de banques pour la banque 4,3,2,1 : cela ne fonctionne pas avec Oricutron, mais sur réel oui : les banques 4,3,2,1 affichent des signatures différentes :

    # twil -s1
# bank

    Si dessous la vidéo montre le fonctionnement de la carte est du switch de banque. C’est comme si sur telestrat, nous changions physiquement la cartouche port droit, sauf que c’est ici sans arrêt de machine, car c’est le hard et le soft qui gèrent tout cela.

    En effet, pour garder une compatibilité avec le telestrat, il a été décidé de n’afficher que 7 banques. Aussi, le kernel qui est issu de telemon, ne gère que 7 banques. Pour ne pas à avoir tout à modifier, la twilighte card fonctionne dans le mode “7 banques” tout le temps à l’affichage. A l’avenir, il sera possible de présenter 31 banques. mais cela nécessitera une modif du kernel et du firmware de la carte.
    Aussi, le paramètre “twil -s” accepte une valeur entre 0 à 8. La valeur 4 est un peu spéciale : elle affiche en banque 4,3,2,1 une banque en plus, puis le kernel, puis le basic1.1 puis le shell.

    Démarrer un fichier .tap

    La rom basic11 ne sait gérer que du tap dans un seul fichier. Le multitap ne fonctionne pas. C’est une limite sofware. En revanche, il est possible de charger plusieurs .tap dans le programme basic : un “10 cload “toto.tap”” sera chargé. C’est le cas pour zip&zap par exemple. Prenez des fichiers .tap, et mettez les à la racine de la sdcard. Puis taper : 

    # basic11

    La rom basic 11 a démarré

    il suffit de faire le cload du fichier déposé à la racine de la sdcard, le programma va démarrer tant qu’il n’est pas en multitap.

    Comment utiliser Orix actuellement ?

    Actuellement, il n’y a l’émulation que du contrôleur sdcard sur Oricutron. Ce qui veut dire que la partie swap de banques et accès à la RAM supplémentaire n’est pas possible sur Oricutron. Néanmoins, il est déjà possible de l’utiliser. Sur Oricutron, il y a déjà les roms de dispos. Il suffit de démarrer Oricutron en mode telestrat, en mettant en banque 7, le kernel, en banque 6, la rom basic11 modifée et le shell en banque 5

  • Bogue PRINT@

    par André C.

    Etat de la question

    Le manuel de l’Atmos présente l’ajout du paramètre “@X,Y;” à la syntaxe de la commande PRINT comme une simple option supplémentaire par rapport au PRINT de l’Oric-1, permettant d’afficher aux coordonnées X,Y de l’écran. PRINT@X,Y;plist n’est pas présenté comme une nouvelle commande, mais comme une simple extension de syntaxe.

    D’autre part, rappelons que si on place un “;” à la fin d’une commande PRINT, les coordonnées X,Y de la “case” qui suit le dernier caractère affiché sont mémorisées pour l’impression suivante. Il est alors possible d’utiliser ces coordonnées pour une autre commande d’affichage. Pour le dire plus simplement, après le “;” final, le curseur reste à clignoter au bout du dernier affichage et représente le prochain point d’affichage.

    Ce que ne dit pas le manuel

    Dans certains cas, il peut y avoir un conflit entre les paramètres “@X,Y;” et le “;”final. En effet, au niveau du code, lorsqu’un paramètre “@X,Y;” a déjà été détecté au début de l’analyse de syntaxe, un paramètre “;” en fin de ligne n’est ni rejeté, ni traité correctement.

    En pratique

    Lorsqu’on utilise une série de PRINT@X,Y;”CHAINE”, pour chacune des commande PRINT@, la chaine mentionnée est bien affichée aux coordonnées X,Y indiquées, pas de problème. Si la longueur de la chaîne est supérieure à la place disponible, l’affichage se poursuit tout naturellement à la ligne suivante.

    Si pour une raison quelconque on est amené à mélanger des commandes PRINT@ avec d’autres commandes d’affichage,  on risque de rencontrer des problèmes. Voyons ce qu’il en est avec un exemple.

    Soit le petit programme ci-dessus.

    La chaîne figurant à la ligne Basic 10 comporte 30 caractères. Le premier caractère, un “2”, sera affiché dans la “case” de coordonnées X=2, Y=10. Le dernier caractère, un “1”, sera affiché dans la “case” X=31, Y=10. A cause du “;” final, le curseur restera à clignoter sur la case suivante. (Le déroulé du programme est trop rapide pour voir ce curseur clignotant, sauf si on place une commande GET R$ en fin de ligne).

    La ligne Basic 15 affiche “OK” au curseur, c’est à dire au point X=32, Y=10. Ici encore, le curseur restera en attente sur la case suivante  à cause du “;” final.

    La ligne Basic 20 devrait commencer l’affichage de la chaîne “SALUT LES GARS!” (15 caractères) de la “case” de coordonnées X=16, Y=10 et la terminer à la “case”  X=30, Y=10. Au lieu de ça, seul “SALUT ” est affiché correctement, le reste de la chaîne, soit “LES GARS!”, est rejeté au début de la même ligne n°10 de l’écran et, curieusement, pas à la ligne suivante.

    Vous me direz que le “;” n’a logiquement rien à faire à la fin du PRINT”OK” et que cela relève d’une faute de conception du programme Basic. Peut-être. Mais la commande PRINT proprement dite est mal codée : Lors de l’analyse de syntaxe, la rencontre d’un paramètre “@X,Y;” devrait entraîner la neutralisation des coordonnées X,Y en cours et leur remplacement par celles indiquées par “@X,Y;”.

    Si on retire le “;” après le PRINT”OK” l’affichage rentre dans l’ordre et redevient ce qu’il doit être.

    Ceci montre bien qu’il ne faut pas utiliser de “;” à la fin d’une commande PRINT@, sauf raison particulière et en toute connaissance des risques.

    Il n’est pas toujours simple de comprendre ce qui se passe. Ainsi, si on garde le “;” après le PRINT”OK”, mais que l’on supprime le “;” de la ligne Basic 10, alors la chaîne “SALUT LES GARS!” s’affiche correctement. Le truc, c’est qu’entre temps les paramètres X,Y ont été régénérés lors du retour à la ligne pour afficher “OK”. Même si le curseur reste à clignoter après le “K” de OK, le PRINT@ qui suit opère sans problème.

    Autre petite curiosité, lorsqu’on déplace progressivement l’affichage de la chaîne “SALUT LES GARS!” vers la droite en augmentant la valeur de X à la ligne Basic 20, on observe une rupture pour X=34. Pour X=33, le reliquat “LES GARS!” est rejeté au début de la même ligne de l’écran, alors que pour X=34, il est affiché au début de la ligne suivante, comme il se doit !

    Il n’existe pas de commande LPRINT@, donc pas de problème de ce côté-là.

    Oups !

    J’ai fait en dernier ce que j’aurais dû faire en premier : Vérifier si la bogue “PRINT@;” était déjà connue. Et oui : Vous pouvez consulter le CEO-mag n°10, page 9 de mars 1991, qui en donne une autre démonstration (article de Roger B.).

    Conclusion

    Comme vous l’avez vu, la situation peut devenir complexe quand la syntaxe d’une commande est mal gérée. Il est difficile de prévoir à l’avance le résultat final. Ceci vaut évidemment pour toutes les commandes Basic de l’Oric réputées pour leurs bogues. A la liste IF THEN ELSE, RND(), POS(), CLOAD, POINT(x,y), ‘ (apostrophe pour REM), EDIT, DRAW, il faut donc ajouter PRINT@;

    Salut et Oricité !