La Place des Développeurs Cross developpement : Tests rapides + debug
Reprise du message précédent
@GDXles "org"s sont mal placé!
Code pour créer une ROM de 16Ko (.ROM) :
Code ASM :
org04000h db041h,042h dwprgStart dw0,0,0,0,0,0 prgStart: ; Insère ton programme ici. prgEnd: ds08000h-prgEnd
Code pour créer une ROM de 32Ko (.ROM) :
Code ASM :
org04000h db041h,042h dwprgStart-020h dw0,0,0,0,0,0 ;-- Routine de sélection de la ROM sur la plage mémoire de 8000h à BFFFh db0CDh,038h,001h,00Fh,00Fh,0E6h,003h,04Fh db006h,000h,021h,0C1h,0FCh,009h,07Eh,0E6h db080h,0B1h,04Fh,023h,023h,023h,023h,07Eh db0E6h,00Ch,0B1h,026h,080h,0CDh,024h,000h ;-- prgStart: ; Insère ton programme ici. prgEnd: ds0C000h-prgEnd
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...
Question bête,
j'ai cherché pendant 10 minutes pourquoi je ne voyais pas mes modifs de variables en mémoire,
mais oui bien sur, c'est considéré comme de la ROM donc on ne peut pas écrire dedans (?!!)....
Est-ce qu'il est commun que les programmes ROM cartouches écrivent aussi dans la RAM ?
en $8000 par exemple pour une ROM 16k,
j'imagine bien que oui, mais comme c'est la première fois que je "constitue" des programmes ROM....
j'ai cherché pendant 10 minutes pourquoi je ne voyais pas mes modifs de variables en mémoire,
mais oui bien sur, c'est considéré comme de la ROM donc on ne peut pas écrire dedans (?!!)....
Est-ce qu'il est commun que les programmes ROM cartouches écrivent aussi dans la RAM ?
en $8000 par exemple pour une ROM 16k,
j'imagine bien que oui, mais comme c'est la première fois que je "constitue" des programmes ROM....
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
les roms de 16k sont en général de roms msx1, et comme beaucoup de msx1 n'ont que 16k de ram, voir 8k, elles ne fonctionnerait pas sur tous les msx
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...
ou stockent leurs variables les ROMS MSX1 de 16k alors ?
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
le fait de ne pas avoir beaucoup de ram n'empéche pas de faire tourner le jeu
souvent les jeux se servent de la ram comprise au dessus de C000H qui est accessible sans changer de slot
cette zone est libre jusqu'a F380h pour un MSX sans lecteur de disquette
il existe des jeux dont une partie est en Basic et l'autre en L.M. qui sont regroupés dans une cartouche 16K
Trial Ski de Ascii est un exemple
souvent les jeux se servent de la ram comprise au dessus de C000H qui est accessible sans changer de slot
cette zone est libre jusqu'a F380h pour un MSX sans lecteur de disquette
il existe des jeux dont une partie est en Basic et l'autre en L.M. qui sont regroupés dans une cartouche 16K
Trial Ski de Ascii est un exemple
En général, on utilise 8 ou 16 Ko de RAM mais si tu veux utiliser tout de même la RAM de 8000h à F380h, il y a 3 solutions.
1/ Le plus simple, tu fais une ROM de 16Ko de 4000h à 7FFFh. Il y a rien de spécial à faire puisque le système place la RAM de 8000h à FFFFh et reste là au moment de l'execution de la ROM.
2/ Tu fais une ROM de 32Ko de 0000h à 7FFFh avec l'entête à 4000h. Là c'est pareil que le 1 sauf que tu devra couper les interruptions pour accéder à la plage de 0000h à 3FFFh de ta ROM. Tu devras aussi changer de slot par accès direct (écriture au port I/O A8h et à l'adresse FFFFh du slot de ta ROM et du slot de la Main-ROM). Tu peux mettre l'entête à 0000h si tu préfères.
3/ Tu fais une ROM de 32Ko de 4000h à BFFFh avec l'entête à 4000h. Tu devras faire une recherche d'un slot avec de la RAM sur la plage 4000h à 7FFFh et le mémoriser avant de sélectionner la seconde partie de la ROM. Edité par GDX Le 17/10/2015 à 16h08
1/ Le plus simple, tu fais une ROM de 16Ko de 4000h à 7FFFh. Il y a rien de spécial à faire puisque le système place la RAM de 8000h à FFFFh et reste là au moment de l'execution de la ROM.
2/ Tu fais une ROM de 32Ko de 0000h à 7FFFh avec l'entête à 4000h. Là c'est pareil que le 1 sauf que tu devra couper les interruptions pour accéder à la plage de 0000h à 3FFFh de ta ROM. Tu devras aussi changer de slot par accès direct (écriture au port I/O A8h et à l'adresse FFFFh du slot de ta ROM et du slot de la Main-ROM). Tu peux mettre l'entête à 0000h si tu préfères.
3/ Tu fais une ROM de 32Ko de 4000h à BFFFh avec l'entête à 4000h. Tu devras faire une recherche d'un slot avec de la RAM sur la plage 4000h à 7FFFh et le mémoriser avant de sélectionner la seconde partie de la ROM. Edité par GDX Le 17/10/2015 à 16h08
tu n'es pas obligé de commencer par une rom
si j'ai bien compris Athanor a une parti basic et une autre en code machine
la disquette convient bien a ce type de programmation et autorise 720k
pour info le MSX a un macro-language graphique par la commande DRAW qui fonctionne dans tous les modes graphiques
voici un exemple : VAMP.dsk
si j'ai bien compris Athanor a une parti basic et une autre en code machine
la disquette convient bien a ce type de programmation et autorise 720k
pour info le MSX a un macro-language graphique par la commande DRAW qui fonctionne dans tous les modes graphiques
voici un exemple : VAMP.dsk
Merci pour les infos!
Je ne vais pas adapter Athanor tout de suite pour MSX
J'ai d'autres choses en tête.
De plus les version C64+VIC20 sont full assembleur.
Je ne vais pas adapter Athanor tout de suite pour MSX
J'ai d'autres choses en tête.
De plus les version C64+VIC20 sont full assembleur.
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
Salut!
J'avance bien dans mon apprentissage,
Si vous savez où je peux trouver des sources pour MSX1 de progs qui manipulent la mémoire vidéo tout en se synchronisant sur le balayage écran ça m'intérèsse !
De plus, est-il plus rapide d'avoir en RAM une copie du contenu video, de faire toutes ses opérations en RAM et puis de "blitter" les modifs en VRAM ? ou de manipuler uniquement la VRAM ? (ce dont je doute...)
J'avance bien dans mon apprentissage,
Si vous savez où je peux trouver des sources pour MSX1 de progs qui manipulent la mémoire vidéo tout en se synchronisant sur le balayage écran ça m'intérèsse !
De plus, est-il plus rapide d'avoir en RAM une copie du contenu video, de faire toutes ses opérations en RAM et puis de "blitter" les modifs en VRAM ? ou de manipuler uniquement la VRAM ? (ce dont je doute...)
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
majikeyric :
Si vous savez où je peux trouver des sources pour MSX1 de progs qui manipulent la mémoire vidéo tout en se synchronisant sur le balayage écran ça m'intérèsse !
Si tu parles de synchro sur le VBLANK (donc une fois par frame), oui c'est possible.
Par contre, sur MSX1, pas possible de synchroniser sur une ligne spécifique de balayage, il faut calculer le temps.
La synchro sur le VBLANK est relativement simple : il suffit d'écrire l'instruction "JP $xxxx" à l'adresse $FD9F (c'est un appel secondaire de l'interruption), en se sécurisant bien évidemment avec DI/EI. Et tu écrit en $xxxx le programme qui gère cette interruption VBLANK, qui peut par exemple passer l'info à ton programme principal par une variable RAM qui passe à 1, sans oublier de le terminer par RET. Pas besoin de sauvegarder tous les registres, c'est déjà fait par l'appel primaire de l'interruption.
majikeyric :
De plus, est-il plus rapide d'avoir en RAM une copie du contenu video, de faire toutes ses opérations en RAM et puis de "blitter" les modifs en VRAM ? ou de manipuler uniquement la VRAM ? (ce dont je doute...)
Cela dépends de ce que tu veux faire comme opération.
Plus elles sont complexes et/ou nombreuses, plus ce sera plus rapide de "blitter" à partir de la RAM. Edité par Metalion Le 18/10/2015 à 19h32
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)
Cool! Merci pour les infos Métalion!
Je vais faire mon premier "hook" alors !!!!!!!!!!!
Je vais tester ça !!!!!
J'imagine donc que pour faire une synchro à la ligne raster , il faut utiliser un timer?
Mais bon à la VBL ça m'ira très bien.
Les écritures d'abord en RAM, c'est par exemple pour faire un scrolling.
Je vais faire mon premier "hook" alors !!!!!!!!!!!
Je vais tester ça !!!!!
J'imagine donc que pour faire une synchro à la ligne raster , il faut utiliser un timer?
Mais bon à la VBL ça m'ira très bien.
Les écritures d'abord en RAM, c'est par exemple pour faire un scrolling.
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
majikeyric :
Je vais faire mon premier "hook" alors !!!!!!!!!!!
C'est exactement ça
majikeyric :
J'imagine donc que pour faire une synchro à la ligne raster , il faut utiliser un timer?
Sur MSX1, oui.
Sur MSX2, c'est possible à la ligne via une interruption spécifique
majikeyric :
Les écritures d'abord en RAM, c'est par exemple pour faire un scrolling.
Si c'est pour un scrolling, alors, c'est beaucoup plus rapide de travailler sur la RAM et de blitter ensuite.
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)
Pourquoi avec une ROM de 32k, il est nécéssaire d'indiquer au MSX que la page 2 ($8000-$bfff) est dans le même slot/subslot que la page 1 ($4000-$7ffff) ?
Ce que je ne comprends pas c'est pourquoi le MSX ne le fait pas de lui même ?
C'est plus une sécurité car il est censé le faire à l'init ?
ou alors c'est parce-qu'il ne trouve pas en $8000 d'entête dans le slot cartouche et bascule donc sur un slot contenant de la RAM ?
Ce que je ne comprends pas c'est pourquoi le MSX ne le fait pas de lui même ?
C'est plus une sécurité car il est censé le faire à l'init ?
ou alors c'est parce-qu'il ne trouve pas en $8000 d'entête dans le slot cartouche et bascule donc sur un slot contenant de la RAM ?
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
majikeyric :
Pourquoi avec une ROM de 32k, il est nécéssaire d'indiquer au MSX que la page 2 ($8000-$bfff) est dans le même slot/subslot que la page 1 ($4000-$7ffff) ?
Ce que je ne comprends pas c'est pourquoi le MSX ne le fait pas de lui même ?
Ce que je ne comprends pas c'est pourquoi le MSX ne le fait pas de lui même ?
C'est juste parce que le MSX sélectionne les slots un a un pour chercher l'entête des ROM.
Au fait, le registre C contient le numéro de Slot (au format FxxxSSPP) de la ROM lors de son exécution à l'adresse de l'entête. C'est bon à savoir.
Sector28bis :
@GDX
les "org"s sont mal placé!
les "org"s sont mal placé!
En effet.
Edité par
GDX
Le 26/10/2015 à 00h36
GDX :
C'est juste parce que le MSX sélectionne les slots un a un pour chercher l'entête des ROM.
Et .... ?
il en trouve une dans le slot cartouche en $4000, alors il bascule la page 1 sur ce slot,
il n'en trouve pas en $8000 et il bascule sur un slot contenant de la RAM pour la page 2 ???
GDX :
Au fait, le registre C contient le numéro de Slot (au format FxxxSSPP) de la ROM lors de son exécution à l'adresse de l'entête. C'est bon à savoir.
Au fait, le registre C contient le numéro de Slot (au format FxxxSSPP) de la ROM lors de son exécution à l'adresse de l'entête. C'est bon à savoir.
Au Start du programme cartouche c contient le numéro de slot ? cool!
Rétro coder fou : Z80 : MSX / Amstrad CPC / ZX Spectrum -- 6502 : C64 / VIC20 -- 68000 : Amiga
Mon site dédié à ma passion pour la programmation : http://majikeyric.free.fr
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie