WordPress

Category: Software

  • Zorgon: keyboards revenge !

    (Scroll down for English version)

    Zorgons Revenge est un des jeux les plus populaires sur Oric. Mais, sorti sur Oric-1, sa configuration clavier pour le niveau “space mission” n’est pas adaptée au clavier Atmos, et encore moins aux claviers modernes pour les émulateurs.

    L’exemple à ne pas suivre
    Le niveau “space mission” utilise les touches “X” et la flèche gauche pour faire monter et descendre le vaisseau spatial. Comme l’illustre Dbug sur Defence-Force dans son article sur la gestion du clavier: c’est parfait sur Oric-1, et moins pour les autres machines ! Et le logiciel ne proposant pas de reconfiguration du clavier, Zorgons Revenge était l’illustration de l’exemple à ne pas suivre en termes d’ergonomie.
    Il existait des palliatifs, comme la cassette “Joystick adapter 1” qui permet d’utiliser un joystick via l’interface PASE, à la place du clavier. Mais combien de joueurs se servent encore d’un joystick aujourd’hui (PASE qui plus est) ?

    Des indices curieux
    Au cours de mes nombreuses numérisations de cassettes, je suis tombé sur une cassette de Zorgon contenant deux fiches d’instructions: une en anglais, indiquant les touches habituelles, et une en français, indiquant les touches SHIFT et CTRL pour bouger le vaisseau verticalement. Voilà qui serait bien pratique, car adapté à la fois à l’Oric-1 et à l’Atmos ! Mais le jeu, lui, était impossible à charger, la bande ayant mal vieilli.

    Interrogé à ce sujet en 2019, alors que je croyais à une erreur dans les instructions en français, voici ce qu’en disait l’auteur, John S. Sinclair:
    Question: Zorgon est sorti avant l’Atmos, du coup les touches pour le niveau spatial sont prévues pour le clavier de l’Oric-1 (X et flèche gauche). Avez-vous jamais envisagé de corriger cela pour l’Atmos, dont la touche X est loin de la flèche gauche ?
    Réponse: Je pense qu’on l’a fait, ou peut-être bien qu’on l’a juste adapté au joystick. Difficile de se souvenir.

    Question: Le manuel en français ne parle pas de touche X ni de flèche gauche, mais de CTRL et SHIFT pour déplacer le vaisseau, ce qui est une erreur. Est-ce qu’une première version utilisait ces touches ? (ce qui expliquerait que la notice, déjà partie à la traduction, n’aurait pu être corrigée à temps)
    Réponse: C’est une bonne question. Je crois que Ctrl et Shift proviennent d’Atlantis, un jeu BBC à scrolling. J’allais sans doute les réutiliser, et il s’est trouvé que le clavier de l’Oric était différent.

    Mince alors, il l’aurait corrigé ?

    La révélation
    Il y a quelques semaines, mon frère m’a ramené des cassettes Oric. Dedans se trouve un exemplaire de Zorgons Revenge, avec la pochette indiquant “for the 48K Oric” sur l’avant, “48K Oric-1 and Oric Atmos” sur le côté, et avec des instructions en français au dos. La fiche d’instructions séparée manquait. Comme d’habitude, je numérise systématiquement le signal audio, pour vérifier qu’on n’a pas une version différente. Et là je me rends compte de quelque chose d’inhabituel: le jeu est précédé du petit soft “ALC”, ce classique chargé de limiter les “Errors found” sur Atmos.


    Je compare le contenu du jeu lui-même, avec un transfert précédent, et bien que WAV2TAP n’ait rien détecté d’anormal, je vois 3 ou 4 octets différents. Erronés ?
    Bien. Nouvelle numérisation: résultat identique. Bizarre. Et subitement, la connexion se fait: je lance le nouveau fichier .TAP, je joue jusqu’à tomber sur le tableau “space mission”, et là… HOURRA, la version corrigée n’était pas un mirage, le manuel en français ne contenait pas d’erreur, et John S. Sinclair a une bonne mémoire: CTRL et SHIFT permettent de monter et descendre !

    Les suppositions
    Je n’ai évidemment pas une quantité monstrueuse de cassettes de Zorgon. Mais de ce que je peux observer jusqu’alors, seules certaines “versions françaises” (sur la jaquette) ont bénéficié de cette nouvelle version. Il existe des VF qui ont toujours les touches X et flèche gauche; seul le manuel (s’il est encore là!) ou l’écoute de la bande permettent de dissocier les deux versions. En revanche jusqu’alors je n’ai pas trouvé de version anglaise utilisant CTRL et SHIFT.
    Ce que l’on peut imaginer, c’est qu’après le succès de Xenon-1, IJK a produit et vendu de grandes quantités de la version Oric-1, et que la version corrigée n’est arrivée que plusieurs mois après, une fois l’Atmos sorti, le problème identifié, et les (gros) stocks d’anciennes versions écoulés. Il est donc envisageable, mais ce n’est qu’une supposition, que seules des versions destinées au marché français aient bénéficié de cette nouvelle version. En effet, le marché français s’est maintenu plus longtemps que le marché anglais, et a donc peut-être été le seul à bénéficier des derniers lots produits par IJK. Dans la même veine, il semble que Tansoft n’ait sorti son dernier jeu, Insect Insanity, que sur le marché français.
    Ceci expliquerait la relative rareté de cette version.

    Les différentes versions connues
    Pour finir, voici une synthèse des différentes versions “officielles” (par IJK, donc) de Zorgons Revenge, connues à ce jour:

    • la démo pour les magasins, qui contient un écran promotionnel spécifique
    • une version destinée aux journaux de l’époque ? Selon Oric Owner (numéro 9), c’est cette version qui aurait permis d’avoir des vies infinies en mourant d’une certaine façon avec le vaisseau spatial, mais aurait été corrigée avant commercialisation. Jamais diffusée ? Je n’ai jamais réussi à déclencher ce cheat avec les versions que je possède.
    • version “48K Oric-1”, jaquette et feuille d’instructions en anglais. C’est la première version vendue, “for the 48k Oric-1”.
    • version “48K Oric”, jaquette et feuille d’instructions en anglais. “Oric-1” a ét abandonné avec la sortie de l’Atmos, au profit de “for the 48K Oric”, mais le programme est inchangé. La feuille d’instruction aussi parle de “Oric manual” au lieu de “Oric-1 manual”. La fin du texte au dos de la jaquette est un peu modifié, notamment l’adresse d’IJK qui change et l’ajout du nom de l’auteur du dessin.
    • version “48K Oric”, dos de la jaquette et feuille d’instructions en français. La jaquette indique sur le côté “48K ORIC-1 and ORIC ATMOS”. Programme inchangé.
    • version “48K Oric”, dos de la jaquette et feuille d’instructions en français. Identique visuellement au précédent, mais la feuille d’instructions est corrigée et indique les touches SHIFT et CTRL, et sur la bande le programme est précédé du petit programme ALC. Bien entendu, le programme diffère puisque X et la touche fléchée ont été changées pour CTRL et SHIFT. Cette version n’est plus compatible avec Joystick Adapter 1 pour l’interface PASE !

    En reste-t-il à (re)découvrir ?

    Zorgons Revenge is one of the most popular games for Oric. But, released for Oric-1, its keyboard configuration for the “space mission” level doesn’t suit the Atmos keyboard, and is even worse for modern keyboards used with emulators.

    An example not to follow
    The space mission level uses X and left Arrow keys to move the ship up and down. As explained in Dbug’s article on Defence-force, about the keyboard handling: it’s perfect for Oric-1, less for other machines! And the game does not offer keys confirguration, making Zorgons Revenge an example not to follow in terms of keyboard design.
    Some workarounds existed, such as using the PASE joystick interface combined with the tape Jostick Adapter 1. But how many players still use joyticks today? (especially PASE?)

    Strange hints
    Having done tapes transfers for many years, I stumbled upon a Zorgon tape hodling two instructions sheets: one in English, describing the usual keys, and another one in French, saying that CTRL and SHIFT were used to move the ship up and down. Which would be quite convenient, since it would work on both Oric-1 and Atmos! But I wasn’t able to load the game, time having damaged the tape.

    When asked about this curiosity in 2019, as I thought it was a mistake on the French instruction sheet, here’s what author John S. Sinclair had to say:
    Question: Zorgon was released before the Atmos, so the space level keys are designed for Oric-1 keyboard (X and left arrow key). Did you ever consider fixing this for Atmos, whose X key was far from the left arrow?
    Reply: I think we did or maybe just made it work with a joystick. It’s hard to remember.

    Question: The French instructions don’t mention X and left arrow keys, but CTRL and SHIFT to move the ship up or down, which is a mistake. Was an earlier version of the game using these keys? (which would explain the French version, already sent to translation, couldn’t have been corrected in time)
    Reply: That’s a good question. I think Ctrl and Shift were from Atlantis, a BBC scrolling game. I probably was going to use those and the Oric keyboard was different.

    Mmmmh, so they would have corrected the keys at some point?

    The revelation
    A few weeks ago, my brother brought home Oric tapes. Among them was Zorgons Revenge, with the inlay stating “for the 48K Oric” on the front, “48K Oric-1 and Oric Atmos” on its side, and having French instructions on its back. The separate instruction sheet was missing. As usual, I sampled the tape to check if there was any difference with previous transfers. I then noticed something unusual: the tape began with the small “ALC” program, the classic piece of code designed to prevent having too many Atmos’ “Errors found” messages.
    I then compared the game itself with a previous transfer, and despite WAV2TAP hadn’t spotted anything special, 3 or 4 bytes were different.
    Transfer errors? I started again: same result. Strange. And suddenly, the light: I launched the new TAP file, played until I was in the space mission level, and then… YES, the corrected version wasn’t an illusion, the French manual wasn’t wrong, and John S. Sinclair had a good memory: CTRL and SHIFT allowed to move up and down!

    Guesses
    Or course, I don’t have loads of Zorgon original tapes. But from what I’ve been able to see so far, only the “French versions” (on the inlay) have been improved. There are other French versions still using the X and left arrow key; only the instructon sheet (if it wasn’t lost!) or listening to the tape allow to differenciate each version. But so far, I haven’t found any “English version” using CTRL and SHIFT.
    What one could guess, is that after the success of Xenon-1, IJK produced (and sold) huge quantities of the Oric-1 version, and that the improved version was made months later, once the Atmos was released, the problem identified, and the (massive) previous stocks sold. So it sounds possible, but that’s just a guess, that only versions for the French market were improved. As the French market stayed strong longer than in the UK, maybe it was the only one benefiting from the last production batches from IJK. In the same vein, it seems that Tansoft only released its last game, Insect Insanity, on the French market.
    This would explain why the improved version is rather rare.

    Different known versions
    Here’s a sum up of all Zorgons Revenge official (i.e. from IJK) known versions:

    • shop demo, holding a specific promotional screen
    • press reviews version? According to Oric Owner (issue #9), this is the version that would allow to have infinite lives when dying in a specific way during space mission, but that would have been fixed before commercial release. I have never managed to use this cheat. Never released officially?
    • “48K Oric-1” version, English inlay and instructions. The first sold version, “for the 48k Oric-1” version.
    • “48K Oric” version, English inlay and instructions. As the Atmos was released, “Oric-1” was replaaced by “for the 48K Oric”, but the program is the same than before. Instruction sheet now states “Oric manual” instead of “Oric-1 manual”. The texte at the back of the inlay ends differently, with the new IJK address, and the drawing artist name.
    • “48K Oric” version, French on back of the inlay and instructions. On its side, the inlay states “48K ORIC-1 and ORIC ATMOS”. Same program.
    • “48K Oric” version, French on back of the inlay and instructions. Visually the same as previous, but corrected French instructions with SHIFT and CTRL, and the tape begins with the small ALC program before the main one. Of coursse, the program is different since it now uses CTRL and SHIFT instead of X and an arrow key. This version doesn’t work anymore with Joystick Adapter 1 for the PASE intrface.

    Would there be more versions to (re)discover?

  • Fut’Oric

    Fut’Oric est un jeu de chiffres de type Futoshiki ce qui veut dire “non égal” en japonais. Il est conçu pour Atmos (c’est-à-dire pour la Rom 1.1 + Sedoric).
    Le programme est au format dsk et peut être utilisé avec un Atmos réel + Microdisc ou avec un Atmos émulé par exemple avec Euphoric. Mais pas avec Oricutron à cause d’une double bogue :
    1) Oricutron retourne le code 166 (#A6) au lieu de 165 (#A5) lorsque la touche FUNCT est pressée.
    2) Le “stick mode” ne marche pas pour la touche FUNCT. Même en modifiant le programme pour qu’il détecte le code #A6 au lieu de #A5, cela ne marche toujours pas car le “stick mode” est indispensable. Il faut donc attendre qu’Oricutron soit débogué…

    L’objectif est de remplir toutes les cases d’une grille avec des chiffres, de telle manière que chaque ligne et chaque colonne soient remplie de chiffres différents. C’est donc un jeu du style Sudoku, mais avec trois différences majeures :
    1) Les chiffres indiqués initialement sont moins nombreux.
    2) Cette réduction du nombre d’indices a été compensée avec l’apparition de quelques signes “inférieur à” et “supérieur à” placés entre certaines cases. Ces symboles < et > indique la relation entre les cases adjacentes.
    3) Les dimensions de la grille peut aller de 4×4 à 9×9 cases (en théorie, car cela devient vite trop compliqué au-delà de 6×6 cases).

    Dans cette adaptation bilingue (Français et Anglais) pour Oric, trois niveaux de difficulté vous attendent :
    1) Fastoche : avec 16 grilles de 4×4 cases à remplir avec les chiffres de 1 à 4. Ce niveau est surtout pédagogique, car ces grilles peuvent être aisément résolues.
    2) Faisable : avec 32 grilles de 5×5 cases à remplir avec les chiffres de 1 à 5. Ces grilles sont les plus intéressantes, car elles sont bien équilibrées entre difficulté et intérêt.
    3) Fortiche : avec 16 grilles de 6×6 cases à remplir avec les chiffres de 1 à 6. Elles vous demanderont probablement beaucoup de patience et de matière grise… avant de parvenir à les résoudre ! Les commandes sont simples et réduites au minimum :
    1) Les 4 flèches pour vous déplacer dans la grille.
    2) Un chiffre (de 1 à 4, 1 à 5 ou 1 à 6 selon la taille de la grille).
    3) FUNCT + chiffre pour placer une hypothèse.
    4) Chiffre 0 pour effacer une case.
    5) La touche R (Reset) pour recommencer la grille en cours.
    6) La touche S (Save) pour sauvegarder la grille en cours.
    7) La touche L (Load) pour recharger la grille précédemment sauvegardée.
    8) La touche B (Bruit) pour valider ou arrêter le clic de la touche FUNCT.
    9) Et pour finir, la touche Q (Quitter).

    Toutes les grilles ont évidemment une solution et peuvent être résolues avec un peu d’observation et de logique, sans avoir besoin d’y “aller au pifomètre”. La possibilité de placer des hypothèses dans les cases devrait vous aider dans les cas complexes.

    PS. Ce programme est également disponible sur http://andre.cheramy.net/oric.htm  Ce site contient notamment une section téléchargement très étoffée. Vous y trouverez tous mes programmes, des trucs et astuces, quasiment tous les livres connus sur l’Oric et le 6502, tout ce qui concerne le Super-Oric, etc. Hélas, il y a aussi plein de choses périmées ou pas mises à jour (merci pour votre compréhension, selon la formule usuelle débile). J’entre dans un âge avancé et il se pourrait que mon site disparaisse sans prévenir. Je vous invite donc à récupérer tous ce qui pourrait vous intéresser.
    Bien cordialement à vous tous.

    FutOricTélécharger

  • [Orix] Démarrage personnalisé par autoboot et submit

    Depuis la version du kernel v2023.1, il est désormais possible de personnaliser le démarrage d’Orix sur son atmos.

    Submit est un langage de scripting issu de CPM mais modifié par Assinie. Assine a fait le code pour Orix mais aussi a amélioré le fonctionnement afin d’intégrer des fonctionnalités en plus. Submit est un langage interprété.

    Autoboot est un fichier localisé dans le répertoire “/etc/” et va contenir un script submit. Ce script contenu dans le fichier autoboot sera lancé au boot de l’ordinateur ce qui permettra de personnaliser son boot, faire des menus etc.

    Si le fichier autoboot est présent, alors il sera démarré, sinon, cela démarrera normalement sans personnalisation. S’il y a besoin de bypasser ce démarrage par autoboot, il faudra faire un reset par exemple avec une touche quelconque appuyée. Cela va empêcher autoboot de démarrer et permettre d’accéder au shell directement.

    Le gros avantage du scripting, c’est que cela permet d’aller vite pour faire quelque chose sans avoir beaucoup de connaissances.

    Voici, donc, un tutorial qui va mettre en application un démarrage par autoboot.

    Prerequis

    • Avoir la twilighte board à jour avec le kernel v2023.1
    • submit version v2022.4 (vérifier avec ‘submit’)
    • un éditeur texte sur pc. Il y a un éditeur texte natif en cours de dev, mais il n’est pas finalisé, et donc, il faudra partir sur la clé usb branchée sur le pc, avec “/etc/autoboot” ouvert.
    • avoir tous les binaires Orix à jour : https://repo.orix.oric.org/dists/official/ sur la clé usb

    Pour demander au système de ne pas lire le fichier autoboot au démarrage, appuyer sur une touche au boot. Si autoboot doit être désactivé, il suffit d’aller dans /etc/, faire une copie d’autoboot avec ‘cp’, et supprimer le fichier autoboot

    Je veux démarrer blake’s 7 au démarrage

    Dans le script submit, je mets juste : 

    #!/bin/submit
