60

Cherchez pas, les gars, Kevin est encore plus furieux et inutile que d'habitude, ces jours-ci...
Pourtant, vous devriez savoir, depuis le temps, que vous ne gagnerez pas au jeu de "qui se comporte de la façon la plus stupide" s'il est de la partie wink
avatar
Membre de la TI-Chess Team.
Co-mainteneur de GCC4TI (documentation en ligne de GCC4TI), TIEmu et TILP.
Co-admin de TI-Planet.

61

Godzil (./47) :
La memoire flahs utilisé dans les TI 68k est de la NOR, il faut compter quelques milliers d'effacement, pas bien plus. Pas des centaines de milliers ça c'est sur.
Mmh, apparemment la puce utilisée (pour les 89 du moins) est soit une LH28F160 soit une LH28F320, et la datasheet dit 100 000 cycles mini.

Par ailleurs j'ai jamais entendu dire que les NOR étaient moins endurantes que les NAND pour le nombre de cycles de réécritures, tu as une source ?
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

62

c'est même plutot l'inverse, les NAND c'est 10k cycles et les NOR 100k, je l'ai appris du temps où je suivais les mailing list openmoko.

63

Non plus, on trouve des NAND qui tapent dans le million de cycles, il y en a dans les clés USB par exemple.
avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

64

65

33-kernel::LibsPtr	(Preos only)

	Input:
		a0.l -> Lib descriptor
		d0.w = Number of the function
	Output:
		a0.l = Pointer to the function or NULL
	Destroy:
		a0

	It gives a pointer to the required function of the library.

Là ya un vrai problème, d0 est détruit... Adress error à cause de ça dans mon programme (corrigé évidemment, mais bon ce fût la surprise ^^)

LibsPtr commence et finit par un movem.l d1-d2,-(sp)/(sp)+. Il est utilisé à deux autres endroits de sld (et dans aucun autre fichier). Chaque fois, d0 est écrasé immédiatement pour tester le résultat (move.l a0,d0). Il n'y a donc pas de problème pour faire un movem.l d0-d2.

66

ou alors changer la doc et dire que d0 est détruit grin
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

67

Oui, solution de loin la plus simple. Mais la modification du code me ferait gagner largement deux bons octets cheeky

68

Tu as arrété le C++ à ce que je vois ;o

69

Je peux pas être sur tous les fronts à la fois, et je suis reviendu à fond dans mon assembleur, PedroM, toussa. Ca me manquait trop love

70

Zerosquare (./61) :
Godzil (./47) :
La memoire flahs utilisé dans les TI 68k est de la NOR, il faut compter quelques milliers d'effacement, pas bien plus. Pas des centaines de milliers ça c'est sur.
Mmh, apparemment la puce utilisée (pour les 89 du moins) est soit une LH28F160 soit une LH28F320, et la datasheet dit 100 000 cycles mini.

Par ailleurs j'ai jamais entendu dire que les NOR étaient moins endurantes que les NAND pour le nombre de cycles de réécritures, tu as une source ?


Me suis planté de un 0. c'est ~100 000 pour la NOR en effet, par contre la NAND, je suis pas du tout d'accord, c'est entre 10.000 et 100.000 pour de la NAND SLC, et largement moins de 10.000 pour de la MLC. Et encore, la NAND est moins testé que la NOR, donc seul les premiers secteurs voir que le secteur 0 sont garantit au nombre d'effacement sans apparition d'erreurs sur les bits.

Ce qui "allonge" la durée de vie des clefs USB/Cartes mémoires (SD/MMC) c'est le controlleur intégré gerant le Wear Levelling et les bad blocs qui donne cette impression. (cf : http://fr.wikipedia.org/wiki/Mémoire_flash#Dur.C3.A9e_de_vie pour les durée de vie)
avatar
Proud to be CAKE©®™


GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.

71

autre différence, tous les chips NOR fonctionnent à 100% mais les chips NAND ont des bad blocks, et la première chose que fait un bootloader basé sur de la NAND est de scanner le chip pour faire une liste des bad blocks et ne plus écrire dedans.

ce qui fait que tous les chips de NAND sont prévus avec plus de blocks que marqué sur l'emballage pour que ça revienne à normal après l'éjection des bad blocks.

et effectivement sans wear leveling on va pas très loin (cf smart media)

J'ai pas de source précise mais y'avait eu des threads la dessus sur les mailing list openmoko.

72

(ça vous dirait pas de forker pour vos nand ? c'est pas trop l'endroit quoi... ya info/hw pour ça smile)

73

avatar
Zeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo

74

Écoute, j'utilise les bug trackers ou les formulaires de bug report quand il y en a, mais là, la méthode officielle est apparemment ce forum, étant donné que c'est ici qu'on trouve pas mal de bug reports pour les logiciels de PpHd.

Si ça ne convient pas à PpHd, c'est à lui de le dire, pas à vous!

Je suivrai toute consigne (raisonnable, évidemment grin – si c'est du genre aller consigner une clé USB en personne à PpHd, ça ne va pas aller évidemment grin) indiquée par PpHd pour les bug reports.
avatar
Mes news pour calculatrices TI: Ti-Gen
Mes projets PC pour calculatrices TI: TIGCC, CalcForge (CalcForgeLP, Emu-TIGCC)
Mes chans IRC: #tigcc et #inspired sur irc.freequest.net (UTF-8)

Liberté, Égalité, Fraternité