L'atelier VIDEO VSU-VDU les cartes video de l'extréme !!

Reprise du message précédent
Eh bien.Je pensai que 9938 et 9958 jouaient exactement le même rôle Pin à Pin avec simplement des performances différentes.
En regardant le tableau Paragraphe 6 en Page 12, on voit que certaines Pins sont différentes au niveau I/O.
En fait, si tu fait des essais sur un 9938, tu obtiendra des résultats biaisés par rapport à un 9958!
Pas sur /YS, HSYNC, CSYNC, R, G, B les signaux que je vais regarder à l'oscilloscope.
Pour la suite je vais réaliser quelques carte V9958 avec ce qu'il faut et j'aurai V9938 du 8235 et V9958 sur carte externe. Ou j'essaie de des souder le V9938, mais sans pompe à dessouder

Pour la suite je vais réaliser quelques carte V9958 avec ce qu'il faut et j'aurai V9938 du 8235 et V9958 sur carte externe. Ou j'essaie de des souder le V9938, mais sans pompe à dessouder

TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)

Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...


J'avais commencé comme ça aussi, heureusement avec de la tresse étamée haute performance qui coûte la peau des fesses mais relativement efficace pour peu que ton fer chauffe suffisamment.

Depuis que j'ai mis la main sur ma pompe, une petite encoche pour faire glisser la Pane sous la buse et c'est le nirvana
Une fois j'ai vu qu'il existe une station avec aspiration en continu. Le rêve pour désosser du MSX

Depuis que j'ai mis la main sur ma pompe, une petite encoche pour faire glisser la Pane sous la buse et c'est le nirvana

Une fois j'ai vu qu'il existe une station avec aspiration en continu. Le rêve pour désosser du MSX

Bonnes nouvelles dans la boite à lettre! 
Les 74HC32, 74HC4053, 74HC688, 74HC04, ainsi que les dip switch CMS sont arrivés!!
Ça avance doucement mais ça avance...

Manque des condos de 12 ou 15pf et j'aurai pu tester l'oscilateur 21.4778MHz avec un 74HC04....
Tient ! ça me fait penser que dans le 8235 c'est pas un quartz de 21.4778 mais 21.3281

Vous savez pourquoi?
C'est pas lié à la sous porteuse de modulation CHROMA du PAL qui est 4.43MHz parce que 4.43*6=26.58MHz
Alors que 3.58MHz est la sous porteuse CHROMA du NTSC et 3.58*6=21.48MHz (21.4778...) qui est la fréquence des VDP dans les MSX Japonais...
Si vous avez une réponse ça m'intéresse...
Edité par
z80
Le 19/06/2013 à 17h37

Les 74HC32, 74HC4053, 74HC688, 74HC04, ainsi que les dip switch CMS sont arrivés!!
Ça avance doucement mais ça avance...

Manque des condos de 12 ou 15pf et j'aurai pu tester l'oscilateur 21.4778MHz avec un 74HC04....
Tient ! ça me fait penser que dans le 8235 c'est pas un quartz de 21.4778 mais 21.3281

Vous savez pourquoi?
C'est pas lié à la sous porteuse de modulation CHROMA du PAL qui est 4.43MHz parce que 4.43*6=26.58MHz
Alors que 3.58MHz est la sous porteuse CHROMA du NTSC et 3.58*6=21.48MHz (21.4778...) qui est la fréquence des VDP dans les MSX Japonais...
Si vous avez une réponse ça m'intéresse...

TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)

Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...


