Rampage graphics issue.. HELP!

Still working this with wugly but no smoking guns as of yet. If anyone else is interested in helping I can supply better scans of the schematics. They still aren't perfect, but visibly better than the PDF's currently available. I have to have someone at work merge my scans together to make one cohesive document at which point I will share will all. I'm really learning a lot, especially from Adam's onecircuit videos on YouTube, but I have a feeling that the final fix will take some serious dumb luck or a logic analyzer to locate the exact issue.

Here is a video of the actual problem:
https://youtu.be/rHI3p6dULaA

And another with one of the sprite roms removed to show that everything else appears to be okay:
https://youtu.be/n6vIXzJt_cA
 
I suppose you've narrowed it down to the sprite rom. I didn't read all the other pages, this thread's mushroomed since I last checked in, but do you know the rom data is good? since it's the sprites that are affected, I would work outward from the rom to whatever chips the traces connect to. if you have rams that aren't pulsing on the data lines then I think you follow the traces/schematics for wherever the suspect data lines connect to. see if the chip before is throwing it off.

it's totally easier said than done, I haven't mastered the art yet, but probes are pretty enlightening. from the Adam video I saw it's all like a cause and effect thing where a bad chip in the middle will throw the next one off. it's certainly an art form!
 
Follow up question. Anyone out there with a working Rampage that has a logic probe? Being able to confirm some of our findings with a known good board would be extremely helpful.
 
we seem to have found hclk1 is shorting to ground. I know it is being generated because we can detect it but after r89 we read no clock pulsing so somewhere down line is a short. I want him to cut the trace to blocks of chips to locate the short since a lot of chips are tied to the bus and trying to remove individuals one at a time will take a long time and might not show a short to the trace somewhere.
 
wugly said:
we seem to have found hclk1 is shorting to ground. I know it is being generated because we can detect it but after r89 we read no clock pulsing so somewhere down line is a short. I want him to cut the trace to blocks of chips to locate the short since a lot of chips are tied to the bus and trying to remove individuals one at a time will take a long time and might not show a short to the trace somewhere.
Click to expand...

It is reading low after r89, but its not shorting to ground as there is no continuity between any of the hclk1 pins and ground (at least none that I have found yet).
 
ok maybe not a direct short to ground but since you are using a logic probe the voltage is probably being pulled low enough by a bad chip so that the probe reads low. once you determine where on the buss there is a drain you can then snip the leg of suspect chips to find the bad one in that area
 
That's the plan. Hoping to print out the pertinent schematics at work today on 11x17 paper for help with note taking and visibility. I should hopefully have some time tonight to start tackling this portion of the troubleshooting.
 
I finally got my game back up and running. I am going to start debugging mine. Any updates to this thread?
 
DZA said:
I finally got my game back up and running. I am going to start debugging mine. Any updates to this thread?
Click to expand...

I ended up buying an "as is" board off of eBay and got lucky with a working board. I still have my problematic board sitting on a shelf. I would love to find someone interested in fixing it, but it's definitely beyond my current skill level.
 
BozoTheClown said:
I ended up buying an "as is" board off of eBay and got lucky with a working board. I still have my problematic board sitting on a shelf. I would love to find someone interested in fixing it, but it's definitely beyond my current skill level.
Click to expand...
Thanks. I will post my journey here in case it helps someone else. Thanks for all your efforts.
 
I wanted to pick this back up. This game has been in my collection since 2016 and not working. That is by far a record for me. Time to pick this back up if nothing else to provide a log for others and to motivate me to finish this up!

Basically you can see the problem with the foreground sprites here - https://www.youtube.com/watch?v=JOCX0OTKpzw

Here is what I have done so far:

Reflowed all main PCB sockets as well as spraying DeoxIt all sockets. I pulled and cleaned the legs of all socketed chips and made sure they are reseated well (no broken legs, etc.).

I have ensured that 5V is actually at the appropriate pins of the EPROMS as a test point. I have not tested all chips but this is a baseline.

All ERPOMS have been pulled and check fine when I verify the data in them with my reader. I also wrote new foreground ROMS (8E, 6E, 5E, and 4E) and this did not fix anything.

