PEDROM ARCHIVES: Flat or Sector - Page 2

Ben non, pas "autant ne pas flasher ça calculatrice et garder l'AMS de TI" parce que AMS est propriétaire. L'intérêt serait d'avoir une alternative libre (GPL).

C'est triste de ne pas vouloir évoluer.

Ce qui bloque c'est les programmes existant.

un AMS GPL s'est bien mais si c'est pour le limiter comme tu veux le faire je ne vois pas trop l'interet par rapport au propriétaire a part le défi technique.

> je ne vois pas trop l'interet par rapport au propriétaire a part le défi technique.
Des ideaux politiques. Cf http://www.gnu.org

>CAS
Au sujet, du CAS, il sera une application externe. Nativement, PedroM supportera plus ou moins le format tokenise AMS (Plutot moins que plus d'ailleurs).

L'autre avantage que vous n'avez pas bien compris, c'est le support des programmes > 64K de facon triviale.

La swap j'abandonne pour l'instant: "Keep it simple" regle 4 du bon programmeur d'OS.

Flat Inconvenient:
+ Peut etre plus de consos des archives (A verifier)
+ Incompatibles avec les programmes qui bidouillent la flash.
+ Les programmes utilisant EM_write ne fonctionnent pas. Mais je ne veux pas les faire fonctionner car meme sous AMS, c'est suceptible de faire des mechants plantages, ou de perdre un secteur. Bref c'est de la programmation sale que je ne veux pas voir fonctionner sous PedroM (Je veux assurer un minimum de securite quand meme). Style Corridor. Sinon pour FAT Engine, je conseille fortement d'utiliser EM_moveSymToExtMem avec un fichier temporaire. C'est propre, sur, ca marchera sur tout systeme (Y compris les futurs AMS. Franchement croire qu'AMS gardera cette structure d'archive me parait ultra-utopique).
+ Lors de l'install a partir d'AMS, on perdra ces archives (Mais on les gardra avec une reinstall de PedroM).
+ PedRhum devra patcher plus (Mais je peux coder l'autre methode et assurer une dual compilation).

Sector inconvenient (compatible AMS 2.0x):
+ Programme limite a moins de 64K.
+ Peut etre moins d'appel a FlashErase... Surement pas si les archives sont saturees.
+ Des bouts d'archive inutilisable.

Je peux par contre dans le pire cas laisser un petit bout d'archive en pature a Corridor et consort

> Des ideaux politiques. Cf http://www.gnu.org
Justement s'aligner a 100% sur un modèle propriétaire ne fait pas vraiment libre.

Pour la version 1.00, je garde le systeme par secteur. On verra plus tard.
C'est surtout parce que la fonction FlashCheck devient beaucoup plus difficile.

Sinon, Kevin parlait de forker PedroM, mais après tout il sera tout à fait possible de faire plusieurs versions, une plus compatible que l'autre avec l'AMS. et pour le CAS, on peut trouver un moyen de faire deux CAS dont le format diffère...

Après tout, un PedroM compatible avec AMS sera toujours un peu plus petit et plus rapide, quand on voit certaines erreurs du code d'AMS... (citées par un membre du forum dans le forum TI, je crois)

Mouais, étant donné que le code est presque entièrement en ASM, bonne chance pour le modifier...

De l'ASM clair est souvent bien plus lisible que du C fouilli.

Bof, c'est pas complique du tout. Le de PedroM est tres bien documente en general.

PedroM est bien codé et bien organisé, les sources se lisent et se laissent modifier sans problèmes.

Ah, ben je n'ai rien dit alors.
Il est vrai que pour l'instant, tout ce que j'ai voulu chercher dans le source de pedrom, je l'ai trouvé et compris rapidement en fait, mais je pensais que d'une façon générale, le C était plus facilement lisible et modifiable que l'ASM.

Dans le cas de PedroM qui n'a pas de structures de données hype-complexe et de communications excessives entre les différentes parties, c'est aussi lisible que du C.

"Pas de communications excessives entre les différentes parties"??? Tu n'as jamais essayé de sortir DrawClipRect de ses sources apparemment. Moi, j'ai essayé (pour voir si je peux l'utiliser pour Backgammon pour Fargo), et ben, impossible, cette fonction nécessite pratiquement toute la ROM pour fonctionner. (OK, j'exagère un peu, mais c'était à peu près ça.) En plus, les routines de PpHd ont la fâcheuse habitude de sauter au plein milieu des routines (cf. labels en _reg etc.) et d'être exprimées en termes de routines internes plutôt qu'externes, donc pour les réutiliser ailleurs, c'est raté. Par exemple, DrawClipRect appelle frame (dans window.asm!) qui appelle horiz et vert (de retour dans graph.asm!) qui eux-mêmes utilisent un gros paquet de variables internes. Cette routine pouvait être implémentée tout simplement par 4 appels à DrawClipLine. horiz et vert sont d'ailleurs de la perte de place inutile, DrawClipLine pourrait être utilisée à la place. Bref, j'ai fait 10 fois plus vite de réécrire la routine plutôt que d'essayer de réutiliser l'implémentation de PpHd.

LOL. Desole. Mais tu vois bien que mon code peut pas etre a de simples fonctions qui ne communiquent pas entre elles. Je fais toujours comme ca, pour reduire la taille. Et puis les routines internes, c'est pour gagner en taille. DrawClipLine a ete ecrite apres DrawClipRect. Donc prend note. Les variables internes, c'est les parametres de clipping. Par ailleurs, DrawClipLine (tout comme DrawLine) est pas optimise pour afficher des lignes horzontales. C'est pas si complique ce que tu racontes. Essayes de sortir find_lib de son contexe, qu'on rigole

Oula... Avec les packs archive, elle doit dépendre d'à peu près tout PreOs, plus pas mal d'endroits dans AMS ou PedroM, plus les librairies de décompression externes.

Oue.