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)?
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.
Quote from: Bryce on 20:42, 21 February 25If 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...
@ikonsgr ? have you measured the Voltage getting to the ULIFAC BOARD ?
Thanks
Keep Safe
Ray
short video please...
I'm shooting.
Does this CPC have 200ns memory?
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
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
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.
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.
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..
Quote from: ikonsgr on 01:46, 22 February 25Quote from: Bryce on 20:42, 21 February 25If 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.
Quote from: Bryce on 16:27, 22 February 25Quote from: ikonsgr on 01:46, 22 February 25Quote from: Bryce on 20:42, 21 February 25If 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.
Thanks all for your interest and help, but i have to say that what
@eto suggests, looks like to suit more with the symptoms... ::)
Quote from: eto on 17:34, 22 February 25In 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.
Quote from: eto on 17:34, 22 February 25To 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... :) )
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
Quote from: ikonsgr on 18:48, 22 February 25Thanks all for your interest and help, but i have to say that what @eto suggests, looks like to suit more with the symptoms... ::)
Quote from: eto on 17:34, 22 February 25In 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.
Quote from: eto on 17:34, 22 February 25To 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.
Quote from: McArti0 on 20:48, 22 February 25have 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.
Quote from: McArti0 on 20:48, 22 February 25try 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.
Quote from: Bryce on 12:09, 23 February 25If 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) ?
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?
Quote from: McArti0 on 13:13, 23 February 25This 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.
But Yellow dots on dark Yellow and blue? or only on blue? or only on dark Yellow?
Quote from: Bryce on 12:09, 23 February 25The 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.
Quote from: McArti0 on 14:50, 23 February 25But Yellow dots on dark Yellow and blue? or only on blue? or only on dark Yellow?
All Yellow characters on blue background.
Quote from: ikonsgr on 20:21, 23 February 25Quote from: McArti0 on 14:50, 23 February 25But 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.
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
Quote from: ikonsgr on 20:21, 23 February 25All 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.
Quote from: ikonsgr on 20:08, 21 February 25- 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).
thanks for the suggestions. i will see to them and let you know.
Quote from: eto on 00:12, 24 February 25Quote from: ikonsgr on 20:08, 21 February 25- 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).
YES! THAT WAS AFTER ALL!! Many thanks to
@eto for pointing that!
The chip in fact, was NOT an original Amstrad 40031 PAL chip, but instead a LATTICE GAL16V8D (probably fitted many years ago...), fortunately i have a TL866II programmer, and manage to reprogram it with the new Fixed version (noting:
"the Original version from Porchy suffer from a bad handling of the RAMDIS signal. This cause screen artefact when accessing an external extension RAM"= EXACTLY my problem!!!) , after that, no more video noise! :D
Quote from: ikonsgr on 10:13, 22 February 25Now, since i've already replaced and test (...) 16L8HAL,
:blank:
Quote from: McArti0 on 12:22, 24 February 25Quote from: ikonsgr on 10:13, 22 February 25Now, since i've already replaced and test (...) 16L8HAL,
:blank:
I'm pretty sure that i replaced GAL from another Amstrad 6128, where both GAL chips worked ok. Maybe because the other 6128 was a burned one, where all chips were removed, placed with sockets + new chips, and for some reason, even the old GAL version worked ok with ram expansions on that 6128 ::)