Oric Explorer est un des meilleurs utilitaires permettant d’inspecter des disquettes (dsk) et cassettes (tap). Damien a revisité le logiciel et ajouté quelques fonctions.
Bonjour à tous, L’année 2020 nous a vraiment réservé bien des surprises et ce numéro vise à garder dans une version papier les excellentes présentations réalisées lors des visu meet de Juin et Septembre. L’année a été assez riche en nouveautés hardware, software et j’ai reçu quelques artciles réalisés par nos plus fidèles rédacteurs. Je les en remercie, et ceux ci sont déjà disponibles sur le site du CEO. On ne peut pas dire qu’il y ait foule sur les ceo meet mais avec le mag, les forums et les visu physiques, c’est un levier supplémentaire pour échanger à propos de notre ordinateur favori, l’Oric. Une nouvelle visu meet est d’ors et déjà prévue début décembre. Reservez vos créneaux et attention … Google ayant restreint le temps d’utilisation du service à une heure, nous n’attendrons pas les retardataires. Bonne lecture et à bientot. Un nouveau numéro paraitra en fin d’année, l’occasion de boucler cette année 2020 coté Oric, et intègrera les différents articles réalisés et disponibles sur le site. Prenez soin de vous
Une nouvelle visu meet s’est tenue le Vendredi 11 Septembre à 21h00. Elle s’est déroulée, comme pour la visu meet de Juin, sous la forme d’un google meet programmé le 11 Septembre de 21h00 à 22h30
Un bon moment de détente pour tous les Oriciens passionés. En direct live, avec réalisation de quelques démonstrations qui ont donné lieu à des échanges ouverts.
Agenda :
Fabrizio : Crosslib, a massively cross-development library
Kenneth : DIY, un simple cordon d’adaptation pour joystick
Damien et Didier : Présentation d’Oric Explorer
Echanges
Le compte rendu de la visu est disponible sur Youtube.
1h30 de vidéo, le livre presque intégral de la session ceo meet autumn 2020
Echanges possibles sur le forum (réservé aux adhérents du CEO)
Pour les chanceux qui possèdent un ordinateur Oric, une solution permet de résoudre le problème d’absence de connecteur DB9 sur Oric qui gâche le plaisir de profiter de jeux plus réalistes avec une manette comme le proposaient d’autres fabricants d’ordis ou de consoles de l’époque. Maintenant, ce petit cordon permet d’adapter un joystick de type Atari ou Amstrad CPC sur un ordinateur Oric-1/Atmos.
“Stingy” adaptateur joystick pour Oric
L’adaptateur possède les avantages suivants :
Pas de circuits intégrés : On utilise des diodes.
Pas de circuit imprimé : Les composants sont dans la coquille de la prise DB9.
Pas de déformation du son pour les jeux prévus avec l’interface IJK.
Compatible avec la manette au standard CPC Amstrad : Le 2e bouton de tir est différencié du 1er, il n’y a pas encore de jeux pour, mais on peut détecter le 2e bouton.
Pour réaliser l’adaptateur il faudra vous procurer :
7 diodes de type 1N4148.
1 connecteur DB9 mâle à souder vers fils avec sa coquille.
1 nappe 20 fils avec son connecteur HE10 2×10 bornes pour connecter sur le port imprimante de l’Oric.
1 morceau de 10 cm de gaine de vieux cordon chargeur USB en caoutchouc.
Commencez par couper les pattes des diodes pour avoir une longueur totale de 12mm. Séparez les fils de la nappe sur une longueur de 25mm à l’aide d’un cutter puis coupez les fils aux longueurs indiqués sur la photo.
Le fil le plus long sera le no1 (fil repère reconnaissable à sa couleur différente des autres). Couper la gaine en caoutchouc en morceaux de 8mm et dénudez les fils 1,3,5,7,9,11,15 de la nappe et enfilez les bouts de gaine sur les fils, soudez le coté opposé à la bague noire des diodes aux fils sauf le fil no1. Déplacez les gaines pour recouvrir les soudures et la moitié des diodes.
Soudez le côté restant de la diode du fil 13 sur la borne 8 du connecteur DB9 en y joignant le fil no1 de la nappe.
Le coté restant de la diode du fil 15 sur la borne 7.
Le coté restant de la diode du fil 7 sur la borne 6.
Le coté restant de la diode du fil 11 sur la borne 1.
Le coté restant de la diode du fil 9 sur la borne 2.
Le coté restant de la diode du fil 5 sur la borne 3.
Le coté restant de la diode du fil 3 sur la borne 4.
Enroulez la nappe pour faire entrer les diodes et le connecteur DB9 dans sa coquille.
Après avoir connecté le joystick et l’adaptateur sur le port imprimante de l’Oric, vous pouvez tester le bon fonctionnement de l’ensemble en chargeant dans l’Oric l’un des jeux suivants :
Don’t Press The Letter Q
Zebbie
Damzel In Distress
Pour les jeux utilisant le joystick avec l’interface IJK, la routine du jeu procède comme suit :
Envoi d’un « 0 » sur la sortie STROBE de l’imprimante de l’Oric, ce qui active l’interface IJK pendant une durée déterminée. L’adaptateur STINGY se comportera différemment, il restera actif pendant toute la durée du signal bas de STROBE et le joystick unique sera toujours sélectionné quelque soit le numéro de joystick choisi par la routine IJK.
Le bit 5 passe à 0 pour indiquer la présence de l’adaptateur.
Le bit 0 passe à « 0 » si manette poussée à droite.
Le bit 1 passe à « 0 » si manette poussée à gauche.
Le bit 3 passe à « 0 » si manette poussée en bas.
Le bit 4 passe à « 0 » si manette poussée en haut.
Le bit 2 passe à « 0 » si appui sur bouton de feu1.
Si le joystick 1 est sélectionné par la routine, le bit 6 passe à « 0 » si appui sur bouton de feu2 (CPC Amstrad).
Vous constaterez en fouillant dans la logithèque Oric qu’il n’y a pas beaucoup de programmes qui utilisent le standard IJK pour la manette, pourtant, la connexion discrète sur le port imprimante laisse la place au port d’extension libre pour y connecter un lecteur de disquettes ou de carte SD. Le code qui permet d’utiliser les adaptateurs IJK est facilement insérable dans les logiciels qui ne marchaient qu’en mode clavier, ce qui permettra de rendre aux jeux d’action Oric le bâton de joie qui leur manque cruellement.
Cela fait quelques années que je travaille sur ce projet. L’objectif était d’avoir un atmos qui puisse tout démarrer (que cela soit les softs telestrat, mais aussi les softs sedoric, jasmin, les taps etc). Techniquement, beaucoup de choses sont possibles car la carte a différents hardwares permettant de faire des choses qui ne pouvaient pas être fait sur atmos ou telestrat
Il manque le software pour plusieurs cas, mais maintenant que le hard est là, le soft peut se faire plus simplement.
Le hardware aurait pu sortir plus rapidement si je m’étais limité à ne faire que le chargement sur sdcard, mais j’ai voulu apporter bien plus : Ajout de RAM, ROMs en banking, de ports joysticks, la gestion USB pour souris USB, la programmation sur réel des banques, et un OS commun (telestrat/Oric-1/Atmos pour tout articuler). La partie qui m’a pris le plus de temps a été sans doute les problèmes de timings avec le 6502.
Cet article ne représente pas tout ce que la carte fait. Cet article est rédigé comme une sorte d’introduction à la carte.
Au début du projet, j’ai travaillé avec des CPCistes car ils avaient déjà fait des choses similaires. Puis, Assinie a proposé son aide, et l’évolution à la fois de la carte et du soft a pris un coup de boost puisque la plupart des trucs soft les plus marquants viennent d’Assinie 🙂
Le projet n’est pas fermé, chacun peut venir se greffer (au soft et au hard). Néanmoins, pour le hardware, j’ai une sorte de feuille de route que j’essaie de suivre car d’autres versions du hard sortiront dans le futur pour améliorer la carte avec des nouvelles fonctionnalités.
Pour le software, il est possible de faire un jeu en .tap avec les joysticks. Ou Alors il est possible de faire un jeu sur Orix pour profiter de primitives d’ouvertures de fichiers, de lecture, d’affichage etc. Il est techniquement possible de faire un .tap qui pourrait profiter de toutes les banques RAM et ROMs, mais à mon avis, il serait plus simple de faire fonctionner le soft en natif Orix.
Contenu de la carte
Fonctionne avec le 6502 de base uniquement
Deux ports joysticks utilisables simultanément si on veut. 1 port avec 3 boutons, le 2ème port avec 1 bouton (la souris AMX marche à partir du moment où on apporte le 5V car l’AMX version CPC n’a pas le 5V de cablé sur le port)
Un connecteur sdcard pour charger à partir de la sdcard (FAT 32 et carte à 32GO maximum)
Un connecteur USB pour connecter tous les devices usb possibles sur usb, mais il faut écrire les drivers ! 🙂 La liaison série au niveau USB est possible mais il faut aussi écrire les drivers ! La souris USB fonctionne à condition d’écrire le code (qui est ici assez simple, il peut s’écrire en basic), une clé USB de stockage fonctionne aussi.
32 banques de 16KB en ROM
32 banque de 16KB en RAM
Transformer un Oric-1 en atmos, un atmos en Oric-1, ou un atmos en telestrat !
Techniquement, il est possible de charger des jeux atmos et de jouer avec des joysticks sans modification du jeu.
Il n’est pas possible de démarrer des soft sur dsk pour l’instant. Mais il sera possible de démarrer sur les jeux oric-1 only.
Néanmoins, avec la carte, il serait possible d’avoir la logithèque telestrat.
Démarrer les .tap Atmos et jouer aux joysticks
La carte permet de charger la rom atmos modifiée (ou tout autre rom) et de démarrer les .tap sur une sdcard ou sur une clé USB. Pour être franc, la carte n’a pas eu pour objectifs de démarrer les .tap sur sdcard. C’était techniquement possible, mais ce n’était pas la partie qui m’intéressait le plus. L’idée était surtout de pouvoir tout démarrer et d’étendre l’oric
Cette rom basic11 peut charger le multitap. Certains jeux sont récalcitrants, mais Assinie réussit progressivement à faire tourner les jeux sans patch du jeu
Ceci est une limite software qui peut être levée grâce à la mise à jour des roms !
Mise à jour des roms
La carte a été prévue pour pouvoir se reprogrammer au niveau des roms et de la RAM sans avoir besoin d’aucun équipement, ce qui donne une certaine souplesse d’utilisation et de mise à jour. La carte n’est pas figée, elle vit 🙂
Un bouton reset qui pourrait être magique !
Un bouton reset est présent, mais il serait possible de conditionner le démarrage après le reset en appuyant sur une touche, en même temps que l’on reset. Ce n’est pas une idée révolutionnaire, c’est ce qui existait déjà un peu sur telestrat avec la touche del et le reset.
Disponibilité
La carte est disponible maintenant, mais les pcb sont déjà réservés (il n’y avait que 10 exemplaires disponibles). Si vous en voulez une, il faudra me contacter par mp sur ce site ou par mail afin que je vous mette en liste d’attente. La carte a un coût de 100 euros, et est un peu longue à assembler (et les composants sont de 3 fournisseurs, ce qui rend compliqué la production). Enfin, je fais cela sur mon peu de temps disponible mais cela avance tout de même 🙂
Le dernier acte (connu à ce jour) de la programmation multi-ordinateurs en basic par Dan Cresp, et un coup de chapeau à Dom
Informations générales
Après presque quatre ans sans programmer sur l’ORIC, quand Dan reprend la création de soft avec «Averno», il est tellement satisfait du résultat qu’il s’engage dans un autre projet encore plus complexe.
AVERNO a été le premier jeu que réalisé en BASIC par Dan où le protagoniste passe en arrière-plan sans défauts d’affichage. Pour ce faire, Dan a placé la totalité de la zone de jeu dans une matrice texte et déplace le fantôme en reconstituant l’arrière-plan à partir des données de cette matrice. Le résultat est bon mais le coût de cette routine, ainsi que la maintenance de la matrice sont élevés. Le processus prend environ 10 secondes. Sur le plan graphique, l’utilisation de 3×2 caractères lui permettait de réaliser des graphismes presque identiques à l’original … monochromes.
Par la suite, Dom sur oric-concours.forumactif.org a amélioré l’apparence du jeu en utilisant une propriété des attributs de couleur de l’écran permettant d’afficher les couleurs complémentaires des couleurs principales. Il a également amélioré la composition du niveau en enregistrant les écrans. Et pour simplifier l’ensemble, il a transféré le logiciel sur une disquette. L’on doit admettre que la version s’est améliorée et que son apparence est meilleure. Bravo !!!
Avec Solomon’s Key, Dan va un cran plus loin dans la conception de l’écran.
Un écran titre alléchant !
Sprites Cette fois, Dan a voulu expérimenter une utilisation améliorée des «sprites», sans avoir à monter l’usine à gaz de la matrice écran, et insérer directement des valeurs 16 bits dans la mémoire vidéo à l’aide de l’instruction DOKE, qui affecte l’adresse de mémoire indiquée et la suivante.
Dan n’avait pas réussi à mettre en oeuvre ce processus auparavant même si au final, il est assez simple. Brièvement, chaque image-objet a une taille de 2×2 caractères. Avant de placer une image-objet à l’écran, Dan enregistre la valeur de 2×2 caractères où elle sera insérée dans deux variables numériques. Ceci est fait avec un DEEK, qui est un PEEK 16 bits (à l’image du DOKE qui est un POKE 16 bits). La position de l’image-objet est une adresse mémoire et non deux coordonnées. Avec deux DOKE, il copie rapidement le sprite sur l’écran. Avant de le déplacer, Dan remplace l’arrière-plan à la position correspondante à partir de la valeur stockée dans la variable numérique, modifie la position de l’image-objet, enregistre l’arrière-plan dans la variable, puis le place dans la nouvelle position à l’aide des deux clés. Le résultat est là, efficace.
L’écran Sur ZX-Spectrum, le jeu original a une largeur d’écran de 32 caractères. Deux pour les marges et 15 blocs de 2×2 caractères. Pour que cette version ait le même aspect, Dan aurais dû utiliser des blocs 3×2, mais avec l’ORIC, il est limité à 38 colonnes, loin de son besoin de 47. De fait, Dan a été contraint à réduire la taille des sprites à 2×2. De plus, les caractères de l’Oric font 6 pixels au lieu des 8 habituels. L’aspect final est de fait moins fouillé, mais avec des graphiques rapides mis en oeuvre avec les 2 DOKE.
Comme la largeur de l’écran comporte plus de caractères, Dan a placé une colonne de blocs des deux côtés de l’écran et une colonne inférieure. Cela l’a également aidé à contrôler le déplacement des éléments mobiles du jeu.
Dans le code, sur les lignes 440 à 455, trois lignes calculent quel bloc de fond doit être placé dans une zone de l’écran quand un bloc bleu est supprimé, et lorsque l’on prend la clé ou une pièce de monnaie, ou encore quand un ennemi frappe.
Graphiques Le jeu de caractères ORIC ne comporte que 128 caractères. Dan souhaitait conserver les lettres, les chiffres et certains caractères spéciaux, Il a donc redéfini le minimum de blocs graphiques possibles. L’utilisation de deux caractères en largeur de bloc au lieu de trois a contribué à cet objectif. L’impact principal de ces options a été la suppression du mouvement de jambes de notre personnage ; mais cela a également permis de simplifier quelque peu le code et à améliorer les performances. Dan peut toujours tout montrer avec deux simples DOKE.
Et comme toujours avec les programmes développés par Dan sur ORIC, les graphiques ont dû être redessinés par rapport à la version initiale car au lieu de la matrice habituelle de 8×8 pixels, nous passons à une matrice 8×6 soit 12 pixels horizontaux au lieu des 16 habituels.
Les couleurs … encore un problème ! En raison de la façon dont l’Oric gère les attributs, Dan a choisi de créer Solomon’s Key en monochrome, avec un peu de couleur dans la présentation et dans les marqueurs. Pour mettre en évidence les briques que nous pouvons détruire, Dan a appliqué la technique consistant à utiliser les couleurs complémentaires des deux couleurs principales en ajoutant 128 au code ASCII du personnage (les caractères inversés). permettant d’afficher 4 couleurs sur l’écran de jeu.
L’encodage des niveaux A ce stade, nous arrivons à la création de l’écran. Chaque écran est constitué d’une matrice de 12 lignes et de 15 colonnes. Dans chaque colonne se trouve un tableau de caractères 2×2, tel que des blocs de pierre, des portes, des clés ou des pièces de monnaie. Dan a choisi de coder les niveaux en utilisant un format similaire à «Averno» simplifié. La présentation du niveau prend environ 6 secondes et le codage est effectué comme suit:
Une lettre entre “A” et “Z” a une valeur comprise entre 1 et 26 et correspond aux blocs de pierre à afficher. Alternativement, ils apparaissent en jaune ou en bleu.
Un caractère “*” signifie qu’il modifie le type de bloc de pierre indiqué, bleu ou jaune.
Une lettre entre “a” et “z” a une valeur comprise entre 1 et 26 et correspond à des blocs vides de 2×2.
Un caractère “.” Désigne un bout de la ligne en sautant au suivant.
Un caractère numérique correspond à un objet:
2 portes,
3 clés,
4 devises,
6 têtes et
7 canaux.
1, et 5 correspondent aux blocs de pierre jaune et bleue.
Un écran de jeu de Solomon’s Key, avec l’aperçu de son encodage graphique
Le contrôle du personnage Une des premières difficultés à résoudre avant de commencer à développer le jeu était de savoir comment gérer les différents mouvements et actions que le joueur pouvait faire. La programmation du jeu en Basic prend en compte l’impossibilité d’appuyer sur plusieurs touches simultanément.
Appuyez sur “Z” et “X” pour déplacer le magicien à gauche ou à droite.
En appuyant sur “P” nous sautons. S’il y a un bloc au-dessus, nous le cassons. Sinon, nous pouvons augmenter la hauteur d’un bloc. Si pendant que nous sautons, nous appuyons sur une flèche, nous irons dans cette direction.
En appuyant sur “L” nous insérons ou supprimons un bloc bleu. Si nous sommes juste au-dessus d’un bloc, nous le placerons devant et si nous ne le plaçons pas au niveau du sol.
Les Ennemis Contrairement au jeu “Averno”, dans ce “Solomon’s Key”, il y a des ennemis et ils bougent ! Dan a mis en place une routine très basique qui permet de déplacer jusqu’à cinq ennemis avec deux vitesses différentes (des déplacements de un ou deux caractères), leur déplacement est horizontal ou vertical, et simule l’effet de rebond ou non lorsque vous touchez un mur, en détruisant les blocs bleus touchées. Le tout en sept lignes de code !
Le type de mouvement de l’ennemi et sa position initiale sont définis dans les DATA de la ligne 9600. Chaque ennemi requiert trois caractères :
le premier indique le type
les deux autres la position initiale horizontale et verticale. Pour les positions, Dan utilise des lettres afin d’indiquer des valeurs supérieures à un chiffre avec un seul caractère.
La routine de mouvement contrôle le nombre d’ennemis dans ce niveau. Moins il y a d’ennemis, plus ils se déplacent fréquemment et rapidement.
Les sprites des ennemis se déplacent également sur le fond sans le supprimer. Comme pour le sprite du protagoniste, la technique de sauvegarde du personnage qui était à l’écran avant d’utiliser l’ennemi sur l’écran a été utilisée. Lorsqu’il se déplace, il reconstitue l’arrière-plan, sa nouvelle position est recalculée, puis le graphique de l’ennemi est placé.
Résultat final En ce qui concerne la vitesse, l’ORIC BASIC pourrait être placé dans le milieu de gamme des ordinateurs 8 bits. C’est l’un des plus rapides en impression à l’écran, mais pour le reste, ce serait au niveau du MSX ou du ZX-Spectrum. Des ordinateurs tels que l’Amstrad CPC impriment très lentement à l’écran mais plus rapidement, en parallèle avec des ordinateurs tels que BBC Micro / Electron ou Lynx Camputers. La gamme basse reste pour le ZX-81 et surtout, le Texas Instruments TI / 99-4A qui mange séparément.
Après toutes ces briques, je dois admettre que, malgré les limites imposées par ORIC BASIC, de par son apparence et ses performances, je suis très satisfait. Cela ressemble à un jeu commercial, mais c’est du BASIC pur et dur. Je pense que ce n’est pas habituel de regarder des programmes en BASIC comme celui-ci. Je pense que j’ai placé la barre très haut, mais avec l’expérimentation de ces techniques, je suis sûr que je ferai autre chose bientôt. En fait, au fond de moi, j’ai déjà l’idée d’adapter un classique qui n’existe pas dans ORIC.
Eh bien, rien de plus, je ne peux qu’espérer que cela vous plaise …
Je vous invite à l’essayer.
Quelques éléments concernant le programme
La routine principale du programme est divisée en 10 blocs:
Déclaration des variables et matrices et début du jeu.
Boucle principale de développement.
Mouvement des ennemis.
Mouvement du protagoniste.
Routines des actions du protagoniste.
Passer le niveau ou perdre une vie.
Routine pour montrer le niveau de jeu.
Présentation et début du jeu.
Charger UDG.
DATA avec les UDG du jeu et les valeurs de la matrice.
L’ensemble du programme occupe 170 lignes dont vous trouverez ci-dessous les principales :
5 – Nous définissons les variables du jeu.
10 – Nous définissons les matrices du jeu.
20 – Passez au sous-programme qui redéfinit les caractères et définit les variables globales.
40 – Afficher le niveau à l’écran.
100 – REPEAT indiquant le début de la boucle principale.
105 – Vérifiez si nous sautons.
110 – Si nous n’avons pas de terre sous nos pieds, le personnage tombe.
115 – Prenez la touche appuyée.
120 – Touche de saut.
125 – Bloquer la touche marche / arrêt.
130 – Touche de déplacement à droite.
135 – Touche de déplacement gauche.
140 – Vérifiez si le personnage frappe à la porte, à la clé ou à la pièce de monnaie.
150 – Aller au sous-programme de mouvement ennemi.
155 – Retournez à REPEAT si la variable U = 0.
160 – Lorsque vous quittez la boucle, regardez la valeur de U. U = -1 niveau et U = 2 perd une vie.
200 – Déplace le fantôme vers la droite.
225 – Déplace le fantôme vers la gauche.
300 – Contrôle la chute du personnage.
320 – Détecte quel objet tu as sous le personnage.
350 – Routine de saut.
400 – Mettre / enlever le bloc.
440 – Routine de remplacement en arrière-plan lors de la pose, de la suppression d’un bloc ou de la saisie d’un objet.
500 – Routine pour passer un niveau.
550 – Programme de perte de vie et fin du jeu.
600 – Montre les marqueurs de points, de niveau et de vies.
2000 – Routine qui montre le niveau. Les données sont encodées dans la matrice M $.
2050 – Définissez le type, la vitesse et la direction des ennemis et placez-les à l’écran.
2500 – Écran de présentation.
3000 – Sélection des couleurs, effacement de l’écran, masquage du curseur et masquage des «CAPS» supérieurs.
3005 – Lecture de données UDG.
3010 – Définir des variables avec des bandes de caractères.
9000 – DATA avec graphes, positions, blocs de graphes et codage de niveau UDG.
9200 – Blocs graphiques utilisés par l’instruction DOKE.
9300 – Position initiale du caractère en fonction de l’écran.
9500 – Données de niveau.
9600 – Données avec les types et la position des ennemis.
Le Jeu !
Solomon’s Key est un jeu publié par Tecmo en 1986 et concédé sous licence pour différents systèmes à partir de 1987. US Gold a commandé les versions 8 bits du jeu.
Le jeu est de type plates-formes avec une pincée de jeu de stratégie. Nous y contrôlons un petit sorcier qui doit saisir une clé et sortir pour monter de niveau. Le magicien a la capacité de créer et de détruire des blocs bleus qui lui permettront d’atteindre la clé. Chaque niveau est plein d’ennemis qui te tueront au moindre contact. Le petit sorcier part avec 5 vies.
La version développée par Dan utilise les mêmes mécanismes que le jeu original avec les 17 écrans de la version ZX-Spectrum, qui sont répétés indéfiniment. Le mouvement des ennemis est adapté aux limitations du BASIC.
Contrôles :
Déplacez l’assistant à gauche ou à droite avec “Z” et “X”.
Appuyez sur “L” pour créer ou détruire un bloc bleu. Selon votre position, il sera créé devant vous à votre hauteur ou à une hauteur inférieure.
Appuyez sur “P” pour sauter, avec en plus la possibilité de contrôler la direction en appuyant sur “Z” ou “X”. Si vous avez un bloc en haut, vous le détruisez d’un coup de tête.
Comparons …
Comparaison des versions Oric-Atmos et ZX-Spectrum
