Comment la rom basic sur la Twilighte board permet de démarrer beaucoup de soft atmos, mapper sans aucune configuration les joysticks et démarrer des softs qui sont censés démarrer uniquement avec un microdisc ? C’est ce que nous allons voir dans cet article.
Définitions
Une banque est un emplacement mémoire en EEPROM ou en RAM qui est annoncé en $C000 à $FFFF
Nous appelerons “ROM” une ROM sous un format .rom stockée sur le stockage de la twilighte board qui est chargé dans une banque.
La commande basic11 est une commande Orix qui va charger en banque un .rom et lancer cette ROM
Crédits
Les ROMS atmos, Oric-1 supportant les joysticks, et faisant le hook vers les storages de la Twilighte board ont été réalisés par Assinie. Les détails du code sont donc explicables par Assinie pour cette partie.
La commande basic11 a été écrite par moi même et ne fait que passer des “arguments” à la ROM pour lui dire comment se comporter. C’est surtout cette partie qui est décrite ici, car c’est celle que je connais le mieux et c’est aussi la partie la plus simple à réaliser au niveau code, par rapport à la ROM atmos où il a fallu composer avec les contraintes de softs. Les fonctionnalités décrites dans cet article ont été présentées en janvier 2020 à la visu online. Cela a fait l’objet de démos des fonctionnalités, mais aucune explication a été fournies par manque de temps. Voici les concepts.
Concepts de la carte ‘Twilighte board’ et d’Orix
Cela fait de nombreuses années que je voulais à la fois avoir un Oric plus puissant, un OS type Linux/Unix, et la possibilité de tout démarrer sans avoir la table remplie de fils d’extensions ajoutée sur l’oric avec en plus son lot d’incompatibilités. A vrai dire, c’est au moins depuis les années 1999/2000 de mon coté que je voulais un oric plus puissant !
La carte et l’OS sont donc une convergence de plusieurs projets (plutôt des tentatives) :
- En 2006, démarrage d’un OS type unix : Le device de la disquette était un mauvais choix, car j’avais commencé un formatage type Minix, mais ce n’était pas viable pour la lenteur, et le fait de voir “Lunix” sur disquette a montré que cela pouvait être long
- En 2009, démarrage de la lecture sdcard en SPI, trop long, non viable sur l’oric pour le même problème de lenteur.
- En 2012, une interface joysticks : oui mais pourquoi faire ? Les jeux ne sont pas compatibles pour la plupart, et si on collait à une interface particulière, il faudrait patcher tous les softs.
Finalement, la volonté de vouloir tout démarrer sur l’atmos sans rentrer dans toutes les contraintes techniques a donc dirigé ce choix : avoir un OS “chapeau” qui est capable de tout piloter et éviter d’avoir une rom atmos standalone, avec toutes les contraintes associées.
Un mode rom Atmos “normale”
Quand on lance en ligne de commande, la commande basic11 sans argument, le code va lancer la banque 6 qui contient une rom “normale” atmos modifiée pour avoir des hooks de la lecture cassette soit sur clé usb ou soit sur sdcard. Ce mode a aussi des hooks par défaut de joysticks qui va en fonction des directions appuyées va donner à la ROM des informations sur ce qui a été appuyé, et donc le curseur peut ainsi bouger simplement sans aucun code avec les joysticks. Le fonctionnement est identique à basic10 (qui lance la rom oric-1)
Un hook de lecture K7 va prendre toutes les actions de cload et csave, et au lieu d’aller lire sur le VIA6522, le code va aller lire et écrire les .tap qui se trouvent dans /home/basic11/ (ou /home/basic10 dans le cas de la rom oric-1).
Sur oric.org, chaque download a un flag indiquant ce que c’est. Si c’est un .tap pour atmos, nous avons les flags ‘A’ pour atmos, et ‘K’ pour K7. Si le .tap est uniquement Oric-1 alors, nous aurons les flags ‘OK’
Mode ROM atmos “jeu”
La ROM jeu n’est pas véritablement accessible en ligne de commande. Elle peut être chargée dans une banque en RAM ou en ROM par exemple avec orixcfg (outil qui permet de programmer les banques eeprom ou ram), mais elle est surtout lancée à la volée de deux manières (c’est à dire que les 16KB de la ROM sont chargés en $C000 à $FFFF:
lancement avec un argument de .tap :
/#basic11 "MYTAPEQuand un paramètre avec un .tap est fourni (sans l’extension), la commande basic11 va trouver sur le device un fichier dans /var/cache/basic11/[lettre]/MYTAPE.db. C’est le fichier “db” unitaire au soft qui est généré dynamiquement avec www.oric.org puis inséré dans l’archive software.tgz par une moulinette quotidienne.
Si ce fichier existe, celui ci va être chargé et va charger un mapping joystick configuré s’il est présent : c’est à dire que si “MYTAPE”, qui est un jeu, qui utilise aussi la touche A pour aller à gauche, ce mapping va dire à la ROM que la gauche sur le joystick, c’est A qui est pressé.
Ce fichier MYTAPE.db contient aussi l’information de la ROM basic à lancer. Le cas le plus fréquent est la ROM jeu car elle est plus “compatible” que la ROM normale. A partir du moment où un fichier .db est trouvé, basic11 considère que le .tap est connu (et donc issu d’oric.org). Il va donc aller chercher le .tap dans /usr/share/[Lettre]/MYTAPE.tap. Ce path est généré à la volée par basic11 pour le fournir à la ROM jeu : La rom jeu est chargée dans une banque RAM, et à un offset particulier, le path est écrit pour que le cload (ou le mode auto de la ROM) démarre le bon .tap du bon path : La rom atmos a bien le path
Et si le fichier MYTAPE.db n’est pas trouvé ? Dans ce cas, basic11 va démarrer la rom normale basic, et charger MYTAPE.tap qui se trouve dans /home/basic11/
Rom “hobbit”
L’objectif du fonctionnement de l’atmos sur la carte n’est pas de modifier les .tap pour qu’ils fonctionnent sur le device concerné. L’idée est de présenter au .tap une ROM pour laquelle les éventuels appels à certains vecteurs en ROM de ce programme n’échouent pas. En effet, pour remplacer la lecture/écriture sur sdcard et clé USB, il a fallu faire des concessions, et couper des bouts de codes. Seulement, certains .tap prennent certaines libertés sur les vecteurs appelés, et peuvent donc appeler un vecteur touché par la modification de lecture sur sdcard. La plupart des cas, cela se résoud sur la ROM “jeu”. Mais pas tous …
The Hobbit pose un problème difficilement résorbable. C’est pourquoi il y a une ROM appelée ‘The hobbit’ qui peut démarrer ‘The hobbit’ sans modification. Cette Rom ne sert pas qu’à quelques softs tels ‘The hobbit’, ‘fireflash’ d’autres softs peuvent l’utiliser.
Quelle est la contrainte majeur de la rom “The hobbit” ? La contrainte est qu’il a fallu mettre le .tap de ‘the hobbit’ à la racine des devices pour qu’il soit chargeable car il n’est pas possible de forger le path dans la ROM atmos.
Pourquoi je peux charger des .tap de plus de 46KB en une seconde ?
Le chargement se fait en 46KB/sec, cela peut être plus long dans les cas des softs qui font du calcul juste après le démarrage. C’est à dire que le contrôleur usb a chargé 40 KB en 1 seconde, mais le programme se lance et peut par exemple faire une copie de DATA en RAM pour des routines asm par exemple.
L’idée aussi est que le contrôleur USB a des facilités de lecture de FAT32. A la base, c’est un vrai contrôleur USB, mais une partie de ses commandes servent à taper sur de la FAT32 en hardware. La ROM a du code très compact pour la lecture des fichiers sur la FAT32 et lit un bloc complet au lieu de lire octet par octet : c’est pour cette raison que le chargement est très rapide. Il n’est donc pas rare de charger les 16KB de la rom atmos, la copier ensuite en $C000 , et charger 48KB de jeu/démo.
Comment est fait le mapping des joysticks ?
Ce mapping est issu d’oric.org. Chaque fiche jeu dans la partie admin d’oric.org contient des champs pour demander quel est le code ascii qu’il faut presser pour aller sur la droite, la gauche etc.
Si les joysticks ne fonctionnent pas, les raisons les plus communes sont :
- Le jeu n’appelle par la ROM pour sa gestion clavier
- Le mapping du joystick n’est pas fait sur oric.org
Donc, une modification sur oric.org influe directement le comportement du jeu sur la twilighte board.
Pourquoi est il possible de démarrer des softs (démos, osid etc) qui ne peuvent fonctionner qu’avec un microdisc, alors que le microdisc n’est pas connecté ?
Certaines démos ont besoin de prendre les 16KB de la RAM overlay, mais ne font pas d’accès disque. Le firmware 2 de la Twilighte board définit un miroir du registre $314. Quand un code appelle donc le registre $314 pour passer en RAM overlay, le registre $314 miroir coté Twilighte board, va basculer sur sa RAM interne en banque 0 pour permettre le code de s’exécuter en RAM.
C’est pourquoi les démos “ripped”, et les fichiers OSID démarrent avec la ROM basic11 : une petite routine va se charger en page 4 à la volée au démarrage de basic11 : les quelques octets de swap en ram overlay, et les codes de musiques osid ou ‘ripped’ appellent ce vecteur en standard, pour démarrer sans problèmes !
Comment les fichiers .db sont générés ?
Une moulinette quotidienne est lancée : une pipeline github va interroger oric.org, et générer tous les fichiers.db et tous les fichiers.tap disponibles, pour les rendre à disposition.
J’ai bien compris le fonctionnement, mais comment fait on pour simplifier le chargement des .tap dispos sur oric.org ?
En tapant le menu “basic11 -g”, un menu va démarrer. Cela affiche tous les softs atmos disponibles issus d’oric.org, et en sélectionnant l’un d’entre eux, tout va être chargé automatiquement : la bonne ROM, le bon mapping joysticks etc
Dans quels cas, les .tap ne se lancent pas ?
Il y a eu un important travail à la fois dans la ROM mais aussi dans oric.org, pour régler beaucoup de problèmes, néanmoins certains jeux n’ont pas été traités. Il est techniquement possible de démarrer tous les .tap, mais il faut pour chaque cas récalcitrant trouver le facteur commun pour releaser une ROM compatible.
- Le fichier .tap n’est pas en autoexec : cela arrive sur certains .tap sur oric.org
- Le multipart fonctionne mais pas sur tous les cas de figure (certains fonctionnent néanmoins)
Que faut il faire pour ajouter plus de mapping joysticks sur les jeux qui ne fonctionnent pas avec les joysticks ?
Il faut des volontaires qui vont aller sur le jeu :), noter les touches clavier pour les directions, pour les reporter sur la fiche jeu d’oric.org. Par défaut, certaines touches sont configurées : la flèche du haut pour haut, la flèche du bas pour bas, mais beaucoup de jeux n’utilisent pas ces flèches.
Est ce techniquement possible de démarrer tous les .tap sur oric.org sans changer le hardware ?
Oui, c’est possible. La condition étant de trouver un compromis pour éviter de sortir une ROM par jeu. Et donc, si une nouvelle ROM permet de corriger 10 jeux, celle ci serait déclarée sur oric.org, et les fichiers .db y feraient référence aussi.
J’ai bien compris que basic11 était capable de lire sur sdcard ou usbdrive automatiquement, mais comment fait il ?
Orix sait quel est son device par défaut. Si le kernel est buildé pour avoir la sdcard en device par défaut, l’appel de basic11 sera sur sdcard, car basic11 donnera l’info à la rom atmos que le device par défaut est la sdcard. Si la commande “twil -u” est lancée, alors le kernel a connaissance que le device par défaut est la clé USB, et donc passera l’information à basic11 qui passera l’info à la ROM basic.
Mais au final qu’est ce qui est préférable de lancer ?
Si c’est pour jouer aux jeux Oric, ou tester des softs, il suffit de lance “basic11 -g” ou “funct + G”
Si c’est pour programmer, faire des tests de code, il suffit de taper “basic11” ou “funct + B” : toutes les sauvegardes seront dans le répertoire /home/basic11.
Enfin, si le but est de démarrer tout ce qu’on veut sans trop se poser de question, il faut démarrer le loader avec “funct + L”
Leave a Reply