porter des progs non compatibles AMS2 - Page 1

comment fait-on ?
quelles sont les modifs à faire ?

Comment on fait?

Je pense qu'il suffit de savoir la différence entre le HW1 et le HW2 et corrigé tout ça proprement

ce que jeux veux savoir, c'est pas HW1/HW2 mais AMS1/AMS2

Généralement y a rien à faire. Recompiler la source. Changer des constantes en ram call.

quelles constantes sont à changer ?

pour un prog dont on a pas la source, on désassemble, ou on peut le faire à l'éditeur hexa ?

oups excuse

c dur...
en gros c les valeurs de Heap et de MainHandle et FolderListHandle

ExtendeD : c'est pas generalement, mais rarement qu'il suffit de recompiler !

- il faut sauvegarder les registres d0-d2/a0-a1 apres chaque appel d'une fonction du tios
- certaines choses ont change, comme la VAT, il faut utiliser FolderListHandle, MainHandle, ...

>- il faut sauvegarder les registres d0-d2/a0-a1 apres chaque appel d'une fonction du tios

On était censé faire de même sous AMS 1. (C'est connu depuis longtemps: c'est écrit même dans la documentation de Fargo!) Les programmes qui ont eu des problèmes à cause de cela étaient bogués.

>- certaines choses ont change, comme la VAT, il faut utiliser FolderListHandle, MainHandle, ...

