Forum Graph100

je viens de trouver un petit truc en plus:

àprès les ..B il y a 0x18, ce qui à l'aire de rester constant peut-être que ça veut dire qu'il faut ajouter à 0x1800:0 mais le plus important c'est que l'octet après ce 0x18 insique le nombre de zone de chaque type !!

voilà je continu mes recherches !

@+

ok !
basiclib2.0 va bientot sortir !

C'est déjà fait depuis 1 semaine ! et en effet je gagne un temps infinie tout est immédiat même rechercher un fichier basic au delà de 85Ko ne prends qu'une fraction de dixième de seconde !

Sinon pour les recherche selon le type, je suis en train de le faire, mes routines risque d'être renomé memory_zone_access_libs.

Pour le findfirst findnext je n'avais pas prévu d'en faire car si ça doit gérer les cractère génériques ça risque dêtre compliqué et surtout de faire grossir la taille de la lib qui a déjà pas mal grossie.

Sinon ce n'est pas très dure à implémenter, pour parcourir la liste des fichiers basiques il suffit de faire ça :

{
    unsigned long transit;
    char far *basic_prog_ptr, far *curent_b_ptr;


    basic_prog_ptr = tell_mem_zone_seg(1);
    curent_b_ptr   = basic_prog_ptr;

    while (curent_b_ptr[2] == 0x01) {

             //...

    transit = *((u_int far *)(curent_b_ptr));
    curent_b_ptr = (char far *)((u_long)curent_b_ptr + (transit & 0xF) + ((transit >> 4) << 16));
    }
}

char far *tell_mem_zone_seg(int id) retourne un pointeur far sur la taille de la première zone du type id choisi.

