Glitch graphique : vertical shrink

Bonjour à tous,

Comme indiqué sur le sujet de présentation (merci de l'accueil au passage ! ), c'est un glitch graphique pour lequel je ne trouve pas de solution qui m'a amené ici.
J'ai une neo geo AES jap, modèle AES 3,5.
A priori tout fonctionne bien en jeu. Sauf que j'ai relevé un problème très spécifique : le dé-zoom ou shrink(de grand vers petit) et uniquement vertical ne fonctionne pas.
Je l'ai constaté sur deux jeux :
- à la fin de chaque niveau de metal slug 1, quand il y a les scores et que le metal slug est comptabilisé au dessus du comptage des prisonniers libérés.
- sur super sidekicks 2 lors des pénaltys, le balon une fois tiré rétrécit bien en largeur mais pas en hauteur).

C'est un détail, mais le diable est dans les détails et tels un pixel mort sur un LCD, ce bug m'obsède!
Comprenez moi, j'ai réalisé un rêve de gosse avec cet achat en juillet, et j'étais déjà tellement soulagé d'avoir réparé le son ! Mais là ... c'est le drame...

Bref, de mes recherches (neo geo dev principalement), j'en ai conclu a priori qu'il pouvait y avoir 2 origines :
- en vram, sur le SCB2 qui reçoit et stocke sur un octet le coefficient de shrink.
- sur la table de correspondance de shrink de la LO ROM.

Sur le point 1 j'en doute, car c'est le même octet qui détermine le shrink horizontal or celui-ci fonctionne sans problème.
En outre, le lancement sans cartouche teste la VRAM si je ne m'abuse et j'ai bien un écran bleu RAS.

Sur le point 2, j'ai observé les traces autour du LO ROM et a priori rien de suspect. Après je n'arrive pas à toutes les suivre (certaines partent sur le chipset graphique LSPC2 et là ça se complique : beaucoup de pattes et toutes petites).

Quelqu'un a-t-il déjà rencontré ce problème ? Quels chipsets et pinouts utiliser pour le test de continuité ?
La cause pourrait-elle être toute autre ?

Dernières précisions : j'ai suspecté d'abord un problème d'alim' et testé 3 différentes, jusqu'à 5A, le problème est ailleurs. Enfin, il ne sagit pas d'un problème de scaling lié à un converter car ce sont bien des jeux AES (Metal slug est un convert bien sûr mais Super Sidekicks2 est un original).

Merci d'avance pour votre aide !!

1er truc nettoyage port cartouche.2eme truc les pcb mères ont des problèmes de vernis qui se décollent et enmennent les piste avec.
Ou de la  corrosion qui efface les piste de contact avec les années.
Ça depend ou ta console a étée stockée.

Donc écran bleu veut dire que tes puces répondent bien après si il y a des traces effacées c'est du travail a la loupe.ça peut aussi venir des puces graphique carré .

T'as une video ou pvoto pour localiser ton problème?

Merci pour la réponse. Le nettoyage du port c'était fait mais rien de neuf. La pcb m'a l'air clean.
J'ai une photo du verso quand j'avais ponté pour le son. La voici.
https://goo.gl/photos/5oydQit3DSPwWkPm6m

C'est 90% de chance que des pistes sont rompus cherche pas c'est ça car c'est la maladie de ces generation de pcb elle sont pas fabriquées en salle blanche et les prises et ports manettes sont soudés a la main et sans gants.

Bugs graphiques=problème d'adressage.c'est a la loupe et plus de 3h ou 5h de recherche c'est très long a trouver parfois mais ta console a des pistes coupées c'est sur vu les défauts que tu dit.

Salut,


Oui je rejoins Kategohi ,


Les test VRAM sont OK donc elles sont normalement bonnes.

c'est une piste rompue ou soudure sèche.

Si tes sprites "a taille normal" sont affichés correctement :
c'est que les données provenant de la cartouche sont bien traités par le chip graphique , le LSPC2-A2

donc comme Kategohi cherche entre les VRAM et le LSPC2-A2
il faut tester les piste une a une !
pour les suivre aide toi du shéma fourni sur neogeo dev wiki.

Ok, merci bien à vous deux. Avant de me lancer dedans, une petite remarque supplémentaire. Je viens de tester super sidekicks 3 (soit la suite de celui testé plus haut). Il utilise exactement le même système de penaltys avec zoom balon. Mais ici aucun bug, tout marche! Du coup la piste de la trace coupée est elle d'actualité toujours?

ha ...  oui là c'est étrange

je viens de regarder vite fait neogeo dev :
j'ai l'impression que la VRAM ne contient pas les données 'data' des sprites uniquement leurs réferences, position écran, palette, zoom etc...
pour que le LSPC2-A2 puisse travailler et afficher l'image.

Les 'data' sprites viennent de la C-ROM
voir graphic pipeline
https://wiki.neogeodev.org/index.php?title=Graphics_pipeline
donc ca passe par le NEO-B1 qui démultiplexe les données sprites.

je commencerais par là pour tester les pistes.


Kategohi t'en pense quoi ?

Il doivent pas utiliser le même codage sur le sidekick 3
Moi je suis partis sur le b-1 aussi philhp.


Ce genre de merde a aussi un problème de pattes qui se touchent aussi.
Piste coupées ou pattes qui se touchent vers les puces graphiques ou les rams ily a des infos qui se perdent ou qui rentrent en conflis.

Multimètre en mode continuité ou bip, un schèma ,faire le dessin papier et au boulot
Tu peux aussi faire des prises de photo avec agrandissement (smartphone).

Sinon pour localiser philhp est plus au courrant des communications hardware que moi.

Ok! Atelier multimètre sur le néo b1 cet aprem' donc! Je vous dirai. Merci!

En plus faut pas oublier que des pistes oxydées (pourries) sont sous le vernis des fois et ça se voit pas(technique sêche cheuveux et unibios pour faire la pause sur le bug)
Y a que le multimètre qui te dira.


Cette megadrive écran noir completement hs a cause d'un gars qui a mis sont pouce(sans gants) vers la puce graphique avant que la puce et le vernis soit posés.

20 ans après ça a tout nické j'ai jamais vu ça a partir de la 5eme generation car les techniques manuelles ont étaient supprimées,malheureusement la neo geo est comme la mégadrive fabriquée artisanalement et comme ça sans salle blanche surement et des manipulations manuelles.

Tu peux tester le décapage des puces comme j'ai fais sur une de mes neo geo.
Regarde la partie tuto du forum. J'ai créé un sujet sur ça justement qui a réglé mon soucis.

Salut,

Idéalement il faut refaire les soudures de tous les IC avec du flux par exemple, nettoyer les contacts cartouches et contacts console, ouvrir les cartouches et vérifier que rien n'est oxydé, etc..

Bye

J'ai le plaisir de vous annoncer que j'ai trouvé et réparé la trace !

J'ai d'abord inspecté le Neo B1 à la loupe. RAS. ..  

Du coup je suis retourné sur ma 1ère intuition du LO ROM (qui stocke la table de shrink vertical) et là... Bingo sur la 1ère piste ! Pas de continuité !


Un petit coup de soudure côté verso :


(je suis pas super habile, c'est pas propre déguelasse mais ça tient).

Et un pansement pour soigner les bobos à la néo (il y a le pont LO ROM et le précédent pour le problème sonore que j'avais réparé en juillet).


J'ai bien retrouvé les bons zooms sur les 2 jeux cités plus haut !!!    

VOilà, il ne me reste plus qu'à régler ce **** de problème de reset intempestifs (mais aléatoires) sur mon combo Phantom-1 et 161 in1 et ce sera du tout bon. J'ai vu des sujets sur le 161 ici, je vais commencer par là. Si vous avez des pistes je suis preneur (en sachant que c'est pas l'alim, j'en ai testé 3 jusqu'à 5A).

En tout cas merci de vos conseils. Je pensais pas la réparer en moins de 24h!

Joli travail !!!

un truc me chiffone :
Ca vient donc de la LO ROM...  Mais alors pourquoi le problème  n’apparaissait pas sur tous les jeux qui utilisent le shrink ?  


encore une neo-geo sauvée  


edit :
Je viens de regarder le schéma, la pin1 de LO-ROM correspond à A15 le tout dernier bit d'adressage.
la coupure aurait été sur les poids faible A0..A7 t'aurait surement eu le problème à tous les jeux.

philhp a écrit:
Joli travail !!!

un truc me chiffone :
Ca vient donc de la LO ROM...  Mais alors pourquoi le problème  n’apparaissait pas sur tous les jeux qui utilisent le shrink ?  


encore une neo-geo sauvée  

Ce n'est qu'une théorie mais je pense que certains coefficients passaient mais pas d'autres en particulier (ceux qui transitent par la patte fautive en question).
Edit : Ninja'd par Philhp

Exact !

La pin1 de LO-ROM correspond à A15 le tout dernier bit d'adressage.
la coupure aurait été sur les poids faible A0..A7 t'aurait surement eu le problème à tous les jeux.

C'est cool,donc il faut une bonne loupe
c'est des pannes très courantes sur les aes (la mégadrive a des circuits plus gros ça n'arrive pas ces éffacements de pistes)

Bravo ... çà fait plaisir de voir cela ...
Maintenant tu peux changer ton pseudo

Mug

Kategohi a écrit:(la mégadrive a des circuits plus gros ça n'arrive  pas ces éffacements de pistes)

Normal, Sega, c'est plus fort que SNK