genSlib (Genesis Static Library) - Page 3

60

Le 06/07/2001 à 16:37

>Dark Angel: * quand TI nous sortira un nouveaux HW ou une nouvelle ROM, les ancient jeux continueront a fonctionner quand le kernel et les libs auront ete adapté. les nostub nececiterons une recompilation, voir plus si des ROM_CALLs sont modifié (en C, il suffit d'utiliser des marcos, mais en asm, ca peut foutre un beau bordel)

>BlueZ: Bon, alors on imagine un instant que graphlib et gray4lib aient été statiques : à l'apparition du HW2, plus aucun jeu n'aurait affiché de niveaux de gris, alors que grâce au fait que ces librairies sont statiques [(je suppose que tu voulais dire: "dynamiques")], il a suffit d'en proposer des versions modifiées pour que tous les jeux qui les utilisaient fonctionnent correctement sans nécessiter l'intervention de chaque programmeur.

L'argument de compatibilité est cité souvent... Cependant:

1. Quand AMS 2 est sorti, de nombreux jeux en assembleur (à cette époque pratiquement tous en mode kernel) n'ont plus marché, alors que CReversi, un jeu en _nostub publié avant la sortie de AMS 2.03, a fonctionné sans modifications. L'important est surtout que les jeux ou programmes soient programmés proprement. Dans les sources de kernels et de jeux pour kernel, on trouve généralement au moins autant de saletés que dans les sources en _nostub. (Je sais que mes programmes résidents en mémoire ne sont pas un bon exemple en ce qui concerne la programmation propre, mais je n'ai utilisé les adresses absolues que là où je n'ai pas eu le choix.)

2. Le premier jeu en assembleur de ma connaissance à marcher sur HW2 AMS 2 était CReversi, un jeu en _nostub (et de taille inférieure à 8 KO).

3. Il y a eu une longue période où les kernels n'ont pas marché sur HW2 AMS 2 (jusqu'à la sortie du HW2Patch de JM). Pratiquement tous les programmes en assembleur dépendaient des kernels. Le résultat: Il n'y avait pratiquement aucun programme ou jeu en assembleur qui tournait sur HW2 AMS 2. Les seuls jeux à faire exception à cette règle étaient CReversi et CBlaster, programmés en C _nostub par Zeljko Juric.

4. Pour les niveaux de gris, de nombreux programmes pour kernel (tetris par exemple) n'ont plus marché avec les nouvelles librairies pour HW2 parce qu'ils partaient du principe que plane0=LCD_MEM.

5. TI jusqu'à présent n'a modifié des ROM calls que pour des changements au niveau interne. Les seuls changements incompatibles dont je suis au courant: des fonctions EM_ ont été supprimées pour ne pas user inutilement la ROM Flash lors du passage à AMS 2, et les fonctions OSVRegisterTimer et OSVFreeTimer ont été supprimées dans AMS 2.04 parce que ces timers n'existent plus dans l'architecture AMS.

Bref, on n'est jamais à l'abri des modifications internes, quelle que soit la méthode de programmation employée (kernel ou _nostub).
Quant à l'argument de compatibilité pour les kernels, il doit faire ses preuves avec les prochaines versions de AMS. Pour l'instant, les kernels n'ont pas un passé très heureux en cette direction-là, et je trouve donc que ce n'est pas une très bonne idée de dire en ce moment que les programmes pour kernel sont plus compatibles que les programmes en _nostub.
[edit]Edité par Kevin Kofler le 20-06-2001 à 18:06:39[/edit]

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é

61

Le 06/07/2001 à 16:37

Kevin>
2. Le premier programme en assembleur de ma connaissance à marcher sur HW2 AMS 2 était CReversi, un jeu en _nostub (et de taille inférieure à 8 KO).

Ce n'est peut-etre pas seulement du au fait que c'est un nostub: il s'agit d'un petit programme, qui n'utilise pas de "trucs" un peu harware (niveaux de gris) ...

4. Pour les niveaux de gris, de nombreux programmes pour kernel (tetris par exemple) n'ont plus marché avec les nouvelles librairies pour HW2 parce qu'ils partaient du principe que plane0=LCD_MEM.

Oui, d'accord.
Mais genlib encapsule complement les niveaux de gris, et on ne s'occupe de savoir ou sont les planes. (meme chose pour la lecture clavier, et d'autres trucs surment)
Avec ce genre de librairie, on court beaucoup moins de risque d'incompatibilités ...

62

Le 06/07/2001 à 16:37

j'ai tout lu

youpi !

63

Le 06/07/2001 à 16:37

Kevin Kofler > je retire ce que j'ai dit !

> Je trouve donc c'était une très
>mauvaise idée de Microsoft d'introduire les DLLs
>sous Windows. Je retiens la solution des
>librairies statiques techniquement supérieure.

mamamïa que font les jeunes a l'école aujourd'hui !

64

Le 06/07/2001 à 16:37

Travaux pratiques:
.Récupérer les sources de KDE et de QT
.Compiler KDE avec les bibliothèques en mode statique (je sais pas si on peut aussi compiler avec la Xlib en statique, mais pour les fous, on peut aussi le faire

)
.Rajouter une barrette de 256Mo dans sa machine, ça coute pas (trop) cher en ce moment et ça va servir

.Lancer Xwindows. On lance aussi une ou deux applis KDE (si vous arrivez jusqu'ici). A près si vraiment vous en voulez encore, je conseille Mozilla avec une machine virtuelle Java.
.Enjoy!

Plus sérieusement allez dire à n'importe quel programmeur que les librairies statiques n'étaient pas un bon choix pour Windows, Linux ou autre OS relativement récent (càd moins de 20 ans

), il vous regardera avec de gds yeux avant de vous éclater de rire au nez.

----------------

Et si on vire le TiOS ? A ben ça marche plus !
Et y a pas de risques que ça marche un jour. Faut tout réécrire. Avec les libs dynamiques, il y a moins de choses à adapter. Et puis comme le rappelait PpHd le Nostub utilise l'AMS comme une grosse lib dynamique. De toute façon, bientôt y aura plus de TiOS, donc plus de Nostub

[edit]Edité par Littleboy le 21-06-2001 à 01:06:22[/edit]

65

Le 06/07/2001 à 16:37

>Littleboy: Et puis comme le rappelait PpHd le Nostub utilise l'AMS comme une grosse lib dynamique.

AMS est le système d'exploitation, donc ses routines sont toujours là et je ne vois aucune raison pour laquelle AMS n'aurait pas le droit de les exporter. Il y a en effet une différence entre les fonctions du système d'exploitation et les librairies de programmeurs tiers. Même des licences comme la GPL les distinguent: on peut linker un programme en GPL à des fonctions ou librairies propriétaires du premier type, mais pas du deuxième, puisque selon la logique de la GPL, seules les premières font partie intégrante de la plateforme.

>Littleboy:
>Et si on vire le TiOS ? A ben ça marche plus !
>Et y a pas de risques que ça marche un jour. Faut tout réécrire. Avec les libs dynamiques, il y a moins de choses à adapter.

Tu sembles défendre la réécriture des ROM calls dans les librairies. (Serait-ce à cause de ta participation dans le projet LiteOS, qui vise à remplacer AMS?) Moi, je vois le fait d'intégrer dans les librairies des fonctions qui sont déjà dans la ROM comme du gaspillage (duplication d'effort et de place), donc j'urge les programmeurs à utiliser AMS partout où c'est possible. S'il vous plaît, préférez les ROM calls aux librairies (même aux librairies statiques) s'il existe des ROM calls adaptés (même si la librairie X fait gagner une dizaine de cycles du processeur, ce qui revient à des fractions de millisecondes)! N'utilisez des remplacements plus rapides que quand c'est réellement nécessaire.

>Littleboy: De toute façon, bientôt y aura plus de TiOS, donc plus de Nostub

De toute façon, aucun programme ou jeu ne sera compatible avec d'autres systèmes d'exploitation comme LiteOS (auquel je suppose que tu fais allusion) sans être porté, à moins d'avoir une émulation au moins partielle de AMS. Si on peut émuler les librairies, on peut aussi émuler AMS, du moins les ROM calls les plus importants. (Par exemple, un jeu n'aura très probablement jamais besoin de fonctions compliquées comme push_parse_text.)

Et puis, tant qu'il n'existe pas d'autre systèmes d'exploitation pour la TI-89/92+, "plateforme TI-89/92+" = "plateforme AMS".

En tout cas, je continuerai à utiliser et à programmer pour AMS tant que les alternatives ne seront pas à la hauteur, "à la hauteur" impliquant entre autres un calcul formel au moins aussi puissant que sous AMS.

66

Le 06/07/2001 à 16:37

>Il y a en effet une différence entre les fonctions du système d'exploitation et les librairies de programmeurs tiers.
Il faut savoir où s'arrête le système d'exploitation dans ce cas

Et puis j'ai jamais dis que AMS n'avait pas le droit d'exporter ses fonctions ! Les libs dynamiques permettent entre autres de pallier les faiblesses de l'AMS. Je les considère un peu comme des extensions au système. Ca fait partie du système d'exploitation.

>Tu sembles défendre la réécriture des ROM calls dans les librairies
Hum, non pas vraiment ! Et puis à part la dernière phrase, ma participation à LiteOS ne rentre pas en ligne de compte dans ce post.

> je vois le fait d'intégrer dans les librairies des fonctions qui sont déjà dans la ROM comme du gaspillage (duplication d'effort et de place), donc j'urge les programmeurs à utiliser AMS partout où c'est possible.
Je ne peux qu'être d'accord

. Mais quand on a une alternative beaucoup plus rapide en lib dynamique, pourquoi ne pas l'utiliser ?

>De toute façon, aucun programme ou jeu ne sera compatible avec d'autres systèmes d'exploitation comme LiteOS.
On ne peut plus vrai, mais pas à cause des ROMS CALLS ni des libs ...

>"à la hauteur" impliquant entre autres un calcul formel au moins aussi puissant que sous AMS.
Quelque chose me dit que tu te trompes ! Quand je disais qu'il n'y aurait plus de TiOS, je ne parlais pas de LiteOS(enfin pas complètement). On peut très bien faire une "surcouche" à AMS, ou plutôt un programme indépendant qui se passe de AMS.
Et puis il y en a beaucoup des progs qui utilisent les fonctions mathématiques de la TI ?
Pas des masses. Sur 92, aucun progs ASM utile en rapport avec les maths... Sur 92+ et 89, c pas tellement mieux

Ce qui m'ennuie chez les défenseurs du nostub, c que la plupart présentent l'utilisation du nostub comme la panacé et quelque chose de quasi-obligatoire! (cf j'urge les programmeurs à utiliser AMS partout où c'est possible ). C'est ce côté racoleur qui a tendance à m'énerver. Même si certains arguments se tiennent, ça décrédibilise un peu.

Et puis le coté "il faut faire en sorte que ça soit facile pour les newbies, pas trop de fichiers, c dur à comprendre !", ça se tient pas!

Quand j'ai commencé, j'ai mis 1 mois à faire marcher l'ASM (pas rigoler please), j'avais juste 2 ou 3 fichiers sur un cd et un cable Ti-Gl (et pas internet donc pas de backup tout fait).
Ben j'ai appris! Idem pour le passage à la Ti92+ (c'était déjà plus simple).
Si ils veulent juste faire tourner un jeu, ben ou bien ils abandonnent direct (et c pas gd chose de perdu pour la communauté) ou bien ils s'accrochent et ils y arriveront assez vite !
Ils ont un PC ou un MAC, ils arrivent à installer un cable Ti, à faire marcher des jeux piratés(ou pas) avec des bidouilles de partout, sont bien capables de mettre 3 fichier sur une Ti qd même !!!
[edit]Edité par Littleboy le 21-06-2001 à 05:06:06[/edit]

67

Le 06/07/2001 à 16:37

Petite précision : l'avis que je donne ici n'as rien à voir avec LiteOS pour une bonne raison, son avenir dépends encore trop de la volonté de quelques personnes pour constituer une alternative fiable. Ca aura probablement changé dans quelques mois (1 an ?) mais rien n'est sur.
C'est simplement que les libs dynamiques me paraissent plus fiables au niveau de l'évolutivité. Il est vrai que jusqu'ici, ça n'a pas été trop le cas avec les kernels, mais c aussi dû à un certain manque de cohésion. Avec UniOS, on n'as pas encore eut de pb en tout cas

D'ailleurs un sujet où il faudrait faire du lobbying, c la libération des sources à l'abandon d'un projet. Pour les kernels c pas trop grave, ils y en a plein, dont certains en open-source, mais il y a bcp de jeux ou d'applis dont les créateurs sont partis ou sont passés à autre chose, et qui n'ont jamais été portés! Cela me semble tout aussi important que la compatibilité binaire.

Ceci dit, je traduis aussi l'aide de Tigcc, c pas vraiment en faveur des libs dynamiques ni des kernels, même si ce n'est que de la traduction.

Le nom LiteOS (ou Win) n'apparait pas dans ma signature et ce topic est le seul endroit où j'y ait fait allusion.

68

Le 06/07/2001 à 16:37

LOL

Littleboy >De toute façon, aucun programme ou jeu ne sera compatible avec d'autres systèmes d'exploitation comme LiteOS. 
On ne peut plus vrai, mais pas à cause des ROMS CALLS ni des libs ...

PAS A CAUSE DES ROM_CALLS!! En es tu sûr? Chez moi quand j'utilise un ercran virtuel.. je crois bien que j'utilise (hum
voyons voir) a si.. TIOS::memalloc ou qqc dans ce genre..& la gestion bas system se fait a l'aide de romcall..
he bein dit moi t'as de bonnes bases en programmation toi, je dit vive Liteos ca ma l'air bien prometteur [2eme]degrés
[edit]Edité par Nhdpp le 21-06-2001 à 09:06:58[/edit]

69

Le 06/07/2001 à 16:37

Bon j'ai tapé un peu vite

Il fallait lire:
On ne peut plus vrai, mais pas que à cause des ROMS CALLS ni des libs...
Ce que je voulais dire, c'est que même si il y avait une compatibilité aux niveaux des fonctions de base TiOS, il faudrait de toute façon tout "réécrire" pour d'autres raisons. En clair, les ROM_CALLS ne sont pas la raison principale qui fait perdre une hypothétique compatibilité.

>he bein dit moi t'as de bonnes bases en programmation toi, je dit vive Liteos ca ma l'air bien prometteur [2eme]degrés

Beuh, m'en fout c pas moi qui programme

Mais avec le programmeur principal (et seul pour l'instant) de ... (et pas encore LiteOS), je me fais pas de soucis. J'ai jamais dit que je programmais LiteOS, je m'occupe un peu de la doc et du site Web.
C certain que tu peux trouver encore pleins de trucs faux dans mes 2 posts pcdts (pourtant j'ai quasi rien mis de technique).

70

Le 06/07/2001 à 16:37

et puis euh on était sur une flamewar Kernel vs Nostub

71

Le 06/07/2001 à 16:37

>Littleboy:
>Et puis il y en a beaucoup des progs qui utilisent les fonctions mathématiques de la TI ?
>Pas des masses. Sur 92, aucun progs ASM utile en rapport avec les maths... Sur 92+ et 89, c pas tellement mieux

Connais-tu RPN et EQW? Ce sont 2 grosses applications de mathématiques écrites en C. Et il y en a aussi de plus en plus de petites.

>Littleboy: D'ailleurs un sujet où il faudrait faire du lobbying, c la libération des sources à l'abandon d'un projet.

Je suis d'accord. Cela résoudrait aussi d'éventuels problèmes de compatibilité avec les programmes en _nostub. (Il suffirait de recompiler en cas d'incompatibilité.)
[edit]Edité par Kevin Kofler le 21-06-2001 à 15:05:15[/edit]

72

Le 06/07/2001 à 16:37

> Quand AMS 2 est sorti, de nombreux jeux en assembleur (à cette époque pratiquement tous en mode kernel) n'ont plus marché, alors que CReversi, un jeu en _nostub publié avant la sortie de AMS 2.03, a fonctionné sans modifications. L'important est surtout que les jeux ou programmes soient programmés proprement. Dans les sources de kernels et de jeux pour kernel, on trouve généralement au moins autant de saletés que dans les sources en _nostub. (Je sais que mes programmes résidents en mémoire ne sont pas un bon exemple en ce qui concerne la programmation propre, mais je n'ai utilisé les adresses absolues que là où je n'ai pas eu le choix.)

C surtout parce qu'il n'utilise aucune ressource.

>4. Pour les niveaux de gris, de nombreux programmes pour kernel (tetris par exemple) n'ont plus marché avec les nouvelles librairies pour HW2 parce qu'ils partaient du principe que plane0=LCD_MEM.
Et oui. Mais c'est a cause d'une mauvaise programmation.

>Bref, on n'est jamais à l'abri des modifications internes, quelle que soit la méthode de programmation employée (kernel ou _nostub).

Ok. Mais en kernel on peut corriger.

>Quant à l'argument de compatibilité pour les kernels, il doit faire ses preuves avec les prochaines versions de AMS.
Il a fait ses preuves avec AMS 2.05.
J'ai rien change et ca a marche directement avec le bon kernel.
Et puis pour les HW2, une mise aj our de genlib et paf tous les porgs hgenlib marchaient sur HW2.
J'ai d'ailleurs ete le premier a offrir des grays sur HW2.

> Pour l'instant, les kernels n'ont pas un passé très heureux en cette direction-là, et je trouve donc que ce n'est pas une très bonne idée de dire en ce moment que les programmes pour kernel sont plus compatibles que les programmes en _nostub.
Si. Pour AmS 2.05

>Tu sembles défendre la réécriture des ROM calls dans les librairies. (Serait-ce à cause de ta participation dans le projet LiteOS, qui vise à remplacer AMS?) Moi, je vois le fait d'intégrer dans les librairies des fonctions qui sont déjà dans la ROM comme du gaspillage (duplication d'effort et de place), donc j'urge les programmeurs à utiliser AMS partout où c'est possible. S'il vous plaît, préférez les ROM calls aux librairies (même aux librairies statiques) s'il existe des ROM calls adaptés (même si la librairie X fait gagner une dizaine de cycles du processeur, ce qui revient à des fractions de millisecondes)! N'utilisez des remplacements plus rapides que quand c'est réellement nécessaire.
Et la compatibilite Ti-92 ?

>Et puis, tant qu'il n'existe pas d'autre systèmes d'exploitation pour la TI-89/92+, "plateforme TI-89/92+" = "plateforme AMS".
Oui. Mais bon.

>En tout cas, je continuerai à utiliser et à programmer pour AMS tant que les alternatives ne seront pas à la hauteur, "à la hauteur" impliquant entre autres un calcul formel au moins aussi puissant que sous AMS.
AUssi ?
Non, plus puissant. Et sans mal en plus.

73

Le 06/07/2001 à 16:37

>Connais-tu RPN et EQW? Ce sont 2 grosses applications de mathématiques écrites en C. Et il y en a aussi de plus en plus de petites.
Je connaissais RPN. Mais pas EQW. J'ai vu sur le site de EQW les liens vers les autres applis. Mea Culpa.

>PpHd: Non, plus puissant. Et sans mal en plus.
Ah. Et tu comptes le faire toi même ?
[edit]Edité par Littleboy le 21-06-2001 à 15:52:59[/edit]

74

Le 06/07/2001 à 16:37

>PpHd

C'est quoi cette histoire de AMS 2.05? Il n'y a eu pratiquement aucun problème de compatibilité avec les programmes en _nostub. Les seuls problèmes de compatibilité du _nostub avec AMS 2.05 sont à ma connaissance:

* La disparition de OSVRegisterTimer et OSVFreeTimer. Cela affectait à ma connaissance un seul programme (Othello II), et Zeljko Juric a vite résolu le problème en réécrivant les routines.
* Les problèmes de lanceur sous HW2 AMS 2.04/2.05 (barre noire occasionnelle en l'absence de HW2Patch). Il s'agit là d'un problème très rare qui existait déjà sous AMS 2.00-2.03, mais qui n'a été repéré que très tard, et qui a été faussement attribué à AMS 2.04/2.05 au début. Ce problème a été résolu par enter_ghost_space, et pour le corriger pour d'anciens programmes, il a suffi de changer le lanceur, sans toucher au programme. On n'a même pas besoin des sources du programme pour le faire!

Comparons cela à la situation des kernels. TeOS et DoorsOS ne permettent toujours pas de faire tourner sous AMS 2.05 tous les programmes ou jeux pour kernel qui marchaient sous AMS 2.03. Seul avec Universal OS, la compatibilité est presque parfaite. (J'ai quand-même eu des problèmes avec ziplib par exemple.) Tu devrais d'ailleurs aussi tenir compte de ce fait quand tu critiques le fait que je compte kernel = 12 KO dans mes calculs.
[edit]Edité par Kevin Kofler le 21-06-2001 à 15:55:14[/edit]

75

Le 06/07/2001 à 16:37

Ca fait quand meme beaucoup de problemes pour les nostub. Surtout que les kernels n'ont subi aucun chnagement.

76

Le 06/07/2001 à 16:37

kevin, dans mon programme j'utilise les fonctions que tu a nommée, pour un imput avec curseur...
Cela peut se resumer simplement pas l'exemple de la tigcc:

#include <tigcclib.h>

int _ti89, _ti92plus;

void Action1 (void)
{
  static int Counter = 0;
  printf_xy (50, 50, "Counter1=%d  ", ++Counter);
}

void Action2 (void)
{
  static int Counter = 0;
  printf_xy (70, 70, "Counter2=%d  ", ++Counter);
}

void _main(void)
{
  OSVRegisterTimer (1, 3, Action1);
  OSVRegisterTimer (2, 10, Action2);
  ngetchx ();
  OSVFreeTimer (1);
  OSVFreeTimer (2);
}

comment devrais je faire pour que ca marche?

77

Le 06/07/2001 à 16:37

>PpHd: Ca fait quand meme beaucoup de problemes pour les nostub. Surtout que les kernels n'ont subi aucun chnagement.

Pour le _nostub, moi, je compte un seul problème dû à l'introduction de AMS 2.04 (et non pas 2.05): les 2 fonctions disparues, qui ont fait qu'un seul programme a dû être recompilé.
L'autre problème n'est pas lié à AMS 2.04/2.05, mais, comme on l'attribue souvent par erreur à ces versions (parce que même Zeljko Juric ne savait pas dès le début que c'était la même chose sous AMS 2.00-2.03), je me suis vu obligé à le mentionner ici.

Pour les kernels, le problème est justement qu'ils n'ont pas été adaptés. Universal OS ne pose pas de problèmes, mais avec DoorsOS ou TeOS, il y a des programmes (plus d'un!) qui n'ont plus fonctionné. Et certains programmes posent problème même avec Universal OS. (J'ai eu personnellement des problèmes avec Tex et avec ziplib.)
[edit]Edité par Kevin Kofler le 21-06-2001 à 19:35:19[/edit]

78

Le 06/07/2001 à 16:37

>Nhdpp: comment devrais je faire pour que ca marche?

Utiliser une version récente de TIGCC. Depuis TIGCC 0.8 ou TIGCCLIB 2.2, ces fonctions sont réimplémentées dans la librairie statique TIGCCLIB, et peuvent donc être utilisées dans tout programme en C sans aucun problème.

D'ailleurs, une des raisons pour lesquelles TI a supprimé ces 2 fonctions est qu'elles étaient boguées. L'implémentation indépendante, en plus de marcher sous AMS 2.04 et 2.05, a aussi l'avantage de fonctionner correctement.

79

Le 06/07/2001 à 16:37

je viens de tout lire c un topic tres interessant

80

Le 06/07/2001 à 16:37

kevin> merci.

81

Le 06/07/2001 à 16:37

JE NE SUIS PAS RESPONSABLE DES PROBLEMES LIES A :
- TEOS
- DOORSOS
- ZIPLIB
- TEX
- en règle générale, tout programme qui n'est pas de moi, et si un programme foire sous Universal OS, ce n'est pas forcément de la faute d'Universal OS : si c'est le cas, prouvez-le et je ferai certainement une correction

S'ils ne marchent pas correctement, c'est peut-être à cause d'une mauvaise programmation, et en aucun cas cela constitue un argument contre les kernels.

Et en ce qui concerne la compatibilité, la supériorité du mode kernel et des librairies ynamiques est indiscutable car en plus des avantages qu'ils apportent, on peut faire tout ce que vous pouvez faire en mode nostub et avec des librairies statiques. Si si, il est aussi possible de recompiler des sources si jamais le kernel n'a pas prévu une "amélioration" dans AMS.

Rien n'empêche de n'utiliser qu'AMS en mode kernel. Là encore, cela reste avantageux puisque les tables de relogements et les instructions d'appel à la rom prennent moins de place. Et vu que c'est le kernel qui reloge le code, il est aussi possible de gérer les fonctions qui disparaissent d'AMS (cela n'est pas encore fait mais c'est possible).

De toute façon, la virtualisation est une règle d'or en programmation et il semble que le nostub aille vraiment à l'encontre de ce proncipe : ce mode mélange tout et n'importe quoi, et en particulier ce qui concerne le matériel et le systme.
A mort rowread dans les programmes utilisateurs ! (ceci est un exemple parmi beaucoup d'autres...)

Il n'y a pas non plus de raisons de supposer que le mode nostub resistera mieux à une nouvelle limitation.

il a suffi de changer le lanceur
Mais quelqu'un peut-il m'expliquer pourquoi un lanceur est merveilleux et un kernel une merde ???

Je me fous aussi complètement des gens qui ont du mal à se retrouver dans le mode kernel/librairies !! C'est complètement idiot de vouloir les aider avec le concept "un logiciel = un fichier" (de toute façon, le mode notub ne l'applique même pas car un lanceur et souvent nécessaire). Certains ne savent même pas lire les quatres premières lignes de mes readme et me demandent par exemple où trouver les dernières versions.
Kevin, faut les ignorer ces gars-là !! L'aide, ça se mérite ! Et je le répète encore une fois, quand on n'est pas analphabète, il suffit de suivre des instructions pour faire marcher facilement n'importe quoi en mode kernel.

Tu devrais d'ailleurs aussi tenir compte de ce fait quand tu critiques le fait que je compte kernel = 12 KO dans mes calculs.
Et on va dire qu'Unervsal OS prend plus de place ! Vous me faites rire !!
C'est vrai, j'ai oublié qu'avec TEOS et DoorsOS, ziplib et filelib sont obligatoires, et je ne les pas comptées. Je voulais surtout les comparer Universal OS (il ne contient pas ces deux librairies) et non pas critiquer le chiffre que tu utilises. Néanmoins, pour Universal OS, tu peux quand même compter que le kernel prend 9.87 ko au lieu de 12 ko car ces librairies ne sont pas vraiment indispensables.

82

Le 06/07/2001 à 16:37

>JM: Je suis entierement d'accord avec ton opinion. Un programme se doit de ne pas acceder directement a l'ecrans, au clavier et aux link, bref a tous ce qui caracterise les ports IO. C une regle de base.

83

Le 06/07/2001 à 16:37

>PpHd: C une regle de base.

1. Et qui définit les règles de base?
2. On ne peut pas appliquer toutes les règles de programmation sur PC à la programmation sur calculatrice!
Sur une calculatrice:
2.1. il n'y a pas autant de matériel différent que sur PC. (On ne compte que 4 versions matérielles de TI-89/92+: TI-89 HW1, TI-89 HW2, TI-92+ HW1 et TI-92+ HW2, qui de plus ont beaucoup de ports I/O en commun.)
2.2. il faut économiser la place et les cycles, donc:
2.2.1. La programmation objet est à proscrire. Cf. http://tigcc.ticalc.org/doc/faq.html#5.
2.2.2. Toute virtualisation réduit la vitesse. Il y a tout l'appel de librairies à faire, y compris la relocation, et le saut jsr abs.l qui lui seul prend 20 cycles par appel.

84

Le 06/07/2001 à 16:37

>La programmation objet est à proscrire.
Pas besoin de programmation objet pour virualiser !

La moindre des choses est de faire des programmes qui marchent à la fois sous 89 et sous 92+ au niveau du clavier.

>Il y a tout l'appel de librairies à faire
On s'en fout du temps perdu à cet endroit !
Et puis même si le kernel fait plus de travial, il n'est pas plus lent à reloger un programme que cette saloperie d'AMS.

85

Le 06/07/2001 à 16:37

La relocation AMS est tres MAL faite. Suffit de lire ce code de merde pour le comprendre.
Et c pas l'appel a une libraire qui reduit la vitesse. Un port IO ne doit pas etre appelle que tous les 36 du mois. Dans le pire cas, on fait un jsr (a4).
Et puis si on programme, autant programmer proprement, non ?

86

Le 06/07/2001 à 16:37

Tout a fait d'accord avec JM & PpHd... je trouve ça etonnant que depuis le temps personne n'a eu l'idée de faire un kernel qui virtualise bien comme il faut, de maniere à pouvoir faire des programmes "binary-compatible" TI-89/92/92+ HW1/2 sans se soucier des différences.

So much code to write, so little time.

87

Le 06/07/2001 à 16:37

C'est vrai ca, on pourrais faire un nouveau format de kernel qui corrigerais les imperfections de l'actuel (maintenant qu'on a bien eu le temps de les reperer) ... allez, au boulot !

88

Le 06/07/2001 à 16:37

LE seul problème : tous les anciens programmes nécéssiteront dans le meilleur des cas une recompilation/modification pour marcher sur le nouveau format.
Je peux me tromper, mais pour faire un truc comme dit nitro faudrait vraiment refaire BCP de choses, donc forcément plein d'incompatibilités.

89

Le 06/07/2001 à 16:37

Oula... ça m'a l'air d'être un topic intéressant ça...
Je crois que je vais lire ça en entier...
en attendant quelques remarques :

Nitro : "programmes "binary-compatible" TI-89/92/92+"
Ca existe, ça s'appelle [tie], http://mxm.ticalc.org/ (ptet down, Mxm a cessé d'exister)
Pour ce qui est de la virtualisation, il n'est pas question de tout reporter sur l'OS (ou kernel comme vous voulez), on ne va pas faire un ouindaube de + (vive les boites DOS...

)
Les programmes ont un minimum de responsabilité dans la stabilité du système... sous UNIX par exemple, il est interdit (sauf au root

) d'accéder aux ports I/O ... mais ELKS (=Linux sur 8086) par exemple ne peux pas les protéger, et pourtant ça fonctionne et c'est pas le chaos parce que les programmes n'essayent pas d'y accéder.
Ce n'est pas parce qu'une chose est possible qu'il faut l'utiliser.

Ce qui me fait le plus marrer c'est que ça fait plus d'un an ( http://www.ticalc.org/archives/news/articles/3/31/31985.html ) que je parle des ce genre de problèmes mais y a pas grand monde que ça intéresse

Enfin si je suis plus tout seul à penser ça...

90

Le 06/07/2001 à 16:37

Je signales que ca fait longtemps que je suis pour. Mais j'attends encore ce kernel.