blakes7

    Je sauve le fichier, je mets la clé usb, et je démarre l’oric.

    Blakes7 démarrera automatiquement

    Démarrage d’un menu personnalisé avec changement de fonte

    Cette fois ci, nous allons lancer un menu au boot. Le script suivant va :

    • effacer l’écran après le boot, mettre la fonte fanta2uk (les fontes sont localisées dans “/usr/share/fonts”).
    • afficher un menu avec des entrées “basic, blake’s 7, Psychiatric, barbitoric, et Orix” : ces choix sont volontaires car ils permettent de montrer les différents lancements, que cela soit à partir d’une rom, du storage, d’un jeu, ou d’une démo). La commande basic11 prend un argument qui est le nom du .tap à lancer (on peut le trouver en faisant un basic11 -l)
    • attendre une touche et lancer le programme sélectionné.
    #! /bin/submit
cls
setfont fanta2uk

@ 10,0
text
            +--------------+
             | 1 Basic         |
             | 2 Blake's 7   |
             | 3 Psychatric |
             | 4 Barbitoric  |
             | 5 Orix           | 
            +--------------+
endtext
:start
getkey
if key = 49 goto _basic
if key = 50 goto _blake
if key = 51 goto _psy
if key = 52 goto _barbitoric
if key = 53 goto prompt

