MV4-FT2 - watchdog even with neogeo diagnostic bios

[hatmoose]

Hi Everyone;

I'm working on a NeoGel MV4-FT4 that I think may have been over voltaged.

It was sold as "parts only". Worked for s breif moment when I got it and has never worked again, over voltage is the only thing I can think of... buy anyway

Symptoms are
stock bios = fast watchdog
diagnostic bios = fast watchdog

So whatever the problem is must be quite early in the startup chain, it's not even able to boot the bios and start the diagnostics.

Troubleshooting so far
1) Replaced bios and bios socket - no change
2) checked carefuly with a microscope for trace damage - no change
3) swapped all the DIP ram for known good (fast video, pallete, sound) - no change
4) swapped z80 for known good - no change

Next steps from here (I think?)
swap 32k work ram and 32k vram for known good
give up and learn how to use a logic probe

Any other ideas on what might be causing this?

 

[slugger_dan]

3) swapped all the DIP ram for known good (fast video, pallete, sound) - no change
4) swapped z80 for known good - no change

Next steps from here (I think?)
swap 32k work ram and 32k vram for known good

Doubt the stuff here will help fix the watchdog. Watchdog means 68k won't boot or is crashing and audio/video section parts probably aren't causing that. Diag BIOS shouldn't need WRAM to not crash so that's unlikely. If WRAM is active when it's not supposed to be then that's a problem though. If you're 100% sure about the traces you could remove the WRAM for now and just stick to diag bios which doesn't need it to function. You will get an error but that comes after the click of death is fixed. One less variable to think about.

If you get a logic probe then I posted a few things in another thread to check. I think a good start is seeing if the 68k is doing anything useful and work from there

Neo Geo MV1AX Click of Death

Hello everyone, After getting my minigun supergun, I had hooked up an atx psu to the minigun's molex connector without realizing that the pins were different (So I effectively ran 12v down the 5v rail and shorted 12v to gnd). That caused the psu to activate the overcurrent protection and just...

www.neo-geo.com

 

[hatmoose]

Awesome - thank you very much!

If anyone comes after me and reads this I also found this video useful to start learning how to use a logic probe so I could follow the info that @slugger_dan posted.

And this will probably come in useful in the near future too.
https://wiki.neogeodev.org/index.php?title=Signals

 

[maki]

Symptoms are
stock bios = fast watchdog
diagnostic bios = fast watchdog

I recommend checking each trace from the 68k to the BIOS

I've seen traces that looked perfectly fine, and then the via connecting to the trace also looked fine, but it had no continuity

visual inspection is important to find areas that need more work, but only trust a continuity test unless you want to waste a lot of time as I did

 

[hatmoose]

I recommend checking each trace from the 68k to the BIOS

I've seen traces that looked perfectly fine, and then the via connecting to the trace also looked fine, but it had no continuity

visual inspection is important to find areas that need more work, but only trust a continuity test unless you want to waste a lot of time as I did

Thanks! I've given up on the other MV4T - so this is my primary restoration project for now.

Excuse my Noob question, this is probably going to sound absulrdly dumb but here goes.

I'm on the neogeo development wiki

Pinout for the Z80 is here
https://wiki.neogeodev.org/index.php?title=68k

Is there a similar pinout, or a table or something that I can follow that shows me what pin on the processor should connect to what pin on the bios?

 

[maki]

its not a dumb question at all

the schematics are here here as you know: https://wiki.neogeodev.org/index.php?title=Schematics

however, they are blurry and hard to read, gets easier after a while once you know what you're looking for

OTOH, you can tell by the signal names, the pinout of the 68k and the Z80

68k - NeoGeo Development Wiki

wiki.neogeodev.org

Z80 - NeoGeo Development Wiki

wiki.neogeodev.org

So you can clearly see the signals D0 to D7 (data bus, 8 bit) and they are also on the 68k, they should be connected, same trace
same for A0 to A15, the address bus, needs to be connected between the 68k and the Z80
the 68k is a 16 Bit CPU, so it has more traces on the data bus, 16 bit

if you look at the cart pinout, you're going to recognise the same signal names, same traces, all need to be connected

AES cartridge pinout - NeoGeo Development Wiki

wiki.neogeodev.org

this also goes for B1, LSPC2-A2 etc. and so on, NEO-D0 is also be connected to the bus

again, same for other ICs in there, like the NEO-D0 (relevant for digital audio), you can see the the data lines there

