Neo MVH MV4F repair - battery damage, garbage overlaid on screen

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
Been a few months since I worked on a 4-slot, this one has been sitting in a buddies box of broken stuff for a while.

Looks like battery damage, but no watchdog for once which is a nice change
IMG_2859 (1).jpeg

So it is booting, won't boot games, I'm thinking it probably wants to give me a RAM error (stock bios and diagnostics bios)
IMG_2853 (1).jpeg

But somewhere between the RAM error being generate and the graphics being drawn the screen is covered in garbage so I can't read the error, also the nature of the graphics glitch changes after about 15 seconds, if it was just a bad trace it might be stable, guessing it could be a bad chip. Behaves exactly the same way with no cart, and with no top-board at all
IMG_2852 (1).jpegIMG_2851 (3).jpeg

So from what I can see the garbage graphics are being drawn very late in the graphics chain
1) Trace the graphics error and fix that so I can read the error messages
2) Read the error message and fix it

So im suspecting NeoB1 at the moment
Any thoughts or ideas before I start beeping out all 160 of its miserable pins?
 

ack

Fio's Quartermaster
10 Year Member
Joined
Apr 9, 2009
Posts
481
Can you take a close up of the screen with the error on it
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
Can you take a close up of the screen with the error on it
IMG_2867.jpegIMG_2866.jpegIMG_2863.jpegIMG_2861.jpeg
These are all with the diagnostics bios, can see where the words would be up the top of the screen, and the acknowledgement message down the bottom. It looks like it's being generated, but then not being drawn properly.
 

maki

Krauser's Shoe Shiner
Joined
Jan 1, 2022
Posts
231
your pic of the battery damage show traces that are probably eaten away

generally: this is very common, sadly so

use white vinegar on the spots with the battery damage, then clean it off very thoroughly
that leaked battery acid is still active otherwise

check every single trace for continuity

post detail pics of that area including the bottom side (acid goes all the ways), I'd focus ion the obvious damage there first

Edit:
looks like the IC (SRAM?) has been corroding away as well, better pics will clear this up
 

Attachments

  • rotten traces.jpg
    rotten traces.jpg
    123.9 KB · Views: 3

ack

Fio's Quartermaster
10 Year Member
Joined
Apr 9, 2009
Posts
481
View attachment 60755View attachment 60756View attachment 60757View attachment 60758
These are all with the diagnostics bios, can see where the words would be up the top of the screen, and the acknowledgement message down the bottom. It looks like it's being generated, but then not being drawn properly.
The error on screen says "VRAM 2K UNWRITABLE" and looks like you are running the original diag bios?. You also seem to have bit 7 stuck high on the lower byte of 32K vram, this is whats causing the bad chars on screen.
 

ack

Fio's Quartermaster
10 Year Member
Joined
Apr 9, 2009
Posts
481
I wanted to provide info on how I was able to come up with error text and the stuck bit. Hopefully it helps folks figure it out on their own in the future.

We know you are using the diag bios, it uses tiles for displaying text on screen. The screen will normally look something like

Code:
<NEOGEO DIAG HEADER>
-----------------------------

<SOME TEXT MESSAGE/ERROR>





<PRESS START/SELECT TO RESET>

If you take a zoomed in version of your picture (a higher res picture would have been helpful)
Screen Shot 2022-11-15 at 5.02.18 PM.png

We can see in your screenshot its the same general format just the tiles are garbled.

On the dev wiki they have the contents of the SFIX rom available as table showing each tile


The table is setup so each tile is a 3 hex value in the format YYX, where the value on the left is the YY, and column headers are the X. For example if you find the tile thats a "3" that maps to 0x033 tile number.

The majority of the screen on the diag bios is going to be empty. This is done using the space tile, which is tile 0x020. However we can see in your screen shot its instead has that "+" looking tile. Using this info we want to determine which extra/missing bits are needed to cause that "+" tile to display instead of the space. The quickest thing to check is both the row and column that the space is a part of and see if we can find that "+" looking tile. And it can be found at 0x0A0.