... ou les ROM calls appropriés (beaucoup plus propre que ces RAM calls qui ne devraient pas exister, surtout vu l'utilisation que l'on en fait (l'accès direct à la VAT)).

JE NE SUIS PAS D'ACCORD !

(beaucoup plus propre que ces RAM calls qui ne devraient pas exister, surtout vu l'utilisation que l'on en fait (l'accès direct à la VAT)).

Kevin Kofler veut nous interdire l'accès à la VAT ?????!!!!!
C'est quoi ton problème ?
Les RAM_CALLs sont plus rapides que tes merdes de ROM_CALLs, raison de plus pour les utiliser. _nostub SUX.

>C'est quoi ton problème ?

Qu'il y a des ROM calls faits pour cela! Et que les ROM calls renvoient des pointeurs, donc continueront à marcher même si TI élargit la structure SYM_ENTRY pour y rajouter des informations (ce qu'ils ont déjà fait de la TI-92 à la TI-89/92+), alors que la lecture directe de la VAT ne marchera plus.

S'il y a des ROM calls, autant les utiliser plutôt que de réinventer la roue en les réécrivant (en utilisant les RAM calls de type Heap, FolderListHandle ou MainFolderHandle).
[edit]Edité par Kevin Kofler le 11-07-2001 à 19:37:39[/edit]

3.. 2.. 1.. FIGHT!

Thibaut : C'est trop lent les ROM_CALL ?
Bah le truc le plus simple est bien de simuler les RAM_CALL en les calculant au debut du prog, et apres tu utilises tes pseudo RAM_CALL et c bon, plus de probleme !
Et puis meme pour les ROM_CALL c pas si lent que ca, de tt facon on ne s'en sert que pour des trucs qui ne demandent pas de rapidite...

de tt facon on ne s'en sert que pour des trucs qui ne demandent pas de rapidite...
Là je suis entièrement d'accord

Paxal->oui.
FlahZ->"de simuler les RAM_CALL en les calculant au debut du prog"
ouais, mais à part pour apprendre à le faire (c surement tres interressant), je ne vois aucun interet à implementer ça ! les kernels sont la pour

à la limite, si tu veux le faire, fais un kernel. ça aurra en plus le merite de faire un folder de + pour les archives de ticalc
[edit]Edité par Pen^2 le 11-07-2001 à 23:24:11[/edit]

Oué, pas touche à la VAT, utilisez le VFS !

#include <prosit/prosit.h>
#include <stdio.h>
int main(void)
{
int f1,f2;
char buff[10];
f1 = open("/boot/main/song1")
f2 = open("/dev/audio")
while(read(f1,buff,10)!=10) {
write(f2,buff,10);
}
close(f2);
close(f1);
return 0;
}

VFS rulez

ben quoi c'est vrai, le Virtual FileSystem (ou Virtual Filesystem Switch c'est au choix) ça rulez bien et ça permet de faire tout un tas de trucs tout en restant propre (c'est que des fichiers)
VFS rulez !

>Pen^2 : ouais, mais à part pour apprendre à le faire (c surement tres interressant), je ne vois aucun interet à implementer ça ! les kernels sont la pour

L'interet est simple : je n'utilise aucune lib, et rajouter ce genre de code dans mon prog rajoute environ 100 octets a la taille de mon prog, je ne vois donc pas pk je programmerais en mode Kernel

paske !
les Kernel Petit Jean c'est bon, mangez-en !

Pen² a répondu avant moi
Effectivement les kernels évitent d'avoir à reprogrammer ces RAM_CALLs... En résumé Kevin ne m'a pas convaincu. Si TI changait la structure le la VAT, il suffirait de mettre à jour UniOS pour que tout rentre dans l'ordre.
_nostub SUX...

Bien sûr que j'utilise filelib !
Les ROM_CALLs ça peut foirer aussi : il fuffit que TI en insère un ou plusieurs dans sa nouvelle ROM, et tous les progs _nostubs seront inutilisables
Avec filelib on a pas ce problème, une mise à jour d'1 librairie suffit. _nostub SUX.

>Thibaut:

>Bien sûr que j'utilise filelib !

Désolé, mais filelib est une des librairies le plus boguées qui existent, et en plus elle n'a aucun intérêt (à quoi bon réécrire les fonctions qui sont déjà dans la ROM?!?).

>Les ROM_CALLs ça peut foirer aussi : il fuffit que TI en insère un ou plusieurs dans sa nouvelle ROM, et tous les progs _nostubs seront inutilisables

Non. Si TI veut ajouter des ROM calls, ils les mettront à la fin de la liste (comme ils ont touours fait jusqu'à présent), d'autant plus que leur SDK officiel utilise les numéros de ROM calls et que l'accès à la table des ROM calls par $c8 est officiellement documenté par TI (même si leur SDK utilise le Line 1111 Emulator).

>Avec filelib on a pas ce problème, une mise à jour d'1 librairie suffit.

Avec le _nostub, on n'a pas de problème du tout, il n'y a aucune librairie à mettre à jour (cf. ma réponse précédente).

>_nostub SUX.

...
(Garde ce genre de commentaires qui n'apportent rien pour toi la prochaine fois s'il te plaît.)

(Garde ce genre de commentaires qui n'apportent rien pour toi la prochaine fois s'il te plaît.)
Alors, toi arrête de faire l'éloge du _nostub.

et en plus elle n'a aucun intérêt (à quoi bon réécrire les fonctions qui sont déjà dans la ROM?!?)
narchivVoyons.jsr filelib::u=4 octets

    movem.l    d0/d1/d3-d7/a0-a6,-(a7)
    bsr        inuse
    cmp.w      #doorsos::FolderListHandle,d0
    beq        error
    bsr        hsymprep
    move.l     d6,-(a7)
    clr.l      -(a7)
    jsr        doorsos::EM_moveSymFromExtMem
    addq.l     #8,a7
    tst.w      d0
    beq        memory
    bra        normalend

hsymprep:
    clr.l      d6
    move.w     d0,d6
    swap       d6
    moveq.l    #4,d5
    mulu       #14,d1
    add.w      d1,d5
    move.w     d5,d6

> 4 octets.

A part prendre 100* plus de place, c'est quoi l'avantage du _nostub (puisque pour toi le _nostub c'est un avantage, je suppose que le manque de mémoire te fait jouir...) ?
[edit]Edité par Thibaut le 13-07-2001 à 16:08:49[/edit]

bon, revenons au sujet.
dans db92, je trouve des instructions movea.l $11A,a1 (code hexa 22 79 00 00 01 1A) avec dans la table des ROM_CALL un ROM_CALL_2F sur se 1er 00.
je pense que c'est pour faire move.l #doorsos::Heap,a1 sous AMS1, c'est ça ?
je ne peux pas en être sûr car je suis obliger de le désassembler avec un désassembleur non doors ( à cause de la taille).

AS92 a été programmé en C...
Autrement dit, bon courage pour piger le source désassemblé...

programmé en C ?
ça explique certain trucs bizarres du code, mais il n'y a pas les traditionnels link #0,a6 et unlk a6

>jsr filelib::unarchiv
>=4 octets

Non, 10 octets. 6 pour le jsr absolu, 2 pour le numéro de la fonction dans la table de relogement et 2 pour le relogement. Sans compter l'identifiant 'filelib' dans la table de relogements (8 octets), le nombre de fonctions de filelib utilisés (2 octets) ou le stub pour le kernel (40 octets minimum)

>l'énorme routine avec les ROM calls que tu as donnée

Ça, c'est du copier-coller de filelib qui montre à quel point filelib est inefficace.

Compare ça à l'utilisation d'un HSym donné par un ROM call officiel, comme par exemple SymFind:

 move.l d0,-(a7) ;d0 contient un HSym
 clr.l -(a7)
 ROM_CALL EM_moveSymFromExtMem ;ou jsr doorsos::EM_moveSymFromExtMem si tu préfères
 addq.l #8,a7

ou d'un nom de fichier:

 clr.l -(a7)
 pea.l sym(PC)
 ROM_CALL EM_moveSymFromExtMem ;ou jsr doorsos::EM_moveSymFromExtMem si tu préfères
 addq.l #8,a7

avec:

 dc.b 0,'folderfile'
sym: dc.b 0

ou alors d'un pointeur SYM_ENTRY * retourné par des fonctions comme SymFindNext et du HSym du répertoire retourné par SymFindHome (c'est la solution la plus pratique pour traverser toute la VAT):

 move.w d0,-(a7) ;en supposant le HSym du répertoire dans d0
 move.l d1,-(a7) ;en supposant le SYM_ENTRY du fichier dans d1
 ROM_CALL MakeHSym ;ou jsr doorsos::MakeHSym si tu préfères
 addq.l #2,a7
 move.l d0,(a7)
 clr.l -(a7)
 ROM_CALL EM_moveSymFromExtMem ;ou jsr doorsos::EM_moveSymFromExtMem si tu préfères
 addq.l #8,a7

hwti : Etrange... Tu es sûr qu'il n'y a aucun LINK ?

oui