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
seems similar to this case
Has Games stripes too?
Yes, games also look weird with vertical stripes. Unfortunately, I didn't take a photo of the screen.
373 works good. GA does not capture the second byte from memory in the video read sequence.
Try type CLG 3.
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.
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
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.
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
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.
Can be an error in the ROM. Can you create a checksum of your BASIC ROM and then the FIRMWARE ROM?
Quote from: Bread80 on 22:49, 15 July 25It 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.
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.
No multiplexer can swap bits.
1111 0000
To
0000 0000
And
0000 1111
To
1111 0000
Quote from: McArti0 on 15:56, 16 July 25No 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.
Quote from: McArti0 on 15:56, 16 July 25No multiplexer can swap bits.
Quote from: Bryce on 18:37, 16 July 25I 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)
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.
Quote from: eto on 20:06, 16 July 25I'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.
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.
Quote from: Rabs on 22:32, 16 July 25How 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?
Quote from: Bread80 on 22:59, 16 July 25Quote from: Rabs on 22:32, 16 July 25How 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.
IC113 PIN3.jpg
I will try IC105 PIN 4 tomorrow and see if I get the same pattern.
Quote from: Bread80 on 22:45, 16 July 25That 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.
Exactly... what could happen is that the address bit of A0 is one or the other - or maybe something completely different is happening. If there would be rubbish on screen or always everything empty or an exact replica of the left side, I would totally agree.
But we see a very special behaviour that can't be explained by an address error. It's the data bits that get transformed in a predictable way. And I don't see how the multiplexer for the address bus can transform data bits in a predictable and consistent way.
Look at the screenshot where he sets PEN 2 and PEN 3. I attached the relevant part here again. The right half of each character is a repetition of the left half - just in PEN 1.
Let's have a look at the first line of pixels of the character R.
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)
If it would working correctly byte 2 would then be right half of R, if it would just be an address glitch it would be a repetition of the first byte or some other content from somewhere in RAM but what we actually get is for every single byte something that could be a shift (4 left) operation.
In the end we get something that would be the equivalent of byte 2 =
PEN 1: 00000000 (empty)
PEN 2: 11110000 (4 pixels but now PEN 1)
PEN 2: 11110000 (4 pixels but now PEN 1)
And this behaviour is consistent for every single character.
The only thing I am aware of that can shift bits (except for the CPU) is the Gate Array.
And there it could be explained, if I understand the schematics correctly. This to me looks like the data of the first byte is loaded into the video shift register in the GateArray. Then it's shifted 4 bits while outputting the first 4 pixels. After that the next byte should be loaded into the video shift register. If this does not happen the GateArray continues with the 4 bits that are still there - which is basically the content of the first byte shifted 4 bits to the right.
This would also explain Mode 2 behaviour as in Mode 2 the shift video register will shift by 8 bits thus being empty.
I forgot to add the video shift register schematics in the previous post
Please be aware that the bits in this schematics are 0...7 and not 7...0.
(I didn't recognize that in the first place why I went back and forth on the original post with what is shifted where. )
Quote from: dr_slump on 17:10, 15 July 25With pen 2/pen 3, now the left part of the characters repeats in yellow. In mode 2, every other character is missing.
could you try again in mode 0?
I would expect that the normal output is striped with two pixels being visible, then two pixels being invisible.
The same should happen for PEN 1-7
But with PEN 8-15 the blank areas should repeat the previous two pixels just in another colour.
@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
Quote from: McArti0 on 10:49, 17 July 25@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
Quotewith 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.
Overall, GA went crazy. Something got unsoldered inside.
This is what I get with IC105 pin 4 CCLK floating. Not sure it is the same.
Full Screen
Full Screen.jpg
Close Up on Ready
Close up.jpg
IC105 Pin 4 CCLK
IC105.jpg
Quote from: Rabs on 15:17, 17 July 25This 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.
Quote from: eto on 15:38, 17 July 25Quote from: Rabs on 15:17, 17 July 25This 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.
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?
Two Colour.JPGReady.JPG
Quote from: Rabs on 15:47, 17 July 25But 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".
Quote from: eto on 16:09, 17 July 25Quote from: Rabs on 15:47, 17 July 25But 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?
Quote from: Rabs on 16:12, 17 July 25Correct. So in dr_slump (https://www.cpcwiki.eu/forum/index.php?action=profile;u=6606) 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.
Quote from: eto on 16:18, 17 July 25Quote from: Rabs on 16:12, 17 July 25Correct. So in dr_slump (https://www.cpcwiki.eu/forum/index.php?action=profile;u=6606) 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?
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:
https://youtu.be/YQN5lTRZ_oA (https://youtu.be/YQN5lTRZ_oA)
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
Quote from: Bryce on 14:33, 16 July 25Hi 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.
:o
Quote from: dr_slump on 17:39, 17 July 25First, 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
Pixels in bites in MODE 1 and MODE 0.
Hi all!
I'm writing to let you know the solution to the mystery, just in case a weird screen like mine shows up in the future. Short answer: the culprit was the gate array. I bought a 40010, replaced the old one, and voilà. Everything works.
Unfortunately for me, it wasn't that easy. When I first replaced the gate array, the CPC worked even worse than before! It showed a grey rectangle in the screen, and it hung. After checking continuity between IC115 and the gate array, I found that between pin 3 (D4) of IC115 and the pad 28 of the 40007 socket (my PCB is prepared for both gate array models) there was less than 1 ohm, but between the same pad of the 40007 and the pin 40 of the 40010 there was 8 Mohm! I checked the IC socket and found that the contact for pin 40 was bent, and it barely touched the pin. I replaced the socket and finally, it is back to life!
Again, thank you all for your help :D .
Paco
GA version 40008 and 40010 are interchangeable, but old 40007 has a different pin order, and cannot be replaced with new ones, or new ones replaced with older ones.
Quote from: ZorrO on 07:14, 30 July 25GA version 40008 and 40010 are interchangeable, but old 40007 has a different pin order, and cannot be replaced with new ones, or new ones replaced with older ones.
That is correct. My board comes with the 40010 installed, but it has a second set of pads ready to install a 40007 (just below the 40010 in this photo):
(https://www.cpcwiki.eu/imgs/6/69/CPC464_PCB_Top_%28Z70200_MC0002D%29.jpg)
Quote from: dr_slump on 10:38, 30 July 25Quote from: ZorrO on 07:14, 30 July 25GA version 40008 and 40010 are interchangeable, but old 40007 has a different pin order, and cannot be replaced with new ones, or new ones replaced with older ones.
That is correct. My board comes with the 40010 installed, but it has a second set of pads ready to install a 40007 (just below the 40010 in this photo):
(https://www.cpcwiki.eu/imgs/6/69/CPC464_PCB_Top_%28Z70200_MC0002D%29.jpg)
that 2nd slot will work, but you'll need to add some resistors to power the chip, they are left off the board as not needed with the 40010
from memory its the 2 links just to the left of the socket (R138 and R139)..they need to be populated with 12 ohm 1/2watt resistors..