Author: admin1957

  • Radar Oric

    Un nouveau jeu de réflexion d’ André C.

    Prévu à l’origine pour être un cadeau de Noël, ce programme a connu un peu de retard à force de le peaufiner.  Mais bon, il est maintenant disponible et vous le trouverez dans le zip accompagnant cet article, ainsi que sur mon site, à l’adresse http://andre.cheramy.net/telechargement/Programmes/choix.htm

    De quoi s’agit-il ?

    C’est une sorte de bataille navale, mais dans le jeu classique (en vigueur dans les cours de récréation et qui se joue sur une grille papier),  deux protagonistes s’échangent des missiles pour couler les bateaux de l’adversaire et (cf. “touché”, “en vue” et “dans l’eau”). Dans les équivalents numériques le jeu est souvent réduit à un seul joueur contre l’ordinateur.

    Dans Radar Oric, il n’y a aucun risque de recevoir des missiles sur vos bateaux, car vous n’avez pas de bateaux. C’est votre QG qui est attaqué par une flotte ennemie et pour vous défendre, vous disposez d’un tout nouveau radar couplé à un ordinateur dernier cri, l’ Oric. Votre tâche est de localiser exactement la position de tous les bateaux ennemis, puis de déclencher un feu apocalyptique qui les anéantira vite fait bien fait avant qu’ils aient eu de temps de dire ouf ! Oui, je sais les bateaux ne peuvent pas dire ouf, mais bon…

    Le jeu proprement dit

    Votre rade est représentée par une grille de 10×10 cases où les 10 bateaux de la flotte ennemie se sont faufilés, profitant d’un épais brouillard. Heureusement, il y a quelques trous dans ce brouillard, dans lesquels vous pouvez apercevoir des bouts de navires ou… de l’eau ! Mais c’est tout (voir la figure ci-dessous).

    Pas facile de savoir où sont les bateaux ennemis ! Heureusement encore, votre super Radar Oric est capable de scanner cette grille et de vous indiquer combien d’éléments de bateaux se trouvent dans chaque ligne et dans chaque colonne (voir les chiffres rouges à gauche et sous la grille). Heureusement encore, votre super Radar Oric est capable de scanner cette grille, ligne par ligne et colonne par colonne, et de vous indiquer combien d’éléments de bateaux s’y trouvent (voir les chiffres rouges à gauche et sous la grille).

    Un peu de réflexion vous permettra de déduire la localisation exacte des 10 bateaux ennemis. Dernier petit service offert par votre Radar Oric : il vous indiquera si vous vous êtes planté dans votre raisonnement ou si les bateaux sont bien là où vous pensez.

    Si c’est correct, il ne vous restera plus qu’à les anéantir et l’ennemi n’aura même pas le temps de comprendre ce qui lui arrive. Le résultat est garanti en un rien de temps !

    Hélas, l’ennemi a la peau dure et il ne va pas tarder à vous envoyer une nouvelle flotte. Sacrebleu, il va encore falloir se creuser les méninges !

    Mais tout est bien qui finit bien, il arrivera inexorablement un moment où l’ennemi sera à court de bateaux et où aurez définitivement  gagné.

    Chaque flotte ennemie est composée des 10 bateaux suivants

    • Un porte-avions (4 cases)
    • Deux croiseurs (3 cases)
    • Trois destroyers (2 cases)
    • Quatre Sous-marins (1 case)

    Cet effectif vous est rappelé au-dessus de la grille et vous sera utile pour vous aider à trouver où peuvent se tenir les bateaux.

    Les commandes disponibles

    • Les quatre flèches pour déplacer le curseur dans la grille.
    • Les chiffres de 1 à 8 pour marquer la case au curseur selon ce que vous pensez qu’elle contient.
    • La touche “R” pour recommencer la grille au début, si vous êtes trop embrouillé.
    • La touche “S” pour sauvegarder la partie en cours afin de la reprendre plus tard.

    Correspondance entre les touches 1 à 8 et le marquage des cases

    1. Case indéterminée
    2. De l’eau
    3. Corps de bateau
    4. Sous-marins
    5. Extrémité gauche d’un bateau
    6. Extrémité droite d’un bateau
    7. Extrémité basse d’un bateau
    8. Extrémité haute d’un bateau

    A tout moment, vous pourrez consulter le pense-bête, situé à droite de la grille (chiffres bleus suivis d’une icône).

    Enfin, le n° de la flotte qui vous attaque est visible  juste au-dessus de ces chiffres (par exemple le 4 sur la figure ci-dessus indique que vous vous défendez contre la 4e flotte ennemie).

    Toutes les grilles du jeu ont bien sûr une solution et une seule.

    A vous de jouer !

  • Micro UK101 + Mod

    Micro UK 101, un ordinateur à réaliser soi-même avec quelques composants “old fashion”.


    Micro UK 101 + Mod, avec ajout de modifications.

    UK 101 ?
    L’ordinateur Compukit UK101, paru en 1979 en Angleterre, pouvait s’acheter en kit ou déjà tout monté. Il était destiné au marché anglais. Pourvu d’un 6502 à 1 MHz, il utlisait 8 kb de ROM , 8 Kb de RAM, augmentée d’un Kb pour la sortie vidéo UHF. Le clavier et l’alimentation faisaient partie de la carte mère, complétée par un port extension à 40 broches. La lecture et la sauvegarde de données pouvait se faire sur cassette mono à 300 bauds. L’affichage sur écran (TV) était de 16 rangées sur 48 colonnes, sans autre option vidéo.

    Micro UK 101 !
    Grant Searle, un passionne doué, fait revivre des ancêtres comme le 6502, le Z80 ou le 6809, en les allégeant beaucoup. Entre autres, il a créé le Micro UK 101, clone de l’UK 101, doté toujours du sempiternel 6502, mais avec maintenant 32 Kb de ROM, 32 Kb de RAM, un ACIA 6850 et quelques circuits logiques. Sans entrée clavier, ni sortie vidéo, le Micro UK 101 est à relier sur un ordinateur récent par un port COM. Sans carte son, ce petit bijou peut s’assembler sur une plaque d’essais type “Breadbord” ou sur une plaque pastillée avec fils point à point.
    Son site fourmille de documents et de conseils.
    Libre à vous de construire un micro des années 80 ou de vous lancer dans un clone à FPGA.


    Sur le Bay, on peut parfois trouver un kit. Celui-ci était déjà monté.

    On peut relier un adaptateur USB RS232 sur la prise DB9 ou un module USB TTL type FT232 sur les broches en bas à droite de la carte.
    Exemple de module FT232 facile à trouver sur le Bay :

    Les ordinateurs récents n’ont plus de port série à DB9, ni de port imprimante. D’où la première Mod faite à cette carte : retirer la DB9, le circuit ICL232 et ses condensateurs associés pour les remplacer par un connecteurs à 4 broches servant au module FT232, en y intercalant des résistances de protection. Et remplacer cette Led rouge par une bleue, avec une résistance de 2k2 pour être plus agréable à voir sans être ébloui ! Enfin, il suffit de dessouder le condensateur C17 et de le repositionner couché, pour gagner quelques millimètres en hauteur.
    Ainsi la carte sera placée entre un support en plastique et une plaque transparente, avec des entretoises de bonne hauteur et quelques boulons.

    Voici le résultat de la Mod 1 :

    Notez les bandes rouge et noire autour du connecteur à 4 broches…

    Deuxième Mod à faire : une petite carte pour relier le module FT232 directement sur la carte sans utiliser de câblage. Un interrupteur petit modèle permettra d’alimenter la carte à partir du PC, opération visualisée par la Led verte..

    Les bandes rouge et noire servent de détrompeur…
    (Rouge pour VCC, noire pour GND)

    L’utilisation du Micro UK 101 est facilitée par ces deux Mods.

    Il ne reste plus qu’à le tester sur PC, en utilisant par exemple un logiciel comme PuTTY et en réglant le port COM relié au FT232 à 19200 bauds.

    Et voici l’écran d’accueil :

    Un petit programme en Basic pour tester l’ensemble :

    Et ça fonctionne !

    Déjà cette carte permet de se faire le main sur le 6502 sans passer par l’Oric et ses périphériques (alimentation, adaptateur RGBS-HDMI, écran LCD ou autre). Le Basic a beau être limité (8 Kb seulement au lieu des 16 Kb de notre Oric), il permet néanmoins de progresser et de découvrir le programmation en langage machine…
    C’est déjà un bon point pour cette petite carte !

    Mais il lui manque de quoi communiquer avec l’extérieur, autre que le PC auquel elle est reliée. Interagir avec quelques Leds et des interrupteurs ou des boutons poussoirs serait un sacré plus.

    Qu’à cela ne tienne ! Il suffit de lui rajouter un 6522 (ou un 65C22) !
    Comme celui qui se trouve dans l’Oric…
    C’est l’objet de la troisième Mod.



    Une petite plaque PCB pastillée sera installée à côté de la carte et supportera le 6522 avec moult connecteurs (pour les ports A et B, les sorties CA et CB). Des fils fins relieront le 6522 au 6502 et il reste à choisir une sortie du 74LS138 pour l’adresse à utiliser (arbitrairement ici, la 5, soit à partir de #D000).

    Il faudra redimensionner les plaques en-dessous et au-dessus du nouvel ensemble, et cela donne :

    Format 10 x 15 cm !

    Afin d’avoir un aperçu visuel des ports du 65(C)22, cette petite carte facile à réaliser s’avère très utile :

    2 circuits ULN2803 et 16 Leds



    Exemple avec un chenillard de type “K 2000” sur 16 Leds :

    Et vu du dos de la carte à 16 Leds :


    Ce petit ordinateur, même limité en périphériques, est maintenant capable de communiquer avec l’extérieur après ces quelques modifications. Facile à transporter, une fois relié à un PC, il s’avère agréable d’emploi et facile à programmer. Le stockage des fichiers se fait directement sur le disque dur du PC.

    Un grand merci à Grant pour ce cousin de notre Oric !


  • Modifications sur Oric

    RESTRUCTURATION D’UN ORIC

    Aie, ça va faire mal aux yeux à certains. Âmes sensibles, passez votre chemin…

    Dans le cadre de ce projet à long terme, le travail proposé va dans un premier temps alléger considérablement une carte mère d’Oric, puis y apporter plusieurs modifications et sa finalisation permettra une utilisation inhabituelle.
    Son appellation pourrait être : ORICMOD.

    Vous êtes prêts ? Alors, attaquons le premier temps.
    De la carte mère originale, il faut arriver à :

    et maintenant défigurée !
    Encore belle…

    Démontage de tous les circuits sur support. A placer piqués dans une mousse électrostatique, sinon dans une mousse enveloppée de papier aluminium.

    En utilisant tout moyen à votre disposition (fer à souder, pompe à dessouder, tresse à dessouder, pistolet à dessouder, pinces, tournevis plat,etc…), dessoudage patient de tous les composants qui sont utilisés pour :
    – l’alimentation négative,
    – la génération du signal vidéo UHF,
    – l’amplificateur LM386,
    – la gestion Entrée-Sortie des signaux TAPE avec le LM358,
    – le relais de commande du magnéto.
    Ainsi que le haut-parleur, le bouton RESET et les prises DIN (RGB et TAPE)…

    Voici donc la carte mère de l’ORICMOD :


    Notre ORIC est devenu sourd et aphone. Impossible pour lui d’afficher quoi que ce soit. Ah misère, quand tu nous tiens !
    Il ne lui reste plus que la peau et les os !

    Mais pourquoi tant de cruauté ? Une carte mère qui avait encore tant de belles années devant elle ! Qui plus, maintenant c’est malin ! Ça ne vaut plus rien, même sur le Bay (alors qu’on y voit des prix astronomiques pour une machine parfois non testée !).
    Oui, mais…
    Les modifications à venir vont lui conférer une souplesse appréciable pour son utilisation future. Ces modifications se dévoileront au fur et à mesure sur ces pages.

    MOD de départ, juste pour se faire la main : l’alimentation.
    L’ORICMOD va être alimenté en + 5 Volts directement. Il sera bon à cette occasion de remplacer la prise Jack trop souvent oxydée par une nouvelle.
    Puis, un pont fait avec une queue de résistance ou un bout de fil va relier deux trous laissées par le 7905 parti en voyage très longue durée…

    Reliez les deux trous “Masse”

    Pour gagner un peu de place, nous décalerons l’implantation des condensateurs. Parfait derrière la prise Jack :


    Poursuivons avec la deuxième MOD : la prise RGB.

    Notre ORICMOD va pouvoir de nouveau envoyer des signaux vidéo vers l’extérieur. Ayant déjà modifié un boîtier Convertisseur de signal HDMI-SCART vers HDMI en lui retirant sa prise Péritel, nous allons installer une petite plaque à bandes avec quelques connecteurs.
    Auparavant, il sera utile de repérer les sorties à utiliser :

    R, G, B et Synchro, sans oublier la Masse…

    Des queues de résistances ou des fils pour assurer la liaison avec les pastilles repérées, un connecteur à 5 broches mâles coudées à 90 degrés, quelques fils de liaison (ici, en couleurs correspondantes, sauf le jaune pour la Synchro), et voilà !

    C’est tout de même moins encombrant que la prise DIN, non ?

    Sans toucher à la coque, il y a pas mal de place gagnée !

    Un petit marquage des broches (comme un commentaire dans un programme) n’est jamais inutile…


    Le temps de remonter les circuits sur leurs supports, de relier la carte modifiée derrière le clavier, et nous pouvons tester sur écran si c’est bon.


    ATTENTION : c’est 5 Volts maintenant, vérifiez votre transformateur !

    Hello, World !
    Et c’est OK ! Ouf !




    _____________________________________________________________________________
    Débranchons le tout et retirons les circuits sur support.

    N’hésitez pas à partager vos commentaires et idées !

    Tout ça là-dedans ? Incroyable, non ?

    A suivre pour de nouvelles aventures ….

  • Space Invasion

    Avec Pipe-Mania déjà réalisé en ce début d’année 2015, Dancresp a fait un bon dans la réalisation de ses jeux. Cette fois, les couleurs sont démultipliées pour le plaisir de nos yeux

    Informations générales

    Ce jeu est une nouvelle version d’un jeu précédemment adapté pour ACORN ELECTRON, MSX et ATARI XL.

    Cette version pour Atari XL est la meilleure version, car une partie de la couleur a été ajustée plus le niveau de difficulté, faisant apparaître progressivement plus de variété d’ennemis. La vitesse est cyclique, de sorte que tous les 3 niveaux la vitesse est maxmale avant de redescendre dans le suivant. Dan a également changé l’ordre d’apparition des envahisseurs dans notre sélecteur, en les regroupant par type et par position et en les différenciant par des couleurs. S’il n’y avait pas le souci du temps de réponse du clavier, ce serait la version ultime.

    Comme ORIC fonctionne sur 40 colonnes, Dan a utilisé la disposition des éléments à l’écran des versions ACORN ELECTRON et ATARI XL, et verticalement, tout cela est un peu plus étiré du fait de l’utilisation des 25 lignes.

    Comme toujours, le fait de disposer de caractères de 8×6 pixels a contraint Dan à redéfinir certains graphismes, tels que le bunker ou le char, qui a réutilisé ceux de «nuclear invaders» pour les envahisseurs.

    Pour lire le clavier, Dan a choisi de le faire avec PEEK (520) ($208 en hexadecimal), ce qui permet de lire la dernière touche enfoncée, en évitant les problèmes de majuscules ou de minuscules. Malheureusement, le tampon clavier est limité à une touche ce qui signifie que la lecture n’est pas aussi fiable que souhaité et que la touche doit être enfoncée plus longtemps. Cependant, la difficulté a été adaptée à cette limitation pour que le jeu fonctionne correctement. Ce problème se produisait déjà dans la version ATARI mais cela a parfaitement fonctionné dans ELECTRON et MSX.

    Dan a supprimé tous les calculs et tous les ET / OU possibles. Pour utiliser un IF et s’il n’est pas satisfait, aucune autre valeur n’est à vérifier. Dan a également évité d’utiliser ELSE chaque fois que possible pour éviter les “erreurs” de l’interpréteur BASIC ORIC.

    Pour que la vitesse soit constante, en tenant compte du fait que parfois plus de lignes sont exécutées que d’autres, sur la ligne 100, j’initialise l’emplacement mémoire n ° 276 sur 0, car cette position et la suivante forment un registre de 16 bits qui est: diminue de 50 fois par seconde. Sur la ligne 220, je crée une boucle qui considère que la valeur de cette position (l’octet de poids faible) est inférieure ou égale à 230. Surtout lors de la mise à jour d’une colonne d’envahisseurs, le processus prend plus de temps que d’habitude et nous obtenons ainsi la vitesse de l’exécution soit constante. Dommage pour le thème de la lecture au clavier …

    Et comme toujours, en ce qui concerne le son, Dan a démontré une fois de plus ce point faible et s’est limité à utiliser les sons standards de l’Oric.

    PAPER et INK, les couleurs de l’Oric
    Faire un jeu coloré avec l’ORIC est toujours difficile. La gestion de la couleur par l’ORIC n’aide pas, mais ce jeu a pu être coloré avec une certaine facilité et bien que le résultat ne soit pas trop “rétro”, il est beaucoup plus attrayant et clair lorsque l’on joue.

    Pour ORIC, un attribut de couleur est un caractère que vous pouvez placer n’importe où sur l’écran. À partir de ce caractère, tout ce qui apparaît à sa droite aura cette couleur jusqu’à ce que vous trouviez un autre attribut de couleur, ce qui affectera à nouveau tout ce qui se trouve à votre droite. Cela induit, si vous faites une impression dans une position de l’écran où il y a un attribut de couleur, un emplacement de perdu, et ce qui est montré par l’IMPRESSION prend la couleur de l’attribut précédent, donnant un spectacle visuel chaotique, et compliquet beaucoup la programmation de jeux en couleurs.

    Pour éviter cette impression de désordre, il est nécessaire de laisser des espaces entre les différents éléments, où seront placés les attributs de couleur. Grâce à la disposition des éléments dans ce jeu, il a été facile de le colorier et lui donner cet aspect multicolore.

    Je vous invite à l’essayer.

    Quelques informations concernant le programme

    Dan a divisé le programme en 12 blocs:

    • Déclaration de matrice.
    • Contrôle de notre tank.
    • Contrôle de notre objectif.
    • Contrôle de notre tir.
    • Déplacer les envahisseurs.
    • Niveau de passage.
    • Perdre une vie.
    • Présentation
    • Afficher l’écran de jeu.
    • Plusieurs routines.
    • Charger UDG.
    • Définition des blocs graphiques.

    L’ensemble du programme occupe 73 lignes

    • 10 – Nous définissons les matrices du jeu.
    • 20 – Appel de routine pour lire les graphiques et afficher l’écran de présentation du jeu.
    • 100 – Début de la boucle principale.
    • 105 – Contrôle du clavier et vérifiez si notre réservoir doit être déplacé horizontalement.
    • 120 – Si vous appuyez sur “M” (Déplacer), l’envadeur de la position correspondante est modifié.
    • 150 – Si vous appuyez sur “L” (Shot), il est vérifié si l’envahisseur sélectionné se trouve dans cette colonne et le détruit.
    • 200 – Si le compteur de vitesse (W) n’atteint pas la valeur souhaitée, il est augmenté de un et passe à la ligne 220.
    • 205 – Une colonne est sélectionnée de manière aléatoire et s’il reste des envahisseurs, un est ajouté et, si aucun espace dans la colonne n’est ajouté.
    • 210 – Il est vérifié si la colonne a atteint le bunker. Si c’est le cas, il saute à la ligne de vie perdue (500).
    • 215 – Actualisez la colonne de l’envahisseur sélectionné.
    • 220 – Contrôle du temps pour que chaque passage dans la boucle principale prenne la même chose.
    • 225 – Fin de la boucle principale. Si «E = 0» revient à la répétition de la ligne 100. Si «E = 1» passe à 500 (perdre la vie).
    • 400 – Niveau de routine dépassé (E = .1). Le niveau est augmenté de 1, mais si nous passons du niveau 9, nous revenons à 7.
    • 500 – Routine qui s’exécute lorsqu’un envahisseur atteint le bunker. S’il nous reste de la vie, les marqueurs sont mis à jour, mais le message «GAME OVER» apparaît et, après une pause, nous revenons à l’écran de présentation.
    • 2000 – Écran de présentation du jeu.
    • 2050 – Attendez que nous appuyions sur une touche pour lancer le jeu.
    • 2100 – Affiche les marqueurs sur le côté droit de la zone de jeu.
    • 2500 – Le statut des cinq colonnes d’envahisseurs et de l’envahisseur “cible” est mis à jour.
    • 2505 – Affiche la partie gauche de l’aire de jeu. Où l’action a vraiment lieu.
    • 3000 – Paramètres de couleur de jeu et POKE pour masquer le curseur et les majuscules.
    • 3005 – Nous chargeons les couleurs dans C $ () et lisons les DONNEES avec l’UDG.
    • 3010 – On conserve dans la matrice G $ les graphiques qui forment chaque envahisseur et sa couleur.
    • 3015 – Lecture du nombre d’envahisseurs différents par niveau “D ()” et sa vitesse “G ()”.
    • 4000 – Routine pour imprimer les valeurs de “REST” et “AMMO”. La position verticale dans “Y” et la valeur dans “N” sont passées.
    • 4200 – Routine pour imprimer les valeurs de “SCORE” et “HI-SCORE”. La position verticale dans “Y” et la valeur dans “N” sont passées.
    • 4500 – Routine pour l’effacement partiel de l’écran.
    • 9000 – DATA avec les UDG du jeu.
    • 9500 – DATA avec les couleurs et les graphiques de chaque type d’envahisseur.
    • 9800 – DATA avec le nombre d’envahisseurs différents par niveau.
    • 9805 DATA avec la vitesse de chaque niveau.

    Le jeu

    C’est une nouvelle tentative des envahisseurs de l’espace pour prendre le contrôle de notre planète !

    Les envahisseurs descendent en colonnes et avec l’aide de notre char, nous devons sélectionner le type d’envahisseur et tirer. Si l’envahisseur est dans cette colonne, il sera détruit et le reste s’éloignera.
    Évitez de vous rendre dans la zone de bunker ou la victoire sera à vous.

    Chaque niveau est composé de 35 envahisseurs et nous avons 60 coups pour les tuer. Lorsque les niveaux sont dépassés, de nouveaux types d’envahisseurs apparaissent et descendent plus rapidement.

    Le jeu enregistre le score maximum atteint dans une partie.

    Quelques autres versions

    Space Invasion sur Acorn Electron
    La version MSX prend beaucoup de place à l’écran
    Les envahisseurs de l’espace attaquent l’Atari XL
  • Développement sur Orix

    introduction

    Le but de cet article est d’expliquer comment développer sur Orix des applications. Cet article ne va expliquer comment coder en C, mais plutôt comment utiliser les fonctions déjà codées dans cc65 pour faire des choses sur Oric. En effet, Orix s’appuie sur telemon. Pour rappel, telemon est une rom de 16Ko qui contient toutes les routines pour faire fonctionner le hard telestrat notamment, mais aussi l’affichage etc. Il n’y a pas d’interpreteur dans cette partie. Il faut imaginer telemon comme étant une grosse lib utilisable en assembleur. Les libs C de la target Telestrat sur cc65 ne font qu’appeler ces routines.

    Prérequis

    Il vous faudra l’archive contenant Oricutron avec l’émulation du CH376 : https://iss.sandacite.com/iss/oricutron/
    Puis cc65, http://cc65.github.io/cc65/
    Puis les roms : https://repo.orix.oric.org/dists/orix1/alpha/tgz/6502/roms.tgz

    Dans oricutron.cfg, mettre la rom kernel en banque7, la rom basic en banque6, la rom shell en banque 5, et dans les autres banques mettre emptyrom.

    Chaque lancement d’oricutron devra se faire avec l’option -t pour pouvoir démarrer les binaires

    Avoir un éditeur texte (notepad, visual code etc)

    CC65 utilise les prototypes de fonctions standardisées (POSIX), ainsi, il n’y a pas de hires par exemple.

    Premier exemple

    Nous allons effacer l’écran.

    Nom du fichier : clrscr.c

    #include <conio.h>
    
    int main (int argc,char *argv[]) {
      clrscr(); // Effacer l'écran (texte) avec conio car conio gère le mode texte.
    } 

    On compile (sous linux ou windows)

     # cl65 -ttelestrat clrscr.c -o clrscr

    Vous aurez un binaire clrscr

    Copiez ce fichier dans oricutron/usbdrive/ (oricutron qui est dans l’archive ci dessus)

    Démarrez Oricutron de cette archive.

    Dans Orix, on regarde les informations du binaire avec file :

    # file clrscr 

    File permet d’afficher les infos de fichiers (file affiche les infos d’un fichier filepack, binaire Orix, raw, script shell etc)

    Dans Orix, on execute le code :

     # ./clrscr 

    Nous avons l’écran qui s’est effacé

    Afficher hello world

    #include <stdio.h> 
    
    main() {     
      printf("Hello World\n");
    } 
    • Puis je compile :
    # cl65 -ttelestrat hello.c -o hello 
    • je déplace le binaire dans le répertoire usbdrive d’oricutron (dans bin) :

    cp hello $ORICUTRON/usbdrive/bin/

    • je lance oricutron, et je tape “hello”. Cela fonctionnera sans faire ./hello, puisque nous avons placé le binaire “hello” dans bin/ qui est dans le “PATH”.

    Lire le clavier

    Nous allons utiliser la lib conio de cc65 qui est une librairie de gestion du clavier et du mode texte. Notez que cela récupère aussi le code ascii du joystick. En effet, sur telestrat, quand on utilise telemon, quand on scrute le clavier, on récupère aussi le joystick !

    #include <conio.h>
    #include <stdio.h>
    
    int main (int argc,char *argv[]) {
       unsigned char key;   // Ici le programme ne sort jamais, dès qu'une touche est pressée, elle s'affiche à l'écran.
       while (1)   {     
         key=cgetc();     
         printf("%c",key);
       }
    } 

    Passer HIRES

    Nous allons utiliser la lib TGI de cc65 qui est une librairie graphique standard pour passer en hires.

    #include <tgi.h>
    #include <conio.h>
    #include <stdio.h>
     int main (int argc,char *argv[]) {
       tgi_install (tgi_static_stddrv);
       tgi_init ();
       tgi_clear ();
       printf("Appuyez sur une touche pour revenir en mode texte");
       cgetc();
       tgi_done();
     } 

    Passer HIRES et afficher une image

    il vous faut une images hrs que vous mettez à la racine de usbdrive dans l’émulateur. Cette image s’appelle img.hrs

    #include <tgi.h>
    #include <conio.h>
    #include <stdio.h>
    int main (int argc,char *argv[]) { 
       FILE *fp;
       char *myfile="img.hrs";
       fp=fopen(myfile,"r");
       if (fp!=NULL)   {
         tgi_install (tgi_static_stddrv);
         tgi_init ();
         tgi_clear ();
         fread(0xa000,8000,fp); // On lit 8000 octets qu'on écrit directement en hires.
         printf("Appuyez sur une touche pour revenir en mode texte"); 
        cgetc(); 
        tgi_done(); 
      } 
    } 
    • Puis je compile:
     cl65 -o picture -ttelestrat picture.c 

    Voilà, vous avez fait à peu près le binaire viewhrs qui permet de voir des images hrs sur oric.

    Quelques exemples sur orix : https://github.com/jedeoric/orix-samples que vous pouvez améliorer facilement. Contactez moi pour que je vous donne accès en écriture à ce repo !

    viewhrs a été recodé en assembleur depuis, et est dispo dans la ROM shell d’Orix. En voici le lien : https://github.com/orix-software/shell/blob/master/src/commands/viewhrs.asm

  • 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

    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.

    A suivre…

  • CEO-MAG 356

    Sommaire:

    • Librairie du CEO
    • Fonctionnement de la pile matériel du 6502 (7/8)
    • Blaguons avec Y.D. 
    • Pipe-Mania
    • Une petite curiosité dans Théoric
    • Quelques Blagues
    • Black Mamba V1.2
    • Hells’ Temple
    • Advert
    • Vu sur le Net

    Edito Décembre 2019.

    Bonjour à tous, C’est avec plein de nouvelles découvertes que nous refermons cette année 2019 oricienne ! Des démos, de nouveaux logiciels et toujours les astuces de programmation de Yann qui remplissent le mag et les fichiers zip du mois. L’année 2020 s’annonce bonne pour le CEO. Les réinscriptions, déjà nombreuses se poursuivent. Gageons que ces passionnés feront de nouvelles découvertes, à partager avec les lecteurs du mag et sur les forums. Bonnes fètes à tous et à bientot avec l’annonce de la date de la prochaine visu, qui, comme d’habitude nous permettra de passer un bon moment.

    [wpdm_package id=’2264′]

    [wpdm_package id=’2263′]

    [wpdm_package id=’2667′]

  • ORIC version RC2019

    — PRESENTATION —

    Disponible sur le Net, un excellent site concernant le RC2014 (cf https://rc2014.co.uk/) est à visiter. Un passionné a créé un simple ordinateur à base de Z80 avec de multiples cartes enfichables, qui tourne avec Microsoft Basic.

    Reprenant l’idée, pourquoi ne pas faire de même pour notre cher Oric ?
    Aussitôt dit, aussitôt fait ! Euh, le temps d’étudier comment organiser les cartes et de réaliser quelques soudures, bien entendu…

    Voici une carte mère d’Oric Atmos :

    Si l’on ne tient pas compte de certains composants pourvus pour d’autres fonctions que l’on n’utilisera pas de suite, on peut grouper les circuits en 4 blocs.

    • le 1 avec le processeur 6502 couplé avec la ROM
    • le 2 avec le VIA 6522, le générateur de sons AY-3-8912 et l’amplificateur LM386
    • le 3 avec l’ULA HCS10017, le générateur de fréquence et la sortie vidéo RGBS
    • le 4 avec la RAM et les deux circuits de décodage d’adresse 74LS257

    Il faudra également prévoir différentes sorties sur connecteurs : le haut-parleur, le port parallèle, le port clavier, le port vidéo.
    Et réaliser une carte support capable de recevoir ces différentes cartes-filles… Six connecteurs de 40 broches véhiculant les signaux des adresses, des données et de diverses commandes communs à toutes les cartes-filles :

    CARTE SUPPORT

    Et voici les cartes-filles, toutes sur un connecteur mâle de 40 broches :

    Un rajout de connecteurs a été nécessaire entre les cartes ULA et RAM (connecteurs jaunes sur les deux dernières photos)

    Les 2 cartes avec le connecteur latéral

    Et voici le tout monté :

    Premiers essais :

    Il a fallu tout d’abord rechercher les erreurs de câblage et de soudure… Pas évident quand on ne travaille qu’avec des petites cartes non reliées sur une carte mère classique d’Oric !
    Mais après un certain temps (comme pour le refroidissement du fût du canon) et l’aide d’une autre carte mère DIY susnommée “Mammouth” par son concepteur, il a été possible enfin de démarrer l’Oric version RC 2019 !

    L’occasion de relier le clavier DIY, un haut-parleur, d’écrire un petit programme de test en basic, de jouer avec quelques Ping et Explode plus tard, ça tourne toujours ! Bonne nouvelle ! D’autres cartes vont pouvoir être développées et connectées a cette version sympa de l’Oric…

    Deux slots d’extension sont encore disponibles. Il est également possible d’utiliser le dernier slot pour y relier une carte intermédiaire comportant d’autres slots…

    Ça ouvre pas mal de possibilités !

    Oui, il faut admettre que cet Oric n’a pas la beauté d’un Oric original. Le boîtier noir et orange a disparu, le clavier mécanique et le bloc d’alimentation aussi…
    Mais c’est un clone fonctionnel, destiné au développement de projets divers qui ne manqueront pas de venir enrichir ces pages.

    Oricalement,
    Voyageur

  • Pipe-Mania

    Un idée simple, une programmation des plus légères. Et nous voilà à jouer sur un jeu très addictif.

    Informations générales

    En pensant à son prochain projet 1K pour le ZX-81, DanCresp ne le savait pas, mais ce jeu était en tête et de la recherche d’informations sur Internet. Il décida de créer une première version pour MSX. Les problèmes de temps et la facilité d’utilisation de MS-DOS EUPHORIC sur son ordinateur portable l’ont incité à l’adapter à l’ORIC, en vérifiant auparavant qu’il n’y avait pas de version connue.

    Au bout de cinq jours, l’auteur a laissé cette version utilisable, quels que soient les niveaux et les blocs qui apparaissent dans la version d’origine, graphiquement sur la base de la version Spectrum.

    Heureusement, l’émulateur EUPHORIC permet, en appuyant sur “F3”, de mapper le clavier ORIC avec les touches du PC, ce qui facilite beaucoup l’introduction du programme. De l’émulateur, il a généré le TAP et de «l’Oricutron» de Windows, il a généré le listing dans un fichier texte utilisé pour déboguer le code source.

    La vérité est que Dan est très satisfait car le fonctionnement et la performance sont parfaits ; avec un très bon game design. Le système pour augmenter la difficulté a donné plus mal à la tête parce que le jeu devait être difficile mais réalisable. (NDLR : Dan est décidément un pro du game design)

    Les petites choses de la version ORIC
    Comme toujours lors de la programmation dans l’ORIC, les graphismes ont dû être repensés car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice de 8×6.
    Étant donné que l’ORIC dispose d’un mode texte de 26 lignes et de 40 colonnes, la zone de jeu a les dimensions de la version Amiga 500 d’origine de 7 lignes x 10 colonnes au lieu de la version 7×9 de la version Spectrum.

    Dan aurais aimé regarder plus avec la couleur de l’écran, mais le système “particulier” de l’ORIC ne m’a pas permis. Après consultation d’amis graphistes, c’était la meilleure solution. Très semblable à MSX … bleu et jaune.

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

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

    Et l’eau coule …
    La difficulté principale et presque unique du projet a été de faire circuler l’eau à travers le tuyau, et même si au début cela semblait une question assez complexe, après une promenade avec brain-storming inclus, j’ai trouvé une solution très simple et rapide .

    Nous avons 7 types de blocs différents pour assembler notre circuit.

    Chacun de ces 7 blocs utilise certains des 11 graphiques de tubes différents, numérotés de 97 à 104.

    L’eau peut avoir 4 directions possibles, numérotées dans le sens des aiguilles d’une montre.

    Nous chargeons la matrice «U $» avec les valeurs DATA des lignes 9600 et 9605. Chacune de ces valeurs contient quatre nombres. La position indique la direction dans laquelle l’eau entre et la valeur de cette position indique la nouvelle direction à prendre par l’eau. Si la valeur est 0, cela signifie que vous avez entré une adresse incorrecte et que le jeu se termine.

    Par exemple, la valeur en U du segment de tuyau 3 (coude inférieur / gauche) est «4300». Ainsi, si l’eau entre, elle monte et entre en dessous (direction 1), elle change à gauche (direction 4). Si vous entrez, il avance vers la droite (direction 2), il passe en bas (direction 3). Mais si l’eau vient du haut ou de la gauche, la valeur est «0» et le jeu se termine.

    Lors du démarrage d’un niveau, la position initiale du bloc de sortie est calculée et dans la variable “W”, nous stockons l’adresse de la mémoire vidéo VRAM où l’eau commencera à circuler et dans la variable “O” son adresse (1, 2, 3 ou 4).

    Lorsque l’eau commence à circuler, nous examinons le graphique correspondant à cette conduite et prenons son code (entre 1 et 11). Sur la base du sens d’entrée de l’eau (1 à 4), nous calculons le changement de direction en fonction de la matrice enregistrée dans «U $» et nous mettons à jour la position dans la VRAM sur laquelle pointe la variable «W» en fonction des valeurs de la matrice «J». Cette matrice contient 4 valeurs: -40, 1, 40 et -1 et est ajoutée à «W» en fonction de la nouvelle adresse pour pointer sur la bonne adresse VRAM afin de calculer le morceau de tuyau suivant.

    Ensuite, nous modifions le CHAR du tuyau pour qu’il corresponde à l’eau, au moyen d’un POKE. Si le graphique de la position indiquée par «W» ne correspond pas à celui d’un tuyau, avec ou sans eau, le jeu se termine. J’ai utilisé un POKE car il est plus rapide et plus facile à contrôler (je n’utilise qu’une variable) qu’en utilisant un PLOT et deux variables.

    Tout cela, qui semble très compliqué, est résolu pendant le jeu avec 3 lignes de code, 170, 175 et 180. C’est aussi simple que cela.

    Une fois le niveau terminé, le même processus est exécuté pour calculer la section construite correcte, avec une copie du code précédent et quelques modifications simples, aux lignes 205, 210 et 215.

    Eh bien, rien de plus, je ne peux qu’espérer que cela vous plaise, et oeil… qui accroche le sien…

    Je vous invite à l’essayer.

    L’écran titre et toutes les touches du jeu !

    Quelques éléments concernant le programme

    Le programme est divisé en 9 blocs:

    • Déclaration de la matrice et début du jeu.
    • Boucle principale de développement.
    • Passer le niveau
    • Plusieurs routines.
    • Fin du jeu.
    • Présentation et début du jeu.
    • Préparez et montrez l’aire de jeu.
    • Charger UDG.
    • DATA avec les UDG du jeu et les valeurs de la matrice.

    L’ensemble du programme occupe 91 lignes.

    • 10 – Nous définissons les matrices du jeu.
    • 30 – Aller au sous-programme redéfinit les caractères et définit les variables globales.
    • 100 – Début de la boucle principale. Si le curseur est verrouillé, il passera à la ligne 160.
    • 105 – Prenez la touche appuyée. Si aucune touche n’a été enfoncée, le nombre passe à 160.
    • 115 – Bloc qui déplace le curseur en fonction de la touche appuyée.
    • 135 – Si vous n’appuyez pas sur “Space”, passez à 160.
    • 140 – Vérifiez si la case est occupée par un bloc spécial, sautez à 160 si c’est le cas.
    • 145 – S’il est occupé par un tuyau, réglez le compteur «N» sur 10 et il nous bloquera.
    • 150 – Bloc qui vérifie qu’aucune eau ne passe à travers le bloc.
    • 155 – Placez le bloc à la position indiquée en mettant à jour le curseur et la ligne des blocs suivants.
    • 160 – Réduit l’heure de l’indicateur “T”. S’il reste encore sauter à 185.
    • 165 – Compteur contrôlant le débit d’eau dans les tuyaux. Si vous ne devez pas avancer, passez à 185.
    • 170 – Bloc qui contrôle la progression de l’eau dans les tuyaux. Si vous ne pouvez pas, mettez “D = -9” pour interrompre la répétition.
    • 175 – Réduit le compteur “D” et vérifie le type de tuyau dans lequel se trouve l’eau.
    • 180 – Modifiez le graphique du tuyau et affectez l’adresse correspondante.
    • 185 – S’il reste encore du temps dans le compteur «D» et que l’eau circule bien dans la canalisation, retournez à REPEAT de la ligne 100.
    • 200 – Si “D = -9” saute à 1900 et met fin à la partie, sinon le niveau est dépassé.
    • 205 – Bloc qui vient de remplir d’eau l’ensemble du circuit de tuyaux assemblé.
    • 220 – Mettez à jour les points, augmentez le niveau et passez à 2100 pour monter un nouveau niveau.
    • 1000 – Routine qui place un bloc dans une certaine position.
    • 1100 – Routine qui sélectionne de manière aléatoire un nouveau bloc à quitter lors des prochaines exécutions.
    • 1200 – Routine qui montre les cinq blocs suivants à partir.
    • 1300 – Place le curseur dans la case sélectionnée.
    • 1350 – Supprimer le curseur de la case sélectionnée.
    • 1400 – Affiche le marqueur à 8 chiffres avec les points ou l’enregistrement.
    • 1900 – Le jeu se termine, met à jour le tableau de bord et marque une pause avant de passer à la présentation.
    • 2000 – Écran initial du jeu.
    • 2065 – Une touche doit être enfoncée. S’il se situe entre “1” et “9”, il est pris comme niveau initial et le jeu commence.
    • 2100 – Initialise les variables et détermine la difficulté du niveau.
    • 2105 – Dessine l’aire de jeu.
    • 2115 – Calcule les cinq prochains blocs qui vont sortir.
    • 2120 – Initialise la position des différentes cases.
    • 2130 – Calculez la position de la boîte initiale et enregistrez dans «W» l’adresse VRAM de la première position de l’eau.
    • 2135 – Calculer et positionner le curseur.
    • 2140 – À partir d’un certain niveau, les blocs avec la clé sont placés à 3 positions de la boîte initiale.
    • 3000 – Sélection des couleurs, effacement de l’écran, masquage du curseur et masquage des «CAPS» supérieurs.
    • 3005 – Lecture de données UDG.
    • 3010 – Assemblez les matrices avec des bandes de caractères.
    • 3020 – Lire les DONNÉES avec les directions de l’eau et leurs incréments.
    • 3025 – Chargez un tableau avec des chaînes numérotées de «01» à 25» et utilisées par les marqueurs. C’est plus rapide comme ça.
    • 9000 – DONNÉES avec graphiques UDG.
    • 9500 – DATA avec les différents types de blocs.
    • 9600 – DATA avec les directions de l’eau en fonction du type de tuyau.
    • 9700 – DATA permet de modifier la valeur «W» lorsque vous pointez vers la VRAM.

    Le jeu

    Pipe Mania est un jeu vidéo de type “casse-tête” développé en 1989 par The Assembly Line pour Amiga. Plus tard, LucasFilm Games a créé des versions pour d’autres machines sous le nom de Pipe Dream.

    Le pipe est confié à un plombier, Alfonzo, qui a pour objectif d’ajuster des tuyaux apparaissant au hasard dans une matrice contenant un robinet d’où sort de l’eau.

    Vous devez savoir que deux marqueurs effectuent un compte à rebours:

    • “T”: indique le temps restant avant que l’eau commence à traverser les tuyaux.
    • “D”: indique le temps restant pour terminer le niveau. Chaque unité correspond à un bloc.

    Mettre un bloc de tuyaux dans une boîte occupée nous bloquera quelques instants.

    À partir de certains niveaux, des blocs avec une clé ou des segments de tuyau apparaissent et ne peuvent être occupés.

    Sur l’écran de présentation, nous pouvons indiquer le niveau, entre 1 et 9, auquel commencer le jeu.

    Cette version suit exactement les mêmes mécanismes, mais les phases de bonus et certains types de blocs ont été éliminés.

    Contrôles:
    Contrôlez le curseur avec “Q” – “A” – “O” – “P” et appuyez sur “Espace” pour placer un segment de tuyaux.

    Quelle est votre préférée : la version Oric ou Amiga ?

    Quelques autres versions

    Pipe-Mania, au plus simple sur ZX-81