Structure d'un fichier .K7 VG5000 ================================= T&J/GPA le 20/01/2012 Revision du 12/07/2013 Attention !! Informations partielles, tout n'est pas clair dans cette structure (comme d'habitude, aucun document officiel, grrr... ) Les bases ********* Le VG5000 est capable de manipuler differents types de fichiers : - Basic - Binaire - Screen (image) - Tableau - Chaine - Basicode La sauvegarde d'un fichier utilise la commande CSAVE (SAVE pour le format Basicode). Le chargement d'un fichier utilise la commande CLOAD (LOAD pour le format Basicode). Les fichiers ont tous le meme format sauf les fichiers BASICODE. Ce format est cense assurer une portabilite d'un listing Basic avec d'autres machines. Il est en theorie possible de charger sur un autre type d'ordinateur un fichier BASICODE cree avec le VG5000. Cela n'a que peu d'interet de nos jours, il faut bien l'avouer. Nous n'aborderons dans la suite de ce texte que les formats de fichiers propres au VG5000. Un fichier K7 VG5000 se compose de trois zones : - un "header" ou "en-tete" de 42 octets (&2A) commencant par 10 octet &D3 et se terminant par 10 octets &D6. - la zone de donnees - un "footer" ou "fin de fichier" de 10 octets a &00 En fonction du type d'un fichier, le header contient plus ou moins d'informations. Le footer est lui toujours le meme. Afin de valider que le contenu du fichier n'est pas endommage, le header contient un "checksum", une valeur 16 bits qui est la somme des differents octets de la zone de donnees. Les differents types de Headers ******************************* Fichier BINAIRE =============== &0000 &D3 10 octets identiques &000A M Type fichier Binaire 1 octet &000B Nom du fichier 6 octets (fin = 0 si moins de 6 octets) &0011 &00 Fin du nom du fichier ? &0012 Inutilise &001A Implantation du fichier Deux octets &001C Longueur du fichier Deux octets &001E Checksum &0020 &D6 10 octets identiques &002A debut de donnees L'octet &000A semble ne pas etre tres important. La plupart des jeux commerciaux du VG5000 sont en assembleur mais sont lances par le BASIC avec une commande CALL. Je suppose que cette technique est censee pallier le fait qu'il n'y a pas dans le header d'adresses d'execution pour un fichier binaire. Du coup, meme si l'octet &0A est different de "M", le programme se charge correctement. Exemple : Header K7 MCODE/Machaon (Binaire) D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 4D 43 4F 44 45 00 ..........MCODE. 4F 00 00 00 00 00 00 00 00 00 00 70 20 0D 40 B6 0..........p .@. D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ Fichier implante en &7000, longueur &D20 Fichier BASIC ============= &0000 &D3 10 octets identiques &000A &20 Type fichier Basic &000B Nom du fichier 6 octets (fin = 0 si moins de 6 octets) &0011 &00 Fin du nom du fichier ? &0012 1ere ligne a executer 5 octets maxi 1 octet = 1 chiffre (ex : 10 = &31 &30) si elle a ete indiquee valeur entre 1 et 65529. lors de la sauvegarde Si tous les octets ne sont pas remplis, on met des &00 &0017 &00 Fin de la ligne a executer ? &0018 ?? &0019 ?? &001A Implantation du fichier Deux octets (toujours &49FC, soit le debut du code Basic) &001C Longueur du fichier Deux octets &001E checksum checksum sur les donnees (calcule comment ?). A priori, on ne tient pas compte du header. &0020 &D6 10 octets identiques &002A Implantation de la ligne Basic suivant la premiere ligne &002C 1ere ligne Basic - - - - - fin - &E &00 &00 Fin du code Basic fin - &C &00 12 &00 pour indiquer la fin du fichier. Virer la ligne de depart dans le header d'un fichier BASIC permet de l'editer. Pas d'impact sur le chargement. Calcul du checksum : simple addition des valeurs des octets de donnees, sans tenir compte du header et du footer. Exemple : Header K7 test (Basic) D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 20 4A 41 43 4B 50 .......... TEST. 4F 00 00 00 00 00 00 00 00 00 FC 49 11 00 0D 05 0..........I.... D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ Fichier implante en &49FC, longueur &11, pas d'adresse d'execution Header K7 test2 (Basic) D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 20 4A 41 43 4B 50 .......... TEST. 00 00 36 35 35 32 33 00 00 00 FC 49 10 00 EC 04 ..65523....I.... D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ Fichier implante en &49FC, longueur &10, ligne de depart 65532 Fichier BASIC protege ===================== Ce header particulier empeche le chargement manuel du programme meme lorsque les octets correspondant a la ligne Basic sont supprimes. Il a ete trouve dans le jeu "Tarot" de Nice Ideas. Par rapport a un header standard : &0017 Valeur &21, a quoi cela correspond t'il ? Mystere. Des valeurs autres que &00 donnent le meme resultat. &001A Implantation du fichier Deux octets : toujours &49FB Si vous supprimez simplement le numero de ligne (octets &0011 a &0016), le programme fait un reset lorsque vous faites une commande LIST. Si vous supprimez aussi l'octet &0017, le programme est listable. On retrouve cette protection sur d'autres programmes commerciaux. Exemple : Header K7 Jackpot/Divertissements (Basic) D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 20 4A 41 43 4B 50 .......... JACKP 4F 00 31 00 00 00 00 03 00 00 FC 49 FC 17 9C E3 0.1........I.... D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ Fichier implante en &49FC, longueur &17FC, ligne de depart 1 Octet &17 pas a zero, fichier protege. D'autres formats de fichiers existent sur le VG5000, c'est d'ailleurs assez etonnant pour une "petite" machine. Malheureusement, ils sont assez difficiles a exploiter. Fichier IMAGE (commande CSAVES) =============================== Meme principe qu'un fichier binaire standard, si ce n'est que l'octet 11 est un S (Screen) au lieu de M (Memoire ?). Ce format de fichier ne contient que la zone ram video dans la memoire du VG5000. On ne retrouve pas les tables de caracteres redefinis. exemple : D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 20 4A 41 43 4B 50 ..........SIMAGE 00 00 00 00 00 00 00 03 00 00 00 40 D0 07 1F BB 0.1........@.... D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ Fichier implante en &4000, longueur &7D0 Fichier TABLEAU (commande CSAVE*) ======================================= L'octet 11 a la valeur &BB. exemple : D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 BB 4A 41 43 4B 50 ...........HERVE 00 00 00 00 00 00 00 03 00 00 00 59 2F 00 E1 02 ...........@.... D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ L'adresse d'implantation du fichier correspond au fait a l'emplacement en memoire du tableau lors de sa sauvegarde (ici &5900). A noter que je n'ai pas trouve bonne syntaxe en Basic pour recharger en memoire un fichier contenant des donnees alphanumeriques. La commande CLOAD*"TEST" A$ fonctionne, mais le contenu du tableau A$ ne correspond pas a la sauvegarde. Le petit programme suivant genere un fichier tableau. 1 CLEAR 100,&"6FFF" 10 DIM A$(9) 20 FOR I=0 TO 9 30 A$(I)="TOTO" 40 NEXT I 50 CSAVE*"TEST" A$ Le contenu du fichier contient pour chaque element du tableau non pas la chaine "TOTO" mais un pointeur sur cette chaine en memoire, sa longueur et un separateur (&7E). Bref, difficile d'entrevoir un usage possible a cette commande... Fichier CHAINE (commande CSAVEX) ================================ L'octet 11 a la valeur &58 (X). exemple : D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 58 54 45 53 54 00 ...........TEST. 00 00 00 00 00 00 00 00 00 00 04 4A 10 00 43 04 ...........@.... D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ L'adresse d'implantation du fichier correspond au fait a l'emplacement en memoire de la chaine tableau lors de sa sauvegarde (ici &4A04). La commande de chargement est : CLOAD "TEST" A$ Grosse contrainte a l'usage de cette commande, la variable dans laquelle la chaine doit etre stockee doit avoir une longueur minimale egale a celle de la chaine sauvegardee. Si elle est plus longue, les caracteres "en trop" ne seront pas ecrases. Bref, la aussi, usage restreint. Au final, on comprend pourquoi les rares bouquins presentant des listings VG5000 ont fait l'economie d'une gestion de fichiers, les commandes VG5000 ne permettent pas facilement de sauvegarder des donnees utilisateur... Melanger BASIC et BINAIRE dans un fichier ========================================= Il est possible de creer un fichier contenant a la fois des donnees Basic et binaire. Cela sert en general a limiter le nombre de fichiers a charger, et presente aussi l'avantage de proteger un petit peu le programme. La technique trouvee pour generer ce type de fichier necessite l'usage de l'emulateur DcVg5k. On doit pouvoir aussi le faire avec un vrai VG5000, mais c'est plus complique car il faudra implanter en memoire une routine de chargement du programme binaire. Les programmes commerciaux Philips en abusent pourtant, il doit donc y avoir une technique d'enregistrement permettant de creer des fichiers valides a coup sur (programme externe au VG5000 ?). Exemple : Header K7 U.S.Rallye (Basic mixe avec binaire) D3 D3 D3 D3 D3 D3 D3 D3 D3 D3 4D 56 47 35 30 30 ..........MVG500 30 00 31 30 00 00 00 00 00 00 FC 49 80 34 59 95 0.10.......I.4Y. D6 D6 D6 D6 D6 D6 D6 D6 D6 D6 xx xx xx xx xx xx ................ Fichier Basic/binaire, execution en &49FC, longueur &3480, ligne de depart en 10 Methode DcVg5k: =============== - Faire un reset de la machine. - Charger le programme Basic - Injecter en memoire le programme binaire (avec la commande ). - Sauvegarder le tout avec une commande CSAVEM"PROG",&"49FC",&"longueur totale du code" Miracle, le fichier peut etre recharge et est listable ! Si vous faites une reinitialisation a chaud, le programme se corrompt. Attention ! Cette technique est pour l'instant totalement instable, et les programmes ne fonctionneront pas forcement. Plantage assure avec de gros programmes. L'analyse du header montre que le programme est considere comme du binaire. Etrangement, suivre la meme procedure en ayant protege la memoire reservee au binaire avec une commande direct CLEAR xxx,&"yyyy" genere un fichier corrompu (message ERREUR FICHIER lors d'une tentative de chargement). Seule difference par rapport a la "bonne" methode, le checksum est different.