Punix sur une vraie calc ! - Page 1

Le développeur de Punix l'a installé sur sa ti92+ : http://punix-os.blogspot.com/2012/03/first-time-real-calc.html et ça marchotte.
C'est sympa, ça avance bien

Bon moi je vais pas prendre le risque de briquer ma v200 ^^

joli, joli

oO (ça change des linux.89p )

justement, j'ai du mal à saisir sur son site : c'est tout un shell+os ou juste un shell ?

apparemment tout un shell+os

About Punix
Punix is a Unix-like operating system for the Motorola M68000-based TI graphing calculators, starting with the TI-92+. It is currently under development and is not ready for widespread use yet. So far the kernel is being written, and user-space utilities and applications will follow. Here are some of the key features that the kernel supports:[ul][li]Preemptive multitasking
[li]Virtual terminal on the console
[li]Linking to a computer or another calculator via the I/O link port[li]Playing audio via the link port![/ul]Please read the pages in the Links section for more information.

ouioui c'est un OS, donc à mettre à la place d'AMS ou de PedroM

Dans TiEmu, il suffit de choisir le .tib comme OS, et ça démarre

Ça m'étonne ces questions, je pensais que le projet était plus connu que ça ici !
Surtout, comme ma première source d'information autour des TI est toujours yN, j'ai forcément eu connaissance de ce projet par un lien (ou un lien d'un lien d'un lien) depuis yN.

Télécharger Punix : http://sourceforge.net/projects/punix/files/betas/

Le Readme : http://sourceforge.net/projects/punix/files/betas/README.txt/download

Je cite :

Readme for Punix (beta)
by Christopher Williams

Getting started
===============

Download one of the TIB files (such as punix-9x-beta0.tib) and open
it as a ROM or basecode in your favorite TI-92+ emulator […]

*WARNING: do not send this to a real calculator! It might brick your calculator!

What does Punix do? […]
===============

* Run a small number of (simplified) Unix utilities (sh, top, cat,
true, false, clear, uname, env, id, date)
* Play sound! (Run "tests" from the shell and type Control-D until
you get to the /dev/audio test)

[…] As of beta 3, Punix can do full multi-tasking. That said, you can't
run any real programs because there is no file system yet. […]

Désolé pour moi c'est Prosit qui est connu, pas Punix

Pareil pour moi, question d'époque

Ou LiteOs

Je connaissais. J'avais lu les sources les sources il y a un moment. Le boot est celui de PedroM (et c'est rassurant ^^)

Sur ticalc on trouve une vieille archive de 2005, dont le contenu fait référence explicite à pedrom.
http://www.ticalc.org/archives/files/fileinfo/366/36671.html

Sur Cemetech on lit que le projet date de 2004, déjà !
http://www.cemetech.net/forum/viewtopic.php?p=174463#174463

Il y a des trucs sympa sur ce forum, notamment un début d'OS pour les ti z80 :
http://cemetech.net/programs/index.php?mode=file&path=/83plus/asm/AsmOS.zip
et le dev de punix a fait la même chose pour les 68k :
http://www.cemetech.net/programs/index.php?mode=file&id=682

Je vois que Lionel Debroux fréquente ce forum :
http://www.cemetech.net/forum/viewtopic.php?p=174653#174653
donc je suppose que j'ai connu punix ainsi : yN → GCC4TI → Punny Unix
Par exemple : topics/130768-whats-new-in-gcc4ti

