La Place des Développeurs Problème ASM - DOS vs ROM
Bonsoir
j'ai un problème que je ne sais pas résoudre...
Voici une routine en assembleur qui permet de faire une rotation de 90 degrés à droite ou à gauche d'un Pattern ou d'un Sprite de 8x8
Cette routine fait partie de Fusion-C 1.3.
Comme indiqué, on rentre dans DE l'adresse RAM où se trouve le Pattern de 8x8 d'origine, dans HL, l'adresse d'un buffer pour recevoir le résultat de la rotation. Et A permet d'indiquer si la rotation de 90 degrés se fait vers la droite, dans ce cas A reçoit 0x17 et si vers la gauche il reçoit 0x1F.
Mon problème est le suivant.
La routine fonctionne très bien lorsque je compile mon programme de test pour MSX-DOS.
Par contre, lorsque je compile le programme pour réaliser une ROM, la rotation se fait uniquement vers la gauche. Même si j'indique un autre paramètre. Même si je mets en dur dans le code, la bonne valeur dans le registre A.
Alors je m'arrache les cheveux (J'en ai bientôt plus), pour essayer de comprendre pourquoi, ce code fonctionne sous dos et pas pour une ROM.
Quelque pour m'aider à comprendre ? et à garder mes quelques cheveux survivants ?
j'ai un problème que je ne sais pas résoudre...
Voici une routine en assembleur qui permet de faire une rotation de 90 degrés à droite ou à gauche d'un Pattern ou d'un Sprite de 8x8
Cette routine fait partie de Fusion-C 1.3.
Code ASM :
;-------------------------------------------- ;Rotate 8x8 Pattern ;input: ;DE = 8x8 Pattern address ;HL = 8 bytes buffer ;A = 0x17 equals Clockwise (R) ; 0x1F equals Counter Clockwise (L) ; ;Output: ; Rotates a Pattern 90° left or right into a buffer ; Push ix ld ix,#0 add ix,sp ld e,4(ix) ld d,5(ix) ld l,6(ix) ld h,7(ix) ld a,8(ix) pop ix and #1 ld a,#0x17 jr z,rotate ; If direction is right (=0) ld a,#0x17 rotate: ld (rotloop),a xor #0x09 ld (rotloop+#2),a ld c,#8 rotbigloop: ld a,(de) inc de push hl ld b,#8 rotloop: rra rl (hl) inc hl djnz rotloop pop hl dec c jr nz,rotbigloop ret
Comme indiqué, on rentre dans DE l'adresse RAM où se trouve le Pattern de 8x8 d'origine, dans HL, l'adresse d'un buffer pour recevoir le résultat de la rotation. Et A permet d'indiquer si la rotation de 90 degrés se fait vers la droite, dans ce cas A reçoit 0x17 et si vers la gauche il reçoit 0x1F.
Mon problème est le suivant.
La routine fonctionne très bien lorsque je compile mon programme de test pour MSX-DOS.
Par contre, lorsque je compile le programme pour réaliser une ROM, la rotation se fait uniquement vers la gauche. Même si j'indique un autre paramètre. Même si je mets en dur dans le code, la bonne valeur dans le registre A.
Alors je m'arrache les cheveux (J'en ai bientôt plus), pour essayer de comprendre pourquoi, ce code fonctionne sous dos et pas pour une ROM.
Quelque pour m'aider à comprendre ? et à garder mes quelques cheveux survivants ?
"ld (rotloop),a" écrit à l'intérieur de ton programme. Je sais pas comment ça peut fonctionner sous DOS, mais en tout cas, en version ROM ton programme est dans... la ROM, donc impossible d'y écrire. Il faudrait stocker ces infos en RAM si y en a vraiment besoin (mais à mon avis, il doit y avoir largement moyen de n'utiliser que les registres ; tu peux utiliser les registres alternatifs af', bc', etc.).
EDIT : OK, je crois avoir compris comment fonctionne le programme. En fait il modifie son propre code en cours d'exécution. C'est donc juste impossible de faire ça depuis une ROM. Ce que tu peux faire c'est copier ce code en RAM et l'y exécuter.
EDIT : OK, je crois avoir compris comment fonctionne le programme. En fait il modifie son propre code en cours d'exécution. C'est donc juste impossible de faire ça depuis une ROM. Ce que tu peux faire c'est copier ce code en RAM et l'y exécuter.
On est toujours ignorant avant de savoir.
Alors là... Je vois que tout le monde se fou totalement de mes cheveux ! Merci bien quoi ! Bonjour la solidarité !
Heureusement dès qu'il s'agit de programmation, la solidarité est là
J'ai pigé !! Oui effectivement ca veut modifier dans la Rom et c'est pas possible ! ok ok !
J'ai donc scindé le prog en 2 parties distinctes :
Déjà que j'ai eu du mal à me faire au DOS, il faut que je pense encore autrement pour que ma librairie fonctionne pour les ROM.
C'est dure la vie !
Merci !
Edité par
ericb59
Le 05/12/2020 à 10h07
Heureusement dès qu'il s'agit de programmation, la solidarité est là
J'ai pigé !! Oui effectivement ca veut modifier dans la Rom et c'est pas possible ! ok ok !
J'ai donc scindé le prog en 2 parties distinctes :
Code ASM :
;-------------------------------------------- ;Rotate 8x8 Pattern ;input: ;DE = 8x8 Pattern address ;HL = 8 bytes buffer ;A = 0 Clockwise (R) ; 1 equals Counter Clockwise (L) ; ;Output: ; Rotates a Pattern 90° left or right into a buffer ; Push ix ld ix,#0 add ix,sp ld e,4(ix) ld d,5(ix) ld l,6(ix) ld h,7(ix) ld a,8(ix) pop ix ld c,#8 and #1 jr z,rotbigloopR ; If direction is right (=0) ; Left Rotation rotbigloopL: ld a,(de) inc de push hl ld b,#8 rotloopL: rra rl (hl) inc hl djnz rotloopL pop hl dec c jr nz,rotbigloopL ret ; Right Rotation rotbigloopR: ld a,(de) inc de push hl ld b,#8 rotloopR: rla rr (hl) inc hl djnz rotloopR pop hl dec c jr nz,rotbigloopR ret
Déjà que j'ai eu du mal à me faire au DOS, il faut que je pense encore autrement pour que ma librairie fonctionne pour les ROM.
C'est dure la vie !
Merci !
Edité par
ericb59
Le 05/12/2020 à 10h07
Franck :
Tu vas pouvoir garder tes cheveux grâce au talent d'Aoineko
Rendons à Sector28 ce qui appartient à Sector28... c'est lui qui a mis le doigt sur le problème en premier.
On est toujours ignorant avant de savoir.
Sector28 :
Éric , pourquoi ne pas créer 2 libs, une pour le msxdos, l'autre pour les roms ou autre.
Oui c’est ce que je suis en train de réaliser.
Je reprends tout le code de ma lib Msx-dos pour l’adapter à la ROM, dans une « side library ».
Le script de compilation s’adaptera en fonction des directives indiquées par le codeur pour compiler avec tel ou tel lib.
Mon objectif est ici, de pouvoir compiler du code pour Dos ou ROM, avec quasi aucune modification du code source.
(Sous entendu de ne pas utiliser des fonctions dédiées msx-dos, bien sur)
Si ça peux t'aider, voici quelques liens sur ma lib.
C'est encore très "work-in-progress" mais le système de configuration automatique pour générer un programme ROM, DOS ou (Basic) BIN est fonctionnel.
Pour un projet, il y a deux fichiers de config :
Les scripts de build en eux-mêmes sont dans : https://github.com/aoineko-fr/cmsx/tree/master/cmsx/script
C'est encore très "work-in-progress" mais le système de configuration automatique pour générer un programme ROM, DOS ou (Basic) BIN est fonctionnel.
Pour un projet, il y a deux fichiers de config :
- Un fichier de configuration du build où on peut choisir notamment le type de program, les étapes de build, etc. Par ex. : https://github.com/aoineko-fr/cmsx/blob/master/proj/gos/build.bat ;
- Un fichier de configuration du make (compil/link) ou on peut spécifier ce qu'on veut inclure ou non dans le program (pour gagner de la place, par ex., on peut retirer le support des Screen modes qu'on ne compte pas utiliser). Par ex. : https://github.com/aoineko-fr/cmsx/blob/master/proj/gos/cmsx_config.h
Les scripts de build en eux-mêmes sont dans : https://github.com/aoineko-fr/cmsx/tree/master/cmsx/script
On est toujours ignorant avant de savoir.
Merci aoineko, je regarderai ça à tête reposée.
Masi que veux tu dire par "pour gagner de la place, par ex., on peut retirer le support des Screen modes qu'on ne compte pas utiliser"
qu'est-ce que tu enlèves ou ajoute selon les cas ?
J'essaie pour ma part de faire en sorte de ne pas avoir à aller éditer des fichiers de configurations. Je préfère l'approche d'ajouter des "directives" dans le code source à compiler. J'y perd sans doute en customisation, mais j'y gagne en terme de facilité d'usage. Je reste sur une approche "user-friendly", à la Apple, en limitant autant que possible les "frictions". En tout cas... c'est mon objectif. Tu as une autre approche, plus "pro" du codage, qui me fait penser plus à la façon de travailler sur linux, si j'ose une analogie.
Edité par
ericb59
Le 07/12/2020 à 10h34
Masi que veux tu dire par "pour gagner de la place, par ex., on peut retirer le support des Screen modes qu'on ne compte pas utiliser"
qu'est-ce que tu enlèves ou ajoute selon les cas ?
J'essaie pour ma part de faire en sorte de ne pas avoir à aller éditer des fichiers de configurations. Je préfère l'approche d'ajouter des "directives" dans le code source à compiler. J'y perd sans doute en customisation, mais j'y gagne en terme de facilité d'usage. Je reste sur une approche "user-friendly", à la Apple, en limitant autant que possible les "frictions". En tout cas... c'est mon objectif. Tu as une autre approche, plus "pro" du codage, qui me fait penser plus à la façon de travailler sur linux, si j'ose une analogie.
Edité par
ericb59
Le 07/12/2020 à 10h34
En fait, je prends juste les décisions de design qui servent mon objectif : pouvoir faire des jeux compacts et les plus rapides possible.
Et oui, même si ça rends la lib pas très user-friendly (pour ça les gens ont déjà Fusion-C
).
Pour ce qui est du support des Screen modes, au lieu d'avoir quasiment un fichier par fonction comme dans Fusion-C, j'ai choisi de regrouper mes fonctions dans des modules (par ex. le module VDP) ; je trouve ça plus "pratique" mais pour un jeu donné, il y a qu'une partie des fonctions qui vont être vraiment utile alors qu'à la base, le Linker va toutes les ajouter dans le binaire final.
Du coup, j'ai deux niveaux de config :
- Dans la config du Build, je choisie quels modules vont être ajouté ;
- Dans la config du Compilo/Linker, je configure ces modules pour ne garder que ce dont à besoin mon projet.
Ah oui, il faut préciser que la grosse différence avec Fusion-C, c'est que ma lib n'existe pas sous forme statique. Elle est linké "à la volé" au moment de build un projet.
C'est ça qui permet à mon programme final de n'embarquer que ce dont il a besoin.
Et oui, même si ça rends la lib pas très user-friendly (pour ça les gens ont déjà Fusion-C
).Pour ce qui est du support des Screen modes, au lieu d'avoir quasiment un fichier par fonction comme dans Fusion-C, j'ai choisi de regrouper mes fonctions dans des modules (par ex. le module VDP) ; je trouve ça plus "pratique" mais pour un jeu donné, il y a qu'une partie des fonctions qui vont être vraiment utile alors qu'à la base, le Linker va toutes les ajouter dans le binaire final.
Du coup, j'ai deux niveaux de config :
- Dans la config du Build, je choisie quels modules vont être ajouté ;
- Dans la config du Compilo/Linker, je configure ces modules pour ne garder que ce dont à besoin mon projet.
Ah oui, il faut préciser que la grosse différence avec Fusion-C, c'est que ma lib n'existe pas sous forme statique. Elle est linké "à la volé" au moment de build un projet.
C'est ça qui permet à mon programme final de n'embarquer que ce dont il a besoin.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie