La Place des Développeurs Projet GOS Et oui, encore trop d'ambitions ^^
Reprise du message précédent
Ma routine Check d’abord la vram, text si on est sur MSX1 ou pas, attends le VDP, Après tout ça 4 ou 8 octets, c’est kif-kif pour la routine à mon avis.
J'ai galéré sur un problème tout bête : en Screen mode 5 (G4), les commandes VDP "high-speed move" ne peuvent pointer qu'un pixel sur deux sur une ligne horizontale (uniquement les pairs).
Je le savais et ça semblait assez normal puis que, dans ce mode, un seul octet représente 2 points consécutifs à l'écran.
Par contre, ce que je ne savais pas, et qui m'a créé du soucis, c'est que des commandes "logical move" n'ont pas du tout cette contrainte !
Le VDP se charge lui-même de faire les décalages de bits quand on écrit dans un pixel de coordonnée X impaire.
Au final, c'est cool, car ça permet de déplacer ses sprites de façon fluide sur l'axe X... faut juste le savoir.
Bon, évidemment, cette fonctionnalité & un coup qui explique pourquoi les commandes "high-speed" sont bien plus rapides.
Je le savais et ça semblait assez normal puis que, dans ce mode, un seul octet représente 2 points consécutifs à l'écran.
Par contre, ce que je ne savais pas, et qui m'a créé du soucis, c'est que des commandes "logical move" n'ont pas du tout cette contrainte !
Le VDP se charge lui-même de faire les décalages de bits quand on écrit dans un pixel de coordonnée X impaire.
Au final, c'est cool, car ça permet de déplacer ses sprites de façon fluide sur l'axe X... faut juste le savoir.
Bon, évidemment, cette fonctionnalité & un coup qui explique pourquoi les commandes "high-speed" sont bien plus rapides.
On est toujours ignorant avant de savoir.
Bon, même si le jeu en lui-même avance pas vraiment, j'ai presque fini les fonctionnalités dont je vais avoir besoin.
J'ai fait des petits programmes de test pour valider mes fonctionnalités :
- Les commandes VDP : smp_vdp.rom
- Les sprites : smp_sprt.rom
- Les fonctions de dessins "avancées" : smp_draw.rom
- Les polices de caractères : smp_print.rom
Oui, je réinvente la roue, mais 1) c'est potentiellement plus rapide que le Bios (ce qui est important pour mon jeu) et 2) ça m'amuse
Tout fonctionne bien en ROM, Basic BIN et DOS sauf :
- En Basic BIN, je ne sais pas comment retourner au Basic proprement en quittant mon programme. Y a une procédure "officielle" ? Je ne me souviens plus si les anciens jeux "pro" permettaient de retourner au Basic ou s'ils considéraient que l'utilisateur devait reboot son MSX pour y retourner.
- Même question pour le DOS
- Pour le DOS, j'ai aussi un soucis quand j'essaye de changer les Hook du Bios : ça freeze. Je me suis dis que le DOS avait déjà ses propres Hook, et j'ai essayé de les appeler depuis mes Hook, mais ça ne marche pas. Vous avez des infos à ce sujet ?
J'ai fait des petits programmes de test pour valider mes fonctionnalités :
- Les commandes VDP : smp_vdp.rom
- Les sprites : smp_sprt.rom
- Les fonctions de dessins "avancées" : smp_draw.rom
- Les polices de caractères : smp_print.rom
Oui, je réinvente la roue, mais 1) c'est potentiellement plus rapide que le Bios (ce qui est important pour mon jeu) et 2) ça m'amuse
Tout fonctionne bien en ROM, Basic BIN et DOS sauf :
- En Basic BIN, je ne sais pas comment retourner au Basic proprement en quittant mon programme. Y a une procédure "officielle" ? Je ne me souviens plus si les anciens jeux "pro" permettaient de retourner au Basic ou s'ils considéraient que l'utilisateur devait reboot son MSX pour y retourner.
- Même question pour le DOS
- Pour le DOS, j'ai aussi un soucis quand j'essaye de changer les Hook du Bios : ça freeze. Je me suis dis que le DOS avait déjà ses propres Hook, et j'ai essayé de les appeler depuis mes Hook, mais ça ne marche pas. Vous avez des infos à ce sujet ?
On est toujours ignorant avant de savoir.
Sympa tout ca 
Pour le DOS c'est quoi ton problème ? Pour les interruptions ?
Ca ne marche pas de manière classique si c'est cela ton problème.
J'ai dû ouvrir un Topic sur MSX.ORG pour qu'à plusieurs une solution émerge.
Il y a deux modèles d'interruption dans Fusion-C 1.3 si tu veux.
Pour le DOS c'est quoi ton problème ? Pour les interruptions ?
Ca ne marche pas de manière classique si c'est cela ton problème.
J'ai dû ouvrir un Topic sur MSX.ORG pour qu'à plusieurs une solution émerge.
Il y a deux modèles d'interruption dans Fusion-C 1.3 si tu veux.
LE voici, https://www.msx.org/forum/msx-talk/development/fusion-c-and-htimi
Par contre la solution finale m'a été fournie par email... Si j'ai bonne mémoire
Par contre la solution finale m'a été fournie par email... Si j'ai bonne mémoire
Merci pour le lien.
Je l'avais déjà lu, mais en le relisant, j'ai enfin compris mon problème !
Je n'avais pas compris que le DOS utilise les routines Bios de la Main-ROM (et surement aussi des autres ROM) et switch donc les slots des pages pendant les interruptions (sauf la page 3 qui reste sur le slot de la RAM).
Du coup, on est jamais sûr que notre fonction sera dans le bon slot au moment de l'appelle du hook.
Pour résoudre le problème, c'est assez simple : il faut connaitre le slot dans lequel est notre programme et changer la façon d'installer le hook dans la table en RAM.
Avant, j'insérais le code (3 bytes) :
Maintenant, j'utilise (4 bytes) :
Et voilà, ça marche \o/
Le seul cas qui pourrait poser problème, c'est si le code de notre hook est à cheval sur 2 pages... mais c'est pas trop compliquer d'organiser son code pour que ça n'arrive pas.
Du coup, le seul problème qui me reste, c'est : comment réinitialiser les graphismes du Basic ou du DOS après avoir quitté mon programme (qui chamboule toute la VRAM) ?
Des idées ?
Je l'avais déjà lu, mais en le relisant, j'ai enfin compris mon problème !
Je n'avais pas compris que le DOS utilise les routines Bios de la Main-ROM (et surement aussi des autres ROM) et switch donc les slots des pages pendant les interruptions (sauf la page 3 qui reste sur le slot de la RAM).
Du coup, on est jamais sûr que notre fonction sera dans le bon slot au moment de l'appelle du hook.
Pour résoudre le problème, c'est assez simple : il faut connaitre le slot dans lequel est notre programme et changer la façon d'installer le hook dans la table en RAM.
Avant, j'insérais le code (3 bytes) :
Code ASM :
jp dw AddressDeMaFonction
Maintenant, j'utilise (4 bytes) :
Code ASM :
rst 30 db SlotIdDeMonProgram dw AddressDeMaFonction
Et voilà, ça marche \o/
Le seul cas qui pourrait poser problème, c'est si le code de notre hook est à cheval sur 2 pages... mais c'est pas trop compliquer d'organiser son code pour que ça n'arrive pas.
Du coup, le seul problème qui me reste, c'est : comment réinitialiser les graphismes du Basic ou du DOS après avoir quitté mon programme (qui chamboule toute la VRAM) ?
Des idées ?
On est toujours ignorant avant de savoir.
et comment fais tu pour que ton code ne soit pas sur 2 pages ?
et dans le cas d'une rom 48 K
Après la solution qui m'a été apportée fonctionne très bien aussi .
et dans le cas d'une rom 48 K
Après la solution qui m'a été apportée fonctionne très bien aussi .
Les fonctions sont assemblées dans l'ordre où le compilateur les trouves donc le plus simple est d'organiser son code pour que les callback de hook se trouve au début de la première page.
Sinon, avec le crt0, y a surement moyen de créer un nouveau segment au début d'une autre page (pour les ROM 32 ou 48K surtout) et d'y mettre nos fonctions de hook.
J'ai vu que la solution que tu utilises passe par une fonction assembleur du coup j'ai pas creusé plus, mais il me semble très probable que tu auras aussi un problème si par malchance ta fonction de Hook se retrouve à cheval sur 2 pages (ce qui est peu probable mais possible).
Sinon, avec le crt0, y a surement moyen de créer un nouveau segment au début d'une autre page (pour les ROM 32 ou 48K surtout) et d'y mettre nos fonctions de hook.
J'ai vu que la solution que tu utilises passe par une fonction assembleur du coup j'ai pas creusé plus, mais il me semble très probable que tu auras aussi un problème si par malchance ta fonction de Hook se retrouve à cheval sur 2 pages (ce qui est peu probable mais possible).
On est toujours ignorant avant de savoir.
J'ai déjà un exemple de code, qui pourtant n'est pas tres gros, qui ne fonctionne pas avec ton crt0, car tu ne fais pas la recherche et l'init de la seconde page de 16K (a moins que tu aid changé) pour une rime de 32/48k.
Donc j'imagine les soucis que ça peut engendrer de ne pas avoir les pages cotes à cores, surtout en mode dos.
Sur le même code en mode dos avec le système d'interruption de Fusion-c je n'ai pas eu de soucis.
Après comme tu l'as déjà dit, on a pas les objectifs, toi tu te fais une lib sur mesure pour tes besoins et tu peux donc contrôler aux petits oignons ce que y fais.
Moi je veux une mon, clé en main pour que l'utilisateur n'ai pas à réfléchir à ce genre de problèmes, j'y mets en flexibilité forcément.
Donc j'imagine les soucis que ça peut engendrer de ne pas avoir les pages cotes à cores, surtout en mode dos.
Sur le même code en mode dos avec le système d'interruption de Fusion-c je n'ai pas eu de soucis.
Après comme tu l'as déjà dit, on a pas les objectifs, toi tu te fais une lib sur mesure pour tes besoins et tu peux donc contrôler aux petits oignons ce que y fais.
Moi je veux une mon, clé en main pour que l'utilisateur n'ai pas à réfléchir à ce genre de problèmes, j'y mets en flexibilité forcément.
Je suis pas sûr de comprendre.
Si tu parles de set la page 2 au même slot que la page 1 pour une ROM 32K commençant en page 1, c'est bien ce que je fais (cf. https://github.com/aoineko-fr/cmsx/blob/master/cmsx/src/crt0/crt0_rom32.s).
Pour les ROM 48K, j'ai choisi de laisser le Bios en page 0 au démarrage ; Ma ROM couvre les pages 0 à 2, mais mon boot est au début de la page 1.
Je réserve la Page 0 de ma ROM 48K pour des datas que j'irai lire via des accès inter-slot.
Pour les programmes DOS ou Basic, ils sont entièrement sur le slot de la RAM. Le problème ne vient pas de notre programme, mais des changements de slot que l'OS fait sur certaines pages durant les interruptions.
Tant mieux si Fusion-C gère proprement des callback qui se trouverait à cheval sur deux pages, mais j'ai quand même un doute.
Si tu parles de set la page 2 au même slot que la page 1 pour une ROM 32K commençant en page 1, c'est bien ce que je fais (cf. https://github.com/aoineko-fr/cmsx/blob/master/cmsx/src/crt0/crt0_rom32.s).
Pour les ROM 48K, j'ai choisi de laisser le Bios en page 0 au démarrage ; Ma ROM couvre les pages 0 à 2, mais mon boot est au début de la page 1.
Je réserve la Page 0 de ma ROM 48K pour des datas que j'irai lire via des accès inter-slot.
Pour les programmes DOS ou Basic, ils sont entièrement sur le slot de la RAM. Le problème ne vient pas de notre programme, mais des changements de slot que l'OS fait sur certaines pages durant les interruptions.
Tant mieux si Fusion-C gère proprement des callback qui se trouverait à cheval sur deux pages, mais j'ai quand même un doute.
On est toujours ignorant avant de savoir.
Citation :
Si tu parles de set la page 2 au même slot que la page 1 pour une ROM 32K commençant en page 1, c'est bien ce que je fais (cf. https://github.com/aoineko-fr/cmsx/blob/master/cmsx/src/crt0/crt0_rom32.s).
J'ai essayé ton, crt0 32K, il ne marche pas avec moi. Mais peut être que je ne l'utilises pas correctement.
Mon code d'exemple, ne fonctionne que si j'introduit cette routine dans le CRT0
Code ASM :
call find_rom_page_2 call _main rst 0 find_rom_page_2:: ld hl, #0x4000 ld b, (hl) xor a ld (hl), a ld a, (hl) or a jr nz,RomPage2 ; El programa esta en RAM - no buscar ld (hl),b ret RomPage2: di ; Slot primario call #0x0138 ; call RSLREG rrca rrca and #0x03 ; Slot secundario ld c, a ld hl, #0xfcc1 add a, l ld l, a ld a, (hl) and #0x80 or c ld c, a inc l inc l inc l inc l ld a, (hl) ; Definir el identificador de slot and #0x0c or c ld h, #0x80 ; Habilitar permanentemente call #0x0024 ; call ENASLT ei ret
ericb59 :
J'ai essayé ton, crt0 32K, il ne marche pas avec moi. Mais peut être que je ne l'utilises pas correctement.
Mon code d'exemple, ne fonctionne que si j'introduit cette routine dans le CRT0
Mon code d'exemple, ne fonctionne que si j'introduit cette routine dans le CRT0
Le changement de page est déjà fait dans le crt0 de mes ROM 32K :
Code ASM :
; 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
Je passe directement par les ports du PPI plutôt que les routines du Bios (le but étant à terme de virer complètement le Bios et de récupérer la Page 0
) mais ça fait la même chose que le ctr0 que tu utilises.Je ne sais pas ce qu'est censé faire le programme que tu testes mais en tout cas, mon crt0 ROM 32K fonctionne avec tous les programmes C que j'ai essayé.
Bon, tout ça me renseigne pas sur mon problème : Comment réinitialiser l'affichage du DOS/Bios après avoir quitté un programme qui modifie la VRAM ?
On est toujours ignorant avant de savoir.
Citation :
mon crt0 ROM 32K fonctionne avec tous les programmes C que j'ai essayé.
Ben je n'en doute pas. Mais pourquoi ca ne marche pas avec moi alors ... discrimination !!
Quel intérêt tu as à te passer du BIOS au Boot ? Pour le jeu en lui même je ne dis pas que c'est inutile, mais au Boot, c'est plus du pinaillage non ?
Citation :
Comment réinitialiser l'affichage du DOS/Bios
Moi je passe en Screen 0 et je fait un Call 5. Si tu as remis les Interruptions tel qu'au départ ça devrait bien se passer.
Quand tu changes de mode écran (avec le Bios), la VRAM est censée se réinitialiser. Edité par ericb59 Le 04/01/2021 à 16h14
ericb59 :
Ben je n'en doute pas. Mais pourquoi ca ne marche pas avec moi alors ... discrimination !!
Y a certainement une bonne raison. Est-ce qu'on a envie de passer du temps à la trouver ? Je pense pas vu que c'est pas bloquant et qu'on a tous les deux des trucs plus intéressant à faire.
ericb59 :
Quel intérêt tu as à te passer du BIOS au Boot ? Pour le jeu en lui même je ne dis pas que c'est inutile, mais au Boot, c'est plus du pinaillage non ?
Oui, ce n'est pas absolument nécessaire à cet endroit précis, mais :
1) je préfère le passage par les ports pour les périphériques standards (PPI, VDP et PSG) car c'est plus rapide, plus court et plus "direct" (pas besoin de savoir quelle tambouille fait le Bios)
2) le jour ou je couperai le cordon ombilical avec le Bios, j'aurai pas besoin de recheck toute ma Lib à la recherche des endroits ou j'utiliserais la Bios.
Mon but est de permettre à l'utilisateur d'accéder au Bios, mais que ce ne soit pas le cas dans les fonctions de ma lib.
ericb59 :
Moi je passe en Screen 0 et je fait un Call 5. Si tu as remis les Interruptions tel qu'au départ ça devrait bien se passer.
Quand tu changes de mode écran (avec le Bios), la VRAM est censée se réinitialiser.
Moi je passe en Screen 0 et je fait un Call 5. Si tu as remis les Interruptions tel qu'au départ ça devrait bien se passer.
Quand tu changes de mode écran (avec le Bios), la VRAM est censée se réinitialiser.
J'avais essayé mais ça ne marchait pas. Le mode était bien réinitialisé, mais pas la VRAM.
Grauw m'a conseillé la routine TOTEXT ; je testerai ça ce soir.
On est toujours ignorant avant de savoir.
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie