WordPress

Category: Emulateurs

Catégorie destinée à tous les émulateurs de l’Oric

  • Manuel du débogueur d’Oricutron

    Cette version française a été établie d’après le fichier ReadMe.txt du 15/05/2020 (Oricutron version win64-20200515).  La version PDF de cet article est disponible (voir en fin d’article).

    English speaking Oricians can directly use the official Oricutron Manual (ReadMe.txt file released with Oricutron).

    Au lancement d’Oricutron, il faut presser sur F1 pour accéder au menu principal, qui permet entre autres choses, d’ajouter un clavier Oric virtuel, ce qui peut être utile, voir indispensable.

    Touches actives dans les menus en général

    Flèches           Se déplacer dans le menu

    Return            Exécuter l’option choisie

    DEL                 Revenir en arrière

    ESC     Quitter le menu (ou touche Backspace ou BACK avec la souris)

    Touches actives dans le mode émulateur

    F1                   Aller au menu principal (sortie par ESC ou Backspace ou BACK avec la souris).

    F2                   Entrer dans le mode Débugueur / Moniteur (sortie par F2).

    F3                   Reset soft (NMI)

    F4                   Reset hard (reboot)

    Shift+F4        Reset Jasmin

    F5                   Basculer entre les 3 états de la ligne d’information sous l’écran.

    F6                   Basculer entre vitesse normale / vitesse x20

    F7                   Enregistrer toutes les disquettes modifiées

    Shift+F7        Enregistrer toutes les disquettes modifiées sous un nouveau nom.

    F8                   Basculer entre mode fenêtre / mode plein écran

    F9                   Sauver le fichier tape

    F10                 Démarrer / arrêter la capture vidéo AVI

    F11                 Copier l’écran texte dans le presse-papiers.

    F12                 Coller le presse-papiers dans l’écran texte.

    Help               Aide (pour Amiga, MorphOS and AROS)

    AltGr              Modificateur supplémentaire

    L’intérêt du couple F11/F12 mérite d’être souligné, car il offre une passerelle intéressante entre Oricutron et le système hôte.

    Le débogueur / moniteur d’Oricutron

    Pour accéder au mode débogueur / moniteur d’Oricutron, vous devez presser la touche F2 (F2 est en fait une bascule entre le débogueur et l’émulateur qui peut être utilisée à tout moment sans perte, ni dans l’émulateur, ni dans le débogueur / moniteur). Un écran apparaît, structuré comme celui de la  Fig. 1 : Cet écran est composé de 4 fenêtres :

    Fig.1 Etat du débogueur apres assemblage de code LM (a $9812) et positionnement du PC (r pc $9812).

    1) Ecran de l’Oric

    2) Status du 6502 (“6502 Status”)

    3) Une zone dans laquelle alternent les 3 fenêtres suivantes : Moniteur (“Monitor”) / Débogueur (“Debug console”) / Dump mémoire (“Memory watch”). On passe d’une fenêtre à l’autre avec la touche F3.

    4) Une zone dans laquelle alternent les 2 fenêtres suivantes : Informations VIA (“VIA Status”) et Informations AY (“AY Status”). On passe d’une fenêtre à l’autre grâce à la touche F4.

    Touches actives dans le mode Débogueur / Moniteur

    Dans ce mode, outre l’écran de l’Oric, les fenêtres suivantes sont visibles :

    “6502 Status” (Fig. 1 en haut à droite).

    Fig. 2 Fenêtre “Debug console” (vide pour l’instant).

    “Monitor” (Fig. 1 en bas à gauche) ou “Debug console” (Fig. 2) ou “Memory watch” (Fig. 3).

    Fig. 3 Fenêtre “Memory watch” (ici on voit la page zéro).
    Fig. 4 Fenêtre “6502 status” (après réinitialisation de CY par F9).

    “VIA Status” (Fig. 1  en bas à droite) ou “AY Status” (Fig. 5).

    Fig. 5 Fenêtre “AY status”.

    Les touches suivantes sont actives de manière générale, sans qu’il soit nécessaire d’indiquer une fenêtre en particulier.

    F1     Aller au menu principal (retour au mode émulateur par ESC ou Backspace ou BACK avec la souris, mais F2 permet de retrouver le  Débogueur / Moniteur au même point).

    F2     Passer dans le mode émulateur (retour dans le  Débogueur / Moniteur par la touche F2).

    F3     Pour basculer entre les fenêtres Moniteur (“Monitor”) / Débogueur (“Debug console”) / Dump mémoire (“Memory watch”).

    F4     Pour basculer entre les fenêtres Informations VIA (“VIA Status”) et Informations AY (“AY Status”).

    F9     Pour réinitialiser le compteur de cycles (ligne CY= dans la fenêtre 6502) (Fig. 4).

    F10   Pour exécuter la ligne de code marquée > dans la fenêtre 6502 (Fig. 1 en haut à droite).

    F11   Comme F10, mais s’il s’agit d’un sous-programme, celui-ci est exécuté en bloc,  sans affichage du détail des lignes de ce sous-programme.

    F12   Pour sauter l’instruction marquée > et pointer sur l’instruction suivante. La paire d’écrans “VIA Status” ou “AY Status” affichent des informations en fonction du contexte et ne disposent pas de commandes spécifiques. Par contre, chacune des fenêtres “Monitor”, “Memory watch” et “Debug console”, possède des commandes propres, en plus des commandes listées ci-dessus.

    Touches actives dans le mode Console (fenêtre “Debug console”) 

    Flèches Haut / Bas     Historique des commandes.

    Touches actives dans le mode Dump Mémoire (fenêtre “Memory watch”)

    Flèches Haut / Bas                Scrolling Haut / Bas, ligne par ligne.

    Shift + Flèches Haut / Bas    Scrolling Haut / Bas, écran par écran.

    Page Up/Page Down              Idem.

    Fig. 6 Fenêtre “Memory watch” (Splitée par S).

    Chiffres hexadécimaux        Pour changer de zone mémoire à visualiser. Exemple $9800 affiche le contenu de la mémoire à partir de $9800 (Fig. 6).

    S          Activer / désactiver le mode fractionné (Split). Dans ce mode, deux demi-fenêtres “Memory watch” permettent de visualiser deux zones différentes de la mémoire (Fig. 6).

    Tab     Changer de demi-fenêtre “Memory watch” en mode fractionné. La demi-fenêtre active est indiquée par une coche dans la marge gauche. Les commandes ne sont alors effectives que sur cette demi-fenêtre (Fig. 6).

    Instructions en mode moniteur (fenêtre “Monitor”)

    En entrée les valeurs numériques sont décimales par défaut. Elles peuvent être hexadécimales si elles sont préfixées par $ ou binaires si elles sont préfixées par %. Presque toutes les sorties sont en mode hexadécimal. Là où vous pouvez entrer un nombre ou une adresse, vous pouvez transmettre un registre CPU ou VIA. (Les registres VIA sont préfixés par V, par exemple VDDRA). Là où vous pouvez entrer une adresse, vous pouvez également utiliser un symbole. En plus des commandes décrites au paragraphe “Touches actives dans le mode Débogueur / Moniteur”, voici les commandes spécifiques du mode Moniteur :

    ?           Affiche toutes les commandes disponibles (RETURN pour avoir l’écran suivant).

    Flèches Haut / Bas       Historique des commandes.

    a <addr>            Assembler le code à l’adresse <addr> (assemble) (Fig. 1). Au prompt entrer une ligne de code. L’assembleur passe à la ligne suivante, presser RETURN pour finir.

    bc <bp id>          Effacer le point d’arrêt indiqué (clear breakpoint).

    bcm <bp id>      Effacer le point d’arrêt mémoire indiqué (clear memory breakpoint).

    bl                         Lister les points d’arrêt (list breakpoints).

    blm                      Lister les points d’arrêt mémoire (list memory breakpoints).

    bs <addr> [zc]   Définir un point d’arrêt classique (set breakpoint) (pour les modificateurs zc, voir plus loin dans la partie consacrée aux points d’arrêts).

    bsm <addr> [rwc]        Définir un point d’arrêt mémoire (set memory breakpoint) (pour les modificateurs rwc, voir plus loin dans la partie consacrée aux points d’arrêts).

    bz                          Supprimer  les points d’arrêt (zap breakpoints).

    bzm                      Supprimer  les points d’arrêt mémoire (zap memory breakpoints).

    Fig. 7 Fenêtre “Monitor” (désassemblage par la commande d $9812).

    d <addr>              Déassembler à partir de l’adresse <addr> (disassemble) (Fig. 7).

    fd <addr> <end> <file>  Désassembler dans un fichier, de <addr> à <end> (disassemble to file). Ce fichier <file> est sauvé dans la racine du répertoire Oricutron. Aucune extension, ni entête, n’est ajoutée. Il ne contient que les data bruts, sans informations complémentaires (adresses, type etc.). NB. L’ancienne commande df <addr> <end> <file> n’est plus reconnue.

    fw <addr> <len> <file>  Sauver une zone mémoire sur la disquette (bin file write) (Fig. 10). Ce fichier <file> est sauvé dans la racine du répertoire Oricutron. Aucune extension, ni entête, n’est ajoutée. Il ne contient que les data bruts, sans informations complémentaires (adresses, type etc.). NB. L’ancienne commande wm (write memory to disk) n’est plus reconnue.

    fr <addr> <file>           Charge un fichier en mémoire à l’adresse <addr> (bin file read) (Fig. 10). Il s’agit d’un fichier brut préalablement sauvé dans la racine du répertoire Oricutron (ou d’un fichier similaire reconstruit). Il faut donc préciser l’adresse cible et le nom exact.

    m <addr>                       Dumper les 128 octets présents en mémoire à partir de l’adresse <addr> tout en restant dans la fenêtre Moniteur (memory) (Fig. 9). Presser la touche RETURN pour afficher la demi-page suivante. Cette commande est moins puissante que la commande mw ci-après.

    mm <addr> <valeur>  Modifier la mémoire (modify memory) (Fig. 8).

    Fig. 8 Fenêtre “Monitor” (mm modify memory).

    mw <addr>             Afficher la fenêtre Dump Mémoire et dumper à partir de l’adresse <addr> (memory watch at addr) (Fig. 3). Cette commande est plus puissante que la commande m ci-dessus (Fig. 9) (voir les nombreuses touches actives dans ce mode Dump Mémoire).

    Fig. 9 Fenêtre “Monitor” (m dump memory).

    nl <fichier>             Charger une recopie d’écran (load snapshot) (pas d’extension par défaut).

    ns <file>                 Enregistrer une recopie d’écran (save snapshot) (pas d’extension par défaut).

    r <reg> <val>         Initialiser le registre <reg> avec la valeur <val> (set register). Exemple “r pc $9812” positionne le Program Compter en $9812 (Fig. 1, fenêtre 6502 status en bas à gauche). Les touches F10 et F11 permettent d’exécuter le code qui se trouve à cette adresse.

    Fig. 10 Fenêtre “Monitor” (commandes fw et fr).

    q, x ou qm               Quitter le moniteur et retourner à l’émulateur (quit, exit, quit moniteur)

    qe                            Quitter l’émulateur (quit emulator)

    sa <nom> <addr>  Ajouter ou déplacer un symbole utilisateur (add symbol)

    sk <nom>        Supprimer un symbole utilisateur (kill symbol)

    sc                      Symboles non sensibles à la casse (symbols not case-sensitive)

    sC                      Symboles sensibles à la casse (symbols Case-sensitive)

    sl <file>            Charger les symboles utilisateur (symbols load) (pas d’extension par défaut)

    sx <file>           Exporter les symboles utilisateur (export symbols) (pas d’extension par défaut)

    sz        Supprimer les symboles utilisateur (zap symbols).

    Points d’arrêt

    Parmi les commandes listées ci-dessus, 8 sont consacrées aux points d’arrêt. C’est dire l’importance qu’ils occupent dans le débogueur / moniteur d’Oricutron. Voici quelques précisions.

    Il existe deux types de points d’arrêt. Les points d’arrêt normaux ou “classiques” se déclenchent lorsque le processeur est sur le point d’exécuter l’instruction à l’adresse du point d’arrêt. Les points d’arrêt “mémoire” se déclenchent lors de l’accès ou de la modification de l’adresse du point d’arrêt.

    Les points d’arrêt “classiques” peuvent utiliser les modificateurs z et / ou c.

    bs $0C00        Arrêt lorsque le processeur est sur le point d’exécuter du code à l’adresse $0C00

    bs $0C00 z     Idem et met le compteur de cycles à zéro

    bs $0C00 zc   Met le compteur de cycles à zéro et continue (pas d’arrêt)

    bs $0C00 c     Continue l’exécution (le point d’arrêt est désactivé)

    L’objectif principal des modificateurs z et / ou c est de faciliter le comptage des cycles.

    Si des symboles sont chargés, ils peuvent être utilisés à la place des adresses absolues.

    Les points d’arrêt “mémoire” peuvent être déclenchés de trois manières: lorsque le processeur est sur le point de lire (r pour read), ou d’écrire (w pour write) à l’adresse ou lorsque la valeur à l’adresse change pour une raison quelconque (c pour change). Le choix du modificateur c  (c pour change) n’est pas très heureux, car pour les points d’arrêt normaux, c est déjà utilisé pour continue. Voici quelques exemples d’utilisation :

    bsm $0C00 r       Arrêt lorsque le processeur est sur le point de lire à l’adresse $0C00

    bsm $0C00 rw     Arrêt lorsque le processeur est sur le point de lire ou d’écrire à l’adresse $0C00

    bsm $0C00 c       Déclenche une pause après le changement du contenu de $0C00

    bsm $0C00 rwc          Déclenche une pause juste avant que le processeur ne lise ou n’écrive à l’adresse $0C00 ou juste après le changement, pour une raison quelconque, du contenu de $0C00.

    Fig. Fenêtre “Ecran Oric” (résultat de l’exécution).

    Conclusion

    Ce manuel est certes très succinct et de nombreuses explications pourraient encore être ajoutées. Néanmoins, j’espère qu’il vous sera utile, comme il l’est pour moi. N’hésitez pas à me faire connaître les manques et les erreurs, afin que je puisse l’améliorer.

    ManuelDebogueurOricutron.pdfTélécharger

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