Je suis un des rares anciens de yAronet (moins que d'autres, mais ça fait plus de dix ans que je suis là ) à fréquenter régulièrement les autres forums de la communauté.

Il y a en effet beaucoup de choses, parmi lesquelles pas mal de choses sympa, sur Omnimaga (principalement TI-Z80 BASIC/Axe et Nspire) et Cemetech (principalement TI-Z80 ASM et Prizm).

Il y a en effet beaucoup de choses, parmi lesquelles pas mal de choses sympa, sur Omnimaga (principalement TI-Z80 BASIC/Axe et Nspire) et Cemetech (principalement TI-Z80 ASM et Prizm).

Oui d'ailleurs, je suis étonné de voir le développement qu'il y a sur la plate-forme z80 !
J'ai du avoir ma ti83+ en 2000, et ma v200 en 2002, et à l'époque, javais du mal à trouver des trucs pour la ti83+, l'essentiel du développement semblait tourner autour des 68k. Puis le bac est passé, ma v200 était en panne, je n'en avais pas non plus besoin pour l'école, j'ai refilé ma ti83+… Et je n'ai fait que suivre les nouvelles par curiosité, et puis la tendance s'est inversé : je voyais plus de nouvelles pour ti z80 que pour ti 68k, et pour les z80, plus que lorsque je l'utilisais.

Aujourd'hui, j'ai l'impression que l'essentiel du développement se retrouve entre nSpire et les diverses z80, et que le dev 68k est au point mort. C'est dommage. J'ai l'impression que les histoires autour de TIGCC/GCC4TI (tiemu, tilp…) ont causé beaucoup de tord.

Par exemple, je ne sais pas trop par où commencer pour pouvoir me repencher sur ma v200, au niveau logiciel sur pc : je viens d'installer le dépot calcforge sur une fedora installée exprès pour ça, tout les programmes que j'ai voulu utiliser ont segfaulté, bref . Finalement j'ai trouvé pour ubuntu un vieil installeur pour gcc4ti et ça a marché (mis à part un bug vite corrigé), et pour tilp et tiemu j'ai de veilles versions moisies et buggées…

Quand je regarde les sites d'archives de programes pour 68k, j'ai l'impression que rien n'a bougé depuis 2004. Je ne vois aucune nouveauté, seulement des màj… C'est pour ça que je m'intéresse aux quelques trucs qui sortent du lot (et qui sont vivants) comme le présent punix.

illwieckz (./16) :
Aujourd'hui, j'ai l'impression que l'essentiel du développement se retrouve entre nSpire et les diverses z80, et que le dev 68k est au point mort. C'est dommage. J'ai l'impression que les histoires autour de TIGCC/GCC4TI (tiemu, tilp…) ont causé beaucoup de tord.

Ne te trompe pas : s'il y en a eu pour enculer des mouches à ce sujet, c'est que c'était déjà mort et que ça ne codait plus... si ça avait codé, ça n'aurait pas fait autant de bruit.
Le dev 68k est assez particulier, parce qu'il représente une génération de calculatrices qui n'est plus distribuée (alors que les z80 le sont toujours et le sont depuis bientôt quoi... 22 ans ?). Le dev nSpire est aussi assez particulier (jeune, très spécifique, plateforme hybride...).
En outre, autant les TI z80 ont une large distribution mondiale, autant les TI 68k ont eu une histoire assez fermée (essentiellement USA, et encore relativement peu en pourcentage, et France parce qu'il y a eu des rapprochements commerciaux entre certains lycées/enseignants et TI ; pour les autres pays, on les retrouvait plutôt dans l'universitaire - pas dans l'équivalent de notre secondaire, quoi - donc avec des gens qui pensent un peu moins à glander en maths ).

Nil (./17) :
Ne te trompe pas : s'il y en a eu pour enculer des mouches à ce sujet, c'est que c'était déjà mort et que ça ne codait plus... si ça avait codé, ça n'aurait pas fait autant de bruit.

C'est crédible

Le dev 68k est assez particulier, parce qu'il représente une génération de calculatrices qui n'est plus distribuée (alors que les z80 le sont toujours et le sont depuis bientôt quoi... 22 ans ?).

C'est sur qu'avec tout les dérivés qui ne cessent de sortir (ti82 stats…), et la nSpire qui émule le z80 sur la version non-cas, c'est une archi pérenne !

En outre, autant les TI z80 ont une large distribution mondiale, autant les TI 68k ont eu une histoire assez fermée

Par contre je ne savais pas que l'archi 68k était plus confidentielle, et peut-être même une exception nationale. En effet quand j'étais lycéen, les 68k étaient le passage obligé si on voulait faire plus que des maths avec !

Et ceux qui se satisfaisaient d'une ti 82/83(+) étaient de la même catégorie que ceux qui se satisfaisaient d'une casio : quand ils écrivaient des programmes basic c'était déjà le bout du monde, et donc dans la culture ambiante, même si c'était possible, on n'attendait pas grand chose du dev sur z80. C'est pourquoi, naïvement, j'ai été surpris de voir précisément cette archi décoller aussi bien !

illwieckz (./18) :
Et ceux qui se satisfaisaient d'une ti 82/83(+) étaient de la même catégorie que ceux qui se satisfaisaient d'une casio : quand ils écrivaient des programmes basic c'était déjà le bout du monde, et donc dans la culture ambiante, même si c'était possible, on n'attendait pas grand chose du dev sur z80.

Alors là je ne suis pas d'accord : j'ai eu une TI-83 (le premier modèle, avec juste 32 Ko de RAM et pas de mémoire Flash du tout), et je ne te permets pas de me comparer à un Casioïste

Pourquoi la 83 plutôt que la 89 ? Hé ben c'est simple, le prix tout simplement. C'était pas donné, et quand tu achètes ça en 1ère ou en Terminale et que l'école que tu vises après le bac interdit les calculatrices graphiques, tu réfléchis à deux fois avant d'investir une somme pour une calc qui va te servir seulement 1 an ou 2. Ça n'empêche pas que j'ai utilisé et codé de l'assembleur dessus

Zerosquare (./19) :
Alors là je ne suis pas d'accord : j'ai eu une TI-83 (le premier modèle, avec juste 32 Ko de RAM et pas de mémoire Flash du tout), et je ne te permets pas de me comparer à un Casioïste

J'attendais la première réaction

De fait, le premier jeu en assembleur auquel j'ai joué sur ti fut penguins sur une ti83 (pas +)
Et avant d'avoir ma v200 j'en ai fait des choses avec ma 83+, mais force est de constater que dans les différentes écoles que j'ai fait, la majorité des gens passaient directement à la 89 (s'ils le pouvaient bien entendue ) quand ils voulaient geeker avec leur calc.

Tant mieux si cette archi est moins délaissée qu'avant .

D'ailleurs, il y a toujours eu une certaine distance entre les communautés ti z80 et 68k, moindre qu'envers les casio, mais une forme d'élitisme tout de même. Il n'y a qu'à voir sur yN où le forum z80 n'est pas évident à trouver, tandis que lorsque la nSpire est apparue, elle a rejoint le forum 68k. Donc la différence d'archi n'était pas un argument qui justifiait la séparation des forums, peut-être le public.

illwieckz (./20) :
D'ailleurs, il y a toujours eu une certaine distance entre les communautés ti z80 et 68k, moindre qu'envers les casio, mais une forme d'élitisme tout de même. Il n'y a qu'à voir sur yN où le forum z80 n'est pas évident à trouver, tandis que lorsque la nSpire est apparue, elle a rejoint le forum 68k. Donc la différence d'archi n'était pas un argument qui justifiait la séparation des forums, peut-être le public.

J'allais dire que la nSpire représente la succession de la 89, mais en y réfléchissant ça n'est vrai que pour la nSpire CAS. La non-CAS s'inscrit quant à elle dans la continuité de la lignée des Z80, de manière encore plus directe puisqu'elle incorpore un émulateur de TI-84+.

Aujourd'hui, j'ai l'impression que l'essentiel du développement se retrouve entre nSpire et les diverses z80, et que le dev 68k est au point mort. C'est dommage. J'ai l'impression que les histoires autour de TIGCC/GCC4TI (tiemu, tilp…) ont causé beaucoup de tord.

Comme l'a indiqué Nil, c'était déjà mort bien avant, quelque part vers 2006-2007. GCC4TI, deux ans après, n'a rien réveillé, mais presque tous les programmeurs TI-68k actifs sont passés à GCC4TI. GCC4TI a plus de features et d'optimisations, et moins de bugs, que TIGCC, tout en disposant de scripts d'installation bien plus portables (Linux muni de bash n'est pas la seule plate-forme dont se préoccupent véritablement les scripts...) et plus sains (arrêt à la première erreur, plutôt que de laisser silencieusement un build incomplet se dérouler).

