[Thomson] SDDRIVE

[Daniel]

Je viens de faire l'essai avec la version 20180930 du contrôleur SDDRIVE.

L'appui sur le bouton d'initialisation permet le retour au Basic, mais comme je l'ai noté dans le post précédent les zones de travail de SDDRIVE sont remises à zéro, donc la disquette n'est plus sélectionnée.

On peut alors relancer le programme SDDRIVE.SEL par la commande EXEC &HA025 et choisir la même disquette que précédemment. Mais comme SDDRIVE.SEL utilise une partie de la RAM il écrase le programme, ou des données, ou la pile système, et le retour au BASIC se solde en général par un plantage.

Il y aurait une parade, mais j'ose à peine la proposer tellement elle est difficile à mettre en œuvre :
- Juste après la sélection initiale de la disquette, noter sur un papier les zones de travail de SDDRIVE obtenues par PEEK
- Plus tard, après l'Initial. Prog, restaurer les zones de travail par POKE
Ces zones sont $2051-$2054 et $2057-$2058 (6 octets).

Plus simplement, il faut sauver sur carte SD le programme que l'on vient d'écrire avant de lancer le test. Si le test se passe mal on éteint puis rallume l'ordinateur, on sélectionne le fichier .sd et on recharge le programme. C'est d'ailleurs ce que font toujours les programmeurs en assembleur, car avec ce langage une erreur peut provoquer des dégâts collatéraux et détruire le programme.

[Edit]
J'oubliais le plus simple : si le programme en cours de test est en BASIC, il n'est peut-être pas nécessaire d'utiliser le bouton blanc pour l'interrompre. En général on peut arrêter un programme BASIC avec CTRL-C. Dans ce cas le fichier .sd reste sélectionné et le programme est toujours en mémoire.

[OlivierH]

Merci déjà pour tes investigations

Plus simplement, il faut sauver sur carte SD le programme que l'on vient d'écrire avant de lancer le test. Si le test se passe mal on éteint puis rallume l'ordinateur, on sélectionne le fichier .sd et on recharge le programme. C'est d'ailleurs ce que font toujours les programmeurs en assembleur, car avec ce langage une erreur peut provoquer des dégâts collatéraux et détruire le programme.

C'est ce que je fais, mais ce n'est pas pratique. C'est pour ça que je demandais si la nouvelle version corrigeait le pb ^^

[Edit]
J'oubliais le plus simple : si le programme en cours de test est en BASIC, il n'est peut-être pas nécessaire d'utiliser le bouton blanc pour l'interrompre. En général on peut arrêter un programme BASIC avec CTRL-C. Dans ce cas le fichier .sd reste sélectionné et le programme est toujours en mémoire.

Oui, mais après le CTRL-C il faut aussi :
- appuyer sur raz (pour être sûr que que le curseur soit pas sur une ligne de texte)
- remettre des couleurs à peu près correctes (screen 4,6,6)
- réinitialiser la console (console 0,24)
- et éventuellement aussi les attributs de largeur/longueur de texte (attrib 0,0)

[Daniel]