Code:
HEX              BITS
0x020 = 0000 0010 0000
0x0A0 = 0000 1010 0000

So we can conclude that bit 7 is stuck high.

For the error message you work backwards knowing that we need to zero out bit 7 from the tile found on screen to get the real tile. This is a little more annoying cause you need find each of those tiles in the error message part of the on screen.

As I write this I see there is actually another stuck bit. bit 6 is stuck low.

For example that first tile in the error message is tile 0x0B6
Code:
HEX              BITS
0x0B6 = 0000 1011 0110
        0000 0011 0110 = 0x036 = "6" (remove bit 7)
        0000 0111 0110 = 0x056 = "V" (add bit 6)
[CODE]

Just removing bit 7 results in 0x036 and maps to "6", but that doesn't make any sense for a valid error message.  However setting bit 6 gives us "V", which could be the start of the word VRAM.  If you follow the same process removing bit 7 and adding bit 6 from the found tiles it will result in the "VRAM 2K UNWRITABLE" error.

tldr you have issues with 2k and 32k vram
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
@ack This is the most epic piece of NeoGeo investigation that I have ever seen - to be able to look at a screen like and be able to find meaning is amazing... there are no words.
@maki thank you - especially for the white vinegar tip - there is a lot of damage to that area that I suspect will be stopping the game from booting, once I get the graphics sorted out that will be my next step

So it looks like this is genuinely of bad RAM chips.
Every other time I've worked on an MVS it has complained of bad RAM but it has been bad traces to/from the RAM - and I needed the practise reading pinouts, so I checked all the traces.

This is where to look for the location of the chips
https://github.com/jwestfall69/neogeo-diag-bios/blob/master/docs/ram_locations/images/mv4f_ram.jpg

can check graphics pipeline here
https://wiki.neogeodev.org/index.php?title=Graphics_pipeline
Both the LOW (speed) 32k VRAM and the HIGH (speed) 2k VRAM only talk to the LSPC2 so that makes it a little bit easier

32K VRAM Visual inspection gives CXK58256AM
data sheet is here and includes pinout https://html.alldatasheet.com/html-pdf/47130/SONY/CXK58257AM/84/1/CXK58257AM.html

2K (FAST/HIGH) VRAM visual inspection gives CXK5814P-35L
data sheet is here and includes pinou https://www.alldatasheet.com/datasheet-pdf/pdf/47128/SONY/CXK5814P-35L.html

And we can find the pinout for LSPC2-A2 here
https://wiki.neogeodev.org/index.php?title=LSPC2-A2

So looking at the pinout
We can see
B0~B14: Low VRAM address bus
E0~E15: Low VRAM data bus
Then we can just beep them out

For Example Lower VRAM pin 1 (address bus pin A14) should go to LSPC2 pin 40 (address bus B14)
The address bus is common across both VRAM 32 chips
Complicated only very slightly slightly because the data bus is split between the VRAM chips
Data E0-E7 on Lower
Data E8 - E15 on upper

have beeped out all the 32k VRAM and it is good
Vram address bus is all good
VRAM data bus is all good
CE is tied to ground
WE is good BWE = 60
OE is good BOE = 59

have beeped out all the 32k VRAM and it is good
Vram address bus is all good
VRAM data bus is all good

So having confirmed that the traces are fine and that it is in fact bad RAM chips I'm ready to pull the chips and replace. Luckily I have lots of spare 32K ram left over from a previous repair, and a donor board with known good 2K ram.

Hold my beer while I hot Air...
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
Got to use the new hot air station today - it is super fast compared to my cheap "squirrel cage" KSger one.

Took off the 32k VRAM and replaced with new chips
Took off the 2k VRAM, added some sockets and swapped in known-good ones from another board
Patched all of the rotten traces that I could find from the battery area
IMG_2952.jpegIMG_2954.jpegIMG_2973.jpeg