Par exemple, je ne sais pas trop par où commencer pour pouvoir me repencher sur ma v200, au niveau logiciel sur pc

En tout cas, surtout pas par la source de logiciels que tu as utilisée, qui ne distribue que des logiciels anciens, non maintenus depuis deux à trois ans - elle est à éviter
Pour la distribution Linux que tu as choisie, tu n'as pas trop le choix: compiler à la main
https://github.com/debrouxl/gcc4ti (voir le README pour compiler la version Git, qui apporte pas mal d'améliorations depuis GCC4TI 0.96 Beta 10)
http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh (voir le contenu du script pour la liste des build-deps, fournie par nom de logiciel, nom de package Debian et nom de package Fedora)
http://lpg.ticalc.org/prj_tiemu/downloads/install_tiemu.sh (idem, même si je n'ai pas pris le temps d'y porter les dernières améliorations d'install_tilp.sh, TIEmu étant beaucoup moins utilisé)

Tu pourrais toujours essayer, sans garantie, les packages pour OpenSUSE qui ont récemment été créés (ceux de "DrSir" sont peut-être un poil plus récents ?): libticonv, libtifiles, libticables, libticalcs, gfm, tilp.
Mais il te restera de toute façon à compiler GCC4TI (le processus en deux étapes hérité de TIGCC reste merdique, mais les scripts sont mieux faits et la procédure pour construire depuis Git est maintenant décrite) et TIEmu.

