What's new
By:
Filters

"Sparkles" in graphics on specific game cartridge (Bomberman - conversion or repaired).

Kujako

Kujako

Champion
Joined
Jun 3, 2020
Messages
1,335
Reaction score
788
Location
USA, California
Dusting off a few more backlog repair items. Have a Neo BomberMan that exhibits bad pixels on some of the graphics and screens.
1673283814745.png

(hey, my capture setup works!)

Two eproms, but the rest looks correct. So thinking this was repaired at some point.
1673284904195.jpeg


Before I try swapping out the eproms, anyone have any ideas what else to check?
 
Last edited:
Going to go ahead and replace the C1 EPROM. Unfortunately, I'm remembering what a PITA it is to burn 4Mb EPROMS and I suspect my limited stash of M27C322 chips are fake (failed the IPA test and I see double printing).
IMG_1392.jpg

Got the old chip off without too much hassle. Pads and traces all look OK.
IMG_1391.jpg
 
So went ahead and burned a new C1. Split a ROM dump I found and did eight passes to populate the 4MB 27C322 (despite my trepidation about their legitimacy, they seem to work).
1673623428596.jpeg1673623443597.png

This produced two results.
1: the sparkles are gone
2: there are a lot of other issues.
1673623553105.jpeg1673623572253.jpeg

So I think I'm on the right track, but I failed to correctly replace the EPROM.

I can think of a few possibilities.
1: I messed up the splitting and multi-step programming.
2: The EPROM is bad.
3: My source image is no good.

To address the last of these, anyone have a known good C1 image? Mine has a MD5 checksum of 81c2d971e2432a6d89b204e0a87d33a1

Thanks,
 
ekorz said:
Mame doesn't list MD5 but maybe you can run one of these

CRC d1f328f8
SHA1 ddf71280c2ce85225f15fe9e973f330609281878

https://github.com/mamedev/mame/blo...608d7d0afed5/src/mame/neogeo/neogeo.cpp#L6532
Code: 
ROM_LOAD16_BYTE( "093-c1.c1", 0x000000, 0x400000, CRC(d1f328f8) SHA1(ddf71280c2ce85225f15fe9e973f330609281878) ) /* Plane 0,1 */ /* TC5332205 */

My bet is #1, you put one or more banks in the wrong spot
Click to expand...

Thanks, found that one from another source as well (matching CRC). Will give it a try.
Code: 
crc32 ./093-c1.c1
d1f328f8
 
ekorz said:
Mame doesn't list MD5 but maybe you can run one of these

CRC d1f328f8
SHA1 ddf71280c2ce85225f15fe9e973f330609281878

https://github.com/mamedev/mame/blo...608d7d0afed5/src/mame/neogeo/neogeo.cpp#L6532
Code: 
ROM_LOAD16_BYTE( "093-c1.c1", 0x000000, 0x400000, CRC(d1f328f8) SHA1(ddf71280c2ce85225f15fe9e973f330609281878) ) /* Plane 0,1 */ /* TC5332205 */

My bet is #1, you put one or more banks in the wrong spot
Click to expand...
So good news, that C1 ROM seems to work. Bad news is that it did not fix the issue.
vlcsnap-2023-01-13-10h37m23s146.pngvlcsnap-2023-01-13-10h36m58s865.png

At first I thought I was golden as the boot screen looked right. But after power cycling the issue returned there as well.
vlcsnap-2023-01-13-10h36m29s502.png

So I'm kind of stumped.

Edit: Will see about replacing the M1 EPROM. Whomever did this originally used a M27C256B rather than a 27C1001 or 27C010. The M27C256B is slower I think, at 120ns. So wondering if that's the root cause here. Think I have some 70ns 27C010s around here someplace.
 
Last edited:
M1 is not graphics content. Have you measured your 5v line recently? (also that image looks fine, am I missing something?)
 
ekorz said:
M1 is not graphics content. Have you measured your 5v line recently? (also that image looks fine, am I missing something?)
Click to expand...
This issue is only with this cart, and was called out as a defect when I got it by the seller. 5v is fine on the various rigs I've tested it in with different power suppliers and MVS boards, everything works with any other cartridge in my pile. If you look at the "HOW TO PLAY" screen above you can see some red pixels on the green grass. This sort of noise is found throughout the game, but not always as shown in the last picture of the logo. It may be that another of the mask ROMs needs replacement. But because it's inconstant I'm starting with the existing repairs. I had hoped it was the C1, as that would make the most sense. But, I have heard that slower program ROMs can cause issues as well. And it's easy enough to swap out the 27C256 for a 27C010 and see what happens.
 
Well M1 is the z80 audio program code, so that's not it. You may have had a couple faults going on, but in that first screen with "countdown" on it, it looks like one color of the palette is coming back wrong. I could be in error, as I haven't tested it in mame, but all the pink spots look like edges of letters, and usually they would pick a different shade of color to help with making letters look round (sort of an alias effect). That code would be the P1 chip.

If you wanted to load up the screen in mame, pause it using the pause dip, you could start goofing around the the palette memory to be sure. Or you could just shotgun the P1 chip, hey.

