Logicielsmoto.com

Rien à voir avec AVATAR

ou la SCHTROUMPHETTE

ce titre fait en fait référence à la nouvelle production SON+IMAGE de PULS pour ce 14 juillet 2011 (Fête Nationale).

Pour voir ce dont il s'agit, allez faire un tour sur le site de PULS en clickant sur l'image suivante:

Vous y trouverez une archive ZIP avec un fichier SAP et un fichier K7 autoboot. Normalement cela tourne sur toute la gamme TO à partir du moment où il y a de la ram en $A000.

Bon bal du 14 juillet!

sam.

sympa,
pour le moment je n'ai regardé que la vidéo mais je testerai sur mon tO8D ce WE probablement.

_________________
http://www.alternative-system.com

Bonjour,

Vraiment super, j'ai essayé sur TO8D, et émulateur DCMOTO2011 (TO9+ ). Je suppose qu'elle tourne en boucle car je n'ai pas vu l'arrêt de la démo, ou je n'ai pas attendu suffusament

Peut on la mettre dans la page de présentation du site du Forum 2011, avec un lien vers Puls.

http://thomsonistes.free.fr/forum2011

_________________
Cordialement
Louis

C'est l'une des rare démos pas seulement TO8D-TO9+, pour une fois elle est dispo pour TO7 en K7. J'aurais bien aimé faire une fichier WAV, mais toutes mes tentatives avec MESS ou K72WAV.py ont échouées (impossible de recharger par la suite).

En fait non: il suffit de clicker avec la souris ou le crayon optique et on retourne gentiment au basic.

Sans doute. préhisto: t'es ok?

pour la K7, puisque le programme semble gentil avec le basic, autant brancher un vrai LEP sur un TO8 et faire un SAVEM. Puis faire un .wav de cette K7 non?

_________________
http://www.alternative-system.com

Oui, aussi en passant par le menu "5 Exploitation de fichier au boot" (il peut copier de D7 vers K7). Il faut juste respecter l'ordre attendu pour les fichiers sur K7:

- AUTO.BAS (pas le .BAT: on en a pas besoin sur K7)
- intro.BIN
- firew.BIN

Normalement ca se fait bien. Cela occupe environ 4-5min de K7 (24Ko à 900bauds = 4.1 min environ). Avec un WAV et Audacity j'aurais pu facilement ajouter une piste pour avoir de la musique pendant le chargement. Hélas je n'ai pas eu le temps de réaliser la manip avant le 14 (et à présent je suis loin de mon TO9, snif).

Quand on voit la taille de intro.BIN (principalement causée par l'image), je me dis qu'un dé-compresseur façon EXOMIZER2 serait effectivement pratique sur Thomson. J'ai récupéré les sources, mais pour l'instant je suis un peu perdu dans le code qui n'est pas foutu comme je m'y attendais. J'y ai trouvé un assembleur dans le compresseur. Bizarre! J'ai l'impression que sur C64 pour faire un truc auto-extractible, un fichier assembleur est généré puis compilé. J'aurais espéré l'affaire bien plus simple (et plus facilement portable pour 6809).

l'exomizer m'intéresse aussi.
pulkomandy a fait un test avec le vieux compilateur C pour flex que j'ai trouvé (mc09), mais je n'ai pas encore testé le résultat. (il existe une version C du decrunch).

A premiere vue ca doit marcher mais ca serait plus rapide directement en asm.

_________________
http://www.alternative-system.com

Plus rapide et plus compact. Le decompresseur occupe je crois 160 octets de 6502, mais avec un 6809 bien plus riche en instruction on doit gagner une poignée d'octets. Dans la manip de Pulkomandy, c'est des données brutes qui ont été compressées ou un prog basic + asm en mode "sfx" (auto extractible) ?

faut que je regarde exactement, je ne pense pas que ce soit testé juste l'asm du décompacteur 6809 a été généré à partir du source C.

_________________
http://www.alternative-system.com

Pas de problème.

Il y a en effet plusieurs modes dans exomizer. J'ai porté seulement le mode RAW qui permet la décompression d'un bloc de données continu. Il exisgte des modes spécifiques au C64 pour par exemple compresser plusieurs fichiers d'un coup et les décomprésser chacun à son adresse de chargement initiale, ce qui permet de gagner encore un peu de compression. ça serait d'ailleurs probablement utile pour les fichiers thomson qui peuvent être composés de plusieurs chunks.

Il y a également des variantes qui décompressent en partant de la fin ou du début du fichier, il me semble, l'une des deux méthodes permet la décompression sur place (on charge le fichier compressé à l'adresse finale, et on l'écrase pendant la décompression). Mais je ne suis pas sur de ne pas confondre avec un autre packer...

Pour créer le fichier .wav de la cassette TO, il y a aussi Dctok7 2010.04, en téléchargement sur le site dcmoto.
J'ai converti le programme de Samuel pour Windows, pour lui donner une plus grande audience : http://dcmoto.free.fr/win
(il y a plus de Windows installés que de TO en état de marche)

Effectivement, tout le bazar en C dans Exomizer ne nous interesse pas. On peut generer la compression en mode raw (pas d'auto-extracteur C64) directement avec l'executable d'Exomizer et secouer vite fait un generateur de loader si on a envie (et pourquoi pas le rajouter a exomizer plus tard).

Ce qui est important c'est le code assembleur du decompresseur, relativement court, qu'il faut porter. Pour ca on a le choix de partir du 6502 ou du Z80. Mais ce serait encore mieux d'avoir l'algorithme.

Edit: j'ai demande a Magnus une doc sur son algo, on verra ce qu'il me repond.

D'après Magnus, il n'existe pas de documentation sur l'agorithme. Il nous conseille d'etudier le code C correspondant (rawdecrs/exodecr.c).

Effectivement, ce code est presque aussi court que son equivalent assembleur et beaucoup plus facile a comprendre.

De ce que j'en avais lu sur un blog, c'est un LZ77 classique: on regarde en arrière de X octets et on recopie Y octets (si Y>=X, cela étends le RLE à une répétition de blocs: cool ), mais avec un optimisation via codage Huffman du couple (X, Y). J'ai pas encore vérifié si c'est effectivement cela ou plus complexe, mais ca doit être l'idée car cela a de bonnes propriétés: pas de dico à maintenir (en fait le dico sont les données précédemment décodées), il étends naturellement le RLE, et décodage efficace sur les petits CPU.