Missing Right Half of Characters

[eto]

@eto it's not like that.

Mode 1 work like that Lp0,Lp1,Lp2,Lp3,Hp0,Hp1,Hp2,Hp3.

First line R pen 1 : 11110000
First line R pen 2 : 00001111
First line R pen 3 : 11111111

You probably saw my first version of the post which was incorrect. It's now

with PEN 1 byte 1 would be 11110000 (4 pixels PEN 1)
with PEN 2 byte 1 would be 00001111 (4 pixels PEN 2)
with PEN 3 byte 1 would be 11111111 (4 pixels PEN 3)

and that seems to be the same values.

[McArti0]

Overall, GA went crazy. Something got unsoldered inside.

[Rabs]

This is what I get with IC105 pin 4 CCLK floating. Not sure it is the same.

Full Screen
You cannot view this attachment.

Close Up on Ready
You cannot view this attachment.

IC105 Pin 4 CCLK
You cannot view this attachment.

[eto]

This is what I get with IC105 pin 4 CCLK floating. Not sure it is the same.

Exactly what I would expect if the address is related to the problem.

Please try PEN 2 and PEN 3 and look how the READY then appears. I would expect that in your case the duplicated parts will still have the same colour and all appear light blur or red.

In dr_slump's case the colour changes - and that can't be related to the address bit.

Also give it a try in MODE 2. I would expect that it's then "RRaayy" (or maybe "eedd. ", depending on what A0  is)  for you.

[Rabs]

This is what I get with IC105 pin 4 CCLK floating. Not sure it is the same.

Exactly what I would expect if the address is related to the problem.

Please try PEN 2 and PEN 3 and look how the READY then appears. I would expect that in your case the duplicated parts will still have the same colour and all appear light blur or red.

In dr_slump's case the colour changes - and that can't be related to the address bit.

You are correct.

[Rabs]

But it is repeating in the same way, ish. But not quite. I have second half not First? Is there more than one thing at play? 

You cannot view this attachment.You cannot view this attachment.

[eto]

But it is repeating in the same way, ish. But not quite. I have second half not First? Is there more than one thing at play? 

Seems in your case the output will be always 1 if the input is floating. So the Gate Array will always get the data on the odd addresses in RAM. 

Try in MODE 2. I would expect that instead of the "Ready" you will see a "eedd".

[Rabs]

But it is repeating in the same way, ish. But not quite. I have second half not First? Is there more than one thing at play?

Seems in your case the output will be always 1 if the input is floating. So the Gate Array will always get the data on the odd addresses in RAM.

Try in MODE 2. I would expect that instead of the "Ready" you will see a "eedd".

Correct. So in @dr_slump case there is an addressing issue but floating low (or low)? And something else is going on?

[eto]

Correct. So in dr_slump case there is an addressing issue but floating low (or low)? And something else is going on?

I would expect that there is no addressing error but an error in the GateArray when it loads the second byte into the video shift register.  A full explanation why I think that this is the problem is on the previous page (#21): https://www.cpcwiki.eu/forum/hardware-related/missing-right-half-of-characters/msg252505/#msg252505

I still might be wrong but imho a malfunction of the GateArray is the only way to explain that in MODE 2 the byte gets not repeated AND that there is a 4 bit shift in MODE 1.

[Rabs]

Correct. So in dr_slump case there is an addressing issue but floating low (or low)? And something else is going on?

I would expect that there is no addressing error but an error in the GateArray when it loads the second byte into the video shift register.  A full explanation why I think that this is the problem is on the previous page (#21): https://www.cpcwiki.eu/forum/hardware-related/missing-right-half-of-characters/msg252505/#msg252505

I still might be wrong but imho that's the only way to explain that in MODE 2 the byte gets not repeated AND that there is a 4 bit shift in MODE 1. But a malfunction of the GateArray would explain it.

Think I understand, thanks. Interesting?

[dr_slump]

Wow!!!! Guys, thank you very much for the discussion. I'm learning a lot and having fun at the same time.
A couple more of data points before getting the PCB out again.
First, a photo in mode 0 showing the result of changing the pen (pen 0, pen 1, pen 2, etc.) I noticed that some of the pen modes (not all of them) have flickering pixels (like noise).
Second, a video of the diagnostics rom booting:



Also, the computer now is freezing of me. I'm now sure if it has started acting up since I changed the IC115 (that is the only thing I have touch), it was like this since the begining but I didn't notice, or if the 30º C  with 75% humidity is killing it...

Now I will check the resistors and everything else.

Thank you again!

Paco

[dr_slump]

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.

I have checked all the resistors and the traces between the multiplexers and the RAM chips, and everything seems fine. For example, the resistance between pin 9 in IC105 and pin 5 in each memory chip  is 120 ohm +/- 2 ohm. The same for pins 7 and 9 for all the multiplexers and their correponding memory pins. 

[ZorrO]

[eto]

First, a photo in mode 0 showing the result of changing the pen (pen 0, pen 1, pen 2, etc.) I noticed that some of the pen modes (not all of them) have flickering pixels (like noise).

The MODE 0 screenshot can also be explained with the GateArray having an issue in it's video logic (Gate Array no longer loading the second byte into the video shift register)


In Mode 0 the pixel/bit organisation is like this:
p0b0 p1b0 p0b2 p1b2 p0b1 p1b1 p0b3 p1b3
(pNbM => pixel N Bit M)

Let's look at the upper left 2 pixels of R. In RAM, depending on the PEN we will see different bits being set.

PEN 2, the two pixels will be 00001100 in RAM (bit 1 is set = 2)

• In the video register this will be shifted 2 to the left 00110000
• now the second byte should be loaded - but this fails (for unknown reasons)
• instead the GateArray continues outputting the still present data 00110000
• 00110000 is the equivalent of PEN 4, which is white by default
• - > exactly what we see in the example, Pixel 3 and 4 repeat Pixel 1 and 2, but white

PEN 4 is 00110000 in RAM (bit 2 is set = 4)

• In the video register this will be shifted 2 to the left 11000000 which is PEN 1 (bit 1 being set)
• PEN 1 is yellow, again exactly what we see: Pixel 3 and 4 repeat Pixel 1 and 2, but yellow

PEN 11 is 11001111 in RAM (bit 0, 2 and 3 being set = 11)

• In the video register this will be shifted 2 to the left 00111100 which is PEN 6 (bit 2 and 1 being set)
• PEN 6 is dark blue, again exactly what we see: Pixel 3 and 4 repeat Pixel 1 and 2, but dark blue