NEO-D0 - NeoGeo Development Wiki

wiki.neogeodev.org

they are all attached to the same bus, sometimes arbitraging/multiplexing needs to be done, this is where these ASIC 244 etc. come into play, they "switch" between different participants of the bus

 

[hatmoose]

OK, so that was lots of fun - learning to use a logic probe makes this much faster.

I checked continuity between the bios and the 68k, everything looked good for the traces, and everything beeped as expected

I used the logic probe on the 68k following these instructions from @slugger_dan.
http://www.neo-geo.com/forums/index.php?threads/neo-geo-mv1ax-click-of-death.267581/post-4393037
The readings were all over the show, notably A1-A3 were stuck low and AS was stuck low too

I swapped the known good 68k from the MV4T into this board, and put the suspect 68k from this board into the MV4T.

The suspect 68k is definately buggered - with the suspect 68k installed the MV4T now exhibits all kinds of crazy symptoms, watchdog, strange graphics, inconsistent oddness

With the known good 68k in the MV4-FT2 board and the diagnostics bios the click of death stopped and I had garbled graphics and 68k activity as expected

Logic probe now shows what I think I should expect from the 68k
Reset = high (except breifly low when the chip resets shortly after power up)
halt = high
AS = pulse
A1 = pulse
A2 = pulse
A3 = pulse
clock = pulse

But what to do about the garbled graphics? I remembered a post here http://newlifegames.com/nlg/index.php?topic=1859.0 about one of the reasons that the MV4 and MV6 were so fussy is that SNK made some pretty strange decisions about the AS245 chips - if one fails it can cause all kinds of weird problems, including halting the boot with garbled graphics.

So I suspected the weird bodged-on resistor array was probably a previous attempt to fix one of the AS245's. I should have probed it to make sure, but I just swapped it.


And success! Watchdog = gone, garbled graphics gone, diagnostics all pass except backup ram. z80 tests all pass in every slot


If anyone else is like me and is wondering "they all look the same, which ones are the backup ram?". I found this site useful
https://github.com/jwestfall69/neogeo-diag-bios/blob/master/docs/ram.md

And the part number for the backup ram that i ordered was this - carefiully selected as being the cheapest they had in stock.
https://www.digikey.co.nz/en/produc...icon-solution-inc/IS62C256AL-45ULI-TR/1557491

So high hopes for a complete recovery on this one - I'll swap the Backup Ram when the parts arrive.

Will update when the Ram arrives.

 

[maki]

awesome work!

if you swap the RAM ICs now (upper with lower backup RAM IC), you can tell if it is a faulty RAM IC (address should change), or if its a trace (same address)

 

[ack]

awesome work!

if you swap the RAM ICs now (upper with lower backup RAM IC), you can tell if it is a faulty RAM IC (address should change), or if its a trace (same address)

If you were to swap the upper/lower backup ram ICs the address of the fault shouldn't change.

If the upper ram was bad when you swapped, the 'actual' value would switch to 0080.
If there was some trace issue and you swapped, the 'actual' value would remain the same at 8000

If anyone else is like me and is wondering "they all look the same, which ones are the backup ram?". I found this site useful
https://github.com/jwestfall69/neogeo-diag-bios/blob/master/docs/ram.md

I added support for telling you the chip at fault if you use the bios available on that repo (you will also need to use the diag m1 from it for z80 testing). Your above fault would have been reported as BRAM DATA (UPPER) instead of what you see with the original diag bios.

 

[hatmoose]

I added support for telling you the chip at fault if you use the bios available on that repo (you will also need to use the diag m1 from it for z80 testing). Your above fault would have been reported as BRAM DATA (UPPER) instead of what you see with the original diag bios.

Thank you for your work disassembling, documenting and adding new features to the BIOS!

It's a super cool tool and the features you are adding are the ones that I had always wanted - your work is valued and appreciated, thank you!

 

[hatmoose]

Digikey came through for me today - new SRAM to replace that bad backup ram... or so I thought


Took the old ram off, soldered the new ram on, powered it up, proud as punch aaaaaaaaaand



Exactly the same error...


To be fair both @maki and @ack did warn me of this...

So a couple of possible things
1) bad trace - if anyone has a pinout for the backup ram I would greatly appreciate that
2) wrong RAM chip - the chip I got was https://www.digikey.co.nz/en/produc...icon-solution-inc/IS62C256AL-45ULI-TR/1557491 which should be a drop-in replacement, but if anyone could please confirm I would greatly appreciate that too

