Posté le 10/04/2013 à 21:53Edité par Folco le 11/04/2013 à 18:59 Membre depuis le 18/06/2001, -26081 message
Je pense depuis longtemps à pouvoir faire tourner des programmes PedroM-only sous AMS, parce que c'est pas possible de le faire. Voici le fruit des mes réflexions, que j'ai soumises sur IRC :
[10/04/2013 21:38:58] <Folco> Je crois que j'ai trouvé le moyen de faire tourner des programmes PedroM-only sous AMS, et ce sans hacker
[10/04/2013 21:39:05] <Folco> Evidemment, c'est un sacré trick
[10/04/2013 21:39:33] <Folco> Il faut écrire un programme appelé pedrom, qui exporte les fonctions de la libc de PedroM
[10/04/2013 21:41:35] <Folco> Quand un programme détecte AMS alors qu'il est PedroM-only (ro, pas de relogement, argv/argc, extension ram_throw)
[10/04/2013 21:42:33] <Folco> il appelle le programme pedrom via le vecteur $34 (kernel::exec)
[10/04/2013 21:44:23] <Kevin_Kofler> Et ton programme "pedrom" doit déprotéger la FlashROM en exécution pour que ça marche…
[10/04/2013 21:45:11] <Folco> pedrom s'auto-référence en tant que lib via Libs::Begin, modifie la signature du kernel, redirige rom_throw, crée argc/argv
[10/04/2013 21:45:45] <Kevin_Kofler> Oui, mais il doit aussi copier le programme en RAM (même s'il dit être ro) si la FlashROM n'est pas déprotégée.
[10/04/2013 21:45:57] <Kevin_Kofler> Sinon, bonjour barre noire. ^^
[10/04/2013 21:46:21] <Folco> Ah, donc un programme en ro ne peut pas se lancer sous AMS ? Faut que PpHd le recopie au moins en RAM sous AMS
[10/04/2013 21:46:32] <Folco> Parce que sinon, c'est mort d'entrée effectivement
[10/04/2013 21:46:50] <Kevin_Kofler> L'idée de ro est que c'est fait pour les libs de données, pas pour du code.
[10/04/2013 21:46:57] <Kevin_Kofler> Du moins à la base.
[10/04/2013 21:47:07] <Folco> Yep. Mais j'ai étendu la base grin
[10/04/2013 21:47:18] <Kevin_Kofler> Faudrait un flag "ro sous PedroM seulement", mais je ne sais pas s'il reste des flags disponibles…
[10/04/2013 21:47:31] <Folco> Tu m'autorises à poster cette conversation, ce post exclu, sur yN, pour avoir des avis, dont celui de PpHd ?
[10/04/2013 21:47:38] <Folco> Je crois qu'il reste un flag
[10/04/2013 21:48:28] <Folco> Oui, le bit 7 des flags est libre
[10/04/2013 21:48:34] <Kevin_Kofler> Il n'y a que 8 flags en tout il me semble, mais il se peut bien qu'il y en ait effectivement un de libre.
[10/04/2013 21:48:45] <Folco> (je viens de vérifier)
[10/04/2013 21:49:33] <Kevin_Kofler> OK[10/04/2013 21:49:51] <Folco> Merci. J'inclue les lignes sur le flag.

[10/04/2013 21:51:14] <Kevin_Kofler> Et tu peux poster cette discussion sur yN, il n'y a rien de problématique dedans (enfin, j'espère qu'on n'aura pas droit à des trolls sur le code de déprotection :-/ ).
[10/04/2013 21:51:51] <Folco> Ah, le OK était pour les flags. Merci alors grin

