WordPress

Author: admin1957

  • Temporisation en langage machine

    par André C. avec l’aide de Christian L.

    Cet article a été corrigé grâce aux indications précieuses de Christian L. “Assinie” concernant l’interférence des interruptions dans la routine TEMPOB. Qu’il en soit cordialement remercié.

    La commande Basic WAIT est une petite merveille de simplicité d’utilisation. Il suffit d’indiquer une valeur de temporisation en centièmes de secondes et pourvu que les IRQ ne soient pas inhibées, l’exécution du programme se fige pendant le délai indiqué. La valeur du délai indiqué doit être comprise entre 0 et 65535 (en pratique entre 1 à 65535), ce qui permet des temporisations de 0,1 à 655 secondes (presque 11 min donc). C’est plus qu’il n’est utile.
    La précision de WAIT est étonnamment bonne. Mais il n’est pas possible d’obtenir des délais très brefs, car la valeur minimale est de 100 µs, ce qui est beaucoup comparé aux 2 µs qu’il est possible d’obtenir en langage machine, en insérant un NOP dans un programme. En effet NOP (No OPeration) ne fait rien, mais ça prend 2 cycles de microprocesseur, soit 2 µs dans le cas de l’Oric. Moi quand je ne fais rien, ça prend quand même plus de temps, heureusement ça n’arrive pas souvent !

    Temporisation à boucle

    Dans la plupart des programmes LM ainsi que dans les routines de la Rom, les temporisations sont basées sur des boucles. Mais vous verrez qu’il y a peut-être mieux à faire.
    Voici le principe d’une temporisation à boucle :

    C’est simple non ? Mais si on veut calculer le délai correspondant à cette valeur 5, ce n’est pas si facile. En effet, il faut tenir compte du nombre de cycles de microprocesseur que prend chaque instruction.
    De plus, très souvent ce nombre de cycle n’est pas une valeur fixe, mais dépend du contexte. Ainsi si LDX et DEX sont des cas simples car nécessitant toujours 2 cycles chacun, c’est plus compliqué avec BNE où trois cas peuvent se présenter :
    ● 2 cycles si le branchement n’a pas lieu.
    ● 3 cycles si le branchement a lieu (cas normal pendant la boucle).
    ● 4 cycles si le branchement a lieu avec un changement de page mémoire.
    Si on fait un bilan pour l’exemple ci-dessus, on a 2 cycles pour LDX, plus 4 fois 2+3 cycles (2 pour DEY + 3 pour BNE avec branchement) plus 1 fois 2+2 cycles (2 pour DEY + 2 pour BNE sans branchement) on arrive à un total de 26 cycles, soit 26 µs pour l’Oric, qui tourne à 1 MHz. Le calcul précédent peut se formuler ainsi : Le délai vaut D = 5Y -1 + 2 ( 1 pour le dernier BNE sans branchement et +2 pour le LDX initial).
    Le délai maximum pour une simple boucle est obtenu avec Y=#FF et se limite à environ 1,3 ms. (D = 256×5 -1 + 2 = 1281 µs). C’est exactement ce code que l’on trouve dans la Rom en #FAE1 pour la durée de ZAP.

    Temporisation à 2 boucles

    Si on veut obtenir un délai plus long, il faut imbriquer deux boucles. C’est ce qu’a fait Fabrice Broche pour OUPS, le nouveau son préprogrammé du Telestrat :

    Essayons de calculer le délai produit par l’exécution de cette routine :
    ● Pour les LDY et LDX d’initialisation : 4 cycles.
    ● Pour la 1e boucle : D = 256×5 – 1 = 1279 cycles (-1 pour le dernier BNE de la 1e boucle). Notez que cette 1e boucle se termine avec X=0 donc X est régénéré à sa valeur initiale pour la suite.
    ● Pour la 2e boucle : D= 96(1279+5) -1 = 123263 cycles (avec 1279 pour l’exécution de la 1e boucle et -1 pour le dernier BNE sans branchement de la 2e boucle). Notez que le temps d’exécution d’un tour de la 2e boucle inclus celui de l’exécution totale de la 1e boucle.
    Au total on a donc 123267 cycles, soit 123267 µs pour l’Oric. La durée théorique finale de OUPS est donc de 0,123 s (sauf si je me suis planté). On voit aussi que l’on peut simplifier ce calcul car il y a quelques cycles négligeables, par exemple les LDY et LDX initiaux et la réduction de 1 cycle pour BNE sans branchement. On arrive alors à un délai D = 96(1280+5) = 123360 µs, soit une approximation de +0,08%.
    Le délai maximum que l’on puisse obtenir avec 2 boucles avec X=#FF et Y=#FF est d’environ 0,33 ms.
    Le calcul simplifié donne D = 256(1280+5)=328960 µs. Ça risque de n’être pas assez dans certains cas. On pourrait ajouter quelques NOPs (2 cycles à chaque fois) dans la 1e boucle qui est exécutée 256×256=65536 fois. L’exécution s’allongerait alors de 65536×2=131072 cycles par NOP ajouté, c’est-à-dire 0,13 s, ce qui n’est pas négligeable. Mais, par exemple, pour atteindre un délai total de 1 s, il faudrait 5 NOP (131072 x 5 = 655360 cycles supplémentaires plus 328960 cycles initiaux = 984320 cycles, soit environ 0,98 s). Mais il ne serait pas raisonnable d’aller plus loin en accumulant les NOP.

    Temporisation à 3 boucles

    Si 1 s ne vous suffit pas, il faut ajouter une 3e boucle en utilisant le 3e registre du 6502 : L’accumulateur A (il n’existe pas de DEA pour décrémenter A, mais c’est facilement contournable). La temporisation maximale possible est tellement grande que l’on peut ajuster finement les valeurs respectives de A, Y et X pour obtenir un délai en chiffre rond. En voici un exemple pour obtenir un délai de 40 s. J’ai choisi cette durée afin de chronométrer la durée obtenue.

    Cette structure des boucles est nécessitée par la réinitialisation des compteurs au début de chaque boucle. A l’issue de la 1e boucle, X est automatiquement réinitialisé à zéro. Toutefois, cette remise à zéro est perdue dans le cas de l’exécution de la 3e boucle et doit être repositionnée. D’autre part, l’exécution de la 2e boucle se termine avec Y = zéro. Si l’on veut utiliser une valeur initiale de Y différente de zéro, il faut également repositionner Y. C’est pourquoi la 3e boucle ne se termine pas par un BNE BOUCL1, mais avec un BNE BOUCL3.
    En faisant abstraction de la durée réduite des BNE de fin de boucle et de 6 cycles pour les LDA, LDY et LDX initiaux, on peut faire le calcul simplifié suivant :
    ● L’exécution de la boule X dure D = 256×5 = 1280 µs.
    ● L’exécution de la boucle Y dure D = 156(1280+5) = 200460 µs soit environ 0,20 s
    ● L’exécution de la boucle A dure D = 200(200460+9) = 40093800 µs soit environ 40 s.
    En ajustant les valeurs de Y et A il est possible d’obtenir la durée dont on a besoin. Il suffit de faire quelques calculs avec les formules ci-dessus.
    Durée maximale possible avec une temporisation à 3 boucles (hors ajout de NOPs) : 84 s
    ● L’exécution de la boule X dure D = 256×5 = 1280 µs.
    ● L’exécution de la boucle Y dure D = 256(1280+5) = 328960 µs soit environ 0,32 s
    ● L’exécution de la boucle A dure D = 256(328960+9) = 84216064 µs soit environ 84 s.

    Temporisation avec le Timer 2

    Vous vous rappelez la simplicité de mise en œuvre de la commande Basic WAIT ? Si on consulte “L’Oric à nu” page 186, on peut examiner ce que fait cette routine. Le paramètre qui suit WAIT (nombre de centièmes de secondes de délai) est analysé, puis placé en page zéro aux adresses #33 (LL de a valeur) et #34 (HH de la valeur). Le registre A est initialisé avec #02 (n° du timer à utiliser), puis le registre Y reçoit le contenu de la mémoire #33 et X celui de #34. La routine #EEAB écrit la valeur YX dans le timer 2, lequel est décrémenté tous les centièmes de secondes. On lit l’état du timer 2 avec la routine #EE9D et on sort quand il tombe à zéro.
    Voici un exemple qui permet d’obtenir un délai de 40 s :

    Quelques mesures

    Pour vérifier les exemples, j’ai comparé ce que donnent WAIT 4000, TEMPOB et TEMPOT avec un Atmos réel, un Atmos sous Euphoric+DosBox et un Atmos sous Oricutron 1.2. Voici les résultats :

    Atmos réelEuphoricOricutron
    WAIT 400040s42s41s
    TEMPOB40s42s41s
    TEMPOT40s42s41s
    Temporisations mesurées

    L’Atmos donne les valeurs escomptées pour WAIT 4000, TEMPOB et TEMPOT. Par contre Oricutron donne des valeurs légèrement plus élevées, mais qui restent dans la limite de la précision de mon chronométrage. Pour Euphoric, c’est encore plus marqué, mais peut-être est-ce dû à DosBox. J’ai déjà remarqué ce défaut de réactivité avec DosBox dans d’autres situations.

    Conclusion

    La temporisation avec le timer 2 est plus facile à mettre en œuvre que les temporisations à boucles et devrait être utilisée préférentiellement pour les délais de 0,1 à 655 s (comme WAIT). Il n’en reste pas moins que pour les petits délais une simple boucle permet de temporiser jusqu’à 1281 µs (et éventuellement deux boucles pour aller jusqu’à 0,33 s). Il n’y donc que l’embarras du choix quant à la méthode à utiliser !

    Disquette TEMPORIS.DSKTélécharger

  • Solomon’s Key

    Le dernier acte (connu à ce jour) de la programmation multi-ordinateurs en basic par Dan Cresp, et un coup de chapeau à Dom

    Informations générales

    Après presque quatre ans sans programmer sur l’ORIC, quand Dan reprend la création de soft avec «Averno», il est tellement satisfait du résultat qu’il s’engage dans un autre projet encore plus complexe.

    AVERNO a été le premier jeu que réalisé en BASIC par Dan où le protagoniste passe en arrière-plan sans défauts d’affichage. Pour ce faire, Dan a placé la totalité de la zone de jeu dans une matrice texte et déplace le fantôme en reconstituant l’arrière-plan à partir des données de cette matrice. Le résultat est bon mais le coût de cette routine, ainsi que la maintenance de la matrice sont élevés. Le processus prend environ 10 secondes. Sur le plan graphique, l’utilisation de 3×2 caractères lui permettait de réaliser des graphismes presque identiques à l’original … monochromes.

    Par la suite, Dom sur oric-concours.forumactif.org a amélioré l’apparence du jeu en utilisant une propriété des attributs de couleur de l’écran permettant d’afficher les couleurs complémentaires des couleurs principales. Il a également amélioré la composition du niveau en enregistrant les écrans. Et pour simplifier l’ensemble, il a transféré le logiciel sur une disquette. L’on doit admettre que la version s’est améliorée et que son apparence est meilleure. Bravo !!!

    Avec Solomon’s Key, Dan va un cran plus loin dans la conception de l’écran.

    Un écran titre alléchant !

    Sprites
    Cette fois, Dan a voulu expérimenter une utilisation améliorée des «sprites», sans avoir à monter l’usine à gaz de la matrice écran, et insérer directement des valeurs 16 bits dans la mémoire vidéo à l’aide de l’instruction DOKE, qui affecte l’adresse de mémoire indiquée et la suivante.

    Dan n’avait pas réussi à mettre en oeuvre ce processus auparavant même si au final, il est assez simple. Brièvement, chaque image-objet a une taille de 2×2 caractères. Avant de placer une image-objet à l’écran, Dan enregistre la valeur de 2×2 caractères où elle sera insérée dans deux variables numériques. Ceci est fait avec un DEEK, qui est un PEEK 16 bits (à l’image du DOKE qui est un POKE 16 bits). La position de l’image-objet est une adresse mémoire et non deux coordonnées. Avec deux DOKE, il copie rapidement le sprite sur l’écran. Avant de le déplacer, Dan remplace l’arrière-plan à la position correspondante à partir de la valeur stockée dans la variable numérique, modifie la position de l’image-objet, enregistre l’arrière-plan dans la variable, puis le place dans la nouvelle position à l’aide des deux clés. Le résultat est là, efficace.

    L’écran
    Sur ZX-Spectrum, le jeu original a une largeur d’écran de 32 caractères. Deux pour les marges et 15 blocs de 2×2 caractères. Pour que cette version ait le même aspect, Dan aurais dû utiliser des blocs 3×2, mais avec l’ORIC, il est limité à 38 colonnes, loin de son besoin de 47. De fait, Dan a été contraint à réduire la taille des sprites à 2×2. De plus, les caractères de l’Oric font 6 pixels au lieu des 8 habituels. L’aspect final est de fait moins fouillé, mais avec des graphiques rapides mis en oeuvre avec les 2 DOKE.

    Comme la largeur de l’écran comporte plus de caractères, Dan a placé une colonne de blocs des deux côtés de l’écran et une colonne inférieure. Cela l’a également aidé à contrôler le déplacement des éléments mobiles du jeu.

    Dans le code, sur les lignes 440 à 455, trois lignes calculent quel bloc de fond doit être placé dans une zone de l’écran quand un bloc bleu est supprimé, et lorsque l’on prend la clé ou une pièce de monnaie, ou encore quand un ennemi frappe.

    Graphiques
    Le jeu de caractères ORIC ne comporte que 128 caractères. Dan souhaitait conserver les lettres, les chiffres et certains caractères spéciaux, Il a donc redéfini le minimum de blocs graphiques possibles. L’utilisation de deux caractères en largeur de bloc au lieu de trois a contribué à cet objectif. L’impact principal de ces options a été la suppression du mouvement de jambes de notre personnage ; mais cela a également permis de simplifier quelque peu le code et à améliorer les performances. Dan peut toujours tout montrer avec deux simples DOKE.

    Et comme toujours avec les programmes développés par Dan sur ORIC, les graphiques ont dû être redessinés par rapport à la version initiale car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice 8×6 soit 12 pixels horizontaux au lieu des 16 habituels.

    Les couleurs … encore un problème !
    En raison de la façon dont l’Oric gère les attributs, Dan a choisi de créer Solomon’s Key en monochrome, avec un peu de couleur dans la présentation et dans les marqueurs. Pour mettre en évidence les briques que nous pouvons détruire, Dan a appliqué la technique consistant à utiliser les couleurs complémentaires des deux couleurs principales en ajoutant 128 au code ASCII du personnage (les caractères inversés). permettant d’afficher 4 couleurs sur l’écran de jeu.

    L’encodage des niveaux
    A ce stade, nous arrivons à la création de l’écran. Chaque écran est constitué d’une matrice de 12 lignes et de 15 colonnes. Dans chaque colonne se trouve un tableau de caractères 2×2, tel que des blocs de pierre, des portes, des clés ou des pièces de monnaie. Dan a choisi de coder les niveaux en utilisant un format similaire à «Averno» simplifié.
    La présentation du niveau prend environ 6 secondes et le codage est effectué comme suit:

    • Une lettre entre “A” et “Z” a une valeur comprise entre 1 et 26 et correspond aux blocs de pierre à afficher. Alternativement, ils apparaissent en jaune ou en bleu.
    • Un caractère “*” signifie qu’il modifie le type de bloc de pierre indiqué, bleu ou jaune.
    • Une lettre entre “a” et “z” a une valeur comprise entre 1 et 26 et correspond à des blocs vides de 2×2.
    • Un caractère “.” Désigne un bout de la ligne en sautant au suivant.
    • Un caractère numérique correspond à un objet:
      • 2 portes,
      • 3 clés,
      • 4 devises,
      • 6 têtes et
      • 7 canaux.
      • 1, et 5 correspondent aux blocs de pierre jaune et bleue.
    Un écran de jeu de Solomon’s Key, avec l’aperçu de son encodage graphique

    Le contrôle du personnage
    Une des premières difficultés à résoudre avant de commencer à développer le jeu était de savoir comment gérer les différents mouvements et actions que le joueur pouvait faire. La programmation du jeu en Basic prend en compte l’impossibilité d’appuyer sur plusieurs touches simultanément.

    • Appuyez sur “Z” et “X” pour déplacer le magicien à gauche ou à droite.
    • En appuyant sur “P” nous sautons. S’il y a un bloc au-dessus, nous le cassons. Sinon, nous pouvons augmenter la hauteur d’un bloc. Si pendant que nous sautons, nous appuyons sur une flèche, nous irons dans cette direction.
    • En appuyant sur “L” nous insérons ou supprimons un bloc bleu. Si nous sommes juste au-dessus d’un bloc, nous le placerons devant et si nous ne le plaçons pas au niveau du sol.

    Les Ennemis
    Contrairement au jeu “Averno”, dans ce “Solomon’s Key”, il y a des ennemis et ils bougent !
    Dan a mis en place une routine très basique qui permet de déplacer jusqu’à cinq ennemis avec deux vitesses différentes (des déplacements de un ou deux caractères), leur déplacement est horizontal ou vertical, et simule l’effet de rebond ou non lorsque vous touchez un mur, en détruisant les blocs bleus touchées. Le tout en sept lignes de code !

    Le type de mouvement de l’ennemi et sa position initiale sont définis dans les DATA de la ligne 9600. Chaque ennemi requiert trois caractères :

    • le premier indique le type
    • les deux autres la position initiale horizontale et verticale. Pour les positions, Dan utilise des lettres afin d’indiquer des valeurs supérieures à un chiffre avec un seul caractère.

    La routine de mouvement contrôle le nombre d’ennemis dans ce niveau. Moins il y a d’ennemis, plus ils se déplacent fréquemment et rapidement.

    Les sprites des ennemis se déplacent également sur le fond sans le supprimer. Comme pour le sprite du protagoniste, la technique de sauvegarde du personnage qui était à l’écran avant d’utiliser l’ennemi sur l’écran a été utilisée. Lorsqu’il se déplace, il reconstitue l’arrière-plan, sa nouvelle position est recalculée, puis le graphique de l’ennemi est placé.

    Résultat final
    En ce qui concerne la vitesse, l’ORIC BASIC pourrait être placé dans le milieu de gamme des ordinateurs 8 bits. C’est l’un des plus rapides en impression à l’écran, mais pour le reste, ce serait au niveau du MSX ou du ZX-Spectrum. Des ordinateurs tels que l’Amstrad CPC impriment très lentement à l’écran mais plus rapidement, en parallèle avec des ordinateurs tels que BBC Micro / Electron ou Lynx Camputers. La gamme basse reste pour le ZX-81 et surtout, le Texas Instruments TI / 99-4A qui mange séparément.

    Après toutes ces briques, je dois admettre que, malgré les limites imposées par ORIC BASIC, de par son apparence et ses performances, je suis très satisfait. Cela ressemble à un jeu commercial, mais c’est du BASIC pur et dur. Je pense que ce n’est pas habituel de regarder des programmes en BASIC comme celui-ci. Je pense que j’ai placé la barre très haut, mais avec l’expérimentation de ces techniques, je suis sûr que je ferai autre chose bientôt. En fait, au fond de moi, j’ai déjà l’idée d’adapter un classique qui n’existe pas dans ORIC.

    Eh bien, rien de plus, je ne peux qu’espérer que cela vous plaise …

    Je vous invite à l’essayer.

    Quelques éléments concernant le programme

    La routine principale du programme est divisée en 10 blocs:

    • Déclaration des variables et matrices et début du jeu.
    • Boucle principale de développement.
    • Mouvement des ennemis.
    • Mouvement du protagoniste.
    • Routines des actions du protagoniste.
    • Passer le niveau ou perdre une vie.
    • Routine pour montrer le niveau de jeu.
    • Présentation et début du jeu.
    • Charger UDG.
    • DATA avec les UDG du jeu et les valeurs de la matrice.

    L’ensemble du programme occupe 170 lignes dont vous trouverez ci-dessous les principales :

    • 5 – Nous définissons les variables du jeu.
    • 10 – Nous définissons les matrices du jeu.
    • 20 – Passez au sous-programme qui redéfinit les caractères et définit les variables globales.
    • 40 – Afficher le niveau à l’écran.
    • 100 – REPEAT indiquant le début de la boucle principale.
    • 105 – Vérifiez si nous sautons.
    • 110 – Si nous n’avons pas de terre sous nos pieds, le personnage tombe.
    • 115 – Prenez la touche appuyée.
    • 120 – Touche de saut.
    • 125 – Bloquer la touche marche / arrêt.
    • 130 – Touche de déplacement à droite.
    • 135 – Touche de déplacement gauche.
    • 140 – Vérifiez si le personnage frappe à la porte, à la clé ou à la pièce de monnaie.
    • 150 – Aller au sous-programme de mouvement ennemi.
    • 155 – Retournez à REPEAT si la variable U = 0.
    • 160 – Lorsque vous quittez la boucle, regardez la valeur de U. U = -1 niveau et U = 2 perd une vie.
    • 200 – Déplace le fantôme vers la droite.
    • 225 – Déplace le fantôme vers la gauche.
    • 300 – Contrôle la chute du personnage.
    • 320 – Détecte quel objet tu as sous le personnage.
    • 350 – Routine de saut.
    • 400 – Mettre / enlever le bloc.
    • 440 – Routine de remplacement en arrière-plan lors de la pose, de la suppression d’un bloc ou de la saisie d’un objet.
    • 500 – Routine pour passer un niveau.
    • 550 – Programme de perte de vie et fin du jeu.
    • 600 – Montre les marqueurs de points, de niveau et de vies.
    • 2000 – Routine qui montre le niveau. Les données sont encodées dans la matrice M $.
    • 2050 – Définissez le type, la vitesse et la direction des ennemis et placez-les à l’écran.
    • 2500 – Écran de présentation.
    • 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 – Définir des variables avec des bandes de caractères.
    • 9000 – DATA avec graphes, positions, blocs de graphes et codage de niveau UDG.
    • 9200 – Blocs graphiques utilisés par l’instruction DOKE.
    • 9300 – Position initiale du caractère en fonction de l’écran.
    • 9500 – Données de niveau.
    • 9600 – Données avec les types et la position des ennemis.

    Le Jeu !

    Solomon’s Key est un jeu publié par Tecmo en 1986 et concédé sous licence pour différents systèmes à partir de 1987. US Gold a commandé les versions 8 bits du jeu.

    Le jeu est de type plates-formes avec une pincée de jeu de stratégie. Nous y contrôlons un petit sorcier qui doit saisir une clé et sortir pour monter de niveau. Le magicien a la capacité de créer et de détruire des blocs bleus qui lui permettront d’atteindre la clé. Chaque niveau est plein d’ennemis qui te tueront au moindre contact. Le petit sorcier part avec 5 vies.

    La version développée par Dan utilise les mêmes mécanismes que le jeu original avec les 17 écrans de la version ZX-Spectrum, qui sont répétés indéfiniment. Le mouvement des ennemis est adapté aux limitations du BASIC.

    Contrôles :

    • Déplacez l’assistant à gauche ou à droite avec “Z” et “X”.
    • Appuyez sur “L” pour créer ou détruire un bloc bleu. Selon votre position, il sera créé devant vous à votre hauteur ou à une hauteur inférieure.
    • Appuyez sur “P” pour sauter, avec en plus la possibilité de contrôler la direction en appuyant sur “Z” ou “X”. Si vous avez un bloc en haut, vous le détruisez d’un coup de tête.

    Comparons …

    Comparaison des versions Oric-Atmos et ZX-Spectrum

  • Radar Oric 2

    Une seconde version quelque peu améliorée

    par André C.

    Comme indiqué dans le sous-titre, il s’agit d’une version améliorée de Radar Oric (voir le CEO-mag n°358, pages 4 & 5 et RadarOric.dsk dans le fichier 358.zip). Outre de nouvelles commandes, cette version comporte 48 nouvelles grilles réparties en 3 niveaux de difficulté (1 Fastoche, 2 Faisable et 3 Fortiche). Autre petit plus : Le jeu est maintenant bilingue Anglais et Français.

    Rappel du synopsis

    Votre QG 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.

    Vitesse de déplacement du curseur

    A l’usage, il est apparu que Radar Oric pouvait être amélioré.

    Tout d’abord, le déplacement du curseur trainait beaucoup trop lentement dans les 100 cases de la grille. J’ai donc un peu revu l’algorithme du jeu afin de perdre le moins de temps possible. Cela a entraîné une redéfinition des labels à attribuer aux cases. Ces labels, sont maintenant passés de 1 à 9 :

    1 – Case vide

    2 –  De l’eau (et sans sous-marin par-dessous !)

    3 – Élément de bateau présent mais indéterminé ou hypothèse de présence d’un élément

    4 – Sous-marin

    5 – Extrémité “gauche” d’un navire

    6 – Extrémité “droite” d’un navire

    7 – Extrémité du “haut” d’un navire

    8 – Extrémité du “bas” d’un navire

    9 – Élément du corps d’un navire

    La nouveauté importante est l’ajout du label 3 qui permet de placer des hypothèses, ce qui n’est pas du luxe pour les grilles de “Fortiches”.

    Autre innovation pour accélérer les déplacements : les mystérieuses commandes H et V. En fait, elles n’ont rien de mystérieux. C’est plutôt que je n’arrivais pas à décrire ces commandes de manière concise dans mon écran d’instructions ! Les commandes H ou V éditent la ligne Horizontale ou la colonne Verticale où se trouve le curseur. Cette édition consiste à marquer toutes les cases de la ligne ou de la colonne avec le label 2 (de l’eau), sauf si une hypothèse ou un élément de bateau est déjà présent. Cerise sur le bateau, le compteur des coups joués n’est pas incrémenté : non seulement vous gagnez du temps dans le déplacement du curseur, mais vous améliorez  vos performances, qui je le rappelle sont la combinaison d’un score maximum ET d’un nombre minimal de déplacements.  En outre, vous réduirez vos déplacements  car le curseur reste à la position initiale, ce qui vous permet d’atteindre des cases distantes sans perdre de temps pour vous y rendre et pour revenir !

    Nouvelles commandes

    Le jeu comporte maintenant 7 commandes au lieu de 4.

    Outre le commandes H et V décrites ci-dessus et les commandes déjà présentes dans la première version (flèches de déplacement, numéros de label pour les cases, R pour reprendre au début la grille en cours et S pour sauver la partie en cours afin d’aller faire dodo), la nouvelle version offre la commande L qui permet de charger (Load) la partie précédemment sauvegardée. Dans la première version de Radar Oric, on ne pouvait choisir cette option que lors du lancement du jeu. Recharger la partie sauvegardée sort donc maintenant de son rôle initial (reprise de la partie le lendemain).

    En effet, au cours de la résolution d’une grille complexe, lorsque plusieurs possibilités s’offrent à vous, il est intéressant d’effectuer une sorte de point de restauration avec la commande S. Si la voie dans laquelle vous vous étiez engagée se révèle erronée, il vous suffit de restaurer l’état précédent avec la commande L et de tester une autre hypothèse. La commande R au contraire régénère la grille à son point de départ. Cette commande sert en principe à repartir sur un bon pied lorsque la situation est devenue trop embrouillée. Le score affiché est alors celui qui était présent lors du chargement initial de cette grille et non celui qui était acquis au moment “du point de restauration”. J’espère que vous apprécierez la meilleure jouabilité de Radar Oric 2 et que ce petit jeu de réflexion vous apportera quelques moments agréables…

    RADAR2.DSKTélécharger

  • Des programmes pour votre Oric

    de Michel Piot, Cedic/Fernand Nathan (1983)

    Des nouvelles de la Librairie Oric de CEO

    Notre Librairie Oric compte environ 80 livres en Français, Anglais et Espagnol, mais malheureusement, à ma connaissance, aucun en Allemand, ce qui est fâcheux pour nos cousins germains. Les ouvrages  les plus importants y figurent, grâce au dévouement de Jérôme et de Didier, sans oublier ceux qui ont envoyé des livres ou des scans. Mais il en manque encore pas mal et nous comptons sur vous pour contribuer à enrichir cette collection. L’ouvrage présenté aujourd’hui m’a été transmis par quelqu’un ayant appris indirectement que je m’intéressais à l’Oric. Comme quoi toutes les voies sont bonnes ! Je l’ai donc scanné et OCRisé et il est maintenant disponible en téléchargement :

    Des-programmes-pour-votre-Oric-OCR.pdfTélécharger

    Comment accéder à la Librairie du CEO?

    L’url https://oric.bqtt.net/doku.php?id=private:librairie n’est plus valable, mais la page https://ceobeta.oric.org/doku.php?id=private:librairie est encore active. Je suppose que son équivalent définitif sera bientôt mis en ligne. En effet, La refonte en cours du site oric.org et de la page du CEO est un énorme travail et vous comprendrez qu’il entraîne forcément quelques inconvénients. En cas d’urgence, vous trouverez tous ces livres sur mon site.

    Des programmes pour votre Oric

    Il s’agit d’un livre d’initiation à l’Oric-1 comportant 24 petits programmes d’application.

    Pratiquement tous les éditeurs ont publié ce type de bouquin et même souvent plusieurs (avec les mêmes auteurs ou avec des auteurs différents). A l’époque, il devait donc s’agir d’un marché juteux. La plupart du temps ces livres ont été publiés dans l’urgence lors de la sortie d’un nouvel ordinateur. La concurrence entre les maisons d’édition était féroce. Il en a hélas résulté que nombre de ces livres ne sont pas d’une qualité transcendante. Cependant, la bibliothèque du CEO se veut d’être exhaustive, autant que possible, et il fallait donc faire une petite place pour le livre de Michel Piot.

    Le contenu de ce livre

    Il est maigre : 120 petites pages, dont en annexe, les codes Ascii et les attributs ! Ces deux annexes font grise mine à côté de celles, abondantes et bien faites, du manuel de John Scriven, livré avec l’Oric-1 (téléchargeable dans la librairie du CEO).

    Le coté initiation se fait au fur et à mesure des programmes proposés. L’auteur a cherché à utiliser un maximum de commandes Basic pour en illustrer l’emploi. Etant donné la faible épaisseur du livre, Michel Piot aurait pu développer un peu le chapitre 15 “Le Basic de l’Oric” du manuel de John Scriven.

    Pendant que j’en suis aux récriminations, les illustrations (des photos de l’écran réel) sont souvent illisibles. Enfin, les listings sont issus d’une imprimante à aiguilles et certaines lignes sont réfractaires à toute OCRisation. Je doute qu’il soit possible de récupérer un listing utilisable. En règle générale, on est toujours obligé d’apporter des retouches aux listings issus d’une OCRisation, mais là, ça ne me semble pas rentable.

    Je vais être plus positif avec les 24 programmes proposés qui sortent souvent des sentiers battus habituels (chenille, pendu etc.) et on peut y trouver quelques belles idées qui pourraient servir de point de départ pour un développement plus conséquent… Je vous laisse le soin de les explorer…

  • CEO-MAG 359

    Sommaire

    Edito

    Bonjour à tous,

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

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

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

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

    [wpdm_package id=’3140′]

    [wpdm_package id=’3138′]

  • Récupérez les caractères redéfinis de tous les logiciels : 2 – Deux exemples “Rush Hour” et “The Hellion”

    par André C.

    Comme nous l’avons vu dans l’article précédent, peu importe que le logiciel à traiter soit protégé ou non, l’essentiel est qu’il soit possible de le faire tourner sur un émulateur et de pouvoir réaliser un dump de la mémoire.

    Disons que si le logiciel n’est pas protégé (ou s’il a été déverrouillé), il est plus facile de savoir s’il est écrit en Basic ou en langage machine, s’il tourne en mode TEXT ou HIRES, s’il utilise les zones normales de stockage des caractères et les procédures normales d’affichage.

    Il y a trois grandes catégories de logiciels :

    1.      Ceux dont les caractères sont redéfinis uniquement lors du lancement.

    2.      Ceux dont les redéfinitions évoluent au fil de l’exécution.

    3.      Ceux dont les caractères ne sont pas redéfinis (oups !).

    1) Logiciels dont les caractères sont redéfinis uniquement lors du lancement

    Dans cette catégorie, j’ai pris comme exemple “Rush Hour” de Fabrice F. En effet ce logiciel est particulièrement astucieux.

    Pour contourner les difficultés d’un cahier des charges très lourd, Fabrice a recopié les caractères utiles du jeu 0 dit “normal” dans le jeu 1 dit “semi-graphique” (dont les caractères d’origine sont évidemment écrasés). Pour l’affichage de texte standard, il faudra désormais utiliser le mode “semi-graphique” ! Les 96 caractères du jeu 0 étant “disponibles” ont été redéfinis pour afficher les sprites de divers véhicules. Notez que ce programme n’est pas protégé et que son listing est bien documenté.

    Procédure dans Euphoric :

    1. Lancez Euphoric, chargez “Rush Hour” (RUSHHOUR.TAP) et lancez-le.
    2. Avancez dans le jeu, dans mon exemple, jusqu’au “Level 11” (choix “Harder”).
    3. Pressez la touche F9 pour générer un dump mémoire. Renommez par exemple en DumpRH.BIN
    4. Pressez F12 pour générer une recopie d’écran au format .BMP. Renommez par exemple en RushHourLevel11.BMP
    5. Laissez Euphoric en attente.

    Procédure dans votre éditeur hexadécimal :

    1.      Ouvrez le modèle d’en-tête SAVJ0TXT.TAP (voir article précédent). CTRL+A puis CTRL+C pour copier les 23 octets du fichier.

    2.      Ouvrez un nouveau document. CTRL+V pour y coller l’en-tête. Modifiez cet en-tête uniquement pour le renommer (par exemple RHJ0TXT).

    3.      Ouvrez le fichier DumpRH.BIN de “Rush Hour”. Allez à l’offset #B500 et sélectionnez les #0300 octets du jeu 0, puis tapez CTRL+C pour copier cette zone.

    4.      Allez à la fin de l’en-tête dans le nouveau document. CTRL+V, pour y coller le jeu 0.

    5.      Sauvegardez votre jeu sous le nom RHJ0TXT.TAP (Rush Hour, Jeu 0, mode TEXT).

    6.      Faites la même chose pour le jeu 1 (SAVJ1TXT.TAP, RHJ1TXT, #B900, #0200 octets, RHJ1TXT.TAP).

    7.      Toujours dans votre éditeur hexadécimal, réglez l’affichage pour 40 octets par ligne, afin qu’une ligne dans l’éditeur corresponde à une ligne de l’écran Oric et allez en #BB80 (début de l’écran TEXT).

    8.      Reprenez la fenêtre d’Euphoric qui était restée en attente et placez là immédiatement à gauche de la zone d’affichage des codes Ascii de votre éditeur (voir la figure ci-dessous). Vous avez maintenant la correspondance entre les véhicules de “Rush Hour” à gauche et les codes Ascii utilisés pour l’assemblage des sprites !

    RecupCaract2Télécharger

    2) Logiciels dont la redéfinition des caractères évolue au fil de l’exécution

    Cette catégorie est semblable à la précédente, sauf que les caractères sont redéfinis pour chaque phase du jeu !

    L’exemple le plus frappant est “The Hellion” avec 101 écrans où se meuvent les sprites d’objets très différents en quantité invraisemblable. En fait, les 101 tableaux de “The Hellion” représentent un cas extrême de redéfinitions à répétition.

    Ce logiciel fonctionne en mode TEXT et les 2 jeux de caractères sont partiellement redéfinis. Vous trouverez le programme (HELLION.WAV, HELLION.TAP & HELLION.DSK au choix), ainsi que les fichiers utilisés ou produits dans cet exemple dans le zip qui accompagne cet article.

    Procédure dans Euphoric

    Il faut traiter “The Hellion” comme s’il s’agissait d’une série de 101 programmes indépendants, mais réunis à la queue-leu-leu. La procédure suivante devra donc être répétée pour chaque tableau :

    1.      Pressez la touche F9 (sauvegarde d’un dump de la mémoire) au début de chaque tableau.

    2.      Puis, le plus vite possible, pressez la touche F12 pour avoir une recopie de l’écran correspondant à ce dump (le plus rapidement possible car les sprites se déplacent très vite).

    3.           Et enfin pressez F11 pour geler la série de tableaux, le temps de renommer le fichier “DUMP” en “DumpH-xx.bin” ainsi que la recopie d’écran en “Hellion-xx.bmp”, xx étant le n° du tableau.

    Procédure dans votre éditeur hexadécimal :

    Chacun des fichiers “DumpHxx.bin” sera traité dans votre éditeur Hexadécimal pour en extraire les deux jeux de caractères et afficher la zone d’écran TEXT. Prenons par exemple le fichier DumpH04.bin :

    1. Ouvrez le modèle d’en-tête SAVJ0TXT.TAP. CTRL+A puis CTRL+C pour copier les 23 octets du fichier.
    2. Ouvrez un nouveau document. CTRL+V pour y coller l’en-tête. Modifiez cet en-tête pour le renommer (par exemple “H04J0TXT”).
    3. Ouvrez le fichier “DumpH04.bin”. Allez à l’offset #B500 et sélectionnez les #0300 octets du jeu 0, puis tapez CTRL+C pour copier cette zone.
    4. Allez à la fin de l’en-tête dans le nouveau document. CTRL+V, pour y coller le jeu 0.
    5. Sauvegardez votre jeu 0 par exemple sous le nom H04J0TXT.TAP (Hellion, tableau “Wave 4”, Jeu 0, mode TEXT).
    6. Faites la même chose pour le jeu 1 avec le modèle SAVJ1TXT.TAP et sauvegarder le jeu 1 par exemple sous le nom H04J1TXT.TAP (Hellion, tableau “Wave 4”, Jeu 1, mode TEXT).
    7. Toujours dans votre éditeur hexadécimal, réglez l’affichage pour 40 octets par ligne, afin qu’une ligne dans l’éditeur corresponde à une ligne de l’écran Oric et allez en #BB80 (début de l’écran TEXT).
    8. Reprenez la fenêtre d’Euphoric qui était restée en attente et placez là immédiatement à gauche de la zone d’affichage des codes Ascii de votre éditeur (voir la figure ci-dessous). Vous avez maintenant la correspondance entre les “feux tricolores” de “The Hellion” à gauche et les codes Ascii utilisés pour l’assemblage de ces sprites à droite !

    Si on compare le jeu 0 obtenu à partir de ce tableau  “Wave 4” avec le jeu 0 natif de l’Oric, on constate que deux caractères seulement sont redéfinis : { (Ascii 123) et } (Ascii 125) (et cette redéfinition varie d’ailleurs d’un tableau à l’autre).

    Pour le reste, les sprites affichés sont formés avec des caractères du jeu 1 (un attribut #09 est placé au début de chaque ligne d’écran).

    Dans le tableau “Wave 4” (voir la figure ci-dessus), les objets volants (des feux tricolores) sont redéfinis avec les caractères 1 2 3 4 ou 5 6 7 8 ou 9 : ; < disposés verticalement.

    C’est plus compliqué pour l’oiseau du bas de l’écran, car celui-ci vole et plusieurs sprites se succèdent pour réaliser cette animation. J’ai détecté des images redéfinies avec = > ? sur une 1e ligne et @ A B en dessous, ou C D E et F G H ou I J K et L M N ou O P Q et R S T ou U V W et X Y Z. L’animation est donc réalisée avec 5 images. Avec 6 caractères redéfinis par image, cela fait 30 caractères redéfinis rien que pour l’oiseau !

    Dans tous les cas (feux tricolores ou oiseau) un attribut de couleur est placé juste à gauche de chacune des lignes des sprites, ce qui permet d’obtenir des sprites multicolores.

    Pour ne pas alourdir cet article, je ne montre que ce tableau “Wave 4”. Mais dans le tableau suivant “Wave 5”, chaque sprite est défini par les mêmes 4 caractères 1 2 3 4 ou 5 6 7 8 ou 9 : ; < disposés sur deux lignes. Or ces caractères ont été redéfinis entre temps puisque les dessins affichés sont différents. L’oiseau qui ressemble comme deux gouttes au précédent est affiché à partir des même 5 jeux de redéfinitions que précédemment ! Je ne suis pas allé plus loin dans mon analyse des 101 tableaux de “The Hellion”. Mais si certains sprites vous intéressent, vous devriez pouvoir les récupérer sans difficulté en suivant mes indications.

    3) Logiciels dont les caractères ne sont pas redéfinis

    Avant de vouloir récupérer des caractères redéfinis, il serait sage de s’assurer qu’il y en a. La présence de sprites sur l’écran ne signifie pas que des caractères ont été redéfinis. C’est, la plupart du temps, le cas pour les programmes qui tournent en mode Hires et qui sont, quasiment à coup sûr, écrits en langage machine. En effet, le Basic n’est pas assez rapide pour faire évoluer des sprites sur l’écran (ni même des caractères via la commande CHAR).

    Pour cette catégorie de logiciels, il s’agira plutôt de récupérer des sprites. Mon prochain article :

     “Récupérez les sprites de tous les logiciels en HIRES” montrera comment s’y prendre sans avoir à désosser le langage machine.

    A bientôt…

  • Carte mère Oric

    J’ai reçu (un peu de façon inattendue par ces temps-ci) la carte mère d’Oric que j’avais commandée (et pour une fois, pas miC…) :

    Et oui ! On peut acheter un PCB nu de carte mère d’Oric…
    Les pastilles ont l’air de bonne qualité, les pistes aussi.

    Mais elle nécessite d’être testée. Déjà, on remarque que R26 a une patte en l’air…
    Peut-être faudra-t’il un câble de jonction pour d’autres composants ?
    Ce topic permettra d’en suivre les évolutions.

    Premières modifications : R26 doit être reliée déjà masse et les pattes 1 des deux 74LS257 doivent être reliées ensemble.

    Suite (mai 2020) : implantation des résistances et problème au niveau de RP1

    Le but étant de reproduire une carte fonctionnelle mais incomplète (pas de partie UHF), destinée à remplacer une carte Oric originale, l’implantation des composants se fera en plusieurs temps.

    Tout d’abord, pour tester le fonctionnement minimum de la carte mère, seront mis en place les circuits suivants: 6502, 6522, ULA, EPROM, AY3-8912, les huit DRAM, les deux 74Ls257, le 74LS04 et le 74LS365, tous montés sur supports (ça aide pour la maintenance !). Quelques résistances et condensateurs, un Quartz, un transistor, un connecteur pour le clavier et un pour la partie vidéo accompagneront le lot.
    Plus tard viendront les autres connecteurs, le 7905 (ou 7805 ?), l’ampli LM386, le LM358 pour les entrées-sorties Son Cassette, le relais, le haut-parleur, le bouton poussoir de Reset, une deuxième Eprom avec sélecteur.


    Pour commencer, il est bon de placer en premier les composants qui ont le moins de hauteur sur la carte. On peut penser aux résistances ou aux diodes. Puis viendront les supports de CI, les condensateurs, le quartz, les connecteurs…

    La référence est le schéma de Fred72.
    Voici donc les résistances nécessaires :

    De gauche à droite,
    – les deux 1 KOhm (pour Quartz et 74LS04),
    – les quatre 220 Ohm (pour sortie vidéo),
    – la 2,2 KOhm (pour la patte 2 du 74LS365),
    – les deux 47 KOhm (pour gestion clavier),
    – la 220 KOhm (pour Reset au démarrage),
    – les cinq 2,2 KOhm (pour jouer le rôle de RP1).

    RP1 ? Kézako ?
    Il s’agit d’un réseau de résistances de 2,2 KOhm à 8 pattes.

    Sept résistances reliées à un point commun (dont l’emplacement est marqué avec un point noir). Dans l’ORIC, ce point commun est branché au + 5 Volt. On peut nommer les résistances de R1 à R7 :

    Sept résistances… Oui, mais il ne nous en faut que cinq ?

    Un coup d’œil à la nouvelle carte :
    (ou c’est ici que ça se passe…)

    Voici l’implantation de RP1 :

    Il est aisé de constater que R4 à R7 sont reliées sur le connecteur 34 broches de l’ORIC, avec les Pins P2, P4, P6 et P8 :

    P2 pour ROMDIS, P4 pour RESET, P6 pour I/O CTRL, P8 pour IRQ

    Et R3 est reliée à P1 :

    P1 pour MAP

    C’est conforme au plan ! Ouf…
    Mais quid de R1 et de R2 ? Une fois la carte retournée :

    Ces résistances sont reliées à P5 et P7 :

    P5 pour I/O et P7 pour R/W

    Ah…
    Comparaison avec une carte mère originale d’ORIC (Issue 3) :

    R1 et R2 ne servent pas au fonctionnement et n’ont qu’un petit boulot décoratif !

    Question :
    Pourquoi avoir relié ainsi ces deux résistances sur la nouvelle carte ?
    Si l’on force les lignes R/W et I/O au niveau haut en permanence, cela va t’il jouer sur le fonctionnement ?
    Les Pros pourront répondre à cette “angoissante” question…
    Sur le Net, la majorité des montages à base de 6502 ne possèdent pas de résistances de tirage vers le haut sur ces lignes…

    Pour respecter le schéma de la carte originale, ces deux résistances seront omises… D’où l’utilité de remplacer le réseau de résistances RP1 par des résistances classiques…

    Pour les supports de CI, on peut aussi utiliser des barrettes sécables, moins chères :

    Les voici à la bonne taille et prêtes à l’emploi :

    Les résistances à plat sont déjà soudées

    Et après 382 points de soudures pour les supports…

    Le support de la deuxième EPROM (IC10) sera installé plus tard, car cela nécessite quelques petits travaux au préalable qui permettront la sélection d’une EPROM ou l’autre…

    Pour les condensateurs, il est difficile de trouver les mêmes originaux. Ici la taille n’a rien à voir, il suffit de plier un peu les pattes pour avoir le même écartement.

    De même pour le Quartz de 12 MHz…

    Ne pas oublier de relier R26 à la masse : par exemple sur la patte de C10…

    Et de relier les deux pattes numéro 1 des 74LS257 :

    Pour RP1 (voir plus haut), voici la solution retenue :

    Ne pas traiter RP2 de la même façon.

    Même s’il lui ressemble, celui-ci n’est que la juxtaposition de quatre résistances de 220 Ohm dans le même emballage…

    On peut le remplacer donc par quatre résistances dites normales…

    Et on obtient :

    Et voici la carte un peu plus habillée…

    Comme il n’y a pas de connecteur d’alimentation ni de 7905, il va falloir créer deux points d’alimentation temporaires qui fourniront du 5 Volt pour les tests. Le choix peut se porter sur l’emplacement de C9, un condensateur de découplage de 47 nF situé au dessus de IC24 :

    Pour bénéficier du filtrage de C8, il faudra temporairement le relier à la masse de la carte :

    Ainsi, la carte sera prête pour les premiers essais en réel !
    Aussitôt dit, aussitôt fait…

    Alors, il est grand temps de tester la tension sur la carte :

    OK !

    Mise en place d’un 74LS04 (ici, un 74HC04) pour test de la fréquence :

    Mise sous tension et test de la fréquence sur la patte 7 de l’ULA (qui devrait recevoir du 12 MHz) :

    Encore OK !

    En attendant (Sœur Anne, ne vois-tu rien venir ?) la livraison des connecteurs DIN pas en stock, il suffit de relier des fils temporaires sur les résistances de 220 Ohm en sortie du 74LS365 :

    Reg Green Blue, Yellow as Synchro, Black as Ground

    Puis enfin, le premier test de boot après avoir installé les circuits et un fil de jonction sur les deux pastilles reférencées LK, on obtient :

    Premier boot réussi !

    Manquent encore le clavier, le son et la gestion Cassette…
    A suivre !

    A+

  • PRINT@ et PLOT en mode HIRES

    par André C.

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

    Etat des lieux

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

    Pour la petite anecdote

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

    Revenons à nos moutons

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

    Positionner le curseur sur une ligne Y

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

    Positionner le curseur sur une colonne X

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

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

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

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

    En conclusion

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

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

  • Manuel développeur du telestrat

  • Averno

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

    Informations générales

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

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

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

    Ecran titre de la version 2019 sur Oric

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Quelques informations à propos du programme

    Le programme est divisé en 10 blocs:

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

    L’ensemble du programme occupe 137 lignes.

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

    Le jeu

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

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

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

    Contrôles :

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

    Une version française modifiée

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

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