La Place des Développeurs Mes 1ers pas sur MSX ...
Reprise du message précédent
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 .’.
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
C'est nickel,
il ne me reste plus qu'à debugger le menu pour passer à la suite
Merci à vous 2
Eric
I'll be back
il ne me reste plus qu'à debugger le menu pour passer à la suite
Merci à vous 2
Eric
I'll be back
Ricco59 :
Est-ce qu'il vous est possible de remplir 'mon' vide qui concerne la prog sur MSX ?
Il manque quelques infos pour pouvoir te répondre précisement :
- Quel support vises-tu ? ROM à priori vu le crt0 que tu utilises, mais est-ce un choix arrêté ? Tu peux aussi visé de créer un programme binaire exécutable sous Basic ou sous DOS.
- Quelle taille anticipes-tu pour l'ensemble de ton jeu ? Comme dit Eric (l'autre qui n'est pas toi
) c'est étonnant que ton intro occupe déjà 16K. Si tu vises plus de 32K pour ton jeu, ça va devenir "un peu" plus compliqué d'utiliser une ROM (faudrait soit commencer à jongler avec les pages que voit le z80, soit mettre le doigt dans l'engr... dans le monde merveilleux des memory mappers).Si tu vises une ROM, voici quelques conseils :
- Dans le crt0, place ta pile d'appelle à la valeur pointé par HIMEM (c'est une valeur en RAM qui est mise à jour par le système en fonction des périphériques présents)
- Dans le ctr0, il faut que tu initialise tes variables statiques (c'est la partie Initialize globals du crt0 ci-dessus), sinon toutes les variables statiques initialisées dans ton code C risquent d'avoir une mauvaise valeur.
- Si ta ROM fait 32K (soit 2 pages pour le CPU) seul la page où se trouve le header de la ROM sera initialisé pour pointer vers le slot de ta cartouche. Dans ce cas, il faut que tu set manuellement l'autre page sur le même slot (c'est la partie Set Page 2 slot equal to Page 1 slot du crt0 ci-dessus)
- Tu peux mettre --code-loc à 4010h (juste après les 16 octets de l'entête)
- Tu dois mettre --data-loc au début de la première page de RAM. Si ta ROM fait 16K (1 page), tu peux le mettre à 8000h. Si elle fait 32K (2 pages), tu dois le mettre à C000h.
- La partie Initialize heap address du crt0 ci-dessus est là pour initialiser une variable C qui aura l'adresse du début de la RAM disponible
On est toujours ignorant avant de savoir.
Merci aoineko
J'ai vu pour msdos et basic mais pour le moment, le support privilégié reste la cartouche
Le jeu sur coleco fait ~28ko.
Comme je l'ai écrit plus haut, il me reste à ajouter la partie code du jeu proprement dite, les sons et peut être musique + son player. TOUS les graphs sont inclus dans l'intro (graphs intro+menu+jeu). Il y aura peut être 10ko de code en plus, c'est tout
Bonne soirée les zamis
Eric et merci encore
J'ai vu pour msdos et basic mais pour le moment, le support privilégié reste la cartouche
Le jeu sur coleco fait ~28ko.
Comme je l'ai écrit plus haut, il me reste à ajouter la partie code du jeu proprement dite, les sons et peut être musique + son player. TOUS les graphs sont inclus dans l'intro (graphs intro+menu+jeu). Il y aura peut être 10ko de code en plus, c'est tout
Bonne soirée les zamis
Eric et merci encore
Tant que tu restes sous les 32 KB, tu auras pas de soucis. 
Et puis, si c'est pas déjà fait, y a surement moyen de bien compresser tes données.
Pour le player, je suis justement en train de l'ajouter dans ma lib.
J'ai déjà inclue le PT3player (https://github.com/mvac7/SDCC_PT3player) qui se branche très facilement vu qu'il est fait pour SDCC.
Ca fonctionne bien mais je suis pas super fan de son outil de création de musique : Vortex Tracker II.
Je vais faire des tests de performance (temps d'exécution / occupation ROM&RAM).
Je vais aussi regarder ce qui se fait ailleurs ; notamment le replayer de Arkos Tracker (https://www.julien-nevo.com/arkostracker/).
Je te tiens au courant.
Et puis, si c'est pas déjà fait, y a surement moyen de bien compresser tes données.
Pour le player, je suis justement en train de l'ajouter dans ma lib.
J'ai déjà inclue le PT3player (https://github.com/mvac7/SDCC_PT3player) qui se branche très facilement vu qu'il est fait pour SDCC.
Ca fonctionne bien mais je suis pas super fan de son outil de création de musique : Vortex Tracker II.
Je vais faire des tests de performance (temps d'exécution / occupation ROM&RAM).
Je vais aussi regarder ce qui se fait ailleurs ; notamment le replayer de Arkos Tracker (https://www.julien-nevo.com/arkostracker/).
Je te tiens au courant.
On est toujours ignorant avant de savoir.
Bon,
même si tout ne fonctionne pas encore, j'ai intégré une bonne moitié du code restant, fait des rectifications au niveau des différentes routines et
- je me suis aperçu qu'une fonction asm avait un buug... ca c'est rien (pas dramatique)
- là où ça l'est plus, c'est qu'en rajoutant cette partie de code mon fichier fait maintenant 34 132 octets !!!!! aïe aïe aïe carambarrrrrr.
Mon main.map, lui est à 23674 octets (de 0x4010 à 0x5c7a) pour _CODE.
pour _DATA, j'ai 627 octets (à partir de 0xc000)
pour _INITIALIZED, j'ai 33 octets (à partir de 0x273)
pour _HOME, j'ai 671 octets (à partir de 0xc294)
pour _INITIALIZER, j'ai 33 octets
pour _HEADER0, j'ai bien mes 16 octets
dans mon crt0.s, j'ai bien data-loc 0xc000 et code-loc 0x4010
Est-ce sdcc 4.0.0 qui 'gonfle' le code et moi par la même (je n'ai presque plus de cheveux) ? (J'utilisais sdcc 3.6.0 sur coleco qui lui me sortait un fichier à ~29ko (jeu complet avec bruitage)...)
Je suis un peu à la déroute.
Je ferme l'ensemble et réouvrirait plus tard
Cela dit, un grand merci les zamis
Eric
même si tout ne fonctionne pas encore, j'ai intégré une bonne moitié du code restant, fait des rectifications au niveau des différentes routines et
- je me suis aperçu qu'une fonction asm avait un buug... ca c'est rien (pas dramatique)
- là où ça l'est plus, c'est qu'en rajoutant cette partie de code mon fichier fait maintenant 34 132 octets !!!!! aïe aïe aïe carambarrrrrr.
Mon main.map, lui est à 23674 octets (de 0x4010 à 0x5c7a) pour _CODE.
pour _DATA, j'ai 627 octets (à partir de 0xc000)
pour _INITIALIZED, j'ai 33 octets (à partir de 0x273)
pour _HOME, j'ai 671 octets (à partir de 0xc294)
pour _INITIALIZER, j'ai 33 octets
pour _HEADER0, j'ai bien mes 16 octets
dans mon crt0.s, j'ai bien data-loc 0xc000 et code-loc 0x4010
sdcc -mz80 --std-c99 --oldralloc --data-loc 0xc000 --code-loc 0x4010 --no-std-crt0 crt0.rel -main.ihx tools.rel video.rel gfx.rel mes_sources\main.c
Est-ce sdcc 4.0.0 qui 'gonfle' le code et moi par la même (je n'ai presque plus de cheveux) ? (J'utilisais sdcc 3.6.0 sur coleco qui lui me sortait un fichier à ~29ko (jeu complet avec bruitage)...)
Je suis un peu à la déroute.
Je ferme l'ensemble et réouvrirait plus tard
Cela dit, un grand merci les zamis
Eric
Vu que tu utilises bien --no-std-crt0, SDCC ne va rien ajouté du tout.
Tout ce que tu as dans ta ROM c'est :
- Ton code (peu probable qu'il soit très gros (tu peux essayer l'option --opt-code-size pour voir si ça change significativement),
- Tes valeurs d'initialisation des variables globales (33 octets donc c'est rien),
- Tes variables const... donc le problème doit venir de là.
Tu ajoutes beaucoup d'image ? Elles sont compressées ?
Tu peux poster ton fichier .map et .sym pour qu'on puisse jeter un oeil ?
Même si je te conseille d'essayer de rester sous 32K (normalement y a la place pour un jeu MSX1), il est tout à fait possible de faire une cartouche de 48K.
Les deux seuls contraintes sont :
- Bien ranger tes données pour n'avoir que des datas dans la 1re page de 16K (aucun code),
- Accéder à ces données par la routine Bios de lecture interslot. C'est plus lent que l'accès direct, mais c'est pas compliqué à mettre en place.
Tout ce que tu as dans ta ROM c'est :
- Ton code (peu probable qu'il soit très gros (tu peux essayer l'option --opt-code-size pour voir si ça change significativement),
- Tes valeurs d'initialisation des variables globales (33 octets donc c'est rien),
- Tes variables const... donc le problème doit venir de là.
Tu ajoutes beaucoup d'image ? Elles sont compressées ?
Tu peux poster ton fichier .map et .sym pour qu'on puisse jeter un oeil ?
Même si je te conseille d'essayer de rester sous 32K (normalement y a la place pour un jeu MSX1), il est tout à fait possible de faire une cartouche de 48K.
Les deux seuls contraintes sont :
- Bien ranger tes données pour n'avoir que des datas dans la 1re page de 16K (aucun code),
- Accéder à ces données par la routine Bios de lecture interslot. C'est plus lent que l'accès direct, mais c'est pas compliqué à mettre en place.
On est toujours ignorant avant de savoir.
c'est quoi cette option de compilation ?
--oldralloc
Use old register allocator. The old register allocator is typically is faster than the current one, but the current one generates better code. This differences are the most noticeable, when a high value for --max-allocs-per-node is used.
--fno-omit-frame-pointer Neve
Je la soupçonne d'augmenter un tantinet la taille du code !? Edité par ericb59 Le 18/01/2021 à 07h18
--oldralloc
Use old register allocator. The old register allocator is typically is faster than the current one, but the current one generates better code. This differences are the most noticeable, when a high value for --max-allocs-per-node is used.
--fno-omit-frame-pointer Neve
Je la soupçonne d'augmenter un tantinet la taille du code !? Edité par ericb59 Le 18/01/2021 à 07h18
Merci Guillaume,
Je posterai les 2 fichiers ce soir
Bonne journée
Je posterai les 2 fichiers ce soir
Bonne journée
Avec sdcc 4.0.0, d'après les tests qui m'ont permi de me lancer, le oldralloc est nécessaire. Lorsque je compilais avec sdcc 3.6.0, il n'y avait pas de soucis et pas besoin de oldralloc...
Pour mes const, il y en a bcp c'est vrai et tous mes graphs sont 'pletterisés'
Peut être vais je retourner sur 3.6.0
Bonne journée les zamis Edité par Ricco59 Le 18/01/2021 à 12h49
Pour mes const, il y en a bcp c'est vrai et tous mes graphs sont 'pletterisés'
Peut être vais je retourner sur 3.6.0
Bonne journée les zamis Edité par Ricco59 Le 18/01/2021 à 12h49
C'est quoi des graphs 'pletterisés' ? 
En tout cas, si tu as besoin, j'ai pas mal bossé sur les systèmes de compression d'image et j'ai de bons outils.
En tout cas, si tu as besoin, j'ai pas mal bossé sur les systèmes de compression d'image et j'ai de bons outils.
On est toujours ignorant avant de savoir.
aoineko :
C'est quoi des graphs 'pletterisés' ?
Pletter est un outil de compression de données sur MSX (comme Bitbuster également)
Enfin, plus précisément : de compression sur PC et de décompression sur MSX.
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)
Metalion :
Pletter est un outil de compression de données sur MSX (comme Bitbuster également)
Enfin, plus précisément : de compression sur PC et de décompression sur MSX.
Enfin, plus précisément : de compression sur PC et de décompression sur MSX.
Ah, c'est une compression LZ77.
Perso, ma conclusion sur les compresseurs c'est que ça dépend énormément des data et de leur agencement.
C'est pour ça que dans mon tool de compression j'ai ajouté pléthore d'algo (pas encore le LZ77
) et que j'ai une option pour générer toutes les versions et sélectionner la meilleure (= la plus petite).Pour en revenir au problème de Ricco, si tout est déjà compressé, ça complique un peu les choses.
On est toujours ignorant avant de savoir.
Yes Sir...
... Gros problèmes Edité par Ricco59 Le 18/01/2021 à 17h15
... Gros problèmes Edité par Ricco59 Le 18/01/2021 à 17h15
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie