MVS Neo GEO Comment faire simple quand... / Why keeping it simple when ...

Publié le par Rage

(English version below)

Quand ton slot se met à te parler en hiéroglyphes, tu sais déjà que la soirée ne va pas se finir à une heure raisonnable. Et quand en plus il te rajoute une petite touche d’art contemporain à l’écran, là je trouve qu’il pousse le bouchon un peu trop loin, Maurice.

 

Premier réflexe : tu te dis que le fix layer ou la SFIX sont aux fraises. Mais non, sinon ce serait presque reposant. Un petit coup d’oscillo, et tout ce beau monde a l’air de très bien faire son travail.

Comme tu sais aussi que “LSPC” rime rarement avec “diagnostic simple”, tu te rassures en sortant le Briconeo de l’ami Aurélien.

Et là, mince alors : les deux tests VRAM sont KO. Bus data HS. Disons-le franchement, ce n’est pas exactement le genre de résultat qui met en confiance. Le seul point commun entre les deux tests, c’est justement le LSPC. Et l’erreur remonte un premier bit bloqué à 1. Ambiance.

 

Mais ce montage graphique en diagonale, il a quand même un petit charme. C’est faux, mais c’est faux avec application. On a presque envie d’encadrer la panne.

Normalement, le décalage de l’écriture à l’écran d’une colonne à l’autre: oui, parce que le SFIX écrit de haut en bas :) se fait grâce au registre REG_VRAMMOD, à l’adresse $3c0004. Quand on écrit dans REG_VRAMMOD, on définit l’incrément appliqué à REG_VRAMADDR après chaque write sur REG_VRAMRW. En clair, sa valeur dépend de ce que le code charge dedans : 1 pour avancer mot par mot, 32 our sauter une colonne. Ici, à chaque colonne, on voit un décalage de 1 ce qui crée ce magnifique effet diagonal. Et comme si ça ne suffisait pas, le caractère lui-même est faux. Vraiment, on est sur une panne qui soigne sa mise en scène.

Du coup, l’écriture du registre semble erronée et provoque ce décalage. On va vérifier ça avec le Briconeo : l’idée, c’est d’écrire 0x20 (32) en boucle dans le registre et d’aller voir à l’oscillo ce qu’il se passe au moment de l’écriture, en particulier sur le bit [D0], le fameux responsable du décalage de 1.

La commande Briconeo : **write 0x20 3c0004

En rose, les écritures [R/W]. En jaune, [D0] côté 68k. Et là, surprise : quand j’écris dans le registre avec le Briconeo, le bus n’est pas perturbé. Le signal [D0] reste bien bas. Même en touchant partout sur la carte comme un druide de la dernière chance, rien ne bronche.

 

 

Bon… Le LSPC serait donc HS ? Sur le papier, ça se tient : ce qui rentre dedans est cohérent, et ce qui en sort… beaucoup moins, vu que les tests VRAM sont dans les choux. Autant dire que la messe est presque dite.

Dernier recours : je vais regarder la tête de [D0] directement à l’entrée du LSPC. Et là… surprise.

Le signal est bloqué haut en permanence.

 

Ce qui confirme une piste coupée entre le [D0] du LSPC et le bus [68k]. Voilà. C’était ça. Une pauvre piste coupée, totalement invisible à l’œil nu, qui m’a déroulé tout un opéra diagnostique pour finir sur le classique absolu : “c’était tout con”.

Merci à Aurélien, mon copain de réparation, capable de me réciter les mnémoniques assembleur [68k] par cœur pendant que moi, je cherche une coupure de piste planquée comme un lâche.

English version :

When your slot starts speaking to you in hieroglyphs, you already know the evening isn’t going to end at a reasonable hour. And when it also throws in a little touch of contemporary art on screen, that’s where I think it’s pushing things a bit too far, Maurice.

First reflex: you tell yourself the fix layer or the SFIX must be acting up. But no, because that would almost be relaxing. A quick check with the scope, and all that little crowd seems to be doing its job just fine.

And since you also know that “LSPC” rarely rhymes with “simple diagnosis,” you reassure yourself by pulling out Aurélien’s Briconeo.

And then, well... both VRAM tests fail. Data bus dead. Let’s be honest, that’s not exactly the kind of result that inspires confidence. The only thing both tests have in common is, of course, the LSPC. And the error points to the first bit being stuck at [1]. Lovely.

But this diagonal graphical mess does have a certain charm. It’s wrong, but it’s wrong with dedication. You almost want to frame the fault.

Normally, the offset in screen writing from one column to the next — yes, because the SFIX writes from top to bottom :) — is handled by the REG_VRAMMOD register at address 0x3c0004. When you write to REG_VRAMMOD, you define the increment applied to REG_VRAMADDR after each write to REG_VRAMRW. In other words, its value depends on what the code loads into it: 1 to advance word by word, 32 to jump one column. Here, with each column, we see an offset of 1, which creates this beautiful diagonal effect. And as if that weren’t enough, the character itself is also wrong. This is truly a fault that cares about presentation.

So the register write seems incorrect and is causing this offset. We’re going to check that with the Briconeo: the idea is to write 0x20 (32) to the register in a loop and see on the scope what happens during the write, especially on bit [D0], the famous culprit behind the offset of 1.

Briconeo command: write 0x20 3c0004

In pink, the [R/W] writes. In yellow, [D0] on the 68k side. And here comes the surprise: when I write to the register with the Briconeo, the bus is not disturbed. The [D0] signal stays firmly low. Even when I poke around the board like a last-chance druid, nothing moves.

So... could the LSPC actually be dead? On paper, it makes sense: what goes into it is coherent, and what comes out of it... a lot less so, given that the VRAM tests are completely off the rails. Safe to say the verdict is almost in.

Last resort: I’m going to look at [D0] directly at the LSPC input. And then... surprise.

The signal is stuck high permanently.

Which confirms a broken trace between the LSPC’s [D0] and the [68k] bus. That was it. A tiny broken trace, completely invisible to the naked eye, that dragged me through a full diagnostic opera only to end on the most classic punchline of all: “it was something stupid.”

Thanks to Aurélien, my repair buddy, who can recite 68k assembly mnemonics from memory while I’m over here hunting down a hidden broken trace like a coward.

Pour être informé des derniers articles, inscrivez vous :
Commenter cet article