[MZ-700 ou autre] Color blending - Soft ou Hard ?

Placez ici vos trucs et astuces, étalez sans retenue votre savoir-faire et votre science qui va nous permettre de redonner une apparence neuve et fonctionnelle à nos bouzes.

Modérateurs : Papy.G, fneck, Carl

Répondre
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

[MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

Ok, ce fil est particulier car à la fois il retrace une expérience de "color blending" sous logiciel et pose la question de comment l'obtenir via un matériel dédié.

Dans le cadre du jeu BrickBuster, j'utilise la technique du "color blending" à 1 niveau ou plus pour créer des effets de lueur (glowing) sur la raquette et les éclairs. Si vous souhaitez savoir ce qu'est à la base le "color blending" dont je parle, lisez ceci qui est pour des jeux du C64.

Pour faire court, j'alterne la couleur par trame (50 par secondes) pour donner une illusion de nouvelle couleur (ABABABAB...) ou de transition entre deux couleurs (AAAAAAAA-AABAAABA-ABABABAB-BBBBBBBB). Sauf que ça ne marche pas superbement avec des trames de 50 Hz sur un écran de 60 Hz et les chances d'avoir un CRT fonctionnel diminue avec le temps, il faudrait bien trouver une solution pour les écrans modernes.

Ce n'est qu'après avoir lu cet article que j'ai voulu avoir le cœur net pour comprendre pourquoi le "color blending" ne fonctionnait pas avec BrickBuster.

Pour y parvenir, j'ai fais trois essais avec l'émulateur EmuZ-700 :
1) émulateur NTSC, 60 Hz sur écran 60 Hz. En bas à gauche de l'écran sur la première vidéo. Presque parfait avec cependant un décrochage toutes les dizaines de secondes et le scintillement plus visibles sur les couleurs alternées à la luminosité diamétralement opposée (que l'on ne voit pas vraiment sur la vidéo).
2) émulateur PAL, 50 Hz sur écran 60 Hz. En bas à droite de l'écran. Bouillis. Même effet constaté sur BrickBuster.
3) émulateur PAL que j'ai traficoté pour que chaque pixel de la trame suivante contienne la moyenne de la nouvelle couleur du pixel (depuis VRAM) et la couleur du pixel de la trame précédente, 50 Hz sur écran 60 Hz. Aucun scintillement et de nouvelles couleurs stables sur l'écran 60 Hz.

Première vidéo :


Pour rendre un peu mieux des couleurs quoique plus saturées, j'ai fait une deuxième vidéo :


Le point 3) m'a permis accessoirement de vérifier que je dessinais un écran plein (1000 caractères + 1000 attributs de couleur) par trame (200 lignes car 10 octets par ligne) et bien 50 trames par secondes vu que les couleurs mixes étaient stables (si par exemple la trame était plus longue que la période de vsync, le mixage se ferait avec la même couleur de base).

Donc il appert que les écrans modernes n'ont pas fini de nous casser l'ambiance.

Et je me pose la question de ce qu'il faudrait faire en hard pour obtenir un "color blending" fonctionnel sur n'importe écran moderne sans trop se préoccuper de la fréquence.

Et c'est là que je requiers les conseils de nos amis "hardeux" qui auront certainement l'hardeur de me conseiller !

Le must serait de pouvoir capturer le signal RGB sur la DIN ou directement sur le connecteur pour traiter les signaux et le repasser à la péritel.

A vue de nez, on aurait besoin d'enregistrer en mémoire chaque signal RGB faisant 0 ou 1 pour chaque pixel avec une adresse incrémentée, de la /VSYNC pour signaler une nouvelle trame et donc remettre à 0 l'adresse. Pour sortir le signal RGB modifié, on prendrait en compte le signal RGB en entrée et l'enregistrement du signal RGB au même emplacement de la trame précédente pour en faire une moyenne qui donnerait une tension par composant RGB.

Maintenant comment peut-on réaliser cela sous forme électronique ?

P.S.: on pourrait aussi étendre à deux niveaux en ajoutant une moyenne entre deux paires de trames consécutives pour obtenir plus de niveau de couleur mais c'est une autre histoire.

@
Dernière modification par hlide le 20 juin 2020 14:52, modifié 2 fois.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

J'ai oublié de mettre le lien du "color switching" sur C64. C'est réparé.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

Voici le schéma de la sortie vidéo du MZ-700 :
colorblending-mz-700.jpg
colorblending-mz-700.jpg (531.59 Kio) Consulté 2998 fois
Dans mon cas, je récupère actuellement R, G, B et CVIDEO pour les fournir à la prise Péritel.

J'ai entouré les signaux d'une couleur ceux qui peuvent entrer en jeu.

- LOAD (1,108404688 MHz) : c'est le signal qui permet d'entrer une nouvelle couleur de pixel et peut donc servir à incrémenter l'adresse de pixel à sauvegarder. Il est fourni par le LSI (un ASIC).
- /VSYNC : c'est le signal de passage à la trame suivante. pourrait servir de remise à zéro de l'adresse du pixel.
- G, R, B : ce sont les signaux RGB qui sont à 0 ou 1.

Apparemment, il faudrait en nombre de bit par composant RGB : 21 Kibit < 1.108404688 MHz / 50,0363 Hz < 22 Kibit. Si on multiplie par 8 (3 bits pour R, G et B et 5 autres ignorés), ça nous donnerait un 256 Kibit minimum, soit 32 Kio de RAM pour les stocker. Si je ne me suis pas trompé dans les calculs.

Il nous faudrait donc un compteur 15-bit avec clock (LOAD) et reset (/VSYNC) qui servirait d'adresse à la RAM.

A l'incrément de l'adresse, il faut d'abord lire les bits R, G et B de la RAM puis écrire les nouveaux. Sur les sorties, on s'arrange pour fournir des tensions sur R, G et B qui prennent en compte une moyenne entre les anciennes lues et les nouvelles. Un buffer devrait enregistrer les signaux /HSYNC, /VSYNC, /CSYNC et CVIDEO pour faire synchroniser tous ces signaux avec le RGB en sortie.

Il y a surement des failles dans ce que je propose.
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par gilles »

le color blending et le changement de fréquence c'est toujours un casse tête.
Idealement il faut simuler un peu de rémanence sur l'image à 50Hz (garder les N dernières trames et appliquer une transparence croissante) et ensuite utiliser un schéma de conversion 50 vers 60hz (en doublant certaines trames ou mieux en calculant des trames manquantes pour que ce soit moins saccadé si mouvement).
Dans tous les cas c'est forcement complexe et imparfait.
pour une image statique la moyenne marche presque mieux mais va sans doute poser problème pour une image animée (images fantômes avec la même intensité comme sur les premiers LCD).
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

J'ai fait quelques essais de plusieurs jeux et démo sur l'émulateur qui fait la moyenne à un niveau et à ma surprise, je n'ai pas ressenti de gène ou d'impression d'images fantômes. Mais je prévoyais en effet de pouvoir activer ou désactiver cet effet avec un senseur tactile sur la coque de la même manière que j'ai fait pour l'échanger de CGROM européen/japonais. En revanche, la conversion 50 Hz -> 60 Hz, je laisse faire l'écran moderne. La moyenne à un niveau suffit à faire disparaître le scintillement si l'on se contente d'un schéma ABAB à répétition (par contre un AABA à répétition n'empêchera pas le scintillement entre AA et BA). Il y a un jeu qui a des sortes de cerises qui fait un cycle répété (ou aléatoire) de couleur et effectivement c'est moins violent avec la moyenne (ce que je préfère). Sur BrickBuster dont le principe est quand même de tourner à 50 trames par secondes, il y a effectivement la balle qui a des traces fantômes mais elle le faisait déjà sans la moyenne. Et comme sa vitesse sera divisée par deux (car elle est trop rapide), ça devrait estomper les effets fantômes. En revanche les blocs éclairs sont du plus bel effet grâce à la moyenne.

Pour en revenir à l'électronique, je pensais combiner les deux couleurs de base de la façon suivante :

Code : Tout sélectionner

R/G/B précédent | R/G/B nouveau | R/G/B résultat
----------------+---------------+---------------
              0 |             0 |             00
              1 |             0 |             10 *
              0 |             1 |             10 *
              1 |             1 |             11

* un choix doit être fait entre 01 (plus sombre) ou 10 (plus clair)
  mais il doit rester le même quand le ou exclusif des deux entrées donne 1.
Et le résultat est ensuite converti en analogique :
RGB_DAC.png
RGB_DAC.png (4.17 Kio) Consulté 2970 fois
Mais je présume que si les résistance R5 et R6 étaient les mêmes, on pourrait alors directement passer par les deux entrées et obtenir une vraie moyenne sans devoir passer par un LUT (du type PAL/GAL).

La partie la plus floue en ce qui me concerne, c'est la mémorisation et la restitution de la couleur dans ce circuit où j'aurais besoin de quelques conseils.
Avatar de l’utilisateur
gilles
Messages : 2779
Inscription : 07 août 2008 13:44
Localisation : Nantes
Contact :

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par gilles »

pour la réalisation le plus simple sera de passer par un FPGA ou un CPLD (au moins pour la mise au point). Il va y avoir pas mal de difficultés parcequ'un signal video est imparfait, il vaut mieux utiliser un seul top de Hsync et l'horloge systeme et compter les cycles avec précision et ensuite être certain de mémoriser la valeur stabilisée (donc lue au milieu d'un cycle, il faut alors une horloge au moins double de celle de la video).

Une autre approche possible, si la valeur de l'octet affiché (ou à minima l'écriture vram et registres video) à l'écran passe par le bus est de recréer from scratch une carte video (on trouve ce genre d'approche sur des cartes vga spectrum par exemple).
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

L'autre approche par le bus d'extension serait encore plus compliqué :

1) l'accès à la VRAM peut être verrouillé pour laisser place à de la DRAM ou à un autre mapping. Certes on peut surveiller les écritures de port E/S qui change le mapping mais là on commence à sortir du cadre de la vidéo. En d'autre terme, simplement surveiller un accès lecture/écriture à une adresse supossé VRAM ne suffit pas. Le LSI ne permet pas non plus de récupérer sous forme de signaux le mapping choisi parce que ces derniers restent internes au LSI.

2) le bus ne donne pas les signaux vidéo (/VSYNC et /HSYNC) or certains programmes ont besoin de se synchroniser par rapport au deux (le /WAIT du CPU est connecté au BLNK - inverse du /HBLK quand on adresse la VRAM et donc on peut se retrouver à attendre jusqu'à 137 µs si on n'y prend pas garde !) et le circuit vidéo alternatif peut se trouver de fait désynchronisé et ne pas donner le résultat escompté - chose que j'ai pu vérifié avec la sortie VGA de l'Unicard Mk3B et m'a incité à revenir sur la sortie RGB d'origine.

3) j'aurais besoin de simuler la composition des couleurs mais aussi des caractères avec un GCROM qui ne pourra pas être lu depuis l'original. On sort réellement du cadre souhaité de ne modifier que les couleurs par pixel indépendamment des caractères. Ça commence à devenir une grosse usine à gaz.

Ces points mis ensembles sont donc rédhibitoires dans la mesure où je ne voudrais pas sortir du but recherché de la plupart de mes projets : moins de composants possibles, des trucs qui ne coûtent pas plusieurs centaines d'euros et ne pas se retrouver à ajouter des fonctionnalités non souhaitées.

Même si on modifie l'approche en allant choper une partie des signaux sur la carte mère (et là je renvoie au schéma que j'ai posté précédemment), je pourrais en effet capturer le signal /CS de la VRAM attributs - et donc, guetter une écriture physique dans cette VRAM pour éviter le problème du point 1), il reste les autres points.

En fait, je peux encore modifier l'approche en zappant le bus d'expansion : l'affichage couleur ne se sert que de la première moitié de la VRAM attribut. Il serait tentant de mettre une VRAM en parallèle.
- A l'écriture, les données seraient enregistrées dans les deux VRAM à un détail près : la VRAM alternative aurait un A10 alterné par trame (l'original aura toujours A10 à 0 pour l'affichage), donc piloté par une bascule enclenchée par /VSYNC.
- A la lecture, les données seraient lues séparément. Entre les deux VRAM on met un buffer des diodes (et peut-être associée une résistance) sur le bus de données. L'objectif, c'est d'éviter qu'une lecture de la VRAM d'origine aille piquer l'autre VRAM. J'ai encore un doute quand le circuit alternatif va lire la VRAM alternative : est-ce que les "diodes" auront un effet de résistance pour que le circuit alternatif n'aille lire que sur la VRAM alternative. A noter que A10 doit être l'inverse de la bascule enclenchée par /VSYNC durant la lecture pour accéder l'attribut de la trame précédente.

Voici le schéma modifié en conséquence :
colorblending-mz-700-2.png
colorblending-mz-700-2.png (960.03 Kio) Consulté 2940 fois
Dernière modification par hlide le 21 juin 2020 16:32, modifié 2 fois.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

Ou alors je remplace le buffer de diode par un autre buffer unilatérale qui met à jour sa sortie sur un /WE = 0 et GT2 = 0. De cette façon, la lecture des VRAM devrait être réellement séparée.

