[EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par 6502man »

jester a écrit :Ne crée surtout pas un format propriétaire... autant lire directement du PCX ce qui permet de produire les fichiers sur PC.
??? justement j'ai fait le convertisseur pour crée des fichiers au format exelvision ????
Si tu utilises ExelMax, Bon courage ! :lol:
J'ai abandonné et suis passé au Cross Compiler...
Exelmax est effectivement pas evident.
Pour l'instant je fait mes routines directement dans l'emulateur en modifiant la ram !
Sinon si tu as un lien pour un cross compilateur, je suis preneur ?
On peut aussi appeler les routines assembleurs du BASIC, mais ça risque d'être plus compliqué sur certains aspects.
je trouve pas specialement compliqué et plutout pratique pour certains cas !

PS: Avec ton algo si tu as une seule occurrence d'un octet à écrire qui a malencontreusement la même valeur que ton octet de contrôle, tu es dans le caca me semble-t'il ? Il te faut dans tous les cas <Rep, Code>+, même si Rep vaut 1... sinon :| Et donc tu perds plein de place si tu n'as pas beaucoup de répétition >1.
Tu n'a pas bien lu, regarde bien la condition: Si caractere de controle..... SINON..... et tu peut voir que cela ne fait pas perdre d'octets et je pense même que l'on peut poussé jusqu'a dire que si un octet se repete moins de 3 fois => ne pas compressé, et la on a encore moins de pertes d'octet.
De plus l'organisation mémoire du VDP me laisse penser qu'il vaut mieux considérer un pattern de 3 octets qu'on répète... ou bien il faut passer à un format PCX (par exemple) pour éviter ce problème.
Le mieux (peut être) pour un format propriétaire serait de placer la valeur de couleur et la répétition dans le même octet (3 bits pour la couleur, 5bits pour la répétition soit 32 répétition d'une couleur). On se retrouve avec un format séquentiel optimal, mais il faut reconstruire le pattern de 3 octets à envoyer au VDP.
Mais je suis pas sur que ce soit vraiment meilleur... à cogiter.
On peut aussi imaginer d'encoder avec cette technique par composante : 1 passe pour le Bleu, une passe pour le vert, une passe pour le rouge (1 bit pour la composante, 7bits pour la répétition). L'image devra être stocké en 3 parties: composante bleu, ensuite composante verte, enfin composante rouge. Pour éviter l'affichage chaotique des 3 passes, il suffit de swapper en mémoire VDP (je change le pointeur BAPA sur ma zone haute résolution qu'une fois mon image construite: il y a assez de mémoire VDP pour supporter un écran texte avec sa police + un écran bitmap 320x200).
Tu te complique, a mon avis, on verras si j'arrive a finir, la decompression sur exelvision.


Aucune de ces techniques ne donnera de résultats formidables, en général tu divises par 2 l'image (rarement plus, souvent moins). Et oui, le RLE c'est tout pourri mais décoder du GIF ou du PNG (coef 5 en compression) c'est compliqué et ça prend beaucoup trop de mémoire sur une vieillerie 8 bits.
Le RLE n'est pas pourri puisqu"il n'y a aucune perte de données avec la compression, d'ailleurs c'est la même technique que le PCX, c'est juste a mon avis la compression la moins lourde a gerer sur un 8 bits (en terme de temps/performance).

Quand au GIF, PNG... , aucun interet sur un 8bits avec 8 couleurs :wink:

Si tu veut tu peut essayer de faire un decompresseur basé sur un autre format ?
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
jester
Messages : 2328
Inscription : 01 janv. 2009 23:16
Localisation : Grenoble

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par jester »

Je continue à penser qu'il y a un Pb si XX=code de contrôle tu dois lire ensuite 2 octets, dans le cas où tu as un et un seul octet à écrire (dont pas de remplissage), mais que sa valeur est le code de contrôle => tu dois toujours considérer on code de contrôle, et dans ce cas tu lis ensuite la valeur à remplir, et ensuite le nombre de répétition, soit 1. Tu perds donc 2 octets... c'est la limite du RLE, tu perds de la place si tu n'as pas ou peu de répétition.
Ex: imaginons que sur ton exemple le code contrôle choisi est 65,
Tu trouves 65, tu dois lire 2 octets, donc tu dois stocker dans ton code compressé 65 65 01
La machine ne peut pas deviner que 65 est parfois un code contrôle, parfois pas.
Le mieux est de choisir le code de contrôle dans les les valeurs rares afin de limiter le problème. Donc le fichier possède alors un en-tête (ce qui est généralement le cas pour les formats connus).

Le RLE a été abandonné depuis longtemps, il compresse très mal les images complexes, et pas tant que ça les images simples, c'est pas l'algo idéal pour de l'image. Mais c'est effectivement l'algo le plus léger pour une machine 8bits. Si tu fais un essai avec une image "photo" convertie avec du dithering, tu verras que 8couleurs ou pas, la compression est mauvaise.

GIF et PNG sont aussi idéals pour les images 8couleurs: toutes tes images ne font que 4-6ko une fois compressé en GIF !!! Mais l'algo est moins adapté aux machines 8bits. Tant qu'il s'agit d'un viewer c'est faisable même sur exl100 (+exeldisk, il faut de la RAM).

Je disais de ne pas créer un nouveau format d'image car si tu compresses tu n'as de toute façon plus de fichier .DES (et même ce format n'en est pas un, c'est juste une image mémoire utilisable dans un et un seul logiciel)... et si on veut retoucher sur PC ça oblige à jongler avec des convertisseurs supplémentaires. La seule justification d'un format ad-hoc est de créer un algo de compression très adapté aux images 8 couleurs et optimisé pour exelvision.

De plus si je te donne l'impression de me compliquer la vie, c'est que l'encodage d'une fichier .DES (sur lequel tu sembles te focaliser) est assez particulier. Il sera difficile de trouver plusieurs octets consécutifs de même valeur (comme avec une image 256couleurs) car l'image est composée de triplet <octet_composante_bleu_8pixels, octet_composante_vert_8pixels, octet_composante_rouge_8pixels>. Donc soit on considère les triplets (et on répète les triplets), soit on considère les octets de chaque composantes ensemble... sinon tu risques de n'avoir aucune répétition !!!

Le coté sympa d'utiliser le BASIC est la gestion de l'interface via l'exelbasic, mais le bestio est quand même très lent même pour afficher une boite avec du texte !!!

Pour le cross Assembler, je te conseille TASM (TeleMark Assembler) qui génère du binaire pour TMS7000. Ultra rapide, ultra pratique.

Pour l'instant je fais du blabla, mais j'ai déjà sorti une oreille des cartons, bientôt la tête et je vais redevenir productif. Si je suis très verbeux sur le sujet des images, c'est que je tourne le Pb dans ma tête depuis 1 bon mois, c'était (et c'est toujours) mon projet... après le déménagement.
Je vais surtout essayer de terminer un petit kit de développement pendant l'été dans l'espoir d'avoir 1 équipe de plusieurs et non pas plusieurs équipes de 1 au développement.
Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par 6502man »

jester a écrit :Je continue à penser qu'il y a un Pb si XX=code de contrôle tu dois lire ensuite 2 octets, dans le cas où tu as un et un seul octet à écrire (dont pas de remplissage), mais que sa valeur est le code de contrôle => tu dois toujours considérer on code de contrôle, et dans ce cas tu lis ensuite la valeur à remplir, et ensuite le nombre de répétition, soit 1. Tu perds donc 2 octets... c'est la limite du RLE, tu perds de la place si tu n'as pas ou peu de répétition.
........
Oui j'avais penser a trouver dans le fichier l'octet non utilisé ou peu utilisé pour comblé ce probleme, et sans avoir besoin de creer un entete il suffit de mettre comme premier octet du fichier de sortie le caractere de controle a trouver ?

Mais de toutes facon pour l'instant j'ai plus trop le temps et surtout il faut que je me penche un peu plus sur l'assembleur pour acceder au lecteur de disquette ?

Pour le remplissage j'ai déjà fait ma routine asm, et elle fonctionne bien !

Apres pour la compression je sait que cela ne seras pas la meilleur dans tous les cas, mais pour obtenir un bon compromis (temps de decompression / place) c'est ce qui me semble de mieux pour l'exelvision ?

Mais si tu trouve un moyen de faire un decompresseur sur l'exelvision performant on peut l'adapter a mon convertisseur :idea:
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
jester
Messages : 2328
Inscription : 01 janv. 2009 23:16
Localisation : Grenoble

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par jester »

Mon objectif est permettre le chargement de PCX :
1) facile à manipuler sur PC
2) on peut charger n'importe quelle taille (dans la limite du 320x200)
3) il suffit d'un convertisseur FICHIER.PCX vers FICHIER.PCX composé d'enregistrements (taille à définir) et de l'entête qui va bien pour le passer sur une disquette EXLDOS. Un utilitaire en ligne de commande permettant le traitement par lot semble le plus simple et le plus pratique.

Coté Exl: disposer d'une bibliothèque à la C pour lire les données octets par octets (et utilisant un tampon qui lit par enregistrement via EXELDOS). c'est un algo de consommation de données, lorsqu'on a tout consommé on recharge. Coté développeur final on voit rien de la mécanique.

Reste le truc merdique à souhait qui montre la simplicité d'esprit des gens d'exelvision:
- lire un fichier en mémoire VDP le stocke en adresse montante (classique)
- lire un fichier en mémoire RAM le stocke en adresse descendante... faut pas l'oublier :mrgreen:
Bien sur cela est très logique car la mémoire VDP se parcourt avec un pointeur incrémental, alors que le TMS7000 n'a pas d'instruction optimisé pour faire une addition 16bits (mais il en possède une soustraction 16bits).

Sinon les routines de l'EXELDOS sont cool... faut juste faire mega attention à la pagination, surtout lorsqu'on utilise une cartouche au même temps (ExelBasic par exemple).

Bon courage.

PS: surtout n'oublie pas que la pile se partage la même zone que les registres... c'est une particularité du TMS7000 qu'il vaut mieux connaitre. Et crois-moi, c'est super-mega chiant à l'usage !
Et attention pleins de registres sont modifiés de tous les cotés (interruptions, routines systèmes, moniteur)...
Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par 6502man »

jester a écrit :Mon objectif est permettre le ....
Le format PCX utilise une compression similaire au RLE ????
jester a écrit :Reste le truc merdique à souhait qui montre la simplicité d'esprit des gens d'exelvision:
- lire un fichier en mémoire VDP le stocke en adresse montante (classique)
- lire un fichier en mémoire RAM le stocke en adresse descendante... faut pas l'oublier :mrgreen:
Bien sur cela est très logique car la mémoire VDP se parcourt avec un pointeur incrémental, alors que le TMS7000 n'a pas d'instruction optimisé pour faire une addition 16bits (mais il en possède une soustraction 16bits).
C'est un peu deroutant au depart mais finalement c'est pas si compliqué que ca !
jester a écrit :Sinon les routines de l'EXELDOS sont cool... faut juste faire mega attention à la pagination, surtout lorsqu'on utilise une cartouche au même temps (ExelBasic par exemple).
Je suis arrivé a lire directement des secteurs de la disquette sur exel en ASM, c'est vraiment beaucoup plus simple que je le pensais :shock:
Je l'ai codé en moins de 10 instructions assembleur :shock:

Par contre pour ouvrir un fichier et le lire sequentiellement la j'obtient qu'une erreur 1F ???
Si tu as reussi a ouvrir un fichier et le lire en ASM je serait curieux de savoir comment tu as configuré le PAB, car je pense qu'il n'y a que la ou j'ai put me trompé ???
J'ai bien fait gaffe que si j'utilise la ram vdp le buffer est ascendant par contre si j'utilise la ram le buffer est descendant !
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
jester
Messages : 2328
Inscription : 01 janv. 2009 23:16
Localisation : Grenoble

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par jester »

Ne te prends pas la tête avec la lecture de secteur !!!
utilises les commandes pour lire les enregistrements.
Je te conseille de jeter un oeil sur mon code pour le chargement de binaire des roms en RAM exeldisk ICI. Tu as les sources sur la disquette.
Je te conseille aussi de désassembler le code de la routine pour charger les images DES que tu utilies (celui de la doc d'exelpaint). Il suffit d'utiliser l'outil de mise au point de Daniel.


Le format PCX est basé sur du RLE. L'en-tête contient plein d'informations utiles et autorise à charger des images de toute taille. Car le pseudo format DES est limité à 320x200. Pour lire un tel fichier il faut:
1) le découper en enregistrement de taille fixe pour peupler le buffer de lecture (disons 255 octets)
2) se développer une librairie de focntion fopen, fread, fclose pour simplifier l'accès aux fichiers, le fread permettant de lire octet par octet (via le buffer). (tu auras aussi besoin de ce genre de fonctions pour lire un DES compressé, sinon galère !)
3) avoir terminé de bricoler son nouvel appart et vider les cartons... et c'est ça le plus long. :mrgreen:
Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par 6502man »