Some succes, the VRAM 2K unwritable error has cleared
IMG_2967.jpeg

And I can now access the diagnostics menu enough to run the checks. The color bar check looks like this
IMG_2969.jpeg

So having beeped out all the traces, and replaced all the ram, I'm still getting the same graphics glitches. Those ram chips don't talk to anything else except the LSPC2, the chips are good and the traces are good. I'm thinking that the LSPC2-A2 itself might be bad.

From here my plan is to focus on Bit 6 (stuck low) and Bit 7 (stuck high) on the 32K VRAM
Bit 6 on the LOW (speed) VRAM looks like pin 30 on the LSPC2
Bit 7 on the LOW (speed) VRAM looks like pin 31 on the LSPC2

My logic probe skills are best described as "basic" but luckily I have a working MV4-FT2 to validate against. I'll start poking at those pins with a logic probe and see if I can confirm the stuckness that way.

Not sure what I'll do if I can confirm the problem that way - replacing the LSPC2 does not sound like a tonne of fun...
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
Spent several hours with the microscope fixing battery damage, pretty sure I got them all but experience has taught me that there is always a sneaky one missing somewhere
IMG_2976.jpegIMG_2985.jpegIMG_2984.jpeg
I also replaced all the THT components by the battery just to be on the safe side, I've had a couple of repairs where these have corroded out on the inside and tested bad despite looking fine. Several of these fell apart on being touched
IMG_2972.jpeg

None of this cleared the stuck Video Ram bit, in the next post
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
So back to the glitchy graphics now that the worst of the mechanical damage was fixed

I had forgotten how to use a logic probe so re-read this post and re-watched this video
https://www.neo-geo.com/forums/inde...hdog-even-with-neogeo-diagnostic-bios.267802/

I was sure that the 68k was working as expected so I probed that to start for practise

On the 68k these are good things to test.
(PIN 6) AS expected = PULSE (this is the bare minimum to expect from a 68k if its not dead)
(PIN 18) RESET expected = HIGH (except on click of death when it will pulse LOW for a moment)
(PIN 17) HALT expected = HIGH (except on click of death when it will pulse LOW for a moment)
(PIN 29) A1 expected = PULSE (this should pulse if the 68k is doing anything useful, if HI/LO there is a chance the 68k is faulty)
(PIN 30) A2 expected = PULSE (if this is LOW or HIGH there is a chance the 68k is faulty)
(PIN 31) A3 expected = PULSE (if this is LOW or HIGH there is a chance the 68k is faulty)
All of these tested as expected

Then I looked at the 2K VRAM (results were as expected and the same for both chips)
(Pin 18) CE = PULSE on power then LOW which Im thinking is probably expected behavior
(Pin 20) OE = PULSE on power then LOW which Im thinking is probably expected behavior
All IO pins = PULSE
All address pins = PULSE

Then I looked at the 32K VRAM (results were as expected)
(Pin 18) CE = PULSE on power then LOW which Im thinking is probably expected behavior
(Pin 20) OE = PULSE on power then LOW which Im thinking is probably expected behavior
All IO pins = PULSE
All address pins = PULSE

both chips have been replaced, so highly unlikely that the problem is on the 32K VRAM end.

So the signal is not being correctly generated by the LSPC

Looking at the graphics pipeline here
https://wiki.neogeodev.org/index.php?title=Graphics_pipeline

The LSPC takes inputs from
LO-ROM like this
https://wiki.neogeodev.org/index.php?title=L0_ROM
and
NEO-B1 like this
https://wiki.neogeodev.org/index.php?title=NEO-B1
The Origin on the tiles is the SFX-ROM
https://wiki.neogeodev.org/index.php?title=SFIX_ROM
The SFX-ROM does not talk to the LSPC directly, but it does talk talk to the LSPC via the NEO-B1

So from here NEO-B1 then the SFX-ROM were the next places to check