Mais moi qui voulait éviter de piquer trop sur la carte mère :(.
Avatar de l’utilisateur
Papy.G
Modérateur
Messages : 3047
Inscription : 10 juin 2014 13:40
Localisation : Haute-Garonne/Gers

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par Papy.G »

Pour mélanger la page courante avec la précédente, il va peut-être falloir doubler la mémoire, à moins de trouver un moyen de "swapper" un registre et un octet en mémoire dans la même opération (trouver un proc. ou core de µC qui sache le faire).
Je pense qu'au vu des moyens techniques à déployer, autant partir sur une modif interne sortant directement vers HDMI.

Plus simplement, le mode vidéo de cette machine ne peut-il être forcé en 60Hz?
Bien sûr, ça limite aux télés sachant identifier et traiter intelligemment le 240p, mais c'est déjà un début.

Des adaptateurs comme l'OSSC ou Framemeister ne proposent-ils pas des modes permettant le "blending temporel"? A voir, si le matériel le permet, si cette possibilité peut être ajoutée au firmware?
Soyez exigeants, ne vous contentez pas de ce que l'on vous vend.
Demandez-en plus, ou faites-le vous-même.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

Si on parle de la méthode externe (on récupère les signaux RGB TTL et synchro), oui il faudra une RAM pour contenir tous les pixels (ou au moins qui sont ceux visibles). Je parlais du signal LOAD présent sur la carte-mère qui permet de changer le pixel :

Code : Tout sélectionner

Pixel	PAL	NTSC
HDISP	320	320
HBLANK	248	136
HTOTAL	568	456
VDISP	200	200
VBLANK	112	62
VTOTAL	312	262
Si l'on tient pas compte de la visibilité du pixel, il faudrait a minima par composant RGB, 568 x 312 = 177216 bits à mémoriser. Vu qu'il y a trois composant, ça fait donc une RAM de 256 Kib x 8 (je doute que l'on puisse trouver du x 4 de nos jours), soit 2 Mio. Si on prend en compte le HBLANK et le VBLANK pour réduire le nombre de pixel à enregistrer, on a 320x200 = 64000 bits, soit une RAM de 64 Kib x 8 ou 512 Ko. C'est beaucoup avec pas mal de gâchis. Si on prend un PSoC5LP, il faudrait 196 Ko or je crois qu'il n'en a que 32 Ko.

Si on parle de la méthode interne (circuit vidéo alternatif avec moyenne en sortie), c'est effectivement rajouter en parallèle une SRAM de même capacité comme indiquée dans le dernier schéma. La SRAM d'origine n'utilise que la première moitié des 2 Ko pour l'affichage. La seconde moitié ne sera jamais affichée et pourrait être utilisé comme une mémoire de donnée ou code supplémentaire à la disposition du CPU sauf que c'est une très mauvaise idée de le faire à cause de la restriction d'accès lié au signal BLANK.

Donc en rajoutant une SRAM de même capacité, on a :
- la possibilité de stocker dans une moitié les mêmes attributs écrits par le CPU.
- la possibilité de lire dans l'autre moitié les attributs à fournir au circuit vidéo alternatif.
- la bascule sur le signal de /VBLANK qui donnera la moitié à lire/écrire.

Le circuit vidéo alternatif reprend en doublon le minimum nécessaire de composants présents dans le circuit vidéo d'origine. Au total, aux sorties des circuits vidéos on mixe les composants RGB.

Seul bémol : la nécessité de repiquer nombre des signaux sur la carte-mère sachant que :
- il y a le clavier au-dessus qui ne donne pas beaucoup de place,
- il n'y a pas de socle sous la VRAM d'origine.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

Et sinon j'ai déjà un boitier qui converti du RGBS en HDMI. L'essentiel, c'est d'arriver à faire une solution qui ne fasse pas 100 € et qui ne t'oblige pas à passer à du HDMI.
Avatar de l’utilisateur
hlide
Messages : 3469
Inscription : 29 nov. 2017 10:23

Re: [MZ-700 ou autre] Color blending - Soft ou Hard ?

Message par hlide »

Je ne me suis rendu compte que je n'avais pas dû essayer avec le boitier SCART>HDMI. Le résultat est très stable (j'ai choisi FullHD 50 Hz mais ça semble marcher pour n'importe quelle résolution et fréquence) mais pas exactement celui escompté :
IMG_20200627_125918bis.jpg
IMG_20200627_125918bis.jpg (450.25 Kio) Consulté 2854 fois
Répondre