TI-89 Titanium - Page 11

Au passage d'ici 10ans on peut ptet esperer que les TI-68k utilise soit un 68040 soit un 80286

bah si c'est un 80286 c'est plus une TI68k, ou alors y a quelque chose que j'ai pas compris

Pour le projet d'ému je pourrai éventuellement donner des petits coups de main par-ci par-là, mais comme Sasume j'ai aussi des vaporwares à liquéfier

Je pense qu'il faudrait utiliser un toolkit relativement "propre" et, en tout cas, portable. Peut-être wxWindows, s'il n'y a pas de pbs de rapidité ? (je pense qu'afficher 30 images de 240x128 par seconde ne devrait pas trop poser de pb, de tte façon...)

Pollux
: Je pense qu'il faudrait utiliser un toolkit relativement "propre" et, en tout cas, portable.

Personnelement c'est pas le toolkit qui doit etre portable, mais le code en lui meme l'idéal etant de toujours utiliser les API native de l'OS/DE qu'on utilise sur le port, l'utilisation du C++ permet ça de maniere tres propre.

Donc franchement l'idéal est de completement s'affranchir d'une quelqu'on API pour le disign du programme

Oui, bien sûr. Mais tant qu'à faire, autant utiliser un toolkit _déjà_ portable (ça doit être moyennement drôle de réimplémenter tout un système de fenêtres sur toutes les plateformes possibles, même si on n'utilise qu'une fraction de ce système...). Et l'API de wxWindows est vraiment d'une simplicité biblique.

de tte deja faut voir qui est partant et comment on découpe le projet

Raaah, quel est le rapport de ces discussions avec la TI-89 Titanic ()?

wow Kevin fait de l'humour !
le rapport? bah faut un ému pour cette calc

et pas que celle la, la v200 aussi

Juste au passage, avant de faire un topic faudrait trouver un nom :/

En général, je trouve que c'est un des trucs les plus durs à faire dans un programme

Bon, petite récapitulation des résultats existants:
1. L'espace fantôme en 0x40000, 0x80000, 0x100000, 0x140000, 0x180000 et 0x1c0000 n'existe plus.
2. ROM_base est à 0x800000.
3. La limite de taille de l'assembleur est à 64 KO (pas 8 ni 24).
4. La protection anti-exécution en-dehors de cet espace de 64 KO existe toujours, la protection n'a pas été totalement désactivée.
5. Les 4 KO en 0x5000-0x5fff sont déprotégés en permanence par AMS 3.00 bêta, comme c'était déjà le cas sous AMS 2.
6. Il existe des espaces fantôme en 0x200000 et 0x400000, mais la protection anti-exécution ne se fait plus avoir malheureusement.
7. Je ne sais pas encore si les ports matériels sont toujours en 0x600000 ou s'il y a un autre espace fantôme de la RAM à cet endroit.
8. J'ai réussi à faire un lanceur ExePack en utilisant 3. et 5. (0x5000-0x5fff a une intersection assez grande avec le LCD en 0x4c00-0x5aff pour me permettre d'exécuter du code de déprotection à l'intérieur de la zone LCD. )

Bon, ça m'embête de continuer le hors-sujet, mais lisez la news d'il y a un mois sur http://tilp.info: apparemment, roms veut continuer TiLP et TiEmu après tout. (Cela dit, il s'occupera avant tout de *nix, donc pour le portage Win32, il faudra que quelqu'un d'autre s'en occupe.)

Beau boulot, Kevin.

Bon, ça m'embête de continuer le hors-sujet, mais lisez la news d'il y a un mois sur http://tilp.info: apparemment, roms veut continuer TiLP et TiEmu après tout. (Cela dit, il s'occupera avant tout de *nix, donc pour le portage Win32, il faudra que quelqu'un d'autre s'en occupe.)

C'est plustôt une bonne nouvelle ca!

Nil
: Oui, sachant que le cable de la ti est "stéréo", en bricolant un petit montage, tu peux facilement bricoler un truc pour "discuter" à 4.

Oui, avec un hub fait maison. Squalyl planche déjà là-dessus.
(Faudrait faire des cables de 10m pour jouer dans toute la classe... )

Les ports I/O n'ont pas l'air d'avoir bougé (toujours à 0x600000 et 0x700000).

Donc la présence du port USB n'est pas la cause directe de tous ces changements ?

on pourrait avoir les infos du menu About ? par exemple le Product ID et le début du serial

Vu que c'est une beta le product ID risque d'être particuier.

on sait jamais ...

Bon, en tout cas il faudra s'attendre à un modèle avec 8 Mo de ROM et > 256 ko de RAM (1 ou 2 Mo?). Je ne pense pas qu'ils créent gratuitement de telles incompatibilités...

euh... c TI

Oui, raison de plus pour qu'ils aient envie de faire du neuf avec du vieux, sans trop se casser la tête

alors qu'ils nous auraient demandé notre avis, on (certains d'entre nous en tout cas) auraient même accepté de leur sous traiter l'étude du système...

Pollux>ou de créer des incompatibilité juste pour le plaisir d'en créer
Ou alors, ils pensent pouvoir relancer la communauté en l'obligeant à tous re-programmer

Ha c'est pas con comme idée Rendre tous les progs incompatibles pour nous obliger à nous remettre au boulot C'est qu'ils sont rusés, chez TI...

Nil
: Donc la présence du port USB n'est pas la cause directe de tous ces changements ?

Non, je pense comme Pollux qu'ils ont fait ça pour préparer la plateforme à de futurs ajouts de RAM et de FlashROM. Ils ont bien besoin d'avoir de quoi faire de "nouveaux" modèles pour les 10-20 ans qui suivent.
Le ghost space à 0x40000 a probablement été viré pour nous obliger à adapter nos programmes dès maintenant. Parce qu'avec plus de RAM, tout programme qui essaye d'écrire en 0x400xx pour modifier les interruptions corrompra la RAM.
Bref, je pense que même si les changements de TI nous font souvent ch**r (même beaucoup!), ils ne sont pas entièrement sans raison.

Kevin Kofler
: Le ghost space à 0x40000 a probablement été viré pour nous obliger à adapter nos programmes dès maintenant.

C'est aussi possible qu'ils se tapent complètement des programmes asm (l'architecture est pas construite forcément par des personnes au courant de tout ça).