|
|
Post by gjaky on Jan 17, 2014 8:39:42 GMT -5
Here is a tough one. So I have increased the scanrate of my 6PG xtra, with rewriting the BIOS EPROM borrowed from a 9PG xtra. The system pwb in the 6PG xtra is a PWC4045, in the 9PG xtra it is PWC3964, but I couldn't find any difference by the look. The eeprom swap really extended the scanrate, but an interesting side effect occured since then. With the test patterns the vertical lines are much thinner than earlier, while I could clearly see the vertical lines but wasn't comfortable to set the convergence with that. So I decided to look at the bottom of this. I noticed that initially the vertical lines were varying in the thickness between the normal and the thin state, and slightly moving the sys board had effect on the degree of varying, then it seemed that it settled in the thin state, and the jiggle had no effect anymore. I was pretty sure that the main reason wasn't the software change, since the the two bios have the same base version, and the content only differing in one bit. But to be sure I changed from the other board the two socketed flash roms, without succes, so I put back the original roms (which are newer version anyway), and this is where it became more complicated. After that there wasn't menus and test patterns, see video: So, I pulled the board and checked the service manual where are the OSD and test signals coming etc, so resoldered the row connector's appropriate part, bent the pins slightly to not bo back the motherboard the same way, deoxited the pins -> no joy. So I actually resoldered the Xilinx PLD (IC8255) where the signals are coming, and the two VRAMs (IC8252, IC8254), So now the menu is quite ok, the vertical line thickness of the test patterns is ok, but now I am missing vertical bars from the test patterns (but not from the menu), jiggling the board still has quite much effect on these. Look at the two pictures below, first is the cross hatch pattern, the other is the white window pattern.   |
|
|
|
Post by mastertech on Jan 17, 2014 16:46:13 GMT -5
I have had quite a few of these system boards with menu issues and I always had the same solution. Not sure if it will solve yours but it is a known problem place to start. The problem has always been C371 and it leaking. I would assume you have already changed this cap but it may have leaked prior to changing and slowly eat away at the traces. The ones I found with menu issues always had damaged traces and had to be replace with wires. Use the schematic to test all traces related to C371, Q223, D243, R397 and R396. And any other traces on that circuit location. Flexing the board maybe making occasional contact. Let me know how you make out.
|
|
|
|
Post by gjaky on Jan 17, 2014 17:52:06 GMT -5
Thanks, now it's late here, but will check it tomorrow. On a sidenote I want to notice that whenever I had a problem with this NEC the first suspected parts were the caps, but in fact simply recapping never helped with this machine, this is from '96, so quite new. I can tell from my memory, there is no leaking cap on that board, but will check the part you said.
I didn't say it in the original post, but I noticed an interesting thing connected to this, and may help to understand the cause of the problem. When the signal entry name is displayed normally it has a black outline and the text is white, but with this problem I noticed that the black outline is missing from the text (more accurately: only where the white is missing from the testpatterns), the white text is unaffected, and this is interesting because with the test patterns the white parts are missing, and I haven't noticed any problem with the menu lately.
|
|
|
|
Post by gjaky on Jan 18, 2014 16:39:01 GMT -5
The traces are seems to be in great condition, I checked all those things you said, resoldered them along with a bunch of other parts, without much success. Checked with oscilloscope that IC255 already puts out the false test signals (pin 26), along with false blanking signals (pin 27) and flexing the board is solving the problem, I also noticed that this blanking signal affects the adjustment text outline as well, but not the menu box, so that must be originated elsewhere...
So what we know so far: IC255 converts digital data to analog signals (edit: the data is actually the lit pixels that is a parallel data, and it is converted to serial data- 1bit analog ), the data is read from IC252 and IC254, the RAMs getting their content from main D (data?) bus, while their get the address from IC249 which is probably the sync processor as well. The output is periodically bad on both test signal output, and both text outline blanking output. A little more insight would be great as at this point I'm not sure if this problem is a missing dataline somewhere, or either PLD getting a false configuration command (again due a missing line). The pattern now looks like the on/off bars have about equal width, so about half of the test pattern data is missing.
|
|
|
|
Post by mastertech on Jan 18, 2014 17:57:29 GMT -5
I see that 252 and 254 are your storage ram for these processes. It is know that in these dual ram arrangements, sometimes control odd and even data signals and an issue with 1 can cause data screen problems in lines, as in, all/some odd lines have an issue or all/some even lines have an issue. Does your problem appear to be an odd or even line data symptom? It may not be every odd or every even line but will have some consistency in this appearance.
|
|
|
|
Post by gjaky on Jan 19, 2014 3:40:15 GMT -5
I see that 252 and 254 are your storage ram for these processes. It is know that in these dual ram arrangements, sometimes control odd and even data signals and an issue with 1 can cause data screen problems in lines, as in, all odd lines have an issue or all even lines have an issue. Does your problem appear to be an odd or even line data symptom? It may not be every odd or every even line but will have some consistency in this appearance. No, in vertical plain it all seems good. Look back the first post, the picture with the white box pattern, the thing has worsened since then, now it looks more like the white and the black bars are equal in width but this is only in the horizontal plain. Took a look recently on plain PG's system board schematics and there is more help: IC255 is not there instead shift registers doing the p/s conversions, and in that setup from IC254 comes the blanking and test signals, from IC252 the OSD, that makes sense here too! |
|
|
|
Post by mastertech on Jan 19, 2014 9:48:45 GMT -5
I was not inferring scan lines in the odd and even comment. It was to infer odd and even in the data realm which could be in either or both the horz or vert plane. I was relating this to your 1st post images.
And since it is flex affected I was suggesting to just touch up the solder joints on these devices. I will look at schematics later to see what you are referring to.
|
|
|
|
Post by gjaky on Jan 19, 2014 14:10:50 GMT -5
I was not inferring scan lines in the odd and even comment. It was to infer odd and even in the data realm which could be in either or both the horz or vert plane. I was relating this to your 1st post images. And since it is flex affected I was suggesting to just touch up the solder joints on these devices. I will look at schematics later to see what you are referring to. Then, I'm not sure on this even/odd data thing, but please take a look on the PG plain schematic... Until then here are a couple other shots: Adjustable menus have no blanking when source is active at the back, note the dots are not equally clipped, their first scanline is longer.  With test pattern at the back the menu looks this way:  |
|
|
|
Post by gjaky on Jan 19, 2014 14:16:44 GMT -5
This is with 480i, again note the jittery effect, the thin bites appeared randomly at that column.  Oh, I resoldered every components in this part of the circuit already, I hope in that if we understand more the circuit we can find the problem more exactly not by random resoldering, because there are pretty much to solder  |
|
|
|
Post by mastertech on Jan 19, 2014 21:33:57 GMT -5
Grab your DMM and put it on ohm scale. Locate ic249 and ic255. Test between ic249, pin 44 and ic255, pin 28 and look for close to 0 ohms. Test high on the leg so you are testing through the solder pad.
Next test between ic255, pin 26 and connector SV, C13 and look for around 23 ohms. Again, test high on the legs.
Last, test between ic255, pin 26 and connector SV, C1 and look for around 1.8 Mohm.
Let me know your results.
|
|
|
|
Post by gjaky on Jan 20, 2014 4:13:19 GMT -5
Grab your DMM and put it on ohm scale. Locate ic249 and ic255. Test between ic249, pin 44 and ic255, pin 28 and look for close to 0 ohms. Test high on the leg so you are testing through the solder pad. Next test between ic255, pin 26 and connector SV, C13 and look for around 23 ohms. Again, test high on the legs. Last, test between ic255, pin 26 and connector SV, C1 and look for around 1.8 Mohm. Let me know your results. I checked those earlier and they were ok, however now I think I found the problem. The dataline between IC254 and 255 (TD4 through TD7) was the problem. First time when I resoldered those ICs I noticed that some of the solder pads literally throwed off the solder when I touched with soldering iron, though they looked ok before, after that the copper looked dark brown (not a good sign), never mind resoldered anyway, and it seemed the new solder was wetting it right after the activation of the flux. Now, as I found out the connection on these datalines are not working I resoldered again the affected pads, and it again dropped off the solder (however looked good again) but now it measures good too! (I used leaded solder throughout). So I got back the good test patterns and flexing the board have no effect anymore. Thanks for the assistance!  |
|
|
|
Post by mastertech on Jan 20, 2014 11:56:27 GMT -5
Hmmm, I seem to remember someone mentioning here that a solder joint on a ram chip could be causing this problem a few posts back, LOL. Good job. Glad you found it.  Do you get the odd and even data line reference now? |
|
|
|
Post by gjaky on Jan 20, 2014 13:20:28 GMT -5
Hmmm, I seem to remember someone mentioning here that a solder joint on a ram chip could be causing this problem a few posts back, LOL. Good job. Glad you found it. Do you get the odd and even data line reference now? I think I got, but after foundout how this works it was a bit hard to fit this odd/even thing on it in my mind. |
|
|
|
Post by mastertech on Jan 20, 2014 16:15:54 GMT -5
Then don't think of it as odd/even. Think of it as each ram chip handles half the data. Doesn't matter if it's ( 1 chip handles 1st frame, 2nd chip handles 2nd frame and so on) or ( 1 chip handles first string of data and 2nd chip handles 2nd string of data)or (1 chip, byte 1 and 2nd chip, byte 2 and so on). It all depends on how the firmware is written to divide the data between the 2 chips. This was at a time when ram was not very large in capacity so it had to be divided up between multiple chips. Newer, larger ram may only require 1 chip to handle all data. So in a 2 chip version, if 1 ram chip is not able to handle all of it's assigned data you will get spotted problems in your display with some sort of consistent pattern, which you did appear to have.
Does that help?
|
|
|
|
Post by gjaky on Jan 20, 2014 16:47:39 GMT -5
Then don't think of it as odd/even. Think of it as each ram chip handles half the data. Doesn't matter if it's ( 1 chip handles 1st frame, 2nd chip handles 2nd frame and so on) or ( 1 chip handles first string of data and 2nd chip handles 2nd string of data)or (1 chip, byte 1 and 2nd chip, byte 2 and so on). It all depends on how the firmware is written to divide the data between the 2 chips. This was at a time when ram was not very large in capacity so it had to be divided up between multiple chips. Newer, larger ram may only require 1 chip to handle all data. So in a 2 chip version, if 1 ram chip is not able to handle all of it's assigned data you will get spotted problems in your display with some sort of consistent pattern, which you did appear to have. Does that help? If we put it this way, then yes, it is a similar configuration. In fact they could do this with one memory as well, because the menu and the test patterns could be overlayed so no additional memory would be needed, though they took advantage from this dual configuration as the menu can be colour, who know what was their original intention. As I was browsing all the NEC manuals I was quite amazed from how little they changed in the topology of the system board from plain PG to XG2. |
|
