fichiers joints

Bonjour,
J'ai un problème que j'aimerais bien solutionner ou, au moins contourner
Voilà : Dans un code BASIC je charge un module complémentaire en fonction du choix fait dans un menu.

Tous les modUles sont du code BASIC dont les lignes sont numérotées à partir de 20000.

J'ai donc des llignes du genre :
IF C= 1 THEN INTRO,J: GOSUB 20000
IF C=2 THEN PARTIE1,J:GOSUB 20000
IF C=3 THEN PARTIE2,J: GOSUB 20000

J'utilise cette méthode de fichiers joints pour éviter d'avoir un CODE BASIC trop volumineux (La somme de toutes les options) qui ne me laisserait plus la place nécessaire aux routineS LM.

Que se passe t-il lors de l'exécution ? Eh bien chaque fichier joint se charge bien comme prévu à la suite du code principal, mais le l'exécution du programme s'arrête après le chargement. (Le GOSUB 20000 ne s'exécute pas)

Quelqu'un connait-il une astuce pour ne pas interrompre le programme après un chargement de fichier joint ?

Bonjour Dom,

Je découvre cette astuce (je n'ai vraiment jamais trop utilisé sedoric)
je me pose les questions et idées suivantes à la suite du chargement :

1/ que dis le pointeur de suivi du basic ? reste t'il sur la ligne après chargement du module ?
2/ peut etre peux tu lancer en auto le module qui se charge à 20000 et faire un goto pour revenir après ta série de if ...
3/ si le module démarre en auto avec un return à la ligne 20000 et ensuite tu fais gosub 20010 ?
4/ est ce que si tu mets explicitement un load "intro,j":gosub 20000 cela change la donne ?

Avec des modules de taille différente, je me demande bien ce que cela doit donner dans la gestion de l'espace des variables.
Didier

le rajout de lignes Basic par chargement suppose une reconfiguration automatique de toutes les variables (tableaux chaines caracteres etc) pour continuer le programme comme si rien était. Je ne pense pas que ce soit faisable sans arreter le prog. Sinon il faudrait sauvegarder les morceaux (appeles par un GOSUB) en mode LM avec un petit code en en-tete executable auto qui recopierait ce morceau juste à la suite du prog principal, remettrait à jour les pointeurs et...provoquerait un RUN en rom pour faire repartir le tout avec en inconvénient toutes les valeurs des personnages effacees ! (sinon tout le programme BASIC serait transformé en bouillie). Il est préférable de faire des CLOAD de temps en temps pour récuperer des segments de donnees sauvegardées en mode LM ce qui n altère pas le fonctionnement du programme en BASIC.

Oui Kenneth, tu as probablement raison.
J'avais pensé "bêtement" que puisque le chargement d'un programme joint était admis en mode programme (en plus du mode direct) la moindre des choses était que ça n'arrêterait pas le programme

tel que cela fonctionne , chargement des lignes de code supplémentaires puis arrêt du programme... l'intérêt est plus que limité (figure de style pour dire NUL )

Le seul intérêt que j'y vois c'est pour optimiser une disquette de travail.

Tu découpes ton prog Basic en plusieurs morceaux ré-utilisables et avant de faire la version définitive tu "Join" ce qui t'intéresse et tu re-numérote le tout.

En sauvant les "modules complémentaires" en mode AUTO, lorsqu'ils sont chargés par un LOAD,J , cela redémarre tout le programme.
Donc si avant de charger ton module complémentaire, tu peux t'arranger pour sauver tes variables, et les relire au début du programme (avec aussi une variable te disant où poursuivre l'exécution), tu dois pouvoir faire "comme si".
Il faudra aussi réinitialiser le fichier de sauvegarde dès qu'il sera lu, sinon en cas de lancement normal du programme, tu vas te retrouver avec les vieilles valeurs de tes variables.

Je ne sais pas si je suis très clair...

Sinon la solution viendra peut-être de la commande MERGE (,L pour éviter des affichages intempestifs).
D'après Sedoric à Nu, il conserve les variables.
Pb: je viens de faire un test rapide, ça marche une fois pour ajouter des lignes, mais si elles existent déjà il produit l'erreur "Lines already exists"