goto start

:_basic
basic11

:_blake
blakes7

:_barbitoric
barboric

:_psy
basic11 "PSY

:prompt
exit

    Le résultat en image:

    Le résultat en vidéo:

    Ce script va lancer, en fonction de la touche pressée, l’entrée voulue (rom basic, blake, psychiatric, barbitoric ou revenir au shell). En revanche, une entrée de fonctionnera pas, c’est barbitoric (pour la version disponible au 7/06/2023).

    Pour expliquer pourquoi barbitoric ne fonctionne pas dans le cas où il est localisé dans un script submit, il faut se référer au fonctionnement d’un binaire Orix. Le problème ne se produit pas pour une commande en ROM, mais il peut se produire pour un binaire sur clé usb/sdcard.

    Au début du développement d’Orix, un seul format de binaire existait, c’est le fameux format statique que nous connaissons pour du basic, hyperbasic, commandes sedoric etc. Les programmes sont assemblés à une adresse fixe, et il y a conflit si on essaie de charger un programme qui est dans la même plage d’adresse : l’un va écraser l’autre. C’est ce qu’il se passe dans le cas de submit et barbitoric, mais ce n’est pas submit le fautif, c’est le binaire barbitoric en natif Orix. Submit est un binaire sur disque au format 2 Orix. Ce format est relogeable. Le kernel va allouer la plage mémoire disponible en fonction de la taille et reloger au runtime le binaire pour que submit puisse tourner à une nouvelle adresse. Submit tourne donc à une adresse inconnue par l’utilisateur, seul le kernel sait où submit est localisé en RAM. Aussi, Submit va faire des allocations mémoire pour sa propre utilisation.

    Ici, barbitoric n’est pas au format relogeable, et quand le kernel va essayer de le lancer, il va regarder s’il est au format 2, s’il est au format 1, le header du binaire définit une adresse fixe. Le kernel va vérifier si l’adresse est occupée. Comme submit a été lancé de manière relogée au 1er offset mémoire libre, il y a conflit et le kernel va renvoyer un “exec format error” qui sera affiché dans submit.

    Voici comment vérifier si un binaire est au format relogeable : Il faut utiliser le binaire file.

    Vous verrez que file n’indique pas que c’est un binaire relogeable pour barboric (nom du programme barbitoric) : 

    /#cd bin
/bin#file barboric

    Ci dessous, en rouge, le test sur le binaire barbitoric, en vert le même test sur le programme blakes7. Nous voyons bien dans ce cas “reloc binary” en vert

    Pour corriger le problème de barbitoric dans le cas de submit, il faut attendre la sortie de la version relogeable. Pour cela, le binaire est converti par un programme après un 1er build du code source.

    Les commandes en ROM n’ont pas besoin d’être relogées. Elles sont déjà résidentes en ROM, et ont été conçues pour ne pas écraser les autres commandes. Les commandes sont déjà dans des emplacements mémoire fixes, et gèrent les allocations mémoire de leur coté. De façon générale, les commandes en ROM sont plus rapides car elles sont déjà chargées, n’ont pas besoin d’être relogées et n’occupent pas de RAM dans les 48KB pour son propre code (à part pour les allocations mémoires nécessaires)

    Couleurs, caractères de contrôles

    Avant d’aller plus loin, l’idéal est de lire la doc “subdoc” en utilisant man. C’est une doc en français qui explique les possibilités de submit

    /#man subdoc

    Nous avons besoin de personnaliser un peu plus ce menu, et nous allons afficher un texte double hauteur avec quelques couleurs. Cela se fait avec les caractères de contrôle : 

    ink_black = ^@
ink_red = ^A
ink_green = ^B
ink_yellow = ^C
ink_blue = ^D
ink_purple = ^E
ink_cyan = ^F
ink_white = ^G

simple_height = ^H
simple_graph = ^I
double_height = ^J
blink_simple = ^L
blink_double = ^N

paper_black = ^P
paper_red = ^Q
paper_green = ^R
paper_yellow = ^S
paper_blue = ^T
paper_purple = ^U
paper_cyan = ^V
paper_white = ^W

    Nous allons modifier autoboot, pour afficher un bandeau avec sur fond bleu et en écriture rouge le mot menu en double hauteur, puis afficher un encadré magenta avec le menu.

    #! /bin/submit
cls
setfont fanta2uk
echo ^[T +-----------------------------------+
echo ^[T^[J|^[A               Menu         ^[G     |
echo ^[T^[J|^[A               Menu         ^[G     |
echo ^[T +-----------------------------------+

echo

echo ^[U
echo ^[U ^[P         1 Basic                   ^[U
echo ^[U ^[P         2 Blake's 7               ^[U
echo ^[U ^[P         3 Psychatric              ^[U
echo ^[U ^[P         4 Barbitoric              ^[U
echo ^[U ^[P         5 Orix                    ^[U
echo ^[U

:start
getkey
if key = 49 goto _basic
if key = 50 goto _blake
if key = 51 goto _psy
if key = 52 goto _barbitoric
if key = 53 goto prompt

goto start

:_basic
basic11

:_blake
blakes7

:_barbitoric
barboric

:_psy
basic11 "PSY

:prompt
exit

    Le résultat

    Pour aller plus loin

    Submit gère des variables, il est possible de les définir et de les sauver dans un fichier texte (save to myfile) et les restaurer. (restore from myfile)

    Submit lit des arguments en paramètre. Ainsi, un script en ligne de commande lancé par submit tel que 

    /#submit monscript.sub toto

    “toto” sera dans la variable $1, permettant de faire des tests avec if.

    Il est possible de tester la présence d’un fichier (if exist myfile.txt goto start)

    D’afficher un prompt avec input, et récupérer ce qui a été saisi dans une variable.

  • Jim Cuomo et l’Oric

    C’est 4 ans après que nous découvrons le décès de Jim Cuomo (Décédé en février 2018). Il était venu nous voir en 2004 à une visu. Et nous étions venu à un de ses concerts, cette même année à Paris (Jean amenant un microdisc et un Oric pour accompagner Jim.)

    Dans les années 80, Jim jouait avec un saxophone accompagné d’un Oric lors de ses concerts. L’oric jouait de la musique et affichait des graphismes.

    Jim Cuomo présentant l’oric apparemment à la TV

    Vous trouverez ci dessous une vidéo du concert de Jim en 2004 à Paris accompagné d’un oric.

    Retrouvez l’article sur ce concert ici dans un mag : https://www.oric.org/ftp/ceo/ceomag/downloads///2004/ceomag/10_october/174-13.pdf

  • Rapid’Oric

    Un jeu de puzzles logiques pour Rom 1.1 et Sedoric (Atmos réel, Euphoric ou Oricutron)

    par André C.

    Ce jeu a été inventé par Naoki Inaba sous le nom de “Nanba Burokku”. Par la suite, il a été renommé “Tectonics”, “Suguru” ou même “Number blocks”. La version Oric, adaptée aux possibilités de l’écran, bénéficie en outre d’une interface Français/Anglais.
    Le principe est simple : Le jeu se joue sur une grille. C’est la taille de la grille qui détermine la difficulté du jeu. Cette grille est divisée en zones de 1 à 5 cases, délimitées par des lignes épaisses. Le but du jeu est de remplir la grille avec des chiffres de 1 à 5 de telle manière que :
    1) Il n’y ait pas de chiffres identiques à l’intérieur d’une même zone.
    2) Il n’y ait pas de chiffres identiques dans les cases qui se touchent, même en diagonale.

    TROIS NIVEAUX DE DIFFICULTÉ POUR LA VERSION ORIC

    Les règles, qui sont simples, permettent au jeu d’être rapide, du moins pour le premier niveau de difficulté labellisé “Fastoche”. Ce niveau comporte 36 grilles de 4×5 cases pouvant être résolues en une à deux minutes chacune (ce qui vous occupera quand même pour un bon moment).

    Niveau “Fastoche”

    Les choses se compliquent avec le deuxième niveau “Faisable” dont les 24 grilles, comptent 9×5 cases. Ces grilles peuvent encore être résolues dans un temps raisonnable, mais le nom de “Rapid’Oric” que j’ai attribué à mon jeu commence à être un peu usurpé…

    Niveau “Faisable”

    Le troisième et dernier niveau “Fortiche” comporte 8 grilles de 11×9 cases et le jeu n’a plus rien de “Rapide”. Ces grilles sont réservées aux malades de la logique. Attention, vous risquez de vous arracher les cheveux (si vous en avez).

    Niveau “Fortiche”

    LES COMMANDES

    Pour résoudre ces grilles, vous disposez des commandes suivantes :
    -Les 4 flèches pour déplacer le curseur dans la grille.
    -FUNCT + flèche pour déplacer plus rapidement le curseur.
    -Touche de 1 à 5 pour placer un chiffre dans la case au curseur.
    -FUNCT + touche de 1 à 5 pour placer une hypothèse.
    -Touche 0 pour effacer la case au curseur.
    -Touche R pour Réinitialiser la grille en cours avec les valeurs de départ.
    -Touche S pour Sauver la grille en cours.
    -Touche L pour recharger (Load) la grille précédemment sauvée.

    UN PEU DE STRATÉGIE

    Il faut commencer par rechercher les zones ne comportant qu’une seule case, car elles ne peuvent contenir que le chiffre 1. Ensuite, vous pourrez peut-être trouver quelques chiffres dans les zones de 2 et 3 cases qui comptent forcément parmi les moins compliquées.
    Sinon, il faut rechercher les solutions les plus évidentes. Cette stratégie suffit en général pour les grilles “Fastoches”, c’est pourquoi elles sont si rapides à résoudre. Un peu plus de matière grise et de temps seront nécessaires pour les grilles plus grandes.

    Premier exemple, illustrant la progression des raisonnements logiques:

    Des extraits séquentiels d’une même grille sont rangés de gauche à droite

    On repère d’abord une zone mono-case et on y place le chiffre 1. Dans la zone située en dessous, une seule case peut recevoir le chiffre 2. Par suite, la place du chiffre 3 est évidente. Du coup, dans la case du dessus, le chiffre 3 ne peut aller qu’à un seul endroit. Les positions du 4, puis du 5 ne posent alors aucun problème. Et ainsi de suite, jusqu’à résolution de toute la grille…

    Deuxième exemple, emprunté à une grille plus complexe:

    Les extraits successifs de cette grille sont rangés de gauche à droite, puis de haut en bas.

    Ici encore on commence par une zone mono-case qui reçoit avec plaisir le chiffre 1. Dans la zone de 5 cases située au-dessus, le 1 ne peut être placé qu’à un seul endroit. On en profite pour renseigner la zone bi-cases située encore au-dessus en y plaçant les chiffres 1 et 2. Intéressons-nous à la zone de 5 cases en croix située au milieu de l’extrait, car le chiffre 4 ne peut aller qu’à un seul endroit. Par suite, plaçons le chiffre 5, puis le 2 et enfin le 1.
    La bonne stratégie consiste à tourner autour de ce bloc central de cases résolues. C’est ainsi qu’on trouve où mettre les chiffres 1 et 2 dans les zones adjacentes. J’attire votre attention sur le chiffre 2 ajouté dans le dernier extrait.
    La stratégie illustrée dans ce cas vous sera souvent très utile lorsque le jeu semblera bloqué. On effet, si on fait le bilan de ce que cette case pourrait contenir, on voit que les chiffres 1, 3, 4 et 5 sont interdits (règle n°2) et donc que seul le chiffre 2 peut y être placé.
    Il arrivera évidemment que plusieurs chiffres semblent possibles (à un moment donné) pour une même case. L’utilisation de la touche FUNCT vous permettra d’y placer des hypothèses. Ne perdez pas de vue que les hypothèses ne représentent pas seulement des possibilités, elles permettent aussi de statuer sur le contenu éventuel des cases adjacentes.
    Toutes les grilles ont bien sûr une solution, n’en doutez pas.
    En toute bonne logique… la logique finira par triompher !

    Rapid’Oric version corrigéeTélécharger

  • 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

  • UNDEL

    Utilitaire Sedoric pour récupérer des fichiers après un DEL

    Catastrophe : Tout votre travail  est perdu à cause d’un DEL malencontreux ! Et vous étiez tellement dans l’action que, bien sûr, vous n’avez pas sauvegardé depuis un bon moment. Le piège principal (mais pas que) est dû à la commande DEL”*.*” pour laquelle il faut confirmer par Y ou N si chacun des fichiers est à supprimer ou pas. Une erreur est vite arrivée…

    Pas de panique rien n’est perdu, mais de grâce n’écrivez plus rien sur cette disquette ! Et si possible, protégez-là en écriture, faites-en une copie et opérez sur la copie.

    Petit historique

    L’envie de faire cet utilitaire m’est venue en 1995, en écrivant l’annexe n° 9 : “Que se passe-t-il lors d’un DEL ?”, à la page 511 de “Sedoric 3.0 à nu”. Et depuis lors, ce projet n’a pas bougé de ma liste “Tout doux” ! Au fil du temps, quelques Oriciens se sont adressés à moi pour récupérer leur travail effacé par erreur, ce qui a renforcé ma motivation. Mais c’est le corona qui m’a fait passer à l’acte…

    Quelques précisions

    Le programme UNDEL est écrit en Basic 1.1 et utilise plusieurs instructions Sedoric sans équivalent dans les autres DOS. Par conséquent, il ne tournera que sur un système équipé d’une Rom 1.1 et sous Sedoric. Il s’agit typiquement d’une configuration Atmos + Microdisc + Sedoric. UNDEL fonctionne avec tout système émulant cette configuration (Euphoric et Oricutron testés). Il est inutile de l’essayer avec un Oric-1 ou avec un Telestrat sous Hyper-Basic. Les instructions Sedoric PMAP, SMAP, CRESEC, FRESEC, etc. sont incontournables et si vous voulez vous en passer, il faut réécrire leur équivalent en code machine.

    Base technique du problème

    Que se passe-t-il lorsqu’on écrit un fichier avec SAVE*, ESAVE ou COPY* ? :

    Dans l’ordre : Un descripteur est créé, un ou plusieurs secteurs du fichier proprement dit sont enregistrés à la suite, les 2 secteurs de bitmap sont ajustés (plusieurs secteurs sont marqués occupés, le nombre de fichiers présents sur la disquette est incrémenté, le nombre de secteurs libres est réduit) enfin une entrée est ajoutée au directory et l’offset de la prochaine entrée libre est ajusté. Il est à noter que le descripteur est toujours écrit sur le 1e secteur libre à partir du début de la bitmap. Le ou les secteurs du programme proprement dit sont écrits, dans l’ordre, sur les secteurs libres suivants, qui ne sont pas forcément contigus lorsque la disquette a déjà subi plusieurs écritures / suppressions.

    Que se passe-t-il si on supprime un fichier avec DEL, DELBAK ou DESTROY ? :

    Lorsqu’il efface un fichier, SEDORIC ne modifie en fait que les secteurs de bitmap et de directory.

    L’entrée du directory est remplacée par des #00 et l’offset de la prochaine entrée libre est réajusté. Les 2 secteurs de bitmap sont actualisés (plusieurs secteurs sont libérés, le nombre de fichiers présents sur la disquette est réduit, le nombre de secteurs libres est augmenté). MAIS ni le secteur de descripteur, ni le ou les secteurs du fichier proprement dit ne sont modifiés.

    Ils restent intacts et sont seulement marqués “libres” dans la bitmap. Il n’y a donc aucun problème tant qu’un nouveau fichier n’est pas écrit dans ces secteurs libérés (et ce sera malheureusement en priorité sur ceux-là). Comme vous pouvez l’imaginer, il est techniquement possible de récupérer le fichier supprimé en restaurant l’entrée de directory, les secteurs de bitmap, quelques liens, etc.

    Et lorsque plusieurs fichiers ont été supprimés ? :

    Pas de problème tant qu’aucune écriture n’est opérée sur la disquette. Il faut relancer UNDEL plusieurs fois, jusqu’à ce qu’il ne trouve plus rien. Pour mes tests, j’ai effacé une disquette 80 pistes de 17 secteurs, double face qui était bourrée de fichiers de toutes sortes avec un DEL”*.*” et j’ai pu tout récupérer avec UNDEL !

    Et si malheureusement une écriture a été faite ?

    Là, il est plus hasardeux de restaurer spécifiquement le fichier qui vous intéresse. Mais ce n’est pas forcément perdu si celui-ci est mappé assez loin dans la bitmap. La localisation des fichiers dans la bitmap n’a rien à voir avec l’ordre des suppressions. En outre, après plusieurs écritures / suppressions, les fichiers sont fragmentés et la disquette est truffée de résidus. Ceci implique un algorithme de restauration assez complexe. Mais le miracle est possible !

    Le programme UNDEL pour Sedoric

    Sedoric a subi quelques modifications au fil du temps (par exemple ajout d’un 2e secteur de bitmap pour passer aux disquettes 3.5″, ajout d’un système de sous-directory, etc.). Dans un premier temps, je me suis concentré sur la version 3.0 de Sedoric, parce que c’est celle que je connais le mieux pour l’avoir dépiautée en détail. Mais quelques vérifications à postériori montrent que UNDEL marche avec les disquettes de toutes les versions de Sedoric. Il est même possible de récupérer des fichiers (simples ou mergés) de disquettes Stratsed car la structure de celles-ci est très proche de celle des disquettes Sedoric.

    Structure d’un fichier Sedoric

    Du plus simple, qui est un fichier “ordinaire” occupant moins de 123 secteurs, au plus compliqué, formés de plusieurs fichiers mergés, il est possible de dresser le schéma général suivant :

    Un fichier “ordinaire” est composé comme suit :

    -Le descripteur principal (obligatoire) du fichier, qui liste le ou les secteurs qu’il faut charger pour mettre le fichier en place dans la Ram. Si nécessaire, un lien vers un éventuel descripteur secondaire est renseigné.

    -Le ou les secteurs du fichier proprement dit, listés dans ce descripteur principal.

    -Un descripteur secondaire, s’il reste des secteurs à lister dont les coordonnées n’ont pas pu être insérées dans le ou les descripteurs précédents, faute de place.

    -Après ce descripteur secondaire, se trouvent les secteurs listés dans ce descripteur.

    -Si cela ne suffit pas, un autre descripteur secondaire est ajouté, etc.

    -Chaque descripteur est relié au suivant par un lien. Le lien du dernier descripteur du fichier est mis à zéro pour indiquer qu’il n’y a plus rien après.

    -Chacun de tous ces éléments (descripteurs et secteurs du fichier proprement dit) est écrit sur le prochain secteur libre. Après plusieurs écritures / suppressions, la disquette est parsemée de “trous” (secteurs libres isolés). Mais les divers morceaux d’un fichier sont toujours écrits dans le bon ordre, même s’ils ne sont pas forcément contigus. -Les informations propres à un fichier sont données dans l’entête de son descripteur principal. Ce sont : Le type de fichier, les adresses de début, de fin et d’exécution, le nombre total de secteurs à charger pour mettre l’ensemble de ce fichier en place. Cet entête est suivi par la liste (ou le début de la liste) des secteurs à charger. Les descripteurs secondaires ne comportent que le lien vers le descripteur suivant et la suite de la liste des secteurs à charger.

    Les fichiers “mergés” sont formés comme suit :

    Plusieurs fichiers “ordinaires” peuvent être rassemblés sous un même nom, on dit alors qu’ils sont “mergés”, ce qui est impropre car “merged” signifie “fusionnés”. Or les fichiers restent intacts et sont seulement juxtaposés. Ils sont mis à la queue-leu-leu, sans être modifiés, sauf les liens entre les différents descripteurs qui sont chaînés : Le dernier lien de chaque fichier “ordinaire” (normalement mis à zéro) est remplacé par l’adresse du descripteur principal du fichier mergé suivant. Et ainsi de suite, jusqu’au dernier descripteur dont le lien est bien sûr maintenu à zéro. Aucune autre modification n’est effectuée. La taille globale de l’ensemble ne figure qu’au niveau de l’entrée de directory correspondant à cet ensemble de fichiers mergés. Seul le nom du premier fichier est retenu et figure dans cette entrée. Les secteurs de ces différents fichiers, sont écrits à la queue-le-leu et dans le bon ordre, mais ne sont pas forcément contigus.

    Et un peu plus de détails sur ce qui se passe lors d’un DEL

    L’information cruciale est qu’après un DEL, le ou les “blocs” (descripteur + secteurs à charger) restent en place sans la moindre modification. Seuls la bitmap et le directory sont affectés : Toute trace de l’existence du ou des fichiers est complétement effacée. De plus, l’ordre des entrées est remanié pour récupérer de la place, mais pas toujours complètement remanié, car il reste des trous. Je n’entre pas dans l’explication de ce phénomène, sans intérêt pour le propos d’aujourd’hui.

    Alors quel est le bilan de la situation ?

    1) Dans la bitmap, tous les secteurs correspondant au fichier supprimé (descripteurs et secteurs) ont été marqués libres (réutilisables), bien que les secteurs en question soient toujours en place. Il faut noter que les fichiers effacés ne sont pas récupérables dans l’ordre de leur effacement, mais dans l’ordre de leur représentation dans la bitmap. La prochaine écriture sur la disquette va écraser en priorité les secteurs libérés qui figurent à partir du début de la bitmap et ce ne sont pas forcément ceux libérés par le dernier DEL. Donc, avec un peu de chance, il est PEUT-ETRE encore possible de récupérer le fichier qui vous intéresse, même si une écriture a eu lieu après le DEL. Dans la bitmap encore, le nombre de secteurs libres est bien sûr augmenté du nombre de secteurs libérés, tandis que le nombre de fichiers est décrémenté. Le nombre de secteurs de directory peut éventuellement avoir été réduit. Heureusement, toutes ces informations sont récupérables.

    2) Dans le directory, l’entrée correspondant au fichier supprimé a tout simplement été effacée, créant ainsi une entrée libre. Comme déjà indiqué, les entrées restantes ont éventuellement et partiellement été réorganisées pour gagner de la place. Une entrée supprimée, cela veut dire que les informations  suivantes ont disparu :

    -Le nom et l’extension du fichier.

    -Les coordonnées piste et secteur du descripteur principal du fichier.

    -Le nombre total de secteurs occupés par le fichier (ou les fichiers s’il s’agit de fichiers mergés). -L’attribut de protection du fichier.

    Stratégie utilisée par UNDEL

    Phase 1 : Retrouver le premier descripteur du fichier

    Coup de chance, le premier secteur libre de la disquette est forcément un descripteur principal. Si ce n’est pas le cas, soit aucun DEL n’a été effectué, soit une écriture est intervenue après le dernier DEL. On a ça par exemple lorsqu’un fichier est écrit et ne surcharge que partiellement un fichier précédemment détruit et si celui-ci était plus gros. Il reste des secteurs “libres” qui ont toutes les chances de ne pas être un descripteur. UNDEL sait gérer cette situation de manière appropriée. A l’issue de cette phase, ce premier descripteur est restauré, ainsi que les secteurs qui y sont listés. Mais le descripteur principal trouvé est-il bien celui du fichier que nous voudrions récupérer ? Si plusieurs DEL ont été effectués et que le descripteur qui nous importe ne correspond pas au premier secteur libre, il faudra recommencer l’opération de sauvetage plusieurs fois, jusqu’à ce que le bon soit trouvé et restauré.

    Phase 2 : Examiner le lien vers le descripteur suivant

    Si ce lien est nul, il n’y a aucun descripteur suivant, notamment pas de descripteur de fichier mergé. Il ne reste plus qu’à finaliser l’entrée de directory et la bitmap (voir plus bas “Phase 4”). Au contraire, si ce lien n’est pas nul, il indique la localisation piste/secteur du descripteur suivant, qui peut être soit un descripteur secondaire du même fichier, soit le descripteur principal d’un fichier mergé. Comment départager ces 2 hypothèses ?

    Phase 3 : Examiner s’il reste des secteurs à charger pour le fichier en cours

    Le descripteur principal nous a indiqué le nombre total de secteur à charger pour mettre en place le fichier en cours. Sachant qu’un descripteur principal peut lister les coordonnées de 122 secteurs et un descripteur secondaire celle de 127 secteurs, il est facile de calculer s’il reste des secteurs qui ne sont pas encore listés. Si c’est le cas, le descripteur trouvé est un descripteur secondaire. Sinon le descripteur trouvé est le descripteur principal d’un fichier mergé. En résumé, il n’y a que 3 possibilités : Soit c’est fini, soit il y a encore un descripteur secondaire, soit il y encore un descripteur principal de fichier mergé. Le programme rebouclera au niveau voulu selon le cas. Le descripteur trouvé est restauré, ainsi que les secteurs qui y sont listés. Après plusieurs éventuelles réitérations et quelle que soit sa complexité, le fichier proprement dit est entièrement restauré. Il ne reste plus qu’à finaliser l’entrée de directory et la bitmap.

    Phase 4 : Créer une entrée de directory pour ce fichier

    Lorsque le dernier descripteur du fichier ainsi que les secteurs correspondants ont été restaurés, il faut créer une entrée dans le directory. Partant du 1er secteur de directory (le secteur 4 de la piste 20) on recherche la première entrée libre. S’il n’y en a pas, on passe au secteur de directory suivant, etc. Si on atteint le dernier secteur de directory sans avoir trouvé d’entrée libre, il faudra créer un nouveau secteur de Directory dont la première entrée sera l’entrée libre voulue. On écrit alors dans l’entrée libre les informations suivantes :

    -Le nom et l’extension du fichier. Par défaut ce sera SANSNOM.COM, ce qui impliquera de renommer le fichier avant de relancer UNDEL pour en restaurer un autre.

    -Les coordonnées piste et secteur du descripteur principal du fichier. Ces données ont été trouvées lors de la phase 1.

    -Le nombre total de secteurs occupés par le fichier. C’est la somme du nombre de secteurs à charger pour mettre en place le fichier (simple ou mergé) et du nombre total de descripteurs.

    -L’attribut de protection du fichier. Par défaut, il sera positionné sur PROT (qui ne gêne pas si on veut renommer le fichier !). Finalement l’adresse de la prochaine entrée libre est mise à jour (ou à zéro si on vient d’écrire sur la dernière entrée libre du secteur de directory).

    Phase 5 : Finaliser la bitmap

    La bitmap proprement dite (représentation des secteurs en fonction de leur occupation / disponibilité) a été mise à jour au fur et à mesure de l’avancée des phases précédentes. Reste à finaliser l’entête ou plutôt les deux entêtes, car la bitmap occupe deux secteurs. Les données à mettre à jour se réduisent à :

    -Le nombre de fichiers (ancienne valeur plus un)

    -Le nombre de secteurs de directory (peut éventuellement avoir été augmenté). Le nombre de secteurs libres a été mis à jour au fur et à mesure des phases précédentes et il n’y a pas à s’en occuper.

    Phase 6 : Renommer le fichier restauré

    La récupération du fichier est terminée. L’affichage des caractéristiques de ce fichier (type de fichier, adresses de début, de fin, d’exécution et nombre de secteurs occupés) vous permettra de comprendre de quel fichier il s’agit et de le renommer correctement. S’il ne s’agit pas du fichier que vous vouliez ou si vous en avez plusieurs à récupérer, il suffit de relancer UNDEL (après avoir renommé SANSNOM.COM).

    Et si une écriture a eu lieu après le ou les DEL ?

    Je pensais au départ que l’absence d’écriture après la suppression était un impératif absolu. Mais comme je l’ai déjà indiqué, les fichiers effacés ne sont pas récupérable dans l’ordre de leur effacement, mais dans l’ordre de leur représentation dans la bitmap. D’autre part, les écritures se font à partir du début de la bitmap. Il est donc possible de récupérer un fichier effacé, s’il n’est pas en tête de bitmap. Après la suppression de plusieurs fichiers, il est possible qu’il existe encore plusieurs fichiers récupérables, même s’il y a eu écrasement de l’un d’entre eux après une écriture malheureuse ! Après avoir reçu un avertissement d’échec, vous avez la possibilité de demander à UNDEL de rechercher s’il n’existe pas encore quelque chose à restaurer sur la disquette. Les nombreux essais, que j’ai effectués, montrent que ça marche assez bien.

    Conclusion

    Que ce soit avec un Atmos réel ou avec un émulateur (Euphoric et Oricutron ont été testés), vous pouvez sans crainte récupérer tous les fichiers effacés par erreur. Et même après une écriture, il reste une chance que tout ne soit pas perdu. Le programme UNDEL est solide et je suis sûr qu’il vous donnera entière satisfaction. Bien que je n’aie jamais rencontré de problème au cours de mes très nombreux essais avec Sedoric 3.0, je vous conseille quand même de protéger votre disquette originale et de travailler sur une copie, on ne sait jamais ! Le zip qui accompagne cet article contient non seulement les fichiers Undel.dsk et Undel.tap, mais aussi des fichiers .txt très commentés,  au cas où vous voudriez retoucher le programme…

    Undel.zipTélécharger

  • Interview: Hervé Lange, auteur du Secret de Kaïpur

    Le Secret de Kaïpur est probablement l’un des plus gros jeux d’aventure Oric sortis sur cassette. Il n’a pas connu un grand écho à l’époque, mais des années plus tard le soin apporté aux graphismes a retenu l’attention des Oriciens. Et c’est là que l’on découvre que son auteur n’est autre que Hervé Lange, auteur des succès Fer et Flamme sur Amstrad, et B.A.T. sur Atari ST et Amiga. Interview !

    – 8 août 2020 –
    CEO- Bonjour M. Lange. Pouvez-vous vous présenter en quelques mots ?

    Salut Simon, je m’appelle Hervé Lange. Je suis Français d’origine mais je vis actuellement au Canada où j’ai acquis la double citoyenneté, et je suis le papa heureux de trois enfants. Doué pour le dessin, passionné par les machines, j’ai toujours été intéressé par les possibilités de relier ces deux univers: le jeu vidéo m’est apparu tout naturellement comme un terreau propice d’une part à nourrir ce désir de mariage, et d’autre part pour pouvoir mettre en oeuvre mes propres histoires et réalisations. J’ai donc très tôt eu la chance de développer des histoires interactives et ce dès le début des années 1980 lorsque les micro-ordinateurs sont devenus accessibles au grand public, ce qui fait de moi une sorte de pionnier dans ce domaine. Par la suite, mon histoire est jalonnée de plus de 40 années de projets de jeux vidéo publiés ou abandonnés et d’outils numériques pour aider à la création numérique sur toutes sortes de systèmes, et la passion ne m’a jamais quittée !

    CEO- Quelle est votre histoire informatique, comment avez-vous décidé de vous lancer dans les jeux vidéo ?

    La découverte des micro-ordinateurs pour moi a commencé chez un ami dont le père avait pu se payer un TRS-80 avec lequel nous avons commencé à apprendre le BASIC. Il y a eu aussi le Centre Mondial Informatique à Paris ou j’ai pu m’essayer sur des ordinateurs Goupil ou Apple II en BASIC et en Logo. Puis en 1982 mes parents ont acheté un Oric 1 a mon frère que j’ai pu récupérer. J’ai rapidement commencé à coder des petits jeux par exemple pour amuser ma grande soeur. Mes programmes grossissaient et j’avais besoin d’une imprimante, alors je me suis rendu au magasin Vismo à Paris ou j’ai rencontré Philippe Derambure qui montait sa boite de jeux vidéo France Logiciel. Il cherchait des programmes de jeu et le courant a passé de suite dès qu’il m’a fait une ristourne sur le prix de l’imprimante :-), bref et je lui ai dit que je reviendrai avec un jeu en septembre sans savoir dans quoi je m’engageais. J’ai travaillé comme un fou pendant mes vacances scolaires sur ce programme: c’était le Secret de Kaïpur! De septembre à décembre 1984 j’ai terminé le programme avec l’aide de Philippe pour le publier.

    Jaquette du Secret de Kaïpur

    CEO- Outre « Le Secret de Kaïpur » qui nous a permis d’entrer en contact, êtes-vous l’auteur d’autres programmes sur Oric ?

    Ce jeu fut mon seul programme commercial sur Oric. J’adorai l’Atmos mais Philippe ayant fleuré l’ascension inéluctable de l’Amstrad CPC, il m’a procuré un 464 en me commandant un nouveau jeu pour cette machine et au plus vite – ce fut mon second jeu commercial: Le Bagne de Nepharia. A noter que Nepharia avait été pensé pour que je puisse le porter sur l’Atmos mais comme l’Oric déclinait, c’est malheureusement tombé à l’eau car France Logiciel ne pouvait pas engager des frais de duplication sans une garantie minimum de revenus.

    CEO- Même des programmes non commercialisés ?

    Pour des programmes non commerciaux, je me rappelle par exemple d’un programme de visualisation de la navette spatiale (genre CAO) et ou l’on pouvait faire apparaître ou animer vectoriellement différentes parties de la navette en appuyant sur différentes touches du clavier de l’Oric. J’avais aussi écrit un petit jeu d’arcade du doux nom de “Ant eater” ou le joueur incarnait une petite fourmi noire devant traverser des lignes de fourmis rouges voraces, un peu a la Froggy.

    CEO- Pouvez-vous nous raconter la genèse du Secret de Kaïpur ?

    Lorsque j’ai rencontré Philippe, j’avais déjà en tête l’idée de faire un jeu d’aventure qui s’inspirait des romans noirs. Mais les influences sont venues d’une part du film Indiana Jones et d’autre part du jeu Time Zone sur Apple II, et donc de combiner un aventurier au chapeau et des voyages dans le temps. D’ailleurs cette idée de voyage dans le temps a sûrement contribuée à la grosseur du jeu: c’était plusieurs jeux d’aventure pour chacune des époques qu’il fallait réaliser !

    CEO- Le jeu est crédité Hervé et Thierry Lange. Quelle a été la part de chacun ?

    Thierry m’a principalement aidé pour le texte du manuel; c’est moi qui ai conçu seul le jeu, le programme et réalisé tous les graphismes. Mais j’utilisais sa machine, alors en bon grand frère il m’avait donné un bon coup de pouce !

    CEO- Comment avez-vous conçu les superbes écrans graphiques, depuis l’idée jusqu’à leur concrétisation sur l’Oric ?

    Je faisais beaucoup d’esquisses au crayon puis directement en programmant les dessins un à un en BASIC, ligne après ligne! Mon choix de faire du vectoriel me permettait cependant de combiner des sous-routines du programme pour composer des scènes (par exemple avec les poses du héros), et en fonction également des interactions précédentes (objets pris ou pas, etc.), et l’utilisation mémoire mais probablement au détriment de la vitesse d’affichage. A noter que chez moi je ne disposais que d’une vieille télévision noir et blanc qui me faisait office de moniteur, et que c’est chez Philippe que j’ai pu disposer d’une télévision couleur pour ajouter un peu de couleur à mes dessins.

    CEO- Avez-vous souvenir de difficultés ou d’anecdotes particulières liées à la création du jeu ?

    Je me rappelle que l’Atmos est sorti alors que les cassettes venaient juste d’être dupliquées, et qu’il a donc fallu adapter le manuel pour régler un petite problème de compatibilité, heureusement réglable en écrivant un petit programme avant de lancer le jeu. C’est assez cocasse et ca montre bien le côté amateur de l’époque: vous vous imaginez maintenant devoir taper un petit programme avant de lancer un jeu !

    CEO- Comment avez-vous réussi à l’époque à faire éditer le jeu ? France Logiciel a-t-elle publié d’autres jeux Oric ?

    Une autre petite anecdote est que quand j’ai rencontré Philippe a Vismo, il a sorti son calepin pour prendre mon adresse et m’a montré les dizaines de jeux que des développeurs amateurs comme moi lui avaient promis, il y avait apparemment pas mal de compétition! En septembre on s’est revus dans une cafétéria (mon premier rendez-vous d’affaire !) et je lui avais amené le gros listing du jeu, pour lui montrer que j’avais fait le travail et fait bon usage de son imprimante. Philippe était super content car j’étais en fait le seul de son calepin à être revenu avec quelque chose, et il avait un programme de jeu à publier ! France Logiciel n’a publié que deux programmes Oric: le mien et un quizz de cinéma si je me rappelle bien, Philippe s’en rappellerait surement mieux.

    CEO- Combien de temps aura duré le développement du Secret de Kaïpur ?

    Le développement s’est étalé sur cinq mois de juillet à novembre 1984: deux mois à plein temps pendant les vacances scolaires où 80% du jeu a été écrit, puis les week-ends et les soirées pendant les trois mois restant vu que j’étais toujours étudiant – donc je dirais un gros trois mois à temps plein.

    CEO- Avez-vous conscience d’avoir écrit ce qui reste sans doute le plus imposant jeu cassette sur Oric ? (216Ko !)

    Pas du tout, c’est toi Simon qui me l’apprends !

    CEO- Le jeu a-t-il connu un grand succès, ou du moins le succès escompté ? (une idée du nombre d’exemplaires produits et vendus ?)

    Pas vraiment de succès mais France Logiciels était une petite structure et ne pouvait même pas se payer un petit encart de publicité dans les magazines de l’époque. Alors on comptait sur le bouche à oreille. Le Secret de Kaïpur s’est vendu à plusieurs centaines d’exemplaires, mais moi j’étais très content car je pouvais enfin me payer un moniteur couleur pour mes prochains jeux, et montrer a mes parents que mes nombreuses heures passées sur l’Oric produisaient quelque chose de tangible!

    CEO- Avez-vous eu des retours de joueurs à l’époque ?

    Pas du tout, on avait très peu d’informations une fois le jeu sorti, et c’est vrai même plus tard pour mes jeux CPC (à part les articles de presse bien sûr). Paradoxalement d’ailleurs et des décennies plus tard grâce à l’internet, j’ai plus de retours avec les retrogamers qui me posent des questions et me livrent leurs impressions!

    CEO- Avez-vous été ennuyé à l’époque par des problèmes de fiabilité des cassettes ? Aviez-vous envisagé une version sur disquette ?

    Oui souvent et c’était toujours un risque, et il me semble que l’on avait essayé divers types de magnétophones et de marques de cassettes pour trouver ce qui donnerait une garantie plus fiable à chaque sauvegarde. Il y avait une blague que Philippe faisait genre “t’es sûr que tu as bien enregistré avant que j’éteigne le bouzin ?”, ce à quoi je répondais “oui, oui c’est fait !”, et Philippe de dire: “ré-enregistre une fois de plus dessus, histoire que les bits soient bien bien incrustés…”, c’était récurrent et on en riait. On travaillait de chez nous et ma hantise c’était la panne d’électricité avant que le programme ne soit enregistré (on enregistrait peu car celà prenait du temps). Une fois à la campagne, ça m’est arrivé: une coupure de courant très brève qui avait avait laissé mon programme visible sur l’écran mais je ne pouvais plus rien sauvegarder – l’enfer – j’ai dû recopier ce que je voyais sur des feuilles de papier avant de redémarrer l’Oric et de retaper le programme en entier! A la fin du développement, Philippe avait acheté un lecteur de disquette Jasmin pour l’Atmos si je me rappelle bien, mais nous n’avons jamais envisagé de vendre le jeu sur disquette car peu de gens en avaient un.

    CEO- Le jeu contient quelques fautes d’orthographe (“Mommie”, “Jetter”). Est-ce qu’une version corrigée a existé ? (comme pour “Le Mystère de Kikekankoi” par exemple)

    Non pas de version corrigée à ma connaissance! D’ailleurs si j’avais pu faire ces correctifs, j’aurais sûrement voulu trouver un moyen d’ajouter des accents.

    CEO- Vous souvenez-vous de la logique de déplacement dans le Secret de Kaïpur, assez déroutante, où faire “nord” puis “sud” vous ramène parfois dans un lieu différent ?

    Je me rappelle que le jeu a été critiqué pour ça. En fait je pense que c’est mon erreur qui a mélangé certaines fois directions cardinales et directions relatives au personnage lors du codage du jeu, probablement pour réconcilier des incohérences de carte et de graphisme. A l’époque, on n’avait pas de testeurs, et donc la famille ou des copains curieux testaient les jeux sans oser contredire la logique parfois tordue de son créateur 🙂 Bref ce n’était sûrement pas le meilleur service de test !

    CEO- Pouvez-vous nous décrire un peu la société France Logiciel ? Y avait-il des salariés, des locaux ?

    Une toute petite compagnie, pas de locaux au départ et juste Philippe qui de son domicile s’occupait un peu de tout mais je crois était aidé par sa femme côté gestion financière. Des copains pour aider comme le dessin des jaquettes.

    CEO- Avez-vous gardé des contacts avec d’autres auteurs sur Oric ou avec des dirigeants de sociétés ?

    Pas sur la période Oric, mais plus mes anciens compagnons de Computer’s Dream avec qui nous avons fait les jeux BAT ou les anciens d’Haïku Studio. Sur Oric je me rappelle que j’avais rencontré avec bonheur Patrice Guerlais, l’auteur de l’excellent Lorigraph mais je ne l’ai pas revu depuis!

    CEO- Utilisez-vous encore un Oric (ou émulateur) de temps en temps, ou avez-vous tourné la page depuis longtemps ?

    J’ai un Oric 1, un Atmos et de nombreux jeux y compris des originaux mais j’ai perdu les câbles alors je ne peux plus les utiliser. J’ai le projet bien sûr de récupérer des câbles pour les refaire tourner et montrer ça aux enfants lorsque je trouverai un peu de temps libre pour ca!

    CEO- Gardez-vous un souvenir particulier de cette machine ?

    En réalité je n’étais pas super fan de l’Oric 1 avec ses 16 KB et son clavier de calculatrice. Quand l’Atmos est apparu disposant de plus de mémoire et surtout d’un clavier mécanique plus ergonomique à mon goût, je l’ai tout de suite adopté en espérant que tout le monde allait passer à ce modèle! Il y avait tout de même beaucoup de limitations sur ces petits 8-bits (pas uniquement l’Oric) comme le colour-clash de 8 pixels, mais comme c’est sur ces machines que j’ai réalisé mes premiers programmes, elles ont une place toute particulière dans mon coeur.

    CEO- Quel regard portez-vous aujourd’hui sur cette période ?

    C’était une période bénie de création ou l’on devait tout débroussailler ce qui nous donnait des opportunités d’innovation inouïe! On était les premiers auteurs d’un monde nouveau et on voulait juste faire des jeux, éventuellement gagner un peu d’argent pour pouvoir toujours continuer. Par ailleurs, la limitation des machines poussait les créateurs vers l’abstraction, le pixel-art, ce qui a produit selon mon opinion une diversité de styles riche et amusante… Loin des canons photoréalistes modernes.

    CEO- Avez-vous des réticences sur la diffusion (gratuite bien sûr) de vos softs Oric par le Club Europe Oric, ou sur Internet ?

    Aucune réticence, je suis plutôt flatté que vous portiez encore un peu d’intérêt à mon premier jeu commercial, alors c’est plutôt un grand merci à vous le Club Oric!

    CEO- Vos armoires renferment-elles des softs non diffusés, des sources, des cassettes oubliées, des photos de l’époque ?

    Peu de choses de l’époque Oric, mais un peu plus d’archives et des versions bêta de jeux non publiés par exemple sur PC CD-ROM de l’époque Haïku Studio. J’ai tout de même un original du Secret de Kaïpur, comme de mes autres jeux.

    CEO- Pouvez-vous nous en dire un peu plus sur votre parcours depuis ? Vous êtes célèbre notamment pour le jeu B.A.T.

    Par la suite j’ai réalisé plusieurs jeux sur Amstrad, Atari ST et Amiga sous le label Ubi Soft, dont les plus connus sont les RPG “Fer & Flamme” sur CPC et les jeux B.A.T. sur Atari et Amiga. En 1993 j’ai été cofondateur du studio Haiku Studio où nous avons produit des jeux sur PC et consoles pour différents éditeurs internationaux, avant sa fermeture en 1997. Puis j’ai travaillé sur différents projets innovateurs de storyboarder 3D exploitant les techniques plus accessibles du jeux vidéo pour le film, notamment pour la société Duran Duboi, puis en collaboration avec le réalisateur Marc Caro. Je suis revenu aux jeux vidéo lors de mon installation au Canada pour le compte de la société Behaviour Interactive où j’ai participé à la mise en oeuvre de jeux consoles et de jeux en ligne MMO, mobile et Facebook. En 2006 j’ai co-fondé xtranormal.com, une start-up de storytelling en ligne qui n’a pas résistée à la crise de 2008. Finalement je travaille depuis plusieurs années pour la société Autodesk sur des outils de modélisation et d’animation 3D pour les jeux et les films.

    CEO- Quelle période de votre carrière vous a rendu le plus heureux, ou vous rend aujourd’hui le plus nostalgique ?

    S’il faut n’en choisir qu’une c’est assurément la période juste après BAT1 où je n’avais plus d’obligations (plus d’école, plus d’armée) et je pouvais me consacrer à 100% sur mes créations. L’équipe de BAT venait de fonder un petit label du nom de Computer’s dream soutenu par Ubi soft, et je découvrais l’Amiga qui fût sans aucun doute la machine que j’ai préféré programmer toutes périodes confondues. On travaillait sur un nouveau jeu très original du nom de Xanathan pour l’Amiga, dont les premiers prototypes étaient superbes, et je commençais à implémenter des routines d’IA bien plus complexes, et ce pendant qu’une autre équipe développait BAT2 a partir de mon game design. Ce fût de courte durée et nous avons dû abandonner Xanathan à la demande d’Ubi pour nous porter au secours de BAT2 qui n’avançait pas.

    Cette photo résume très bien cette période:

    CEO- A quels hobbies vous consacrez-vous aujourd’hui ?

    Lorsque mes enfants me donnent un peu de temps, je continue à expérimenter de nouvelles techniques en faisant des petits programmes et surtout sur ce qui permettrait de résoudre la quadrature du cercle entre gameplay et storytelling. Comme dit précédemment, la passion ne m’a jamais quittée!

    CEO- Avez-vous des projets actuels dont vous souhaiteriez dire un mot ?

    Oui mais c’est trop tôt pour en parler 🙂 disons que je mets toujours un point d’honneur à finir ce que j’ai commencé et qu’il y a certains chantiers que j’aimerai bien boucler avant de n’en être vraiment plus capable!

    CEO- Quelque chose de particulier à ajouter ?

    J’aimerais en profiter pour remercier tous les retrogamers qui par passion continuent à faire vivre ou revivre nos vieilles machines et leurs logiciels. Bravo et chapeau bas a vous tous!

    Fin de l’interview.
    Un grand merci à Hervé, qui malgré ses nombreuses activités a pris le temps de répondre à nos questions !

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

    1e partie : Récupération et adaptation du code source

    par André C.

    Les 3 articles précédents “Musique, Note, Octave, Fréquence et Période“, “Les enveloppes du PSG 8912” et “Temporisation en langage machine” vous ont fourni quelques éléments de compréhension des sons de l’Oric. Nous allons voir comment exploiter au mieux les sons préprogrammés grâce à une nouvelle série de 3 articles. Afin d’éviter les redites, j’ai zappé les bases déjà décrites et vous invite à vous reporter aux articles précédents en cas de besoin.

    Liste des sons préprogrammés

    Aux commandes usuelles PING, SHOOT, EXPLODE et ZAP, il faut ajouter TOUCON (bruit clavier des touches contrôles), TOUNOR (idem touches normales) et OUPS, le petit dernier du Telestrat.

    Tous les sons préprogrammés ont le même inconvénient : il n’est pas possible d’en moduler le volume sonore (d’où divers petits gadgets hardware apparus pour atténuer le son pendant la nuit !). La raison en est simple : Tous ces sons sont figés en Rom et on peut difficilement intervenir.

    Il est quand même possible de s’inspirer de leur code pour le mettre en Ram et le modifier. Pour OUPS par exemple, le volume sonore est figé plein pot, mais il est facile de rendre ce paramètre ajustable dans une version en Ram. Malheureusement, pour les sons préprogrammés utilisant une enveloppe, on est bien obligé de garder celle-ci, sous peine de faire autre chose. Il est toutefois possible de modifier la hauteur de la note, sa durée etc.

    Structure des sons préprogrammés

    Tous ces sons sont basés sur 2 routines en Rom :

    • La routine #F590 envoie un seul des 14 paramètres au PSG (les registres A et Y du 6502 contenant respectivement le paramètre à envoyer et le numéro du registre cible).
    • La routine #FA86 envoie 14 paramètres au PSG (les registres X et Y du 6502 contenant l’adresse où se trouvent les 14 paramètres).

    En outre ZAP et OUPS font appel à une temporisation à boucle pour gérer la durée du son produit.

    Récupération des sources en langage machine

    Le plus simple est donc de recopier le code présent en Rom dans un fichier source en langage machine. Il faut aussi modifier les adresses des blocs de paramètres pour les diriger vers la Ram. Enfin, dans le cas d’OUPS, il faut remplacer les adresses Telestrat par les adresses Atmos pour les 2 routines citées ci-dessus.

    C’est ainsi que j’ai obtenus les 8 fichiers source suivants : PINGLM.ASM, SHOOTLM.ASM, EXPLODLM.ASM, TOUCONLM.ASM, TOUNORLM.ASM, ZAPLM.ASM, OUPSLM.ASM et même PREDEFLM.ASM qui regroupe le code des 7 sons préprogrammés (voir le fichier SonsPreprogr1.zip qui accompagne cet article).

    Mise en œuvre des sons préprogrammés

    Après compilation, j’ai obtenu 8 fichiers exécutables .TAP qui sans surprise reproduisent fidèlement les 7 sons d’origine. Il ne reste plus qu’à étudier le mécanisme de chaque son et éventuellement à modifier certains paramètres.

    Les commandes PING, SHOOT, EXPLODE, TOUCON et TOUNOR utilisent une enveloppe pour contrôler le volume sonore alors que ZAP et OUPS fixent celui-ci au maximum. Le code de tous ces sons envoie un bloc de 14 paramètres au PSG 8912. Mais en outre, le code de ZAP et OUPS met en place des boucles de temporisation pour contrôler le son produit.

    L’analyse du bloc de 14 paramètres est facile car tous les paramètres sont à zéro par défaut (sauf R7 qui contrôle les canaux en service et qui est mis à #3F pour tout inhiber). Voir éventuellement “Retour sur la mise en œuvre du PSG AY3-8912” dans le CEO-mag de Janvier 2020.  Les paramètres spécifiques d’un son donné sont donc immédiatement apparents ce qui permet de comprendre ce que fait ce son. Attention toutefois au paramètre R13 dont la valeur #00 peut désigner l’enveloppe de n°0 lorsque le contrôle du volume sonore fait appel à une enveloppe.

    A suivre…

    SonsPreprogr1.zipTélécharger

  • Créer des écrans texte à partir de fichiers Markdown

    md2hlp est un outil programmé en python qui permet de générer des écrans textes Oric à partir de fichier Markdown (.md). L’outil est très utile pour faire par exemple des man pages sur Orix.

    Il fonctionne avec un script python, un fichier de conf et un fichier markdown en entrée. Ci dessous une image générée avec un markdown en entrée.

    Le résultat

    Le but de l’outil est d’avoir un écran texte généré par un fichier mark down tout en se basant sur un fichier de conf qui définira la mise en forme de l’écran, sans avoir à faire la mise en forme manuellement.

    Commençons

    Nous allons faire un écran avec un exemple de base (il vous faudra python3. Pour python2, il y a aussi la version du script python dans src/)

    $ git clone https://github.com/assinie/md2hlp.git
$ cd md2hlp/src/
$ python md2hlp.py3 -f ../examples/basic11.md -o basic11.hlp

    A ce stade, vous obtenez un fichier .hlp. C’est juste un écran texte.

    Maintenant, ajoutons un header pour qu’il se charge en $BB80. Il faudra osdk avec le binaire header et spécifier l’adresse $bb80 pour charger le .tap à la bonne adresse texte

    Allons plus loin

    Nous avons affiché la page avec la configuration par défaut qui est contenue ici : https://github.com/assinie/md2hlp/blob/master/src/md2hlp.cfg

    Cette configuration définit comment le programme python doit convertir le fichier .md (c’est une sorte de template)

    Cherchons la ligne contenant [Heading1] et remplaçons cette ligne :

    Head = __^J ^Q_ORIX 1.0 ^P___

    par

    Head = __^J ^Q_POUET POUET ^P___

    Notez les ^J ^Q etc : Cela correspond aux attributs définis dans le fichier de conf. Si vous cherchez ^J, vous tomberez sur : double_height = ^J

    Nous avons défini que le double_height est le contrôle ^J. Ainsi, le titre sera en double hauteur.

    paper_red = ^Q indique que ^Q sera le paper en rouge. Ainsi, notre POUET POUET sera également sur fond rouge. Je vous laisse trouver à quoi sert le ^P

    Pour finir, il suffit de définir un template qui déterminera ensuite l’apparence de votre fichier .md en sortie sur l’écran texte.

    L’outil md2hlp est utilisé pour faire les man pages sur Orix. Nous avons juste à mettre à jour les fichiers md, puis nous lançons md2hlp qui fera le reste. Par exemple, pour Orix, le fichier .hlp doit être placé dans /usr/share/man.

    Au lancement de man, il suffira de spécifier en paramètre le fichier hlp déposé dans le répertoire sans le .hlp