WordPress

Tag: Truc software

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

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

    par André C.

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

    Limites et difficultés

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

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

    La méthode de récupération

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

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

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

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

    Fabriquez les en-têtes appropriés

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

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

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

    RecupCaract1Télécharger

    Récupérez les DUMPs

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

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

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

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

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

    Dans votre éditeur hexadécimal :

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

    Configuration Atmos ou Atmos+Microdisc+Sedoric

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

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

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

    à suivre…

  • Récupérez les écrans des logiciels protégés : 2 – Application, Démo Talisman

    par André C.

    Je ne peux pas résister au plaisir de vous montrer les écrans que j’ai pu récupérer à partir du fichier TALISMAN_DEMO.WAV de Simon G. A ma connaissance il n’existe pas de fichier .TAP ou .DSK pour cette démo et je l’ai choisie pour illustrer la simplicité de la procédure de récupération des nombreux écrans Hires qu’elle contient. Cet article montre des recopies d’écran, mais vous trouverez tous ces écrans au format .tap dans le zip joint à cet article.

    RecupEcrans2Télécharger

  • Récupérez les sprites des logiciels en mode HIRES

    par André C.

    En mode HIRES, pour afficher quelque chose qui bouge rapidement (cas des jeux d’arcade), il faut obligatoirement passer au langage machine.

    La commande Basic CHAR est trop lente pour faire évoluer des sprites basés sur des caractères redéfinis. Or les astuces développées pour stocker, afficher et déplacer des objets en mode HIRES restent mystérieuses tant qu’on ne procède pas à un “reverse engineering”. Et c’est un gros boulot !

    Oui, mais il n’est pas sûr que l’on soit obligé d’en arriver là. Notre propos n’est pas de comprendre comment marche le programme, mais seulement de récupérer le dessin des sprites et les data nécessaires à leur affichage.

    Lors de la sortie de Xenon-1, je me souviens avoir été fasciné par la beauté et la rapidité des sprites, lesquels sont animés qui plus est ! Je ne peux pas faire autrement que de choisir cet exemple pour illustrer mon propos sur la récupération des sprites.

    Un écran HIRES est composé de 200 lignes de 40 octets. Ces 8000 octets sont, soit des attributs, soit des octets compris entre #40 et #7F. Dans ce dernier cas, chaque octet représente un “tiret” composé de 6 pixels. Récupérer les data d’un sprite, c’est récupérer les octets correspondant à tous les tirets qui le composent et si le sprite est multicolore, la valeur et la position des attributs utilisés. En outre, si le sprite est animé, il faut récupérer toutes les images du sprite.

    Je vous propose deux méthodes :

    1. Faire simultanément un dump de la mémoire et une recopie d’écran (enfin, aussi simultanément que possible). Avec un éditeur hexadécimal, comparer les octets de la zone écran HIRES avec les objets présents sur la recopie d’écran. Récupérer tout simplement ces octets, qui constituent les data de définition des sprites.
    2. Faire une recopie d’écran. Agrandir le fichier .bmp ou .png jusqu’au niveau du pixel avec un bon logiciel de traitement d’image. Isoler le sprite intéressant et le numériser manuellement. La bonne vieille méthode quoi ! Faisable mais ch…, heu… fastidieux ! Si vous avez beaucoup de sprites à traiter vous pouvez aussi utiliser une feuille de calculs pour simplifier la numérisation.

    La première méthode en pratique

    Les paresseux sont des gens qui cherchent à s’éviter du travail. C’est en cherchant à échapper à la phase de numérisation des tirets que j’ai eu l’idée de la méthode 1, dérivée de celle que j’ai utilisée précédemment pour les écrans TEXT. Autant vous avouer tout de suite, que ma paresse n’a pas été récompensée ! Certes cette méthode marche, mais au final, c’est très compliqué. Vous pouvez donc passer directement à la seconde méthode, sauf si vous avez la fantaisie et le temps d’être curieux !

    Procédure dans Euphoric :

    1. Lancez Xenon1.tap avec Euphoric en configuration Atmos (vous trouverez la version Simon G. de ce tap dans le zip qui accompagne cet article, ainsi que sur le site oric.org).
    2. Allez à l’écran qui vous intéresse, le premier par exemple.
    3. Pressez aussi rapidement que possible les touches F9 (dump de la mémoire) puis F12 (recopie de l’écran).
    4. Pressez F11 (débogueur) pour figer le jeu et gardez la fenêtre en réserve en vue d’un autre essai (il s’agit de sprites animés et il y a plusieurs images à récupérer pour chacun).
    5. Renommez le fichier DUMP qui a été généré par exemple en DumpX1-01.bin
    6. Renommez le fichier Screenxx.bmp en Xenon1-01.bmp
    RecupSpritesTélécharger

    Procédure avec votre éditeur hexadécimal :

    1. Ouvrez DumpX1-01.bin et réglez l’affichage pour avoir 40 octets en largeur.
    2. Allez à l’adresse #A000 (début de l’écran HIRES). Chaque ligne de l’éditeur correspond à une ligne HIRES.
    3. Dans la partie gauche de l’éditeur se trouvent les octets présents dans l’écran. Chacun représente, soit un attribut, soit un tiret de 6 pixels, selon que son bit 6 est à zéro (attribut) ou à un (tiret). Dans ce dernier cas, les 6 bits les plus faibles représentent les pixels. Par exemple les octets #40 (les plus nombreux et de loin) soit 01000000 en binaire, correspondent à un espace ou plutôt à un tiret dont les 6 pixels sont de la couleur du fond, donc invisibles (par défaut en HIRES, le fond est noir et l’encre blanche).
    4. Dans la partie droite de l’éditeur, sont affichés les caractères Ascii correspondants. Le foisonnement de @ qui correspond aux nombreux octets #40 saute aux yeux. On peut voir aussi soit des points (les attributs), soit des caractères. Ces caractères n’ont rien à voir avec des caractères dans l’écran. C’est seulement que l’éditeur hexadécimal considère chaque octet comme un code Ascii et affiche le caractère correspondant.

    Contrairement à ce qui se passait avec l’écran texte, il n’est pas possible de visualiser tout l’écran HIRES d’un seul coup. En effet, alors que l’écran TEXT compte 28 lignes, l’écran HIRES en compte 200. Il faut donc faire défiler l’affichage de l’éditeur verticalement pour comparer les octets et caractères associés avec ce qu’on voit sur la recopie d’écran.

    Comparaison des octets dans la Ram et de l’écran

    La figure ci-dessus, montre une telle tranche d’écran, et permet de comparer les octets (à gauche), le caractère Ascii correspondant (à droite) et la portion d’écran HIRES correspondante en dessous. Les caractères correspondant aux tirets des sprites sautent aux yeux au milieu de la forêt des caractères @. Il “suffit” de noter (ou faire un collé/copié) des octets proprement dits (partie gauche de l’éditeur) pour avoir les data définissant chaque sprite. Enfin, c’était sans compter que les sprites se déplacent de façon très fluide (sur la figure ci-dessous, l’oiseau glisse, de un pixel à la fois, de gauche à droite dans l’écran). L’affichage d’un sprite coïncide rarement avec les octets (sinon les déplacements seraient saccadés de 6 pixels en 6 pixels).

    Le sprite glisse de gauche à droite dans l’écran Hires, de un pixel à la fois

    Dans le cas de cet écran Xenon1, les sprites font 18 pixels de large sur 18 pixels de haut. En théorie, il faut donc 3 tirets de 6 pixels pour afficher un sprite dans le sens de la largeur. En pratique, le programme en langage machine se charge de faire glisser le sprite dans une fenêtre de 4 tirets de large.

    Par exemple, la première ligne du sprite situé en haut à gauche de l’écran (ligne qui inclut le haut des deux cornes) peut être définie par les pixels suivant (0=pixel éteint, 1=pixel visible) : 000000100001000000. Ce qui devrait correspondre aux 3 octets suivants (après avoir forcé le bit 6 à 1, drapeau indiquant qu’il ne s’agit pas d’un attribut) : #40, #61 et #40. Or on observe sur la figure que 4 octets sont impliqués : #40, #42, #44 et #40, ce qui, en ne conservant que les bits b0 à b5, correspond aux pixels suivants : 000000000010000100000000. On voit que l’affichage du sprite de 18 pixels de large a été effectué sur 24 pixels. Pour récupérer les valeurs significatives des 3 octets il faudrait redécouper les 24 pixels en 3 zone de 6 pixel et laisser tomber (dans ce cas précis) les 4 pixels de tête et les 2 pixels de queue. En pratique c’est bien trop compliqué, à moins d’être un expert des tableurs genre Excel ou Calc !

    La seconde méthode en pratique

    La figure ci-dessous montre l’un des sprites de Xenon1, très agrandi. J’ai laissé volontairement une bande supplémentaire de 4 pixels de large à gauche et une autre de 2 pixels à droite pour que vous puissiez restituer et visualiser ce que nous avions précédemment avec la méthode 1.

    Résumons ce que l’on voit : On a un sprite de 18×18 pixels (3 tirets de 6 pixels de large sur 18 lignes HIRES de haut) affiché dans une zone de 24×18 pixels (4 tirets de 6 pixels de large sur 18 lignes HIRES). Les lignes verticales blanches délimitent les octets directement impliqués dans le dessin du sprite proprement dit. Chacune des 18 lignes HIRES doit donc être découpée en 3 tirets de 6 pixels de façon à récupérer le dessin réel du sprite. La nouvelle séparation en 3 zones de 6 pixels de large est visualisée par les lignes pointillées.

    Numérisation du dessin pour obtenir les octets définissant le sprite

    Au total, il nous faut donc numériser 18 fois 3 tirets pour récupérer tous les data du sprite. La figure ci-dessus montre un exemple de numérisation. Il s’agit de la tête du sprite.

    Le premier tiret par exemple (haut des cornes sur la tête) correspond à 100001 en binaire soit #21, valeur à laquelle il faudra ajouter #40 pour mettre le bit 6 à un (drapeau pour reconnaître les tirets), soit #61 dans cet exemple. Et ainsi de suite pour l’ensemble des 54 tirets du sprite.

    Ceci représente un travail forcément important, mais moins qu’il n’y parait, car il y a beaucoup de redondances (tirets identiques).

    A vous de voir si vous voulez vous aider soit d’un tableur (vous mettrez des croix dans les cases et il calcule les valeurs finales à utiliser), soit d’un simple tableau des 64 combinaisons possibles donnant directement les valeurs à utiliser.

    Bon courage !

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

    par André C.

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

    Constatation

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

    Un florilège de protections

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

    Bilan des transferts au format .tap ou .dsk

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

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

    Ecrans versus recopie d’écrans

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

    Exploration de la Ram

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

    Les divers types d’écrans

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

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

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

    Fabriquez les en-têtes appropriés

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

    100 HIRES

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

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

    130 TEXT

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

    150 PING

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

    Récupérez les DUMPs

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

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

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

    Et enfin, récupérez les écrans

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

    Dans votre éditeur hexadécimal :

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

    A suivre…