Category: Ceomag

  • Galaxy Wars

    Infos générales

    Ce jeu est une adaptation de la version précédemment programmée pour le COMMODORE-16 et le ZX-SPECTRUM. Pour cela, j’ai copié, ligne par ligne, le code de la version C-16, en y apportant de petites modifications car elles ont le même nombre de lignes et peuvent toutes deux utiliser ELSE.

    Galaxy Wars sur C-16, base du développement de la version Oric
    Une des premières versions de Galaxy Wars, sur ZX

    Pour la première fois, j’ai utilisé un émulateur pour développer le jeu : EUPHORIC sous MS-DOS. Le résultat est très satisfaisant puisque cet émulateur permet, en appuyant sur F3, d’avoir un clavier qui correspond à celui du PC, cela permet de taper un programme très rapidement et confortablement. Prendre un listing ou charger / enregistrer un programme est tout aussi simple.

    Les graphismes originaux, basés sur des largeurs de 8 pixels de base

    La seule complication lors du développement de cette version a été le besoin de coder à nouveau tous les graphiques, car l’ORIC utilise des caractères de 6 pixels de large et non de 8 comme le reste des ordinateurs. Ainsi, la conception du missile est légèrement plus étroite et les vaisseaux supérieurs occupent 3 caractères de large au lieu de 2. Quoi qu’il en soit, je l’ai fait et si vous touchez un navire du côté droit, vous ne le détruisez pas.

    Des graphismes “handheld”

    En ce qui concerne le son, j’ai repris les routines standards.

    Et en ce qui concerne l’aspect, grâce au système particulier de mémoire d’écran de ce système, c’est la seule version dans laquelle j’ai vraiment été capable de reproduire l’effet «cellophane», en émulant les rayures colorées.

    Ecarts à la version TAITO d’origine:

    • Cette version est un peu plus large et beaucoup moins haute puisque dans le jeu original l’écran est vertical.
    • Il y a moins de rangées d’astéroïdes, en raison de la taille verticale.
    • Pendant l’ascension du missile, nous pouvons le contrôler horizontalement, mais nous ne contrôlons pas la vitesse.
    • Les envahisseurs n’accélèrent pas lorsqu’il ne reste que quelques-uns d’entre eux.
    • Les astéroïdes ne descendent pas lorsqu’ils atteignent les extrêmes.
    • Les scores sont limités à 50, 100 et 150 points.
    • Il n’y a pas d’animations sur les ennemis.

    Le contrôle des ennemis est très simple. Il y a 6 bandes avec les ennemis dans la position correspondante. Les lignes paires tournent à gauche et les lignes impaires à droite.

    Le bloc principal du programme n’occupe que 18 lignes. À chaque passage, je déplace une rangée d’ennemis et contrôle un tir ennemi. Le compteur est commun dans les deux cas (A).

    Pour gagner de la vitesse, je me suis débarrassé des animations des ennemis. J’ai choisi d’utiliser les graphiques des ennemis dispersés.

    Lors de collisions, je vérifie seulement si la tête du missile touche quelque chose, mais pas la partie inférieure. En ce qui concerne les bombes ennemies, seul celui qui est actif vérifie s’il touche quelque chose. Cela rend le jeu plus rapide, mais il se peut que nous touchions quelque chose et que rien ne nous arrive. Comme le processus est rapide, il y a un risque … et il vaut mieux ne pas y jouer.

    En ce qui concerne les performances, cette version fonctionne aussi bien (sinon autre chose) que les deux précédentes (C-16 et SPECTRUM).
    La vérité est que, malgré ses bugs, ce BASIC tire plus que bien.

    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

    Le programme principal est divisé en 10 blocs:

    • Déclaration de matrice. Appel aux routines principales.
    • Contrôle notre plateforme ou missile.
    • Contrôle des envahisseurs et des astéroïdes.
    • Contrôle des tirs ennemis.
    • Détection d’impact de missile. Touchez un astéroïde, un envahisseur ou un tir ennemi.
    • Perdre une vie.
    • écran de présentation.
    • Début du jeu.
    • Plusieurs routines.
    • Données avec les graphismes du jeu.

    Comment le programme fonctionne-t’il, avec ses 88 lignes ?

    • 10 – Nous définissons les matrices du jeu.
    • 30 – Initialiser l’enregistrement (R) et aller à la routine qui redéfinit les graphiques.
    • 50 – Allons à la présentation du jeu.
    • 100 – Nous déplaçons la plate-forme ou le missile dans la direction indiquée.
    • 130 – Si le missile a été tiré (T = 2), il passe à 160.
    • 140 – Si la touche RETOUR est enfoncée, nous tirons le missile et supprimons la plate-forme.
    • 160 – Nous supprimons le missile et modifions la position verticale (Y).
    • 170 – Si la pointe du missile touche quelque chose, nous sautons à 400.
    • 180 – Nous mettons le missile dans la nouvelle position.
    • 200 – Nous déplaçons l’une des 6 rangées d’ennemis ou d’astéroïdes dans la direction correspondante. (B = 1: Droite, B = -1: Gauche).
    • 220 – Nous imprimons la ligne de l’ennemi.
    • 250 – Nous voyons si l’une des 6 bombes ennemies est active.
    • 260 – Si ce n’est pas le cas, nous voyons s’il y a un envahisseur en position sur l’écran pour activer le tir.
    • 270 – Si le tir touche la plate-forme ou si le missile passe à 500.
    • 400 – Si la position Y est supérieure à 5, c’est que nous avons frappé avec un astéroïde ou tiré et sauté à 500.
    • 410 – Nous calculons la position de l’envahisseur détruit.
    • 420 – On met l’explosion, un son retentit et on calcule les points (50, 100 ou 150).
    • 430 – Nous supprimons l’envahisseur de la ligne et soustrayons un envahisseur des autres (Q).
    • 450 – Nous montrons les points et faisons une pause (5500) et mettons à jour le marqueur.
    • 470 – En passant le niveau, nous augmentons sa valeur s’il est inférieur à 5.
    • 500 – Nous mettons une explosion à la position du missile et reproduisons un son.
    • 520 – Nous mettons à jour le marqueur de vie.
    • 550 – S’il n’y a plus de vies, le jeu se termine.
    • 2000 – Écran de présentation du jeu.
    • 2050 – Appuyez sur une touche pour effacer l’écran (5400) et faire clignoter le marqueur du lecteur 1.
    • 2500 – Nous avons monté les bandes des envahisseurs.
    • 2510 – Routine générant de manière aléatoire des bandes d’astéroïdes. Fuller dans les niveaux avancés.
    • 2570 – Initialisation des variables principales de l’item.
    • 5000 – Changer les couleurs, masquer le curseur et désactiver les majuscules.
    • 5002 – Instruction Écran pendant la lecture des graphiques.
    • 5010 – La routine commence pour redéfinir le jeu de caractères.
    • 5020 – Nous sauvegardons l’attribut color de chaque ligne de l’écran dans la matrice C $.
    • 5040 – Initialise la matrice de la hauteur des différents ennemis V ().
    • 5050 – Initialise la position des bombes ennemies.
    • 5100 – Affiche le marqueur de score ou l’enregistrement.
    • 5400 – Routine d’effacement de l’écran activant les couleurs correspondantes par ligne.
    • 5600 – Affiche les 6 rangées d’ennemis dans leur position et avec la couleur correspondante.
    • 9000 – Ligne de données avec graphiques du jeu.

    Le jeu

    Ce jeu vidéo d’arcade a été développé par Universal et fabriqué par Taito en 1979.

    L’objectif du jeu est de détruire la flotte d’envahisseurs dans la partie supérieure de l’écran. Pour cela, nous contrôlons une plate-forme avec un missile. Lors du tir du missile, vous devez éviter les astéroïdes et les tirs ennemis et toucher un envahisseur.

    Contrôles:
    Appuyez sur Z ou X pour déplacer la plate-forme et le missile vers la gauche ou la droite. Appuyez sur la touche RETOUR pour tirer le missile.

    Quelques autres versions

    Comparaison de la version C-16 avec la version originale
    Le C-16 en action !
    Comparaison de la version ZX Spectrum avec la version d’arcade originale
    le ZX Spectrum en action
  • Visitons la Rom Monitoring (7e et dernière partie)

    Paru mag 164 page 6 https://www.oric.org/ceomag_download/index.php?action=&id=&exppath=/2003/ceomag/12_december

    par André C. et Claude S.Z

    Partie finale de la Rom (en FFC7-FFFF).a)

    Table de conversion Clavier/Ascii FFC7: 10 4C La touche ‘L’ de caractère Ascii normal #4C devient #10 normalement inutilisé (CTRL/P qui inverse le b2 de 026A). Le seul effet visible en pratique est qu’après un CTRL/T (mode minuscules) l’appui sur SHIFT+L n’afficherien alors que SHIFT+K par exemple affiche bien un ‘K’. Cette différence avec la Rom v1.1 ressemble bien à une bogue. Modification des vecteurs d’interruption

    b) Le vecteur d’interruption NMI, situé en FFFA-FFFB envoie normalement à l’adresse 0247 où se trouve l’adresse de la routine F8B2 (Warm Start qui correspond aussi aubouton Reset). Maintenant le détour par la page 2 a été supprimé : Le vecteur envoie directement en F8B2, supprimant ainsi tout détournement ou inhibition de ce Reset. En FFFA-FFFB les octets 4702 ont été remplacés par B2F8.c) Le vecteur d’interruption de Reset Système, situé en FFFC-FFFD renvoie normalement à l’adresse F88F où se trouve la routine Cold Start.

    Maintenant il envoie en F89A où se trouve la nouvelle routine simplifiée.En FFFC-FFFD les octets 8FF8 ont été remplacés par 9AF8.d) Le vecteur d’interruption IRQ, situé en FFFE-FFFF envoie normalement à l’adresse 0244 où se trouve celle de la routine EE22. Maintenant le détour par la page 2 a été supprimé : Le vecteur envoie directement en EE22, supprimant ainsi tout détournement. En FFFE-FFFF les octets 4402 ont été remplacés par 22EE. Le même type de prévention a été appliqué en C4B 4(001A, imprimer chaîne AY), C5E8 (023B, prendre un caractère au clavier), CCF4 (023E, vecteur imprimante), EE31 (024A, retour IRQ), F907 (0238, afficher caractère) et FA0 1 (0238, afficher caractère). BANC D’ESSAI A l’utilisation, cette Rom présente le très grand avantage de permettre une maîtrise quasi complète de la situation.

    Les outils de débogage qui ont été ajoutés (DUMP, DES, HDKMOD, CLEAN, SEARCH, MOVE et MON) font merveille. Et comme ils sont inscrits dans la Rom, ils sont disponible sen permanence. De ce point de vue la Rom Monitoring est un excellent outil de développement. La perte de certains caractères,notamment les minuscules peut être facilement contournée par leur chargement en Ram après le boot. Vous pouvez facilement récupérer le fichier nécessaire en exécutant un SAVE”MINUSC.CHS”,A#B708,E#B770 sur un Oric normal. Mais cette Rom a quand même quelques petits défauts.

    Citons en premier lieu, le non blocage du lancement AUTO lorsqu’il s’agit non plus de développer, mais de transférervos cassettes favorites sur disquette. Certes, on peut utiliser le Reset sous l’Oric et accéder à tout ce qu’il y a en mémoire. Mais ce n’est pas très pratique. Il est vrai que certaines protections reposent sur l’obligation d’exécuter le programme et nous avons fait l’expérience que les Roms ‘qui bloquent tout’ ne sont pas non plus d’un usage universel. Notez aussi que l’exécution d’un programme peut parfois détruire les vecteurs du Dos, rendant impossible la sauvegarde sur disquette… A propos de Dos, la Rom Monitoring n’est malheureusement pas compatible avec Sedoric et il faut se rabattre sur un autre Dos pour sauvegarder son travail. Enfin, l’affichage des adresses de début et de fin est très pratique, notamment parce qu’il se produit à la fin, au moment où il faut appuyer sur le Reset.

    Mais cet affichage présente l’inconvénient de polluer l’écran qui fait partie du programme qu’on cherche à récupérer. Il n’y a pas de solution simple, à part peut-être l’ouverture d’une fenêtre temporaire avec restitution ultérieure de l’écran. Mais cela aurait sans doute fait beaucoup de code à caser dans une Rom déjà pleine comme un oeuf !

    TRANSFERT K7 VERS DISQUETTE

    Si vous avez un problème pour transférer une de vos anciennes K7 sur disquette, nous vous invitons à relire notre article de synthèse paru dans le Ceo-Mag n°138, pages 6 à 9.Au fil de nos articles, nous vous avons parlé de plusieurs Roms susceptibles de vous aider : La Rom ‘Renifleuse’ (Ceo-Mag n°77, pages 3 et 4), dans laquelle les caractères minuscules ont été sacrifiés pour installer une routine qui affiche les adresses de début et de fin de fichier. Un Reset permet ensuite de sauver sur disquette en utilisant les adresses indiquées.La Rom ‘Déplombeuse’ (Ceo-Mag n°139, pages 6 à 8),dans laquelle le démarrage Auto a été neutralisé, ainsi que laroutine de ëvérification’ de la Ram (cette routine écrit des #AA puis des #55 qui écrasent tout), largement utilisée dans nombre de dispositifs ‘anti-copie’.La Rom ‘Suceuse’ (Ceo-Mag n°140, pages 7 à 10), qui a les mêmes propriétés que la ‘Déplombeuse’, mais en plus la commande EDIT a été remplacée par la commande SUCE, capable de lire octet après octet tout ce qu’il y a sur une K7 et de le copier en RAM sans chercher à savoir quoi que ce soit. B’te, mais efficace ! Enfin la Rom ‘Monitoring’ qui a fait l’objet de toute cette série d’articles, tant son contenu était riche.

    CONCLUSION

    Nous nous doutons bien que la plupart d’entre vous ont décroché depuis belle lurette, découragés par cette avalanche de code machine. Portant, le Ceo-Mag n’a pas pour unique but de distraire ses lecteurs. Comme l’ont remarqué beaucoup d’entre vous, le Ceo-Mag c’est la mémoire de l’Oric. Un hommage a été rendu à Jean-Jacques Jung, auteur de la Rom Monitoring. Espérons qu’un jour ou l’autre, certains pourront y puiser l’une ou l’autre des bonnes routines de Jean-Jacques. En attendant, n’hésitez pas à l’utiliser, même sans connaître le détail de ses rouages…

  • Les Chips 65xxx

    http://www.westerndesigncenter.com/

    Cet article est issu du mag 164 juillet page 7 & 8 (2003) : https://www.oric.org/ftp/ceo/ceomag/downloads///2003/ceomag/12_december/164-07-08.pdf

    D’après un e-mail de Fabrice F., rédigé à propos d’une commande groupée.

    – Processeur W65C02S (il tourne jusqu’à 14 Mhz !) : La version CMos du 6502. Moins consommatrice enénergie et jeu d’instruction étendu. Disponible en boîtier carré PLCC 44 broches pour les pros du hard ouen boîtier DIP 40 broches pour rentrer directement dans les Oric.

    – Processeur W65C816S (14 Mhz aussi) : La version 16 bits du 6502. Registres 8 ou 16 bits, modes d’adressages supplémentaires, jeu étendu, 16 Mo adressable, etc. Disponible en boîtier carré PLCC 44 broches pour les pros ou en boîtier DIP 40 broches. Mais attention, le brochage n’est pas complètement compatible avec l’Oric ! Si quelqu’un sait comment modifier l’Oric pour qu’il accepte un 65816, pensez à moi : J’en commande quelques-uns uns au cas où j’en fusillerais pendant mes essais !

    – Microcontrôleur W65C134S (8 MHz): Contient un W65C02S, plus 4Ko de Rom, 192 octets de Ram, 4timers 16 bits, 56 broches d’entrées-sorties, interface bus série, interface série asynchrone, contrôleurd ‘interruptions, chien de garde, signaux de sélection de boîtiers externes… Disponible en boîtier carré PLCC 68 broches pour les pros ou en boîtier QFP 80 broches pour les super-pros…

    – Microcontrôleur W65C265S (8 MHz): Contient un W65C816S (16 bits), plus 8Ko de rom, 576 octets de Ram, 64 broches d’entrées-sorties, 2 générateurs de son, 8 timers 16 bits, 4 interfaces série asynchrones,contrôleur d’interruptions, chien de garde, signaux de sélection de boîtiers externes… Disponible en boîtier carré PLCC 84 broches pour les pros ou en boîtier QFP 100 broches pour les super-pros…

    VIA W65C22S (il marche jusqu’à 10 MHz): La version CMOS du VIA 6522. Disponible en boîtier carré PLCC 44 broches ou en boîtier DIP 40 broches pour entrer directement dans les Oric.

  • Carte contrôleur Microdisc et Eprom 2764

    Cet article est issu du mag 164 juillet page 7 & 8 (2003) : https://www.oric.org/ftp/ceo/ceomag/downloads/2003/ceomag/12_december/164-07-08.pdf

    De Luc B. : J’ai décidé de me lancer dans la réalisation du contrôleur de disquette et suis preneur du plan du circuit imprimé.

    Réponse de André C. : Tu as bien-s ̊r vu les superbes articles deThierry dans le Ceo-Mag. Je t’encourage à lui écrire. Il aide déjà quelqu’un d’autre à réaliser une carte contrôleur. Et comme vous ‘tes tous les deux des gens sympas, je pense que vous allez vous entendre facilement. Je ne sais pas quelles facilités tu as pour réaliser un circuit imprimé à partir de ses tympons. Tu peux voir ça avec lui. En cas de besoin, j’ai une copie de ces typons: le fichier fait 1Mo et je pourrais te l’envoyer soit par la poste soit par e-mail. Pour la Rom de la carte contrôleur, je pourrais te la ́ shooter ª, mais je n’en ai pas d’avance. Il est encore possible de trouver dans le commerce des 2764 et des 27C64. Je crois que Thierry a utilisé une 27C64 et qu’il a eu quelques difficultés. Demande-lui s’il a essayé une 2764 avec son prototype. En principe cela devrait ‘tre mieux,car sa carte est une copie de la carte Microdisc d’origine qui utilise une 2764. Mais il a peut-être modifié quelques réglages pour utiliser sa 27C64. Dans mon contrôleur Microdisc, les 27C64 ne marchent pas,c’est pourquoi je pense qu’il a adapté quelque chose. Pour l’Eprom 2764, plutôt que d’en acheter uneneuve (dans les 30F et difficile à trouver), regarde si dans ton coin il n’y a pas un magasin d’occasion informatique ou un réparateur. Tu pourras probablement en trouver pour une bouchée de pain, car cela n’intéresse plus personne.

    Réponse de Thierry B. : Ok pour vous faire profiter de monexpérience sur la réalisation de la carte contrôleur :

    1) Je confirme qu’il s’agit d’une réplique de la carte contrôleur Microdisc mais sur un circuit imprimé simplifié donc réalisable par tout amateur en électronique.

    2) Luc, je peux t’adresser mes typons originaux si tu as du matériel pour insoler des plaques pré-sensibilisées.

    3) J’ai utilisé une 27C64-200 donc temps d’accès 200ns avec ma carte. J’ai ajusté quelques composants,tout cela est détaillé dans l’article publié dans le Ceo-Mag.

    4) Je n’ai pas essayé une vraie 2764. Effectivement cela devrait mieux marcher.

    5) Mais si on ne peut pas utiliser de 27C64, on doit pouvoir utiliser une 27C128-200 ou 27C256-200…

    Suite de Thierry [à propos de la nécessité d’utiliser un Amplibus avec sa carte équipée d’un 27C64] : Ma carte contrôleur fonctionne bien avec l’Amplibus simplifié, mais seulement lorsque le signal Phi2 n’est pas amplifié ! Lorsque Phi2 est amplifié, il est parasité. Je suppose qu’il s’agit d’un problème électromagnétique lié à la conception de la carte mais je n’ai pas eu le temps d’étudier le problème. Ma carte contrôleur fonctionne avec tous mes Oric, d’origine ou améliorés.

    Nouveau problème d’André : Je viens de tenter de transformer une carte contrôleur Microdisc en carte contrôleur Cumana (pour voir si c’est possible et comment Áa marche). Pour ce faire, j’ai shooté le fichier Cumana.rom distribué avec Euphoric dans une 27C64. Dans les Microdisc il y a des 2764, mais j’avais seulement une 27C64 CMOS sous la main. Résultat, j’ai réussi à booter une disquette Cumana une foispar hasard au premier essai et plus jamais par la suite, même avec un Amplibus. Et c’est un coup de pot, sinon, j’aurais pensé que c’était une idée merdique! Comme je sub-odorais que ça devait marcher et que d’autre part mon Jasmin 2 ne boote qu’avec un seul de mes Atmos et pas avec les autres, j’ai été chercher cet Atmos et j’ai testé. Ca marche dans 80% des cas. Fabrice a tourné plusieurs fois autour de l’idée depondre une nouvelle version de l’Eprom de la carte contrôleur du Microdisc, pour en corriger les bogues et la rendre compatible avec tous systèmes Oric. Que ferons-nous sans 2764 ?

    Le point de vue de Fabrice F. : Je pense que les problèmes de compatibilité rencontrés entre certains Oric et certains Microdisc viennent essentiellement du mécanisme utilisé pour s’accommoder des temps d’accès des vieilles Eproms (j’ai aussi rencontré des cartes mères Oric modifiées bizarrement pour amplifier le signal Phi2 et qui posaient problème). Je voudrais insister sur ce problème de temps d’accès : les Eproms 2764 utilisées à l’époque étaient particulièrement lentes. Celle qui équipe mon microdisc est à 450ns !. Si l’Oric avait une horloge équilibrée, c’est à dire des créneaux haut et bas de 500ns chacun, ça pourrait passer (tout juste)… Mais vous savez que l’horloge de l’Oric estrépartie différemment de sorte que l’Ula ait la Ram à sa disposition pendant les 2/3 du temps, et le Cpu pendant le 1/3 restant. Ce qui veut dire que le créneau de l’horloge qui donne l’usage du bus au Cpu ne Carte contrôleur Microdisc et Eprom 2764 Par Fabrice F., Thierry B., Luc B. et André C.8dure que 330ns environ… Du coup, les concepteurs du Microdisc ont construit un signal Phi2 décalé de façon à anticiper les accès à l’Eprom ! C’est le décalage de ce signal qui est délicat : Il peut facilement déborder sur l’utilisation du bus par l’Ula (sur le créneau d’avant ou sur le créneau suivant… d’o ̆ collision)ou n’être pas assez décalé pour donner suffisamment de temps à l’Eprom. Lorsque j’avais utilisé une eprom 16Ko dans un Microdisc pour y installer un Telemon modifié, il avait fallu que j’ajuste la résistance variable si je me souviens bien… Mais en plus, le décalage ne dépend pas que du temps d’accès de l’Eprom utilisée : Lorsque j’ai fait des essais avec des processeurs 65C02 certifiés pour marcher à 2, 3 et 4 MHz, je n’ai pas réussi à ajuster la résistance variable pour faire marcher le Microdisc avec le Cpu certifié 4 MHz. Tout ça parce que même en ayant un signal d’horloge d’entrée qui reste toujours le même (Phi1), les temps des créneaux de l’horloge Phi2 changent en fonction du processeur (c’est lui qui fabrique ce signal). Bref, pas glop… Thierry, à mon avis, il serait bon de supprimer ce circuit d’avance d’horloge dans ta nouvelle carte contrôleur, maintenant que les Eproms ont des temps d’accès de 250ns dans le piredes cas (et plus couramment 200, 150 ou 120ns ou même moins sur des grosses capacités) : La carte serait beaucoup plus simple et s’accommoderait mieux des différents processeurs et des différentes Eproms…C’était ma contribution à 2 centimes (d’euros) 🙂

    Réponse d’André : Fabrice, j’espère que tu peux attendre un peu pour tes 2 centimes d’euros. Pas cher d’ailleurs l’avis de l’expert, mais chut, il risque d’augmenter ses tarifs… Nous avons tendance à ne pas assez prendre en compte le genre de considérations, que tu as judicieusement rappelé. D’ailleurs, je crois me souvenir qu’il existe différentes manières d’amplifier Phi2 et que selon le dispositif utilisé on introduit un décalage différent dans le signal. Comme il est difficile de remonter le temps perdu, il me semble que la carte contrôleur se cale sur le créneau suivant, c’est à dire retarde jusqu’à la période suivante (rôle deRV1). Sachant que les SAV ont bricolé de toutes les manières les cartes mères pour qu’elles ́acceptentªle Microdisc (lui-même aussi bricolé), il n’est pas étonnant d’une part que certains ́couplesª dépareillés ne marchent pas (et comment retrouver l’ancien conjoint?) et d’autre part que le changement d’une ancienne Eprom pour une plus rapide entraîne à nouveau des problèmes trop difficiles à résoudre avec RV1 [et tu as également raison pour les problèmes liés au changement de microprocesseur]. Pour l’Eprom 16K que tuavais mis dans ton Microdisc, si tu ne l’as pas ́recycléeª, peux-tu regarder si c’était une 27128 ou un e27C128? J’ai vérifié de mon coté et mon Eprom marquée ́Bicedisª que j’avais shootée avec ton fichier pour faire cohabiter le Microdisc avec un émulateur de Telestrat sur Atmos (avec bascule entre Microdisc classique et émulation Telestrat par interrupteurs) est une 27C256 à 200ms. Et ça marchait

  • CEO-MAG 351-352

    Sommaire :

    04 John S. Sinclair Interview

    18 Interview de John S. Sinclair

    34 Journal de transferts : Zorgon’s Revenge (Demo Only)

    Edito

    IJK fut l’une des sociétés de production et de publication les plus emblématiques de l’Oric. A chacune de ses sorties, nous nous mettions à rêver et courions chez notre revendeur préféré (bien qu’il exista déjà un monde parallèle dans les cours de lycée) pour acquérir la perle encensée par les magazines de l’époque ; Tilt en tête. Steve avait soulevé un coin du voile voici 15 ans déjà. Avec ces articles fabuleux, remplis d’anecdotes, Simon nous propose un CEO-MAG hors du temps qui comblera également les anglophones. Un numéro hors pair qui figurera en bonne place dans ma bibliothèque. Merci Simon. Bonne découverte. Didier

    [wpdm_package id=’2626′]

    [wpdm_package id=’2624′]

    [wpdm_package id=’2662′]

    Téléchargement ouvert à tous

  • Exclusive : An Interview of John S. Sinclair

    Hi, Andre, I’ve been contacted by John Sinclair, who wrote Xenon 1 etc for IJK. Got some interesting information from him and so I asked if he would be willing to do an interview for CEO. He accepted. I’ll cut and paste some of the interesting stuff below. Regards, Steve M.

    (Xenon-1 cassette labels – refers to my Collectors Corner articles)

    From John Sinclair

    Sorry to be the bearer of bad news, but the IJK labels changed from black or blue on white to silver when we made more money and could afford more expensive labels. 9 King street was our first address.

    The pre-production sample of Zorgon is indeed a rare beast. Duplidata was an associated company to IJK. There would have been about 10 produced and some were sent to reviewers in plain boxes. You must have one of these.

    For your info, both Xenon and Zorgon were crossassembled and downloaded to the Oric using a BBC micro with a torch disk drive unit. I was 16 at the time, and getting rather tired of doing games, after a long career of writing BBC games !!!
    My first program was for the Tangerine, a UK ´Appleª made by some of the people that formed Oric.

    [Next …]

    The silver ones were later, when we started to manufacture the cassettes ourselves. They were self-adhesive so we didn’t need a machine to put them on. This is probably why they look early. They probably even rarer, cause we got a machine eventually and I think they went back and white again. The address is the give away. We sold 120,000 copies so plenty of money was made.

    We put all our money into a company called Duplidata as tax was 60% back then, who eventually duplicated disks and distributed for all the big names. I then put mine into Tetra Systems to make stuff for people with disabilities, I then merged with SRS Technology to do the same thing. We floated on Aim two years ago. So not too bad.

    The thing I learned from an early age is the value of a good royalty agreement. I work part time for them now, designing home control hardware (mainly for the fun of it).

    We always cross-compiled our games. It gave a distinct advantage working on new hardware. People forget when seeing Xenon now, when in the life of the Oric it was created. There were no details of firmware or hardware available to us. Oric were linked with Tansoft. This is where the single button thing came from. We found a memory location that changed when the keyboard scan had finished, we used that.

    However Xenon caused quite a stir, and I was whisked down to Oric and given ‘royal’ treatment. Even had a ride in the famous Ferrari. I had a crush on Rosalind Zawadska who was assigned to ‘look’ after me. That’s where Princess Roz came from in Zorgon.

    All Oric were developed on the Beeb. I then went onto C64 games, that were developed on the first PC with a hard drive PC XT. I’m looking for the source code now. I have all the PC stuff (C64), but the Beeb disks I think have gone. I have the original framed art work for the inlays somewhere.

    The movement was smooth because we created 6 animated icons slightly shifted to give pixel movement. This also took up a big chunk of memory, so it wasnít possible to make the games quiet as large and playable as I would have liked. We were also one of the first companies to realise the value of a good game intro and game inlay, as this was just about the only bit of a game that would be seen in a computer dealer. Current games have now taken this to the max.

    If you look at the logo, you’ll find IS JS KS. I’m JS, my uncle Ian is IS and my dad Keith is KS, we were ‘IJK’ the company.

    Glad you enjoyed them. I don’t mind reliving those days one bit. They were FUN!!!

    Cheers
    John S Sinclair

  • FDC 1793 et Read Track

    Par Simon

    Ou l’aventure des déboires avec les disquettes, partie 1 d’une possible longue série !

    Quel est le besoin ?

    Depuis quelques années me tourne en tête l’idée d’un outil de transfert de disquettes Oric vers PC. Readdsk est déjà très puissant sur PC, mais l’idée est d’utiliser le matériel Oric à la fois pour les non-bricoleurs qui ne voudraient pas désosser un drive 3 pouces et le brancher dans un PC, mais aussi parce que seuls les PC vieillissants sont encore capables de gérer un lecteur de disquettes. Savedisk, sorti en 2005 (cf. CEO-Mag n° 182, de juin 2005), répondait en partie à cette idée en permettant de lire, secteur par secteur, une disquette Sedoric, puis de la sauver sur PC par… Le port cassette ! Et ensuite de refaire un fichier .DSK pour émulateurs.

    L’idée suivante était de rendre cet outil universel, en faisant en sorte qu’il ne se préoccupe pas du système de la disquette lue (Sedoric, Randos, Oric Dos, Stratsed, FTDos, XL-Dos, …). Il existe une commande au niveau du contrôleur de disquette du Microdisc (le FDC 1793), qui permet de lire une disquette piste entière par piste entière, indépendamment du format. Cela permet d’embarquer tous les secteurs et toutes les informations entre les secteurs, d’un seul coup, et donc a priori de gérer tous les DOS possibles tant que l’on trouve un moyen de gérer le nombre de pistes et de faces.

    La galère commence

    Las ! En testant cette commande (avec un gros coup de pouce de Fabrice), je me suis vite rendu compte d’un problème: a priori aléatoirement, des octets de valeur $C2 s’inséraient dans les données, voire les écrasaient. Cela ruinait la fiabilité. Pensant à un problème matériel (drive, disquette ?), j’ai varié les sources: drives 3″ ou 3.5″, test lors d’une visu sur du matériel de Thierry… Sans résultat probant: toujours des dizaines ou centaines de $C2 !

    Pourtant, j’étais très intrigué car Nibble, l’éditeur de disquettes, est capable de lire et copier piste par piste, sans erreur. En regardant une piste dans Nibble et en comptant (un par un…), je pouvais voir beaucoup moins de $C2 que lorsque je faisais la lecteur moi-même… Quant à Euphoric, il rend une lecture parfaite de la piste.

    Mais c’est quoi ce bazar ?

    Passablement découragé, j’ai sollicité tranquillement les forums Oric, et au fil du temps et des d’échanges, a émergé une analyse d’un “bug” sur le contrôleur de disquette Atari ST (par Claus Brod), utilisé pour protéger des disquettes contre la copie. Il ressemble furieusement au problème sur Oric !

    Schématiquement, lorsqu’il lit une disquette piste par piste, le contrôleur est en permanence à la recherche d’octets de synchronisation sur la disquette. Ces octets de synchro forment une suite de bits qui permet au contrôleur de caler le démarrage de sa lecture d’une piste. Comme il ignore la longueur d’une piste, le contrôleur sera en permanence ” à l’écoute” de cette séquence pour savoir si une nouvelle piste démarre.En détail, voici les différentes synchro qui existent sur une disquette:

    • IAM – Index Access Mark (C2C2C2FC) marking the start of a track
    • IDAM – ID Access Mark (A1A1A1FE) marking the start of a header field (Sector ID)
    • DAM – Data Access Mark (A1A1A1F8 or A1A1A1FB) marking the start of a Data field (Sector)

    Les C2 et A1 sont de plus, si j’ai bien compris, enregistrés sur la disquette avec une petite erreur volontaire, pour les démarquer d’octets de données.

    Mais malgré cette précaution, une séquence de bits de synchro peut être présente au beau milieu des données d’un secteur, à partir d’une combinaison d’octets qui n’ont rien à voir. Et elle peut tromper la lecture qui va penser déceler un octet de synchro ! Sur Atari ST, c’est la séquence 000101001 qui serait en cause; je n’ai pas vérifié sur Oric.

    Ce bug ne se produit pas avec les commandes de lecture par secteur (lesquelles ne recherchent pas de synchro piste !).

    Voilà a priori l’origine des $C2 aléatoires ! Euphoric n’a pas ce problème car j’imagine que la lecture d’un fichier DSK sur le PC ne nécessite pas ce décodage bas niveau.

    Magic Nibble

    Et Nibble alors, pourquoi les $C2 sont moins visibles ?

    Eh bien, Dominique m’a transmis il y a quelques mois une photocopie du manuel de Nibble. Ce dernier montre que ses auteurs ont bien rencontré des difficultés dans la lecture par piste, et explique le contournement du problème: la piste est lue, mémorisée, puis chaque secteur de la piste est relu individuellement. Cette lecture par secteur remplace celle faite en mode piste ! Ainsi les données des secteurs sont épargnées par les $C2 parasites.

    Voilà la solution d’un mystère… Et une piste (sans jeu de mots !) pour poursuivre le copieur de disquettes universel sur Oric ? A noter que sur Jasmin, qui utilise un autre FDC (FDC 1770), le problème serait identique, mais je n’ai pas vérifié !

    Documents expliquant le mystère de la commande Read Track sur Atari ST:

  • CEO-MAG 350

    Sommaire :

    • 2 LA VISU DE L’ÉTÉ
    • 4 REVUE DES BELLES LETTRES
    • 6 COLLECTION HIRES
    • 7 PUBLICITÉ
    • 8 FONCTIONNEMENT DE LA PILE MATÉRIELLE DU 6502 (4)
    • 13 QUELQUES BLAGUES
    • 14 MECCANO – MAN

    Edito

    C’est l’été, les vacances approchent ou ont commencé pour certains. Les différents articles du mois devraient permettre à chacun de passer de bonnes vacances ( Nous sommes à la moitié de la saga proposée par Yann ; et nul doute que les programmeurs en herbe pourront déjà utiliser toutes les techniques détaillées autour de la pile du 6502. Pour la sieste, les 12 disquettes d’écran hires compiliées par André permettront de somnoler devant les plus beaux écrins Oric. Enfin (et je ne l’avais pas dans mes tap en stock), vous pourrez pour le dessert analyser les 3 pages de listings de Meccano scannées par Steve. A noter que le jeu (en tout cas le tap) n’est pas 100% compatible avec l’Atmos ; du fait de la fonction PLOT. A privilégier sur une config Oric1. Bonnes vacances. Didier

    [wpdm_package id=’2628′]

    [wpdm_package id=’2629′]

    [wpdm_package id=’2660′]

  • Fonctionnement de la pile matérielle du 6502 (4/8)

    PARAMÈTRES ET SOUS-ROUTINES

    L’entrée et la sortie de données nécessaires au fonctionnement d’une sous-routine, peut se dérouler de quatre façons :

    1. En passant par les registres (A, X et / ou Y). C’est la meilleure méthode et la plus performante lorsqu’il s’agit de données constituées d’un ou deux octets
    2. En passant par des variables en RAM. Cette méthode est parfaite pour des données qui doivent rester en RAM et qui doivent servir à d’autres routines. Elle est souvent utilisée de manière conjointe à la première méthode.
    3. Les besoins en entrées de la sous-routine peuvent être intégrés au programme lui-même, juste après l’instruction JSR (comme par exemple une chaîne alphanumérique à afficher). Dans ce cas, la sous-routine utilise l’adresse de retour stockée sur la pile en guise d’adresse de début des données. Elle peut aussi utiliser un octet qui détermine le nombre de données ou un délimiteur afin de savoir de combien d’octets avancer l’adresse de retour avant d’exécuter l’instruction RTS (et d’éviter que le processeur ne traite les données comme une instruction).
    4. En passant par la pile matériel.
      • Pile en page 1 : le programme appelant empile la (ou les) données grâce à PHA, puis récupère le (ou les) résultats grâce à PLA, au retour de la sous-routine.
      • Pile virtuelle en page 0 : Idem précédemment, avec une pile de données différentes de la pile matérielle, ce qui peut faciliter certaines opérations sur la pile et l’adressage indirect. Par exemple, la pile de données peut être utilisée dans un processus en plusieurs étapes pour calculer une adresse, adresse qui à son tour peut être utilisée pour un accès indirect à un octet dans un tableau pour faire un calcul ou une opération logique.
      • Pile en RAM : Idem pile virtuelle en page 0, mais pouvant typiquement servir pour des nombres en virgule flottante autres que des adresses nécessitant les modes d’adressage disponibles en page 0.

    Examinons un exemple dans lequel il s’agit d’utiliser la pile matériel pour une donnée d’entrée. Dans cet exemple, notre sous-routine transforme un demi-octet hexadécimal en octet ASCII, avec un octet en entrée et un octet en sortie, le tout stocké sur la pile matériel.

    <do_stuff>      ; Get the nybble into A.  Allowable value is 0-F.
    PHA             ; Other code can be put between the PHA and the PLA, as long
    JSR  NYB2ASCII ; as it doesn't care if NYB2ASCII overwrites A and X. The
    PLA             ; subroutine's input and output are protected on the stack though.
    <do_stuff>      ; Do something with the ASCII output, like add it to a string, display it, etc..

    La sous-routine NYB2ASCII pourrait ressembler à ceci.

    NYB2ASCII:

    TSX

    LDA  $103,X     ; 103 reaches past the return address, to the input parameter.

    CMP  #$0A       ; Anything below $0A will end up in the $30’s.

    CLC             ; CLC before the BMI so we only have to do it once.

    BMI  n2a1       ; For 9 or less, skip the next instruction.

    ADC  #7         ; $0A becomes $11, $0B becomes $12, etc..  C is still clear.

     n2a1:  ADC  #$30       ; Whether the 7 got added above or not, this gives the ASCII.

    STA  $103,X     ; Put it on the stack, overwriting the input value.  Note

    RTS             ; that we read and overwrote the byte just behind the

    ; return address, leaving the return address undisturbed.

    Voici un autre exemple dans lequel deux nombres de 16 bits non signés en entrée sur la pile, sont multipliés pour donner un nombre de 32 bits non signé, en sortie sur la pile.

    On empile tout d’abord les deux nombres à transformer, chacun avec le poids fort en premier, de sorte que le poids fort prenne l’adresse la plus haute comme dans le fonctionnement habituel du 6502.

    <do_stuff>     ; Get high byte of first input,

    PHA            ; and push it.

    <do_stuff>     ; Get low  byte of first input,

    PHA            ; and push it.

    <do_stuff>     ; Get high byte of second input,

    PHA            ; and push it.

    <do_stuff>     ; Get low byte of second input,

    PHA            ; and push it.

    JSR  UM_STAR   ; Now you can call the subroutine below that does the multiplying.

                   ; If you pull the product off the stack now, the byte order will be:

    PLA            ; 2nd-highest byte

    <do_stuff>

    PLA            ; high byte

    <do_stuff>

    PLA            ; low byte

    <do_stuff>

    PLA            ; 2nd lowest byte

    <do_stuff>

    Selon les opérations que vous souhaitez réaliser ensuite, vous pouvez très bien laisser le premier résultat sur la pile.

    Si l’opération après la multiplication des deux nombres est de calculer la racine carrée pour en obtenir la raison géométrique, alors il convient de ne pas toucher à la pile tant que cette seconde opération n’est pas effectuée (la raison géométrique équivaut à une moyenne logarithmique. La raison géométrique de 1 et 100 est de 10, et non de 50,5).

    Pour accéder aux données stockées sur la pile sans les dépiler et dans l’ordre de votre préférence, vous pouvez continuer d’utiliser X comme index de pile (ainsi que décrit dans l’exemple UM_STAR ci-dessous). En cas de TSX, vous devrez ajuster l’index en tenant compte du fait que l’adresse de retour n’est plus sur la pile, et comme décrit ci-après, qu’un PLA a déplacé les résultats sur la pile de $101,X à $104,X. Par contre, sans TSX l’index est toujours valide et pointe bien sur les bonnes données.

    UM_STAR: LDA #0                 ; Unsigned, mixed-precision (16-bit by 16-bit input, 32-bit output)

             PHA                    ; multiply.  Add a variable byte to the stack, initializing it as 0.

             TSX                    ; Now 101,X holds that new variable, $102,X and $103,X hold the return address

             LSR $107,X             ;and $104,X to $107,X holds the inputs and later the outputs.

             ROR $106,X

             FOR_Y  16, DOWN_TO, 0  ; Loop 16x.  The DEY, BNE in NEXT_Y below will drop through on 0.

                 IF_CARRY_SET

                     CLC

                     PHA            ; Note that the PHA (and PLA below) doesn’t affect the indexing.

                        LDA $101,X

                        ADC $104,X

                        STA $101,X

                     PLA

                     ADC $105,X

                 END_IF

                 ROR

                 ROR $101,X

                 ROR $107,X

                 ROR $106,X

             NEXT_Y

             STA $105,X

             PLA                    ; Retrieve the variable byte we added at the top, cleaning up the stack.

             STA $104,X             ; Again note that the PLA changed S but not X, so the $104 is still $104.

             RTS

    Note : Dans de nombreux cas, il serait plus judicieux de nommer les données présentes sur la pile, en utilisant la macro EQU, plutôt que de se contenter de $101,X ou équivalent.

    Supposons maintenant que vous ayez besoin d’une sous-routine avec quatre octets en entrée et six octets en sortie.

    Afin de servir de la pile matérielle pour deux données supplémentaires en sortie, il faut donc résoudre le problème de l’adresse de retour qui ne sera pas en haut de la pile lors du RTS.

    La meilleure méthode consiste à faire de la place sur la pile avant d’appeler la sous-routine :

    PHA              ; Push two dummy bytes onto the stack to hold the

    PHA              ; positions open for outputs of the subroutine called below.

    <do_stuff>       ; Prepare the subroutine input bytes to be passed.

    JSR  subroutine  ; Without changing the stack pointer, the subroutine

    ; can now give you two more bytes of output than input.

    Autre cas pratique, celui où vous auriez besoin de plus de données en entrées qu’en sortie.

    Dans ce cas, il suffit de dépiler les données inutiles après être sorti de la sous-routine.

    Ainsi, pour restaurer la hauteur de pile, faites :

    <do_stuff>        ; Set up inputs, reserve output byte places in stack, etc..

    TSX               ; Mark the current stack position.

    <do_more_stuff>

    JSR  <subroutine>

    <do_stuff>        ; Handle outputs, etc..

    TXS               ; Restore stack to the marker set earlier, possibly also

    ; to put certain outputs at the top.

    Évidemment le registre X ne devra pas être modifié par la sous-routine, ou alors il faudra le sauvegarder à son tour sur la pile.

    Comme décrit précédemment, la pile matériel n’est pas la seule solution en tant que pile de stockage. Une pile en page zéro (ZP) présente par exemple l’avantage de disposer de modes d’adressages supplémentaires.

    Utiliser une autre pile que la pile matériel permet aussi de résoudre le problème suivant : admettons que la pile matériel en page 1 serve pour passer des paramètres à une sous-routine qui elle-même doit fournir des paramètres à autre sous-routine. Lors de l’entrée dans la seconde sous-routine, l’adresse de retour se retrouve donc désormais au sommet de la pile, tandis que les données d’entrée sont décalées vers le bas, ce qui donnera à coup sûr des résultats erronés.

    Mettons en œuvre cet exemple avec la sous-routine GEOMEAN.

    GEOMEAN: JSR  UM_STAR  ; Multiply two 16-bit unsigned inputs on the stack.  Get 32-bit product.

             JSR  SQRT     ; Take a 32-bit input on the stack and get a 16-bit output, leaving two

             RTS           ; dummy bytes on stack (problem: GEOMEAN’s return addr is still on top!)

    Supposons que vous commenciez par empiler $1234 sur la pile matériel (poids fort en premier, sur le dessus de la pile), puis que vous empiliez $5678 avant d’appeler la sous-routine GEOMEAN.

    Lorsque le pointeur de programme attend la première instruction après PHA et TSX dans le programme UM_STAR, UM_STAR part à la recherche du premier nombre à multiplier ($1234 dans notre exemple), censé se trouver aux adresses $106,X et $107,X, puis du second nombre ($5678 dans l’exemple) qui se trouve aux adresses $104,X et $105,X. L’adresse de retour se trouve quant à elle indexée par $102,X et $103,X.

    Il y a cependant maintenant deux adresses de retour au sommet de la pile : celle qui a fait appel à UM_STAR et celle qui a fait appel à GEOMEAN. UM_STAR va donc ignorer $1234 et multiplier $5678 avec l’adresse de retour de GEOMEAN, entraînant ainsi un résultat erroné et l’écrasement de l’adresse de retour de GEOMEAN. C’est le plantage assuré !

    Vous vous apercevez également que le fait d’utiliser JMP au lieu de la paire d’instruction JSR / RTS peut entraîner des problèmes d’incompatibilité liés à une mauvaise gestion des données empilées sur la pile matériel.

    La pile en page zéro permet de contourner ce genre de problème, tout simplement parce que l’adresse de retour n’est pas empilée sur cette dernière.

    En plus de l’adressage de la page zéro qui est plus performant que celui de la pile matériel, signalons aussi les bénéfices suivants :

    • Inutile de replacer les paramètres d’entrée sur la pile sans arrêt, avec pour résultat immédiat une exécution plus rapide des étages de la pile ;
    • Réduction des effets liés à la récursivité (ce sujet sera abordé dans un prochain article) ;
    • Possibilité de placer plusieurs type (et quantité) de valeurs ;
    • Code plus compact qui permet un meilleur fonctionnement car plus besoin de devoir empiler/dépiler des paramètres lors de l’appel de sous-routines.

    Revenons maintenant à notre sous-routine qui transforme un demi-octet hexadécimal en octet ASCII et voyons comment réaliser cette transformation en utilisant une pile ZP.

    X servira de pointeur de pile, initialisé en début de programme pour indexer de la manière suivante $00,X.

    Pour empiler en page zéro, il faut donc faire un DEX puis stocker en $0,X.

    Voici ce que donne la routine modifiée pour la pile ZP :

    <do_stuff>      ; Get the nybble into A.  Allowable value is 0-F.

    DEX

    STA  0,X        ; Other code can be put between the STA and the LDA, and

    JSR  NYB2ASCII  ; NYB2ASCII’s input and output are protected on the stack.

    LDA  0,X        ; X must be preserved as the data stack pointer of course.

    INX

    <do_stuff>      ; Do something with the ASCII output, like add it to a string, display it, etc..

    Note : Si vous avez besoin du registre X dans le reste de votre programme, il vous faudra le sauver sur la pile matériel.

    La sous-routine NYB2ASCII devient :

    NYB2ASCII:              ; (The initial TSX is no longer necessary.)

            LDA  0,X        ; Get the input parameter from the data stack.

            CMP  #$0A       ; Anything below $0A will end up in the $30’s.

            CLC             ; CLC before the BMI so we only have to do it once.

            BMI  n2a1       ; For 9 or less, skip the next instruction.

            ADC  #7         ; $0A becomes $11, $0B becomes $12, etc..  C is still clear.

     n2a1:  ADC  #$30       ; Whether the 7 got added above or not, this gives the ASCII.

            STA  0,X        ; Put it on the data stack, overwriting the input value.  Note

            RTS             ; that the return address is not on this stack to worry about.

    Procédons selon la même logique pour la sous-routine UM_STAR.

    UM_STAR: DEX                    ; Add a stack byte to use as a temporary variable.

             LDA  #0

             STA  0,X               ; 0,X addresses the temporary variable.  These are in ZP.

             LSR  4,X

             ROR  3,X

             FOR_Y  16, DOWN_TO, 0

                 IF_CARRY_SET       ; The 1st time thru the loop, A needs 0; so don’t use STZ above.

                     CLC

                     PHA

                        LDA  0,X

                        ADC  1,X

                        STA  0,X

                     PLA

                     ADC  2,X

                 END_IF

                 ROR

                 ROR  0,X

                 ROR  4,X

                 ROR  3,X

             NEXT_Y

             STA  2,X

             LDA  0,X

             STA  1,X

             INX                    ; Take back the stack byte we used as a temporary variable.

             RTS

     ;——————

    Ici, un octet est empilé sur la pile ZP grâce à l’instruction DEX (puis dépilé grâce à INX), de la même manière que pour PHA (puis PLA). La pile ZP permet donc d’éviter d’avoir à sauver/restaurer l’index X.

    Il est en outre possible de se passer des instructions DEX/INX en adressant le nouvel octet grâce à $FF,X qui permet de rester en page zéro et qui économise au passage 2 octets et 4 cycles d’horloge.

    Assurez-vous cependant de n’avoir aucune sous-routine ou interruption susceptible d’écraser cet octet, car X semble indiquer que cet emplacement est libre.

    La sous-routine GEOMEAN quant à elle, peut désormais s’écrire :

    GEOMEAN: JSR  UM_STAR  ; Multiply two 16-bit unsigned inputs on the stack and get a 32-bit product.

             JMP  SQRT     ; (JSR, RTS)  Take a 32-bit input on the stack and get a 16-bit output.

     ;——————

    Voici dans le détail les avantages à travailler avec des piles séparées :

    • Le nombre d’octets entrés est indépendant du nombre d’octets sortis. En d’autres termes, nul besoin de nettoyer les octets de sortie factices ni de placer des octets factices sur la pile ;
    • En disposant de données séparées, les adresses de retour ne sont pas traitées comme des données. Le paramétrage devient implicite ;
    • Une sous-routine peut faire appel à une autre sous-routine sans avoir à faire le ménage sur la pile matériel (qui devient désormais la pile de retour) ;
    • La pile matériel est maintenant disponible pour d’autres usages tels que la gestion des limites et des index de boucles (y compris des boucles imbriquées) ;
    • L’ajout d’une nouvelle pile permet d’augmenter l’espace de stockage et d’éviter un crash sur la pile matériel ;
    • Grâce aux modes d’adressages du 6502 en page zéro (ZP,X), nous pouvons adresser la pile ZP très facilement.

    Voyons justement comment mettre à profit les modes d’adressage ZP,X dans l’exemple de routine de déplacement suivante.

    Nous appellerons cette routine CMOVE, pour “character move”.

    Avant de faire tourner cette routine, nous plaçons six octets sur la pile ZP, sous la forme de 3 nombres de 16 bits (poids fort sur l’adresse la plus haute dans chaque cas) :

    • Adresse de départ
    • Adresse de destination
    • Taille de mémoire à déplacer (pouvant aller jusqu’à quelques dizaines de milliers d’octets)

    CMOVE:  LDA  0,X      ; “See-move” Character (memory) move  ( from to len — )

            ORA  1,X

            BEQ  POP3     ; If remaining length is 0, branch to POP3 which is just 6 INX’s, then RTS.

            LDA  (4,X)    ; Get a byte and

            STA  (2,X)    ; transfer it.

            INC  4,X

            BNE  cm1$

            INC  5,X      ; Increment the source addr

     cm1$:  INC  2,X

            BNE  cm2$

            INC  3,X      ; and the destination addr,

     cm2$:  DEC  0,X      ; decrement the count left,

            LDA  0,X

            CMP  #$FF

            BNE  CMOVE

            DEC  1,X

                          ; and go back up for another loop.  If we’re done,

            BRA  CMOVE    ; that fact will be caught in the first three lines (BRA is for 65c02 only and stands for Branch Always).

    Quand faut-il éviter l’emploi d’une pile pour l’usage de paramètres d’entrées / sorties dans des sous-routines ?

    Déplacer des données dans une pile requiert du temps processeur.

    Aussi, si vous devez manipuler une grande quantité de données, comme une chaîne alphanumérique, un tableau ou même une matrice, placez là ailleurs en mémoire et indiquez son adresse de stockage sur la pile.

    RÉCURSIVITÉ

    Une sous-routine peut présenter la particularité d’être récursive, à savoir qu’elle peut s’appeler elle-même à de nombreuses reprises.

    Afin d’éviter que ce genre de sous-routine ne reboucle indéfiniment, entraînant une surcharge de la pile matériel, il faut prévoir une condition qui permette de quitter la sous-routine au bout de x boucles récursives.

    Lorsque cette (ou ces) condition(s) est respectée, on quitte alors la sous-routine par une série de RTS.

    Chaque sous-routine nidifiée (imbriquée) peut disposer de ses propres variables ayant  pourtant des noms semblables.

    Prenons l’exemple de la fonction de Fibonacci qui est utilisée en calculs financiers, lors de la génération de nombres pseudo aléatoires, dans des algorithmes de tri et de recherche ou encore pour la compression de fichiers audio.

    fiboIO:    SETL $103    ; For clarity, give names to the locals.

    fiboTemp:  SETL $102    ; (Record of X will be at $101,X.)

    FIBO:  CMP  #2          ; Test the input.

           BCC  end         ; If it’s 0 or 1, so is the output, so just end.

                            ; This prevents endless nesting, too.  Otherwise,

           PHA              ; create local variable fiboIO, and store A there.

           PHA              ; Create another local variable byte, fiboTemp.

                            ; (Its initial value doesn’t matter.)

           PHX              ; Push X too, to protect the calling routines.

           TSX              ; Prepare X to use for stack-relative addressing.

           DEA              ; Get the n-1 term

           JSR  FIBO        ; and calculate the number for it (recursing here)

           STA  fiboTemp,X  ; and store its result in local variable fiboTemp.

           LDA  fiboIO,X

           DEA

           DEA              ; Now get the n-2 term

           JSR  FIBO        ; and calculate the number for it (recursing here).

           CLC

           ADC  fiboTemp,X  ; Add those two together, and

           STA  fiboIO,X    ; store the answer.  Don’t forget the “,X”!

                            ; Note that there is no looping.

           PLX              ; Restore X for the calling routines.

           PLA              ; Pull fiboTemp off the stack and discard it.

           PLA              ; Pull the answer (fiboIO) off the stack into A.

    end:   RTS

    Cette sous-routine tient sur 34 octets et n’utilise pas la RAM pour le stockage, hormis bien sûr la pile matériel.

    La donnée d’entrée doit rester inférieure à 14 car la donnée de sortie est sur 8 bits et le nombre de Fibonacci pour 13 est 233.

    Avec une réponse sur deux octets ou plus, nous pourrions avoir une donnée d’entrée plus grande sans manquer de place sur la pile, même si ce genre de sous-routine en consomme beaucoup.

    La place disponible sur la pile est largement suffisante pour des sous-routines simples, mais rappelons que les routines récursives ne sont pas des routines normales.

    À suivre.

  • CEO-MAG 349

    Sommaire

    • 2 VISU D’ETE
    • 4 CHARGEMENT CASSETTE : NOVALIGHT V1.2A
    • 7 PUBLICITÉ
    • 8 LES CLONES DE PAC-MAN SUR ORIC (FIN)
    • 12 TESTEUR DE DRAM 4164 POUR ORIC
    • 14 FONCTIONNEMENT DE LA PILE MATÉRIELLE DU 6502 (3)
    • 17 BLAGUES, HOMMAGE À PIERRE DAC (5)
    • 18 FROGGER, LE TAPE-INS DU MOIS
    • 22 LA VISU HIVERNALE EN IMAGES
    • 25 QUELQUES BLAGUES

    Edito

    André est décidément incontournable. il maintient en éveil de nombreux Oriciens avec ses articles toujours précis et propices à nous faire découvrir de nouvelles facettes de notre ordinateur préféré ; mais en plus c’est un de nos gamers les plus avertis. Il nous a de nouveau gratifié de 2 high scores ce mois-ci. Bravo André. L’été approche, vous allez pouvoir prendre vos Orics pour aller à la plage et programmer, jouer, souder. Mais il vous faudra aussi prendre votre PC (ou votre MAC) pour écrire les articles de la rentrée et participer à ce mag qui prend de plus en plus de place dans ma bibliothèque.

    [wpdm_package id=’2630′]

    [wpdm_package id=’2632′]

    [wpdm_package id=’2658′]