I suspect it would depend on the function of the chip and how broken it is. I agree that it is not reliable. I don't really want to shotgun this board since the traces are pretty fine and adding sockets likely is going to end up breaking something.
-
Please post all monitor technical topics in the Technical - Videogames - Monitors section, not in the General Help section.
Rampage graphics issue.. HELP!
- Thread starter descrentl
- Start date
I suspect it would depend on the function of the chip and how broken it is. I agree that it is not reliable. I don't really want to shotgun this board since the traces are pretty fine and adding sockets likely is going to end up breaking something.
tendril
Well-known member
Yes, if anything a TTL is more likely to successfully piggy back than RAM. If the TTL has failed with 'high outputs' as Fujitsu's in particular are quite likely to do, then the piggyback can still pull the output to ground and work correctly. If the TTL has failed with internal shorts to ground, then no, usually the piggyback can't provide a high output as it itself gets sucked to ground.
tendril
Well-known member
I really wish you had a scope to put on those pins rather than a probe, as I suspect the probe is just giving you bad results perhaps due to the clock being less than 5V. Think about the problem from the other angle - if HCLK1 really was stuck going to 7F and 8F then RA02-RA15 (all your sprite ROM addresses) would also be stuck. If the LS377 is working, then it can only latch data on a clock change. From your video we know the sprite addresses are working most of the time as we can see the sprites.
Yeah. I agree. I am going to think about this a bit. I might "jumper" the clock from "good" sources to "bad" sources to see if anything happens. It won't take too long to try this and I can report back.
@tendril do you have any logic analyzer/scope recommendations? On one hand, I feel like I should just send this to Eldorado games to repair. On the other hand, this might be my chance to really debug this right. I have an advanced degree in EE so this is in my wheelhouse. The issue really is time (I have a young child).
tendril
Well-known member
DZA sent me his board, for the record here's what I did to fix it.
First I concentrated on the fact 'blocks' were missing from the sprites - this suggests a problem in the setup of the sprites (as opposed to the line buffer output).
drive.google.com
I replaced the main sprite RAM with a NVRAM - this meant I could 'capture' the sprite RAM and read it back on a PC.
drive.google.com
Which looks like this! You can compare this dump to the RAM inside MAME, but I know from the patterns it was looking good (4 bytes per sprite). This means the CPU was writing correctly to the main sprite RAM.
drive.google.com
The hardware copies the main sprite RAM to the fast sprite RAM during vblank. I would have done the same trick of capturing this RAM but my slimline adaptor didn't fit in the socket very well.
A group of three LS163 counter chips controls the address lines to the fast RAM. When I shorted some of the lines together using my probe some of the missing chunks came back - so I'm surely on the right track. I pulled the LS163's and tested off-board and all were good. When I replaced them and rechecked my work I realised there was no continuity to one of the fast RAM address pins (yeah, I should have checked this first but whatever). Went hunting for bad traces, and there it was:
drive.google.com
drive.google.com
Patched up and all good!
drive.google.com
(Technical explanation - the floating address line meant some chunks never made it to the correct destination when writing to the RAM and slightly random results when the RAM was read back).
First I concentrated on the fact 'blocks' were missing from the sprites - this suggests a problem in the setup of the sprites (as opposed to the line buffer output).
20200819_174649.jpg
drive.google.com
I replaced the main sprite RAM with a NVRAM - this meant I could 'capture' the sprite RAM and read it back on a PC.
20200817_202118.jpg
drive.google.com
Which looks like this! You can compare this dump to the RAM inside MAME, but I know from the patterns it was looking good (4 bytes per sprite). This means the CPU was writing correctly to the main sprite RAM.
20200817_202226.jpg
drive.google.com
The hardware copies the main sprite RAM to the fast sprite RAM during vblank. I would have done the same trick of capturing this RAM but my slimline adaptor didn't fit in the socket very well.
A group of three LS163 counter chips controls the address lines to the fast RAM. When I shorted some of the lines together using my probe some of the missing chunks came back - so I'm surely on the right track. I pulled the LS163's and tested off-board and all were good. When I replaced them and rechecked my work I realised there was no continuity to one of the fast RAM address pins (yeah, I should have checked this first but whatever). Went hunting for bad traces, and there it was:
20200818_171746.jpg
drive.google.com
20-08-18 12:53:07.png
drive.google.com
Patched up and all good!
20200818_183051.jpg
drive.google.com
(Technical explanation - the floating address line meant some chunks never made it to the correct destination when writing to the RAM and slightly random results when the RAM was read back).
Great writeup. Hope this helps someone else!
Well done... you wanna fix my sounds good board? Lol
