DCMOTO - Emulateur universel Thomson 8 bits : Forum - Machines et périphériques - [TO7-70] - MagnétoK7 Arrêt pendant lecture
Auteur Message
FabriceFABS
Visiteur
Date : 12/09/2004 à 10h53
Bonjourno !

Voilà je me demande pkoi le magnéto reprends et s'arrête pendant la lecteure de certains progs...
Il semble que j'ai cru l'avoir lu qquepart mais je ne sais plus où !
Si qqun sait...

C pas parqu'il est enregistré en ASCII ?
Citation :
Save "Nom",R
en haut - en bas
Daniel
Visiteur
Date : 12/09/2004 à 11h23
Les fichiers enregistrés sur cassette sont découpés en blocs physiques, séparés par des espaces appelés "gaps inter-blocs".
Si le programme qui enregistre le fichier est rapide, il a le temps de préparer le bloc suivant pendant la durée du gap, et il n'y a pas d'arrêt du moteur.
S'il n'a pas le temps, parce que le traitement de préparation du bloc est long, il arrête le moteur, prépare le bloc, redémarre le moteur, écrit le bloc.

A la lecture, s'est pareil. Le bloc lu est traité et stocké en mémoire. Si c'est moins long que le gap, le moteur ne s'arrête pas. Si c'est plus long, le moteur s'arrête, et redémarre quand le traitement est terminé, pour lire le bloc suivant.

Dans le cas de la lecture d'un programme Basic en ASCII, le traitement d'un bloc est long, car il faut coder les instructions à partir du texte du listing, les implanter en mémoire en reconstituant la structure adéquate, en particulier les pointeurs de lignes. C'est plus long que le gap, il faut donc arrêter le moteur.

Daniel
en haut - en bas
FabriceFABS
Visiteur
Date : 12/09/2004 à 12h52
Merci...

Citation :
Si le programme qui enregistre le fichier est rapide...
Que veuc-tu dire ?

Ou alors, qu'est-ce qui favorise sur l'UC le fait que ce soit ± long concernant le traitement puisqu'ils qu'ils sont tous à 1MHz !!

Cette question accompagne ma précédente : Pourquoi desfois il n'y a aucun arrêt ? (Je tourne la question à l'envers par exemple les programmes VIFI NATHAN avec la zique, ce serait un peut moche ) Je suis pointilleux et dur de la feuille mais je veux comprendre un peux plus...
en haut - en bas
smague
Visiteur
Date : 12/09/2004 à 14h17
on constate le même probleme de lenteur en chargeant d apres une disquette lorsqu il s agit d un programme sauvegardé en ASCI c est beaucoup plus long qu un LOAD de programme sauvegardé en standard.
en haut - en bas
Daniel
Visiteur
Date : 12/09/2004 à 14h54
FabriceFABS a écrit :
Que veux-tu dire ?

Je me suis mal exprimé : le programme n'est pas rapide ou lent, disons qu'il a peu de choses à faire, et alors ça prend peu de temps, ou bien il a beaucoup de choses à faire, et alors ça prend beaucoup de temps.

S'il a peu de choses à faire, il a le temps de les faire pendant le gap inter-blocs, alors le moteur ne s'arrête pas.

S'il a beaucoup de choses à faire, il n'a pas le temps de les faire pendant le gap inter-blocs, alors le moteur s'arrête.

Remarque : le programme dont je parle est le programme de chargement, pas le programme chargé. Dans le cas où tu fais LOAD"PROG" le programme de chargement est le Basic. Ne pas confondre avec le programme que tu charges, qui est PROG.BAS

Daniel
en haut - en bas
FabriceFABS
Visiteur
Date : 12/09/2004 à 15h36
Ah alors voudrais-tu dire que celà vienne de la complexité des lignes ou éventuellement de leurs structure ? (longues/courtes...)

PS : merci pour la correction de la faute de frappe
en haut - en bas
Daniel
Visiteur
Date : 12/09/2004 à 17h48
Oui, tu as raison : plus la ligne Basic est longue, plus il faudra de temps pour la coder telle qu'elle sera stockée en mémoire.

Mais le codage des instructions n'est pas la seule tâche à effectuer quand un programme ASCII est chargé : il faut aussi réserver la place mémoire et mettre à jour différents pointeurs, en particulier celui qui donne l'adresse de la ligne suivante.

Donc, même si la ligne est courte, le moteur s'arrête un instant. Si la ligne est plus longue et plus complexe, le moteur s'arrête plus lontemps. A l'oreille on doit entendre les différences.

Daniel
en haut - en bas
FabriceFABS
Visiteur
Date : 12/09/2004 à 19h01
D'accodac
en haut - en bas
smague
Visiteur
Date : 12/09/2004 à 21h06
Ne s agit t il pas aussi d une cassette avec un programme principal qui contient des instructions LOAD et RUN portant sur plusieurs autres programmes et qui les appelle au fur et à mesure ....ce qui explique les arrets et redemarrage.
En pascal on avait aussi la possibilité d ecrire des programmes appelés segmentés(SEGMENT PROCEDURE) pour eviter de surcharger la memoire avec le code de fonctions ou procedures lorsqu elles n etaient pas indispensables à un instant donné.
Donc cela provoquait à l interieur d un meme programme des appels au disque de manière discontinue.Cependant cela ne pouvait se produire qu'avec des disquettes, le Pascal Thomson,sauf erreur de ma part, etant totalement incompatible cassette.
en haut - en bas
Daniel
Visiteur
Date : 12/09/2004 à 21h53
A l'exécution, bien évidemment, les programmes peuvent faire autant de démarrage et d'arrêt de cassette qu'ils le souhaitent.

Fabrice était surtout intrigué par les arrêts du moteur pendant le chargement.

Daniel
en haut - en bas
FabriceFABS
Visiteur
Date : 12/09/2004 à 22h12
Oui c vrai.
Mais dans le doute, j'allais essayer un
Citation :
SKIPF
sur une bande que je connaissais qui s'arrêtait...
en haut - en bas