Missing Right Half of Characters

[dr_slump]

Hi everyone!
New member here — long-time Amstrad user. I learned to program on a CPC-464, owned one back in the day, and recently acquired another unit that I'd like to use to teach my daughter how to program. :-)The computer is in generally good shape and basically works. It even loads and runs games without issues. However, there's a clear display problem visible on the startup screen (see the attached photo).
As you can see, the right half of each character is missing and is replaced by the background color.
Since everything else seems to work normally, I assume the CPU and memory are fine, and the issue lies somewhere in the video subsystem. The motherboard is a Z70200, MC0002D, with a Gate Array model 40010.
Before spending 40€ to replace the GA, I started checking the chips that feed its inputs. I replaced IC115 (74LS244), but that didn't change anything. My next suspect is IC114 (74LS373).
Before going further with the repair, I wanted to ask if anyone here has seen this specific issue before. I've watched several repair videos, but haven't come across this exact symptom.
Any ideas?
Thanks in advance!
—Paco

[salvogendut]

seems similar to this case 

[McArti0]

Has Games stripes too?

[dr_slump]

Yes, games also look weird with vertical stripes. Unfortunately, I didn't take a photo of the screen.

[McArti0]

373 works good. GA does not capture the second byte from memory in the video read sequence.

Try type CLG 3.

[dr_slump]

Hi!

I think you are right. Running the CLG 3 command I get vertical stripes (see photo). Does it mean the gate array is faulty?

Thank you for your help.

[McArti0]

Omg At second byte
11110000->0, pen1 to pen0
11111111->11110000 !!!! Pen3 to pen1 !
00001111->11110000 pen2 to pen1

Try type MODE 2

And try
Cpc reset
pen 2
Ready
Pen 3
Ready

[dr_slump]

There you go. With pen 2/pen 3, now the left part of the characters repeats in yellow. In mode 2, every other character is missing.

[McArti0]

Clearly, the GA is getting the same video byte twice, and with inverted color interpretation. So this error is most likely in the GA. It would be best to check this with an oscilloscope to see if the CCLK, nCAS, and CAS ADDR signals are shifted and misaligning the LS153 multiplexers.

Try replug GA

[Bread80]

That's an interesting failure mode. The system is reading each video byte twice, but the second is corrupted.

Selecting between the two video bytes is done by the CCLK signal into IC105. This is a similar failure mode to that in the video posted earlier in the thread, but on a different address line. I'd look at IC105 (possibly swap with the other multiplexer chips) and the relevant traces into and out. I could be a broken trace or a poor solder joint. Maybe rework the pins on IC105, check for any shorts between traces and, perhaps, bodge wire pin 4 to the GA (or CRTC) to bypass a bad trace.

Since the CPU side of the RAM appears to be working that suggests the signals between IC105 and RAM are good.

Note that CCLK is also the clock signal into the 6845. Since the 6845 appears to be functioning properly that would indicate that CCLK is correct (unless it is, somehow, out of phase, which is unlikely).

As to why the second video byte is corrupted, that's harder to say. It could be a symptom of the first fault, faulty RAM, or a faulty GA. My money says it's on the first of those options. I'd recommend solving that issue and see if that fixes it.

[GUNHED]

Can be an error in the ROM. Can you create a checksum of your BASIC ROM and then the FIRMWARE ROM?

[eto]

It could be a symptom of the first fault, faulty RAM, or a faulty GA. My money says it's on the first of those options. I'd recommend solving that issue and see if that fixes it.

For the byte repeat it could be the multiplexer or the track to the multiplexer. It probably can't be the signal itself as as the CRTC, which uses the same signal, works. 

What makes me doubt that it's a normal IC are the tests with the different colours. It looks more like a bit shift as the first byte is repeated but instead of PEN 2 and PEN 3 the output is in PEN 1 for the second byte. Afaik the only bit shift is done in the GateArray in the video register.

But yeah, before swapping that I would also try the multiplexer first. 

[Bryce]

Hi dr_slump,
        could you check the resistors R146 to R153 (scattered around the chips at the bottom of the board) and see if any of them are physically broken or reading open circuit? If they are all ok, I'd suspect that the multiplexers could be the problem.

Bryce.

[McArti0]

No multiplexer can swap bits.

1111 0000
To
0000 0000

And 

0000 1111
To
1111 0000

[Bryce]

No multiplexer can swap bits.

1111 0000
To
0000 0000

And

0000 1111
To
1111 0000

I fully agree, but floating bits can cause all sorts of craziness. I used to think that floating bits would always produce random results, but I've since seen systems that gave a repeatable result due to floating inputs. That's why I suggested checking the resistors first, and taking a really close look at the PCB is never a bad thing and sometimes even reveals something completely unexpected.

Bryce.

[eto]

No multiplexer can swap bits.

I fully agree,

I'm a bit lost here. How can the address multiplexer have an impact on the data bits? (except for selecting the wrong address of course)

[Rabs]

How does the CRTC come into play with addressing lines, could it be that if one of the  tracks between the CRTC and multiplexers was broken that the same adress lines would be repeated when addressing the memory for the screen display and hence repeat? See Noel's video, mentioned above.

[Bread80]

I'm a bit lost here. How can the address multiplexer have an impact on the data bits? (except for selecting the wrong address of course)

It's interesting to note that A0 (CCLK) is the only bit which changes between the two bytes. Suppose the multiplexers are running a little slow. That could mean A0 hasn't fully settled by the time ~CAS transitions low and the DRAM's address decoders start working. The late transitioning signal could, perhaps, mean that different DRAM's are working off of different values for A0. So, maybe, some of the chips are return a value for A0=1 and some are returning a value for A0=0. Possibly the address decoding is incomplete and they may be returning data for a completely different address.

We're in the world of gate delays and nanosecond timings. Electrical signals travel at the speed of light, so the signals travel 30cm in a single nanosecond, and signals take a moment or two to settle into a new state. The distance between the DRAM IC could easily result in different chips sampling different values if the transition and bouncing happens at the wrong moment. This is the reason the world abandoned parallel interfaces in favour of serial ones.

I believe the correct term is 'metastability' for signals getting sampled when they are between states.

The above is just supposition, and the answer could be something entirely different, but I'd suggest it's plausable.

And I'd second Byrce's suggestion to check the resistors. They're in there to improve the settling time of the signals and it's very possible an issue with them could cause such issues.

[robcfg]

May I also suggest to check if the logic chips are of the same time (that is LS, or HC)?

They have slightly different TTL activation levels and that can cause problems.

[Bread80]

How does the CRTC come into play with addressing lines, could it be that if one of the  tracks between the CRTC and multiplexers was broken that the same adress lines would be repeated when addressing the memory for the screen display and hence repeat? See Noel's video, mentioned above.

Yup. That's pretty much the issue here. But the repeat in this instance is every successive byte. So we're talking about address line A0. A0 is driven directly by the GA, it's the signal whose full name is MA0_CCLK - "address line zero, CRTC clock".

I've no idea why they didn't just clock the CRTC at twice the frequency though. I believe it's capable. Maybe there's a limitation on how it can be programmed? Maybe it would have required an extra signal from the GA? Maybe the CRTC is too slow to update between the two video bytes?

[Rabs]

How does the CRTC come into play with addressing lines, could it be that if one of the  tracks between the CRTC and multiplexers was broken that the same adress lines would be repeated when addressing the memory for the screen display and hence repeat? See Noel's video, mentioned above.

Yup. That's pretty much the issue here. But the repeat in this instance is every successive byte. So we're talking about address line A0. A0 is driven directly by the GA, it's the signal whose full name is MA0_CCLK - "address line zero, CRTC clock".

I've no idea why they didn't just clock the CRTC at twice the frequency though. I believe it's capable. Maybe there's a limitation on how it can be programmed? Maybe it would have required an extra signal from the GA? Maybe the CRTC is too slow to update between the two video bytes?

Yup, so I would check the traces first. You can create all sorts of odd repeating patterns.

This is IC113 PIN 3 on my test board.

You cannot view this attachment.

I will try IC105 PIN 4 tomorrow and see if I get the same pattern.