La Place des Développeurs Mes 1ers pas sur MSX ...
Reprise du message précédent
il manque un "return ..." dans tes sous-routinesToute matrice carrée sur un corps K, dont le polynôme caractéristique est scindé, est semblable à une matrice de Jordan. Cette réduction est unique à l'ordre des blocs près. De plus, toute matrice carrée nilpotente sur un corps K est semblable à une matrice de Jordan dont chaque bloc est associé à la valeur 0. Évidement, cette réduction est encore unique à l'ordre des blocs près...
tu peux aussi les déclarer void et utiliser un transtypage.
Toute matrice carrée sur un corps K, dont le polynôme caractéristique est scindé, est semblable à une matrice de Jordan. Cette réduction est unique à l'ordre des blocs près. De plus, toute matrice carrée nilpotente sur un corps K est semblable à une matrice de Jordan dont chaque bloc est associé à la valeur 0. Évidement, cette réduction est encore unique à l'ordre des blocs près...
Le warning 59 est un faux positif dans ton cas.
Quand tu utilises __z88dk_fastcall, tu as juste besoin de mettre ton paramètre de retour dans le registre L (ou HL si tu retourne une valeur 16-bits).
SDCC ajoute le ret final.
C'est uniquement dans le cas de la directive __naked que tu dois ajouter un ret manuellement.
Alors, pourquoi SDCC te renvoi un warning alors qu'il n'y a pas de problème ?
Simplement parce qu'il n'a aucun moyen de savoir si tu as bien gérer le retour ou pas.
A partir du moment ou tu as pas le code C "return uneValeur;" tu auras ce warning.
Personnellement, j'ai complétement désactiver ce warning dans ma lib avec le code :
C'est vraiment du détail, mais tu peux retirer la ligne :
Quand tu utilises __z88dk_fastcall, tu as juste besoin de mettre ton paramètre de retour dans le registre L (ou HL si tu retourne une valeur 16-bits).
SDCC ajoute le ret final.
C'est uniquement dans le cas de la directive __naked que tu dois ajouter un ret manuellement.
Alors, pourquoi SDCC te renvoi un warning alors qu'il n'y a pas de problème ?
Simplement parce qu'il n'a aucun moyen de savoir si tu as bien gérer le retour ou pas.
A partir du moment ou tu as pas le code C "return uneValeur;" tu auras ce warning.
Personnellement, j'ai complétement désactiver ce warning dans ma lib avec le code :
Code C :
#pragma disable_warning 59 ///< remove "function must return value" warningC'est vraiment du détail, mais tu peux retirer la ligne :
Code C :
unsigned char get_trigger(unsigned char choix)__z88dk_fastcall { choix; __asm ld a,l call GTTRIG ld h,#0x00 ; <<<< ne sert à rien vu que tu retournes une valeur 8-bits dans L ld l,a __endasm; }
On est toujours ignorant avant de savoir.
Merci Sector28 et Aoineko
C'est parfait et c good
A+
C'est parfait et c good
A+
hello les zamis
J'ai un petit souci de compilation et donc de compréhension
lorsque, pour un sprite, j'assigne une coordonnée y comme ca : ZeZone[16].y = 21*8 > Ca fonctionne
si j'assigne comme ça : ZeZone[16].y = 21*8-1 > j'ai "warning 158: overflow in implicit constant conversion" ??
si je fais comme ça : ZeZone[16].y = 167 > c'est ok
apparemment SDCC n'aime pas les calculs....
est-ce relatif à un bug tel que je peux le lire sur github ? (encore un #pragma sur 158 ?) ou c'est moi qui beuuuggggg
Merci pour vos éclaircissements les zamis
ps : je travaille avec SDCC 4.0.0
Bon courage pour la semaine à venir
Tchao
J'ai un petit souci de compilation et donc de compréhension
lorsque, pour un sprite, j'assigne une coordonnée y comme ca : ZeZone[16].y = 21*8 > Ca fonctionne
si j'assigne comme ça : ZeZone[16].y = 21*8-1 > j'ai "warning 158: overflow in implicit constant conversion" ??
si je fais comme ça : ZeZone[16].y = 167 > c'est ok
apparemment SDCC n'aime pas les calculs....
est-ce relatif à un bug tel que je peux le lire sur github ? (encore un #pragma sur 158 ?) ou c'est moi qui beuuuggggg
Merci pour vos éclaircissements les zamis
ps : je travaille avec SDCC 4.0.0
Bon courage pour la semaine à venir
Tchao
salut
tu es certain ( je pense) que ton Y est déclaré en Unsigned Char ?
montre un morceau de code.
parfois le problème peut venir de plus haut.
Le compilateur va de toute façon transformer ton opération en un nombre.
Quel intérêt de garder une opération qui ne sert à rien ? Edité par ericb59 Le 11/01/2021 à 07h54
tu es certain ( je pense) que ton Y est déclaré en Unsigned Char ?
montre un morceau de code.
parfois le problème peut venir de plus haut.
Le compilateur va de toute façon transformer ton opération en un nombre.
Quel intérêt de garder une opération qui ne sert à rien ? Edité par ericb59 Le 11/01/2021 à 07h54
Ricco59 :
est-ce relatif à un bug tel que je peux le lire sur github ? (encore un #pragma sur 158 ?) ou c'est moi qui beuuuggggg
Non, tu ne bug-es pas
C'est bien un problème de SDCC qui a tendance à interpréter comme des short tous les calculs littéraux.
Du coup, dès qu'il y a un signe moins en jeu, tu va avoir ce warning.
Par contre, je te déconseille de désactiver ce warning qui est parfois utiles.
Le plus simple dans ton cas, c'est de faire un cast explicite :
Code C :
ZeZone[16].y = (unsigned char)(21*8-1);
Rien à voir, mais mon expérience de prog multi-plateforme m'amène à toujours conseiller de redéfinir tes types de bases.
Personnellement j'utilise u8 pour les unsigned char et u16 pour les unsigned short, mais la version la plus rependue c'est uint8_t et uint16_t.
Ca permet :
- d'avoir une vue directe sur la taille de tes variables (ce qui est très important pour la programmation sur ordi 8-bits),
- d'être indépendant du compilateur et/ou de la plateforme (notamment pour les int qui n'ont pas forcement la même taille d'un compilo à l'autre).
On est toujours ignorant avant de savoir.
Autre chose sur les sprites MSX1 que j'ai découvert récemment.
Leur paramètre Y à un comportement différent en fonction de sa valeur :
- 0 à 191 : ligne où va apparaitre le sprite ;
- 208 : cache le sprite et tous les suivants (ça je savais) ;
- 224 à 255 : affiche le sprite au dessus de l'écran, comme si les valeurs de Y étaient négatives (ça je savais pas
). Les valeurs [224 : 255] sont mappés sur les valeurs [-32 : -1].
Ce dernier comportement permet de faire disparaitre un sprite progressivement en le déplaçant vers le haut au delà de la ligne 0.
Et du coup, j'ai aussi compris l'intérêt du flag EC (early clock) de la Table d'attribues, qui permet de décaler le sprite de 32 pixels vers la gauche par rapport à sa position X réél. Le but est également de pouvoir déplacer un sprite au delà de la bordure gauche de l'écran.
32 pixels correspondant à la plus grosse taille de sprite possible sur MSX : 16x16 pixels avec le scale x2.
PS : Sur les screen MSX2, la valeur pour cacher un sprite (et les suivants) est Y=216 (puisque l'écran peut avoir jusqu'à 212 pixels de haut).
Leur paramètre Y à un comportement différent en fonction de sa valeur :
- 0 à 191 : ligne où va apparaitre le sprite ;
- 208 : cache le sprite et tous les suivants (ça je savais) ;
- 224 à 255 : affiche le sprite au dessus de l'écran, comme si les valeurs de Y étaient négatives (ça je savais pas
). Les valeurs [224 : 255] sont mappés sur les valeurs [-32 : -1].Ce dernier comportement permet de faire disparaitre un sprite progressivement en le déplaçant vers le haut au delà de la ligne 0.
Et du coup, j'ai aussi compris l'intérêt du flag EC (early clock) de la Table d'attribues, qui permet de décaler le sprite de 32 pixels vers la gauche par rapport à sa position X réél. Le but est également de pouvoir déplacer un sprite au delà de la bordure gauche de l'écran.
32 pixels correspondant à la plus grosse taille de sprite possible sur MSX : 16x16 pixels avec le scale x2.
PS : Sur les screen MSX2, la valeur pour cacher un sprite (et les suivants) est Y=216 (puisque l'écran peut avoir jusqu'à 212 pixels de haut).
On est toujours ignorant avant de savoir.
Merci Guillaume
pour le côté gauche je savais. Il me semble qu'en plus il faut faire un ajustement sur X pour le sprite allant vers la gauche. Je n'ai pas encore testé car pas l'utilité... Pour le moment ... ???? Edité par Ricco59 Le 11/01/2021 à 17h11
pour le côté gauche je savais. Il me semble qu'en plus il faut faire un ajustement sur X pour le sprite allant vers la gauche. Je n'ai pas encore testé car pas l'utilité... Pour le moment ... ???? Edité par Ricco59 Le 11/01/2021 à 17h11
Oui, si tu veux un sprite qui se déplacer de façon smooth vers la gauche au-delà de la bordure il faut que X évolue comme ça :
Code TEXT :
- ... - X = 3 - X = 2 - X = 1 - X = 0 - X = 31 + EC - X = 30 + EC - X = 29 + EC - X = 28 + EC - ...
On est toujours ignorant avant de savoir.
aoineko :
(...)
- 208 : cache le sprite et tous les suivants (ça je savais)
(...)
PS : Sur les screen MSX2, la valeur pour cacher un sprite (et les suivants) est Y=216 (puisque l'écran peut avoir jusqu'à 212 pixels de haut).
- 208 : cache le sprite et tous les suivants (ça je savais)
(...)
PS : Sur les screen MSX2, la valeur pour cacher un sprite (et les suivants) est Y=216 (puisque l'écran peut avoir jusqu'à 212 pixels de haut).
Pour être complet :
- MSX1 : Y=209 efface le sprite courant, Y=208 efface le sprite courant et tous les suivants
- MSX2 : Y=217 efface le sprite courant, Y=216 efface le sprite courant et tous les suivants
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Je ne fais que reprendre ce qu'il y a dans le Technical Handbook :
"MSX2 TECHNICAL HANDBOOK" :
In screen modes 1 through 3, Y-coordinate was 209 for erasing the display of
the specified sprite and was 208 for erasing the displays of the specified
sprite and all sprites following it, but in screen modes 4 through 8, where
the limit of Y-coordinate has been increased to 212 dots, the values to be
specified are now 217 and 216, respectively.
the specified sprite and was 208 for erasing the displays of the specified
sprite and all sprites following it, but in screen modes 4 through 8, where
the limit of Y-coordinate has been increased to 212 dots, the values to be
specified are now 217 and 216, respectively.
MSX1: Daewoo DPC-200 / Yamaha CX5M
MSX2: Sony HB-F9P
MSXVR
Vidéo: V9990 (GFX-9)
Audio: MSX-Music (FM-PAC) / MSX-Audio (Audiowave) / OPL4 (Monster Sound FM Blaster) / OPNB (Neotron)
Salut les potos,
J'espère que vous allez tous bien
Bon j'ai un souci qui ne me permet plus d'avancer.
Depuis le debut de ce projet, je me suis fait les dents avec le crt0msx.s que j'ai récupéré chez BFG à cette adresse : https://oib.home.blog/2019/12/28/coder-en-c-sur-msx-les-bases/
Le souci c'est que pour mon intro/menu (tous les graphs sont inclus), j'en suis à 16588 octets (il manque la partie code du jeu, les sons et why not une zik+son player)
Dans le compile.bat, le code-loc est à 0x4020 et le data-loc à 0x8048.
Etant apprenti débutant en prog C sur MSX, si je fais 0x4020+16588, je grignote des variables stockées à partir de 0x8048 ce qui fait plantin le bouzin. Me trompe-je ?
J'ai donc mis mon data-loc à 0xc000 mais le problème reste le même :
- à partir d'un certain moment, le programme plante
- si par contre j'enlève quelques 100aines d'octets (gfx non encore utilisé), ça marche.
Je pense que le soucis vient de ce crt0msx.s
mon compile.bat
@echo off
set path=%path%;D:\_Msx_Dev_\_Progr_MSX\SDCC\bin
sdasz80 -o crt0.rel crt0msx.s
sdcc -mz80 -c --oldralloc video.c
sdcc -mz80 -c --oldralloc tools.c
sdcc -mz80 -c --oldralloc gfx.c
sdcc -mz80 --std-c99 --oldralloc --data-loc 0x8048 --code-loc 0x4020 --no-std-crt0 crt0.rel -main.ihx tools.rel video.rel gfx.rel main.c
objcopy --input-target=ihex --output-target=binary main.ihx tmp.rom
del result.rom > nul
rename tmp.rom result.rom
del *.sym > nul
del *.noi > nul
pause;
D:\_Msx_Dev_\_Progr_MSX\meisei\meisei.exe D:\_Msx_Dev_\wii\result.rom
mon crt0msx.s
;; Generic crt0.s for a Z80
.globl _main
.area _HEADER (ABS)
;; Reset vector
.org 0x4000
.db 0x41
.db 0x42
.dw init
.dw 0x0000
.dw 0x0000
.dw 0x0000
.dw 0x0000
.dw 0x0000
.dw 0x0000
init:
;; Stack at the top of memory.
ld sp,(0xfc4a)
;; Initialise global variables
call _main
;; Ordering of segments for the linker.
.area _CODE
.area _GSINIT
.area _GSFINAL
.area _DATA
.area _BSS
.area _CODE
;; Special RLE decoder used for initing global data
;;__initrleblock::
;; Pull the destination address out
;; ld c,l
;; ld b,h
;; Pop the return address
;; pop hl
;;1$:
;; Fetch the run
;; ld e,(hl)
;; inc hl
;; Negative means a run
;; bit 7,e
;; jp z,2$
;; Code for expanding a run
;; ld a,(hl)
;; inc hl
;;3$:
;; ld (bc),a
;; inc bc
;; inc e
;; jp nz,3$
;; jp 1$
;2$:
;; Zero means end of a block
;; xor a
;; or e
;; jp z,4$
;; Code for expanding a block
;;5$:
;; ld a,(hl)
;; inc hl
;; ld (bc),a
;; inc bc
;; dec e
;; jp nz,5$
;; jp 1$
;;4$:
;; Push the return address back onto the stack
;; push hl
;; ret
.area _GSINIT
gsinit::
.area _GSFINAL
ret
Je préférais de loin l'ASM car tout est contrôlable mais le C est génial pour sa vitesse de développement et sa portabilité.
Est-ce qu'il vous est possible de remplir 'mon' vide qui concerne la prog sur MSX ?
Merci encore et bon dimanche
Eric
J'espère que vous allez tous bien
Bon j'ai un souci qui ne me permet plus d'avancer.
Depuis le debut de ce projet, je me suis fait les dents avec le crt0msx.s que j'ai récupéré chez BFG à cette adresse : https://oib.home.blog/2019/12/28/coder-en-c-sur-msx-les-bases/
Le souci c'est que pour mon intro/menu (tous les graphs sont inclus), j'en suis à 16588 octets (il manque la partie code du jeu, les sons et why not une zik+son player)
Dans le compile.bat, le code-loc est à 0x4020 et le data-loc à 0x8048.
Etant apprenti débutant en prog C sur MSX, si je fais 0x4020+16588, je grignote des variables stockées à partir de 0x8048 ce qui fait plantin le bouzin. Me trompe-je ?
J'ai donc mis mon data-loc à 0xc000 mais le problème reste le même :
- à partir d'un certain moment, le programme plante
- si par contre j'enlève quelques 100aines d'octets (gfx non encore utilisé), ça marche.
Je pense que le soucis vient de ce crt0msx.s
mon compile.bat
@echo off
set path=%path%;D:\_Msx_Dev_\_Progr_MSX\SDCC\bin
sdasz80 -o crt0.rel crt0msx.s
sdcc -mz80 -c --oldralloc video.c
sdcc -mz80 -c --oldralloc tools.c
sdcc -mz80 -c --oldralloc gfx.c
sdcc -mz80 --std-c99 --oldralloc --data-loc 0x8048 --code-loc 0x4020 --no-std-crt0 crt0.rel -main.ihx tools.rel video.rel gfx.rel main.c
objcopy --input-target=ihex --output-target=binary main.ihx tmp.rom
del result.rom > nul
rename tmp.rom result.rom
del *.sym > nul
del *.noi > nul
pause;
D:\_Msx_Dev_\_Progr_MSX\meisei\meisei.exe D:\_Msx_Dev_\wii\result.rom
mon crt0msx.s
;; Generic crt0.s for a Z80
.globl _main
.area _HEADER (ABS)
;; Reset vector
.org 0x4000
.db 0x41
.db 0x42
.dw init
.dw 0x0000
.dw 0x0000
.dw 0x0000
.dw 0x0000
.dw 0x0000
.dw 0x0000
init:
;; Stack at the top of memory.
ld sp,(0xfc4a)
;; Initialise global variables
call _main
;; Ordering of segments for the linker.
.area _CODE
.area _GSINIT
.area _GSFINAL
.area _DATA
.area _BSS
.area _CODE
;; Special RLE decoder used for initing global data
;;__initrleblock::
;; Pull the destination address out
;; ld c,l
;; ld b,h
;; Pop the return address
;; pop hl
;;1$:
;; Fetch the run
;; ld e,(hl)
;; inc hl
;; Negative means a run
;; bit 7,e
;; jp z,2$
;; Code for expanding a run
;; ld a,(hl)
;; inc hl
;;3$:
;; ld (bc),a
;; inc bc
;; inc e
;; jp nz,3$
;; jp 1$
;2$:
;; Zero means end of a block
;; xor a
;; or e
;; jp z,4$
;; Code for expanding a block
;;5$:
;; ld a,(hl)
;; inc hl
;; ld (bc),a
;; inc bc
;; dec e
;; jp nz,5$
;; jp 1$
;;4$:
;; Push the return address back onto the stack
;; push hl
;; ret
.area _GSINIT
gsinit::
.area _GSFINAL
ret
Je préférais de loin l'ASM car tout est contrôlable mais le C est génial pour sa vitesse de développement et sa portabilité.
Est-ce qu'il vous est possible de remplir 'mon' vide qui concerne la prog sur MSX ?
Merci encore et bon dimanche
Eric
Dans ton CRT0 y a pas la routine qui sert normalement à reposition la seconde page de 16K de ta rom sur le même slot que la première (me semble -t-I-il)
Utilises le crt0 de Aoinko, déjà pour voir .’.
Utilises le crt0 de Aoinko, déjà pour voir .’.
Code ASM :
;------------------------------------------------------------------------------ ; █▀▀ █▀▄▀█ █▀ ▀▄▀ ; █▄▄ █ ▀ █ ▄█ █ █ v0.2 ;------------------------------------------------------------------------------ ; crt0 header for 32KB ROM ; ; Code address: 0x4010 ; Data address: 0xC000 ;------------------------------------------------------------------------------ .module crt0 .globl _main .globl l__INITIALIZER .globl s__INITIALIZED .globl s__INITIALIZER .globl s__HEAP HIMEM = #0xFC4A PPI_A = #0xA8 ;------------------------------------------------------------------------------ .area _HEADER (ABS) .org 0x4000 ; ROM header .db 0x41 .db 0x42 .dw init .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 .dw 0x0000 ;------------------------------------------------------------------------------ .area _CODE init: di ; Set stack address at the top of free memory ld sp, (HIMEM) ; Set Page 2 slot equal to Page 1 slot in a, (PPI_A) and a, #0xCF ld c, a in a, (PPI_A) and a, #0x0C add a, a add a, a or a, c out (PPI_A), a ; Initialize globals ld bc, #l__INITIALIZER ld a, b or a, c jp z, start ld de, #s__INITIALIZED ld hl, #s__INITIALIZER ldir ; Initialize heap address ld hl, #s__HEAP ld (#_g_HeapStartAddress), hl start: ; start main() function ei call _main rst 0 ;------------------------------------------------------------------------------ ; Ordering of segments for the linker ;-- ROM -- .area _HOME .area _CODE .area _INITIALIZER .area _GSINIT .area _GSFINAL ;-- RAM -- .area _DATA _g_HeapStartAddress:: .ds 2 .area _INITIALIZED .area _BSEG .area _BSS .area _HEAP
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie