Pacman Repair - thoughts?

Calphool

New member
Joined
May 29, 2023
Messages
10
Reaction score
2
Location
Iowa, APO/FPO
Hello,

I'm working on a Pacman repair. I've attached a screen shot. The CPU is in a reset loop, so it's having trouble kicking the watchdog, that much is plain.

I have a Teensy based Z80 emulator that lets you do stuff kind of like a Fluke 9100A. Using that I can see that I can read all the ROMs okay and their checksums are good. However, when I write anything to RAM, either vram or cpu ram, it always returns as 0xFF when I read it back. So it *seems* like that would be easy to sort out, but after replacing the 2114 video ram, it's still the same.

So, I put the scope to the bus sync board and started trying to figure out if it's in there. There is a 74LS244 in there which seems like it would be a likely candidate, but nothing changes when I replace it. I can see the chip select line for the bus sync board toggling when I read or write to ram at 0x4000, so I know that much is getting to that bus sync board.

Can anybody explain how the bus sync board on pacman actually works? It's got a line going to the wait line on the cpu, and it's got lines that loop back into itself. It's not exactly obvious what it's trying to do. Clearly *part* of what it does is just normal data line buffering, but what is all that other stuff it's got going on?

If anybody has any ideas on how to proceed more quickly than tracing every single line from the CPU to the RAM I would appreciate the benefit of someone's experience/wisdom. I haven't worked on Pacman before.

Thanks!
 

Attachments

  • 20230525_174517.jpg
    20230525_174517.jpg
    2.4 MB · Views: 18
I think what it does is synchronize access between the CPU and the video subsystem so that they're not both trying to access VRAM at the same time? If it's not working right, then you will get clobbered RAM addresses and data. So I think you are on the right track.

Do you have another sync buss controller card? Easiest test would be to pop a known working one in and see what that does.

Otherwise you'll have to work through it.

I had a problem with one of the 74LS74s on mine (it was Jr. Pac Man actually but the circuit is the same). It was still working but out of spec I guess.
 
So I acquired a working Pacman board. I substituted the sync bus board, and it made absolutely no difference. I could swap the sync board back and forth between the working and screwed up board, and the working board worked, and the screwed up board didn't. So that eliminates the sync bus board itself. So then I started wondering if the inputs to the sync bus board was different. I captured a scan of all 28 pins from both the sync bus board of the messed up and the working PCB (using pin 27 as the trigger, which is the chip select). Each scan was captured using a Fluke-like Z80 emulator. Basically the emulator was just instructed to Write 0xFF to address 0x4000, and I captured what happened on all 28 pins.

What I see that strikes me as different is pin 3. It seems to be inverted. In 12 and pin 13 seem to be different as well. There are some other minor differences. Pin 3 is H2, but I'm not quite sure how in the world it could be inverted. It originates at 3R, which I replaced, but it didn't make any difference.

Any thoughts?
Sync_Bus_Comparison-1.pngSync_Bus_Comparison-2.pngSync_Bus_Comparison-3.pngSync_Bus_Comparison-4.pngSync_Bus_Comparison-5.pngSync_Bus_Comparison-6.pngSync_Bus_Comparison-7.png
 
I'm working on a Pacman repair. I've attached a screen shot. The CPU is in a reset loop, so it's having trouble kicking the watchdog, that much is plain.
You have multiple problems going on...
In the graphics section there are stuck/shorted address bits going to the video ROMs (or the video counters that drive them) causing the replication, and likely a problem addressing the CRAM as well, given the apparent duplicate chars in adjacent columns.

All that is independent of the code not executing -- one of the first things the code does is wipe the CRAM, and that's clearly not happening.

Can anybody explain how the bus sync board on pacman actually works? It's got a line going to the wait line on the cpu, and it's got lines that loop back into itself. It's not exactly obvious what it's trying to do. Clearly *part* of what it does is just normal data line buffering, but what is all that other stuff it's got going on?
U5 is only used when writing to RAM, and has nothing to do with your problem.

U0 asserts /WAIT on the Z80 if the CPU tries to read RAM when the video circuit is using it (2H low).

U4 times pulses for read/write based on 1H and 6M.

