System 18 / Moonwalker - blue stuck on

[ekorz]

I'm planning to probe around a little later this evening, but my last question got answered so quickly here I thought I'd post again. My Moonwalker is booting up fine, but instead of a black background I'm getting perpetual blue. So for example when you boot up the game, it's a blue-background with normal text. The test menus are all blue instead of black. Otherwise it seems OK - the V.D.P Test shows all colors (what does V.D.P. mean?) and the C.R.T. test looks washed-out-with-blue.

Any ideas where to start? I just replaced IC41 and IC42, the 6116 SRAM that previously tested bad. I replaced them, they pass now, but I'm going to check stuff connected to them, I suppose.

More photos here: https://imgur.com/gallery/dZwut

 

[xodaraP]

I think VDP stands for Video Display Processor. That's a test for the custom GPU. The fact you get all colours on this test would suggest that the GPU is fine

First things first, have you tried the board on a different monitor to rule it out? You said the CRT test is washed out with blue, so it may well be a monitor issue

From there I don't have the schematics in front of me, but you need to test the RGB lines to see if something isn't active (I'd be suspicious of Green since your photo does seem to have some Red in it) and follow these lines back to see where they're connected and look for a faulty component

I've not done any work on a Sys18 boardset, but on system 16A the RGB from the edge connector goes through a resistor array through a set of logic ICs (can't remember what type, maybe LS04 or LS74?) I think it is? From a pair of 6116 SRAMs (which may be the same ones you already replaced)

The problem is the data is generated by a big fat custom, but through the VDP test it sounds like it may be ok

There are a few issues it could be, but I'd guess it's either the blue line has failed somewhere and is stuck active, your green is missing and possibly your red is mostly missing so you're not getting the full colour range, or both.

Edit: just looked at the other photos, strange the VDP seems to be able to override whatever is causing the issue to do its own test.

 

[ekorz]

I can throw on another pcb through the HAS and I get all colors, so it's not my PVM I don't think. I'll trace the RGB from the jamma edge and start probing those logic ICs. Seems like a decent place to start. thanks.

I wish there were schematics for this motherboard but can't seem to find them!

Also yeah... that vdp screen is weird isn't it! Great colors!

 

[ekorz]

so I'm not very good at this to begin with, but without a schematic it's even harder for me!

I traced continuity from the blue jamma edge through a film capacitor, then into a NEC D74HC4066C. I probed it a bit and think some of the lines were stuck high, so we'll just start there. Of course something else could be driving them high but I ran out of time tonight.

Just so I'm reading this right, if pin 9 was high (that's the pin with continuity to the blue jamma output), the input would be from pin 6 yeah? full sheet here

Digikey stocks a Texas Instruments CD74HC4066E that I think/hope is equivalent. The general area also had a bunch of SN74LS32N gates so I picked up a few of those just in case.

 

[xodaraP]

That sounds right, but what is the input doing on pin 6? Is the output jammed high (on) or is the input stuck, meaning it could be whatever is supplying the input

 

[ekorz]

That sounds right, but what is the input doing on pin 6? Is the output jammed high (on) or is the input stuck, meaning it could be whatever is supplying the input

Yeah, if I recall pin 6 was also high but I found that diagram afterwards and haven't been back yet. Further down the line then perhaps...

 

[ekorz]

Learning a bit about interpreting datasheets now - typing this so it could be helpful for others, or so that someone can tell me i'm wrong!

The way to read this is pin 8 (3y) is the input, pin 9 (3z) is the output, and 3E (pin 6) is the control. When I probe this board, all the controllers seem to have continuity with eachtother. Dunno if that's normal, but that is what's up. I guess the control could be faulty, or the input could be faulty, but I will try hunting down the input next.

 

[xodaraP]

The datasheet will tell you if it's normal

I wouldn't have thought the control lines would have continuity personally, as they need to be controlling lines independently, but there may be a reason for it

 

[ekorz]

Input pin seems to lead to a PAL. Burning another PAL changes things (the jammarcade jed is 'assumed working') such that some sprites have no background, and now the VPD test actually looks normal -- with a black background. So I'm thinking it's that chip, the socket it lives in, or something feeding it.

My spare GALs are old/used and my programmer doesn't seem to love them that much, only one out of 4 even yeilded that change above, so I'm buying some new ones. Also found another sys18 mobo so that should help speed things up since I can probe and compare.

 

[xodaraP]

Nice, once you get the new GAL, post an update as to whether that fixes it and then move on from there

 

[ekorz]

Nice, once you get the new GAL, post an update as to whether that fixes it and then move on from there

Bad news(?) the GAL is fine.

Good news, I know it's fine because I found a working motherboard, so i can a/b now. Time to probe some stuff... I'm thinking I may have done something bad when I replaced the 6116's, so I'm going to start there.