Il est diffusé avec les sources, sans aucune garantie. A utiliser à vos risques et périls.
[Exelvision] Dcexeldisk
Modérateurs : Papy.G, fneck, Carl
[Exelvision] Dcexeldisk
DC Exel Disk Toolbox v2009.03 est un utilitaire de manipulation d'images de disquettes Exelvision au format .fd
Il est diffusé avec les sources, sans aucune garantie. A utiliser à vos risques et périls.
Il est diffusé avec les sources, sans aucune garantie. A utiliser à vos risques et périls.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
fneck
- Site Admin
- Messages : 17490
- Inscription : 01 avr. 2007 12:03
- Localisation : Drôme Provençale (26)
- Contact :
Très intéressant comme outil pour manipuler les images, merci.
Fabien https://www.system-cfg.com
Les bonnes pratiques de l'utilisateur du forum viewtopic.php?f=14&t=3
Les bonnes pratiques de l'utilisateur du forum viewtopic.php?f=14&t=3
-
gatesbillou
- Messages : 128
- Inscription : 31 juil. 2008 14:02
- Localisation : la cadiere d'azur - var (83)
Au début je ne comprenais pas comment Daniel arrivait à recréer sur une disquette FD les fichiers avec les mêmes tailles d'enregistrement d'origine à partir de fichiers dans un répertoire WINDOWS.
En relisant et en scrutant les fichiers Windows j'ai compris que chaque fichier doit posséder un HEADER de 18octets: un FDR fictif qui contient toutes les infos utiles pour reconstruire ce fichier au sein d'une disquette.
Donc, pour ajouter un fichier à une disquette il faut ajouter ce HEADER en plaçant tout à zéro sauf:
l'octet de départ FD
le nombre d'enregistrement et la taille
le numéro de la première AU (toujours 00 01 il me semble).
le nombre d'AU utilisé: la je n'arrive pas à trouver la bonne valeur à placer. Sur un fichier exelpaint faisant 120*200octets j'aurais dis 2F (120*200/512) mais on trouve 30 (donc 1 AU de plus) ??? J'ai du loupé un truc car ça marche bien avec 30.
L'objectif étant bien sur de placer des fichiers qui viennent directement de windows (image retraité sous Gimp, fichier LPC, etc.).
En relisant et en scrutant les fichiers Windows j'ai compris que chaque fichier doit posséder un HEADER de 18octets: un FDR fictif qui contient toutes les infos utiles pour reconstruire ce fichier au sein d'une disquette.
Donc, pour ajouter un fichier à une disquette il faut ajouter ce HEADER en plaçant tout à zéro sauf:
l'octet de départ FD
le nombre d'enregistrement et la taille
le numéro de la première AU (toujours 00 01 il me semble).
le nombre d'AU utilisé: la je n'arrive pas à trouver la bonne valeur à placer. Sur un fichier exelpaint faisant 120*200octets j'aurais dis 2F (120*200/512) mais on trouve 30 (donc 1 AU de plus) ??? J'ai du loupé un truc car ça marche bien avec 30.
L'objectif étant bien sur de placer des fichiers qui viennent directement de windows (image retraité sous Gimp, fichier LPC, etc.).
Les lignes d'un fichiers exelpaint sont composées de 120 octets précédés de la longueur de la ligne sur deux octets. Soit 122 octets par ligne et 24400 pour 200 lignes. Donc 48 unités d'allocation (30 en hexadécimal). On voit dans le FDR :
- Nombre d'enregistrements : 00C8 (200 en décimal)
- Longueur d'enregistrement : 0078 (122 en décimal)
La taille logique du fichier est de 244000 octets. Sur la disquette l'unité d'allocation a une longueur de 512 octets, le fichier occupe physiquement 49 AUs (48 pour les données plus 1 pour le FDR).
Un fichier exelvision contient, en complément des données :
- 1 octet de flags (attributs du fichier)
- 2 octets pour le nombre d'enregistrements
- 2 octets pour la taille des enregistrements
Il faut donc stocker au minimum 5 octets supplémentaires. Par analogie avec la structure des fichiers sur disquette, j'ai placé ces octets dans un File Descriptor Record (FDR) de 256 octets, lui-même stocké dans une unité d'allocation (AU) de 512 octets. Toujours par analogie avec la structure des disquettes, j'ai mis dans le FDR le n° de la première AU des données. C'est toujours 1 car elle suit l'AU n°0 contenant le FDR. J'ai mis aussi le nombre d'AUs nécessaires pour stocker les données du fichier. Ces deux dernières informations ne sont pas strictement nécessaires puisqu'on peut les recalculer, mais je trouve plus élégant de garder exactement la structure des fichiers sur disquette.
Pour l'anecdote : il y a quelques mois j'ai écrit qu'il fallait une demi-journée pour écrire ce programme. Evidemment c'était une blague, pour inciter quelqu'un d'autre à faire le travail. Je m'y suis lancé faute de volontaire. Et en réalité j'ai mis deux bons jours
- Nombre d'enregistrements : 00C8 (200 en décimal)
- Longueur d'enregistrement : 0078 (122 en décimal)
La taille logique du fichier est de 244000 octets. Sur la disquette l'unité d'allocation a une longueur de 512 octets, le fichier occupe physiquement 49 AUs (48 pour les données plus 1 pour le FDR).
Un fichier exelvision contient, en complément des données :
- 1 octet de flags (attributs du fichier)
- 2 octets pour le nombre d'enregistrements
- 2 octets pour la taille des enregistrements
Il faut donc stocker au minimum 5 octets supplémentaires. Par analogie avec la structure des fichiers sur disquette, j'ai placé ces octets dans un File Descriptor Record (FDR) de 256 octets, lui-même stocké dans une unité d'allocation (AU) de 512 octets. Toujours par analogie avec la structure des disquettes, j'ai mis dans le FDR le n° de la première AU des données. C'est toujours 1 car elle suit l'AU n°0 contenant le FDR. J'ai mis aussi le nombre d'AUs nécessaires pour stocker les données du fichier. Ces deux dernières informations ne sont pas strictement nécessaires puisqu'on peut les recalculer, mais je trouve plus élégant de garder exactement la structure des fichiers sur disquette.
Pour l'anecdote : il y a quelques mois j'ai écrit qu'il fallait une demi-journée pour écrire ce programme. Evidemment c'était une blague, pour inciter quelqu'un d'autre à faire le travail. Je m'y suis lancé faute de volontaire. Et en réalité j'ai mis deux bons jours
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Reste que mes données font 24400octets + le header 512octets = 24912
Mais mon fichier fait 25088octets, donc j'ai 176 octets en trop ???
Je sens que je vais finir par comprendre.
Ok il s'agit des 176octets permettant de compléter ma 49ieme AU... on a toujours un multiple de 512 comme taille de fichier.
Donc il y a des données inutiles en fin de fichier, mais pas à 0 !!!
Mais mon fichier fait 25088octets, donc j'ai 176 octets en trop ???
Je sens que je vais finir par comprendre.
Ok il s'agit des 176octets permettant de compléter ma 49ieme AU... on a toujours un multiple de 512 comme taille de fichier.
Donc il y a des données inutiles en fin de fichier, mais pas à 0 !!!
Dernière modification par jester le 25 mars 2009 16:29, modifié 1 fois.
Logiquement le fichier contient le FDR de 256 octets et 24400 octets de données. Mais :
1) Le FDR est stocké dans une unité d'allocation de 512 octets, donc 256 octets sont perdus.
2) Les données sont stockées dans 48 unités d'allocation, soit 24576 octets, donc 176 octets sont perdus.
La taille physique du fichier est toujours un multiple de la taille de l'unité d'allocation (512).
1) Le FDR est stocké dans une unité d'allocation de 512 octets, donc 256 octets sont perdus.
2) Les données sont stockées dans 48 unités d'allocation, soit 24576 octets, donc 176 octets sont perdus.
La taille physique du fichier est toujours un multiple de la taille de l'unité d'allocation (512).
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
J'avais trouvé tout seul : Champion du monde.
Donc les données inutiles (pour aligner sur un multiple de 512) en fin de fichier devraient être à 0... non ? C'est pas grave... mais je comprends la logique.
Bon il faudra générer des fichiers bien formés avant intégration sur une disquette.
Reste à savoir si Fabrice va réussir à copier le contenu d'une disquette virtuelle sur une disquette physique.
Donc les données inutiles (pour aligner sur un multiple de 512) en fin de fichier devraient être à 0... non ? C'est pas grave... mais je comprends la logique.
Bon il faudra générer des fichiers bien formés avant intégration sur une disquette.
Reste à savoir si Fabrice va réussir à copier le contenu d'une disquette virtuelle sur une disquette physique.
Oui, ce serait plus logique de remettre à zéro les octets inutiles. Exelvision ne le fait pas : il reste ce qu'il y avait en mémoire au moment de l'écriture. Alors je ne me suis même pas posé la question, j'ai fait pareil. On peut voir ces octets inutiles dans toutes les images de disquettes avec un éditeur hexadécimal.
Une utilité de dcexeldisk est de permettre de réparer la structure des fichiers incorrects. Je l'ai fait pour le dessin n°1 de la démo exelpaint. La réparation de la structure permet d'afficher le dessin sans planter exelpaint, mais ne peut pas retrouver les octets perdus. Van Gogh ne me pardonnera peut-être pas cette restauration à la manière de Picasso.
Une utilité de dcexeldisk est de permettre de réparer la structure des fichiers incorrects. Je l'ai fait pour le dessin n°1 de la démo exelpaint. La réparation de la structure permet d'afficher le dessin sans planter exelpaint, mais ne peut pas retrouver les octets perdus. Van Gogh ne me pardonnera peut-être pas cette restauration à la manière de Picasso.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
Je remarque juste qu'ils se sont pas cassés le *#$ chez exelvision pour fournir les images. ça ressemble à des scans dégradés en 8 couleurs (avec tramage). A l'époque ça devait être pénible à obtenir, mais sans doute moins que de dessiner avec 8 couleurs.
Il faut 30s sous GIMP pour avoir une image comme-celle ci avec le mode palette indexé en 8 couleurs (construite pour l'occasion).
Le seul moyen d'obtenir des images jolies et nette est de dessiner en mode BD... j'arrive avec GIMP à transformer des planches de sprites 256 couleurs en planches 8 couleurs très sympa (sans tramage). Reste à faire une moulinette qui récupère le mode RAW de GIMP pour construire un fichier bien adapté à la gestion sur EXEL100 et l'encapsuler dans le container à Daniel pour l'importer sur disquette (ça sera pas le plus dur).
Si y'a des fans de oldies qui connaissent des outils ou des filtres pour dégrader une image en 8bits ou 24 bits en 8 misérables couleurs... ça m'intéresse.
Il faut 30s sous GIMP pour avoir une image comme-celle ci avec le mode palette indexé en 8 couleurs (construite pour l'occasion).
Le seul moyen d'obtenir des images jolies et nette est de dessiner en mode BD... j'arrive avec GIMP à transformer des planches de sprites 256 couleurs en planches 8 couleurs très sympa (sans tramage). Reste à faire une moulinette qui récupère le mode RAW de GIMP pour construire un fichier bien adapté à la gestion sur EXEL100 et l'encapsuler dans le container à Daniel pour l'importer sur disquette (ça sera pas le plus dur).
Si y'a des fans de oldies qui connaissent des outils ou des filtres pour dégrader une image en 8bits ou 24 bits en 8 misérables couleurs... ça m'intéresse.
Je connais un outil qui permet de passer une image dans le nombre de couleurs que l'on souhaite pour Linux. Il me semble qu'il existe aussi pour Windows.
Présentation de imagemagick et de sa commande convert.
Installer le paquet imagemagick :
Ensuite, la commande convert est accessible depuis le terminal. pour réduire le nombre de couleurs d'une image il suffit de faire :
Voici les deux images en question :
Cette outil permet de modifier pas mal de choses, le format d'une image, sa résolution, le nombre de couleurs utilisées, etc... en fait imagemagick est un bon couteau suisse de manipulation d'image.
Voilà, my 2 cents, pour une fois que je peut aider un peu
Présentation de imagemagick et de sa commande convert.
Installer le paquet imagemagick :
Code : Tout sélectionner
sudo apt-get install imagemagickCode : Tout sélectionner
convert -colors 8 source.jpg result.pngCette outil permet de modifier pas mal de choses, le format d'une image, sa résolution, le nombre de couleurs utilisées, etc... en fait imagemagick est un bon couteau suisse de manipulation d'image.
Voilà, my 2 cents, pour une fois que je peut aider un peu
Seules les 8 couleurs "exl100" peuvent être utilisées. Pour ma part j'utilise PaintShopPro 7.02. Une copie d'écran quelconque (mais comportant impérativement les 8 couleurs) permet de sauver la palette exelvision. Ensuite il suffit d'appliquer cette palette à n'importe quelle image. Exemple d'un tableau réduit en 160x200. Remarquez que c'est mieux que la démo exelpaint. Le deuxième exemple est une image 320x250 avec les couleurs exl100. Quand la résolution est très faible le tramage n'est pas, à mon avis, une bonne solution.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.