U2 latches the U0 outputs and gates them with U4 pulses make read/write pulses & clocks for the RAM w/ U2.

U6 latches the data bus at the end of each CPU 2H cycles for buffered readback during video cycles.

U0/U7 latch are used in interrupt handling, and the code isn't getting far enough for that to matter.

If anybody has any ideas on how to proceed more quickly than tracing every single line from the CPU to the RAM I would appreciate the benefit of someone's experience/wisdom. I haven't worked on Pacman before.
Get normal video garbage first...

Not being able to read RAM is likely to be something to do with 4H, assuming you're actually getting the 2H clock to the SBC.
 
@Calphool do you have the ability to burn 2532s or 2716s (or 28C16s)? There's a Pac Man diagnostic ROM floating around that might be of some help. I got a couple of very simple ROMs I've written as well that could be useful.
 
After doing a bit of shotgunning, I'm now looking like this. The graphics "shimmer" with random noise wherever a character should appear. It does get through the startup process now, though I can tell that the graphics are messed up as it's doing it. I have not swapped my Z80 emulator back in, but I suspect that if I do I can probably now read and write to memory, or at least CPU ram. I'll do that next to confirm my current RAM situation, which is apparently different than it was (though I'm not altogether sure which chip caused it to change -- I *think* it was when I swapped 3R, which is confusing because I had *already* swapped it.)

Since I can't read what the screen is trying to show, I'm *guessing* that it's trying to tell me that it's having trouble reading or writing to somewhere.

In answer to @jeema's question, I do have the ability to create 2532s. So yeah that's a good idea, trying one of the diagnostic ROMs.

pacman_20230617_102139.jpg
 
Got this working, after much gnashing of teeth.

Although it doesn't look like it, the screen above is actually the screen right after you drop a coin in, it's just scrambled. The game's dip switch was set on free play, so it was waiting for me to press Player 1.

As far as the fix goes, the board had had prior work by someone who wasn't great at soldering. When I got it to the point of the screen above, I could tell that my problem was definitely related to the character ROM (5E) because I could read and write to all of the RAM space (using the MCLZ8 ICE/Z80 emulator) and I could see the effects of writing to VRAM on the screen (things were just scrambled). So that meant that the problem was somehow related to the retrieval of character rom data and transfer of that data to the rest of the video circuit for display.

I started scoping the legs of 5E to make sure that the addressing and data lines made sense. A couple of the data lines appeared to have cross talk. So I removed 5F and 5E, which should have made the data lines float, but sure enough some of them weren't floating. So I desoldered the sockets that had been installed, and I could see that there were solder blobs that had connected some of the address lines to data lines on the top surface of the board where the socket legs went into the board. There are some very fine traces that try to go in-between the legs of the sockets, and they don't have any solder mask on them. So, after removing the sockets and cleaning all that up, I lacquered the traces that pass between the legs with a fine brush, and then soldered new sockets in. Tested with a scope, and all of the data lines were floating as expected. Put 5F and 5E back in, and it was *almost* working correctly, but periodically the the sprites would scramble. I noticed that if I pressed on the center of the PCB it would correct the scrambled sprites. So, I figured I had a cold solder joint somewhere. I reflowed all of the solder joints. No dice, same problem. So, I got my scope out, looking for a signal that changed when I flexed the board. Found one on the socket that held the VRAM addresser (pin 21). Reflowing it didn't seem to make any difference. Then I looked very closely at the traces that ran to that pin, and one of them seemed to have a bit of a bubble in it under the solder mask. It appears that it had a hairline break in the trace somewhere, probably near the bubble. I ran a bodge wire for that trace, and voila, problems gone.

So this board had multiple issues. I bought it off ebay, so I'm guessing it was sitting in someone's dead pile because they had given up on some faulty repair work. Main issue was probably 3R or 3S, though I had changed those out already, so that's still a bit of a head scratcher. Once those were working, then the issue was some bad solder work on 5E and 5F. Finally, there was the scrambled sprite problem due to a broken trace to the VRAM addresser. I sort of wonder if the board ultimately ended up in the repair pile because of *that* problem, and everything else was subsequent damage by someone who wasn't good at fine soldering.
 
Last edited:
Back
Top Bottom