Ms. Pacman no characters on screen

danzig8155

New member
Joined
Aug 30, 2009
Messages
181
Reaction score
1
Location
Martins Ferry, Ohio
I have a ms. PAC board that has no ms. Pac or ghosts on screen. You can play the game and see the maze and dots, just no characters.

Found a few sites to diagnose this and one said to check for short between pin7 and pin10 at 2E. Sure enough they're shorted. My question is now what? Replace the chip or is it fixable?

Anyone have any other suggestions. I know it sounds like a dumb question, but I'm having a serious brain fart here I think.
 
I would most likely check to make sure what's on the eproms aren't corrupt first before I would get into anything major.
 
I have a eprom programmer that I use. They are fairly inexpensive and work well. Not to mention if you want you can write your own eproms if anything is corrupt. I insert the eprom into the read/writer and compare the checksum with the mame rom for that specific eprom. If the checksum matches then your good. If it's different then you know what's on the eprom is corrupt and needs to be replaced.
 
I have a ms. PAC board that has no ms. Pac or ghosts on screen. You can play the game and see the maze and dots, just no characters.

Found a few sites to diagnose this and one said to check for short between pin7 and pin10 at 2E. Sure enough they're shorted. My question is now what? Replace the chip or is it fixable?

Anyone have any other suggestions. I know it sounds like a dumb question, but I'm having a serious brain fart here I think.

Check for anything bridging the pin along the traces. If all looks good you're going to have to isolate the one of the pins from the board. Cutting a trace on the board that you'll have to repair eventually... Removing the chip and testing it out of circuit... Cutting the leg on the chip between the IC and board and lifting the leg a little and testing it for shorts again. Between the 3, I'd just cut the leg, lift it and test it. If it's good you can just bend it back down and tack it back in place with a bit of solder. Quick, dirty, and effective.

The EPROMs I wouldn't worry about. With everything on those chips, you'd see at least something on the screen and the odds of it just effecting a couple of things entirely and nothing else... not too likely.
 
I have a eprom programmer that I use. They are fairly inexpensive and work well. Not to mention if you want you can write your own eproms if anything is corrupt. I insert the eprom into the read/writer and compare the checksum with the mame rom for that specific eprom. If the checksum matches then your good. If it's different then you know what's on the eprom is corrupt and needs to be replaced.

I've seen eproms report the same checksum but have a few bits that are off, causing problems.

Darthi8nt has seen this too.
 
Really? If it's even 1 byte off it should have a different checksum. Seems like a software bug to me if that's the case. o_O What hardware were you guys using and what software?
 
Last edited:
Really? If it's even 1 byte off it should have a different checksum. Seems like a software bug to me if that's the case. o_O What hardware were you guys using and what software?

From this webpage:

http://www.advin.com/faq-device-programmer.htm


[SIZE=+1]Section 1. Checksums[/SIZE]


How are checksums calculated? For memories and micros, the most common methods are:
(A) Adding data as bytes
(B) Adding data as words

(A) Adding data as bytes

This is the most commonly used method. The data is added as bytes, and the result is accumulated in a double word. (Double word means 2 words, or 4 bytes, or 8 hex digits.)

For example, if there are 4 bytes in a device, and the data is:
11
80
22
90
The checksum will be: 11+80+22+90=00000143

Note that if these 4 bytes are IN A DIFFERENT ORDER, the chksum still comes up to be the same. That is why a chksum is good to be used IN GENERAL to distinguish different versions of firmware but is NOT a good way to tell if two chips contain EXACTLY the same data or not.

Older programmers and programming s/w retain only the last 4 digits, as 0143. That is why most EPROMs are marked with only a 4-digit checksum. (which is deemed sufficient for most customers and is convenient to copy, save and read by a human being.)
 
What hardware are you using because the hardware and software I use doesn't calculate a checksum like that. At least not from what I remember. I may have to get out a eprom and check it out on my end.

Even at that you would still be able to use something totally different for producing a checksum no matter what type of file it is. For instance md5 or even sha-1 if you wanted to. I'll check out my theory if you want me to test it.
 
Last edited:
I was talking to Darthi8nt on the phone about this a few weeks back. He said that his eprom reader was reporting a checksum that was the same on two different eproms he had. One worked, the other one didn't.

When he looked into the rom's binaary file, he saw one bit was off. It didn't change the checksum, but it did cause problems.

I had a similar situation come up. I had an eprom that I programmed report the correct checksum, but it didn't work. I erased it, re-programmed it, verified the same checksum again, and the 2nd time, it worked.
 
Right, but what did you use to check the checksum? What software?

http://support.microsoft.com/kb/841290 anything at all that changes and the checksum changes and is reliable. I could even go in with a hex editor and change 1 byte if you want me to and see how reliable it actually is.

C:\checksum>fciv "C:\kinst\kinst.chd"
//
// File Checksum Integrity Verifier version 2.05.
//
c55d552c3a698f839d32c41203213dc9 c:\kinst\kinst.chd

C:\checksum>
 
Last edited:
Check out the rams eclipseye mentioned and the chips below them. The 74161 counters are another suspect. If your character rom was bad or out of circuit you should see colored blocks moving around in place of the characters. Im not saying rule out the roms or their sockets but usually they wont cause the characters to disappear completely.
 
Back
Top Bottom