PC-Engine Core Grafx corrupted graphics.

Started by Eddyiori, April 24, 2008, 12:49:24 AM

Previous topic - Next topic

Eddyiori

Got this PCE of a friend that have these issues and trying to fix it. Cleaned the hucard port but no sucess. One thing is this problem also happens to the cd games. Could it be bad ram chips? Anyone have seen any like this?? Any help will be apreciated. ;D
http://youtube.com/watch?v=HLNtYW6zGrs

ken_cinder

I'm going to take a stab at saying it's the HuC6270A VDC or it's 64kb of RAM. I will await the expertise of the "others" on the board as I like playing the guessing game (It's fun).
If I'm right though, you should probably be able to salvage either out of any PC Engine hardware rather than trying to replace that specific unit.

l_oliveira

That look like VRAM addressing error.
And I can't tell if the background is corrupted too, due to artifacts on the video compression but if I were you I would look for rusty copper tracks on the PCE main board. A good place to start would be the area surrounding the graphics chip and it's 62256 ram chips.

Depending on how the graphics glitch you can have a idea of which address/data lines are failing. If it were data lines you would see vertical lines on the "blocks" that form the screen, instead of seeing them moving randomly. Other possibility is addressing error on the name table for the blocks (Is that stored into the VRAM chips or into the HuC6270 ?

As I don't know much about PCE programming myself, I can only toss in rough guesses.

Anyway there is a good way to test if you have an faulty copper track on your board:


|------------------------------|\/\/\|-----------------------|---------------------
^-- connect to +5v         ^--10k ohm resistor       ^--needle

Touch the needle (with +5v pullup signal) onto all the SRAM pins and if there is a faulty track on your board, in the exact moment you connect the pull-up to the pin which is "floating" (due to cut copper track) the screen will stop to flick and the image will be solid (even if it's still glitched but it will be solid anyway).   That will allow you to know which pin you have to follow without using an O-Scope to track the signals.  It's possible to follow the track optically on most cases.

Hope this information is useful.

l_oliveira

Can't edit my own post :\



|------------------------------|\/\/\|-----------------------|---------------------
^-- connect to +5v||||     ^--10k ohm resistor||||||||||   ^--needle

Just to explain this drawing better it's a pair of wires with a 10k resistor and a needle on the tip so you can "probe" the pins on the SRAM inputs/outputs without short them to +5V or GND.  Also this "tool" can be used on any other system (Including arcade boards) to help with tracking down problems on graphic buses.

ken_cinder

Quote from: l_oliveira on April 25, 2008, 10:43:05 AM
Can't edit my own post :\



|------------------------------|\/\/\|-----------------------|---------------------
^-- connect to +5v||||     ^--10k ohm resistor||||||||||   ^--needle

Just to explain this drawing better it's a pair of wires with a 10k resistor and a needle on the tip so you can "probe" the pins on the SRAM inputs/outputs without short them to +5V or GND.  Also this "tool" can be used on any other system (Including arcade boards) to help with tracking down problems on graphic buses.

A bit off-topic, but I have a double dragon PCB that has corrupt background (Red lines through 1 layer), I could use this to probe the chips where this data would be stored, to figure out what's causing it?
How would I do this? Isn't that bg loaded once into RAM? Where would I probe while powered in this case?

l_oliveira

In the 80s the hardware would read directly from the roms (It was slow enough and RAM was also expensive enough to keep developers from doing so) then copy ALL the data to a "rendering buffer"  (By all data I mean everything already added, BG + OBJ + TEXT) and then push through a latch and the D/A converter for video, which usually is a array of resistors (R2R Digital to Analog converter).


You should check the data lines for the BG roms (which are usually separated from program roms) if they go to a buffer chip as it could either be blown or it's output or input is faulty. Or the hardware that adds the layers of the video (priority controller) is damaged. Usually on botleg boards it's a bunch of TTL chips but on original boards it's a custom ASIC.

You can use the "probe" for testing your arcade board but first you should track the data lines from your board ROMs and see where they go to, so you have a idea of where to go probe.