Help with dead Waku Waku 7 MVS cart

[buffi]

I have a dead Waku Waku 7 cart that just boots to Cross Hatch Test when plugged in, which I guess means that the MVS doesn't detect it as a cart. Happens on different motherboards.

I also have a working Waku Waku 7 and have isolated the issue to the prog board (by swapping PCBs between carts until I found the broken one).
I did inspect all joints through a microscope, washed the PCB thoroughly and then tried to probe away at it with a scope, but not really sure what the best way to approach doing that is.

I see some action on the address busses of the ROMs, and they both have voltages... but that's about it.
CE is LOW, OE is HIGH on all of them which means they are in "Output deselect".

Nothing looks obviously wrong, so I'm sortof at a loss for what the next step to do here is.
Desolder all roms, dump them and make sure they seem correct? Otherwise replace the ones that are not?

What would you typically check on a small board with basically just ROMs like this.

Pics of my setup:

The working PCBs running:

 

[stj]

if you have UniBios then i think it can checksum the roms against an internal list and tell you if any are bad.

 

[buffi]

if you have UniBios then i think it can checksum the roms against an internal list and tell you if any are bad.

I do, but I just get a cross hatch test, which means I dont even get that far.

I suppose Ill just check all traces manually to see if some important one is busted.

 

[buffi]

All traces were connected. Thought I'd actually just go ahead and see what more there is to do here, so I swapped PCM chip from a cheap extra cart of Tecmo World Soccer I had, but that did nothing.

Desoldered and removed the PROM chips now, so I just need to get myself a programmer to dump them and figure out if they are the culprits now I suppose.

Probably not worth spending this much time on this cart, but seems like a good learning opportunity if anything.

 

[ShootTheCore]

If the dumped ROMs check out then the PCM chip that handles V ROM multiplexing has probably died. I had the same thing happen with a Metal Slug 5 cart. If that turns out to be the case, then you can move the mask ROMs over to another PROGBK1 board donated from another game. Just match the jumpers up on the donor board to match the setup on this one.

 

[buffi]

If the dumped ROMs check out then the PCM chip that handles V ROM multiplexing has probably died. I had the same thing happen with a Metal Slug 5 cart. If that turns out to be the case, then you can move the mask ROMs over to another PROGBK1 board donated from another game. Just match the jumpers up on the donor board to match the setup on this one.

Mentioned briefly in post above, but I've actually tried swapping the PCM chip between carts.

The PCM chips dont have the exact same markings on them, but my understanding is that the PCM chips in various carts with similar prog boards should be pin compatible.

Swapping to another PCM chip didn't do anything :/

 

[ShootTheCore]

Oops, sorry I missed the part where you said you swapped the PVM chip. Dumping the mask ROMs and verifying them is definitely recommended, but let's go over proper chip behavior.

The mask ROMs for the PROGBK1 PCB match the pinout of a 27C160 EEPROM. In that case, Pin 11 is your Chip Enable (active low) and Pin 13 is your Output Enable (active low). On a properly-operating chip, one or both of those Control Lines will be set high (inactive) while the CPU sets the address lines to what it wants to read. After the address lines are set, both control lines will be set low, and the chip will output the selected data through the Data Lines (Q lines in the diagram).

So with a logic probe, when the ROM is working properly, you should see high-low transitions on one or both Control Lines, on all Address Lines, and on all Data Lines. VCC should always hold high, VSS should always hold low.

If the Mask ROMS check out after dumping them, there may be a broken trace on the PCB itself that's causing your problem. It's time consuming, but you could verify continuity on all pins to their end points with a multimeter set to continuity test.

 

[buffi]

Ok, I'm somewhat of a loss here now.

I have

- Dumped all V and P ROMs. All of them have identical checksums to the mame romset, so they seem fine.
- Tried replacing the PCM chip from a donor cart
- Checked continuity from all pins to the ROMs, and found no broken traces.
- Check continuity across all 0-ohm jumpers

Could I be seeing crosshatch due to one of the LS IC's being busted (LS74, LS08, LS139)?

My understanding of carts is (from https://wiki.neogeodev.org/index.php?title=PROGBK1):

LS139 : Used for V ROM selection

LS74 : Used for P ROM bankswitching


LS08 : "The LS08 is used to AND the /PORTOEU and /PORTOEL signals to get /PORTOE."
http://www.jamma-nation-x.com/jammax/mvspinout.html for PORTOEU and PORTOEL pins.

Sounds like a crosshatch could potentially be due to a busted LS74 or LS08.

Testing the LS08 should be easy since it's just a gate. Testing the LS74 flipflop seems harder.

Might just buy some 42 pin sockets and new LS ICs and replace all of them, socket the chips on the board and see what happens.

 

[ShootTheCore]

There are rare times when a mask ROM passes validation on a programmer but won’t actually work on the PCB. If you socket the chips, try swapping EPROMs in place of the mask ROMs one at a time.

 

[stj]

if you socket the chips, you cant get the shell back together - just be aware of that.
you may not even get the boards close enough - i cant remember though.

 

[buffi]

Oh...
Its the top board, so clearance to the other board should not be an issue, but not being able to close the cart doesnt sound like what I want :/

 

[stj]

i'm the type of person who would just cutout a rectangle from the case above each chip!!
there are collectors screaming as they read shit like that!

 

[buffi]

I'm going to:
- Replace the LS chips (quick and easy, so why not)
- Put sockets on the prog board anyways
- Try with current roms
- Burn PROM EPROMS and try switching one, then the other

If I still don't have it working after that, I'll try transplanting onto a donor prog board I guess (changing jumpers, adding LS chips, putting back a PCM chip since I transplanted the old one to the current board), then putting sockets + ROMs.

If _that_ also fails, then I dunno. I guess I'll be grumpy and give up on it. It's not something super expensive, and I already have another waku waku 7 cart

Waiting for parts (sockets, eproms and LS chips) right now, so not much I can do until I have those.

 

[stj]

you could desolder the existing roms,
read them out and check them with mame.

read them as binary BIN files,
put them in a zip (test.zip?)

put them in with mame and type "mame -romident test.zip"
and it will list them all against known roms/sets.

 

[buffi]

you could desolder the existing roms,
read them out and check them with mame.

read them as binary BIN files,
put them in a zip (test.zip?)

put them in with mame and type "mame -romident test.zip"
and it will list them all against known roms/sets.

Done this already, see Post #8 in this thread.

What I did was dump all P and V roms, then just CRC32 compare them to the roms in Mame after unzipping the waku waku romset. They were identical.

 

[buffi]

Well. Replacing the LS chips did nothing.
Time to rejumper a donor progboard then...

Dont have EPROMs to try swapping roms right now. Will take like two weeks of shipping from China.

 

[buffi]

Transplanted it onto another prog board.

Still doesnt work.

I guess I just have to wait for the EPROMs now, and see if that works. Otherwise Ill give up on this.

 

[stj]

check for shorted capacitors or bad links/resistors - it's about the only thing left.

i would say check pcb via's, but that's a very clean pcb so i doubt there is a problem with it.

 

[buffi]

check for shorted capacitors or bad links/resistors - it's about the only thing left.

i would say check pcb via's, but that's a very clean pcb so i doubt there is a problem with it.

Capacitors shouldn't be the issue, since as mentioned I transplanted everything from one PCB to another (see bottom right text below SNK logo in last two PCB pics), but didnt move any caps between boards.

Broken jumpers/resistors could be an issue though since the second board needed some additional jumpers/resistors, so I moved some from board 1. Can't hurt to check.

 

[ack]

Usually in crosshatch situations it helps to look at the memory viewer as it can give an idea of whats wrong. Normally I will scroll down to offset 000100 in the viewer as all games should have the same data there, which is "NEO-GEO". If there is corruption in that string then try to identify common stuck bits between corrupt vs non-corrupt versions of the data. If you dont find anything common then it maybe an address line issue, which is a bit more pita to track down. Here is what my waku has at that location for comparison.

https://www.mvs-scans.com/misc/IMG_0474.jpg