Exomizer sur MO5 ???
Modérateurs : Papy.G, fneck, Carl
Exomizer sur MO5 ???
J'ai voulu essayer d'assembler le code source du décompresseur EXOMIZER pour MO5 de Fool-Duplex trouvé LA
mais l'assembleur me retourne une erreur sur cette ligne :
leax <tab1,pcr
relative branch out of range.
Fool-duplex, Sam, Daniel,... comment dois je proceder ?
J'ai essayé A09, AS09 !!!!
mais l'assembleur me retourne une erreur sur cette ligne :
leax <tab1,pcr
relative branch out of range.
Fool-duplex, Sam, Daniel,... comment dois je proceder ?
J'ai essayé A09, AS09 !!!!
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Exomizer sur MO5 ???
Essaye c6809 (compatible assembler v3 sur thomson)
L'erreur indique que tab1 est trop loin. Normalement il doit être à au plus 127 octets du pointeur programme à ce moment là, ce qui est le cas dans le programme source. La syntaxe "leax <biba,pcr" est supposée indiquer à l'assembleur qu'on veut utiliser le mode 8 bits relatifs, qui est à la fois plus compact (c'était le rôle de l'exercice) et plus rapide.
Est-ce que tu as modifié le code pour pousser biba plus loin ? si non c'est probablement que AS09 interprète le "<biba" comme une valeur 16 bits littérale ($xxxx) et pas comme une étiquette (biba). La valeur 16 bit littérale ne tient pas dans les 8 bits du mode d'où le message d'erreur. C'est moralement un bug dans l'assembleur, car les assembleurs que j'utilise ont toujours considéré "<biba,pcr" comme le mode d'addessage relatif 8bits pointant sur "biba".
Ce que tu peux faire dans tous les cas, c'est utiliser la syntaxe "leax biba,pcr" qui suivant que les assembleurs optimisent ou pas utilisera le mode 8 bits relatifs ou 16 bits relatifs. En 16 bits c'est plus gros et plus lent, mais au moins il n'y a pas de problèmes d'offset trop gros. Cependant, si le compilo est intelligent il va automatiquement utiliser l'offset 8 bits à la place.
L'erreur indique que tab1 est trop loin. Normalement il doit être à au plus 127 octets du pointeur programme à ce moment là, ce qui est le cas dans le programme source. La syntaxe "leax <biba,pcr" est supposée indiquer à l'assembleur qu'on veut utiliser le mode 8 bits relatifs, qui est à la fois plus compact (c'était le rôle de l'exercice) et plus rapide.
Est-ce que tu as modifié le code pour pousser biba plus loin ? si non c'est probablement que AS09 interprète le "<biba" comme une valeur 16 bits littérale ($xxxx) et pas comme une étiquette (biba). La valeur 16 bit littérale ne tient pas dans les 8 bits du mode d'où le message d'erreur. C'est moralement un bug dans l'assembleur, car les assembleurs que j'utilise ont toujours considéré "<biba,pcr" comme le mode d'addessage relatif 8bits pointant sur "biba".
Ce que tu peux faire dans tous les cas, c'est utiliser la syntaxe "leax biba,pcr" qui suivant que les assembleurs optimisent ou pas utilisera le mode 8 bits relatifs ou 16 bits relatifs. En 16 bits c'est plus gros et plus lent, mais au moins il n'y a pas de problèmes d'offset trop gros. Cependant, si le compilo est intelligent il va automatiquement utiliser l'offset 8 bits à la place.
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
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
-
- Messages : 2336
- Inscription : 06 avr. 2009 12:07
Re: Exomizer sur MO5 ???
Merci sam pour cette réponse très complète. A toutes fins utiles, je précise que ce code est très optimisé et la moindre modification (comme déplacer biba) peut casser le truc. Par contre, il est relogeable.
Il suppose que les données sont compressées en mode backward.
Il suppose que les données sont compressées en mode backward.
Re: Exomizer sur MO5 ???
Merci pour les explications Sam
Concernant l'erreur je sait bien ce que sais un grand classique des assembleurs les déplacements relatifs
Le problème était surtout de trouver le bon assembleur pour assembler ce source
J'ai testé avec "leax biba,pcr" l'assembleur ne retourne pas l'erreur, et ça fonctionne, Merci.
Je viens de faire des essais mais cela est dans la pratique pas utilisable avec le DOS, car trop peu de RAM disponible et surtout il y a risque de chevauchement entre les données compressées et décompressées, sauf à avoir un petit fichier EXO et dans ce cas utiliser le RAM vidéo
Concernant l'erreur je sait bien ce que sais un grand classique des assembleurs les déplacements relatifs
Le problème était surtout de trouver le bon assembleur pour assembler ce source
J'ai testé avec "leax biba,pcr" l'assembleur ne retourne pas l'erreur, et ça fonctionne, Merci.
Je viens de faire des essais mais cela est dans la pratique pas utilisable avec le DOS, car trop peu de RAM disponible et surtout il y a risque de chevauchement entre les données compressées et décompressées, sauf à avoir un petit fichier EXO et dans ce cas utiliser le RAM vidéo
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Exomizer sur MO5 ???
de mon coté j'ai repris le compresseur de binaires... et étudié le chauvauchement.. il y aura moyen de faire un truc bien. La mise au point est lente cependant.
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
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
- Papy.G
- Modérateur
- Messages : 3051
- Inscription : 10 juin 2014 13:40
- Localisation : Haute-Garonne/Gers
Re: Exomizer sur MO5 ???
Pour le chevauchement, n'est-il pas possible de loger les données compressées en toute fin de l'espace données, et celles décompressées en tout début (à l'inverse, si le mode backward suppose que le fichier est compressé en commençant par la fin)? Ainsi, il ne devrait pas y avoir besoin de beaucoup plus d'espace que celui nécessaire au fichier décompressé.
Pour le code en mémoire vidéo, utiliser un mode où la zone utilisée n'est pas affichée (un mode utilisant une moins grande place vidéo, un masquage de la zone utilisée...), m'enfin, ce ne sont que des considérations esthétiques, si aucun programme ne vient interférer et effacer ledit code avant la fin de son utilisation.
Pour le code en mémoire vidéo, utiliser un mode où la zone utilisée n'est pas affichée (un mode utilisant une moins grande place vidéo, un masquage de la zone utilisée...), m'enfin, ce ne sont que des considérations esthétiques, si aucun programme ne vient interférer et effacer ledit code avant la fin de son utilisation.
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Demandez-en plus, ou faites-le vous-même.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Exomizer sur MO5 ???
Le chevauchement est prévu par exomizer. Pas d'inquiétude. Dans mes expériences il faut mettre les données compressées juste un peu avant la zone mémoire à remplir (avec la compression backward).
Le soucis c'est d'avoir un algo d'allocation mémoire qui respecte des contraintes (préservation du dos, du basic, etc).
J'ai loupé l'info, mais sur MO5 les structure dos vont jusqu'à $2300 ou au delà ? Pour être tranquile avec le chargement sur D7 il faut considérer que la RAM libre démarre à quelle adresse ?
Il y a aussi un truc qui m'inquiète: où se loge la pile du basic pendant le chargement sur MO5 ? Il ne faut pas écrire des données DISK à cette adresse...
Le soucis c'est d'avoir un algo d'allocation mémoire qui respecte des contraintes (préservation du dos, du basic, etc).
J'ai loupé l'info, mais sur MO5 les structure dos vont jusqu'à $2300 ou au delà ? Pour être tranquile avec le chargement sur D7 il faut considérer que la RAM libre démarre à quelle adresse ?
Il y a aussi un truc qui m'inquiète: où se loge la pile du basic pendant le chargement sur MO5 ? Il ne faut pas écrire des données DISK à cette adresse...
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
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: Exomizer sur MO5 ???
Sur MO5 le 3'5 Disk Basic 1.0 se charge jusqu'en $4A6F.
Les programmes Basic commencent en $4DE0.
Il est donc possible que la plage mémoire $4A70-$4DDF soit utilisée comme zone de travail par le DOS.
Pendant l'initialisation du MO5 la pile est initialisée dans la zone des variables système, en $2081-$20CC.
Ensuite, après l'initialisation du Basic, elle est en fin de ram ($9FFF).
Les programmes Basic commencent en $4DE0.
Il est donc possible que la plage mémoire $4A70-$4DDF soit utilisée comme zone de travail par le DOS.
Pendant l'initialisation du MO5 la pile est initialisée dans la zone des variables système, en $2081-$20CC.
Ensuite, après l'initialisation du Basic, elle est en fin de ram ($9FFF).
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Exomizer sur MO5 ???
Ah c'est marrant $9FFF, c'est comme sur TO7/70: la pile est placé vers la fin de la ram non commutable Du coup il peut y avoir des surprises qui on charge des blocs dans cette zone par le basic sans avoir fait un clear (réservation) auparavant.
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
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: Exomizer sur MO5 ???
Les jeux que j'ai converti pour l'instant occupe pour la plupart entre 22/28 Ko en RAM soit beaucoup plus que ce que laisse le DOS DU MO5 un peu moins de 20Ko, et donc cela va être difficile de décompresser en "backward" avec la config DOS, le décompresseur va ce mordre la queue
Par contre si on essai en "forward" ca peut être possible (à mon avis) .
Constatation :
$4E00-$9FFF : RAM dispo avec le DOS
$2200-$9FFF : RAM dispo sans le DOS (à confirmer)
$2800-$9FFF: RAM dispo pour les binaires sans le DOS (en mode Basic)
$2900 : début des plus gros binaires que j'ai vu pour l'instant.
Ce que j'imagine :
- LOAD".EXO" en $6FFF-$9FFF en calant sur $9FFF selon la taille du fichier compressé.
- DECOMPRESSION en RAM en commencant par l'adresse la plus basse ($2900)
Le seul soucis est que les derniers octets vont ils être décompressés avant d'être écrasés ?
Alternative créer un buffer en RAM vidéo
C'est une idée mais je suis sur que Sam, Daniel, Fool-duplex, ... ont des idées encore plus efficaces
Par contre si on essai en "forward" ca peut être possible (à mon avis) .
Constatation :
$4E00-$9FFF : RAM dispo avec le DOS
$2200-$9FFF : RAM dispo sans le DOS (à confirmer)
$2800-$9FFF: RAM dispo pour les binaires sans le DOS (en mode Basic)
$2900 : début des plus gros binaires que j'ai vu pour l'instant.
Ce que j'imagine :
- LOAD".EXO" en $6FFF-$9FFF en calant sur $9FFF selon la taille du fichier compressé.
- DECOMPRESSION en RAM en commencant par l'adresse la plus basse ($2900)
Le seul soucis est que les derniers octets vont ils être décompressés avant d'être écrasés ?
Alternative créer un buffer en RAM vidéo
C'est une idée mais je suis sur que Sam, Daniel, Fool-duplex, ... ont des idées encore plus efficaces
Dernière modification par 6502man le 07 déc. 2015 17:28, modifié 2 fois.
Re: Exomizer sur MO5 ???
Exomizer est une solution très satisfaisante intellectuellement. Dans la pratique elle va se heurter à pas mal d'obstacles, que vous avez à peu près tous identifiés. Dans les cas extrêmes le programme binaire écrase toute la ram de $2000 à $9FFF, et en plus la mémoire vidéo est occupée par l'écran de présentation, il est difficile de trouver assez d'octets libres pour le code du décompresseur.
La solution d'initialiser la ram à partir des secteurs physiques avec un loader placé en $1F40 est plus brutale, certes, mais infiniment plus facile, plus sûre et plus rapide. Le seul souci est de savoir où mettre la pile système. Le bon endroit est celui où le programme chargé la place, normalement c'est une zone qu'il ne détruira pas. Il suffit de prendre garde de ne pas l'écraser lors du chargement.
La solution d'initialiser la ram à partir des secteurs physiques avec un loader placé en $1F40 est plus brutale, certes, mais infiniment plus facile, plus sûre et plus rapide. Le seul souci est de savoir où mettre la pile système. Le bon endroit est celui où le programme chargé la place, normalement c'est une zone qu'il ne détruira pas. Il suffit de prendre garde de ne pas l'écraser lors du chargement.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Exomizer sur MO5 ???
Oui je suis d'accord avec Daniel. Le mieux est d'avoir un loader court qui se trouve dans la ram video (si possible hors zone visible), qui squatte la pile système ($20cc) et charge les secteurs directement en ram depuis le disk via les accès moniteur. la zone $1F40 me parait bien pour ca.
Si on tient à utiliser exomizer tout en préservant le DOS, il faut modifier le décompresseur pour qu'il aille charger sur disk les secteurs compressés qu'il rapatrie quand il en a besoin (et le place dans la zone du programme pas encore écrite). Le dernier secteurs, pour éviter de s'écraser en se décompressant, serait un secteur brut non compressé. L'occupation mémoire d'un tel systeme serait d'environ 300 octets seulement.
L'intérêt d'avoir des secteurs disks compressés avec exomizer c'est qu'on peut mettre un paquet de jeux sur une seule diskette. Prenons une compression d'un facteur 3. Un jeu fait disons 21ko, soit 7ko compressés. Sur une face de diskette, il y a 45 fois 7ko de libre. On pourrait faire tenir 45 gros bon jeux K7 sur une seule face de diskette!
Mais si on a qu'un jeu par diskette, alors il ne faut pas se casser la tête avec ca. Le loader direct est très bien.
Si on tient à utiliser exomizer tout en préservant le DOS, il faut modifier le décompresseur pour qu'il aille charger sur disk les secteurs compressés qu'il rapatrie quand il en a besoin (et le place dans la zone du programme pas encore écrite). Le dernier secteurs, pour éviter de s'écraser en se décompressant, serait un secteur brut non compressé. L'occupation mémoire d'un tel systeme serait d'environ 300 octets seulement.
L'intérêt d'avoir des secteurs disks compressés avec exomizer c'est qu'on peut mettre un paquet de jeux sur une seule diskette. Prenons une compression d'un facteur 3. Un jeu fait disons 21ko, soit 7ko compressés. Sur une face de diskette, il y a 45 fois 7ko de libre. On pourrait faire tenir 45 gros bon jeux K7 sur une seule face de diskette!
Mais si on a qu'un jeu par diskette, alors il ne faut pas se casser la tête avec ca. Le loader direct est très bien.
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
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: Exomizer sur MO5 ???
Oui le loader directe est ce qui est de plus simple et pratique
Sinon j'ai essayé d'utiliser des appels au moniteur pour afficher un texte par SWI #02, mais il ressort directe au basic en affichant que la première lettre
Après le "SWI" il ne revient jamais dans le routine du moins d'après le déboggeur de DCMOTO
Sinon j'ai essayé d'utiliser des appels au moniteur pour afficher un texte par SWI #02, mais il ressort directe au basic en affichant que la première lettre
Après le "SWI" il ne revient jamais dans le routine du moins d'après le déboggeur de DCMOTO
Code : Tout sélectionner
DEBUT
LDX #MESSAGE
AFFICHE
LDB 0,X
BEQ TOUCHE
SWI
FCB $02
INX
BRA AFFICHE
TOUCHE
SWI
FCB $0C
BEQ TOUCHE
JMP DEBUT
MESSAGE
FCB "BOUJOUR"
FCB 0
-
- Messages : 7964
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: Exomizer sur MO5 ???
c'est quoi ton "INX" ? C'est pas un opcode 6809. Ca ressemble plus à un code 6502
INX est l'opcoe $E8 sur 6502, mais sur 6809, c'est un EORB à accès différé qui va décaler la lecture du flot d'instruction en mangeeant un ou deux octets suivants et probablement faire revenir au basic tout de suite.
Ton code sur 6809 doit plutot ressembler à
INX est l'opcoe $E8 sur 6502, mais sur 6809, c'est un EORB à accès différé qui va décaler la lecture du flot d'instruction en mangeeant un ou deux octets suivants et probablement faire revenir au basic tout de suite.
Ton code sur 6809 doit plutot ressembler à
Code : Tout sélectionner
DEBUT
LDX #MESSAGE
AFFICHE
LDB ,X+
BEQ TOUCHE
; avec les compilo Thomson il y a souvent une macro CALL 2 qui fait pareil que le couple swi/fcb
SWI
FCB $02
BRA AFFICHE
...
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
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: Exomizer sur MO5 ???
Désolé je ne suis pas alaise avec le 6809
le INX est bien compris par mon assembleur et donne ce code assemblé $30 $01
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
Finalement j'ai trouvé dans les docs une routine système qui affiche un texte fini par $00 = JSR $CE2C
Maintenant mon problème est de placer cette routine ailleurs qu'en RAM vidéo
le INX est bien compris par mon assembleur et donne ce code assemblé $30 $01
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
Finalement j'ai trouvé dans les docs une routine système qui affiche un texte fini par $00 = JSR $CE2C
Maintenant mon problème est de placer cette routine ailleurs qu'en RAM vidéo