WordPress

Tag: ceomag357

  • CEO-MAG 357

    Sommaire :

    Edito Janvier 2020.

    Au nom du Comité, des rédacteurs du CEO-MAG, je vous souhaite une bonne année 2020, pour vous et vos proches.

    La souscription au CEO lancée et suivie avec brio par René, notre trésorier adjoint est un franc succès. A ce jour, c’est 55 adhérents, Oriciens actifs qui ont renouvelé leur adhésion et marqué leur intèrêt dans les services proposés par l’association ; dont j’en rappelle quelques uns : visu ouverte à tous et l’occasion de faire réparer du matériel, le mythique magazine CEO-MAG, la distribution de logiciels estampillés CEO (même si avec internet, nous sommes tous facilement des auto-éditeurs), l’accès à des archives sur le site oric.org et dans sa section CEO-MAG qui dispose également d’un forum avec une partie privée et une partie publique. Les bases sont lancées.

    Parmi les 55 adhérents, il y a 4 nouveaux adhérents pour 2020 dont certains sont très actifs et tentent de nouvelles expériences sur notre machine favorite. Bienvenue à vous. Le dernier «trombinoscope» remontait à 2015. Une version à jour sera proposée dans un prochain mag, ainsi que quelques infos sur le contenu et le fonctionnement du site oric.bqtt.net/ monté par Jérome. J’espère que cela motivera les adhérents n’ayant pas encore créé leur profil sur le site à le faire, pour réagir en ligne aux articles proposés. Ce premier numéro est plein de découvertes proposées par nos rédacteurs les plus prolixes et Dominique nous a concocté un nouvel article pour les amoureux du fer à souder.

    Bonne lecture et rendez-vous le 1/2 à Paris.

    [wpdm_package id=’1919′]

    [wpdm_package id=’2586′]

  • 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 écrans des logiciels protégés : 1 – Méthode

    par André C.

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

    Constatation

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

    Un florilège de protections

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

    Bilan des transferts au format .tap ou .dsk

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

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

    Ecrans versus recopie d’écrans

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

    Exploration de la Ram

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

    Les divers types d’écrans

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

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

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

    Fabriquez les en-têtes appropriés

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

    100 HIRES

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

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

    130 TEXT

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

    150 PING

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

    Récupérez les DUMPs

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

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

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

    Et enfin, récupérez les écrans

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

    Dans votre éditeur hexadécimal :

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

    A suivre…

  • 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
    • 1= CARTE 6502+ROM
    • 2= CARTE VIA6522

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

    • 3= CARTE ULA
    • 4= CARTE RAM

    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

  • Retour sur la mise en œuvre du PSG AY3-8912

    par Andre C.

    Dans certaines de mes expérimentations musicales récentes (par exemple MereMichel2, qui utilise la commande SOUND), j’ai été amené à ajouter un CALL#C4B7 en fin de programme. Il s’agit d’une sorte de pseudo END qui permet de sortir du programme en évitant le “Ready” et surtout le parasite sonore qui l’accompagne (une sorte de “PEUP”). Impossible de trouver la cause de ce parasite.

    En cherchant autre chose, je suis tombé sur la citation suivante : “Le fait crucial suivant ne figure dans aucun manuel : Au boot et lors de chaque retour à l’interpréteur BASIC, le canal 1 est validé (mais ni le 2, ni le 3, ni le bruit). C’est comme si un PLAY 1,0,0,0 était exécuté. Ceci explique pourquoi les essais que l’on peut faire sur le canal 1 ne marchent pas toujours lors de leur mise en application ultérieure. Par exemple au “Ready”, un MUSIC 2,3,10,9 ne produit rien, alors que MUSIC 1,3,10,9 produit bien un LA de l’octave 3. Si le bit 3 de #26A est à zéro (bruit clavier actif) alors PLAY 1,0,0,0 est envoyé à chaque “Ready”. Si le bit 3 est à un (clavier muet) alors c’est le dernier PLAY qui reste valide (comme en mode programme) tant qu’on n’envoie pas un nouveau PLAY ou qu’on ne coupe pas l’alimentation électrique du PSG.“

    Ceci se trouve dans l’article “PLAY, MUSIC, SOUND, une mise au point effectuée par André C., Dominique P. et Claude S.” (CEO-mag n°119, pages 25-39). En fait, Dominique est le père de cette observation étonnante, ce qui explique peut-être que je ne l’avais pas gardée en mémoire.

    “Le fait crucial suivant ne figure dans aucun manuel : Au boot et lors de chaque retour à l’interpréteur BASIC, le canal 1 est validé (mais ni le 2, ni le 3, ni le bruit). C’est comme si un PLAY 1,0,0,0 était exécuté. Ceci explique pourquoi les essais que l’on peut faire sur le canal 1 ne marchent pas toujours lors de leur mise en application ultérieure. Par exemple au “Ready”, un MUSIC 2,3,10,9 ne produit rien, alors que MUSIC 1,3,10,9 produit bien un LA de l’octave 3. Si le bit 3 de #26A est à zéro (bruit clavier actif) alors PLAY 1,0,0,0 est envoyé à chaque “Ready”. Si le bit 3 est à un (clavier muet) alors c’est le dernier PLAY qui reste valide (comme en mode programme) tant qu’on n’envoie pas un nouveau PLAY ou qu’on ne coupe pas l’alimentation électrique du PSG.“
    Ceci se trouve dans l’article “PLAY, MUSIC, SOUND, une mise au point effectuée par André C., Dominique P. et Claude S.” (CEO-mag n°119, pages 25-39). En fait, Dominique est le père de cette observation étonnante, ce qui explique peut-être que je ne l’avais pas gardée en mémoire.


    Comme ce phénomène me chiffonnait toujours, j’ai effectué quelques recherches. Voici les observations que j’ai pu faire :
    1) Les sons parasites produits dépendent de la configuration. On peut bien sûr les entendre avec un Atmos seul (configuration 1), mais ils sont plus importants dans la configuration Atmos+Microdisc+Sedoric (configuration 2). Ainsi, dans la configuration 2, si l’on remplace le CALL#C4B7 final par un END, le programme modifié produit un “PEUP” en rendant la main. Par contre avec la configuration 1, le même programme modifié de la même manière rend la main sans produire de parasite sonore. Curieux non?
    2) Les sons parasites produits dépendent des commandes utilisées. Par exemple, les deux programmes MereMichel1 et MereMichel2 sont quasi identiques et produisent les mêmes sons, sauf que le premier utilise la commande MUSIC et reste silencieux après le retour au “Ready” (configuration 2), alors que le second utilise la commande SOUND et nécessite l’ajout du fameux CALL#C4B7 pour bloquer le disgracieux “PEUP”(toujours avec la configuration 2).
    3) La manière dont on termine le programme joue aussi. Curieusement, ajouter une commande END en fin de programme est souvent toxique. Si nécessaire, mieux vaut sortir avec un CALL#C4B7 ou alors effectuer un reset des registres du PSG (voir plus loin la routine RSETPSG).
    4) Si on utilise un Oric réél ou un émulateur.
    Je ne suis pas allé plus loin dans la recherche des causes du phénomène, découragé par l’hétérogénéité des conditions dans lesquelles il se produit.
    Mais le problème vient sans doute en grande partie du fait que les 14 registres du PSG sont latchés (verrouillés), ce qui veut dire que la valeur qu’on y écrit y reste jusqu’à ce qu’on en écrive une autre ou que l’on coupe le courant.
    Selon la configuration, les commandes musicales utilisées et la manière dont on termine le programme, il est difficile de savoir ce qu’il y a dans ces 14 registres. Certes un PLAY 0,0,0,0 semble tout couper, mais en apparence seulement car seul le registre 7 est mis à jour, sans nettoyage des 13 autres registres. Ce registre 7 sert à valider les canaux actifs. Les bits 0, 1 et 2 contrôlent respectivement les canaux 1, 2 et 3 ; les bits 3, 4 et 5 mixent le bruit blanc aux canaux 1, 2 et 3. Attention, pour valider un canal, il faut mettre le bit correspondant à 0. Par conséquent la commande PLAY 0,0,0,0 envoie la valeur #3F (111111 en binaire) dans le registre 7 ce qui bloque toutes les sorties ! Je ne suis pas à l’origine de cette conception tordue et j’espère que vous avez suivi !
    Quand on revalide un canal (ou quand on retourne au “Ready”, ce qui revalide le canal 1), on peut alors entendre s’exprimer ce que le PSG a dans le ventre, même si ce n’est ni voulu, ni agréable !
    Je ne vois qu’une seule solution à ce problème : neutraliser tous les registres du PSG !

    Registre 0 et 1 : Tonalité canal 1 (de #00 à #0FFF) mettre à #0000
    Registre 2 et 3 : Tonalité canal 2 (de #00 à #0FFF) mettre à #0000
    Registre 4 et 5 : Tonalité canal 3 (de #00 à #0FFF) mettre à #0000
    Registre 6 : Tonalite bruit blanc (de 0 a $1F) mettre à #00
    Registre 7 : Contrôle des canaux en service (de #00 à #3F) mettre à #3F
    Registre 8 : Volume canal 1 (de #00 à #10) mettre à #00
    Registre 9 : Volume canal 2 (de #00 à #10) mettre à #00
    Registre 10 : Volume canal 3 (de #00 à #10) mettre à #00
    Registre 11 et 12 : Durée du son (de #00 à $FFFF) mettre à #0000
    Registre 13 : Forme de l’enveloppe (de #00 à #0F) mettre à #00

    Ceci peut se faire à l’aide de la petite routine en assembleur RSETPSG ci-dessous :

    ; Routine RSETPSG pour neutraliser les 14 registres du PSG AY3-8912
    ; Cette routine sera appelée par CALL STP (soit #980E si la routine est implantée en #9800)
    org $9800 ; Exemple d'adresse d'implantation de la routine
    DATA db $00, $00, $00, $00, $00, $00 ; Tonalite canaux A, B et C (de 0 a $0FFF)
    db $00 ; Tonalite bruit blanc (de 0 a $1F)
    db $3F ; Canaux C+br, B+br, A+br, C, B, A)
    db $00, $00, $00 ; Volume canaux A, B et (0 a $0F, -> enveloppe si $10)
    db $00, $00 ; Durée du son (de 0 a $FFFF)
    db $00 ; Forme de l'enveloppe (de 0 à 7)
    STP ldx #LOW DATA ; Adresse des 14 valeurs
    ldy #HIGH DATA ; à envoyer au PSG
    jmp $FA86 ; Routine en Rom "écrire dans les 14 registres du PSG"
    EOF


    Il est évidemment possible de POKEr les octets correspondants avec un programme Basic :

    100 FOR K=#9800 TO #9814:READ V:POKE K,V:NEXT
    200 DATA 0,0,0,0,0,0,0,#3F,0,0,0, 0,0,0,#A2,#00,#A0,#98,#4C,#86,#FA
    300 SAVE"RSETPSG",A#9800,E#9814

    La routine est relogeable si on assemble le programme source à une autre adresse ou si on met à jour manuellement les octets du LDX #00 (ici #A2,#00) et ceux du LDY#98 (ici #A0,#98) afin de cibler la nouvelle adresse d’implantation.
    La différence entre ces 2 CALL est que le CALL#C4B7 (routine de la Rom) rend la main (sans afficher le “Ready”), alors que le CALL#980E (routine RSETPSG en Ram) permet de rester dans le programme et éventuellement d’en sortir plus proprement. Ces deux remèdes devraient résoudre vos éventuels problèmes. N’hésitez pas à faire connaître vos tribulations musicales…