On a slightly more positive note I can use the unibios to swap to AES mode (which skips the backup ram test) and the game works perfectly - but with no sound...

Oh MV4-FT2 you are such a cruel mistress and a dirty tease... Your mystery and your majesty excite and frustrate

 

[maki]

its most certainly a trace, very common, don't worry I've replaced plenty of ICs and then realising its just a trace, like swapping the LSPC-A0.. its a learning curve
if the IC didn't work, you'd get another kind of error, dead RAM etc.

Here is the pinout for the MV1FZ Backup RAM, should be the same except for the orange marked traces, they go to a bank switcher
When I started fixing MVS, nearly every single one had problem with the backup bios, on lots of models its close to the backup battery that leaks, and this was very helpful, see the rotten traces/missing pads I jumped there?



@ack great work on the improved diag BIOS, much appreciated had no idea it was you who put in all the effort to disassemble and then change it, much obliged sir!

 

[hatmoose]

Thanks!

I unsoldered the new ram just to make sure, and also so that I could trace the traces more easily - can confirm that if the RAM is properly missing it gives a "BRAM dead output" error


So looking a lot like a trace - thank you very much for the ram pinout - that is a super useful thing.

I'm still getting used to reading so do please it correct me if i'm wrong but I think the "A" (68k address) lines are reasonably simple
Pin 9 on the backup ram is A1
Pin 29 on the 68k is A1
Pin 31 on the z80 is A1
So all of those should show continuity right?

And same story
Pin 6 on the backup ram is A4
Pin 32 on the 68k is A4
Pin 34 on the z80 is A4
Pin 61 on the Neo-D0 is A4
So all of those should also show continuity right?

The ones I'm having trouble with are
/WE /OE /CE
IO1 - IO8
I dont know enough about what these are mean to be able to figure out where they are meant to go

 

[maki]

I'm still getting used to reading so do please it correct me if i'm wrong but I think the "A" (68k address) lines are reasonably simple
Pin 9 on the backup ram is A1
Pin 29 on the 68k is A1
Pin 31 on the z80 is A1
So all of those should show continuity right?

Yes.
They are the bus, so they are all over the place

They also should have continuity between A1 on the upper and lower backup RAM IC, thats more important to check IMO also easier to do, so all yellow marked traces on the upper and lower with the same number are connected

Ax = address line
IOx = input/output data, thats where the actual data is transferred, either written to the RAM IC or read from it
/WE = write enable, active low (/ means active low, so 0V means active), so this IC can be written to
/OE output enable, active low, this means the output of this IC is enabled, it can be read

basically with the last two the machine can switch between the backup RAM and the actual RAM.

I'd focus on the Ax traces and the the IOx traces, the others should be working or you have other problems IMO

 

[ack]

The error is

Actual 8000
Expected 0000

This directly points to IO8 of the upper (byte) backup ram chip. Note this is the physically lower backup ram chip. It should have continuity to the pin 54 (D15) on the 68k

68k - NeoGeo Development Wiki

wiki.neogeodev.org

 

[hatmoose]

Spoilers - you nailed it from just the error message - i'm speechless

details

Good continuity tests
There is Continuity between all of the A (address) lines between upper and lower BRAM
Thre is Continuity between all of the A (address) lines between upper/lower BRAM and the 68k

Also good continuity tests
There IS continuity between the IO lines on the lower BRAM pads and the 68k
Lower BRAM pin 11 (IO1) goes to 68k pin 5 (D0)
Lower BRAM pin 12 (IO2) goes to 68k pin 4 (D1)
Lower BRAM pin 13 (IO3) goes to 68k pin 3 (D2)
Lower BRAM pin 15 (IO4) goes to 68k pin 2 (D3)
Lower BRAM pin 16 (IO5) goes to 68k pin 1 (D4)
Lower BRAM pin 17 (IO6) goes to 68k pin 64 (D5)
Lower BRAM pin 18 (IO7) goes to 68k pin 63 (D6)
Lower BRAM pin 19 (IO8) goes to 68k pin 62 (D7)