@Symoon
Oui MERGE est peut-être une solution. Merci !
Il faut que j'essaie.
D'après le manuel de SEDORIC, la commande DELETE est utilisable en mode programme. On doit donc pouvoir supprimer les lignes du module précédant, avant de MERGER le module suivant...
Reste à voir ce que deviennent les variables avec ce DELETE en mode programme...

Sinon Hialmar et Maxi m'ont donné une autre astuce qui fonctionne à coup sûr puisque utilisée par Maxi pour T3...

Ah, bah sauf si c'est secret défense ou trop long à expliquer, n'hésitez pas à la faire connaître, cette astuce

pas de secret entre oriciens  

hialmar a écrit:Ah si pour résoudre ton pb tu peux faire comme Maximus :
- tu n'utilises pas le Join mais des chargements successifs qui remplacent donc tout le code ;
- tu planques une info dans une partie de la RAM (inaccessible au Basic) dont tu connais la valeur (exemple au début du jeu de caractères alternés c'est toujours des 85 au démarrage - Maximus utilise lui la zone réservée juste avant la ROM mais Sédoric y stocke des routines donc pas glop) ;
- tu testes cette valeur au chargement du programme menu. Si c'est un 0 pas de pb. Si c'est un 1 (ou autre) tu fais un GOTO sur une ligne située après celle de chargement dans le menu.

CODE:

1 IF PEEK(#B800)=1 THEN 10005
2 IF PEEK(#B800)=2 THEN 10015
2 IF PEEK(#B800)=3 THEN 10025

...
10000 IF C= 1 THEN INTRO
10005 GOSUB 20000
10010 IF C=2 THEN PARTIE1
10015 GOSUB 20000
10020 IF C=3 THEN PARTIE2
10025 GOSUB 20000

Et à la fin de INTRO tu fais un POKE(#B800,1)
à la fin de PARTIE1 tu fais un POKE(#B800,2)
...

Ceci étant dit,
j'ai réussi à faire fonctionner DELETE 20000- : MERGE"INTRO",L  

Dans un premier temps, j'avais le message "INSERT MASTER DISC"
Hop, un coup de pach.001 (Merci André)
Et je croyais être quitte, mais non... car la commande MERGE demande systématiquement que l'on introduise le disc avec les données à MERGEr...
Je m'en suis tiré en modifiant SEDORIC ... à l'aide de NIBBLE comme pour la disquette de TYRANN (Cf Mag Septembre 2011)
L'ordre MERGE est dans la banque 3 Le code à modifier en C698c soit piste 4 secteur #0A de la disquette SEDORIC.

J'ai simplement remplacé
C695c JSR D44F      Lit nom de fichier
C698c PHP
C699c PHA
C69Ac BIT C016
C69Dc BPL C6A9
C69Fc LDX #03     Indexe message "LOAD"
C6A1c JSR D364    Affiche LOAD
C6A4c JSR D648    Affiche DISC IN DRIVE A AND PRESS RETURN
C6A7c BCS C692
C6A9c PLA
C6AAc PLP
C6ABc CLC

par :

C695c JSR D44F   Lit nom de fichier
C698c JMP C6AB  Saute à la suite sans passer par les messages importuns
C69Bc NOP
C69Cc NOP
C69Dc NOP
C69Ec NOP

Et ça fonctionne !

Ah oui quand même...

T'es sûr que t'aurais pas du remplacer les commandes enlevées par des NOP en laissant les JSR au même endroit ? Des fois il y a des optimisations qui consistent à faire un JSR en plein milieu d'une routine. Ca existe dans la ROM en tout cas.

Tu veux dire remplacer, le code entre $C69D et $C69E par des NOP ?
oui, ce serait plus propre, c'est sûr

(message précédent édité...)

Merci !
Bon eh ben pas si simple tout ça
Est-ce que charger un petit bout de programme assembleur au début, puis la suite du programme, ne serait pas une solution ?
(genre juste un RTS au début du module, comme on fait sur ROM1.0 pour charger une page HIRES sans revenir au Ready)