PpHd, quid d'un flag ro pedrom-only ? Quid de recopier en RAM les programmes ro sous AMS, sans rien y changer pour autant (relogements éventuels, BSS, etc...) ? Parce qu'en fait, un programme PedroM-only pouvant être ro, il est même pas lançable sous AMS s'il est archivé...
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 10/04/2013 à 22:12 Membre depuis le 27/04/2006, 60479 messages
Sacré Folco grin
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 10/04/2013 à 22:12 Membre depuis le 10/06/2001, 40269 messages
Call : PpHd appelé(e) sur ce topic...
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 11/04/2013 à 10:33 Membre depuis le 13/06/2001, 73049 messages
Zerosquare (./2) :
Sacré Folco
Pas mieux grin
avatar
Posté le 12/04/2013 à 23:22 Membre depuis le 18/06/2001, -26081 message
En fait, il est étonnant que PreOS soit designé pour permettre l'exécution en ROM. Si le but premier est en effet de récupérer des données en ROM sans passer par la RAM, très bien. C'est très bien vu. Mais à ce moment-là, on a juste besoin d'un pointeur sur les données. Et le seul moyen de récupérer ce pointeur par ce biais à une époque était un relogement. PreOS a fait mieux : kernel::LibsPtr. On évite le relogement, et le kernel garde le travail de fournir le pointeur.
J'ai exploité ça dans PedroM, car avec la ROM déprotégée en exécution, on peut alors écrire des programmes sans relogements exécutable en ROM. Gros progrès grâce à PedroM.
Mais du coup, impossible d'avoir une compatibilité binaire entre un programme designé pour PedroM et un pour AMS, car ça va planter à la première instruction de _main, et ça c'est très dommage.

La solution qui me paraitrait la plus propre :
- ne pas tenir compte du flag ro sous AMS, dans le cas d'un kernel::exec, kernel::LibsExec ou kernel::LibsCall, car nécessairement ça va planter, on le sait d'avance.
- laisser le programme en ROM s'il est ro lors d'un kernel::LibsPtr, ou d'un relogement à résoudre, car ça ressemble tout à fait à de l'accession de données, pas de code.
Cette solution serait totalement transparente pour les anciens programmes, dont les utilisations de libs de données sont très probablement basées sur des relogements.

Donc pour tourner une lib readonly (donc designées spécifiquement pour PedroM) sous AMS, un programme n'aura qu'à appeler la lib en tant que programme, qui en s'auto-référençant à nouveau dans _main, ne sera pas dérelogée en RAM à l'exit, et donc sera utilisable de manière transparente en RAM par le programme, qui croira de bonne foi que la lib est peut-être en ROM.

Ca demande juste un code d'init dans un programme "pedrom" à écrire, et un simple kernel::exec pour chaque lib utilisée dans les programmes "PedroM-only". L'overhead est donc vraiment minime pour un tel programme, s'il veut également tourner sous AMS.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 13/04/2013 à 01:19 Membre depuis le 11/06/2001, 19563 messages
Folco (./1) :
PpHd, quid d'un flag ro pedrom-only ?

bof.
faudrait plutôt un nouveau format de programme. Parce qu'un KPV4 pour exécuter en flash, c'est bof.
Folco (./1) :
Quid de recopier en RAM les programmes ro sous AMS, sans rien y changer pour autant (relogements éventuels, BSS, etc...) ?

c'est contraire à la spec du flag qui dit bien "pas de recopie si pas archivé"
et ca peut très bien marcher si l'utilisateur à fait "péter" la protection flash.
Posté le 13/04/2013 à 01:30 Membre depuis le 10/06/2001, 40269 messages
Folco (./5) :
La solution qui me paraitrait la plus propre :
- ne pas tenir compte du flag ro sous AMS, dans le cas d'un kernel::exec, kernel::LibsExec ou kernel::LibsCall, car nécessairement ça va planter, on le sait d'avance.
- laisser le programme en ROM s'il est ro lors d'un kernel::LibsPtr, ou d'un relogement à résoudre, car ça ressemble tout à fait à de l'accession de données, pas de code.Cette solution serait totalement transparente pour les anciens programmes, dont les utilisations de libs de données sont très probablement basées sur des relogements.