Par contre je ne savais pas que l'archi 68k était plus confidentielle, et peut-être même une exception nationale. En effet quand j'étais lycéen, les 68k étaient le passage obligé si on voulait faire plus que des maths avec !

Nombreux sont les pays, dans le monde, possédant des examens déconnectés de l'usage dans le monde réel, où le CAS est interdit. Dans ces pays, les TI-68k ont toujours été confidentielles, et les modèles CAS de la famille Nspire (ceux qui sont explicitement vendus, plus cher, comme CAS - les modèles vendus, moins cher, comme non CAS sont pourtant tout à fait capables de tourner l'OS CAS...) aussi.

Quand je regarde les sites d'archives de programes pour 68k, j'ai l'impression que rien n'a bougé depuis 2004. Je ne vois aucune nouveauté, seulement des màj…

Les nouveautés sont épisodiques depuis 2006-2007, mais il y en a
Actuellement, les sites qu'il faut consulter pour savoir ce qui se passe sont Omnimaga et Cemetech pour les news anglophones, TI-Planet pour les news francophones. Le newsing de ticalc.org n'est plus très actif, même avec le newser ajouté à l'équipe il y a quelques mois.

personne n'a pensé à porter Axe Parser sur ti68k et sur Nspire?

non, je fais déja trop de trucs pour attaquer ça

Il y a déjà des choses comme Newprog, sans même parler de GFA-Basic et autres

non, je parlais d'un interpréteur *compatible* avec le parser existant

Lionel Debroux (./22) :

Pour la distribution Linux que tu as choisie, tu n'as pas trop le choix: compiler à la main
https://github.com/debrouxl/gcc4ti (voir le README pour compiler la version Git, qui apporte pas mal d'améliorations depuis GCC4TI 0.96 Beta 10)
http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh (voir le contenu du script pour la liste des build-deps, fournie par nom de logiciel, nom de package Debian et nom de package Fedora)
http://lpg.ticalc.org/prj_tiemu/downloads/install_tiemu.sh (idem, même si je n'ai pas pris le temps d'y porter les dernières améliorations d'install_tilp.sh, TIEmu étant beaucoup moins utilisé)

Tu pourrais toujours essayer, sans garantie, les packages pour OpenSUSE qui ont récemment été créés

En fait je tourne quotidiennement sur ubuntu ou debian, je n'ai installé une fedora que pour le dépot calcforge : je n'avais pas envie de compiler et j'ai installé fedora dans une vm et je comptais ensuite utiliser la distrib dans un chroot pour partager le même noyau que ma distrib et ainsi avoir accès au périphériques… Bha je suis pas allé plus loin que l'installation des paquets… si même dans une distrib toute neuve dans sa propre machine ça marche pas, j'ai pas envie d'essayer de faire des trucs tordus en croisant les distrib.

À vrai dire, peut importe l'un ou l'autre des forks, juste que le dépot calcforge est le premier que j'ai trouvé, s'il y a un dépot opensuse pour tilp et le reste, je peux toujours essayer d'installer une opensuse si je ne veux pas compiler !
Pour le moment j'ai un gcc4ti qui fonctionne grâce à l'installeur pour ubuntu (je confirme qu'il marche toujours avec une 11.10 64bit, même si elle était prévue pour 9.4 32bit, si ce n'est un bug vite corrigé), j'ai pu compiler un pedrom + preos + maylib sans souci, juste un bug dans la procédure de preos (à remonter, aussi ).

D'ailleurs j'ai trouvé le bug tracker de gcc4ti sur le redmine de Godzil, mais où faut-il rapporter les bugs concernant preos ?

je n'avait pas vu les scripts de compilations, mais j'ai envie de dire, si je compile, autant faire un dépôt, non ?

illwieckz (./26) :
D'ailleurs j'ai trouvé le bug tracker de gcc4ti sur le redmine de Godzil, mais où faut-il rapporter les bugs concernant preos ?

Ben là ?

Bon j'ai mit ça là : topics/147184-quelques-problemes-de-compilation-autour-de-pedrom-et-de-preos

À vrai dire, peut importe l'un ou l'autre des forks

libti*/gfm/tilp sont maintenus et reçoivent des contributions externes, et comportent des dizaines de bugfixes et features que leurs inutiles forks hostiles, non maintenus depuis bientôt deux ans, sans contributions externes, ne comportent pas

mais j'ai envie de dire, si je compile, autant faire un dépôt, non ?

Les dépôts non officiels sont peu utiles, et il est impossible de packager GCC4TI dans un repo officiel:
* compiler et packager GCC4TI est moins difficile que compiler et packager TIGCC, mais ce processus reste moins facile qu'il devrait l'être, malgré les améliorations des scripts dans GCC4TI;
* l'arborescence de fichiers historique de TIGCC/GCC4TI viole plusieurs guidelines de packaging. Un soft bien élevé ne nécessite pas la définition de variables d'environnement ($TIGCC) pour fonctionner, s'intègre avec l'arborescence du système plutôt que de tout installer dans son propre répertoire, peut être installé dans /usr/bin ou /usr/local/bin sans rentrer gravement en conflit avec les exécutables de base du système (gcc, as et autres - ce point-là est corrigé dans GCC4TI Git), etc.


Le principal élément restant sur la todo list de GCC4TI est justement de rendre sain le système de build, pour réduire très fortement la barrière héritée entre mainteneur et utilisateur
Une telle barrière mise en place par le mainteneur est efficace pour se rendre indispensable, surtout si le mainteneur prend soin de ne pas la documenter, mais nuisible.

Lionel Debroux (./29) :
il est impossible de packager GCC4TI dans un repo officiel:
* compiler et packager GCC4TI est moins difficile que compiler et packager TIGCC, mais ce processus reste moins facile qu'il devrait l'être, malgré les améliorations des scripts dans GCC4TI;
* l'arborescence de fichiers historique de TIGCC/GCC4TI viole plusieurs guidelines de packaging. Un soft bien élevé ne nécessite pas la définition de variables d'environnement ($TIGCC) pour fonctionner, s'intègre avec l'arborescence du système plutôt que de tout installer dans son propre répertoire, peut être installé dans /usr/bin ou /usr/local/bin sans rentrer gravement en conflit avec les exécutables de base du système (gcc, as et autres - ce point-là est corrigé dans GCC4TI Git), etc.

ah ouai ok
En effet, l'exemple de la variable d'environnement est explicite, si tout les programmes faisaient ça, ce serai très vite dégueu !

Le principal élément restant sur la todo list de GCC4TI est justement de rendre sain le système de build, pour réduire très fortement la barrière héritée entre mainteneur et utilisateur

Ah oui ce serai bien, et pour réduire encore plus la barrière, pouvoir proposer de vrais paquets

Sinon, j'en profite parce qu'on en parle, quand j'essaie de compiler tiemu avec le script cité plus haut, j'obtiens cette erreur :

configure: error: can only configure for one host and one target at a time
configure: error: /bin/bash '../.././sim/m68k/configure' failed for m68k

Une idée ?