WordPress

Tag: ceomag359

  • CEO-MAG 359

    Sommaire

    Edito

    Bonjour à tous,

    Cela fait maintenant 6 ans (une olympiade et demi) que je m’occupe du mag. On mesure la difficulté pour les athlètes de rester au top pendant 3 ou 4 cycles olympiques.
    Que de bons souvenirs, de plaisir à lire les reportages, interviews et tests proposés. Aux auteurs je dis merci, merci pour avoir permis au mag de vivre ces 6 dernières années.

    Le manque de temps, la motivation qui s’émousse, l’envie de retrouver avec le site web ce qui était un de mes plaisirs d’antan «le courrier des lecteurs» auront eu raison de ma volonté de créer ce mensuel à la date de sortie quelque fois décalée. L’heure est venue de tirer ma révérence pour retrouver du temps pour de nouvelles créations que cela soit sur Oric ou sur un autre média.
    Déjà depuis le début de l’année, vous retrouvez vos auteurs favoris : André, Yann, Jérome, Voyageur… sur le site du CEO. Alors continuez tous à tester, découvrir, créer, raconter vos expériences sur Oric. La vie du site, du mag ne tient qu’à vous.

    Le CEO avec son mag a.toujours évolué. Rappelons nous ces mags du début, faits main à l’époque ou seul les 36.14 et le courrier permettaient les échanges. Le mag s’est ensuite étoffé, mensuel avec des articles pointus et une disquette trimestrielle, il est ensuite devenu 100% digital et petit à petit des rubriques ont disparu avec le développement des forums. Je suis sur que dans les mois à venir, de nouvelles idées émergeront.

    Exceptionnellement, Covid-19 oblige, les bureaux du CEO sont fermés au public pour une durée indéterminée. Alors à tous, prenez soin de vous et profitez de ces moments de tranquilité pour retrouver les sensations apportées par votre Oric et je vous dis à bientôt, sur les forums du club et qui sait … un jour le mag, tel le phénix (ndlr : faut faire une recherche sur les index des magazines) renaitra peut être de ses cendres …

    [wpdm_package id=’3140′]

    [wpdm_package id=’3138′]

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

  • PRINT@ et PLOT en mode HIRES

    par André C.

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

    Etat des lieux

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

    Pour la petite anecdote

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

    Revenons à nos moutons

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

    Positionner le curseur sur une ligne Y

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

    Positionner le curseur sur une colonne X

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

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

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

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

    En conclusion

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

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

  • Averno

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

    Informations générales

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

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

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

    Ecran titre de la version 2019 sur Oric

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Quelques informations à propos du programme

    Le programme est divisé en 10 blocs:

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

    L’ensemble du programme occupe 137 lignes.

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

    Le jeu

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

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

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

    Contrôles :

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

    Une version française modifiée

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

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

  • Compte rendu de la visu hivernale 2020

    Comme d’habitude, nous nous sommes retrouvés vers 12h – 12h30 au Restaurant Nord-Est, qui est un des moyens les plus économiques que l’on puisse avoir pour nous restaurer. Les habitués étaient présents ; Jean bien sûr notre vénérable président, René notre trésorier adjoint et artisan du renouvellement des adhésions, Jean-Marc B., Christian L, et moi-même.
    Il était pratiquement 14h quand nous avons quitté le restaurant pour retrouver notre salle. Elle n’est pas très loin mais nous avons pris une sécurité au vu du repas clôturé avec une dégustation de calva, cognac et autres substances dignes de la prohibition.

    Présents : Christian L, René P, Jean-Marc B, Laurent D, Jean B, Didier V., et Simon G. Une visu finalement assez confidentielle en regard des dernières.

    Une fois n’est pas coutume, nous attaquons la réunion par les bilans et autres points d’organisation à préciser.

    Quelques moments de détente avant que le trésorier ne nous assaille de chiffres …

    Bilan Financier : Les charges à 387,90 en hausse à cause des visus ; mais maîtrisées car nous avons choisit des salles plus petites. Et des rentrées d’argent à 534,78 qui doivent nous permettre de faire désormais des visus plus ambitieuses. Aux adhésions sont venus s’ajouter 4,78 euros de dons issus des paiements paypal ayant initialement posé des soucis pour 10 donateurs.

    Avec l’arrêt des renouvellements auto, nous sommes passés en 2020 à 55 adhérents (dont 4 en 2020).

    Pour mémoire, le club a des adhérents à vie (selon les statuts définis à l’article 18) :

    • Daniel Duffau
    • Vincent Talvas
    • Laurent Chiacherini

    Le rapport financier est approuvé à l’unanimité.
    Le rapport moral est approuvé à l’unanimité

    Le rapport financier est inséré dans le numéro de mars du mag.

    Cette année, quelques changements dans le bureau ; Jérome entre dans le bureau en temps que Vice-Président tandis que René reste membre du Conseil d’Administration en tant que Community Manager.

    Composition du Conseil d’Administration :
    Jean B, Jérôme D. Chloé A., André C, René P., Didier V.

    Composition du bureau :

    • Président : Jean B.
    • Vice-Président : Jérome D.
    • Trésorière : Chloé A.
    • Secrétaire : André C.

    Après quelques échanges et la présentation du fonctionnement du site, quelques décisions sont prises :

    • Le routage de forums.oric.org doit être réalisé prochainement vers le forum interne au oric.bqtt.net/ (Jérome).
    • Il est convenu de garder un lien vers le forum hébergé sur forumactif pour assurer une bonne transition. Laurent regarde pour faire une sauvegarde de cette belle histoire dont on ne peut pas sauvegarder les données facilement.
    • Lors de la transition des mags de la zone oric.org vers le blog, un point d’attention sera porté à la mise en valeur des numéros hors-série (Transfert prévu par Jérome, relecture par Didier). Une anomalie a été détectée durant la visu, la sécurisation des accès aux mags sera vérifiée.
    • Après une démo et l’enregistrement de Jean-Marc sur le site, l’idée d’avoir les droits ci-dessous est validée. Cette ouverture permettrait au CEO de rayonner durablement avec des lecteurs non adhérents.
    Légende :
    R : Lecture
    C : Commentaires
    W : Ecrire    		Visiteur non enregistréInscrit non adhérentInscrit Adhérent CEOInscrit Rédacteur CEO
    Accès aux forums sur les rubriques publiquesRR/WR/WR/W
    Accès aux forums sur les rubriques CEO–R/WR/WR/W
    Accès aux articles publics sur oric.bqtt.net/RR/CR/CR/C
    Accès aux articles CEO––R/CR/C
    Ecriture d’articles–––W
    • Toujours pour améliorer la visibilité des activités du CEO, il est convenu de faire l’ouverture chez google d’un compte pour les associations. Didier s’en charge ; et fera appel à Jérôme et René si besoin pour les informations concernant l’enregistrement de l’association. Cette ouverture doit nous permettre d’avoir un accès “spécifique” à Youtube. (il faudra sans doute effacer la chaîne actuelle)

    La dernière partie de la réunion a été consacrée à la présentation des différents modèles d’Erebus. Il a été regretté qu’une production pour les membres du CEO n’ai pas été organisée. (NDLR et private joke pour les présents : tiens, ce pourrait être une mission du Community Manager)

    Les jeux Fifteen Puzzle et RadarOric ont été testés sur les 2 atmos présents. Le premier Atmos équipé de l’Erebus et magnifié par le boitier issu d’une impression 3D a permis à tous de découvrir sur une vrai Oric ce beau jeu de taquin. Le second était équipé d’un Cumulus (version Zaxxon) pour présenter RadarOric, la dernière production d’André.

    Radar Oric, le soft du mois

    Enfin, nous avons collectivement échangé sur les différences entre les assembleurs XA et CA 65, sur les bricolages modernes permettant de lire les fichiers tap (des Erebus en couleurs pour les plus beaux).
    De quoi nous donner des idées à tester parmi lesquelles :

    • un lecteur gotek avec écran revu pour lire directement les fichiers dsk (Didier a le matériel, mais pas de délai)
    • un lecteur de fichier tap pour ZX Spectrum et C64, qui pourrait être adapté sur Oric et ainsi nous permettre encore de meilleurs accès à notre logithèque.

    il est 19h (la salle étant inoccupée après nous, nous avons pu jouer les prolongations). C’est l’heure de nous disposer et nous regagnons nos gares respectives… et tandis que Jean est de nouveau confronté aux affres de la vie parisienne :
    “ma première erreur a été de croire que les trains de la ligne de Chelles repartiraient de la gare Magenta. Ben, non, les travaux ont pris du retard, le départ et l”arrivée des trains sont maintenus gare de l’Est. Prochain départ 20h00, c’est bon, il est 19h55. A 20h00, rien puis une annonce : voyageur malade, départ prévu dans un délai de 10 à 15 minutes, même annonce au bout de dix minutes, mais un départ est prévu à 20h15 sur le quai suivant. Ruée générale vers la voie 23 où le train ne part pas à 20h15. A 20h20, nouvelle annonce, nouveau problème. 20h30, le train de 20h00 démarre à moitié vide sous notre nez. Notre train partira quelques minutes après. Finalement, je descend à Noisy pour finir le trajet en bus, il est 20h57. Nous avons parcouru 8 kilomètres. Ah, les ascenseurs ont été réparés ! “,
    je rentre paisiblement dans le grand nord et commence à rédiger ce compte-rendu … je suis sur que parmi toutes les idées évoquées ce samedi, nous pourrons en voir certaines d’ici à la prochaine visu voire quelques micro-productions proposées aux membres du CEO.

    Rendez vous en Juin. Si tout va bien, la prochaine visu devrait se dérouler sur une journée complète.

  • Sauvegardez vos tableaux (alphanumériques) en toute sérénité (DSTORE / DRECALL version 2)

    Dans un précédent article (voir CEO-Mag n°357), j’expliquais clairement que les commandes DSTORE / DRECALL souffraient de certaines limites dans leur version initiale :

    • Impossibilité de sauver des tableaux à plusieurs dimensions ;
    • Risque d’écrasement de la routine en cas de redéfinition du jeu de caractères alternés ;
    • Utilisation du mode TEXT uniquement.

    Avec cette nouvelle version, ces imperfections appartiennent désormais au passé :

    • La routine loge entre $9400 et $977B, ce qui permet d’utiliser le mode HIRES et de redéfinir les caractères alternés mais nécessite un HIMEM#93FF avant toute utilisation ;
    • Grâce à l’appel de la commande SAVEM de SEDORIC, les tableaux alphanumériques de grandes tailles (et de plusieurs dimensions) peuvent être stockés sur la disquette.

    La syntaxe n’a quant à elle pas évoluée :

    • DSTORE TAB, “Nom Fichier” : sauve un tableau alpha/numérique avec le nom “Nom Fichier” sur disquette
    • DRECALL TAB, “Nom Fichier” : récupère un tableau alpha/numérique portant le nom “Nom Fichier” depuis la disquette

    Le branchement sur la routine se fait désormais grâce à DOKE#4EA,#9400.

    COMMENT ÇA MARCHE ?

    La sauvegarde des caractères qui composent un tableau alphanumérique a toujours lieu en RAM Overlay, de $C400 à $C7FF :

    • $C400-$C401 : nombre d’éléments stockés.
    • $C402-$C7FF : caractères du tableau alphanumérique. Les caractères sont précédés d’un nombre qui indique la taille de la variable alphanumérique en cours de stockage.

    Lorsque l’adresse de stockage en RAM Overlay dépasse $C7FF, une première sauvegarde a lieu sur la disquette. Le stockage des éléments restants reprend alors en RAM Overlay à partir de $C400, et un nouveau fichier sera ajouté au précédent grâce à la commande SAVEM.

    Lors de la récupération des données depuis la disquette, le premier fichier est transféré en RAM Overlay de $C400 à $C7FF.

    Chaque élément du tableau alphanumérique est créé en RAM grâce à la routine $D264/RAM Overlay ($D5AB/ROM) qui réserve une chaîne dont la longueur est dans le registre A (adresse chaîne réservée en $D1-$D2, longueur en $D0).

    Les caractères sont ensuite copiés un par un, depuis la RAM Overlay vers la RAM jusqu’à obtenir la longueur finale de la chaîne en cours.

    Lorsque toutes les chaînes du fichier en cours ont été transférées en RAM, on vérifie s’il existe un fichier “mergé” et on poursuit de la même manière si tel est le cas.

    Au passage, quelques routines en ROM / RAM Overlay :

    • $EA9E (ROM) : Ajuster adresse tableau alphanumérique dans $0209-$02AA ($0C-$0D) et $02AB-$02AC.
    • $D264 ($D5AB/ROM) : Réserver chaîne de longueur A (adresse chaîne réservée en $D1-$D2, longueur en $D0).
    • $E12E (RAM Overlay) : Charger fichier mergé selon valeurs en $C102,x et $C103,x (avec valeur x fixée par le registre X).

    UN BEAU DESSIN VAUT MIEUX QU’UN LONG DISCOURS

    Ci-après, les ordinogrammes des commandes DSTORE et DRECALL afin d’y voir plus clair.

    UN P’TIT COUP DE DÉBOGUEUR POUR LA ROUTE ?

    Les copies d’écran du débogueur ci-dessous montrent le descripteur du tableau alphanumérique M$ et une portion dudit tableau stocké en RAM Overlay.

    Descripteur tableau alphanumérique M$(21)
    Descripteur tableau alphanumérique M$(21)
    Sauvegarde tableau alphanumérique M$ en RAM Overlay

    Après sauvegarde du tableau alphanumérique M$ via la commande DSTORE M$,”TABLEAUM”, un rapide ‘DIR’ permet de vérifier la présence du fichier ‘TABLEAUM’ sur la disquette et de contrôler ses adresses de début ($C400) et de fin ($C6C8) ainsi que le type de fichier ($42).

    Contenu disquette
    STREC.BIN (routine principale #C9400-#977B)
    DEMALPHA (programme de démo en Basic)
    TABLEAUM (Tableau alpha M$ sauvé en #C400-#C6C8)

    Bonnes sauvegardes !!!

    STORECALL2Télécharger

  • 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é !

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