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.
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
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.
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 !
En
mode HIRES, pour afficher quelque chose qui bouge rapidement (cas des jeux
d’arcade), il faut obligatoirement passer au langage machine.
La
commande Basic CHAR est trop lente pour faire évoluer des sprites basés sur des
caractères redéfinis. Or les astuces développées pour stocker, afficher et
déplacer des objets en mode HIRES restent mystérieuses tant qu’on ne procède
pas à un “reverse engineering”.
Et c’est un gros boulot !
Oui, mais il n’est pas sûr que l’on soit obligé d’en arriver là. Notre propos n’est pas de comprendre comment marche le programme, mais seulement de récupérer le dessin des sprites et les data nécessaires à leur affichage.
Lors
de la sortie de Xenon-1, je me souviens avoir été fasciné par la beauté et la
rapidité des sprites, lesquels sont animés qui plus est ! Je ne peux pas
faire autrement que de choisir cet exemple pour illustrer mon propos sur la
récupération des sprites.
Un écran HIRES est composé de 200 lignes de 40 octets. Ces 8000 octets sont, soit des attributs, soit des octets compris entre #40 et #7F. Dans ce dernier cas, chaque octet représente un “tiret” composé de 6 pixels. Récupérer les data d’un sprite, c’est récupérer les octets correspondant à tous les tirets qui le composent et si le sprite est multicolore, la valeur et la position des attributs utilisés. En outre, si le sprite est animé, il faut récupérer toutes les images du sprite.
Je vous propose deux méthodes :
Faire simultanément un dump de la mémoire et une
recopie d’écran (enfin, aussi simultanément que possible). Avec un éditeur
hexadécimal, comparer les octets de la zone écran HIRES avec les objets
présents sur la recopie d’écran. Récupérer tout simplement ces octets, qui
constituent les data de définition des sprites.
Faire une recopie d’écran. Agrandir le fichier
.bmp ou .png jusqu’au niveau du pixel avec un bon logiciel de traitement
d’image. Isoler le sprite intéressant et le numériser manuellement. La bonne
vieille méthode quoi ! Faisable mais ch…, heu… fastidieux ! Si vous
avez beaucoup de sprites à traiter vous pouvez aussi utiliser une feuille de
calculs pour simplifier la numérisation.
La première méthode en pratique
Les paresseux sont des gens qui cherchent à s’éviter du
travail. C’est en cherchant à échapper à la phase de numérisation des tirets
que j’ai eu l’idée de la méthode 1, dérivée de celle que j’ai utilisée
précédemment pour les écrans TEXT.
Autant vous avouer tout de suite, que ma paresse n’a
pas été récompensée ! Certes cette méthode marche, mais au final, c’est
très compliqué. Vous pouvez donc passer directement à la seconde méthode, sauf
si vous avez la fantaisie et le temps d’être curieux !
Procédure dans Euphoric :
Lancez Xenon1.tap avec Euphoric en configuration Atmos (vous trouverez la version Simon G. de ce tap dans le zip qui accompagne cet article, ainsi que sur le site oric.org).
Allez à l’écran qui vous intéresse, le premier par exemple.
Pressez aussi rapidement que possible les touches F9 (dump de la mémoire) puis F12 (recopie de l’écran).
Pressez F11 (débogueur) pour figer le jeu et gardez la fenêtre en réserve en vue d’un autre essai (il s’agit de sprites animés et il y a plusieurs images à récupérer pour chacun).
Renommez le fichier DUMP qui a été généré par exemple en DumpX1-01.bin
Ouvrez DumpX1-01.bin et réglez l’affichage pour
avoir 40 octets en largeur.
Allez à l’adresse #A000 (début de l’écran
HIRES). Chaque ligne de l’éditeur correspond à une ligne HIRES.
Dans la partie gauche de l’éditeur se trouvent
les octets présents dans l’écran. Chacun représente, soit un attribut, soit un
tiret de 6 pixels, selon que son bit 6 est à zéro (attribut) ou à un (tiret).
Dans ce dernier cas, les 6 bits les plus faibles représentent les pixels. Par
exemple les octets #40 (les plus nombreux et de loin) soit 01000000 en binaire,
correspondent à un espace ou plutôt à un tiret dont les 6 pixels sont de la
couleur du fond, donc invisibles (par défaut en HIRES, le fond est noir et
l’encre blanche).
Dans la partie droite de l’éditeur, sont
affichés les caractères Ascii correspondants. Le foisonnement de @ qui
correspond aux nombreux octets #40 saute aux yeux. On peut voir aussi soit des
points (les attributs), soit des caractères. Ces caractères n’ont rien à voir
avec des caractères dans l’écran. C’est seulement que l’éditeur hexadécimal
considère chaque octet comme un code Ascii et affiche le caractère
correspondant.
Contrairement à ce qui se passait avec l’écran texte,
il n’est pas possible de visualiser tout l’écran HIRES d’un seul coup. En
effet, alors que l’écran TEXT compte 28 lignes, l’écran HIRES en compte 200. Il
faut donc faire défiler l’affichage de l’éditeur verticalement pour comparer
les octets et caractères associés avec ce qu’on voit sur la recopie d’écran.
Comparaison des octets dans la Ram et de l’écran
La figure ci-dessus, montre une telle tranche d’écran, et permet de comparer les octets (à gauche), le caractère Ascii correspondant (à droite) et la portion d’écran HIRES correspondante en dessous. Les caractères correspondant aux tirets des sprites sautent aux yeux au milieu de la forêt des caractères @. Il “suffit” de noter (ou faire un collé/copié) des octets proprement dits (partie gauche de l’éditeur) pour avoir les data définissant chaque sprite. Enfin, c’était sans compter que les sprites se déplacent de façon très fluide (sur la figure ci-dessous, l’oiseau glisse, de un pixel à la fois, de gauche à droite dans l’écran). L’affichage d’un sprite coïncide rarement avec les octets (sinon les déplacements seraient saccadés de 6 pixels en 6 pixels).
Le sprite glisse de gauche à droite dans l’écran Hires, de un pixel à la fois
Dans le cas de cet écran Xenon1, les sprites font 18 pixels
de large sur 18 pixels de haut. En théorie, il faut donc 3 tirets de 6 pixels
pour afficher un sprite dans le sens de la largeur. En pratique, le programme
en langage machine se charge de faire glisser le sprite dans une fenêtre de 4
tirets de large.
Par exemple, la première ligne du sprite situé en haut à gauche de l’écran (ligne qui inclut le haut des deux cornes) peut être définie par les pixels suivant (0=pixel éteint, 1=pixel visible) : 000000100001000000. Ce qui devrait correspondre aux 3 octets suivants (après avoir forcé le bit 6 à 1, drapeau indiquant qu’il ne s’agit pas d’un attribut) : #40, #61 et #40. Or on observe sur la figure que 4 octets sont impliqués : #40, #42, #44 et #40, ce qui, en ne conservant que les bits b0 à b5, correspond aux pixels suivants : 000000000010000100000000. On voit que l’affichage du sprite de 18 pixels de large a été effectué sur 24 pixels. Pour récupérer les valeurs significatives des 3 octets il faudrait redécouper les 24 pixels en 3 zone de 6 pixel et laisser tomber (dans ce cas précis) les 4 pixels de tête et les 2 pixels de queue. En pratique c’est bien trop compliqué, à moins d’être un expert des tableurs genre Excel ou Calc !
La seconde méthode en pratique
La figure ci-dessous montre l’un des sprites de Xenon1, très agrandi. J’ai laissé volontairement une bande supplémentaire de 4 pixels de large à gauche et une autre de 2 pixels à droite pour que vous puissiez restituer et visualiser ce que nous avions précédemment avec la méthode 1.
Résumons ce que l’on voit : On a un sprite de 18×18 pixels
(3 tirets de 6 pixels de large sur 18 lignes HIRES de haut) affiché dans une
zone de 24×18 pixels (4 tirets de 6 pixels de large sur 18 lignes HIRES).
Les lignes verticales blanches délimitent les octets
directement impliqués dans le dessin du sprite proprement dit. Chacune des 18
lignes HIRES doit donc être découpée en 3 tirets de 6 pixels de façon à
récupérer le dessin réel du sprite. La nouvelle séparation en 3 zones de 6
pixels de large est visualisée par les lignes pointillées.
Numérisation du dessin pour obtenir les octets définissant le sprite
Au total, il nous faut donc numériser 18 fois 3 tirets pour récupérer tous les data du sprite. La figure ci-dessus montre un exemple de numérisation. Il s’agit de la tête du sprite.
Le premier tiret par exemple (haut des cornes sur la tête)
correspond à 100001
en binaire soit #21, valeur à laquelle il faudra ajouter #40 pour mettre le bit
6 à un (drapeau pour reconnaître les tirets), soit #61 dans cet exemple. Et
ainsi de suite pour l’ensemble des 54 tirets du sprite.
Ceci représente un travail forcément important, mais moins
qu’il n’y parait, car il y a beaucoup de redondances (tirets identiques).
A vous de voir si vous voulez vous aider soit d’un tableur (vous mettrez des croix dans les cases et il calcule les valeurs finales à utiliser), soit d’un simple tableau des 64 combinaisons possibles donnant directement les valeurs à utiliser.
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 :
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).
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).
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 :
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.
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.
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.
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 :
Ouvrez le modèle d’en-tête correspondant, soit MODLHRS2.
CTRL+A puis CTRL+C pour copier les 23 octets du fichier.
Ouvrez un nouveau document. CTRL+V pour y coller
l’en-tête. Editez les 8 caractères “MODLHRS2” pour renommer votre
fichier .tap
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.
Allez dans le nouveau document, à la fin de
l’en-tête, CTRL+V, pour y coller l’écran.
Sauvegardez votre écran au format .tap par
exemple sous le nom ECRANxx.tap. C’est fait.
Bonjour à tous, C’est avec plein de nouvelles découvertes que nous refermons cette année 2019 oricienne ! Des démos, de nouveaux logiciels et toujours les astuces de programmation de Yann qui remplissent le mag et les fichiers zip du mois. L’année 2020 s’annonce bonne pour le CEO. Les réinscriptions, déjà nombreuses se poursuivent. Gageons que ces passionnés feront de nouvelles découvertes, à partager avec les lecteurs du mag et sur les forums. Bonnes fètes à tous et à bientot avec l’annonce de la date de la prochaine visu, qui, comme d’habitude nous permettra de passer un bon moment.
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.
Un idée simple, une programmation des plus légères. Et nous voilà à jouer sur un jeu très addictif.
Informations générales
En pensant à son prochain projet 1K pour le ZX-81, DanCresp ne le savait pas, mais ce jeu était en tête et de la recherche d’informations sur Internet. Il décida de créer une première version pour MSX. Les problèmes de temps et la facilité d’utilisation de MS-DOS EUPHORIC sur son ordinateur portable l’ont incité à l’adapter à l’ORIC, en vérifiant auparavant qu’il n’y avait pas de version connue.
Au bout de cinq jours, l’auteur a laissé cette version utilisable, quels que soient les niveaux et les blocs qui apparaissent dans la version d’origine, graphiquement sur la base de la version Spectrum.
Heureusement, l’émulateur EUPHORIC permet, en appuyant sur “F3”, de mapper le clavier ORIC avec les touches du PC, ce qui facilite beaucoup l’introduction du programme. De l’émulateur, il a généré le TAP et de «l’Oricutron» de Windows, il a généré le listing dans un fichier texte utilisé pour déboguer le code source.
La vérité est que Dan est très satisfait car le fonctionnement et la performance sont parfaits ; avec un très bon game design. Le système pour augmenter la difficulté a donné plus mal à la tête parce que le jeu devait être difficile mais réalisable. (NDLR : Dan est décidément un pro du game design)
Les petites choses de la version ORIC Comme toujours lors de la programmation dans l’ORIC, les graphismes ont dû être repensés car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice de 8×6. Étant donné que l’ORIC dispose d’un mode texte de 26 lignes et de 40 colonnes, la zone de jeu a les dimensions de la version Amiga 500 d’origine de 7 lignes x 10 colonnes au lieu de la version 7×9 de la version Spectrum.
Dan aurais aimé regarder plus avec la couleur de l’écran, mais le système “particulier” de l’ORIC ne m’a pas permis. Après consultation d’amis graphistes, c’était la meilleure solution. Très semblable à MSX … bleu et jaune.
Pour contrôler le curseur, le clavier est lu à l’aide d’un «PEEK 520» (NDLR : le fameux PEEK #208 si connu des développeurs), ce qui évite les problèmes de lettres majuscules / minuscules et vous garantit de toujours lire la dernière touche enfoncée, en accédant à la mémoire tampon du clavier.
Et pour le son, une fois encore, Dan a utilisé les effets prédéfinis de l’ORIC, démontrant ainsi une faiblesse dans ce domaine …
Et l’eau coule … La difficulté principale et presque unique du projet a été de faire circuler l’eau à travers le tuyau, et même si au début cela semblait une question assez complexe, après une promenade avec brain-storming inclus, j’ai trouvé une solution très simple et rapide .
Nous avons 7 types de blocs différents pour assembler notre circuit.
Chacun de ces 7 blocs utilise certains des 11 graphiques de tubes différents, numérotés de 97 à 104.
L’eau peut avoir 4 directions possibles, numérotées dans le sens des aiguilles d’une montre.
Nous chargeons la matrice «U $» avec les valeurs DATA des lignes 9600 et 9605. Chacune de ces valeurs contient quatre nombres. La position indique la direction dans laquelle l’eau entre et la valeur de cette position indique la nouvelle direction à prendre par l’eau. Si la valeur est 0, cela signifie que vous avez entré une adresse incorrecte et que le jeu se termine.
Par exemple, la valeur en U du segment de tuyau 3 (coude inférieur / gauche) est «4300». Ainsi, si l’eau entre, elle monte et entre en dessous (direction 1), elle change à gauche (direction 4). Si vous entrez, il avance vers la droite (direction 2), il passe en bas (direction 3). Mais si l’eau vient du haut ou de la gauche, la valeur est «0» et le jeu se termine.
Lors du démarrage d’un niveau, la position initiale du bloc de sortie est calculée et dans la variable “W”, nous stockons l’adresse de la mémoire vidéo VRAM où l’eau commencera à circuler et dans la variable “O” son adresse (1, 2, 3 ou 4).
Lorsque l’eau commence à circuler, nous examinons le graphique correspondant à cette conduite et prenons son code (entre 1 et 11). Sur la base du sens d’entrée de l’eau (1 à 4), nous calculons le changement de direction en fonction de la matrice enregistrée dans «U $» et nous mettons à jour la position dans la VRAM sur laquelle pointe la variable «W» en fonction des valeurs de la matrice «J». Cette matrice contient 4 valeurs: -40, 1, 40 et -1 et est ajoutée à «W» en fonction de la nouvelle adresse pour pointer sur la bonne adresse VRAM afin de calculer le morceau de tuyau suivant.
Ensuite, nous modifions le CHAR du tuyau pour qu’il corresponde à l’eau, au moyen d’un POKE. Si le graphique de la position indiquée par «W» ne correspond pas à celui d’un tuyau, avec ou sans eau, le jeu se termine. J’ai utilisé un POKE car il est plus rapide et plus facile à contrôler (je n’utilise qu’une variable) qu’en utilisant un PLOT et deux variables.
Tout cela, qui semble très compliqué, est résolu pendant le jeu avec 3 lignes de code, 170, 175 et 180. C’est aussi simple que cela.
Une fois le niveau terminé, le même processus est exécuté pour calculer la section construite correcte, avec une copie du code précédent et quelques modifications simples, aux lignes 205, 210 et 215.
Eh bien, rien de plus, je ne peux qu’espérer que cela vous plaise, et oeil… qui accroche le sien…
Je vous invite à l’essayer.
L’écran titre et toutes les touches du jeu !
Quelques éléments concernant le programme
Le programme est divisé en 9 blocs:
Déclaration de la matrice et début du jeu.
Boucle principale de développement.
Passer le niveau
Plusieurs routines.
Fin du jeu.
Présentation et début du jeu.
Préparez et montrez l’aire de jeu.
Charger UDG.
DATA avec les UDG du jeu et les valeurs de la matrice.
L’ensemble du programme occupe 91 lignes.
10 – Nous définissons les matrices du jeu.
30 – Aller au sous-programme redéfinit les caractères et définit les variables globales.
100 – Début de la boucle principale. Si le curseur est verrouillé, il passera à la ligne 160.
105 – Prenez la touche appuyée. Si aucune touche n’a été enfoncée, le nombre passe à 160.
115 – Bloc qui déplace le curseur en fonction de la touche appuyée.
135 – Si vous n’appuyez pas sur “Space”, passez à 160.
140 – Vérifiez si la case est occupée par un bloc spécial, sautez à 160 si c’est le cas.
145 – S’il est occupé par un tuyau, réglez le compteur «N» sur 10 et il nous bloquera.
150 – Bloc qui vérifie qu’aucune eau ne passe à travers le bloc.
155 – Placez le bloc à la position indiquée en mettant à jour le curseur et la ligne des blocs suivants.
160 – Réduit l’heure de l’indicateur “T”. S’il reste encore sauter à 185.
165 – Compteur contrôlant le débit d’eau dans les tuyaux. Si vous ne devez pas avancer, passez à 185.
170 – Bloc qui contrôle la progression de l’eau dans les tuyaux. Si vous ne pouvez pas, mettez “D = -9” pour interrompre la répétition.
175 – Réduit le compteur “D” et vérifie le type de tuyau dans lequel se trouve l’eau.
180 – Modifiez le graphique du tuyau et affectez l’adresse correspondante.
185 – S’il reste encore du temps dans le compteur «D» et que l’eau circule bien dans la canalisation, retournez à REPEAT de la ligne 100.
200 – Si “D = -9” saute à 1900 et met fin à la partie, sinon le niveau est dépassé.
205 – Bloc qui vient de remplir d’eau l’ensemble du circuit de tuyaux assemblé.
220 – Mettez à jour les points, augmentez le niveau et passez à 2100 pour monter un nouveau niveau.
1000 – Routine qui place un bloc dans une certaine position.
1100 – Routine qui sélectionne de manière aléatoire un nouveau bloc à quitter lors des prochaines exécutions.
1200 – Routine qui montre les cinq blocs suivants à partir.
1300 – Place le curseur dans la case sélectionnée.
1350 – Supprimer le curseur de la case sélectionnée.
1400 – Affiche le marqueur à 8 chiffres avec les points ou l’enregistrement.
1900 – Le jeu se termine, met à jour le tableau de bord et marque une pause avant de passer à la présentation.
2000 – Écran initial du jeu.
2065 – Une touche doit être enfoncée. S’il se situe entre “1” et “9”, il est pris comme niveau initial et le jeu commence.
2100 – Initialise les variables et détermine la difficulté du niveau.
2105 – Dessine l’aire de jeu.
2115 – Calcule les cinq prochains blocs qui vont sortir.
2120 – Initialise la position des différentes cases.
2130 – Calculez la position de la boîte initiale et enregistrez dans «W» l’adresse VRAM de la première position de l’eau.
2135 – Calculer et positionner le curseur.
2140 – À partir d’un certain niveau, les blocs avec la clé sont placés à 3 positions de la boîte initiale.
3000 – Sélection des couleurs, effacement de l’écran, masquage du curseur et masquage des «CAPS» supérieurs.
3005 – Lecture de données UDG.
3010 – Assemblez les matrices avec des bandes de caractères.
3020 – Lire les DONNÉES avec les directions de l’eau et leurs incréments.
3025 – Chargez un tableau avec des chaînes numérotées de «01» à 25» et utilisées par les marqueurs. C’est plus rapide comme ça.
9000 – DONNÉES avec graphiques UDG.
9500 – DATA avec les différents types de blocs.
9600 – DATA avec les directions de l’eau en fonction du type de tuyau.
9700 – DATA permet de modifier la valeur «W» lorsque vous pointez vers la VRAM.
Le jeu
Pipe Mania est un jeu vidéo de type “casse-tête” développé en 1989 par The Assembly Line pour Amiga. Plus tard, LucasFilm Games a créé des versions pour d’autres machines sous le nom de Pipe Dream.
Le pipe est confié à un plombier, Alfonzo, qui a pour objectif d’ajuster des tuyaux apparaissant au hasard dans une matrice contenant un robinet d’où sort de l’eau.
Vous devez savoir que deux marqueurs effectuent un compte à rebours:
“T”: indique le temps restant avant que l’eau commence à traverser les tuyaux.
“D”: indique le temps restant pour terminer le niveau. Chaque unité correspond à un bloc.
Mettre un bloc de tuyaux dans une boîte occupée nous bloquera quelques instants.
À partir de certains niveaux, des blocs avec une clé ou des segments de tuyau apparaissent et ne peuvent être occupés.
Sur l’écran de présentation, nous pouvons indiquer le niveau, entre 1 et 9, auquel commencer le jeu.
Cette version suit exactement les mêmes mécanismes, mais les phases de bonus et certains types de blocs ont été éliminés.
Contrôles: Contrôlez le curseur avec “Q” – “A” – “O” – “P” et appuyez sur “Espace” pour placer un segment de tuyaux.
Quelle est votre préférée : la version Oric ou Amiga ?
Pour être vraiment universelle, la “big-cartouche” doit aussi accepter de la RAM. Premier problème, trouver une puce de RAM de 64 koctets (512 kbits), compatible avec le circuit imprimé de François S. c’est à dire avec le brochage des EPROM de la famille 27xxx. Il existe de nombreux types de RAM et en ce qui nous concerne, nous avons besoin de RAM statique sans rafraîchissement, c’est à dire appartenant aux familles 43xxx ou 62xxx comme celles livrées par ORIC ou encore à la famille 55xxx qui est également compatible.
Revenons
en aux puces de 32 koctets de RAM. Il serait bien sûr possible de souder en
parallèle, broche à broche deux RAM 62256 ou 55256 ou 43256, comme c’est le cas
dans les cartouches RAM d’origine ORIC, mais, comme nous l’avons déjà indiqué à
plusieurs reprises, nous sommes opposés à cette stratégie qui rend très
difficile la maintenance (l’usage de deux supports de circuit intégré est
impossible pour cause d’encombrement excessif).
Comme
pour les EPROM, il serait intéressant d’utiliser des puces de 64 koctets à 28
broches. Mais hélas, il n’existe pas de 43512, 62512 ou 55512. Nous sommes donc
obligés d’utiliser des RAM de 128 koctets (c’est à dire 128 x 8 = 1024 kbits) à
32 broches de type 431000, 551001, 621000, 621001 ou 628128 selon le fabriquant.
Bien
sûr, nous n’avons besoin que la moitié de cette RAM, puisque pour faire 4
banques de 16 koctets il faut 64 koctets soit 64 x 8 = 512 kbits. Mais nous allons en
profiter pour faire une double cartouche: un interrupteur permettra de passer
d’une extension RAM 64K à l’autre (pour simplifier nous dirons d’une demi- RAM
à l’autre). C’est votre TELESTRAT qui va être content de récupérer 64K de plus!
Si vous êtes bricoleur, rien ne vous empêche de basculer
entre les deux demi-RAM à l’aide du signal PB5, comme nous l’avons fait avec la
ROM de I’ATMOS. Votre TELESTRAT disposera alors de 128 koctets de RAM,
accessibles par programmation. Mais pensez tout de même à vérifier si le soft
du TELESTRAT respecte PB5 (voir ce que nous avons fait pour I’ATMOS dans la rubrique
“SEDORIC? DO IT YOURSELF” n°20, CEO-MAG n°90 d’octobre 1997, pages 9
et 10).
Nous avons réussi à utiliser une TC551001-70 et une D431000ACZ-70 (32 broches, 128 koctets). Mais finalement, la 621001 (même brochage) semble plus courante et donc plus facile à trouver. La figure 15 vous montre les brochages comparatifs des 62256 (identiques aux 43256 utilisées en paire dans les cartouches RAM d’origine Oric), 621001 (que nous préconisons) et de l’EPROM 27C010 (pour mémoire, puisque c’est notre circuit de référence, celui pour lequel la carte et le support de la “big-cartouche” avaient été conçus).
Prenez quelques minutes pour comparer le brochage de la RAM 621001 à celui de l’EPROM 27010. Cinq broches seulement different:
La broche n°1: Rafraîchissement des données (ex mode programmation, devenu inutile!).
La broche n°29 devient WE au lieu de A14.
La broche n°3 devient A14 au lieu de A15.
La broche n°31 devient A15 au lieu de ROMDIS (également inutile!).
Et enfin la broche 30, qui était non connectée, reçoit une nouvelle fonction CE2.
Nous avons expliqué dans le Journal du Hard précédent, comment utiliser 8 diodes pour décoder les désirs du TELESTRAT et lui présenter la banque qu’il demande. Notre figure 12a reste valable du point de vue théorique. Seuls changent les noms des banques (1 à 4 au lieu de 4 à 7) et par conséquent des CS (CS0 à CS6 au lieu de CS0 à CS3) changent.
Passons donc directement à notre schéma mi-théorique mi-pratique. Ce type de représentation doit maintenant vous être familier. Au menu, comme précédemment, relier les broches du connecteur TELESTRAT à celle du circuit intégré, tout en assurant le décodage des lignes de contrôles CS3 à CS6 Pas de nouveauté en ce qui concerne la masse, les lignes A0 à A13 et les lignes de données. Peu de modifications pour le reste des connexions.
Les lignes
d’adressage A14, A15 et A16
Tout d’abord, A16 (qui “divise” la RAM en deux “demi-RAM”) est soit tirée au +5V à travers une résistance de 4,7 kohms, soit mise à la masse par un interrupteur. Si vous envisagez d’utiliser le signal PB5 de votre TELESTRAT pour basculer entre les deux demi-RAM, un simple fil devra relier cette ligne A16 à la broche n°15 du 6522 (voir le Journal du Hard n°9).
L’emplacement des lignes A14 et A15 est différent entre les EPROM et les RAM (figure 15). Mais en fait, comme nous l’avons expliqué à plusieurs reprises, le TELESTRAT n’utilise que les lignes d’adressage AO à A13 (pour lire et écrire dans l’espace d’une seule banque à la fois soit 16 koctets). Les deux lignes d’adressage A14 et A15 permettent de “diviser” la demi-RAM en 4 banques de 16 koctets. Le niveau de ces lignes A14 et A15 est manipulé à l’intérieur de la cartouche en fonction de l’état des lignes de commandes pilotées par le TELESTRAT. Le fait qu’elles aient changé de place n’est pas très grave et ne demandera en pratique qu’un peu d’adaptation.
En effet, s’il était impératif de
respecter un certain ordre des banques à l’intérieur de EPROM, ce n’est plus
nécessaire dans le cas présent : les banques peuvent être placées dans le
désordre à l’intérieur de la RAM. Cela tombe bien, car nous allons devoir
adapter le circuit imprimé de François S (conçu pour le brochage des 27xxx) à
un brochage légèrement différent (celui des 62xxx, 43xxx et 55xxx). Notre seul
souci sera donc de faire en sorte que cette adaptation soit la plus simple
possible.
Le choix entre les 4 banques est contrôlé par les signaux CS3, CS4, CS5 et CS6 (voir le deuxième tableau du Journal du Hard n°15). La banque n°1 est opérationnelle lorsque CS6 est tiré à la masse, la n°2 lorsque c’est CS5, la n°3 quand c’est CS4 et enfin la banque n°4 est sélectionnée si est au niveau bas. Voyons cela concrètement.
Au repos, les broches A14 et A15 sont tirées au niveau haut par une résistance de 4,7 kohms. C’est le quart le plus haut de la demi-RAM qui est “sélectionné”, mais en fait, il n’est pas en ligne car le Chip Enable n’est pas validé. Suivez sur la figure 16. La broche CE1 est maintenue au niveau haut (puce non sélectionnée) par une résistance de 4,7 kohms.
Lorsque l’un des 4 signaux CS3, CS4, CS5 ou CS6 est mis à la masse par le TELESTRAT, la diode correspondante, c’est à dire l’une des diodes du premier groupe (n°l à 4), devient conductrice et tire la broche CE1 au niveau bas, ce qui valide la puce (oui, toute la puce, mais seule une demi-RAM est “sélectionnée” par action de l’inter sur A16). Ce niveau bas de CE1 ne se répercute pas sur les autres lignes, car les 3 autres diodes de ce premier groupe ne peuvent conduire à contre sens.
Lorsque la ligne de commande CS6 est mise à la masse par le TELESTRAT, A15 est alors tirée au niveau bas, grâce à la diode n°8 qui devient conductrice.
Si CS5 est mise à la masse, alors A14 est tirée au niveau bas, grâce à la diode n°6.
Mais quand la ligne CS4 est mise à la masse, les deux lignes A14 et A15 sont misent ensemble au niveau bas (diodes 5 et 7).
Vous pouvez vérifier que CS3 se contente de valider la puce et donc que la banque correspondante (n°4) se trouvera tout en haut de la demi-RAM (A15 haut et A14 haut). La banque n°2 viendra ensuite (A15 haut et A14 bas) puis la banque n°1 (A15 bas et A14 haut) et enfin la banque 3 (A15 bas et A14 bas).
Enfin, une nouvelle broche WE (Write Enable, validation de la RAM en écriture) fait son apparition par rapport aux EPROM. Le circuit imprimé n’avait pas été prévu pour et là encore, il faudra effectuer une petite adaptation. Cette broche WE est directement pilotée par le TELESTRAT, qui la met au niveau bas lorsqu’il veut écrire dans la RAM.
Puisque vous n’aurez qu’une seule cartouche RAM à construire, inutile de modifier le tracé du circuit imprimé de la big-cartouche pour ce nouveau brochage. Il suffira de couper 3 pistes et d’ajouter quelques straps, pour adapter le circuit originel de François S .Vous devrez donc distinguer deux types de “big-cartouche”: celles pour EPROM et celles pour RAM
Finalement, la figure 17 révèle l’implantation d’une 621001 sur le circuit imprimé de la “big-cartouche”. Les modifications à faire sont minimes, mais le nombre de composants est assez élevé: un interrupteur (d’aussi petite taille que possible), une capacité de 100nF, 4 résistances de 4,7 kohms, 8 diodes de type 1N4148 (ou une des nombreuses diodes équivalentes, mais de petite taille si possible), un support de circuit intégré à 32 broches, une RAM 621001, 431000, 551001, 621000 ou 628128 et l’outillage de base habituel
Effectuez
les 3 coupures en premier, puis construisez votre cartouche en suivant ligne
après ligne le schéma de la figure 16. C’est le seul moyen de minimiser les
erreurs. Rappelons en effet un point crucial Selon toute vraisemblance, sauf si
vous êtes un professionnel, les traversées de votre carte n’ont pas été
métallisées La continuité électrique doit donc être assurée en plaçant une
cosse (ou un simple bout de fil) dans les trous correspondant à chacune de ces
traversées et à souder cette cosse sur les pistes des deux cotés de la carte.
D’où la nécessité de suivre le schéma de principe! Il faudra tout réviser dans
le détail avant de procéder aux essais.
Nous avons perdu beaucoup de temps faute d’avoir effectué
les bons essais. Ne faites pas comme nous. En effet, qui dit extension RAM, dit
RAM-DISK et c’est bien tentant de se contenter de créer un disque virtuel D,
puis d’écrire quelques fichiers dessus et de faire un DIR. C’est bien, mais ce
n’est pas suffisant Bootez plutôt votre TELESTRAT avec une cartouche TELE-ASS à
gauche et votre big-RAM à droite. Et procédez aux essais suivants:
Choisissez
l’option TELE-ASS.
Tapez
BANK1 puis MODIF #C000 puis CTRL/A puis le message “Ceci est la banque
1” (ou ce que vous voudrez) puis ESC (tout ceci pour écrire un message
identifiant la banque 1).
Procédez
de même avec les trois autres banques: BANK2 … “Ceci est la banque 2”
etc…
Retapez
tour à tour BANK1, BANK2, BANK3 et BANK4, suivi d’un DUMP #C000 et vous devez
retrouver vos 4 messages au bon endroit. Si ce n’est pas le cas, re-vérifiez
votre cartouche, il doit y avoir une diode soudée au mauvais endroit. Un peu de
réflexion devra alors vous guider.
Et pour commencer, un petit ERRATUM. Le troisième schéma (Cartouche de type 3 banques) de la figure 4, du Journal du Hard n°16 comporte une erreur. En effet, la résistance 4,7 Kohms ne doit pas être reliée à la broche 27 (A14), mais à la broche 28 (+TV). Les lecteurs attentif on réctifié d’eux-mêmes, d’autant que les schémas situés de part et d’autre montraient eux, la bonne connexion !
L’EXTENSION RAM 64K Version 1.0 pour ORIC TELESTRAT
Cette extension RAM fut une bien belle invention permettant de faire cohabiter les DOS et les applications sur le port gauche et 4 banques de 16Koctets de RAM sur le port droit. La mention “version 1.0” rappelle que cette cartouche RAM était livrée, non seulement avec une notice de 12 pages, mais aussi avec une disquette contenant des programmes pour exploiter cette extension mémoire.
Par exemple, INSTAL.COM permet d’installer un disque virtuel occupant toute la RAM (en théorie 64koctets soit 256 secteurs mais en pratique seulement 248 secteurs car la gestion de ce disque virtuel consomme un peu de mémoire). INSTALTEL.COM permet d’installer la banque TELEMATIC en RAM. En effet, la cartouche RAM prend la place de la cartouche TELEMATIC dans le port droit. La mémoire utilisée pour la banque TELEMATIC est prise sur le disque virtuel dont la capacité diminue de 32 secteurs (8 koctets).
D’autres utilitaires ou informations, permettent de gérer cette extension RAM à partir du Langage Machine ou à partir du langage FORTH (accès direct aux banques de mémoire dans les deux cas). Enfin, des programmes supplémentaires permettent de gérer le disque virtuel (par exemple pour pouvoir utiliser la commande COPY dans ce contexte spécial) et une fonction de récupération de disque virtuel après un reset (mais pas une extenction).
Quel luxe de disposer de mémoire supplémentaire : le TELESTRAT affiche bravement 128 koctets de RAM ! L’extension RAM autorise aussi l’utilisation d’un disque virtuel beaucoup plus véloce qu’un disque réel : pour lire 100 fiches de 100 caractères, le RAM-DISK met 6s au lieu de 80s pour le lecteur de disquette !
Comment est faite la cartouche ?
Elle utilise le même circuit imprimé que les cartouches d’EPROM et est équipée de deux circuits intégrés de type 43256 ou 62256 soudés en parallèle, broche à broche, comme dans le cas des cartouches à 3 banques (STRATORIC par exemple). Toutes les broches, sauf les broches 1 et 20 …
Comme dans le cas des EPROM, la broche 20 correspond à la fonction CE (Chip Enable, c’est à dire validation du circuit intégré). La broche 1 est l’homologue de la broche 27 des EPROM, c’est la ligne d’adressage A14, le principe pour piloter les 4 banques est identique à ce que nous avons décrit précédemment pour une cartouche à 4 banques. Et pour cause, puisque c’est une cartouche à 4 banques ! Seuls changent certaines numéros de broches du circuit intégré et du connecteur de cartouche (puisqu’il s’agit maintenant d’une cartouche pour port droit).
Voici donc une comparaison cartouche “64K EPROM” versus cartouche “64 K RAM”. Puisqu’il faut pouvoir booter, l’eprom est évidemment destinée au port gauche et la RAM ne peut être présente que sur le port droit.
L’interconnexion de la puce et du connecteur est réalisée par le même circuit imprimé, qui n’a subit que de légères modifications dont le principe est donné à la figure 7. La réalisation pratique est faite avec des fils “volants” et une piste coupée I Le condensateur de lOOnF était absent sur la cartouche de RAM que nous avons autopsiée et c’est un tort. Par contre un fil fin relié à la masse a été ajouté, qui court le long du “ventre” de la RAM B et qui sert de blindage protégeant contre les champs électromagnétiques générés par la carte mère. C’est un peu rustique et il serait possible de faire mieux, par exemple avec une feuille métallique.
RÉALISATION PRATIQUE
Trois cas de figure : a) Vous partez de rien et alors nous vous conseillons plutôt d’attendre un de nos prochains articles qui décrira la “big-cartouche” de François S Cette “big-cartouche” représente vraiment la solution idéale b) Vous avez une cartouche RAM grillée. Il vous faudra remplacer les 2 puces en employant la manière forte que nous avons décrite précédemment (à base de pince coupante et de mine de mini-critérium). Si ce genre d’opération vous térrifie, appeler-nous à votre secours. c) Vous voulez ré-utiliser une cartouche grillée de type EPROM. Vous aurez à la transformer en cartouche RAM Cette opération n’est pas difficile, mais il faut avoir un peu de pratique de l’électronique II vous faudra remplacer l’EPROM (ou les EPROM) par deux RAM 43256 ou 62256 (pour la procédure d’ “extraction” des puces voir notre article précédent). Puisque l’étendue des travaux à effectuer dépend du type de cartouche dont vous partez (cartouche à 1,2, 3 ou 4 banques), nous nous contenterons de lister les connections dont il faut vérifier l’existence et qu’il faut éventuellement effectuer si elles ne sont pas présentes (suivez sur la figure 7, sinon vous ne comprendrez rien) : 1 ) Liaison de la broche B2 (CS4) du connecteur de la cartouche à la broche 20 (CE) de la RAM A par l’intermédiaire d’une diode 1N4148 (située à l’emplacement marqué “D2” sur le circuit imprimé) 2) Liaison de la broche A1 (CS5) du connecteur de la cartouche à la broche 20 (CE) de la RAM A par l’intermédiaire d’une diode 1N4148 (située à l’emplacement marqué “D1” sur le circuit imprimé) En outre, la broche A1 (CS5) sera également reliée directement à la broche 1 (A14) de la RAM A (faire tout simplement un petit pont de soudure entre la piste concernée et la broche 1). 3) Liaison broche A2 (CS6) du connecteur à la broche 20 (CE) de la RAM B par l’intermédiaire d’une diode 1N4148 (en “volant” : une patte de la diode est soudée sur A2, l’autre est prolongée par un fil “F” qui passe coté composants au travers d’un des nombreux oeillets de la carte, avant d’être soudé sur la broche 20 de la RAM B) 4) Liaison broche A3 (CS3) du connecteur à la broche 20 (CE) de la RAM B par l’intermédiaire d’une diode 1N4148 (également en “volant”. une patte de la diode est soudée sur A3, l’autre est soudée au fil “F” ci- dessus En outre, la broche A3 (CS3) sera également reliée directement à la broche 1 (A14) de la RAM B (fil “volant”). 5) Liaison directe de la broche B3 (WE) du connecteur aux broches 27 (WE) des deux RAM (fil “volant” direct). 6) La broche 20 (CE) de la RAM A sera également tirée au +5V par une résistance de 4,7 kohms (située à l’emplacement marqué “R1” sur le circuit imprimé) 7) De même la broche 20 (CE) de la RAM B sera tirée au +5V par une résistance de 4,7 kohms (soudée directement entre les broches 20 et 28 de la RAM B). 8) Un condensateur de 100 nF doit être présent à remplacement marqué “C1” sur le circuit imprimé 9) Un blindage (un simple fil semble suffire !) sera connecté à la masse (par exemple en partant du pied de “C1” le plus proche des connecteurs de la cartouche) et installé sur le “ventre” de la RAM B (un peu de colle permet de le maintenir en place sur la puce). 10) La piste du circuit imprimé qui connectait les broches 1 des deux puces au +5V sera interrompue (un petit coup de meule ou de cutter à l’emplacement indiqué dans la figure 5 de notre article précédent). Voilà, cela fait un peu bricolage, mais c’est exactement ce qui sortait de l’usine Oric ! Comme il y a longtemps qu’on n’en trouve plus sur le marché, il faut bien se charger soit même de la modification. Notez qu’il vous faudra souder les RAM, car il est impossible de placer un support de circuit intégré des deux cotés du circuit imprimé (encombrement rédhibitoire). Vérifiez aussi que votre cartouche RAM a bien le détrompeur pour port droit. Il existe malgré tout quelques cartouches d’origine Oric qui furent correctement construites, c’est à dire avec un seul détrompeur ! Si ce n’est pas le bon, il vous faudra effectuer un trait de scie à l’emplacement de la piste 14 (mini-meule ou à la rigueur scie à métaux) pour pouvoir insérer votre cartouche RAM dans le port droit. Pour tester et utiliser votre cartouche, vous aurez besoin de la disquette “EXTENSION RAM64K” ou de la cartouche TELE-ASS pour port gauche Si vous n’êtes pas un as de la programmation, n’hésitez pas à nous appeler au secours