Also good continuity tests
There is IS continuity between other IO lines on the lower BRAM pads and the 68k
Lower BRAM pin 11 (IO1) goes to 68k pin 61 (D8)
Lower BRAM pin 12 (IO2) goes to 68k pin 60 (D9)
Lower BRAM pin 13 (IO3) goes to 68k pin 59 (D10)
Lower BRAM pin 15 (IO4) goes to 68k pin 58 (D11)
Lower BRAM pin 16 (IO5) goes to 68k pin 57 (D12)
Lower BRAM pin 17 (IO6) goes to 68k pin 56 (D13)
Lower BRAM pin 18 (IO7) goes to 68k pin 55 (D14)

Not good continuity test
Lower BRAM pin 19 (IO8) should go to pin 54(D15) but in fact it does not...

Stay tuned for the next post showing the problem

 

[hatmoose]

The bad trace as basically impossible to find by looking - even with a microscope the fault was invisible - I knew exactly where to look and exactly what I was looking for and it still took about 20 mins to find it

The backup ram (upper) is conected to the 68k via the work ram (upper). I beeped out all the traces and eventually isolated the fault to this line here


The fault is actiually impossible to see, the via was disconnected from the trace, here it is with the solder mask scraped off and it's still pretty much impossible to see.


So this was the completed repair


And like any good politician I solved one problem and created three more - valuable lesson here never to use masking tape on PCB's - these guys survived being desoldered and soldered and desoldered just fine, then I stupidly ripped them up with the tape I was using to label my work. What a Rookie :-)

They are easy to bridge with bodge wire, but I'll try to repair the pads for the practise first.
I'll follow these instructions and see what happens
https://www.circuitrework.com/guides/4-7-1.html

 

[maki]

last pic, IMG_0152.jpeg, these might be salvageable, but IME its way better to use very short jumpers, solder one side into the via, this will give it really good mechanical strength, only time it might move is when you solder the IC to it, but even then its easy to fix
you can glue the other side down with UV solder mask, but thats totally optional with such short jumpers IME

have a look at my pic with the traces marked for the backup RAM, A12 on the upper and /WE on the lower is were I did exactly that

these replacement traces for sale do not hold as much as a wire IMO, so they are totally useless to me

edit:
I doubt that your masking tape ripped the pads off by itself
the traces and pads are glued to the PCB with epoxy, really old epoxy, it will dissolve if it gets too hot, and the pad/traces will lift, happens a lot with these AES/MVC PCBs
my soldering iron (temp controlled) is set to 310C for these PCBs, my hot air station to 330C but gotta be really careful with the latter and just careful with the former, white dots on the PCB where you solder are a sign of de-lamination

 

[hatmoose]

Some learnings, some success, some annoyances, and a mystery

Learnings
I tried gluing the pads down with standard 2-part epoxy - failure, did not stick at all. i was able to salvage 2 of them and jumpered the 3rd one to get the
BRAM chips back on.


Some sucess
With the traces repaired, and the pads that i destroyed while repairing the traces also also repaired, the diagnostic bios and the z80 test cart were happy. That dratted BRAM error is gone! With the diagnostics bios and the m1 sound test cart I get
Slot 1 = all tests passed, including the z80 tests (z80 test tones play correctly)
Slot 2 = all tests passed, including the z80 tests (z80 test tones play correctly)
Slot 3 = all tests passed, including the z80 tests (z80 test tones play correctly)
Slot 4 = all tests passed, including the z80 tests (z80 test tones play correctly)

And games play as expected! No errors, full sound, it's very lovely


Some annoynaces
Slot 4 is dead - will not play games, will not recognise carts are inserted (goes to jailbars)
Slot 1 works but with sound distortion - music plays as expected, sound is crackly

And a mystery
With the test bios things work as expected. With the stock bios things work as expected.
With the unibios... nothing works, boots to a black screen...
I've actually tried two different unibios chips and both of them work perfectly in any other neogeo, including the other MV4T with the bad top board. But in this board the unibios boots to a black screen.

So the cart slot defects I'll deal with later - but the UniBios thing has me stumped

The unibios was working fine in this very board just the other day. I used it to bypass the BRAM error just the other day.
Things that have changed between now and then
Fixed IO8 to D15 trace
Damaged and repaired IO1, IO2 and IO3
Swapped the original BRAM for new BRAM

Is it worth undoing all these changes to see if I can get back to working unibios?

 

[maki]

Good job

Is it worth undoing all these changes to see if I can get back to working unibios?

I'd say "No".

It sounds like your UnibIos IC could be damaged, killed a BIOS EPROM by dropping it on a hard floor before.

Try 3.3 and 4.0 (easy if you have a EPROM burner and eraser).

The sound problem seems to be on the digital part.

Edit:
just read that you've tried diFferent BIOS ICs

 

[Neo Alec]

I think sometimes on an AES you might have to bridge some of the last few pins to get the Unibios working? @Xian Xi used to talk about that. Maybe he's updated his guidance since. In my experience I think just wiring a socked 1-to-1 to the AES usually works.

You probably need to double check the bios pins/traces. There might be something that affects the Unibios, but not the others.

 

[ack]

And a mystery
With the test bios things work as expected. With the stock bios things work as expected.
With the unibios... nothing works, boots to a black screen...
I've actually tried two different unibios chips and both of them work perfectly in any other neogeo, including the other MV4T with the bad top board. But in this board the unibios boots to a black screen.

Be aware there are a couple bugs with unibios 4.0 and multi slot boards.

On some multi slot boards if you boot the board with no games you will just get a black screen. It seems kinda random about what boards it effects. I've had multiple of the same model number where some got the black screen and others didn't.

If there is no game in slot 1 you will not get sound in any other slot.

 

[hatmoose]

Be aware there are a couple bugs with unibios 4.0 and multi slot boards.

On some multi slot boards if you boot the board with no games you will just get a black screen. It seems kinda random about what boards it effects. I've had multiple of the same model number where some got the black screen and others didn't.

If there is no game in slot 1 you will not get sound in any other slot.

Now this is some useful information! thank you @ack I would have gone crazy trying to figure that one out :-)
And in fact on reflection I had encountered this bug earlier, no sound on the unibios (slot 1 was empty)

So back to the sound distortion in slot 1 and the dead slot 4.

per the feedback from @maki I had a look at the audio system here
https://wiki.neogeodev.org/index.php?title=Category:Audio_system
The YM2610 here
https://wiki.neogeodev.org/index.php?title=YM2610
And the YM3016 here
https://wiki.neogeodev.org/index.php?title=YM3016
Since the problem is with the digital audio only YM3016 would be be my prime suspect. Except sound in all the other slots is fine, its just slot 1.

So I'm thinking that checking Slot 1 continuity, expecially for the sound pins should me my next step

MVS slot pinout here
https://wiki.neogeodev.org/index.php?title=MVS_cartridge_pinout
I'm guessing that the sound lines are "SD"?
If that's right then SDD0-SDD7, SDA0-SDA15 and SDPAXX and SDRAXX are the ones to look at first, right?
And I'm thinking that I can check continuity to the top board connectors with these pinouts
https://wiki.neogeodev.org/index.php?title=MVS_board_connectors_pinouts

Have I got that right, are the SD lines indeed the ones I need

 

[ack]

The SDD0-7 and SDA0-15 you can ignore in this case. Those are the address and data lines that go to the M1 rom on the cha board, which you already proved out as working with the diag m1 tests.

You will want to focus on the sound signals on the prog board which will goto the V roms.

Before you get too deep into probing stuff I would suggest cleaning the slot as its a common cause for static sounds.

 

[hatmoose]

Slot 1 is now fixed -I'll post my notes and pinouts later but the TL;DR was

Symptom - distorted digtial audio on Slot 1 only. Digital Audio on all other slots OK, music on all slots OK. Passed neogeo diagnostics with z80 test OK.
Solution - No continuity between Slot 1 PROG B51 and NEO-G0 at C1 on pin 8. Jumpered Slot 1 PROG B51 to NEO-G0 at C1 on pin 8 to restore clear audio to slot 1

Details
Unfortunatley there is no easy-to-follow pinout for the MV4-FT2 top board so I had to beep and guess a lot

Eventually found
SPRAD1(PROGB50) went to pin 7 of the NEO-G0 chip at position C1 on the top board
SPRAD3(PROGB52) went to pin 9 of the NEO-G0 chip at position C1 on the top board
BUT
SPRAD2(PROGB51) went nowhere when it should (I assumed) go to pin 8

Reflowed NEO-G0 at position C1, no improvement
The broken trace was actually UNDER the NEO-GO at C1
Jumpered Slot 1 PROG B51 to NEO-G0 at C1 on pin 8 to restore clear audio to slot 1

here it is after I tidied it up a little bit - I left this one as obvious as possible so I can find it easily later.


Now for the jailbars on slot 4 - this might be a bit harder as there is not such an obvious starting point. Luckily slot 3 works perfectly, so I can use that for clues.