Le firmware NumWorks porté pour ta HP Prime !

[critor]

De rien.
On aurait lourdement mis en garde si la manipulation avait été dangereuse (y compris irréversible).

@Extra44
Voilà, testé donc ton dernier firmware sur la révision matérielle C (puisque tu n'as pas parlé d'améliorations pour la révision matérielle A).
Excellent, le mode examen fait désormais clignoter la diode rouge :


Ton portage du firmware est donc à partir de maintenant conforme pour les examens et concours français 2019, félicitations !

[ptijoz]

bonjour
question idiote ? ne peut-on pas mettre sur la Numworks une Rom de TI ?

[Lionel Debroux]

Cela pose des problèmes d'architecture matérielle et d'espace de stockage disponible. A la limite, sur la machine NumWorks, on pourrait faire émuler une 84+ non SE, et les modèles plus anciens.
En ajoutant un chip de Flash externe sur la NumWorks, la 84+SE (2 MB Flash) et la 84+CSE (4 MB Flash) deviennent accessibles. En revanche, 83PCE/84+CE et TI-68k resteraient inaccessibles (pas assez de RAM sur la machine NumWorks), et la Nspire resterait inaccessible à la fois par manque de RAM et de Flash.

[Zocipal]

Bonsoir,
Des nouveautés pour ce projet ?
Cela fonctionne avec la G2 ?
Merci !

[jean-baptiste boric]

Des nouveautés pour ce projet ?
Cela fonctionne avec la G2 ?

Non et non. J'ai arrêté de faire de l'homebrew sur HP Prime G1 parce que la combinaison de l'outillage officiel et officieux rend cela très pénible à développer et j'ai arrêté celui-là en particulier parce qu'on atteignait déjà à l'époque la limite technique du méga-octet de PRIME_OS.ROM qui ne fut jamais contourné.

Pour la G2, une personne a fait un PoC de U-Boot+Linux dessus qui serait l'option privilégiée pour exécuter des choses plutôt que de réinventer la roue, mais je suis bien trop occupé sur d'autres sujets pour me pencher dessus ces temps-ci.

[parisse]

Je déterre le topic pour poser une question liée à la limitation de PRIME_OS.ROM à 1M.
Est-ce qu'il serait possible de générer plutot un PRIME_APP.DAT qui donc ne serait pas limité à 1M?
Imaginons qu'on puisse faire tourner Upsilon+KhiCAS par exemple (ou meme Epsilon 1.6 avec une application external). Ca permettrait d'utiliser les nouveautés de KhiCAS sans attendre Moravia, ou bien des fonctionnalités impossibles à intégrer en logiciel propriétaire (par exemple intégrer GMP+MPFR+MPFI).

[parisse]

J'ai trouvé un projet qui a l'air d'aller dans ce sens
https://github.com/Project-Muteki
Je pense qu'il doit être possible de faire sur les G1 ce qui a été fait sur les 39gii avec ExistOS, mais avec un public cible nettement plus important.

[jean-baptiste boric]

Je déterre le topic pour poser une question liée à la limitation de PRIME_OS.ROM à 1M.
Est-ce qu'il serait possible de générer plutot un PRIME_APP.DAT qui donc ne serait pas limité à 1M?
Imaginons qu'on puisse faire tourner Upsilon+KhiCAS par exemple (ou meme Epsilon 1.6 avec une application external). Ca permettrait d'utiliser les nouveautés de KhiCAS sans attendre Moravia, ou bien des fonctionnalités impossibles à intégrer en logiciel propriétaire (par exemple intégrer GMP+MPFR+MPFI).

La limitation à l'époque était due au fait que Rip'Em n'avait pas de pilote pour la NAND et ne pouvait donc pas lire de données supplémentaires depuis le stockage de masse de la calculatrice. Il était alors limité au méga-octet de PRIME_OS.ROM lu par le bootloader de la calculatrice (même si le stub GDB permettait de charger des programmes en RAM via l'UART).

Les difficultés liées à l'outillage austère et les contraintes de travailler sur une calculatrice graphique physique m'avaient démotivé, mais il existe un émulateur basé sur QEMU pour la HP Prime G1 qui était suffisamment avancé de mémoire pour démarrer une vieille version béta du firmware d'origine (avant qu'un widget scroll-to-unlock ne fut ajouté au premier démarrage, nécessitant l'émulation de l'écran tactile pour le passer).

Je n'ai plus en tête tous les détails, mais de nos jours un port u-boot+Linux et exécuter ce que l'on veut par dessus serait probablement plus approprié que de tout recoder en bare-metal comme je l'avais fait à l'époque.

[parisse]

Perso, je n'ai aucune compétence pour me lancer dans un projet genre uboot+Linux.
Par contre, le fichier PRIME_APP.DAT semble assez simple: il y a 8Ko d'en-tête qui n'ont pas l'air de changer d'une fois sur l'autre, et si on copie les données qui suivent, on obtient un fichier qu'on peut monter avec mount. Donc on doit pouvoir en recréer un custom, et y changer l'exécutable programs/misc/armfir.elf pour un autre fichier ARM au format ELF généré avec une toolchain arm-gcc/newlib éventuellement modifiée (https://github.com/Project-Muteki) pour tenir compte de l'OS, en utilisant la liste de syscalls de https://github.com/Project-Muteki/muteki-shims. Il me semble qu'il faut aussi mettre à jour la liste des hash md5 (appslist.md5 à la racine du fichier monté).
Et du coup on ne serait pas limité par 1Mo et on devrait pouvoir bénéficier des drivers de l'OS. Je ne suis pas du tout un expert dans ces domaines, mais ça ne me semble pas trop difficile, ou bien j'ai manqué quelque chose?

[jean-baptiste boric]

Je ne sais pas si c'est une option viable ou non, je n'avais pas étudié le firmware original au-delà des headers de PRIME_OS.ROM.

Dans tous les cas, si j'avais à refaire ça avec mon expérience actuelle, j'aurais mené le projet de rétro-ingénierie et de développement tiers autrement... D'autant plus qu'entre temps j'ai développé des techniques et outillages particulièrement intéressants dans ce domaine, mais ça c'est une autre histoire.