(ne cherchez pas les bug car y'en a pas)


Donc si tu veut parcourir la liste à partir d'un nom tu n'as qu'à faire pointer curent_b_ptr sur ce nom et l'incrémenter suivant le shémas précédent (qui est si compliqué car doit suporter des adressages de plus de 0xFFFF octets...)

@+

Je devrais avoir fini dans qq jours, il faut patienter encore un peu

Salut,

Je crois kil valais mieux ke les premiers resultats restent entre nous dans un premier temps juska etre sur des Infos,
Cest pour ça dailleurs ke jai pas voulu publier d'infos Précoces,
En tt cas je dois dire ke jai pas tres bien compris ce ke tu voulais dire ds ton poste (l'explication), mais tu sembles ne pas etre
arrivé a la meme explication ke moi !

Ça ne veut surtt pas dire ke c faux, peut etre ke c ce ke jai trouvé mise a part ke tu las mal expliké...

En tt cas, en ce ki me concerne, bein avant hier je croyais ke javais vraiment tt compris et kil ne restait plus ka developé le premier
programme de démonstration pour la creation de fichiers basikes Automatike, mais ce matin, jai retesté la zone mémoire avec de nouvelles
Données, pis je me suis rendu compte kil fallait kil me mankait un détail, la je suis entrain de le chercher.
ça riske de prendre kelkes temps.

En tt cas, regarde ce shéma et jespere ke tu vas comprendre, car jai vraiment pas envie de trop ecrire:
traduit en Décimal:

Début: 1BF2:00
     0    64 

    24    29     0    10    66 
    24     1     0    34    66 zone Prog 
    24     1     0    54    66 zone Graphique
    24     1     0    76    66 zone Fname et autre chose
    24     0     0    76    66 
    24     3     0     4    67 zone Liste
    24     1     0    69    67 zone Matrice
    24     1     0    82    75 zone Image
    24     0     0    82    75 
    24     0     0    82    75 
    24     0     0    82    75 
    24     0     0    82    75 
    24     7     0   123    76 Zone Systeme
    24     0     0   123    76 
    24     0     0   123    76 
    24     0     0   123    76 
    24   255   127    56   122    76 
    24     0     3    54    66 Zone réagissant aux Prog et Grafike
    24     0     0     0 
Fin: 
   128    56 

Légende:
Chake Ligne corespond a une Zone, ya des zones ke jai pas mentionné kar jai pas trop le temps de faire ts les tests
et pis çâ nous interresse pas trop
Chake Colonne represente une Information sur une Zone, voici le detail de chake colonne


- Alors la premiere colonne represent lidentificateur du début de la zone (markeur), il ne sert pas a grand chose.
- la deuxieme colonne represente le nombre de fichiers ds la zone spécifiée, par exemple ds la zone prog si tas deux Progs cette valeur sera egale a 2à
meme chose pour les listes et matrices, si tas une liste en mémoire  ds la case corespondante a Liste yaura 1....
- la 3eme ne change pas
- la 4eme represente la taille de façon cumulative dans le ses descendant du tableau, regardez bien:
au debut on a 10 octetc doffice ensuite on a un prog de 24 octets: 10+24=34
pis on  une equation ke jai dessinée ds le menu Graf de la Casio ki prend 20 octets, donc 34+20=54
1 Fname de 22 Octets, comme toujours, donc: 54+22=76
puis on a 3 listes mais leur taille est de 184 Octets, donc 76+184=260 mais comme un octet peut contenir au max une valeur de 255
on a recours a loctet dapres pour lincrementer donc, ds la colonne dapres (le fameux B) devient C, donc 66+1=67
pis AInsi de suite,
mais vers la fin les choses se corsent et cest la ou je travaille actuellement:
la 3eme ligne avant la fin, bcp dinformations ! tas un 255 ki a mon avis donne une indication sur la base utilisée, il devient parfois 127 chamboulant
par la meme ocasion ts les calculs kon a fait precedemment et lavant dernier octets de cette ligne le 122, est toujours Inférieurs de 1 a ce kil devrait etre !

pis lavant derniere ligne est bizarre aussi, cette Zone, ds la case relative a la taille, ne reagit kkaux donnée des Prog et des grafikes, Bizarres !

Je donnerai plus dexplications des ke je le pourrai !

Envoie moi ce ke tas fait, avec un peu plus de Detail 2072 !

Oui pour les 2 dernières zones je me suis posé pas mal de questions mais je pense que c'est simple:

- l'avant dernière pointe vers la TAILLE de la dernière zone, sûrement pour pouvoir parcourir les zones dans l'autre sens.

- la dernière est la même que la zone identifier par 0x03 (FNAME et d'autres) seulement pour pouvoir localiser FNAME très rapidement sans avoir à parcourir.

Je pense pas qu'il faille chercher plus loin



DES POINTS TRÈS IMPORTANT DONT JE SUIS SÛRE:

LA PLUS IMPORTANTE :


le 24 qui constitu ta première colonne (0x18) n'est pas un identifieur mais le segment de départ / 100. des zones.

soit la base des adresses sur 2 octets qu'il faut rajouter à ce 0x18 * 1000

le .@0x40 au début n'est en aucun cas un marqueur mais tout simplement comme les autre zone: un pointeur vers la zone 0 et oui les variables A à Z + 3 29 variables en tout (29 == 0x1D)

Je suis sûre de ma méthode:
- mais une valeur dans la var A
- selon ma théorie elle devrai se trouver à 0x18 * 0x1000 + 0x4000 == 0x1C000 soit 0x1C00:0x0
- regarde avc TOUCHE et tu arriveras sur la taille occupé par la var A

et c'est pareille pour toute les autres zones, il ne peut y en avoir que 16 au total puisque l'id de chaque zone tiens sur 1 octet (cette id ce trouve juste avant le nom de chaque zone c'est 0x01 pour les fichiers basiques)

ce qui montre que les 2 dernieres zones voir même les 3 dernières ne servent pas à la même chose, (l'antépénultième zone aurrait 0x7FFF éléments, je ne l'ai jamais vu changé :???: ).

- et le nombre de zones de chaque type tiens sur 2 octets.


J'ai bientôt fini les lib basics ça devrait marcher dans quelques heures...

Mais je n'ai jamais vu changer le 0xFF en 0x7F sauf le 0x18 devient 0x28 quand nécessaire si plus de 65535 Ko de fichiers basiques par exemple...

Une fois mon prog terminé il sera très facile de faire des tests.

@+

  super cool !

Bravo !

oublie pas de menvoyer le tout pour ke je puisse tester
.

@+

lol vous postez tard vs!

2072 Check t mails je t envoyer la reponse a ton probleme en assembleur

Vous êtes trop fort les gars.... Fo ke je mette les fonx basic ds mes jeux...  :up: 2072 :up: