probleme de memoire - Page 1

est-il possible d'acceder a un fichier en archive sans le desarchiver.
Je m'explique, je veux stocker des donnees dans un fichier archive et avoir l'adresse du debut de ces donnees pour y acceder par mot de 8 bits.

est-il possible d'acceder a un fichier en archive sans le desarchiver.

Bien sur que oui, tu peux accéder à ces données sans les désarchiver, mais en lecture seule, ce qui, je suppose, ne t'intéresse pas.

par mot de 8 bits

Plus simplement, on appelle ça un octet.

Tu veux seulement lire ces donnees ?

Les donnees represente le niveau, je veux juste lire c donnee.
Donc il est possible d'avoir un pointeur vers c donnee.
Pour la rapidite, c la meme?

Disons pour simplifier, oue.

Tu as seulement besoin d'obtenir un pointeur vers ton fichier (cf vat.h)
qu'il soit archivé ou non ne change rien

> Disons pour simplifier, oue.
Euh, "oui" tout court selon mes tests.

Ca depend de la machine et du hardware et des piles Bref tres simple a mesurer

89 HW1, piles correctes. Moins de 0.1% de différence (i.e. pas de différence mesurable) avec des piles moyennes, que ce soit en exécution ou en lecture.

Merci a tous, je voulais juste savoir si c'etait possible avant de me lancer dans n'importe quoi.
Pour la vitesse, du moment que ce n'est pas 20 fois plus lent, c pas grave.
Nerick, ta page c du c, je ne pense pas que toutes c fonctions soient des romcall.

./9>Peut-être qu'en overclockant...

Euh ben après en overclockant peut-être, encore que je ne sais pas si ça va simplement ralentir ou carrément bugger.

La plupart (sinon toutes) les fonctions de vat.h sont des romcalls

92+ HW1 : Je mesurais des differences (Pile a moitie morte aussi, d'ailleurs ma pile de secours est morte aussi...)

Je me demande ce qui se passe d'ailleurs avec des piles mortes. AMS rajoute des wait states pour la RAM, alors s'il n'en rajoute pas pour la ROM ça deviendrait plus rapide de passer par la ROM

Et sinon de quel ordre les différences?

20% je crois. Mais je peux raconter des conneries.

heu sinon faut faire attention avec les movem aussi
enfin là s'il lit octet par octet ça devrait aller sans problemes.

1 wait cycle quoi... Je serais curieux de voir si ça arrive souvent. Faudrait que je fasse un petit prog pour détecter ça

Toute façon au bout d'un certain voltage les piles sont considéré comme morte et la calculatrice s'éteint, même si le peu d'énergie est capable d'alimenter la TI.

Pollux
: 89 HW1, piles correctes. Moins de 0.1% de différence (i.e. pas de différence mesurable) avec des piles moyennes, que ce soit en exécution ou en lecture.

C'est normal. Ni la RAM, ni la FlashROM, n'ont besoin de waitstates (cf. J89hw.txt).

Pen^2 :
heu sinon faut faire attention avec les movem aussi

Oui, movem strictement interdit quand la source est en mémoire archive. La protection anti-exécution des HW1 est stupide et croit qu'on veut exécuter du code dès qu'il y a 3 lectures consécutives, ce qui est le cas avec un movem.l de 2 registres ou plus et avec un movem.w de 3 registres ou plus. Résultat: barre noire. (Le problème a été corrigé dans les HW2, mais c'est trop tard.)

> C'est normal. Ni la RAM, ni la FlashROM, n'ont besoin de waitstates (cf. J89hw.txt)
Sauf si les piles sont basses, auquel cas le TIOS dit au hardware d'en rajouter. Je ne sais pas si ce sont les mêmes valeurs en Flash et en RAM....

> C'est normal. Ni la RAM, ni la FlashROM, n'ont besoin de waitstates (cf. J89hw.txt)
Ca depend. Sous HW2, c'est vrai. Sous 89HW1, je sais pas. Sous 92+ HW1, par contre c'est 100% faux.