Depuis le début du développement de SDDRIVE je me heurte toujours au même problème : le contrôleur a besoin de zones de travail en RAM (une douzaine d'octets environ), et il est très difficile de trouver des zones libres. Microsoft et Thomson ont déjà utilisé à peu près tous les emplacements disponibles.

Au début j'utilisais le bas de la piste système. Mais j'ai découvert que d'autres programmeurs avaient eu la même idée que moi, et certains jeux étaient incompatibles. J'ai alors utilisé des adresses plus hautes, toujours dans la pile système. D'où une nouvelle incompatibilité avec des programmes comme Space Project et TO8Demoded, qui utilisent abondamment les PSHS et PULS. Je me suis alors rabattu sur des zones de travail du contrôleur de disquette (la position des têtes de lecture), et là nouvelle déconvenue : Thomson se sert aussi de cette zone pour stocker deux octets lors de l'initialisation du système des TO8-TO8D-TO9+. J'ai évité d'utiliser ces deux octets et maintenant ça marche (à partir de la version 20180702 de l'EPROM). Sauf que le bouton d'initialisation remet ces zones à zéro, ce qui fait perdre l'accès au fichier .sd sélectionné.

La solution ultime serait d'avoir 12 octets de RAM dans le contrôleur SDDRIVE. Mais c'est une énorme complication, qui doublerait la taille et le prix. Je m'y refuse car je veux garder le système aussi simple que possible.

Une autre solution serait de modifier la procédure d'initialisation du MO5 pour qu'elle ne remette plus à zéro les 6 octets identifiant le fichier .sd sélectionné. C'est très simple pour moi, j'ai mis un support pour la ROM et je l'ai remplacée par une EPROM. Malheureusement très peu d'utilisateurs de MO5 sauront faire cette modification.

Donc, dans l'immédiat, sauvegardez vos programmes avant de les tester.

[jasz]

Peut-on lors de l'initialisation de SDdrive modifier les adresses S et U en les décalant de 15 octets. Si oui, cela permettrait de profiter de cet espace ainsi libéré. Mais, à mon avis, tu y as déjà pensé.

[Daniel]

On ne peut rien décaler, pratiquement toutes les zones disponibles dans la plage $2000-$20FF sont utilisées et la plupart sont remises à zéro lors de l'appui sur le bouton d'initialisation. Et, encore plus compliqué, il y a des différences d'une machine à l'autre : un octet libre pour le MO5 peut être utilisé par le TO8 et réciproquement. Il faut en tenir compte si on veut que le contrôleur fonctionne avec tous les ordinateurs.

J'ai beaucoup cherché et la solution retenue est un bon compromis. Il est peut-être possible de faire mieux mais pour l'instant je n'ai pas trouvé.

[jasz]

Tous les ordinateurs réinitialisent leur mémoire tampon après le RESET.
Sur atariST, le RESET modifiait la plage $0000-$1000 et pour déplomber certaines démos dont le programme souche se situait dans la plage $0500-$1000, j'avais trouvé une combine -> modifier le comportement du vecteur. C'est simple, il suffit de changer l'adresse de ce dernier vers une autre avec un programme de boot direct sur disquette.
Pour revenir aux Thomson, le RESET modifie la plage $2000-$20FF. Donc ne serait-il pas possible de réorienter ce dernier vers le programme de boot SDdrive en modifiant l'adresse du vecteur? (Tout ça lors de l'init SDD). Enfin, si c'est possible. Ce qui est moins certain
Mais il y a un inconvénient de taille. Si la machine est grandement plantée il faut éteindre et tout reprendre.

Ce n'est sans doute pas la meilleure solution, mais peut-être bien une piste.

[__sam__]

Sur thomson les vecteurs, et en particulier celui du reset ($FFFE-$FFFF), sont dans la rom. Il n'y a pas moyen de le changer. La plage "page0" ($20xx sur MO et $60xx sur TO) est rénitialisée lors des "reset à froid". Ce dernier est detecté par une mauvaise valeur (ie autre que $A55A) en page0+$fe/page0+$ff:

Code : Tout sélectionner

F00E CEA55A     LDU    #$A55A             
F011 1193FE     CMPU   <$FE               
F014 2709       BEQ    $F01F              
F016 DFFE       STU    <$FE   
F018 CE070C     LDU    #$070C             
F01B EF84       STU    ,X                 
F01D EF01       STU    $01,X              <--- remarquez comme ceci est curieux: ca écriut $0707C en ,x (qui est en page 0)
F01F <suit le code de remplissage de la page0>            

Mais j'ai la forte impression que sur cette rom de MO la routine passe toujours en $F01F, cad réinitialise beaucoup de points (tous?) de la page0.

[Daniel]

Les vecteurs sont tous réinitialisé par le reset à froid (au démarrage de la machine), mais pas tous par le reset à chaud. Malheureusement il n'est pas possible de trouver une zone libre de 6 octets dans ceux qui ne sont pas réinitialisés. La pile système, par exemple, n'est pas remise à zéro, mais l'expérience montre qu'il n'est pas prudent de l'utiliser, les risques d'écrasement sont trop grands.

Code : Tout sélectionner

WARM    EQU     *
        CLRA                    A = 0 pour init. des flags de pointeurs.   
        LDU     #TABADR         U pointe sur la table des adresses -->pointeurs     
INIPTR  EQU     * 
        PULU    Y               Y contient I'adresse a mettre dans le pointeur.    
        STA     ,-X             Le flag est mis en tete {3eme octet = 0),     
        STY     ,--X            suivi de l'adresse.   
        CMPX    #SWI1PT         Dernier pointeur a charger = SWI1PT.     
        BGT     INIPTR
SET$00  EQU     *                      
        STA     ,-X             A contient encore la valeur zero --> tous    
        CMPX    #STATUS         les registres jusqu'a STATUS inclus.     
        BGT     SET$00              
        COMA    
SET$FF  EQU     *                          
        STA     ,-X             A = $FF.
        CMPX    #TERMIN         La table des terminateurs est initialisee a $FF   
        BGT     SET$FF              
        STB     TABPT           B contient encore la valeur RDIRECT.     
        STB     TOPTAB          Initialisation des octets superieurs des     
        STB     BOTTAB          pointeurs de la table des terminateurs.      
        CLR     DKFLG               

[OlivierH]

Pour info, dans le jeu "Le 5ème Axe", le bouton "Init. Prog" ne fait rien... pas de réinitialisation.
Il y a donc au minimum un moyen d'empêcher son fonctionnement.
Si on peut modifier le vecteur de l'interruption on doit pouvoir le faire pointer sur une routine qui appelle la fonction originale après avoir sauvegardé ce qu'il faut (sur la pile système ?) puis restaure les données au retour ? (si pas de retour, peut être que l'appel d'une fonction ou d'une autre du contrôleur pourrait restaurer ces valeurs si elles ne sont pas présentes ?)

[Daniel]

Comme l'a écrit __sam__ le vecteur et la routine de reset sont en ROM, il est impossible de les modifier.
Avec le 5e Axe (et d'autres jeux) le reset à chaud fonctionne normalement : il réinitialise la RAM système et lance le BASIC. C'est un vecteur du BASIC (en RAM) qui est détourné pour lancer automatiquement le jeu.

[OlivierH]

Comme l'a écrit __sam__ le vecteur et la routine de reset sont en ROM, il est impossible de les modifier.
Avec le 5e Axe (et d'autres jeux) le reset à chaud fonctionne normalement : il réinitialise la RAM système et lance le BASIC. C'est un vecteur du BASIC (en RAM) qui est détourné pour lancer automatiquement le jeu.

En effet dans mon souvenir le bouton ne faisait rien mais je viens de vérifier et effectivement il relance le jeu.

Du coup j'ai une autre suggestion, surement idiote sinon vous y auriez déjà pensé, mais je la dis quand même au cas où
Qu'est-ce qui empêche d'enregistrer ces quelques octets sur la carte SD elle même, si elle est en lecture/écriture, et de les relire si ces zones se trouvent vides en mémoire ?
Ca ne fonctionnerait évidemment pas avec une carte SD en lecture seule, mais quand on utilise la carte SD pour développer elle est forcément en lecture/écriture ^^

[Daniel]

Non, ce n'est pas une mauvaise idée, j'y ai déjà pensé mais jusqu'à maintenant l'ai reculé devant la complexité de la tâche au regard du maigre bénéfice pour l'utilisateur. Aujourd'hui très peu de programmeurs développent en BASIC sur la vraie machine, les autres ne sont pas concernés. Il y a plusieurs problèmes à résoudre, mais ce n'est peut-être pas insoluble :

1) Il faut trouver un emplacement physique dans la carte qui ne risque pas d'être écrasé par le partitionnement ou le système de fichiers. Le secteur 1 de la piste 0 serait l'idéal. Selon le type de formatage il peut contenir un MBR (Master Boot Record) ou le secteur de boot de la partition. Il doit être possible de trouver une zone de 6 octets qui ne perturbe le fonctionnement ni de l'un, ni de l'autre.

2) Il faut trouver la place dans l'EPROM du contrôleur pour programmer l'écriture et la relecture de ces 6 octets. C'est plus difficile car il ne reste pas beaucoup de place libre.

C'est un peu compliqué, mais je vais y réfléchir...

[OlivierH]

Aujourd'hui très peu de programmeurs développent en BASIC sur la vraie machine, les autres ne sont pas concernés.

Et en plus personnellement je ne suis pas sûr de développer beaucoup directement sur le MO5 '^^ C'était juste pour retrouver le plaisir de l'époque.
Mais je suis sûr que le défi t'intéresse (sinon ce n'est pas la peine de s'embêter... je peux vivre avec ^^ )

1) Il faut trouver un emplacement physique dans la carte qui ne risque pas d'être écrasé par le partitionnement ou le système de fichiers.

En fait si ces infos sont écrites à chaque sélection de fichier sd, ce n'est pas très grave qu'elles puissent être écrasées lors d'une opération qui de toute façon ne se fera que sur une autre machine... si ?
Il y a un espace "vide" dans la MBR à priori prévu pour les différentes traductions des messages d'erreurs (http://poloastucien.free.fr/mbr_fat_sec ... oot_h.html)
Je pense que ça pourrait être pas mal de stocker ces 6 octets entre 1AE et 1B4 du premier secteur.
Qu'en penses tu ?
Edit: en fait à la réflexion il vaudrait mieux entre 1E8 et 1EE ... ce sont eux qui ont le moins de chance d'être utilisés.

2) Il faut trouver la place dans l'EPROM du contrôleur pour programmer l'écriture et la relecture de ces 6 octets. C'est plus difficile car il ne reste pas beaucoup de place libre.