(also I'm sure you have, but make sure the contacts are all looking good on the cart edges)
 
ekorz said:
Well M1 is the z80 audio program code, so that's not it. You may have had a couple faults going on, but in that first screen with "countdown" on it, it looks like one color of the palette is coming back wrong. I could be in error, as I haven't tested it in mame, but all the pink spots look like edges of letters, and usually they would pick a different shade of color to help with making letters look round (sort of an alias effect). That code would be the P1 chip.

If you wanted to load up the screen in mame, pause it using the pause dip, you could start goofing around the the palette memory to be sure.
Click to expand...
I am regrettably totally not setup to run anything in mame. Haven't done anything in emulation in years. I don't think it's just a pallet swap problem because the bad pixels are not static. But I could definitely be way off on that, kind of out of my depth on this one.

Here's a quick video capture of the title screen showing the problem. The graphics are static, but the effected pixels flicker and have the wrong color value.

Or you could just shotgun the P1 chip, hey.
Click to expand...
What EPROM would I use for that? I only have V, M, S and C in my notes.
 
Do you have a unibios? I think it can run a checksum on the program rom.

And oh I see the colors changing now, that's not great. But yeah, also not a palette issue (well, not ONLY a palette issue).
 
Last edited:
ekorz said:
Do you have a unibios? I think it can run a checksum on the program rom.

And oh I see the colors changing now, that's not great. But yeah, also not a palette issue (well, not ONLY a palette issue).
Click to expand...

I know how to get to the cart CRC, but that's not broken out into the individual ROMs. Interestingly, I see the corruption in the UniBIOS menu graphics... wondering if this is an issue with a capacitor or other part of the PCB outside of the ROMs.
1673647342811.jpeg

Edit: You know what, never mind... realizing I had already removed the M1. But that the corruption is there would indicate that that's not it.
 
The CRC is checking P1 only. So that is at least part of the problem!

27c800 is the replacement chip, but…

For p1 I like 29F1615 since they’re cheap, electronically erasable, and look more like the original mask rom — but 27c160 is also fine. The file is 8mbit and those chips are 16mbit so you’d write the p1 file to each of the 2 banks.

You could use 27c322 also, writing the p1 file to each of the 4 banks.

(Also and again M1 is z80 audio code so yeah no way it influences pixels.)
 
Last edited:
ekorz said:
The CRC is checking P1 only. So that is at least part of the problem!

27c800 is the replacement chip, but…

For p1 I like 29F1615 since they’re cheap, electronically erasable, and look more like the original mask rom — but 27c160 is also fine. The file is 8mbit and those chips are 16mbit so you’d write the p1 file to each of the 2 banks.

You could use 27c322 also, writing the p1 file to each of the 4 banks.

(Also and again M1 is z80 audio code so yeah no way it influences pixels.)
Click to expand...

I'll see what I have in my EPROM drawer. But, since I'm making unforced errors like removing the M1 and then testing the board I'll wait until tomorrow.

Thanks,

Edit: @ekorz just to be clear (I seem to be slow today, long week) the CRC check from UniBIOS is checking the P1 ROM? If so, then that's definitely the issue since I get different values each time I test it... and as for MX29F1615 chips, I don't see any direct support for them in my EPROM burner (Tl866ii+) but I may be missing something.
 
Last edited:
CRC check on unibios just checks the program code in banks. There’s only one program bank on your game, P1, the first bank of 1mbyte/8mbit.

D2B251E6-18F5-4FEB-8512-929E801DA146.jpeg
 
ekorz said:
CRC check on unibios just checks the program code in banks. There’s only one program bank on your game, P1, the first bank of 1mbyte/8mbit.

D2B251E6-18F5-4FEB-8512-929E801DA146.jpeg
Click to expand...

Thanks, then as I said that's definitely a problem since I get difference CRC values each time I run it. So, will look at pulling and replacing it this weekend (if I have an appropriate EPROM).
 
So tried a 27C160, had to split the 1Mb image into two 512Kb files and wrote them both twice to the appropriate segments. But this seems to have not worked. It either boot loops or throws an illegal instruction error.
1673730840256.jpeg

What's more I'm still getting different CRC values each time I run the test out of UniBIOS. @ekorz any other ideas, or thoughts on what I did wrong with the 27C160? If I had just miss-programmed it, I would at least expect to have consistent (if wrong) CRC values. I can't see anything that looks damaged or otherwise problematic on the board. All traces and vias look OK, and while I've not tested them all the ones I have all had the expected continuity. Same with the capacitors and resistors. No shorts or other issues that I can find.
1673731886013.jpeg1673731931663.jpeg
 
If you’re writing 512k banks, you split it (A B) and write each twice. A B A B. The chip is 2mb and you have to fill it.

Might have to adjust caps.. lemme grab a photo
 
ekorz said:
If you’re writing 512k banks, you split it (A B) and write each twice. A B A B. The chip is 2mb and you have to fill it.

Might have to adjust caps.. lemme grab a photo
Click to expand...
Yeah, that’s what I did (or at least what my intention was). Not overly worried about the eprom failure given that I get inconsistent CRCs, thinking the failure must be elsewhere. Just stumped as to what would cause this sort of read failure. What I might do is check the voltage at the P1 and see if it seems OK.
 
You must log in or register to reply here.
Back
Top