Data coming out of SFX-ROM and into NEO-B1
SFX-ROM seems to be undocumented, but the lines that I was interested in were the ROM data lines FIXD0-FIXD7 that come out of SFX-ROM and into NEO-B1. These are documented on the NEO-B1 as Pins 131 to 138
Then with a bit of Multimeter sweeping I could identify the pins on SFX-ROM, then I could logic probe them.
FIXD0 = NEOB1 PIN131 = SFX-ROM PIN13 = Pulse
FIXD1 = NEOB1 PIN132 = SFX-ROM PIN14 = Pulse
FIXD2 = NEOB1 PIN133 = SFX-ROM PIN15 = Pulse
FIXD3 = NEOB1 PIN134 = SFX-ROM PIN17 = Pulse
FIXD4 = NEOB1 PIN135 = SFX-ROM PIN18 = Pulse
FIXD5 = NEOB1 PIN136 = SFX-ROM PIN19 = Pulse
FIXD6 = NEOB1 PIN137 = SFX-ROM PIN20 = Pulse
FIXD7 = NEOB1 PIN138 = SFX-ROM PIN21 = Pulse

Data going into SFX ROM from NEO-IO - this was where it started to get funky
Again, because SFX-ROM was undocumented, I had trouble understanding the logic probe reading from the other pins. Eventually I realised that the INPUT data for SFX-ROM came from NEO-IO on the p-bus
NEO-IO is documented here
https://wiki.neogeodev.org/index.php?title=NEO-I0
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
So the input data comes into NEO-IO on the P-BUS (P0-P15)
then goes out to SFX-ROM Q address lines (Q1-Q18)

For some reason the Q address lines start counting from 1 instead of 0 per here
https://wiki.neogeodev.org/index.php?title=NEO-I0

Probing all the P-BUS inputs = all pulse
Probing the Q address lines
Q1 = NEO-IO PIN6 = Pulse
Q2 = NEO-IO PIN7 = Pulse
Q3 = NEO-IO PIN8 = Pulse
Q4 = NEO-IO PIN9 = Pulse
Q5 = NEO-IO PIN11 = Pulse
Q6 = NEO-IO PIN12 = Pulse
Q7 = NEO-IO PIN13 = LOW
Q8 = NEO-IO PIN14 = HIGH
All others Q9-Q18 = Pulse

I also checked continuity from the NEO-IO to the SFX-ROM on those linse
Q5 = NEO-IO PIN11 = SFX ROM PIN26 = Pulse = continuity
Q6 = NEO-IO PIN12 = SFX ROM PIN23 = Pulse = continuity
Q7 = NEO-IO PIN13 = SFX ROM PIN25 = LOW = continuity
Q8 = NEO-IO PIN14 = SFX ROM PIN4 = HIGH = continuity

Remember waaaaaay back at the start where @ack said that Bit 6 was stuck low and Bit 7 was stuck high?

Because Q address lines start counting at 1, and bits start counting at 0
Q7 (which is stuck low on the NEO-IO) = 7-1 = BIT6 stuck LOW
Q8 (which is stuck High on the NEO-IO) = 7-1 = BIT7 stuck HIGH

Ack truly is the NeoGeo Guru

Next post what to do
 
Last edited:

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
At this stage I think I have traced the problem

NEOB1 is generating palette RAM address requests correctly and sending them on the P-BUS to NEO-IO
NEO-IO is receiving the requests correctly then generating SFX rom addresses incorrectly, then sending incorrect requests on BIT6 and BIT7 to SFX-ROM
SFX-ROM is getting bad rom addresses to look up from NEO-IO it is correctly looking up the wrong tiles and sending those wrong tiles on SFXD to NEO-B0
NEO-B0 is correctly sending the wrong tiles to the Palette ram
The Palette ram is making those wrong tiles available to be rendered by the DAC
The wrong tiles are showing up on the screen

There are no address line problems, broken traces or etc, NEO-IO is taking good inputs and generating bad outputs.

So the fix in this case looks like it might be to replace NEO-IO

