Suggestions about a very weird symptom with CPC 6128...

[ikonsgr]

I have a very strange problem with one of my CPC 6128 and the ULIfAC board.
With all software that uses extra ram (like 128k games, symbos, cp/m plus etc), i get video noise on screen (horizontal bars or artifacts, on symbos, i get horizontal lines at the middle of screen,like old tv channels with bad tuning  )
Now the weird thing is that, this happens ONLY when ULIfAC board is connected! When i disconnect board and use internal 64k extra ram of CPC, problem disappears!
 So far, i:
- Clean thoroughly edge connector, using sand paper and isopropyl alcohol,
- Remove 6845CRT video chip, place a socket and test with another 6845CRT chip
- Replace Z80
- Replace 40010
- Replace 16L8HAL

Mind that, as i have another CPC board that all chips were removed and replaced with sockets, all the above chips were already tested and surely work ok. But, despite all efforts, problem still remains!
So, i was wondering, if this... "video screen leakage", can caused by a bad 74LS153 multiplexer (there 4 of them on CPC 6128).
Any suggestions about what can cause  this strange phenomenon (video noise ONLY when extra ram through expansion connector is used, and NOT when internal 64k extra ram used)?

[Bryce]

If the problem only happens when the ULIfAC board is connected, why are you looking for a problem in the CPC? It obviously doesn't have an issue.

Bryce.

[ikonsgr]

If the problem only happens when the ULIfAC board is connected, why are you looking for a problem in the CPC? It obviously doesn't have an issue.
Bryce.

Because the same ULIfAC board works perfect on all other CPCs i have (both 6128 and 464), so obviously it doesn't have to do with the board (btw, i'm the one that made ULIfAC board, so i've tried different ULIfAC boards and all have the same problem on the specific Amstrad ) , but something is wrong on the specific amstrad 6128, but i still can't find out what...

[Audronic]

@ikonsgr 

? have you measured the Voltage getting to the ULIFAC BOARD ?

Thanks

Keep Safe

Ray

[McArti0]

short video please...

I'm shooting.
Does this CPC have 200ns memory?

[McArti0]

1 OUT &7FFF, &C4
2 CALL &BFFC,&E9DD,&C9E9, &1A12,&1A12,&1A12,&1A12,&1A12,&1A12,&1A12,&1A12, &BFEA,&2100, &4000, &11F3

org &4000

di

ld de,&4000

ld hl,here
.here

repeat 8
ld a,(de)
ld (de),a
rend

Jp (hl)

and oscilloscope

[ikonsgr]

yes, this 6128 was from 1985 and has 200ns Ram chips. You can see what i mean in this short video:
https://www.dropbox.com/scl/fi/11usdlvap2zmy8oid88o4/weird_noise.mp4?rlkey=ifv5wlrb1v0m8hd1fxm5o3b61&dl=0

Even this simple Basic program that read/write to external ram, causes video noise!
Now, the weird thing is that, this is NOT happening when i use the internal extra 64k ram (execution of the same above listing, doesn't give any video noise), but ONLY when the extra ram is accessed through expansion connector! Note also that there is no actual corruption of video ram, as when i pause the access to external ram, video noise disappears!
So, in 2 words, the problem is that any activity to extra ram accessed through expansion port, causes video noise!
Now, since i've already replaced and test Z80, GA40010, 6845CRT and 16L8HAL, what other chip might cause this? Can a faulty 8255, 74LS153 multiplexers or even a ROM chip cause this?
Or maybe it's a problem with  bad caps/resistors somewhere ,or even bad  tracks on Amstrad's board?
Btw, this is the board revision of CPC 6128 with problem: https://www.cpcwiki.eu/index.php/File:CPC6128_PCB_Top_(Z70210_MC0009C).jpg

[eto]

How does it look when your program is running completely in the expanded ram and no base ram is accessed? Is then (almost) all the screen affected.

If yes I could imagine that it's related to the 74ls244 buffer that isolates the gate array from the bus. Or the 244en signal from the gate array behaves weirdly. If that doesn't work properly the ram signals from your expansion maybe slip through to the gate array when it reads from screen ram. 

That it doesn't appear with the internal secondary 64k is plausible as the PAL ensures only the base ram is active during screen ram access.

[McArti0]

Maybe it's changing to Write Read RAM mode?

Try only RD &1A1A   and next only  WR &1212.

in your BASIC only POKE and only PEEK. Maybe peek only will be clear.

[Brocky]

i seen something like this with the usifac on the 464 + ram expansion some time ago.. (havent used it on the 6128)
usually when voltage is too low.. are you powering from the CPC? or externally? might be worth checking
when it would access anythin the screen would show some bad pixels.... not exactly the same pattern as your vid tho... just one or 2 flashing pixels on screen..

[Bryce]

If the problem only happens when the ULIfAC board is connected, why are you looking for a problem in the CPC? It obviously doesn't have an issue.
Bryce.

Because the same ULIfAC board works perfect on all other CPCs i have (both 6128 and 464), so obviously it doesn't have to do with the board (btw, i'm the one that made ULIfAC board, so i've tried different ULIfAC boards and all have the same problem on the specific Amstrad ) , but something is wrong on the specific amstrad 6128, but i still can't find out what...

Ok, then you're definitely the best person to know what's happening. Is the ULIfAC possibly preventing the RAM from refreshing on certain cycles?

Bryce.

[eto]

If the problem only happens when the ULIfAC board is connected, why are you looking for a problem in the CPC? It obviously doesn't have an issue.
Bryce.

Because the same ULIfAC board works perfect on all other CPCs i have (both 6128 and 464), so obviously it doesn't have to do with the board (btw, i'm the one that made ULIfAC board, so i've tried different ULIfAC boards and all have the same problem on the specific Amstrad ) , but something is wrong on the specific amstrad 6128, but i still can't find out what...

Ok, then you're definitely the best person to know what's happening. Is the ULIfAC possibly preventing the RAM from refreshing on certain cycles?

Bryce.

In the video you can see that the ,,pixelnoise" vanishes once the code is paused. Without refresh I would expect that the corrupted data stays corrupted.

 To me that looks more like the data from the external RAM expansion is put on the bus and gets through to the gate array during screen RAM reads. 

[ikonsgr]

Thanks all for your interest and help, but i have to say that what @eto suggests, looks like to suit more with the symptoms...

In the video you can see that the ,,pixelnoise" vanishes once the code is paused. Without refresh I would expect that the corrupted data stays corrupted.

This behavior (pixel noise vanishes when there is no external ram access through expansion port) is general, so there is no actual "accidental" writing on video ram, but more of a video Interference when ram  is accessed through expansion connector.

To me that looks more like the data from the external RAM expansion is put on the bus and gets through to the gate array during screen RAM reads.

So,  you think that a faulty 74LS244 can cause this weird symptom, of getting video noise upon access of extra ram, but ONLY through expansion port?
Note also that the same video Interference is shown, not only with ram writes, but with ram reads too (both peek and poke commands to external ram range, create video noise, although in a different pattern) so maybe the 74LS373 has problem too? Or maybe the root of the problem can be somewhere else?...

I think what describes more accurately the problem is, as if ALL expansion ram activity, somehow "passes through" the video ram, resulting in having video Interference, BUT  WITHOUT ACTUALLY corrupting any video ram data! (sound like arcane riddle... )

[McArti0]

have you checked the reading itself, does it also make dots? maybe it's IORD?

Are the dots Cyan? these will be only bits from D3-D0 and D7-D4 are correctly zero.

try this as a background...
mode 1: ink 1,12: PRINT string$(255,chr$(85)); string$(255,chr$(85)); string$(255,chr$(85)); string$(255,chr$(85))

see if the dots are also red, this will indicate whether only the second byte is damaged or the first in the sequence 1 NOP

[Bryce]

Thanks all for your interest and help, but i have to say that what @eto suggests, looks like to suit more with the symptoms...

In the video you can see that the ,,pixelnoise" vanishes once the code is paused. Without refresh I would expect that the corrupted data stays corrupted.

This behavior (pixel noise vanishes when there is no external ram access through expansion port) is general, so there is no actual "accidental" writing on video ram, but more of a video Interference when ram  is accessed through expansion connector.

To me that looks more like the data from the external RAM expansion is put on the bus and gets through to the gate array during screen RAM reads.

So,  you think that a faulty 74LS244 can cause this weird symptom, of getting video noise upon access of extra ram, but ONLY through expansion port?
Note also that the same video Interference is shown, not only with ram writes, but with ram reads too (both peek and poke commands to external ram range, create video noise, although in a different pattern) so maybe the 74LS373 has problem too? Or maybe the root of the problem can be somewhere else?...

I think what describes more accurately the problem is, as if ALL expansion ram activity, somehow "passes through" the video ram, resulting in having video Interference, BUT  WITHOUT ACTUALLY corrupting any video ram data! (sound like arcane riddle... )

If the 74LS244 was faulty, then the CPC wouldn't work without the ULIfAC either. The problem is either BUS contention (two devices writing to the bus at the same time), or a refresh issue, possibly due to the slower RAMs in the CPC as suggested by McArti0 above.

Bryce.

[ikonsgr]

have you checked the reading itself, does it also make dots? maybe it's IORD?
Are the dots Cyan? these will be only bits from D3-D0 and D7-D4 are correctly zero.

Both reading and writing produce video interference. Color of the dots appear to be at the color of pen 1, i tried different ink 1,x colors and the dots always changed to the corresponding color too.

try this as a background...
mode 1: ink 1,12: PRINT string$(255,chr$(85)); string$(255,chr$(85)); string$(255,chr$(85)); string$(255,chr$(85))
see if the dots are also red, this will indicate whether only the second byte is damaged or the first in the sequence 1 NOP

No, dots are yellow, nothing red appears on screen.

[ikonsgr]

If the 74LS244 was faulty, then the CPC wouldn't work without the ULIfAC either. The problem is either BUS contention (two devices writing to the bus at the same time), or a refresh issue, possibly due to the slower RAMs in the CPC as suggested by McArti0 above.
Bryce.

Hmmm, if there was a bus connection problem (two devices writing to the bus at the same time as you say) then we would have alteration of video screen too, but here, the video noise disappears the moment the access to expansion ram ends! So, i think that the other possibility of the slower ram might really cause the problem,  although i'm pretty sure that i've tested ULIfAC on other Amstrad boards having 200ns ram chips and worked ok... What other chips are involved into ram refresh procedure (i think amstrad CPC doesn't use Z80 memory refresh ability) ?

[McArti0]

This means the problem is with D7-D4 and D3-D0 are good.

Try this background
mode 1: PEN 2 : ink 2,12: PRINT string$(255,chr$(&85)); string$(255,chr$(&85)); string$(255,chr$(&85)); string$(255,chr$(&85))

sorry &85 must be HEX.

Have You red dots on dark yellow?

[ikonsgr]

This means the problem is with D7-D4 and D3-D0 are good.

Try this background
mode 1: PEN 2 : ink 2,12: PRINT string$(255,chr$(&85)); string$(255,chr$(&85)); string$(255,chr$(&85)); string$(255,chr$(&85))

sorry &85 must be HEX.

Have You red dots on dark yellow?

All yellow again.

[McArti0]

But Yellow dots on dark Yellow and blue? or only on blue? or only on dark Yellow?

[eto]

The problem is either BUS contention (two devices writing to the bus at the same time), or a refresh issue, possibly due to the slower RAMs in the CPC as suggested by McArti0 above.

Can you explain that please?

The error is only a "visualisation" error. The RAM is not really altered in any way. How could RAM refresh be related to that? If anything is wrong with RAM refresh, the data would be corrupted and stay corrupted, so the spots that show garbage should stay in place. Or do I get that wrong?

And the ULIFAC writing to the bus should also not result in screen noise as the GateArray data pins are isolated from the CPU data bus via the 74LS244 when the GateArray reads from the base RAM. 

[ikonsgr]

But Yellow dots on dark Yellow and blue? or only on blue? or only on dark Yellow?

All Yellow characters on blue background.

[eto]

But Yellow dots on dark Yellow and blue? or only on blue? or only on dark Yellow?

All Yellow characters on blue background.

Can you please try the following code and let us know what is happening then? It will run completely in expanded RAM so I would expect the whole screen will be garbage as long as it's running.

As it disables interrupts it will never return and you have to reset the CPC to stop it.

Code Select Expand

10 INK 0,0:INK 1,18:INK 2,6:INK 3,2
20 PAPER 3:CLS
30 OUT &7F00,&C4
40 POKE &4500,&F3:POKE &4501,0:POKE &4502,&B0:POKE &4503,&18:POKE &4504,&FC
50 CALL &4500

[McArti0]

All Yellow characters on blue background.

You have problem with second video byte after second CAS only and only bits D7-D4. This is place when many signals is changing. RAS up, nCPU down, nCASADR up, nCCLK down. When are you changing RAMDIS and mayby something else?

https://bread80.com/2021/06/03/understanding-the-amstrad-cpc-video-ram-and-gate-array-subsystem/

Fig 5 and 6 Place before vertical grey line with scale.

[eto]

- Replace 16L8HAL

Is it the original PAL? A replacement PAL could implement logic that causes artifacts (https://www.cpcwiki.eu/index.php/PAL16L8#Fixed_version_.28Gerald.29).