Est-il envisageable de mettre une EPROM plus grosse ? (je n'ai aucune idée de la complexité de la chose)

C'est un peu compliqué, mais je vais y réfléchir...

Merci en tout cas

Et à part ce détail je suis très content de ce SDDrive pour lequel je te renouvelle mes félicitations

[Daniel]

Pour choisir l'emplacement dans le premier secteur de la carte, il y a encore deux autres contraintes :
- Il faut que l'emplacement soit également inutilisé dans le secteur de boot, car avec certains formatages sans partitionnement il n'y a pas de MBR, le premier secteur est le secteur de boot de l'unique partition.
- Il faut qu'après l'écriture des 6 octets le MBR ou le secteur de boot fonctionnent encore sur PC ou Mac, pour permettre d'accéder aux fichiers .sd ou en ajouter d'autres.

Dans un ordinateur Thomson, l'espace d'adresses réservé au contrôleur de disquette est limité à $07C0 octets. Pour mettre une plus grosse EPROM il faut construire un système de commutation de banques mémoire, comme dans le contrôleur CD90-351. C'est beaucoup plus compliqué, autant pour l'électronique que pour la programmation, et je voudrais l'éviter.

J'ai bon espoir de trouver assez de place dans l'EPROM, car en fait seule la lecture des octets doit y être programmée. L'écriture peut être faite par le programme SDDRIVE.SEL, juste après la sélection du fichier .sd par l'utilisateur. SDDRIVE.SEL est beaucoup moins limité en taille puisqu'il est stocké sur la carte SD et chargé en RAM.

[Daniel]

J'ai modifié les deux programmes (SDDRIVE.SEL et l'EPROM du contrôleur SDDRIVE) et testé avec dcmoto. Ca marche, les six octets sont écrits en $01E8 dans le premier secteur de la carte et relus en cas d'appui sur le bouton Init. Reste à confirmer avec un vrai MO5, mais je suis confiant.

Toutefois je trouve cette modification très complexe et source d'ennuis potentiels. Un plantage du programme du MO5 peut conduire à des écritures non souhaitées sur la carte. La modification n'apportera rien aux programmes commerciaux et aux démonstrations qui écrasent les vecteurs du moniteur et nécessitent un reset à froid pour reprendre la main. Elle n'apportera rien aux programmeurs assembleur qui sont obligés de sauvegarder le programme avant de le tester pour éviter de le perdre en cas de plantage. Elle ne sert qu'aux programmeurs BASIC qui veulent utiliser le bouton d'initialisation.

Pour toutes ces raisons, la variante sera diffusée et vous pourrez l'utiliser, mais je n'en ferai pas une version officielle et elle ne sera pas intégrée dans les prochaines révisions du logiciel. Il est déjà très complexe sans cette fonction. Simple is beautiful, particulièrement en programmation.