TI-84+: Chiera-t-elle comme la TI-89 Titanic? - Page 1

La TI-84+ est sorti, mais g entendu parlé que la TI-89 Titanic ne supporte pas les jeux asm de la TI-89. En sera-t-il de même pour la TI-84+ avec les jeux de TI-83+?

mais g entendu parlé que la TI-89 Titanic ne supporte pas les jeux asm de la TI-89

faux. uniquement certains programmes ne seront pas supportés.

En tout cas, avec TitaniK, on pourra faire tourner pas mal de progs.

TitaniK n'est pas une recette miracle. La plupart des programmes qui tourneront seront des programmes _nostub. (Il suffit de recompiler avec TIGCC 0.95 Beta 6 ou supérieure.) Pour les programmes kernel, il faut les patcher un par un. Les handlers d'interruption doivent être gérés de manière particulière avec TitaniK, et ça oblige à patcher presque tous les programmes kernel. Et tous les bogues qui nécessitent des patches en _nostub concernent aussi le kernel, par exemple l'utilisation de 0x400xx pour modifier les interruptions.

ah et c'est quoi la différence profonde entre patcher un programme et le recompiler en .95b6ou+ ??? parcqu'à ce qu'on a pu lire, certains programmes nécessitent modfi pour passer en .95 alors qu'ils passaient sans pb en .94

sauf si un patch de type hw2patch est trouvé

oui il y a en effet cette solution aussi.

et qui aurait l'avantage de pemettre de ne pas patcher les programmes kernel

bah les pronostubs mais là n'est pas le sujet...

Hum, mais certains pourraient voir là dedans un méchant hack pas beau, et ouuh que c'est pas bien les hacks pas beau .

vince
: ah et c'est quoi la différence profonde entre patcher un programme et le recompiler en .95b6ou+ ???

Aucune, on peut aussi patcher les programmes compilés. Mais si la source est disponible, il est plus simple de recompiler.

La différence avec le kernel, c'est que beaucoup de programmes kernel nécessitent aussi une modification des sources pour marcher avec TitaniK, pas seulement une recompilation. En termes de patches du binaire, ça se traduit par l'ajout de code à la fin du programme (ce que j'ai fait pour SMQ).

parcqu'à ce qu'on a pu lire, certains programmes nécessitent modfi pour passer en .95 alors qu'ils passaient sans pb en .94

Normalement non. Même les vieux programmes de TIGCC 0.65 sont censés toujours compiler!

Flanker
: et qui aurait l'avantage de pemettre de ne pas patcher les programmes kernel

Si, pour changer toutes les écritures à 0x400xx pour rediriger les interruptions!

Kevin Kofler
: Normalement non. Même les vieux programmes de TIGCC 0.65 sont censés toujours compiler!

Je me souviens d'avoir dû galérer pas mal de fois pour changer de version de TIGCC...

Flanker
: et qui aurait l'avantage de pemettre de ne pas patcher les programmes kernel

Si, pour changer toutes les écritures à 0x400xx pour rediriger les interruptions!

Mauvaise foi spotted... C'est le même pb en nostub (et on peut aussi utiliser SetIntVec en kernel...)

Normalement, quelqu'un qui code proprement n'est pas censé utiliser des hacks aussi laids, alors qu'une méthode propre existe : changer $600001.2.
Et les programmes kernel qui redirigent les interruptions ne sont pas légions

En plus en général les progs kernel n'utilisaient pas ce hack sale avant TIGCC et modifiaient $600001:2 ...

oh le zouli croisé

nope, Flanker disait que les progs kernel n'utilisaient pas souvent ce hack parce qu'il ne redirigaient pas les int, j'ajoute que avant, la méthode utilisée était la méthode propre ; le hack a été d'abord introduit par TIGCC, puis, constatant que de toute façon les progs TIGCC seraient rendu incompatibles si ce hack ne marchait plus, les programmeurs kernel se sont mis à l'utiliser eux aussi...

Kevin Kofler
:

parcqu'à ce qu'on a pu lire, certains programmes nécessitent modfi pour passer en .95 alors qu'ils passaient sans pb en .94

Normalement non. Même les vieux programmes de TIGCC 0.65 sont censés toujours compiler!

Ah ben voilà

Flanker
: Et les programmes kernel qui redirigent les interruptions ne sont pas légions

Si.
Je sais de quoi je parle, j'ai regardé ça pour TitaniK.

Pollux
: nope, Flanker disait que les progs kernel n'utilisaient pas souvent ce hack parce qu'il ne redirigaient pas les int, j'ajoute que avant, la méthode utilisée était la méthode propre ; le hack a été d'abord introduit par TIGCC, puis, constatant que de toute façon les progs TIGCC seraient rendu incompatibles si ce hack ne marchait plus, les programmeurs kernel se sont mis à l'utiliser eux aussi...

C'est le contraire! TIGCC n'existait même pas quand ce hack a été introduit! Ce sont les programmeurs kernel qui ont introduit ce hack. Même certains auteurs de kernels l'ont mis dans leur kernel (*ahem* TeOS *ahem*).

Ca a été assez tardif, et c'était plus ou moins l'époque des débuts de TIGCC, si mes souvenirs sont bons

Ben non, tu as tout faux. Voilà quelques gemmes de la source de PlusShell 1.0 alpha:

KernelNew:
        clr.l ($40030)
        SET_REL_RAM_DWORD #$3fff4,$2f,$104+$a
        move.l $c8,d0
        and.l #$600000,d0
        move.l #$120e8,a0
        add.l d0,a0
        move.l #$40060,a1
        move.l #7,d0
KernelNewLoop:
        move.l (a0)+,(a1)+
        dbra d0,KernelNewLoop
        lea.l UninstallStringTag(pc),a0
        rts

KernelCopyLoop:
        move.b (a1)+,(a0)+
        dbra d0,KernelCopyLoop
        move.w #KERNEL_VER,($40030)
        move.w #KERNEL_IDENT,($40032)
        lea.l exec-_KernelStart(a2),a0
        move.l a0,($40034)
        lea.l Reloc-_KernelStart(a2),a0
        move.l a0,($40038)
        lea.l RelocFromPtr-_KernelStart(a2),a0
        move.l a0,($4003c)
        lea.l Unreloc-_KernelStart(a2),a0
        move.l a0,($40040)

_main:
        movem.l d1-d7/a0-a6,-(a7)
        tst.w ($30)
        beq KernelNotInstalled
        clr.l ($40030)

installCrashRecover:
        move.l ($40008),oldVect+0
        move.l ($4000c),oldVect+4
        move.l ($40010),oldVect+8
        move.l ($40014),oldVect+$c
        move.l ($4002c),oldVect+$10
        move.l ($400ac),oldVect+$14
        move.l ($400b0),oldVect+$18
        move.l ($400b4),oldVect+$1c
        move.l ($400b8),oldVect+$20
        move.l ($400bc),oldVect+$24
        move.l ($40064),oldVect+$28
        move.l ($40068),oldVect+$2c
        move.l ($4006c),oldVect+$30
        move.l ($40070),oldVect+$34
        move.l ($40074),oldVect+$38
        move.l ($40078),oldVect+$3c
        move.l ($4007c),oldVect+$40
        move.l ($40028),oldVect+$44
        move.l ($40084),oldVect+$48
        move.l #crashBusError,($40008)
        move.l #crashAddrError,($4000c)
        move.l #crashIllegalError,($40010)
        move.l #crashDivideError,($40014)
        move.l #crashThrowError,($40028)
        move.l #crashLine1111Error,($4002c)
        move.l #crashTrap11Error,($400ac)
        move.l #crashTrap12Error,($400b0)
        move.l #crashTrap13Error,($400b4)
        move.l #crashTrap14Error,($400b8)
        move.l #crashTrap15Error,($400bc)
        cmp.b #CALC_TI92PLUS,CALCULATOR
        bne noCheckTerminate
        move.l #checkTerminate,($40078)
noCheckTerminate:
        move.l #crashMemoryError,($4007c)
        move.l #newTrap1,($40084)
        move.l #683,d7
        move.l #newROMTable,a0
        move.l $c8,a1
        move.l a1,oldROMTable
romTableInstLoop:
        move.l (a1)+,(a0)+
        dbra d7,romTableInstLoop
        move.l #newHeapAlloc,newROMTable+$240
        move.l #newHeapAllocThrow,newROMTable+$24c
        move.l #newHeapFree,newROMTable+$25c
        move.l #newHeapFreeIndir,newROMTable+$260
        move.l #newERThrow,newROMTable+$54c
        move.l #newROMTable,($400c8)
        move.l #0,handlecount
        rts

(Voilà la perle, il utilise le hack même pour lire!)

deinstallCrashRecover:
        move.l oldROMTable,($400c8)
        move.l oldVect+0,a0
        move.l a0,($40008)
        move.l oldVect+4,a0
        move.l a0,($4000c)
        move.l oldVect+8,a0
        move.l a0,($40010)
        move.l oldVect+$c,a0
        move.l a0,($40014)
        move.l oldVect+$10,a0
        move.l a0,($4002c)
        move.l oldVect+$14,a0
        move.l a0,($400ac)
        move.l oldVect+$18,a0
        move.l a0,($400b0)
        move.l oldVect+$1c,a0
        move.l a0,($400b4)
        move.l oldVect+$20,a0
        move.l a0,($400b8)
        move.l oldVect+$24,a0
        move.l a0,($400bc)
        move.l oldVect+$3c,a0
        move.l a0,($40078)
        move.l oldVect+$40,a0
        move.l a0,($4007c)
        move.l oldVect+$44,a0
        move.l a0,($40028)
        move.l oldVect+$48,a0
        move.l a0,($40084)
        move.w #$980,$600010
        rts

CrashRecover:
        move.l oldVect+$28,a0
        move.l a0,($40064)
        move.l oldVect+$2c,a0
        move.l a0,($40068)
        move.l oldVect+$30,a0
        move.l a0,($4006c)
        move.l oldVect+$34,a0
        move.l a0,($40070)
        move.l oldVect+$38,a0
        move.l a0,($40074)
        move.l oldVect+$3c,a0
        move.l a0,($40078)

C'était en octobre 1998, ça. TIGCC a été créé en juillet 1999. Donc voilà, c'est bien des kernels que vient ce hack, pas de nous!

PlusShell c pas une référence, d'ailleurs y a qu'à voir ce code pour s'en convaincre (et puis les parenthèses autour des adresses, ça donne un certain style ^^)

Je croyais que TIGCC & TICT se voulaient des exemples de propreté et de stabilité ?

Pollux
: et puis les parenthèses autour des adresses, ça donne un certain style ^^

Z80 style

Non pas que je trouve que ça soit une mauvaise idée en soi (évite les erreurs de débutant), mais en tout cas quand on utilise "oldVect+$30" sans parenthèses, c un peu bizarre d'écrire "($74)" alors que c exactement la même chose...

Flanker
:

mais g entendu parlé que la TI-89 Titanic ne supporte pas les jeux asm de la TI-89

faux. uniquement certains programmes ne seront pas supportés.

Alors ce sera la fin des ancien jeux TI-89 qui ne seront jamais recompilé à caause des prgmer qui les abandonne. Donc de nombreux progs peuvent coulder avec le TitaniK.

C'était déjà le cas au moment de l'arrivée d'AMS 2.0x, pourtant tout le monde ou presque a upgradé, aujourd'hui...

Kevin9999
:

Flanker
:

mais g entendu parlé que la TI-89 Titanic ne supporte pas les jeux asm de la TI-89

faux. uniquement certains programmes ne seront pas supportés.

Alors ce sera la fin des ancien jeux TI-89 qui ne seront jamais recompilé à caause des prgmer qui les abandonne. Donc de nombreux progs peuvent coulder avec le TitaniK.

Les programmes peuvent être patchés.

Pour les programmes _nostub, ça se fait automatiquement. Pour les programmes kernel, s'ils utilisent des interruptions, il faut les adapter pour TitaniK à la main (éditeur hexa). C'est faisable, je l'ai déjà fait pour SMQ.

Les programmes peuvent être patchés.

je n'aime pas les patchs à la barbare

Tu fais comment sinon pour les programmes dont les auteurs n'ont pas sorti la source?

Flanker > Huhu, c'est quoi, les TSR que tu fais pour AMS ? C'est pas des patchs ?