Je peux pas t'apporter de réponses précisément mais je peux te dire que.
1) Un VDP interne avec une fréquence différente d'un autre VDP externe mais possédant chacun son traitement vidéo ne génère pas de parasites.
2) Un VDP Externe avec une fréquence différente d'un autre VDP Externe et partageant la partie Vidéo Commune génère des Parasite.
3) Un VDP Externe avec une fréquence Identique d'un autre VDP externe et partageant la partie vidéo Commune génère aucune parasite.
Enfin, le VDP semble fonctionner sans problème avec une fréquence approximative.
1) Un VDP interne avec une fréquence différente d'un autre VDP externe mais possédant chacun son traitement vidéo ne génère pas de parasites.
2) Un VDP Externe avec une fréquence différente d'un autre VDP Externe et partageant la partie Vidéo Commune génère des Parasite.
3) Un VDP Externe avec une fréquence Identique d'un autre VDP externe et partageant la partie vidéo Commune génère aucune parasite.
Enfin, le VDP semble fonctionner sans problème avec une fréquence approximative.
Effectivement les quartz servent a générer la fréquence "native du VDP ce qui ne les empêchent pas de tourner une fréquence en dessous ou au dessus mais la c'est de façon logiciel que ce traitement est gérée. après ce que je ne comprends pas trop c'esti si il était possible de ralentir de façon logiciel la fréquence du VDP pourquoi s’embêter a effectuer la modification hardware sauf si la durée de vie des composants risque d’être réduite.
Concernant le synchronisme des vdp c'est obligé sans ça effectivement ça risque d’être assez étrange comme résultat
.
Concernant le synchronisme des vdp c'est obligé sans ça effectivement ça risque d’être assez étrange comme résultat


galine :
Effectivement les quartz servent a générer la fréquence "native du VDP ce qui ne les empêchent pas de tourner une fréquence en dessous ou au dessus mais la c'est de façon logiciel que ce traitement est gérée. après ce que je ne comprends pas trop c'esti si il était possible de ralentir de façon logiciel la fréquence du VDP pourquoi s’embêter a effectuer la modification hardware sauf si la durée de vie des composants risque d’être réduite.
Concernant le synchronisme des vdp c'est obligé sans ça effectivement ça risque d’être assez étrange comme résultat
.
Concernant le synchronisme des vdp c'est obligé sans ça effectivement ça risque d’être assez étrange comme résultat

Il n'y a pas de variations de fréquence quand ont passe de 50 à 60Hz, juste une modification du nombre de coups d'horloge qui constitue une ligne et le nombre de ligne 525 en NTSC et 625 en PAL.
La seule explication que j'ai dans l'immédiat c'est qu'on s'écarter légèrement des timing vidéos sans trop s'en éloigner...
Et le Z80 ne tournera pas pil poil à 3.58MHz.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)

Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...

Premiers essai d'observation de la synchro sur un V9938.
en jaune: /HSYNC, en rouge: /YS (>0V alors affiche VDP)
COLOR15,0,0:SCREEN5:LINE(0,0)-(255,255),15,bf:VDP(10)=&h02'(valeur par défaut S1=0 S0=0)

On peut noter que:
/HSYNC (trace jaune) fait un front descendant à chaque ligne avec une période ou il reste à l'état haut (fin/début d'image)
page 131 de la doc du V9938 (page 142 du PDF) dernière ligne de la page.
COLOR15,0,0:SCREEN5:LINE(0,0)-(255,255),15,bf:VDP(10)=&h12'(S1=0 S0=1)

On peut noter que:
/HSYNC (trace jaune) fait un front montant à chaque ligne avec une période ou il y a des fronts plus raprochés (fin/début d'image)
page 131 de la doc du V9938 (page 142 du PDF) avant dernière ligne de la page.
une vue zoomée

On voit qu'entre le groupe de fronts rapides et le debut de monté du signal /YS, on peut noter qu'il s'écoule un certain nombre de lignes.
j'en ai compté63 54 avec un setadjust (0,0) et 56 47 avec un setadjust(0,-7).
On zoom un peut plus:

On peut voir un temps de 6.4µs entre la fin du top ligne (front descendant du jaune) et la commutation de /YS (front montant du rouge). Curseur violet sur l'image...
C'est le temps entre la fin du top synchro ligne et le début du signal vidéo (R, G, B, ou composite) voir page 128 de la doc du V9938 (page 139 du PDF) avant dernier signal de la page Edité par z80 Le 23/06/2013 à 17h52
en jaune: /HSYNC, en rouge: /YS (>0V alors affiche VDP)
COLOR15,0,0:SCREEN5:LINE(0,0)-(255,255),15,bf:VDP(10)=&h02'(valeur par défaut S1=0 S0=0)

On peut noter que:
/HSYNC (trace jaune) fait un front descendant à chaque ligne avec une période ou il reste à l'état haut (fin/début d'image)
page 131 de la doc du V9938 (page 142 du PDF) dernière ligne de la page.
COLOR15,0,0:SCREEN5:LINE(0,0)-(255,255),15,bf:VDP(10)=&h12'(S1=0 S0=1)

On peut noter que:
/HSYNC (trace jaune) fait un front montant à chaque ligne avec une période ou il y a des fronts plus raprochés (fin/début d'image)
page 131 de la doc du V9938 (page 142 du PDF) avant dernière ligne de la page.
une vue zoomée

On voit qu'entre le groupe de fronts rapides et le debut de monté du signal /YS, on peut noter qu'il s'écoule un certain nombre de lignes.
j'en ai compté
On zoom un peut plus:

On peut voir un temps de 6.4µs entre la fin du top ligne (front descendant du jaune) et la commutation de /YS (front montant du rouge). Curseur violet sur l'image...
C'est le temps entre la fin du top synchro ligne et le début du signal vidéo (R, G, B, ou composite) voir page 128 de la doc du V9938 (page 139 du PDF) avant dernier signal de la page Edité par z80 Le 23/06/2013 à 17h52
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)

Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...


z80 :
On voit qu'entre le groupe de fronts rapides et le debut de monté du signal /YS, on peut noter qu'il s'écoule un certain nombre de lignes.
j'en ai compté 63 avec un setadjust (0,0) et 56 avec un setadjust(0,-7).
On voit qu'entre le groupe de fronts rapides et le debut de monté du signal /YS, on peut noter qu'il s'écoule un certain nombre de lignes.
j'en ai compté 63 avec un setadjust (0,0) et 56 avec un setadjust(0,-7).
Ca fait très plaisir de voir interprété des choses auxquels on comprend pas tout.

Je dois dire que lorsque j'ai stabilisé (accidentellement) la synchro du 8280 par le Software, j'ai pensé à la possible influence de SET ADJUST sur l'ensemble des deux programmes qui se suivent. ici => http://www.msxvillage.fr/forum/topic.php?id=1866#m41803
en attendant, dans mon cas ça reste de la spéculation

Edit: D'ailleurs on peut très bien envisager un réglage fin entre les différents VDP par le SET ADJUST...(reste à savoir comment lol) Edité par igal Le 23/06/2013 à 14h51

@Z80 : La page suivante pourrait t'être également utile : http://openmsx.sourceforge.net/vdp-vram-timing/vdp-timing.html
Lors de la Nijmegen 2013, certains ont en effet entrepris d'enregistrer les différents signaux du/des VDP(s).
Tu peux éventuellement joindre Wouter Vermaelen ( vermaelen [dot] wouter @robase gmail [dot] com) afin de récupérer les données enregistrées.
EDIT :
Les données recueillies semblent disponibles à cette adresse : http://sourceforge.net/mailarchive/message.php?msg_id=30375119
et le lien direct est : http://damad.be/joost/nijmegen2013_VDP_timing_measurements.zip Edité par SveN Le 23/06/2013 à 16h34
Lors de la Nijmegen 2013, certains ont en effet entrepris d'enregistrer les différents signaux du/des VDP(s).
Tu peux éventuellement joindre Wouter Vermaelen ( vermaelen [dot] wouter @robase gmail [dot] com) afin de récupérer les données enregistrées.
EDIT :
Les données recueillies semblent disponibles à cette adresse : http://sourceforge.net/mailarchive/message.php?msg_id=30375119
et le lien direct est : http://damad.be/joost/nijmegen2013_VDP_timing_measurements.zip Edité par SveN Le 23/06/2013 à 16h34
Philips.NMS.8245/50/80, Sony.F1XV/HBF-700D, Pana.FSA1FX/A1WX(x2)/A1GT, OCM, GR8BIT.... et ...
Autre programme de test:

Ça donne:

Vu d'ensemble:

Je vais chercher la clé USB sur l'oscilloscope...
Cette fois ci signal jaune /HSYNC et le rouge, composante B du RGB.

On peut noter trois niveaux différent sur la voie rouge, un niveau de suppression "noir", un seuil qui correspond à la composante bleu de la couleur N°2 de la palette par défaut du MSX2 (color 2 c'est du vert, voir photo de l'écran ci-dessus).
Le niveau le plus haut correspond au niveau maxi puisque c'est le niveau de bleu utilisé pour la couleur blanche (color 15)
Le deux curseurs violet c'est donc le temps d'affichage utile de X=0 à X=255 soit 48µs. Edité par z80 Le 23/06/2013 à 17h15

Ça donne:

Vu d'ensemble:

Je vais chercher la clé USB sur l'oscilloscope...
Cette fois ci signal jaune /HSYNC et le rouge, composante B du RGB.

On peut noter trois niveaux différent sur la voie rouge, un niveau de suppression "noir", un seuil qui correspond à la composante bleu de la couleur N°2 de la palette par défaut du MSX2 (color 2 c'est du vert, voir photo de l'écran ci-dessus).
Le niveau le plus haut correspond au niveau maxi puisque c'est le niveau de bleu utilisé pour la couleur blanche (color 15)
Le deux curseurs violet c'est donc le temps d'affichage utile de X=0 à X=255 soit 48µs. Edité par z80 Le 23/06/2013 à 17h15
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)

Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...

SveN :
@Z80 : La page suivante pourrait t'être également utile : http://openmsx.sourceforge.net/vdp-vram-timing/vdp-timing.html
Lors de la Nijmegen 2013, certains ont en effet entrepris d'enregistrer les différents signaux du/des VDP(s).
Tu peux éventuellement joindre Wouter Vermaelen ( vermaelen [dot] wouter @robase gmail [dot] com) afin de récupérer les données enregistrées.
EDIT :
Les données recueillies semblent disponibles à cette adresse : http://sourceforge.net/mailarchive/message.php?msg_id=30375119
et le lien direct est : http://damad.be/joost/nijmegen2013_VDP_timing_measurements.zip
Lors de la Nijmegen 2013, certains ont en effet entrepris d'enregistrer les différents signaux du/des VDP(s).
Tu peux éventuellement joindre Wouter Vermaelen ( vermaelen [dot] wouter @robase gmail [dot] com) afin de récupérer les données enregistrées.
EDIT :
Les données recueillies semblent disponibles à cette adresse : http://sourceforge.net/mailarchive/message.php?msg_id=30375119
et le lien direct est : http://damad.be/joost/nijmegen2013_VDP_timing_measurements.zip
COPIER/COLLER intéressant de ce quej'avais déjà lu mais je ne savais plus trop ou

Citation :
Edité par
z80
Le 23/06/2013 à 17h54
Horizontal line timing
The VDP renders a full frame line-by-line. For each line the VDP (possibly) has to read some bitmap and sprite data from VRAM. It's logical to assume (and the measurements confirm this) that the data fetches within one line occur at the same relative positions as the corresponding data fetches of another line. So if we can figure out the details for one line, we can extrapolate this to a whole frame. Similarly we can assume that different frames will have similar relative timings. So really all we need to know is the timing of one line.
TODO: odd and even frames in interlace mode probably do have timing differences. Still need to investigate this.
Let's thus first look at what we already know about an horizontal display line. The 'V9938 Technical Data Book' contains the following timing info about (non-text mode) display lines.
Description Cycles Length
Synchronize signal [0 - 100) 100
Left erase time [100 - 202) 102
Left border [202 - 258) 56
Display cycle [258 - 1282) 1024
Right border [1282 - 1341) 59
Right erase time [1341 - 1368) 27
Total [0 - 1368) 1368
So one display line is divided in 6 periods. The total length of one line is 1368 cycles. The previous section showed how long individual VRAM accesses take. The next sections will figure out how all the required accesses fit in this per-line budget of 1368 cycles.
.......
TODO horizontal set-adjust: The numbers in the above table are valid for horizontal set-adjust=0. Similarly all our measurements were done with set-adjust=0. Using different set-adjust values will make the left/right border bigger/smaller. I still need to figure out which timing values of the next sections are changed by this. E.g. are all the VRAM accesses in a line shifted as a whole, or are just the bitmap data fetches shifted and remain (some) other accesses fixed?
TODO bits S1,S0 in VDP register R#9: The above table is valid for S1,S0=0,0. In other cases the length of a display line is only 1365 cycles instead of 1368. The rest of this text assumes a line length of 1368 cycles. I still need to figure out where exactly in the line this difference of 3 cycles is located.
The VDP renders a full frame line-by-line. For each line the VDP (possibly) has to read some bitmap and sprite data from VRAM. It's logical to assume (and the measurements confirm this) that the data fetches within one line occur at the same relative positions as the corresponding data fetches of another line. So if we can figure out the details for one line, we can extrapolate this to a whole frame. Similarly we can assume that different frames will have similar relative timings. So really all we need to know is the timing of one line.
TODO: odd and even frames in interlace mode probably do have timing differences. Still need to investigate this.
Let's thus first look at what we already know about an horizontal display line. The 'V9938 Technical Data Book' contains the following timing info about (non-text mode) display lines.
Description Cycles Length
Synchronize signal [0 - 100) 100
Left erase time [100 - 202) 102
Left border [202 - 258) 56
Display cycle [258 - 1282) 1024
Right border [1282 - 1341) 59
Right erase time [1341 - 1368) 27
Total [0 - 1368) 1368
So one display line is divided in 6 periods. The total length of one line is 1368 cycles. The previous section showed how long individual VRAM accesses take. The next sections will figure out how all the required accesses fit in this per-line budget of 1368 cycles.
.......
TODO horizontal set-adjust: The numbers in the above table are valid for horizontal set-adjust=0. Similarly all our measurements were done with set-adjust=0. Using different set-adjust values will make the left/right border bigger/smaller. I still need to figure out which timing values of the next sections are changed by this. E.g. are all the VRAM accesses in a line shifted as a whole, or are just the bitmap data fetches shifted and remain (some) other accesses fixed?
TODO bits S1,S0 in VDP register R#9: The above table is valid for S1,S0=0,0. In other cases the length of a display line is only 1365 cycles instead of 1368. The rest of this text assumes a line length of 1368 cycles. I still need to figure out where exactly in the line this difference of 3 cycles is located.
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)

Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...

suite des mesures:
avec SETADJUST(0,0)

2,6µs de couleur de bordure
[EDIT]
Ça recoupe plutôt bien avec les informations de la doc du V9938:
avec le quartz du 8235 qui fait 21.32812MHz
56 x 1/21,32812.10E-6 = 2.6256µs
[/EDIT]
avec SETADJUST(-7,0)

1,3µs de couleur de bordure Edité par z80 Le 23/06/2013 à 22h45
avec SETADJUST(0,0)

2,6µs de couleur de bordure
[EDIT]
Ça recoupe plutôt bien avec les informations de la doc du V9938:
Citation :
Left border [202 - 258) 56
avec le quartz du 8235 qui fait 21.32812MHz
56 x 1/21,32812.10E-6 = 2.6256µs
[/EDIT]
avec SETADJUST(-7,0)

1,3µs de couleur de bordure Edité par z80 Le 23/06/2013 à 22h45
TurboR GT (1Mo), CANON V20! ( en kit, modif 2+ en cours)

Pas encore retrouvés: V9990, Grafx9000, SUNRISE IDE 2x CF, SUNRISE MOONSOUND, FM PAC, MUSIC MODULE, NMS8280, SD SNATCHER,...


J'ai peut être pas tout compris mais...
L'image est générée Horizontalement Ligne après ligne de Haut en Bas.
A partir de là, Les deux colonnes Blanches sur Fond Vert ne seraient pas mieux placées à l'horizontal?
Cela donnerait des résultats plus contrastés non?
(Je dis peut être des bêtises, mais ça me semble logique comme raisonnement
)
Edité par
igal
Le 24/06/2013 à 13h31
L'image est générée Horizontalement Ligne après ligne de Haut en Bas.
A partir de là, Les deux colonnes Blanches sur Fond Vert ne seraient pas mieux placées à l'horizontal?
Cela donnerait des résultats plus contrastés non?
(Je dis peut être des bêtises, mais ça me semble logique comme raisonnement

Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie