L'atelier VDP 9958 gigogne. Ajout d'un 9958 sur un 9938.
Salut à tous.
Nb: Pour faciliter l'écriture, je remplacerai [Vdp Flash Pipeline] par [VDPFP]
Afin de trouver une solution radicale au "clipping" naturellement généré par la méthode du [VDPFP], j'ai pour idée une solution qui devrait (pas encore testé) être radicale.
Dans les grandes lignes, la solution consisterait (au conditionnel donc) à cloner le VDP présent dans le MSX2 de type NMS8280 de Philips ou encore du matériel Sony ayant les capacitées de [Super Impose & Numérisation] en implantant le plus simplement du monde, un VDP 9958 par dessus le 9938 déjà présent dans le MSX en "gigogne".
Les objectifs recherchées sont les suivantes:
1) Vampiriser le [Circuit Vidéo Sortant] du MSX2 en le reliant un 9958 à la place du 9938. (Le 9938 n'affichera donc plus d'image à l'écran!)
2) Connecter correctement les Pins spécifiques au 9958 en tenant compte des quelques différences [Pin à Pin] avec le 9938 qui sera dessous.
3) Ne pas relier le 9958 au COLOR BUS [Pins C0/C1/C2/C3/C4/C5/C6 et C7)
Et...Ben c'est tout
De mes expérimentations passées, j'avais pu déterminer qu'il est tout à fait possible d'utiliser le Quartz d'origine pour deux VDP!
Reste l'inconnue concernant le fonctionnement des VRAMS reliées à deux VDP simultanément mais pour cela, je suis confiant de nature.
A partir de là, il suffit d'utiliser un périphérique RS232 pour injecter à souhait et instantanément, des données par paquet de:
53,0 Ko (taille d'une image flashée) X nombre de cycles (indéterminés) possibles par seconde.
Voici un exemple d'expérimentation en BASIC.
Cette méthode fonctionne comme suit:
1) Flux d'image depuis un périphérique multimédia. (a défaut de périphérique RS232 réel ou émulé, j'ai envoyé un flot en continu)
2) Je COPY SCREEN l'image affichée par le périphérique multimédia vers la page caché ZERO.
3) Je COPY depuis la page caché ZERO vers la page visible UN.
4) Je SET SCROLL
Nb: On voit s'afficher à l'écran, le fameux clipping conséquence naturelle du VDPFP.
Voici un autre exemple en basic qui ne demande qu'à être combiné.
Dans cette vidéo, je démontre le fonctionnement d'un scrolling "bidirectionnel" (avant/arrière) nécessitant idéalement, un périphérique "pilotable" par (RS232 par exemple).
Nb: Cette approche permet de prétendre à un jeu de type aventure puisque le héro peut revenir sur ses pas
Nb2: Combiné au VDPFP, le scrolling pourra se faire à très grande vitesse.
Dans cette vidéo (juste pour le concept) j'alterne COPY SCREEN / GCOPY (GFX9990) afin de tester la capacité de transfert.
Nb: On voit bien que lorsqu'on bascule sur le GFX9990, le clipping conséquent au VDPFP disparaît.
Nb2: La vitesse d’exécution est à multiplié par 10 ou plus puisque je génère un VDPFP à chaque cycle Juste pour pousser le test au maximum!
Voilà dans les grandes lignes le pourquoi et le comment de mes prochaines investigations.
La suite, sera une nomenclature du fonctionnement ainsi qu'un schéma de principe et autres dessins d'implantation, schémas etc..
Idées, remarque et suggestions en tous genres sont les bienvenues
Edité par
igal
Le 17/11/2018 à 12h31
Nb: Pour faciliter l'écriture, je remplacerai [Vdp Flash Pipeline] par [VDPFP]
Afin de trouver une solution radicale au "clipping" naturellement généré par la méthode du [VDPFP], j'ai pour idée une solution qui devrait (pas encore testé) être radicale.
Dans les grandes lignes, la solution consisterait (au conditionnel donc) à cloner le VDP présent dans le MSX2 de type NMS8280 de Philips ou encore du matériel Sony ayant les capacitées de [Super Impose & Numérisation] en implantant le plus simplement du monde, un VDP 9958 par dessus le 9938 déjà présent dans le MSX en "gigogne".
Les objectifs recherchées sont les suivantes:
1) Vampiriser le [Circuit Vidéo Sortant] du MSX2 en le reliant un 9958 à la place du 9938. (Le 9938 n'affichera donc plus d'image à l'écran!)
2) Connecter correctement les Pins spécifiques au 9958 en tenant compte des quelques différences [Pin à Pin] avec le 9938 qui sera dessous.
3) Ne pas relier le 9958 au COLOR BUS [Pins C0/C1/C2/C3/C4/C5/C6 et C7)
Et...Ben c'est tout
De mes expérimentations passées, j'avais pu déterminer qu'il est tout à fait possible d'utiliser le Quartz d'origine pour deux VDP!
Reste l'inconnue concernant le fonctionnement des VRAMS reliées à deux VDP simultanément mais pour cela, je suis confiant de nature.
A partir de là, il suffit d'utiliser un périphérique RS232 pour injecter à souhait et instantanément, des données par paquet de:
53,0 Ko (taille d'une image flashée) X nombre de cycles (indéterminés) possibles par seconde.
Voici un exemple d'expérimentation en BASIC.
Cette méthode fonctionne comme suit:
1) Flux d'image depuis un périphérique multimédia. (a défaut de périphérique RS232 réel ou émulé, j'ai envoyé un flot en continu)
2) Je COPY SCREEN l'image affichée par le périphérique multimédia vers la page caché ZERO.
3) Je COPY depuis la page caché ZERO vers la page visible UN.
4) Je SET SCROLL
Nb: On voit s'afficher à l'écran, le fameux clipping conséquence naturelle du VDPFP.
Voici un autre exemple en basic qui ne demande qu'à être combiné.
Dans cette vidéo, je démontre le fonctionnement d'un scrolling "bidirectionnel" (avant/arrière) nécessitant idéalement, un périphérique "pilotable" par (RS232 par exemple).
Nb: Cette approche permet de prétendre à un jeu de type aventure puisque le héro peut revenir sur ses pas
Nb2: Combiné au VDPFP, le scrolling pourra se faire à très grande vitesse.
Dans cette vidéo (juste pour le concept) j'alterne COPY SCREEN / GCOPY (GFX9990) afin de tester la capacité de transfert.
Nb: On voit bien que lorsqu'on bascule sur le GFX9990, le clipping conséquent au VDPFP disparaît.
Nb2: La vitesse d’exécution est à multiplié par 10 ou plus puisque je génère un VDPFP à chaque cycle Juste pour pousser le test au maximum!
Voilà dans les grandes lignes le pourquoi et le comment de mes prochaines investigations.
La suite, sera une nomenclature du fonctionnement ainsi qu'un schéma de principe et autres dessins d'implantation, schémas etc..
Idées, remarque et suggestions en tous genres sont les bienvenues
Edité par
igal
Le 17/11/2018 à 12h31
En gros tu veut faire ce que fait déjà un Msx2 en l'améliorant avec le set scroll du 2+
Je sais que sur le HBG900p (et pas le HBG900Ap), le Vdp est sur support
Je ne sais pas si c'est une instruction spécifique aux 900 mais c'est possible surimposser des images genre un image d'écran de tv avec la surimposse qui apparaît dans cette "Box"
Edité par
TurboSEB
Le 17/11/2018 à 13h54
Je sais que sur le HBG900p (et pas le HBG900Ap), le Vdp est sur support
Je ne sais pas si c'est une instruction spécifique aux 900 mais c'est possible surimposser des images genre un image d'écran de tv avec la surimposse qui apparaît dans cette "Box"
Edité par
TurboSEB
Le 17/11/2018 à 13h54
MSX 1&2 + Moniteurs+divers (environ 0.70Tonnes)
Salut TurboSeb.
Avoir le VDP sur support tulipe est un avantage certain pour souder le 9958 par dessus
En fait il ne s'agit pas de remplacer le VDP, mais de le compléter par un second VDP.
Ce second VDP étant un 9958, il embarque donc le scrolling horizontal en hardware. (Exploiter cette capacité avec la commande SET SCROLL nécessite de remplacer les ROMS MSX2 par les ROMS MSX2+).
Donc avant tout, le but ici est d'afficher à l'écran le VDP qui n'est pas relié au COLOR BUS de sorte à ne plus visualiser le clipping conséquent au VDPFP.
C'est la raison pour laquelle, le VDP relié au COLOR BUS ne doit pas être le VDP qui s'affiche à l'écran
Evidemment, si je trouve un moyen plus simple de résoudre ce problème de flash à l'écran, je n'hésiterai pas à changer de direction selon les résultats de mes testes hardware.
Par exemple, si il suffit de déconnecter une "PIN" du VDP d'origine pour éluder le problème, alors ce sera la solution la plus simple retenue.
Comme toujours, j'avancerai en expérimentant et à tâtons. J'aime tâter
Avoir le VDP sur support tulipe est un avantage certain pour souder le 9958 par dessus
En fait il ne s'agit pas de remplacer le VDP, mais de le compléter par un second VDP.
Ce second VDP étant un 9958, il embarque donc le scrolling horizontal en hardware. (Exploiter cette capacité avec la commande SET SCROLL nécessite de remplacer les ROMS MSX2 par les ROMS MSX2+).
Donc avant tout, le but ici est d'afficher à l'écran le VDP qui n'est pas relié au COLOR BUS de sorte à ne plus visualiser le clipping conséquent au VDPFP.
C'est la raison pour laquelle, le VDP relié au COLOR BUS ne doit pas être le VDP qui s'affiche à l'écran
Evidemment, si je trouve un moyen plus simple de résoudre ce problème de flash à l'écran, je n'hésiterai pas à changer de direction selon les résultats de mes testes hardware.
Par exemple, si il suffit de déconnecter une "PIN" du VDP d'origine pour éluder le problème, alors ce sera la solution la plus simple retenue.
Comme toujours, j'avancerai en expérimentant et à tâtons. J'aime tâter
Visiteur
Vagabond
Message : 0
Salut Igal! Cela me paraît une solution bien compliquée et accessible à peu de monde. Au risque d'être un peu lourd, je reviens sur le fait qu'il faudrait peut être trouver une solution logicielle en réalisant le scrolling au moment du temps mort vertical de l'affichage VDP pour éviter cet effet de clipping 
Salut Sylvain.
En fait, le fonctionnement est le suivant:
[COPY SCREEN], ou [COPY SCREEN 0 (mode "normal")] ou encore [COPY SCREEN 1(mode "entrelacé")] s'applique Exclusivement que sur la Page visible!
Le clipping en question n'est pas la conséquence du scrolling ou d'un temps d'utilisation du CPU ou VDP mais une conséquence directe du BASIC et probablement aussi la conséquence du Hardware "normale/logique" du VDP!
En effet, il n'y a aucune bonne raison de "numériser" ce que l'on ne voit pas et il est beaucoup plus logique de voir ce que l'on souhaite numériser.
Il faut comprendre que:
La définition wikipédia d'une [Numérisation] est claire, il faut que les données soient transférées en RAM ou VRAM ou SRAM etc..
COPY SCREEN est une commande pour le moins étrange dans le sens ou la numérisation est plus que rapide, elle semble complètement instantanée.
Voici une vidéo qui met en évidence "l'exploit/le comportement inattendu":
Nb: Jusqu'à 2 minutes 20, absolument chaque pixel que tu vois à l'écran est "numérisé" à la volée sans le moindre effort par le VDP!
Nb: A partir de 2 minutes 40, tu vois des images stockées en RAM (pendant les premières 2 minutes 20, certaines des images ont été transférées depuis la VRAM => la RAM. Le temps imputé à ce transfert VRAM => RAM, les scènes numérisées par le VDP le sont encore lues/numérisées en continu sans le moindre effort mais tant que le transfert VRAM =RAM n'est pas terminé, l'opération de VRAM => RAM ne peut pas se répéter. Cela explique pourquoi seulement une image toutes les secondes est mise en RAM et non pas 10,20 ou 30 images par seconde comme semble le gérer sans problème le Color Bus du VDP ainsi que la VRAM qui semble absorber le flux en continu sans le moindre effort
).
Pour rappel, le clipping c'est ce que tu peux voir au secondes:
0 / 2 / 4 / 6 etc.. de la vidéo ci dessous:
Nb: En ce qui me concerne, l'effet indésirable n'est pas la micro coupure du scroll mais la sorte de "Flash" qui apparaît brièvement à l'écran
En conclusion:
A moins que le BASIC soit la cause exclusive du Flash, je pense que le problème est en réalité le fonctionnement normal du VDP
Edité par
igal
Le 20/11/2018 à 18h14
En fait, le fonctionnement est le suivant:
[COPY SCREEN], ou [COPY SCREEN 0 (mode "normal")] ou encore [COPY SCREEN 1(mode "entrelacé")] s'applique Exclusivement que sur la Page visible!
Le clipping en question n'est pas la conséquence du scrolling ou d'un temps d'utilisation du CPU ou VDP mais une conséquence directe du BASIC et probablement aussi la conséquence du Hardware "normale/logique" du VDP!
En effet, il n'y a aucune bonne raison de "numériser" ce que l'on ne voit pas et il est beaucoup plus logique de voir ce que l'on souhaite numériser.
Il faut comprendre que:
La définition wikipédia d'une [Numérisation] est claire, il faut que les données soient transférées en RAM ou VRAM ou SRAM etc..
COPY SCREEN est une commande pour le moins étrange dans le sens ou la numérisation est plus que rapide, elle semble complètement instantanée.
Voici une vidéo qui met en évidence "l'exploit/le comportement inattendu":
Nb: Jusqu'à 2 minutes 20, absolument chaque pixel que tu vois à l'écran est "numérisé" à la volée sans le moindre effort par le VDP!
Nb: A partir de 2 minutes 40, tu vois des images stockées en RAM (pendant les premières 2 minutes 20, certaines des images ont été transférées depuis la VRAM => la RAM. Le temps imputé à ce transfert VRAM => RAM, les scènes numérisées par le VDP le sont encore lues/numérisées en continu sans le moindre effort mais tant que le transfert VRAM =RAM n'est pas terminé, l'opération de VRAM => RAM ne peut pas se répéter. Cela explique pourquoi seulement une image toutes les secondes est mise en RAM et non pas 10,20 ou 30 images par seconde comme semble le gérer sans problème le Color Bus du VDP ainsi que la VRAM qui semble absorber le flux en continu sans le moindre effort
).Pour rappel, le clipping c'est ce que tu peux voir au secondes:
0 / 2 / 4 / 6 etc.. de la vidéo ci dessous:
Nb: En ce qui me concerne, l'effet indésirable n'est pas la micro coupure du scroll mais la sorte de "Flash" qui apparaît brièvement à l'écran
En conclusion:
A moins que le BASIC soit la cause exclusive du Flash, je pense que le problème est en réalité le fonctionnement normal du VDP
Edité par
igal
Le 20/11/2018 à 18h14
en mode digitalisation le VDP travaille uniquement avec sa VRAM par le COLOR BUS
la digit est faite par des puces spécialisées dont un convertiseur Analogique Digital le V7030
il travaille en temps réel sans passer par le CPU d'ou la rapidité
le RGB est issu du V7020
la digit est faite par des puces spécialisées dont un convertiseur Analogique Digital le V7030
il travaille en temps réel sans passer par le CPU d'ou la rapidité
le RGB est issu du V7020
Moi je dis qu'il y'a des messages subliminaux cachés dans les flash, genre "edenpure"
Si il faut des circuits spécialisé pour digitaliser, pourquoi Igal arrive a le faire sans sur un 8250 par exemple ? D'ailleurs son truc fonctionne bien avec le 8280 tout intégré genlock et digitaliseur , mais quand est-il des 900 avec seulement le genlock, le digitaliseur étant externe !?
Edité par
TurboSEB
Le 21/11/2018 à 07h55
Si il faut des circuits spécialisé pour digitaliser, pourquoi Igal arrive a le faire sans sur un 8250 par exemple ? D'ailleurs son truc fonctionne bien avec le 8280 tout intégré genlock et digitaliseur , mais quand est-il des 900 avec seulement le genlock, le digitaliseur étant externe !?
Edité par
TurboSEB
Le 21/11/2018 à 07h55
MSX 1&2 + Moniteurs+divers (environ 0.70Tonnes)
Salut TurboSeb.
Je ne numérise rien du tout sur un 8250!
COPY SCREEN se contente de "Numériser" l'état des entrées [ C0 / C1 / C2 / C3 / C4 / C5 / C6 / C7 ].
En amont, si tu n'envoies pas des valeurs 0 ou 1 sur ces 8 entrées, la numérisation conséquente à la commande COPY SCREEN se résumera à une image noire ou blanche (je sais plus mais j'avais déjà essayé il me semble lol)!
J'en profite pour soulever une question très intéressante à savoir:
1) L'émulation du 8280 prend en charge l'état du COLOR BUS des VDP9938 et 9958.
2) Cela signifie que l'état 0 ou 1 des 8 entrées est statuée en continu.
En extrapolant ces deux éléments, on peut raisonnablement penser que:
Il suffit d'alimenter les 8 entrées avec les données 0 ou 1 dans l'état ou elles sont à l'instant T ou l'on lance la commande COPY SCREEN pour obtenir un résulta équivalent sur n'importe quel MSX équipé d'un VDP9938 / 9958!
Par exemple:
A) J'utilise Bluemsx en émulant un NMS8280.
B) j'affiche une image (un cercle par exemple).
C) Je lance COPY SCREEN.
D) Je saisie l'état des entrées C0 à C7 du COLOR BUS (à l'instant T ou mon COPY SCREEN s'éxécute)
E) je sauvegarde sur un média l'état 0 et 1 des entrées du COLOR BUS.
F) J'utilise n'importe quel MSX équipé d'un 9938 / 9958
G) Je relie 8 fils sur les 8 entrées du COLOR BUS du VDP9938 vers le média qui contient la sauvegarde de l'état des entrées du COLOR BUS telles qu'elles étaient sur le NMS8280 au moment de la commande COPY SCREEN.
H) Je "diffuse" l'état des 8 entrées du COLOR BUS précédemment sauvegardées sur un média.
I) Je lance COPY SCREEN
J) Je devrais voir un cercle s'afficher.
Logiquement, ces étapes permettent d'obtenir le même résulta que les circuits Genlock + digitaliseur (NMS8280) sur n'importe quel MSX2 pourvu que les Pins [C0 à C7] du VDP soient reliées à un média capable d'envoyer le flux des données sur ces 8 pins au moment voulu.
Ca reste un peu farfelu mais cela permettrait de transformer n'importe quel MSX en équivalent d'un MSX Genlock + Digitaliseur
Edité par
igal
Le 21/11/2018 à 10h54
Je ne numérise rien du tout sur un 8250!
COPY SCREEN se contente de "Numériser" l'état des entrées [ C0 / C1 / C2 / C3 / C4 / C5 / C6 / C7 ].
En amont, si tu n'envoies pas des valeurs 0 ou 1 sur ces 8 entrées, la numérisation conséquente à la commande COPY SCREEN se résumera à une image noire ou blanche (je sais plus mais j'avais déjà essayé il me semble lol)!
J'en profite pour soulever une question très intéressante à savoir:
1) L'émulation du 8280 prend en charge l'état du COLOR BUS des VDP9938 et 9958.
2) Cela signifie que l'état 0 ou 1 des 8 entrées est statuée en continu.
En extrapolant ces deux éléments, on peut raisonnablement penser que:
Il suffit d'alimenter les 8 entrées avec les données 0 ou 1 dans l'état ou elles sont à l'instant T ou l'on lance la commande COPY SCREEN pour obtenir un résulta équivalent sur n'importe quel MSX équipé d'un VDP9938 / 9958!
Par exemple:
A) J'utilise Bluemsx en émulant un NMS8280.
B) j'affiche une image (un cercle par exemple).
C) Je lance COPY SCREEN.
D) Je saisie l'état des entrées C0 à C7 du COLOR BUS (à l'instant T ou mon COPY SCREEN s'éxécute)
E) je sauvegarde sur un média l'état 0 et 1 des entrées du COLOR BUS.
F) J'utilise n'importe quel MSX équipé d'un 9938 / 9958
G) Je relie 8 fils sur les 8 entrées du COLOR BUS du VDP9938 vers le média qui contient la sauvegarde de l'état des entrées du COLOR BUS telles qu'elles étaient sur le NMS8280 au moment de la commande COPY SCREEN.
H) Je "diffuse" l'état des 8 entrées du COLOR BUS précédemment sauvegardées sur un média.
I) Je lance COPY SCREEN
J) Je devrais voir un cercle s'afficher.
Logiquement, ces étapes permettent d'obtenir le même résulta que les circuits Genlock + digitaliseur (NMS8280) sur n'importe quel MSX2 pourvu que les Pins [C0 à C7] du VDP soient reliées à un média capable d'envoyer le flux des données sur ces 8 pins au moment voulu.
Ca reste un peu farfelu mais cela permettrait de transformer n'importe quel MSX en équivalent d'un MSX Genlock + Digitaliseur
Edité par
igal
Le 21/11/2018 à 10h54
sylvain :
Salut Igal! Cela me paraît une solution bien compliquée et accessible à peu de monde. Au risque d'être un peu lourd, je reviens sur le fait qu'il faudrait peut être trouver une solution logicielle en réalisant le scrolling au moment du temps mort vertical de l'affichage VDP pour éviter cet effet de clipping
+1
Mais comme Igal ne programme qu'en BASIC, ce n'est pas envisageable ...
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 jipe.
Le scrolling couplé au vdpfp est très rapide et ne nécessite pas d'optimisation pour le moment.
Le seul problème du vdpfp est qu'il doit impérativement être ccompli sur la page visible.
En fait.. La commande copy screen se fait obligatoirement sur la page visible en basic.
Est ce que cet impératif est du au basic qui s'est limité volontairement dans ce sens ou alors est ce que le vdp est incapable de flasher sur une page "non visible" du fait de son hardware ?
Mon avis est que le problème vient du hardware mais ce n'est qu'un avis purement spéculatif.
Pour en avoir le cœur net, il faudrait faire le test de fdpfp en langage machine en forçant la commande sur la page non visible voir ce qu'il en ressort ! Edité par igal Le 21/11/2018 à 17h17
Le scrolling couplé au vdpfp est très rapide et ne nécessite pas d'optimisation pour le moment.
Le seul problème du vdpfp est qu'il doit impérativement être ccompli sur la page visible.
En fait.. La commande copy screen se fait obligatoirement sur la page visible en basic.
Est ce que cet impératif est du au basic qui s'est limité volontairement dans ce sens ou alors est ce que le vdp est incapable de flasher sur une page "non visible" du fait de son hardware ?
Mon avis est que le problème vient du hardware mais ce n'est qu'un avis purement spéculatif.
Pour en avoir le cœur net, il faudrait faire le test de fdpfp en langage machine en forçant la commande sur la page non visible voir ce qu'il en ressort ! Edité par igal Le 21/11/2018 à 17h17
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie