Forum

Gilles59 fait en effet partie de ceux qui ont des machines réelles, comme critor et un certain nombre d'autres ailleurs qu'ici

La communauté traditionnellement TI s'intéresse beaucoup à la Prime, j'imagine que ça nous change des 84+CSE ouvertes mais lentes et des Nspire fermées au BASIC incapable d'afficher à l'écran ou de lire le clavier de manière non bloquante.
HP se débrouille bien pour attirer les bidouilleurs vers la machine ^^

Pour une entreprise, le problème de l'ASM pur est le temps de développement et debug qu'il nécessite, facilement 3-5 fois plus élevé que le développement du code C strictement équivalent...

Par ailleurs, dans le cas général, la réduction de portabilité est un autre gros défaut, mais en pratique, l'ARM est le processeur de choix pour un peu de puissance dans l'embarqué (même si certains persistent à utiliser autre chose...), donc cet argument ne s'applique pas ici.

En absolu, 32 MB de RAM n'est pas faible pour une calculatrice, bien que ce soit faible pour une plate-forme basée sur un processeur ARM.
En relatif, ce n'est pas exceptionnel par rapport à la précédente plus puissante calculatrice du marché
* Nspire Clickpad, 2007: 32 MB RAM.
* Nspire CX, 2011: 64 MB RAM.
* HP Prime, 2013: 32 MB RAM ""seulement"".

Seule solution non limitée dans le temps: l'émulateur communautaire nspire_emu http://www.omnimaga.org/index.php?topic=6763.0
En fait, c'est le seul vrai émulateur, car le logiciel officiel TI pour ordinateur, téléchargeable gratuitement mais à durée limitée dans le temps, n'est en réalité qu'une une compilation du coeur de calcul pour la plate-forme x86, avec une couche UI / input différente (qui peut être retaillée et se comporte différemment de la couche sur calculatrice, entraînant des particularités de codage pour avoir du code qui fonctionne sur machine réelle et sur le logiciel de TI, bref).

Avec nspire_emu, puisque c'est une CX CAS que tu veux émuler, tu devras trouver, d'une façon ou d'une autre, un boot1 de CX, vu que le boot2 des CX, partiellement chiffré, est déchiffré par le boot1 (comme si ça empêchait le reverse-engineering... en tout cas, le déchiffrage ralentit le boot de la machine). Ca n'était pas nécessaire pour les Clickpad et Touchpad, on pouvait directement démarrer à partir des OS upgrades téléchargeables depuis le site de TI.
Il existe un howto en français qui gagne du temps pour la mise en place de nspire_emu, mais poster des liens vers son site d'origine est interdit ici.

Cela veut-il dire qu'on peut créer des menus, fenêtres, listes déroulantes, boutons, champs texte... ?

Oui, voir entre autres http://www.omnimaga.org/index.php?topic=13849.0 (recodage du EEPro des TI-68k pour Nspire en Lua) ou http://www.omnimaga.org/index.php?topic=16597.0 (éditeur de Lua en Lua)
En BASIC Nspire, c'est malheureusement impossible comme tu le soulignes, alors que le BASIC TI-68k (production de la toute fin du XXème siècle) permettait de faire des menus, et des dialogs avec listes déroulantes et champs texte. Pour être complet, signalons que sur TI-68k, le code natif permet l'utilisation de fenêtres, ainsi que des dialogs avec boutons (dont boutons radio), même si on ne le fait presque jamais pour des raisons de performance. Sur Nspire, la documentation du back-end code natif des éléments d'UI Lua est partielle, et de mémoire, là aussi, le Lua ne donne pas accès à tout.
Pour plus d'infos sur la programmation sur calculatrices TI, les sites de référence (projets et news) sont Omnimaga, Cemetech et TI-Planet, avec quelques différences: par exemple, Cemetech est habituellement plus orienté TI-Z80 et ne s'intéresse pas aux Nspire.

Pour avoir avancé un peu un vieux portage de Lua sur TI-68k ( http://www.omnimaga.org/index.php?topic=9228.0 ), je confirme que c'est extensible et plutôt léger. Bien entendu, pour le calcul brut, Lua reste quand même très loin derrière le code natif, voir les benchmarks de LuaJIT (sur x86 / x86_64 et ARM, plus de la moitié des benchmarks sont un à deux ordres de grandeur plus rapides avec un JIT), et le JIT n'est, sauf exception (paraît-il que certaines VMs avancées, comme la VM Java, y arrivent parfois), pas aussi bon que du code natif AOT.

Je ne sais pas quelle est l'étendue du support sur Nspire, mais sur Palm et PSP c'était assez sympa.

L'étendue du support a de gros trous sur Nspire, au premier rang desquels io.* et os.* (soupir).
En revanche, il y a le framework spécifique plate-forme de programmation graphique événementielle (dont lecture au clavier) entrevu plus haut, pas inintéressant. Le format non standard et inefficace d'images qui lui est associé (soupir) coûte en taille et certainement en performance.

Pourquoi toujours vouloir avoir de la vitesse ? pour faire de l'émulation et faire tourner des roms de jeux de console ?

Les jeux font clairement partie des utilisations de la vitesse CPU, de la quantité de RAM et de la quantité de stockage persistant... mais pas seulement
Avoir plus de puissance brute permet aussi d'avoir le même résultat en moins de temps (et si on utilise des composants plus récents, ça ne consomme pas forcément plus sur l'alimentation piles / batteries). Et pour ça, le fait est que la fx-CP400 de 2013 est plus mal équipée qu'une Nspire de 2007, alors qu'elle doit se coller des choses comme la gestion d'un écran comportant plus de pixels, une profondeur de couleur plus importante et du touch (plutôt qu'un écran niveaux de gris utilisé en 4 bpp et un classique clavier à matrice sur port hardware, le touchpad sur I2C ou SPI n'étant apparu que plus tard sur Nspire), choses pour lesquelles le matériel supérieur des Nspire CX de 2011 est le bienvenu.

Autre évidence: tout le temps passé à optimiser pour faire rentrer ce qu'on veut dans les limitations de la plate-forme (ce qui a des impacts négatifs sur plusieurs autres aspects dits "non fonctionnels" du processus de développement logiciel: portabilité, maintenabilité, et j'en passe) n'est pas passé à développer les fonctionnalités. Tous les hobbyistes passionnés comme nous en sommes conscients (ou devraient l'être), et nous tendons à placer le curseur beaucoup plus du côté de l'optimisation que les professionnels du développement logiciel (ce que certains d'entre nous sont le jour) employés chez les fabricants de calculatrices ou ailleurs...
Les concurrents dont les contraintes matérielles sont moins élevées peuvent passer une proportion plus élevée de leur temps à développer les fonctionnalités. Ca peut s'avérer important

qui propose des éléments vraiment intéressants : transferts comme avec une clé USB

L'utilisation d'une classe USB standard, qui plus est une classe aussi répandue que Mass Storage Device, est une excellente chose, je suis tout à fait d'accord. TI, HP et les autres devraient en prendre de la graine. Certes, les protocoles non standard occupent, au fil des âges, les développeurs de logiciels de transfert tiers... mais là aussi, le temps qu'ils doivent passer à faire du reverse-engineering sur des protocoles non documentés et à l'implémentation de code compatible côté ordinateur (plus portable et sous une licence plus permissive, au passage), n'est pas passé au développement d'autres programmes.

langage évolué et une compatibilité avec les basics Casio des autres modèles qui lui confère d'emblée une Enorme bibliothèque...

Peut-être pas si énorme, comme l'écrit gege - et puis l'abondance de la logithèque, au premier ordre, suit la diffusion des modèles sur le marché et les limitations des fonctionnalités des calculatrices.

Les tests de Cncalc chez Casio Shangai, relayés sur TI-Planet puis Omnimaga, montraient des performances décevantes en Basic sur un benchmark simple, d'autant plus incompréhensibles que la machine est vraiment chère. Les limitations étaient attendues sur le long terme, les caractéristiques techniques de la fx-CP400 étant nettement surclassées par les Nspire de 2007, les Nspire CX de 2011 et les Prime de 2013. Il reste certainement de la place pour l'optimisation sur la fx-CP400, d'autant que la Nspire a quelques inefficacités crasses, mais ça ne compensera pas la différence brute de matériel vis à vis des Nspire récentes, des Prime, et des futurs modèles de TI.

En revanche, dans la communauté habituellement TI, les gens sont très intéressés par la Prime

Peut-on faire du calcul avec le CAS et utiliser des types plus compliqués que les nombres (calcul matriciel, solve, manipulation d'expressions) ?

Oui, le Lua a accès à la fonction d'évaluation du BASIC et aux variables du document.

Et pour faire des jeux interactifs, n'importe quoi est plus performant qu'une Nspire... (hors Lua).

Je sais que tu connais suffisamment bien les machines pour ne pas vouloir écrire ça au premier degré, mais ce que tu écris, tel que tu l'écris, pourrait être mal interprété

* avec l'incompréhensiblement horrible programmation BASIC, en effet, à peu près n'importe quoi est plus performant qu'une Nspire, malheureusement.
* avec le Lua (pas fait pour être programmé on-calc...), les Nspire permettent de faire des choses plus avancées et plus rapides que certaines machines qui mettent des centaines de ms à faire des opérations graphiques simples (c'est le cas de plusieurs Casio, dont la Prizm, pour ce que j'ai lu; la 84+CSE n'en est pas tout à fait là, mais ce n'est pas brillant).
* avec le code natif, quand il est accessible... à l'heure actuelle, aucune calculatrice ne s'approche des Nspire, qui tournent un portage assez direct de DOOM, divers émulateurs, un portage de SDL et la gestion du C++ (qui permet de porter bien plus de programmes)... sans parler bien sûr de tout le userspace théoriquement permis par Linux. Le processeur plus puissant de la future HP Prime

Je n'ai pas encore vu d'info à ce sujet ici, donc je cross-poste

Sur Casiopeia, il y a quelques jours, Helder7 a publié un test de la fx-CP400 qu'il s'est procurée: http://www.casiopeia.net/forum/viewtopic.php?f=2&t=1571



Il fait même un petit programme que tout le monde reconnaîtra


Ceci est un résumé d'un post de critor sur notre site. J'y ajouterai à titre personnel que les caractéristiques techniques de la machine sont en-dessous de celles des Nspire de 2007, et l'écart est encore plus grand avec les Nspire CX de 2011 et les futures Prime de 2013.

La machine est très lente à l'utilisation, en effet. Essaie aussi de te déplacer dans un programme BASIC un peu long, tu vas voir
Les calculs de la communauté des développeurs, sur Cemetech, montraient que le fill rate de l'écran complet à pleine résolution (un mode demi-résolution horizontale a été trouvé) ne peut pas dépasser 7 FPS environ sur la 84+CSE - et encore, c'est si tout l'écran est dessiné de la même couleur.

Okinawok: c'est une info, voir http://www.omnimaga.org/index.php?topic=16517.0

Même si je suis d'accord avec toi et que ce n'est pas toi qui as introduit ce hors-sujet, ce n'est pas le sujet, critor

Mic a écrit :On peut personnaliser le thème de l'OS contrairement à la TI-Nspire !!

J'imagine que tu veux dire par là qu'il y a officiellement un outil pour ce faire.? Ca fait deux ans que les OS Nspire contiennent de quoi personnaliser le thème (et il y a un outil pour changer le thème dans un OS prototype, voir http://www.omnimaga.org/index.php?topic=13132.0 ), même si l'outil on-calc non officiel n'existe que depuis un an environ ( http://www.omnimaga.org/index.php?topic=13932.0 ).
Bref, autant il y a des choses intéressantes et novatrices dans la Prime, autant celle-là n'en est ni novatrice ni impressionnante

gege a écrit :Pourras-tu donner un aperçu de la programmation et de ce qui est possible, au hasard capture de touches au clavier, dessin à l'écran, input en cours de programme ?
(tiens, c'est marrant, la Nspire ne sait rien faire de tout ça )

En BASIC, en effet, elle ne sait malheureusement toujours pas faire, et ne saura certainement jamais faire. En Lua, elle sait faire, mais le Lua n'est pas très agréable à programmer on-calc...

Mic a écrit :Prizm : Mémoire RAM: 61 ko
Prime : Mémoire RAM: 32 Mo

Tu compares la mémoire disponible et la mémoire totale, ta comparaison n'est pas juste (équitable)...
Cependant, même si on compare les mémoires totales, la Prizm est très inférieure, techniquement, aux Nspire et aux Prime.