jester a écrit :Ne te prends pas la tête avec la lecture de secteur !!!
C'est que j'ai voulu essayé ce que cela donnais, ca a etait tres facile a coder, ca ma rappeler l'optimisation des disk sur C64 :wink:
jester a écrit :utilises les commandes pour lire les enregistrements.
Je te conseille de jeter un oeil sur mon code pour le chargement de binaire des roms en RAM exeldisk ICI. Tu as les sources sur la disquette.
J'ai regardé et en faite mon code est pratiquement identique au mien sauf la gestion de la pagination (moi j'en ai pas fait, pensant que je pouvait faire comme pour lire/ecrire les secteur des disk, directement en ram cpu)
Mais j'ai l'impression que toutes les commandes passent par l'appel a $D013 doit être paginé ???
jester a écrit :Je te conseille aussi de désassembler le code de la routine pour charger les images DES que tu utilies (celui de la doc d'exelpaint). Il suffit d'utiliser l'outil de mise au point de Daniel.
Ca je l'utilise depuis le debut, et j'ai pas manqué de desassemblé le code pour voir comment cela fonctionne :wink:
D'ailleurs c'est l'un des moyen que j'utilise pour saisir mes code ASM, cela me rappelle MON sur C64 :D
jester a écrit :Le format PCX est basé sur du RLE. L'en-tête contient plein d'informations utiles et autorise à charger des images de toute taille. Car le pseudo format DES est limité à 320x200. Pour lire un tel fichier il faut:
1) le découper en enregistrement de taille fixe pour peupler le buffer de lecture (disons 255 octets)
2) se développer une librairie de focntion fopen, fread, fclose pour simplifier l'accès aux fichiers, le fread permettant de lire octet par octet (via le buffer). (tu auras aussi besoin de ce genre de fonctions pour lire un DES compressé, sinon galère !)

jester a écrit :3) avoir terminé de bricoler son nouvel appart et vider les cartons... et c'est ça le plus long. :mrgreen:
Bon courage
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
jester
Messages : 2328
Inscription : 01 janv. 2009 23:16
Localisation : Grenoble

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par jester »

Je remonte ce topic car j'ai bidouillé un algo de compression basé sur le RLE du format PCX, mais mieux adapté à la mémoire écran et aux 8 couleurs de l'Exl100.
J'obtiens en moyenne 20% de mieux que le format PCX.
Les images (pas trop fouillées) en 320x200 font souvent moins de 10ko.
J'ai essayé d'avoir un format permettant une décompression très optimisée (rien en mémoire et peu en CPU).

L'algo passe aussi assez bien à l'échelle, un petit sprite de 1,26ko en PCX ne fait plus que 323octets dans mon format.

ça ouvre des perspectives intéressantes car 3 grandes images peuvent tenir en mémoire... à suivre :wink:
On en est pas encore à faire du mpeg4 :lol:
Avatar de l’utilisateur
6502man
Messages : 12286
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par 6502man »

C'est tres interressant !

en ce moment j'ai pas assez de temps pour m'y remettre, mais je compte bien reprendre le developpement de l'utiliaire de conversion d'images.

Et si tu veux je peux l'adapter a ton algo de decompression ?
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
jester
Messages : 2328
Inscription : 01 janv. 2009 23:16
Localisation : Grenoble

Re: [EXELVISION] utilitaire de conversion d'image PC vers EXEL.

Message par jester »

Je te filerais les sources.
Mon utilitaire n'est qu'un outil en ligne de commande... je termine la partie sauvegarde au format DCEXEL.

Ensuite je fais un micro programme Exeldos pour charger une image (histoire de tester et sans doute débugger un peu :lol: )

En gros je compte les paquets de 8 pixels identiques et je stocke dans 1 octet, sinon je stocke les paquets de 3 octets pour stocker 8 points (comme d'hab). Facile à décompresser et c'est meilleur que PCX en mode 8bits.
L'encodeur est quand même plus compliqué que celui du format RLE d'un fichier PCX.
Il y a surement des améliorations à faire pour gagner encore un peu... mais passer à de la compression GIF-like risque d'être un peu trop couteuse :roll: alors je focalise sur du RLE++

Dernier modif: plutot très satisfait car plusieurs fichiers (screenshot lucas art, sierra, et image complexe) de 20Ko en PCX donne 5-7Ko dans mon format nommé JIF (Jester Incredible File), clin d'oeil à GIF :)
Si je fais un slideshow, il sera show show chaud bouillant :wink:
Répondre