If I pull IC 10C then all the foreground and related corruption goes away. I guess this is expected. It does provide a starting point since I suspect it is something "downstream" of this that is causing the issue.

As a shotgun method I did swap 10C, 11G, 11J, 9J, and 10K with known working versions and there was no change. I had these anyway to try.

I have the original schematics and can see that 10C (my starting point) is on sheet 17 as part of the PAC_RAM. Its output goes to the OBJ_ROM block (sheet 18).

I guess that is where I am going to start next with my logic probe.

I will report back after I go through sheet 18. If anyone has any insight, it would be great. Thanks!
 
Unfortunately I never got anywhere with mine. Plenty of helpful tips, but nothing concrete that ever fixed my issue. I was also never able to find anyone willing to do repairs to these boards. Good luck with your repair and hopefully you have better luck than I did.
 
BozoTheClown said:
Unfortunately I never got anywhere with mine. Plenty of helpful tips, but nothing concrete that ever fixed my issue. I was also never able to find anyone willing to do repairs to these boards. Good luck with your repair and hopefully you have better luck than I did.
Click to expand...
Making some progress. Are you able to confirm some logic probe readings on your machine? No worries if you can't...
 
If anyone reading this has the energy or interest, I would love to know what chip 8F pin 11 and 7F pin 9 read for you. They are both low for me but are clock signals. The clock out of 3E pin 5 is pulsing then goes through R89 and is low out of the resistor into 8F and 7F. However it is pulsing in to 15K pin 11 (which also comes from the resistor according to sheet 6 in the schematics). That seems strange to me. I suppose my logic probe might not be able to pick up the clock signal but it should be in range. Happy to explain more if anyone is interested.
 
Ha. As I read just a couple posts back, I see this is where the last person got (I am tired). Anyway, still interested.
 
I repaired one of these last year, it was a bit of a pain in the ass as loads of TTL had fried themselves.

The video from DZA has sprite addressing faults - like the missing or misaligned character pieces. I think you're right to suspect 7F and 8F as they control sprite addressing, I would also suspect the RAM but you said that tested ok? The LS163's on that page could also be suspect, if you had a scope you could see if they had 'noisy' outputs but can't do that with just a probe. Piggybacking known good 373's and 163's and see if anything changes might be the best approach.

The video from Bozo I think may be a fault in the line buffer section rather than the object section.
 
I forgot to mention that I have tried a new 3E chip and actually put a socket on 7F and put a new chip there.

I followed HCLK1 to the following chips with these results:

Sheet 6
3E pulsing - new chip
R89 low
15K pulsing

Sheet 16
13K pulsing
14H pulsing

Sheet 18
8G low
8F low
7F low - new chip

Sheet 19
9F low
9H low
11H low
14G pulsing
13F pulsing
14F pulsing
12F pulsing

As you can see a handful of the clock signals are stuck low. I was able to painfully figure out the clock tree in the attached image. It starts with 3E and then fans out going down as shown. The * are the chips that are low for me as I said in the list in this thread.

I piggybacked all the ones not working and nothing clearly changed. I will play with this more.
 

Attachments

  • HCLK1_Tree.jpg
    HCLK1_Tree.jpg
    770.7 KB · Views: 2
I also did piggyback chips 3D, 4D, and 5D with good 163s as suggested. Doesn't seem to fix it but piggybacking to me seems to be a bit of a crap shoot...
 
You must log in or register to reply here.

Similar threads

MK2 Graphics/ROM Issue
Replies
0
Views
74
grantopia28
Anthony605
Moon Patrol Graphics Issue (Level #2)
Replies
13
Views
626
vintagegamer
vintagegamer
wolfievtec
Punch Out Video Issue help
Replies
11
Views
214
wolfievtec
wolfievtec
Atari Asteroids Deluxe graphics issue with text on an angle
Replies
7
Views
287
andrewb
andrewb
magicianlord77
Atari Championship Sprint - Playfield graphics issue in certain tracks
Replies
3
Views
215
magicianlord77
magicianlord77
Back
Top Bottom