À mon avis, c'est probablement la meilleure solution. Ça ressemble un peu à l'heuristique de TitaniK pour savoir quand il faut mettre directement l'adresse de destination (accès aux données) et quand il faut interposer le fameux stub de déprotection (appel de code), mais dans ton cas, où le chargement est dynamique, c'est moins risqué parce qu'on a une API différente pour les 2 cas, alors que TitaniK n'a que l'instruction utilisée devant le relogement, qu'il compare bêtement à jsr.l et jmp.l, sans gérer aucun autre cas (genre l'appel indirect avec lea et jsr (%an) etc.).

Mais PpHd a peut-être une autre idée, comme d'habitude. wink
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 13/04/2013 à 01:32 Membre depuis le 10/06/2001, 40269 messages
Call : PpHd appelé(e) sur ce topic...
Et quid de la méthode du post ./5 (cf. aussi ./7 ci-dessus)?
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 13/04/2013 à 10:38 Membre depuis le 18/06/2001, -26081 message
PpHd (./6) :
faudrait plutôt un nouveau format de programme. Parce qu'un KPV4 pour exécuter en flash, c'est bof.

Ah poutaing ! J'osais pas le dire, mais ça me parait une évidence depuis longtemps ça ! grin
PpHd (./6) :
c'est contraire à la spec du flag qui dit bien "pas de recopie si pas archivé"
Flags $0011 1 Flags
bit 0 - runs on 92+ if set
bit 1 - runs on 89 if set
bit 2 - Do not redraw the screen after the end of the program if set bit 3 - Do not make a copy of the program (If it is archived) : Read only if set

Si pas archivé tu veux dire ? Ok, mais le flag était-il fait pour permettre l'exécution en ROM, ou permettre la lecture de données en ROM sans bouffer la RAM ? Parce que là, on est encore dans un autre contexte qui n'a très probablement pas été pensé au moment du design du flag...
PpHd (./6) :
et ca peut très bien marcher si l'utilisateur à fait "péter" la protection flash.

avec le code aussi protégé que la recette du coca-cola ? non merci... puis amha c'est absolument pas à un programme user-space de faire ça.
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 13/04/2013 à 12:47 Membre depuis le 11/06/2001, 19563 messages
Kevin Kofler (./7) :
Folco (./5) :
La solution qui me paraitrait la plus propre :
- ne pas tenir compte du flag ro sous AMS, dans le cas d'un kernel::exec, kernel::LibsExec ou kernel::LibsCall, car nécessairement ça va planter, on le sait d'avance.
- laisser le programme en ROM s'il est ro lors d'un kernel::LibsPtr, ou d'un relogement à résoudre, car ça ressemble tout à fait à de l'accession de données, pas de code.Cette solution serait totalement transparente pour les anciens programmes, dont les utilisations de libs de données sont très probablement basées sur des relogements.

À mon avis, c'est probablement la meilleure solution. Ça ressemble un peu à l'heuristique de TitaniK pour savoir quand il faut mettre directement l'adresse de destination (accès aux données) et quand il faut interposer le fameux stub de déprotection (appel de code), mais dans ton cas, où le chargement est dynamique, c'est moins risqué parce qu'on a une API différente pour les 2 cas, alors que TitaniK n'a que l'instruction utilisée devant le relogement, qu'il compare bêtement à jsr.l et jmp.l, sans gérer aucun autre cas (genre l'appel indirect avec lea et jsr (%an) etc.).

Mais PpHd a peut-être une autre idée, comme d'habitude. wink


Honnêtement, ca reste une heuristique qui va être fausse de temps en temps.
on peut très bien appeler LibPtr pour remplir une table d'appel indirect, et passer cette table aux autre modules...
Par ailleurs, la relocation se fait au moment de l'appel à Begin et pas lors du Call ou du Ptr... et que tu peux avoir un mélange des 2 dans ton programme.
Je sens une énorme usine à gaz pour le gérer à peu près...


Folco (./9) :
Si pas archivé tu veux dire ? Ok, mais le flag était-il fait pour permettre l'exécution en ROM, ou permettre la lecture de données en ROM sans bouffer la RAM ? Parce que là, on est encore dans un autre contexte qui n'a très probablement pas été pensé au moment du design du flag...

Pour ne pas faire de copie ROM->RAM, c'est tout. Le reste n'est pas géré.
Folco (./9) :
avec le code aussi protégé que la recette du coca-cola ? non merci... puis amha c'est absolument pas à un programme user-space de faire ça.

Pourquoi ne pas l'ajouter dans hw3patch?
Posté le 13/04/2013 à 14:01 Membre depuis le 10/06/2001, 40269 messages
Déprotéger l'exécution en FlashROM est aussi nécessaire sur HW1, le code à modifier dans AMS est différent, comme l'est aussi le code nécessaire pour désactiver la grande protection (et je ne suis pas sûr de me rappeler comment faire, Zeljko m'avait donné la démarche aussi pour les HW1 il y a longtemps, mais je ne trouve plus le log ou mail).
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 13/04/2013 à 14:05 Membre depuis le 18/06/2001, -26081 message
PpHd (./10) :
on peut très bien appeler LibPtr pour remplir une table d'appel indirect, et passer cette table aux autre modules...

Tout à fait, et c'est ce que je fais sous PedroM
code
;===============================================================================
;
;       pdtlib::InstallTrampolines
;
;       in      a0      char*    LibName
;               d1.b    char     LibVersion
;               a1      short [] FunctionsTable
;               a2      short [] OffsetsTable
;               a3      void*    TrampolinesTableBase
;
;       out     a0      LibRef* Descriptor
;
;       destroy d0
;
;       Open the library LibName, checking that is version is >= LibVersion.
;       Return LibRef if installation is successful, else NULL
;
;       For each element of FunctionsTable, create a trampoline (actually a
;       "jmp Function").
;       FunctionsTable must ends with a negative value.
;
;       For each trampoline created for FunctionsTable [x], 6 bytes will be used
;       at TrampolinesTableBase + OffsetTable [x].
;       These entries need not to be packed
;
;===============================================================================

pdtlib@0004:
        RAMT    RAM_kernel::LibsBegin
        move.l  a0,d0
        beq.s   \Fail
        movem.l a0-a2,-(sp)

\Loop:  movea.l (sp),a0
        move.w  (a1)+,d0
        bmi.s   \EOT

        RAMT    RAM_kernel::LibsPtr
        move.w  (a2)+,d0
        move.w  #$4EF9,0(a3,d0.w)               ; jmp ...
        move.l  a0,2(a3,d0.w)                   ; ... imm.l
        bne.s   \Loop

                movea.l (sp),a0                 ; Function not found
                RAMT    RAM_kernel::LibsEnd
                clr.l   (sp)

\EOT:   movem.l (sp)+,a0-a2
\Fail:  rts

Le truc, c'est que ce code dans un programme ro, c'est du pedrom-only, ça n'a aucune raison d'être sous AMS, puisque que dans l'état actuel, ça ne peut pas marcher. Donc un programme qui fait ça sait ce qu'il fait, et il n'a qu'à mettre en application ce que j'ai posté à la fin de ./5.
PpHd (./10) :
Pourquoi ne pas l'ajouter dans hw3patch?

Ca, je crois que c'est la solution ultime love
Plus aucun problème, plus rien à modifier ! smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 13/04/2013 à 15:43 Membre depuis le 10/06/2001, 40269 messages
Ce n'est pas si simple que ça, cf. ./11.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 13/04/2013 à 17:11 Membre depuis le 18/06/2001, -26081 message
File-moi le code de déprotection HW2, je t'implante déjà celui-là moi tongue
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 13/04/2013 à 18:07 Membre depuis le 27/04/2006, 60479 messages
(et c'est partiiiiii grin)
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 13/04/2013 à 18:43 Membre depuis le 18/06/2001, -26081 message
Tiens, le code de TIOSMOD (merci Lionel) pour t'aider :
    // 1b) Disable Flash execution protection:
    //         * on HW2+, by setting a higher value in port 700012;
    //         * on HW1, by turning reads from three stealth I/O ranges to writes to those ranges.
    {
        // * HW2+: 1 direct write early in the reset code.
        temp = ROM_base + 0x12188;
        Seek(temp);
        temp = SearchLong(UINT32_C(0x700012));
        printf("Killing Flash execution protection initialization at %06" PRIX32 "\n", temp - 8);
        PutShort(0x003F, temp - 6);
        // * HW1: three references to the stealth I/O ports in the early reset code
        PutShort(0x33C0, temp - 26);
        PutShort(0x33C0, temp - 20);
        PutShort(0x33C0, temp - 14);
        // * HW2+: 1 reference in a subroutine of the trap #$B, function $10 handler.
        temp = GetAMSTrapBFunction(0x10);
        printf("Killing Flash execution protection update at %06" PRIX32 "\n", temp);
        Seek(temp);
        WriteLong(UINT32_C(0x33FC003F));
        WriteLong(UINT32_C(0x700012));
        WriteShort(0x4E75);
    }

smile
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 13/04/2013 à 19:13 Membre depuis le 10/06/2001, 40269 messages
Bah, ce n'est pas prévu dans HW3Patch, ce n'est pas son but.

Utilise tiosmod si tu veux absolument cette modification.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 13/04/2013 à 19:16 Membre depuis le 10/06/2001, 40269 messages
D'ailleurs, les modifications telles qu'elles sont faites dans tiosmod sont très dangereuses à faire on-calc parce qu'il faut mettre des bits de 0 à 1, ce qui nécessite de supprimer le secteur de FlashROM entier et de le réécrire. Pour faire un patch on-calc, il faut faire les modifications telles qu'on ne passe que des bits de 1 à 0.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 13/04/2013 à 20:19 Membre depuis le 18/06/2001, -26081 message
Kevin Kofler (./17) :

Bah, ce n'est pas prévu dans HW3Patch, ce n'est pas son but.

Ok, mais quitte à hacker les protections TI pour faire sauter des limitations débiles, pourquoi pas le faire, non ?
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 13/04/2013 à 23:33 Membre depuis le 10/06/2001, 40269 messages
Parce que c'est plus compliqué, et en particulier s'applique aussi aux HW1 que HW3Patch n'essaie actuellement même pas de gérer (version 2 minimum) parce qu'elles ne sont pas concernées par la protection contre l'exécution en RAM, et justement les HW1 sont très différentes niveau protections. Et je ne veux pas faire un travail à moitié. D'autant plus que ça ne vaut pas vraiment le coup depuis qu'il y a tiosmod et que la clef de signature a été factorisée.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 14/04/2013 à 10:56 Membre depuis le 18/06/2001, -26081 message
Bon, alor je désassemble HW3Patch ou tu me files le source ? cheeky

(Pour ton dernier argument : envoyer et installer HW3Patch est sans comparaison plus simple que de demander à quelqu'un de tiosmoder sa rom, puis de la signer. C'est Texas qui devrait utiliser TIOSMOD !!!)
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 14/04/2013 à 11:00 Membre depuis le 10/06/2001, 40269 messages
Le chantage ne mène nulle part.

Pourquoi veux-tu absolument un patch on-calc quand il existe déjà une version sur ordinateur (tiosmod)? À mon avis, ça ne vaut pas du tout l'effort.
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 14/04/2013 à 11:01 Membre depuis le 11/11/2001, 116496 messages
c'est pas du chantage, j'imagine en plus qu'en tant que fervent supporter du libre et de l'open source que tu es ça doit déjà être le cas, non ?
avatarWebmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca
Posté le 14/04/2013 à 11:03 Membre depuis le 18/06/2001, -26081 message
C'est absolument pas du chantage. Si je veux forker c'est mon droit, si je veux proposer un patch c'est mon droit, etc...
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 14/04/2013 à 11:25 Membre depuis le 10/06/2001, 40269 messages
Folco (./24) :
Si je veux forker c'est mon droit

Non, c'est interdit par la licence.

Cela dit, franchement j'ai ras le bol d'être le gardien du secret. (J'ai toujours été contre ce genre de secrets. Mais j'ai promis à Zeljko de le garder secret et c'est une personne que je respecte!) Peut-être que je vais quand-même finir par mettre tout sous GPL un de ces jours, et si les gens sont suffisamment cons pour vouloir écrire un virus qui détruit les calculatrices, tant pis. Mais pour l'instant, la licence est celle qu'elle est.

Grrr, je savais que ça allait finir en trolls sur la déprotection!
avatarMes news pour calculatrices TI: Ti-Gen (fr/en), MobiFiles (de)
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é
Posté le 14/04/2013 à 11:42 Membre depuis le 18/06/2001, -26081 message
Ben si personne ne propose de solution autre que la déprotection, que veux-tu que j'y fasse moi...
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 14/04/2013 à 12:57 Membre depuis le 16/06/2001, 69781 messages
./26 un émulateur, qui lise et exécute les opcodes en live trioui
Posté le 14/04/2013 à 13:54 Membre depuis le 18/06/2001, -26081 message
maso grin
avatar<<< Kernel Extremist©®™ >>>
Feel the power of (int16) !
Posté le 14/04/2013 à 14:21 Membre depuis le 27/04/2006, 60479 messages
Je te rappelle qu'il a aussi voulu porter Java sur TI-68k, si c'est pas maso ça... tongue

Pour la déprotection, pourquoi ne pas poser la question à Zeljko ? Il a peut-être changé d'avis depuis, et honnêtement les risques que quelqu'un en fasse une utilisation malveillante sont quasi-nuls aujourd'hui (ne serait-ce que vu le nombre de développeurs TI-68k qui restent).
avatarZeroblog

« Tout homme porte sur l'épaule gauche un singe et, sur l'épaule droite, un perroquet. » — Jean Cocteau
« Moi je cherche plus de logique non plus. C'est surement pour cela que j'apprécie les Ataris, ils sont aussi logiques que moi ! » — GT Turbo
Posté le 14/04/2013 à 15:00 Membre depuis le 16/06/2001, 69781 messages
ça marche presque, c'est juste flemme-stoppé embarrassed