GetDataType, SmapTypeStrings... - Page 1

Dans TICT-Explorer, j'utilise ces fonctions, qui sont documentées dans le SDK de TI et dans mes updates à la doc de TIGCC, afin de diminuer la taille de mon programme. Cela a aussi l'effet d'augmenter la language localization du programme au cas où l'utilisateur utilise une FlashApp de language localization (beurk). Le source est disponible dans un topic de http://p080.ezboard.com/ftichessteamhqfrm10
Or, ces ROM_CALLs sont disponibles uniquement sous AMS 2.xx, bien qu'un Address Hack sûr permette de les trouver et de les utiliser sous AMS 1.xx. Et mon problème est là: PedroM est une réimplémentation incomplète d'un AMS 1.xx. Je viens de me rendre compte ces jours-ci que PedroM n'avait certainement pas ces ROM_CALLs.
Ces ROM_CALLs étant faciles à implémenter, pourraient-ils être implémentés ASAP (TICT-Explorer 1.40 sortira avant que l'année scolaire recommence pour moi) dans PedroM, et accessibles facilement d'une manière à définir (mais similaire à celle des adresses des fonts, je suppose) ?

const char *SmapTypeStrings (short type);

Returns the 3-4 character description of a variable type.

SmapTypeStrings returns a string of three characters for the variable type represented by type. Valid values for type are defined in the enum SystemDataTypes; you can use GetDataType to convert a tag to such a type value.

The value returned is the string displayed in the VAR-LINK dialog. This string is localized for the current language and can be up to four characters long. Note that files of type SDT_OTH will return a pointer to the string "OTH", and not to the true extension of the file.

See also: GetDataType, handleVarLinkKey

short GetDataType (CESI ptr);

Returns the data type for a given tag.

GetDataType returns the data type value for the variable tag pointed to by ptr. Valid values are defined in the enum SystemDataTypes.

enum SystemDataTypes {SDT_EXPR = 0, SDT_LIST = 1, SDT_MAT = 2, SDT_FUNC = 3, SDT_PRGM = 4, SDT_PIC = 5, SDT_STR = 6, SDT_TEXT = 7, SDT_GDB = 8, SDT_DATA = 9, SDT_FIG = 10, SDT_MAC = 11, SDT_OTH = 12, SDT_SYS = 13, SDT_ALL = 14, SDT_ASM = 15};

Si tu me files une implantation ca ira d'antant plus vite
Sinon, je propose un hack identique a GetCurrentTick (je me souviens plus du nom exact).

Oups, ces deux-là ont déjà été intégrés...
> Si tu me files une implantation ca ira d'autant plus vite
Certes, mais dans PedroM, SmapTypeStrings serait
const char *SmapTypeStrings (short type) {
return types[type];
}
où type est un tableau de chaînes de caractères commençant par "EXPR","LIST"... Pas insurmontable.
GetDataType est un peu plus compliquée, car il faut déterminer si on a affaire à un PRGM ou une FUNC, mais il y a du code pour ça dans TICT-Explorer 1.30- (c'est ce qui a été remplacé par GetDataType+SmapTypeStrings).
> GetCurrentTick
Je suppose que tu parles de FiftyMsecTick ?


Je n'ai pas mis de sortie dure dès le début de tictex (mais si je voulais faire en sorte que ces routines soient le moins tôt possible dans PedroM, je pourrais difficilement m'y prendre autrement !).

Certes, mais dans PedroM, SmapTypeStrings serait
const char *SmapTypeStrings (short type) {
return types[type];
}
où type est un tableau de chaînes de caractères commençant par "EXPR","LIST"... Pas insurmontable.

Non

GetDataType est un peu plus compliquée, car il faut déterminer si on a affaire à un PRGM ou une FUNC, mais il y a du code pour ça dans TICT-Explorer 1.30- (c'est ce qui a été remplacé par GetDataType+SmapTypeStrings).

Bah, pas grave si on se trompe. De toute facon, les programmes basics ne marchent pas.

Je suppose que tu parles de FiftyMsecTick ?

Yes

> De toute facon, les programmes basics ne marchent pas.
En effet, mais des fois qu'un utilisateur mette des PRGM et FUNC sous PedroM...
AMS utilise GetFuncPrgmBodyPtr, qui appelle une sous-routine, mais a priori, la méthode des TICT-Explorer précédents est fiable.

Ah, et tant qu'on est dans les ROM_CALLs faciles à implémenter: "debug_printf" ? Voir http://p080.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=3077.topic
L'utilité est discutable, vu que je n'ai documenté ce double que récemment (je savais les noms non officiels, mais je ne m'étais jamais vraiment penché dessus).

Si je suis motive.

Il me faudrait pour tester que j'ai bien implante ces fonctionnalites.

Si tu veux l'implémenter, le code de debug_printf est celui de sprintf et printf, c'est juste le callback (en gros, envoyer le caractère sur le link si RC_47A==1) qui change.

Pas plutot faire un test juste avant :

debug_printf:
tst.b TOTO
beq.s printf_end

printf:
....

printf_end:
rts

Au fait, ca marche comment le position a l'ecran ?

> Au fait, ca marche comment le position a l'ecran ?
?? Ca ne fait qu'envoyer sur le link (et encore, ssi RC 47A == 1), ça n'affiche pas à l'écran.

Je sens que je vais implémenter les ROM_CALLs pour PedroM ASAP, peut-être ce soir, parce que là, en fait, TICT-Explorer 1.40 ne fonctionne pas du tout sur PedroM (aucun type de fichier reconnu => tout va dans l'éditeur hexa).

Oups, j'aurais dire plus soignement ce qu'elles font.

Je n'ai pas encore implémenté les ROM_CALLs, mais: bouh, sur TIEmu 2.00-rc7 / 89T AMS 3.01, TICT-Explorer 1.40 veut bien lancer les programmes kernel-based (quand on met le #define qui va bien, évidemment), mais il y a un "Crash Intercepted" quand on sort du programme kernel-based.

Si tu me l'envoies le programme je veux bien voir pourquoi.

J'ai regardé tout seul.
En plus de la distribution, je pourrais t'envoyer des images d'une 89 HW2 AMS 2.05 (Certificate compris) et d'une 89T HW3 AMS 3.01 (sans Certificate), et les savestates correspondants (j'utilise VTI modifiée par JM et TIEmu 2.00-RC7) contenant:
* PreOS 1.0.2;
* HW3Patch;
* TICT-Explorer 1.40 Beta 0 avec une boucle infinie avant le lancement d'un programme (tictex, tictexpl, tictexpv);
* txtrider/cube;
* des images d'exemple pour tictexpv.
mais ma connexion Internet est une 56k limitée dans le temps...

Pour la raison du plantage à la sortie: la zone de retour du programme, à la fin du handle du programme, où un nouvel appel indirect à la trap #11 a lieu, a été détruite. C'était facile à voir.
Tests (programmes: "cube" et surtout txtrider 1.ß96. Au moins txtrider est "kernel V4") pour savoir qui la détruit:
* faire retourner le programme kernel-based directement, comme s'il n'y avait pas de kernel: aucun problème.
* laisser le programme kernel-based appeler la routine de lancement dont l'adresse est dans 0x34.l, startKernel: tout va bien jusqu'à move.w d7,d0; bsr kernel::exec de sams.asm. En traçant à l'intérieur et en comparant avec le code de PreOS, on voit que le coupable est kernel::relocation. En laissant continuer jusqu'au programme lancé, le jsr 0(a5,d0.l) de sld.asm, on voit que le handle complet a été bougé le plus haut possible en RAM (alors qu'il était locké), mais que la partie au-delà du ASM_TAG n'a pas été copiée, et que l'adresse de retour n'est pas changée...
En regardant de plus près, le fautif est certainement le bout de sams.asm qui ruine le twin avant d'appeler kernel::exec. Je suis sûr que c'est la raison du crash à la sortie d'un programme kernel-based, d'autant plus qu'il n'y a pas de crashes avec ttstart, qui ne crée pas de twins...

Que peut-on faire ? Puisque le beta-test est presque prêt, en attendant d'avoir une solution au premier problème, je dois désactiver le lancement des programmes kernel-based, car je n'ai pas envie de crasher les calculettes des beta-testeurs s'ils se trompent...

Maintenant que je sais pourquoi les programmes kernel-based ne fonctionnent pas, je vais me mettre à l'implémentation de GetDataType et SmapTypeStrings.

Je suis desole je ne comprends pas le probleme. Je vais tracer ca avec ce que tu m'as file.

Ok, j'ai compris en lisant le code. C'est un bug de tict (Franchement cette methode de lancement est deguelasse ).
SInon pour corriger, c'est simple: lorsqu'on utilise une telle methode de lancement, on ne crees pas de SYM, mais on recopie toujours le handlle.
(C'est la seule methode propre de faire).

Comme ttstart et SIDE (sur lequel est basé le nouveau code) sont faits, donc... Mais je fais quand même une version sans avoir corrigé ce bug, parce que je risque de ne pas tester correctement la correction aujourd'hui.

Oue mais cette methode est franchement bugguee. La preuve...

Certes, mais quand on n'explose pas le twin, ça n'arrive a priori pas... TICT-Explorer n'est pas le seul responsable.

PreoS <= 0.67 le faisait aussi pour les Pack Archive. Et je crois me souvenir de programmes nostub qui le faisaient aussi.
Sans parler des problemes de memoires (Reallouer peut souvent echouer avec une memoire fragmentee).

> Reallouer peut souvent echouer avec une memoire fragmentee
Même tout simplement allouer, c'est à dire que les programmes ont des chances de ne pas pouvoir fonctionner. Dans ces cas-là, reset, donc ce n'est pas très important !
Pour EXECUTE_IN_GHOST_SPACE sur tictex, il faut que je regarde si on n'a besoin du handle du programme nulle part.

Voici les ROM_CALLs, je les ai testés.
Quel sera le mode d'emploi détaillé pour y accéder ? As-tu une table de ROM_CALLs avec plus d'entrées que ce qui est reporté (si oui, ça peut être simple: si 0x32.w = 'RO', on utilise la jump table comme sur AMS 2.xx) ?

; __ATTR_TIOS__ short GetDataType (CESI ptr); (ROM_CALL_435)
; Implemented by Lionel Debroux.
xdef GetDataType

; The cascade of subq and the simplified inline version of GetFuncPrgmBodyPtr make this routine much
; smaller than that of AMS. It is slower on average, though, but who needs speed for such a routine ?
GetDataType:
move.l 4(a7),a0
move.b (a0),d1
moveq #15,d0
cmpi.b #$F3,d1 ; ASM_TAG -> 15;
beq.s \GetDataTypeEnd
subq.w #3,d0 ; 13 and 14 do not seem to be returned by GetDataType ??
cmpi.b #$F8,d1 ; OTH_TAG -> 12;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$E2,d1 ; MAC_TAG -> 11;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$E1,d1 ; FIG_TAG -> 10;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$DD,d1 ; DATA_TAG -> 9;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$DE,d1 ; GDB_TAG -> 8;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$E0,d1 ; TEXT_TAG -> 7;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$2D,d1 ; STR_TAG -> 6;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$DF,d1 ; PIC_TAG -> 5;
beq.s \GetDataTypeEnd
subq.w #1,d0
cmpi.b #$DC,d1 ; FUNC_TAG -> 3 (FUNC) or 4 (PRGM).
bne.s \GetDataTypeCheck12
; Based on the optimized version of GetFuncPrgmBodyPtr previously used in tictex.
; Note that GetFuncPrgmBodyPtr is much more complicated, but it does the same thing !
\GetDataType34Loop:
cmpi.b #$E5,-(a0)
bne.s \GetDataType34Loop
cmpi.b #$E4,(a0)
beq.s \GetDataType34OK ; Branch not taken -> strange data... Return EXPR.
\GetDataType0:
moveq #0,d0
bra.s \GetDataTypeEnd
\GetDataType34OK:
cmpi.b #$19,-(a0)
beq.s \GetDataType34Over
subq.w #1,d0 ; Assume FUNC if not PRGM, like TICT-Explorer did.
bra.s \GetDataType34Over
\GetDataTypeCheck12:
subq.w #2,d0
cmpi.b #$DB,d1 ; MATRIX_TAG -> 2;
beq.s \GetDataTypeEnd
cmpi.b #$D9,d1 ; LIST_TAG -> 1 (LIST) or 2 (MAT)
bne.s \GetDataType0 ; Not LIST_TAG -> 0 (EXPR).
cmpi.b #$D9,-(a0)
beq.s \GetDataType12Over
subq.w #1,d0 ; Single LIST_TAG -> 1 (LIST).
\GetDataType12Over:
\GetDataType34Over:
\GetDataTypeEnd:
rts


; __ATTR_TIOS__ const char *SmapTypeStrings (short type); (ROM_CALL_436)
; Implemented by Lionel Debroux.
xdef SmapTypeStrings

; Work around a bug in the assembler by not using "\".
; Having an array of 5-character strings was the most size-efficient way I (Lionel Debroux) could think of:
; * Using a C array of strings was obviously out of the question.
; * Using a packed array of strings (offsets of each string from the beginning + strings) would not save space either.
SmapTypeStringsTable:
dc.b "EXPR",0
dc.b "LIST",0
dc.b "MAT",0,0
dc.b "FUNC",0
dc.b "PRGM",0
dc.b "PIC",0,0
dc.b "STR",0,0
dc.b "TEXT",0
dc.b "GDB",0,0
dc.b "DATA",0
dc.b "FIG",0,0
dc.b "MAC",0,0
dc.b "OTH",0,0
dc.b "SYS",0,0
dc.b "ALL",0,0
dc.b "ASM",0,0

SmapTypeStrings:
suba.l a0,a0
move.w 4(sp),d0
cmpi.w #15,d0
bhi.s \SmapTypeStringsEnd
move.w d0,d1
lsl.w #2,d1
add.w d1,d0 ; * 5
lea SmapTypeStringsTable(pc,d0.w),a0
\SmapTypeStringsEnd
rts

Je donne ici l'autorisation d'utiliser le code comme on veut.

Quel sera le mode d'emploi détaillé pour y accéder ? As-tu une table de ROM_CALLs avec plus d'entrées que ce qui est reporté (si oui, ça peut être simple: si 0x32.w = 'RO', on utilise la jump table comme sur AMS 2.xx) ?

Oue. Il suffit de tester si l'adresse de la romcall est non nulle pour savoir si c'est implente (Et ca marchera avec PedroM 0.80 et les RC precedentes de 0.81):

if (AMS_2XX ||(PEDROM_P && (GetDataType != 0))

Sinon pas de probleme pour mettre ces routines sous GPL/

OK. J'aurais oublié le check != NULL, mais de toute façon, sans ces ROM_CALLs, TICT-Explorer perd tout son intérêt...

Romcalls mis dans PedroM. Je ne les ai pas testees.
http://www.medicis.polytechnique.fr/~pphd/preos/pedrom-0.81-rc6.tar.bz2

Merci, ça va me permettre de tester un TICT-Explorer 1.40 correct sous PedroM.