Exomizer sur MO5 ???

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

__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: Exomizer sur MO5 ???

Message par __sam__ »

6502man a écrit :le INX est bien compris par mon assembleur et donne ce code assemblé $30 $01 :roll:
Oui ca donne "LEAX 1,X". C'est bon.
En faite je viens de trouver le problème lorsque j'inclus cette routine en 1Fxx ca plante si je la place ailleurs que dans le zone vidéo ca fonctionne :lol: :lol: :roll:
C'est sur que si le texte affiché détruit le programme il va se passer des trucs bizarres :mrgreen:
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
6502man
Messages : 12242
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Exomizer sur MO5 ???

Message par 6502man »

Oui mais la j'utilise la zone après $1F40 qui ne correspond pas à l'écran, mais peut être utilisé par le moniteur :roll:
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
Daniel
Messages : 17288
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Exomizer sur MO5 ???

Message par Daniel »

La plage $1F40-$1FFF est dans une zone de ram commutée par le bit 0 de $A7C0. Si ce bit change entre le chargement et l'exécution du programme, ou pendant l'exécution, ça ne peut pas marcher.

Dans les machines de première génération (TO7, MO5, TO7/70) cette zone n'est jamais utilisée par le système. Elle est utilisée uniquement par les TO8, TO9 et TO9+.
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: Exomizer sur MO5 ???

Message par __sam__ »

Oui, il est certain que l'affichage des texte commute forme/fond, et qu'il y a toutes le chances que la page mémoire en sortie du SWI soit différente de celle en entrée. Résultat au retour du SWI on a n'importe quoi. Plante, et retour au basic.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
6502man
Messages : 12242
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Exomizer sur MO5 ???

Message par 6502man »

Oui c'est ca la commutation de la page formes et couleurs, je n'y avait pas pensé :oops:
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
Fool-DupleX
Messages : 2271
Inscription : 06 avr. 2009 12:07

Re: Exomizer sur MO5 ???

Message par Fool-DupleX »

Cette zone est par contre utilisée par LOGO et par le Nanoréseau sur toutes les machines. Et il n'y a que 192 octets contigus, après on jardine dans la page 0 du moniteur.
Daniel
Messages : 17288
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Exomizer sur MO5 ???

Message par Daniel »

Déterrage de sujet, car je voudrais utiliser Exomizer pour des programmes MO5.

Question 1 :
Le compresseur de fichiers binaires Thomson de __sam__ exobin.c (https://pastebin.com/pLjHRC9H) semble limité aux programmes TO. Si on le lance avec un programme MO chargé en $5000 il retourne une erreur :
Can't write below page 0 ($5000)
Comment faire pour les programmes MO5 ?

Question 2 :
La version actuelle d'Exomizer est 3.1.0 (https://bitbucket.org/magli143/exomizer/wiki/Home). Est-ce utile ou pas de mettre à jour les outils Thomson pour bénéficier des progrès accomplis depuis la version 2 ?
Daniel
L'obstacle augmente mon ardeur.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: Exomizer sur MO5 ???

Message par __sam__ »

Daniel a écrit : 10 avr. 2021 18:25 Question 1 :
Comment faire pour les programmes MO5 ?
Il faut modifier ce test ligne 403:

Code : Tout sélectionner

 if(adr<0x6100) {
                    fprintf(stderr, "Can't write below page 0 ($%04X)\n", adr); 
                    break;
                }
mais aussi le test ligne 410 aussi probablement

Code : Tout sélectionner

 if(adr>=0xE000) {
                        fprintf(stderr, "Can't write in ROM space ($%04X)\n", adr); 
                        break;
                    }
(ca charge le BIN dans une zone mémoire reflétant le mapping mémoire TO en effet)
Question 2 :
La version actuelle d'Exomizer est 3.1.0 (https://bitbucket.org/magli143/exomizer/wiki/Home). Est-ce utile ou pas de mettre à jour les outils Thomson pour bénéficier des progrès accomplis depuis la version 2 ?
Joker :!: :lol:
La version mc6809 date de 2011 (2.0.2) et depuis il y a eu tous ces changements, dont une révision majeure en 2018:

Code : Tout sélectionner

2020-12-22
Release of 3.1.0 source code and Win32 binaries.
+ Fixed bug in the sfxdecr.s affecting c128 reported by Fredrik Ramsberg.
+ Implemented split encoding support  (-E) in the 6502 decruncher.
+ Updated raw decrunchers for Zilog Z80 contributed by Antonio Villena.
+ Added raw decrunchers for Intel 8080 contributed by Ivan Gorodetsky.
+ Added raw decrunchers for ARM 32bit thumb2 contributed by ALeX Kazik.
+ Implement optional forward decrunching properly in exodecrunch.s and as a
  consequence of this also remove krilldecr.s
+ Implement sequence read pointer blacklist to be able to avoid reading from
  specified memory areas like hardware registers (Experimental feature),
  Requested by Oziphantom.
+ update dasm and add acme exodecrunch sources
+ Improve compression by previous offset reuse, -P-32 to disable
+ Extended -e and -E to be able to reuse/calculate shared header/table info
  for multiple crunched files. (Experimental feature, no direct support in
  exodecrunch.s yet), Requested by Lazycow

2019-01-05
Release of 3.0.2 source code and Win32 binaries.
+ Add documentation about level, mem and raw outfile structure.
+ Fix raw -d -r combination to reverse the inbuffer before decrunch.
+ Fix -P0 literal sequences bug in exodec.c, Bug reported by Nino Porcino.
+ improved cruncher tuning for slightly improved compression on average.
+ Added sfx support for a new target, BBC Micro B (-t 0xbbcb).
+ Added -P+16 awareness to exodecrunch.s
+ Fix bucket optimization to be -T+4 aware in search.c, Bug reported by
  Ciccioriccio.
+ Fix absolute offset overflow bug in sfxdecr.s. Bug reported by Comos.

2018-08-10
Release of 3.0.1 source code and Win32 binaries.
+ Add missing clc to the new 6502 decrunchers. Bug reported by Soci.

2018-05-16
Release of 3.0.0 source code and Win32 binaries.
+ Up to almost 50% faster 6502 decruncher (sfx and stand-alone). However the
  bitstream format has changed in an incompatible way. See exo30info.txt for
  more info.

2018-03-08
Release of 2.0.11 source code and Win32 binaries.
+ No change from preview 3
2018-03-06
Release of 2.0.11 preview 3
+ Improved desfx c64 IO banking handling and automatic decrunched area
  detection.
+ sfx: Detected in-file type exported making target auto detection possible for
  some sfx bin and sfx <addr> (not sfx basic or sfx sys).
+ sfx: Applesingle file write now writes the header descriptors in in ascending
  order, suggested by Oliver Schmidt.

2018-02-20
Release of 2.0.11 preview 2
+ Fix compression improvement loop crashing bug exposed by the thread safety
  changes for library compilation, reported by Lasse Öörni.
+ Support the AppleSingle format instead of the 4 byte cc65 header, suggested
  by Oliver Schmidt.

2018-02-11
Release of 2.0.11 preview 1
+ Add i_raw assembler directive for sfx to generate header less output.
+ Make sfx 0xa2 fall back to 4 byte Apple II cc65 headers for in-files instead
  of prg-headers.
+ Add sfx bin directive as a shortcut for creating sfx files with as little
  impact on memory outside of the decrunched area as possible. Perfect for
  crunching Apple II binary files.

2017-12-25
Release of 2.0.10 source code and Win32 binaries.
+ Fix broken things in rawdecrs folder since 2.0.9
+ Add PET 4032 as sfx target from the nanoflite github fork.

2017-12-16
Release of 2.0.10 preview 3
+ Fix core dump when using max_passes=1 caused by static var removal.
+ Change zp-usage of the sfx-decr for plus4/c16 to avoid overwriting current
  device number address.

2017-12-09
Release of 2.0.10 preview 2
+ Add used encoding to the crunch_info struct returned by core crunch func.
+ Rework core compression core to not use local static vars to simplify use
  when compiled into a library.
+ rework -C into a generic favor speed flag and make it disable the crunch
  result changes too.
+ Improve crunch result slightly by also consider same length sequences at
  larger offsets too (but by doing this also slowing it down).

20170708
Release of 2.0.10 preview 1
+ Add a brief output mode enabled with -B, suggested by both Daniel Hotorp and
  Bacchus independently.
+ Display progress indication only on ttys and not when output is redirected,
  inspired by input from  Daniel Hotorp.
+ Make it possible to add offset and length to plain and prg file loading.
+ Improve sfx memory layout dump, suggested by Steffen Görzig.
+ sfx -Di_decr_table=2 should disable i_irq_during, reported by Steffen Görzig.
+ Updated z80 decrunchers, now with License information.
+ More portable by not using negative exit codes.
+ Add new keyword systrim to the sfx command. It behaves like the sys keyword
  but will also remove the sysline from the loaded infile.
+ Exit with an error if the parsing of the sfxdecr.s fails. This might happen
  with user provided assembly given by the options -x -X -s -f, reported by
  Stefan A. Haubenthal.
+ Change -mtune flag to make exomizer build on more platforms "out of the box".

2015-09-21
Release of 2.0.9 source code, Win32 and DOS binaries.
+ Fix gcc-compiler warnings.
+ sfx decr src comments echoed to stdout, reported by iAN CooG, fix by soci.
+ NULL pointer dereference crash, reported by Flavio, fix by soci.

2015-09-20
Release of 2.0.8 source code, Win32 and DOS binaries.
+ Fix bug reported and analyzed by Adrien Destugues. The ECHO token in asm.y
  collides with the flex ECHO macro. The cause is that Bison 2.3a and newer
  stopped to generate defines for the declared tokens. To resolve this the ECHO
  token has been renamed to ECHO1.
+ Add -E flag to not write the encoding to the outfile.
+ Remove max nr of chunks limit from the chunkpool allocator.
+ Enforce match max_len everwhere, bug reported by Zik / Futurs.

2013-04-14
Release of 2.0.7 source code, Win32 and DOS binaries.
+ Bugfixed commodore sfx targets to automatically disable irq when decrunching
  over system areas. This together with moving the table to zero-page,
  -Di_table_addr=0x2, allows decrunching $0200-<end of mem> without corruption
  for all commodore targets except for the vic20-configs without a 3kB memory
  expansion since they have a memory hole at $0400-$1000.
+ Bugfixed z80 decrunchers from Metalbrain.
+ Bugfixed sfx c16/plus4 target where the default irq could corrupt memory
  while decrunching data that covers $07f6-$0800, reported by Luca/FIRE.
+ Bugfixed sfx c16/plus4 target where the default decrunch effect could corrupt
  memory while decrunching data that covers $0be7, reported by Luca/FIRE.
+ Added feature to sfx-mode that complains if the data it too big to fit in the
  available memory of the selected target, suggested by Luca/FIRE.
+ Added c16 target, -t 4, like -t4 but with smaller memory, suggested by
  Luca/FIRE.

2013-01-27
Release of 2.0.6 source code, Win32 and DOS binaries.
+ New improvements to the z80 decrunchers, again smaller and faster.

2013-01-12
Release of 2.0.5 source code, Win32 and DOS binaries.
+ Add -C and -M <length> flags that trades crunch result for speed. It is now
  possible to really speed up crunching, even for "worst case"-type files.
+ Now skips the DAG traversing of the final pass if the encoding hasn't changed
  since the previous pass.

2012-08-16
Release of 2.0.4 source code, Win32 and DOS binaries.
+ Bug in z80 decrunchers fixed by Metalbrain. Thanks goes to Hervé Monchatre
  and Tim Riemann (Octoate) for reporting.
+ Implement sfx basic for the Apple II target.
+ Improve documentation slightly for the sfx and level commands.

2012-03-25
Release of 2.0.3 source code, Win32 and DOS binaries.
+ z80 decrunchers improved by Antonio Villena, now smaller and faster.

2011-08-19
Release of 2.0.2 source code, Win32 and DOS binaries.
+ Added 6809-decruncher contributed by Edouard Forler.
+ Fix language errors in the documentation. Thanks to Csabo/LOD.
+ Remove bogus printout about the default decrunch effect when using a custom
  decrunch effect. Bug reported by Csabo/LOD.
+ Fix bug that prevented the correct error message from showing when trying to
  combine a basic start and a non rom config for the sfx command.  Bug reported
  by iAN CooG.
Ce passage en 3.0.0 apporte 50% de vitesse en plsu sur 6502, mais change totalement le format du bitstream :( Je crains qu'il ne faille tout revoir sur 6809.

En parlant de bitstream, en fait je me dis que si ca se trouve cela accélérerait le chargement depuis SDDrive où la lecture bit à bit est super aisée. (je pense à la restoration d'état d'émulation sur machine réelle avec les avancées du nouveau format d'exomizer supportant des bouts de mémoire non contigus.)

sam .oO(Rêve)
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Avatar de l’utilisateur
6502man
Messages : 12242
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Exomizer sur MO5 ???

Message par 6502man »

@Daniel: Pour la compression ca fonctionne directement avec la version 2 sous Win10.
c'est ce que j'ai utilisé pour les programme de la Multirom :)
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
Avatar de l’utilisateur
hlide
Messages : 3456
Inscription : 29 nov. 2017 10:23

Re: Exomizer sur MO5 ???

Message par hlide »

La vitesse est-elle si importante (pour le décodage bien sûr) ? je privilégierais la solution qui offre la meilleure compression et sur place si possible. Si la dernière version d'Exomizer ne gagne qu'en vitesse de décompression et non en réduction, ça réduit l'intérêt de changer de version. Dernièrement, je suis passé du LZ7 au LZ0 qui change effectivement le bitstream produit mais maintient malgré tout le décodeur sur place dans la même taille d'octet que le précédent. Ce changement a été motivé sur le fait qu'il devait mieux compresser. Dans les faits, la majorité des programmes qui faisaient plutôt plus de la moitié en taille une fois compressés en LZ7 font plutôt moins de la moitié en taille une fois compressés en LZ0.
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: Exomizer sur MO5 ???

Message par __sam__ »

La compression est aussi meilleure d'après le changelog posté plus haut.

Code : Tout sélectionner

+ Improve compression by previous offset reuse,
../..
+ improved cruncher tuning for slightly improved compression on average.
../..
+ Improve crunch result slightly by also consider same length sequences 
at larger offsets too (but by doing this also slowing it down).
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17288
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: Exomizer sur MO5 ???

Message par Daniel »

Si quelqu'un a le courage d'écrire le décompacteur pour la version 3...
De mon côté je compacte avec le programme de __sam__ après l'avoir recompilé pour l'adapter aux fichiers MO.
Je décompacte avec la routine de Fool-DupleX améliorée par PULS.

Pour l'instant la version 2 d'Exomizer me suffit, avec un gain de de 50,3% sur la taille du programme que je voulais compresser.
Passer à 51% ou 52% n'apportera pas grand chose, sauf dans les cas extrêmes de compétitions avec limite imposée sur la taille du programme.
Daniel
L'obstacle augmente mon ardeur.
Avatar de l’utilisateur
6502man
Messages : 12242
Inscription : 12 avr. 2007 22:46
Localisation : VAR
Contact :

Re: Exomizer sur MO5 ???

Message par 6502man »

Si je comprend bien tu veux compresser directement sur MO5 plutôt que de passer par Windows ?
Phil.

www.6502man.com

To bit or not to bit.
1 or 0.
Fool-DupleX
Messages : 2271
Inscription : 06 avr. 2009 12:07

Re: Exomizer sur MO5 ???

Message par Fool-DupleX »

Si quelqu'un a le courage d'écrire le décompacteur pour la version 3...
C'est moi qui a écrit le décompresseur pour 6809, avec des suggestions et contributions diverses, mais notamment de Sam.

Je vais regarder ce que la version 3 apporte, mais franchement, je doute de l'utilité de la supporter. J'ai optimisé l'algorithme de décompression de la version 2 de manière quasi-ultime. Il était à l'époque très nettement supérieur en performance à ce que proposait l'auteur d'Exomizer sur les autres plateformes, tant en taille qu'en vitesse. L'objectif était d'avoir, peut-être pour la première fois, un vrai bon algorithme de compression disponible sur Thomson, tout simplement parce que j'en avais besoin :-) Il est compact, il est efficace, il n'a pas de bug.

Peut-être que la version 3 apporte un gain en compression, mais là encore, je doute d'une réelle différence. La théorie de l'information n'a pas beaucoup changé depuis Hamming et Exomizer 2 était déjà pas mal de ce point de vue.

A noter aussi que le décompresseur pour 6809 ne supporte qu'un seul format, alors qu'Exomizer 2 en proposait déjà plusieurs. Ajouter un nouveau format pour ajouter un nouveau format, c'est contraire à ma philosophie d'origine (j'avais choisi celui des formats E2 proposés qui me semblait le plus avantageux en performance sur 6809, en l'occurence la compression en sens inverse, dite "backwards"). De plus, le format semble avoir été modifié pour améliorer la performance sur 6502. Ca ne veut pas dire que ce sera la même chose sur 6809.

Edit: je vois que dans la doc, il y a des mesures de performance en nb. cycles par octet et nb. octets par mille cycles, est-ce qu'il y aurait moyen de profiler ça, par exemple avec dcmoto ?
__sam__
Messages : 7909
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: Exomizer sur MO5 ???

Message par __sam__ »

Fool-DupleX a écrit : 12 avr. 2021 10:19 Edit: je vois que dans la doc, il y a des mesures de performance en nb. cycles par octet et nb. octets par mille cycles, est-ce qu'il y aurait moyen de profiler ça, par exemple avec dcmoto ?
Oui tu mets un point d'arrêt au début de la routine de décompression, un autre à la sortie, et dans la partie "cycle" tu as précisément le nb de cycles passés entre les deux points d'arrêts.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Répondre