Unfortunately I don't have a spare NEO-IO to hand; So before I rush off and order one I'm going to beg @ack for his assistance checking my work to confirm I've got this right.
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
Rats - not the result I was hoping for.

I swapped the suspect bad NEO-IO for a known good one that I had from this board
https://www.neo-geo.com/forums/index.php?threads/mv4t-no-sound-when-cart-inserted.267803/
That board had problems (Bad sound) but nothing to do with the NEO-IO, the NEO-IO was good
IMG_2990.jpegIMG_2989.jpeg

After swapping in the known good NEO-IO it won't boot at all
Static screen like this for the Diagnostics bios, and fast watchdog with the unibios
IMG_2992.jpegIMG_2991.jpeg

All I can think of is that I may have damaged the known good NEO-IO when I swapped them over? I was extremely careful so that's unlikely, but im now stumped...
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
And then I remembered the old "push hard on the chip" trick. After a few minutes of poking at the NEO-IO in various ways it started working perfectly

Will reflow the legs and check the traces, I think I must have burned one accidentally while removing the chip. But the good news it that the core issue has been identified and resolved, everything from here is detail (famous last words)
IMG_2993.jpegIMG_2997.jpeg

Flush with my success with the bottom board I threw a hail Mary for the top board - which of course does not work. but solid progress nonetheless.
IMG_2996.jpeg
 
Last edited:

ack

Fio's Quartermaster
10 Year Member
Joined
Apr 9, 2009
Posts
481
I will usually use a sharp/skinny pair of tweezers and test each leg by applying a small amount of side pressure to verify the leg is soldered down properly. Like this

 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
Back into messing with old gear after a brief Christmas break - to my complete lack of surprise the barely functional board is now completely non-functional :-)

Have carefully checked all of the legs on the NEO-IO but no amount of poking and prodding will coax it back to life, I can only assume that I cooked it while desoldering, have desoldered hundreds of chips before with no issues, massively frustrating.

Back to the old logic probe to verify that it is indeed cooked, Luckily I have some other MV2 and MV4's to compare correct operation against.

TL;DR - does anyone know where I can buy replacement NEO-IO chips from?
 

maki

Krauser's Shoe Shiner
Joined
Jan 1, 2022
Posts
231
I only know other MVS boards that have the NEO-I0, nothing modern like what Furrtek builds for some other ACICs.

I did notice that sometimes on MVS and AES PCBs, the actual pads are disconnected from the traces, nearly impossible to see, easy to measure.

Its just odd that the IC would have totally died, its possibly but you've done this before.

On a side note, I use bismuth based solder when I don't want things to go too hot, its mark3ted as ChipQick in the US and is really expensive, but buying pure bismuth and mixing it 1:1 with leaded solder is much cheaper and works as well.
 

hatmoose

Kuroko's Training Dummy
Joined
Dec 3, 2021
Posts
79
I only know other MVS boards that have the NEO-I0, nothing modern like what Furrtek builds for some other ACICs.

I did notice that sometimes on MVS and AES PCBs, the actual pads are disconnected from the traces, nearly impossible to see, easy to measure.

Its just odd that the IC would have totally died, its possibly but you've done this before.

On a side note, I use bismuth based solder when I don't want things to go too hot, its mark3ted as ChipQick in the US and is really expensive, but buying pure bismuth and mixing it 1:1 with leaded solder is much cheaper and works as well.
Thanks for the words of support! I was feeling a bit down, so much work, and so close but so far away.

You're right of course, will almost certainly be a bad trace - I need to stop freaking out, be patient, and go back to basics - not shotgun replace parts on a wing and a prayer :-)
 

maki

Krauser's Shoe Shiner
Joined
Jan 1, 2022
Posts
231
I have some MVS here that I've worked on for months on/off, its especially frustrating after changing ICs/bigger effort when things go even worse.
Just the other day, on a MV2F, I found bridged pins on a NEO-G0, I made that bridge, and then I was chasing the problem for months on and off..
 
Top