Hi,
Complete newbie here trying to resurrect a CPC 6128.
It seems to boot to a white screen with a black border. Digging through previous posts here, some seem to think that this means the Z80 is intact?
Suspecting the RAM, I did the "RAM bank swap trick" by removing the IC118 and replacing it with some jumper wires in the appropriate positions (triple-checked!). This made no difference - still the same white screen with black border.
At this point I'm thinking I could:
1. Replace the Z80 for around £10
2. Replace the 40010 for £35
3. I would also be tempted to replace the RAM banks, but with my soldering skills I'm concerned that I could cause more harm than good. (So that might be a last resort...)
Anyway, before I try any of those options I thought I'd see what you experts think. Help? :)
Thanks
M
CRTC working
ROM and Z80 sometimes working.
Press DEL. Do You hear sound?
40010 Pin 32 conect to Pin1 expansion port.(sound) Do You hear sound 300Hz? if no GA not work.
74LS145 pin 15 conect to Pin1 expansion port.(sound) Do You hear sound 50Hz? if no interrupts not work.
Quote from: McArti0 on 23:09, 31 March 24CRTC working
ROM and Z80 sometimes working.
Press DEL. Do You hear sound?
40010 Pin 32 conect to Pin1 expansion port.(sound) Do You hear sound 300Hz? if no GA not work.
74LS145 pin 15 conect to Pin1 expansion port.(sound) Do You hear sound 50Hz? if no interrupts not work.
I knew I'd forget to detail everything. No sound on pressing DEL.
Thanks for the diagnostics suggestions.
I got the 300Hz tone nice and clear, so the 40010 seems to be good.
With the 50Hz tone, it did make a sound but I needed to keep moving the connecting wire over the expansion port pin for the sound to continue. And it sounded more like static. Not sure if that's a pass or a fail!
Check this:
https://www.cpcwiki.eu/forum/general-discussion/cpc464-no-video/msg237132/#msg237132
Quote from: mmldrm on 08:57, 01 April 24Not sure if that's a pass or a fail!
Fail. 50Hz must be strong.
Quote from: McArti0 on 09:08, 01 April 24Check this:
https://www.cpcwiki.eu/forum/general-discussion/cpc464-no-video/msg237132/#msg237132
Thanks. Although I must admit that table doesn't mean much to me. :( Are those some other locations that I can use with the expansion pin to test for a signal/sound? I'll happily give those a try if that is correct.
Quote from: McArti0 on 09:08, 01 April 24Fail. 50Hz must be strong.
Damn. I wonder why moving the wire caused it to make the sound.
Interrupts not working - would that be a faulty 40010 chip?
(Thanks for your help!)
The black border and white/grey screen show, that the CPC started to boot and initialised the CRTC but as soon as the CPU tries to access RAM it stops. Therefore you can't hear a beep as that requires that everything works.
However due to that screen we can also expect that ROM and Z80 are almost certainly okay. Also CRTC and GateArray are most likely working.
But this error is a typical result from a RAM fault. Probably one of the RAM ICs or one of the ICs that isolate the RAM from the bus (the mixers and latches) is faulty.
If you have a Lower ROM board, Dandanator or M4 you can try to run Amstrad diagnostics. If all RAM ICs seem to be dead, it's probably a mixer IC and if it's single ICS then the respective RAM IC or the latch is the culprit.
you could also try to remove the PAL IC and insert a socket where you bridge a few pins to force the 6128 to use the secondary RAM bank as it's primary bank. If it's just a malfunctioning RAM IC (with no permanent short) this can give you a working 6128 - with just 64KB of RAM of course. but then you know for sure that it's the RAM.
https://www.youtube.com/watch?v=LLVHJO-aj3Q
of course, this will only work, if it's only an IC of the primary RAM bank that is failing and nothing else.
Quote from: mmldrm on 10:45, 01 April 24Although I must admit that table doesn't mean much to me
Do You have a multimeter?
No. Pin32 and 300Hz sound showing that GA 40010 work.
Z80 not run properly code in RAM.
ps. check sound on pin7 and pin9 all 74LS153. Another but obvious sound on all outputs. muliplexers are good
Quote from: eto on 11:22, 01 April 24you could also try to remove the PAL IC and insert a socket where you bridge a few pins to force the 6128 to use the secondary RAM bank as it's primary bank. If it's just a malfunctioning RAM IC (with no permanent short) this can give you a working 6128 - with just 64KB of RAM of course. but then you know for sure that it's the RAM.
https://www.youtube.com/watch?v=LLVHJO-aj3Q
of course, this will only work, if it's only an IC of the primary RAM bank that is failing and nothing else.
Thanks. I tried that with a few jumper wires I had, but got the same white screen with black border. Was hoping that would narrow it down to a single faulty RAM bank, but sadly not.
Quote from: McArti0 on 11:45, 01 April 24Do You have a multimeter?
I do, but to be honest I've used it once about 3-4 years ago and never since. Would have to find YouTube instructions first, to set it up correctly.
But, in short, yes I do. :)
Edit: this is the multimeter I have, in case it helps to suggest tests.
Quote from: McArti0 on 11:52, 01 April 24ps. check sound on pin7 and pin9 all 74LS153. Another but obvious sound on all outputs. muliplexers are good
This was interesting. Should the output noise be noticeably different across the pins? All were loud, if varied, except pin 7 on IC105 (the bottom one of the four).
(I'll try to get the multimeter set up today so I can see actual numbers as outputs. Forgot I had it, tbh.)
20V bottom-left is yours and now https://www.cpcwiki.eu/forum/general-discussion/cpc464-no-video/msg237132/#msg237132 (https://www.cpcwiki.eu/forum/general-discussion/cpc464-no-video/msg237132/#msg237132)
probes hole mid and right.
Quote from: mmldrm on 13:07, 01 April 24Should the output noise be noticeably different across the pins? All were loud, if varied, except pin 7 on IC105
All differents like bad piano :D
What about this Pin7 of IC105? died?
Quote from: McArti0 on 15:11, 01 April 2420V bottom-left is yours and now https://www.cpcwiki.eu/forum/general-discussion/cpc464-no-video/msg237132/#msg237132 (https://www.cpcwiki.eu/forum/general-discussion/cpc464-no-video/msg237132/#msg237132)
probes hole mid and right.
Sorry, I see the table of voltages on the GA/Z80 chips but I'm not sure what you are suggesting to try. :(
Not sure what you mean by 20V (literally 20 volts?) or the probes line. (My lack of technical skills causing trouble here I think!)
Happy to test anything with the multimeter, but imagine you are instructing a guy who sees it as two pointy sticks. (I don't want to fry a chip by pushing current across the wrong pins.)
imagine
Thanks. Where is best to ground on the motherboard?
watch on image
Quote from: McArti0 on 19:13, 01 April 24watch on image
Oh man... 🤦�♂️ Can't believe I missed that. I wasn't even being lazy. Did lots of searching for 'best ground on cpc motherboard, etc.
Dziękuję. I will try those tonight/tomorrow.
Quote from: McArti0 on 15:15, 01 April 24What about this Pin7 of IC105? died?
So, I tried Pin7 of IC105 with the multimeter and measured 1v. So the pin is not dead.
Also here are the results from the 40010:
Pin Me Expected
CCLK 4 1.76v ~1.2v
RAS 34 1.01v ~0.9v
RAMRD 29 4.93v ~3.5v
nCPU 14 2.57v ~2.5v
ROMEN 27 2.84v ~2.8v
PHI 19 2.06v ~2.1v
READY 22 1.33v ~1v
244en 23 4.95v ~4.5v
CCLK, RAMRD, and maybe READY all look too high.
Happy to test anything else, now that I used the multimeter and didn't blow anything up (so far).
This means that the RAM is not read very often.
Now You must have 4 hands.
ROMDIS on expansion port. signal to ground And check RAMRD voltage.
Ground is on screw at flopy drive too.
Quote from: McArti0 on 06:49, 02 April 24This means that the RAM is not read very often.
Now You must have 4 hands.
ROMDIS on expansion port. signal to ground And check RAMRD voltage.
Ground is on screw at flopy drive too.
Just to confirm:
1. Connect ROMDIS to ground first
2. Measure RAMRD voltage
I'll get one of my kids to help me. 🫣😅
Sorry. ROMDIS to ground is nonsens :picard:
Quote from: McArti0 on 11:52, 02 April 24Sorry. ROMDIS to ground is nonsens :picard:
Haha, no problem. ;) Are there more diagnostic tests I can do? Are the RAM chips a likely cause?
Ok ROMDIS to 5V pin28 of ROM. check if anything on the screen changes color.
and monte carlo REFRESH Z80 pin30 to BUSREQ pin37. check if anything on the screen changes color.
Quote from: McArti0 on 21:16, 02 April 24Ok ROMDIS to 5V pin28 of ROM. check if anything on the screen changes color.
and monte carlo REFRESH Z80 pin30 to BUSREQ pin37. check if anything on the screen changes color.
Thanks once again, for sticking with this.
Connecting Z80 pin30 to BUSREQ pin37 didn't change the screen. (Wasn't sure if monte carlo was an autocorrect thing)
I wasn't sure which ROM chip, so I tried pin28 of 40015, 40025, and also 40010... connected to ROMDIS pin43 on the expansion port. Also didn't change the screen.
Actually, I just checked which pin is REFRESH on Z80. Is it pin28 and not pin30?
I will try Z80 pin28 to BUSREQ pin37 in the morning.
Quote from: mmldrm on 12:03, 02 April 24Are the RAM chips a likely cause?
yes. it's just not clear which one(s).
Pin30 pin37 expansion port. Z80 pin 28,25 Sorry.
Quote from: McArti0 on 06:16, 03 April 24Pin30 pin37 expansion port. Z80 pin 28,25 Sorry.
Connecting Z80 pin30 -> expansion port pin37 : no change to screen
I wasn't sure what Z80 pin 28,25 meant, sorry.
Looking at Z80 docs, pin25 is BUSRQ and pin28 is REFSH. Connect those? I didn't want to make a guess and do damage. ;D
All what i write to You I was tested on my real 6128. Still live. :D
Quick short touch.
Quote from: McArti0 on 06:16, 03 April 24Pin30 pin37 expansion port. Z80 pin 28,25 Sorry.
what do you want to achieve by that?
Quote from: mmldrm on 13:54, 03 April 24Connecting Z80 pin30 -> expansion port pin37 : no change to screen
Your RAM is currently malfunctioning. The only thing you can achieve by connecting other pins would be that you have a totally black screen.
If you have a ROM board or Dandanator or M4 you can execute the Amstrad diagnostics ROM. If a subset of RAM IC shows in red it's most likely those ICs or maybe the LS373 latch. If all RAMs appear red, I would check the MUX chips.
Did you check if any of the RAM ICs gets hotter than the rest?
artifacts resulting from accidental writes to frames that I see on my screen
Quote from: eto on 15:43, 03 April 24Quote from: mmldrm on 13:54, 03 April 24Connecting Z80 pin30 -> expansion port pin37 : no change to screen
Your RAM is currently malfunctioning. The only thing you can achieve by connecting other pins would be that you have a totally black screen.
If you have a ROM board or Dandanator or M4 you can execute the Amstrad diagnostics ROM. If a subset of RAM IC shows in red it's most likely those ICs or maybe the LS373 latch. If all RAMs appear red, I would check the MUX chips.
Did you check if any of the RAM ICs gets hotter than the rest?
Unfortunately no ROM board, Dandanator, or M4 here. A friend owns this 6128 and I volunteered to investigate, with my very limited knowledge. (I'm more a software guy. I think I have already proven here that I am not much of a hardware guy! 😅)
Maybe I could buy a Dandanator on eBay for €50 and hopefully sell it again without losing too much money, but it is a risk for something I would use once (and not even my 6128).
I will check each RAM IC for temperature. Could I also do continuity or diode checks with a multimeter?
Thanks,
M
Quote from: McArti0 on 15:23, 03 April 24All what i write to You I was tested on my real 6128. Still live. :D
Quick short touch.
Haha, good to know! I also don't want to accidentally do something different to what you did. 🫣
So I connect Z80 pin25 to Z80 pin28? A quick touch? And I should see a change on screen?
That will lead to nothing.
You are trying to diagnose something, that you have no clue about on how it works, with a tool that is insufficient for the job (a multimeter cannot answer the question on which RAM chip is dead that way) and also you are not really familar on how to use a multimeter.
Just asking on how you want to get any diagnosis out of that approach. Do yourself a favor and find someone who can diagnose it for you.
There is a schematic available, you need to be able to read it and at least an oscilloscope to understand what signals are lookging good and which ones are not.
For now we can only check RAM bank one (assuming not any of the other chips are dead like the MUX chips or the Latch).
So check chips IC127-IC134. This is Bank1. Check Pin P14 of each chip. It should change its value. So on a voltmeter it would look like you have a voltage in between +5V and 0V. But it cannot be either +5V and not 0V. +5V would mean a line is allways high, and that is a stuck bit and a line that is allways 0V is stuck at low level. Both indicate a faulty RAM chip. If all Chips are the same (all low for instance) it is more an indication of a faulty logic chip.
Yes.
I'm trying to find a procedure that will allow us to recognize whether RAM or ROM is damaged, without using an oscilloscope or dandanator.
SerErris. RAMRD is near 5V Ram is never read by Z80.
RAMRD at 5V does not need to mean anything.
CPU is first reading from ROM and only after quite some initializations it is actually reading something from RAM. The GA setup with colors for instance already have happend at that stage, so you would at least see a blue screen, not white on black border.
If the ROM is the culprit here, then that would lead to this scenario as well.
You should check all the ROM datalines if they are stuck.
Quote from: mmldrm on 23:15, 01 April 24Quote from: McArti0 on 15:15, 01 April 24What about this Pin7 of IC105? died?
So, I tried Pin7 of IC105 with the multimeter and measured 1v. So the pin is not dead.
Also here are the results from the 40010:
Pin Me Expected
CCLK 4 1.76v ~1.2v
RAS 34 1.01v ~0.9v
RAMRD 29 4.93v ~3.5v
nCPU 14 2.57v ~2.5v
ROMEN 27 2.84v ~2.8v
PHI 19 2.06v ~2.1v
READY 22 1.33v ~1v
244en 23 4.95v ~4.5v
CCLK, RAMRD, and maybe READY all look too high.
Happy to test anything else, now that I used the multimeter and didn't blow anything up (so far).
The voltage readings are depending on your multimeter and how quick it reacts on changes (e.g. how much it averages). It is not the perfect tool for analyzing digital signals.
We are talking about 4Mhz frequency for the PHI signal for instance and all the others are also pretty much aligned to that frequency.
For real understanding on what is going on you would need at least a cheap oscilloscope with enough bandwidth:
https://www.amazon.de/dp/B0C1SLST75
The above one is the bare minimum capabale Oscilloscope I found on Amazon. The cheap ones, are not fast enough (500khz or even lower) to actually see anything.
You can also use a logic analyzer as they are just much cheaper, however not the same as an oscilloscope.
This is just one of the examples.
Sorry for the german Amazon links.
https://www.amazon.de/dp/B07K6HXDH1
Back to the Signals:
Your 244en is also always high. So that means that there is no IORequest coming into the GateArray. The 244en signal is created by two bits from sequencer (which is running as we already worked out) and the IORQ bit. It goes down when the CPU sends an IORQ to be able to get the output to the GA.
That it never goes down means, the CPU is never sending an IORequest.
A interpretation of that is: ROM is dead.
(obviously there are other reasons possible, like GA defect, but ROM is most likely here).
Please go ahead and measure the data pins on the ROM (IC103). If they are stuck, the ROM is dead.
Voltage on Data line of Rom is not any info, because always R-rfresh is on this line. :(
Quote from: SerErris on 22:11, 03 April 24That will lead to nothing.
You are trying to diagnose something, that you have no clue about on how it works, with a tool that is insufficient for the job (a multimeter cannot answer the question on which RAM chip is dead that way) and also you are not really familar on how to use a multimeter.
Just asking on how you want to get any diagnosis out of that approach. Do yourself a favor and find someone who can diagnose it for you.
First of all, thank you for your help and suggestions in later replies. I know it can be frustrating to be helping someone with little understanding of electrical engineering and CPC hardware. (I did maybe one university course 30 years ago, and have no access to an oscilloscope.)
This story started with a friend telling me he got his 6128 out from the attic after many years and it had this boot problem. I offered to take a look, hoping it was something simple enough for me to fix... but it looks like it isn't so simple.
I thought maybe with some expert knowledge on the forums that I/we might find the cause and that the fix might be simple (swap out a socketed IC, for example) so I registered and posted on here. Maybe it will reach a dead end without diagnostic tools, but I wanted to try my best and avoid this 6128 going into the bin.
You are 100% right that the best way to fix computer is to find a local expert. But time is money and I think an expert would cost more than the 6128 is worth, and this was just a fun challenge, trying to learn and save a little bit of 8-bit history.
Anyway, thank you and McArti0 for taking the time to read and reply to this post. I will trust you guys if you tell me there is nothing more that can be done (without equipment and knowledge), then I/we tried our best.
Thanks again
M
P.S. I will give those RAM/ROM measurements a try after work today, thanks.
Quote from: SerErris on 10:31, 04 April 24CPU is first reading from ROM and only after quite some initializations it is actually reading something from RAM. The GA setup with colors for instance already have happend at that stage, so you would at least see a blue screen, not white on black border.
Black border, grey/white screen is typical when RAM is malfunctioning. If ROM is dead, you will have a completely black screen. I have repaired both situations several times and it was always RAM when it's the grey/white screen.
And when looking at the firmware this also makes sense. That's my understanding from reading the source:
As long as the ROM works, the firmware can do (not many but) a bit of initialisation purely in ROM before RAM is absolutely crucial to work properly. These first steps in ROM include setting the GateArray to Mode 1 and setting the CRTC registers to the right values for a 50 or 60Hz display. The first few thinbgs in firmware are mostly sequential, where it uses JP or JR statements. No RAM is needed here.
But after the initial "easy" things, the firmware then starts to CALL subroutines. And a CALL needs the stackpointer in working RAM. So latest when the first subroutine tries to return, the boot process will fail as the return address cannot be read from RAM anymore. It simply can't get to the point where the palette is initialised.
When z80 has no data connected, does it read command 00 or FF?
This is how I recently simulated the problem on a 464: one of the Dout pins of a single RAM IC is connected to GND - and voilà - the black border / grey screen. Remove the short - and it's back to normal again.
Sounds absolutely reasonable.
So please to the check with the multimeter to check every data pin of bank1 (you can ignore bank2 for now) and check if any databit is stuck.
Also if you have a EPROM programmer, you can replace the ROM with a diagnostic ROM.
As the rest seems to function you will get an indication of which RAM is actually faulty.
Quote from: SerErris on 10:45, 04 April 24Your 244en is also always high. So that means that there is no IORequest coming into the GateArray. The 244en signal is created by two bits from sequencer (which is running as we already worked out) and the IORQ bit. It goes down when the CPU sends an IORQ to be able to get the output to the GA.
That it never goes down means, the CPU is never sending an IORequest.
A interpretation of that is: ROM is dead.
(obviously there are other reasons possible, like GA defect, but ROM is most likely here).
Please go ahead and measure the data pins on the ROM (IC103). If they are stuck, the ROM is dead.
I had a busy couple of days with work, but finally back to this. (Not sure if that is good news or not!)
So, the IC103/40025 ROM looks okay. I measured the data pins and all were >0.
Pin Value
11 4.14
12 4.14
13 4.13
15 4.19
16 0.63
17 4.21
18 4.22
19 0.74I will now go check the data pins on bank 1. (Thanks again for the help.)
Quote from: SerErris on 10:45, 04 April 24Your 244en is also always high. So that means that there is no IORequest coming into the GateArray. The 244en signal is created by two bits from sequencer (which is running as we already worked out) and the IORQ bit. It goes down when the CPU sends an IORQ to be able to get the output to the GA.
That it never goes down means, the CPU is never sending an IORequest.
The CPU is sending IO requests to the GateArray only when it tries to change something. E.g. screen mode or palette or enabling/disabling ROM. But in this case here, that happens only during the very first nanoseconds of the boot process - then it hangs and no further commands will be sent to the Gate Array.
It's absolutely impossible to measure these initial few commands with a multimeter.
If the boot process is successful this is probably different. I haven't tried it yet but I would assume that the firmware is constantly switching on/off the BASIC and firmware ROM to access the RAM in the same area. Then you will see activity on 244en. But if the system halts, there will just be no further interaction with the GateArray and thus the 244en signal will always be high.
Quote from: SerErris on 10:00, 05 April 24Sounds absolutely reasonable.
So please to the check with the multimeter to check every data pin of bank1 (you can ignore bank2 for now) and check if any databit is stuck.
Also if you have a EPROM programmer, you can replace the ROM with a diagnostic ROM.
As the rest seems to function you will get an indication of which RAM is actually faulty.
I just want to make sure - should I focus on testing pin2 (data in) and pin14 (data out) rather than the other pins, like address, etc.
(Unfortunately I have no access to an EPROM programmer.)
Quote from: SerErris on 10:00, 05 April 24Sounds absolutely reasonable.
So please to the check with the multimeter to check every data pin of bank1 (you can ignore bank2 for now) and check if any databit is stuck.
Also if you have a EPROM programmer, you can replace the ROM with a diagnostic ROM.
As the rest seems to function you will get an indication of which RAM is actually faulty.
So I checked pin2 and pin14 of each RAM chip (Bank 1, IC127-IC134).
Each pin2 read between 0.58v and 4.15v.
Each pin14 read 2.9v-3.0v, except IC127 which read 1.29v.
A side note - one time I switched on to this screen, which was a little different. Sadly, it hasn't happened again.
Quote from: eto on 22:06, 04 April 24This is how I recently simulated the problem on a 464: one of the Dout pins of a single RAM IC is connected to GND - and voilà - the black border / grey screen. Remove the short - and it's back to normal again.
I don't quite know how to apply this information to my malfunctioning 6128, other than it being more evidence that it is most likely a RAM problem, but thanks!
If I don't get positive confirmation of the issue, at least the RAM chips are cheap to replace. So I could try that if all else fails.
Thanks again!
Quote from: mmldrm on 17:48, 05 April 24Each pin14 read 2.9v-3.0v, except IC127 which read 1.29v.
I suspect that this shows that data is being read from all eight chips, with a mix of 1s and 0s mostly averaging out at ~3v, and that the 1.29v just happens to be data with more 0s than 1s? i.e. the RAM chips look ok?
Or, if it makes IC127 look suspicious, I am probably happy to try replacing IC127 to see if that makes a difference. I just assumed that if 7 of the 8 RAM chips are working then it would get further than the black and white screen. But I guess it depends which area in memory has a problem, or because the RAM chips work together.
Each individual 4164 IC is 1bit, and hence there are 8 to make up the 8 bit data bus. It only takes 1 IC to fail and you have corrupt data.
Quote from: mmldrm on 17:48, 05 April 24A side note - one time I switched on to this screen, which was a little different. Sadly, it hasn't happened again.
This is the correct image from cold memories right after turning on. Are you sure it wasn't an image from a wire PAL replacement?
Quote from: Rabs on 21:56, 05 April 24Each individual 4164 IC is 1bit, and hence there are 8 to make up the 8 bit data bus. It only takes 1 IC to fail and you have corrupt data.
Thanks, I did think that was the case (having read many old discussions here) but that confirms it.
More and more, I might just buy the 8 RAM chips and cross my fingers that there are no other issues. At least those are inexpensive (around £10 I think?).
Quote from: McArti0 on 22:09, 05 April 24This is the correct image from cold memories right after turning on. Are you sure it wasn't an image from a wire PAL replacement?
Sorry, what is a wire PAL replacement? If it is a mod, I can check the board for it.
But this Amstrad is from a friend who owned it since he was a kid in the 80s and not really used it since the 80s either. (Either never, or almost never.)
Very interesting that it is the correct image though! :o
Quote from: mmldrm on 22:41, 05 April 24Sorry, what is a wire PAL replacement? If it is a mod, I can check the board for it.
Quote from: mmldrm on 22:02, 31 March 24Suspecting the RAM, I did the "RAM bank swap trick" by removing the IC118 and replacing it with some jumper wires in the appropriate positions (triple-checked!).
Quote from: McArti0 on 06:55, 06 April 24Quote from: mmldrm on 22:41, 05 April 24Sorry, what is a wire PAL replacement? If it is a mod, I can check the board for it.
Quote from: mmldrm on 22:02, 31 March 24Suspecting the RAM, I did the "RAM bank swap trick" by removing the IC118 and replacing it with some jumper wires in the appropriate positions (triple-checked!).
Thanks. When I see PAL, I think of video signals.
Definitely not that. The IC118 is back in place.
Three full forum pages of faffing around with pointless tests. Just swap the RAM and get on with enjoying your CPC.
Bryce.
Quote from: Bryce on 11:33, 06 April 24Three full forum pages of faffing around with pointless tests. Just swap the RAM and get on with enjoying your CPC.
I have now ordered RAM, but was hoping to have positive confirmation that RAM is the problem before doing so.
For example, removing the HAL chip (40031) completely makes no difference. So maybe I'm replacing RAM when the 40031 is the problem. That's the kind of thing that has been putting me off buying replacement parts.
40031
pin7 and pin17 have the same voltage. ~3v
pin8, pin12 have the same voltage.
pin9, pin19 have the same voltage.
ps.
Quote from: mmldrm on 17:48, 05 April 24A side note - one time I switched on to this screen, which was a little different. Sadly, it hasn't happened again.
WHEN you seen this image! with 40031 or without?
Quote from: McArti0 on 19:38, 06 April 2440031
pin7 and pin17 have the same voltage. ~3v
pin8, pin12 have the same voltage.
pin9, pin19 have the same voltage.
pin7 (2.18v) - pin17 (3.63v)
pin8 (1.67v) - pin12 (3.73v)
pin9 (0.66v) - pin19 (0.75v)
But should it be pin7 to pin16? (And pin17 to pin20?)
Actually, pin16 was the same as pin17... 3.63v. And only pin9-pin19 values are close.
ps.
Quote from: McArti0 on 19:38, 06 April 24Quote from: mmldrm on 17:48, 05 April 24A side note - one time I switched on to this screen, which was a little different. Sadly, it hasn't happened again.
WHEN you seen this image! with 40031 or without?
With 40031. Still only ever seen it once. :(
I ordered 8x RAM chips (and sockets), so I can replace the main bank. But I get the impression it might not just be RAM that is faulty here...
ramove 40031 and add 3 wire jumper pin 7-17, pin8-12, pin9-19
check by Ώ on multimeter if pin 7 is join to RAM pin15 ic127-ic134 (mutimeter show ~0 )
check pin 8 is join to IC109 pin10
check pin 9 is join to IC109 pin 6
https://www.cpcwiki.eu/imgs/4/4a/CPC6128_Schematic.png
Quote from: McArti0 on 21:15, 06 April 24ramove 40031 and add 3 wire jumper pin 7-17, pin8-12, pin9-19
check by Ώ on multimeter if pin 7 is join to RAM pin15 ic127-ic134 (mutimeter show ~0 )
check pin 8 is join to IC109 pin10
check pin 9 is join to IC109 pin 6
https://www.cpcwiki.eu/imgs/4/4a/CPC6128_Schematic.png
With 40031 replaced by 3 jumpers:
pin7 to RAM pin15 - all 8 RAM chips show resistance of 47-48
Ώpin8 to IC109 pin10 - 0.5
Ώpin9 to IC109 pin - 0.6
Ώ
Ok. any changes on screen?
next changes not wire 7-17 but 7-16
Quote from: McArti0 on 06:06, 07 April 24Ok. any changes on screen?
next changes not wire 7-17 but 7-16
Both 7-17 and 7-16 get the same black border, white screen.
Should I have a pin going to pin20? Like 7-16 and 17-20? The YouTube video for this shows a 4th pin.
BTW with speaker volume high, there has always been a barely audible pulse, roughly 1Hz. I don't know if that means anything. (Sorry, I only realised it was coming from the 6128 now. I thought it was coming from outside the house, it is so faint.)
normal.
20-17 or 20-16 for other bank reduce noise. its ok.
Check RAMDIS to ground and turn on. And check visible condition R124.
Quote from: McArti0 on 19:32, 07 April 24Check RAMDIS to ground and turn on. And check visible condition R124.
Hi,
Sorry, I was away for a few days. Do you mean these steps:
1. Connect RAMDIS to ground.
2. Turn on 6128.
3. Check voltage across R124
R124 normally connects ramdis to ground. We want to check if this is really happening.
Then check if the voltage on IC112 pin8 is the same on pin9.
Quote from: McArti0 on 16:34, 13 April 24R124 normally connects ramdis to ground. We want to check if this is really happening.
Then check if the voltage on IC112 pin8 is the same on pin9.
RAMDIS is grounded (0v)
IC112 pin8 - 4.34v
IC112 pin9 - 4.93v
Try RAMDIS grounded and turn ON CPC.
Quote from: McArti0 on 18:29, 13 April 24Try RAMDIS grounded and turn ON CPC.
RAMDIS grounded while turning on, still white screen. :(
Ok. And now when CPC working +5V connect to ROMDIS. IC103 Pin22 to Pin28
Quote from: McArti0 on 18:59, 13 April 24Ok. And now when CPC working +5V connect to ROMDIS. IC103 Pin22 to Pin28
Connect IC103 Pin22 to Pin28, +5v to ROMDIS, and switch on?
NO First ON next Connect
Quote from: McArti0 on 19:06, 13 April 24NO First ON next Connect
Thanks.
I powered on, connected +5v to ROMDIS, then connected IC103 Pin22 to Pin28. No change on screen at all.
(I must admit, I am very close to buying a cheap oscilloscope if we are close to running out of ideas/options here.)
Quote from: mmldrm on 20:36, 13 April 24I must admit, I am very close to buying a cheap oscilloscope if we are close to running out of ideas/options here.)
have you replaced the RAM ICs already? Or did you try the Amstrad diagnostics ROM?
we cant see anything because we have all colors white. :'( BUT ... ;D
When you start CPU. Next Disable ROM by const +5V on ROMDIS
Voltages on working good bank RAMs are:
Pin14 IC127 ~2V
Pin14 IC128 ~0V
Pin14 IC129 ~0V
Pin14 IC130 ~2V
Pin14 IC131 ~2V
Pin14 IC132 ~2V
Pin14 IC133 ~0V
Pin14 IC134 ~0V
This is address 39h pushing on stack after doing FF (RST 38) reading from bad gate.
bingo!
Quote from: McArti0 on 21:48, 13 April 24we cant see anything because we have all colors white. :'( BUT ... ;D
When you start CPU. Next Disable ROM by const +5V on ROMDIS
Voltages on working good bank RAMs are:
Pin14 IC127 ~2V
Pin14 IC128 ~0V
Pin14 IC129 ~0V
Pin14 IC130 ~2V
Pin14 IC131 ~2V
Pin14 IC132 ~2V
Pin14 IC133 ~0V
Pin14 IC134 ~0V
This is address 39h pushing on stack after doing FF (RST 38) reading from bad gate.
bingo!
Thanks. So... I used expansion port VCC (pin27) -> ROMDIS (pin43) for . It was near, and I had no hands helping me.
Pin14 on all 8 ICs (127-134) are wild. None of them are stable values.
Check voltage on All pins 2.
Also all unstable values.
Interestingly, while my second pair of hands (daughter) was holding VCC to ROMDIS, we got a bunch of yellow screen artefacts. Maybe she lost connection or connected VCC to RSET or RAMDIS, but I thought I would share.
It can't be a weak connection.
mayby beter point for RomDis is here....
Quote from: mmldrm on 17:27, 14 April 24Also all unstable values.
Interestingly, while my second pair of hands (daughter) was holding VCC to ROMDIS, we got a bunch of yellow screen artefacts. Maybe she lost connection or connected VCC to RSET or RAMDIS, but I thought I would share.
More likely she was coming in contact with some part of the clock source (before TTL conversion) which would cause multiple resets and similar effects.
Bryce.
Quote from: McArti0 on 19:24, 14 April 24It can't be a weak connection.
mayby beter point for RomDis is here....
I have attached an image of what I did with ROMDIS while checking the DRAM pins. Just to confirm it was correct.
Quote from: McArti0 on 19:24, 14 April 24It can't be a weak connection.
mayby beter point for RomDis is here....
In your latest image, what should I do between R112 and diode D201?
Should I take +ve from pin40 (IC201) and connect it to ROMDIS on the expansion port?
Place between r112 and diode is the same ROMDIS but i think better to hold probe. Pin40 of 765 is better to hold 5v
Quote from: McArti0 on 06:23, 15 April 24Place between r112 and diode is the same ROMDIS but i think better to hold probe. Pin40 of 765 is better to hold 5v
Thanks. We did this and there was nothing on-screen. I think this is correct because without ROM the board does nothing?
I measured pin2 and pin14 of IC127-IC134. All are still fluctuating between 0-5v, same as last time. :(
Quote from: mmldrm on 20:01, 15 April 24All are still fluctuating
but how? does ic127 have a different voltage from time to time?
What have you now in PAL 40031 socket?
Remember that we do not expect any changes on the screen because we do not have any colors set. All colors are white.
Before measuring, connect +5V to RAMDIS for 1 second, but the PAL socket should not be 40031, but 4 wires.
1 Turn ON
2 connect +5V to ROMDIS const
3 connect +5V to RAMDIS 1sek
4 measuring Pin14 and pin 2
Quote from: McArti0 on 20:23, 15 April 24Remember that we do not expect any changes on the screen because we do not have any colors set. All colors are white.
Before measuring, connect +5V to RAMDIS for 1 second, but the PAL socket should not be 40031, but 4 wires.
Ahh ok.
I had +5V to ROMDIS for the whole time I was measuring the RAM pin2/pin14 voltages.
I also had the 40031 IC in the socket.
I will do the tests again, with the 4 wires replacing the 40031 IC.
Quote from: McArti0 on 20:16, 15 April 24but how? does ic127 have a different voltage from time to time?
Yes, IC127-134 pin2/pin14 voltages were always moving between ~0.2V and ~4.8V. But I will retest with 40031 replaced with the 4 wires.
Should I keep +5V between r112 and diode while I am measuring the RAM voltages? Or remove it after 1 second, then test RAM?
rOm Dis long lasting connected
rAm Dis 1sek.
measuring voltages ... pin14 all memories and write where is ~0V
Quote from: McArti0 on 21:48, 13 April 24Voltages on working good bank RAMs are:
Pin14 IC127 ~2V
Pin14 IC128 ~0V
Pin14 IC129 ~0V
Pin14 IC130 ~2V
Pin14 IC131 ~2V
Pin14 IC132 ~2V
Pin14 IC133 ~0V
Pin14 IC134 ~0V
This is address 39h pushing on stack after doing FF (RST 38) reading from bad gate.
bingo!
Ok, I finally got a helper. :)
Pin14 IC127 ~2.5
Pin14 IC128 ~0.04
Pin14 IC129 ~0.04
Pin14 IC130 ~2.5
Pin14 IC131 ~2.5
Pin14 IC132 ~2.5
Pin14 IC133 ~0.04
Pin14 IC134 ~0.1 (I think - maybe 0.04)
Pin2 IC127 ~4.2
Pin2 IC128 ~4.2
Pin2 IC129 ~4.2
Pin2 IC130 ~4.2
Pin2 IC131 ~0.6
Pin2 IC132 ~4.2
Pin2 IC133 ~4.2
Pin2 IC134 ~0.7
So they are very clearly hi/lo values, if a little off (2.0v vs. 2.5v). Is pin2 ok at 4.2v hi?
Is this looking like RAM is ok but maybe RAM management isn't?
(Also, I finally bought the oscilloscope this morning. It won't arrive until around 24/4. Maybe we will have a solution before it arrives? 😂 )
Also, I know this has probably been a terrible process, but I am really enjoying learning about the 6128 internals. Thank you.
Yes RAM has been written!!! by 0011 1001 = 39h next this is instruction ADD HL,SP no write to RAM.
But why on Pin2 6Fh?
Quote from: McArti0 on 21:30, 17 April 24Yes RAM has been written!!! by 0011 1001 = 39h next this is instruction ADD HL,SP no write to RAM.
But why on Pin2 6Fh?
Fantastic! This gives me some hope. (Even though I already bought the replacement RAM. Oops.)
Tomorrow I can do the same test again, and make sure the pin2 result is definitely 11110110 / 0x6F. Maybe I made a mistake when writing the results.
Quote from: McArti0 on 21:30, 17 April 24Yes RAM has been written!!! by 0011 1001 = 39h next this is instruction ADD HL,SP no write to RAM.
But why on Pin2 6Fh?
...because I screwed up!
I just retried and got the same results on both pins.
Pin2 TAKE TWO
Pin2 IC127 hi
Pin2 IC128 lo
Pin2 IC129 lo
Pin2 IC130 hi
Pin2 IC131 hi
Pin2 IC132 hi
Pin2 IC133 lo
Pin2 IC134 lo
Pin14 TAKE TWO
Pin14 IC127 hi
Pin14 IC128 lo
Pin14 IC129 lo
Pin14 IC130 hi
Pin14 IC131 hi
Pin14 IC132 hi
Pin14 IC133 lo
Pin14 IC134 loSo 0011 1001 = 39h both times!
Ok. Now you need to check why the ram is not being read.
Give us sharp Photo your mainboard.
I removed the IC118 wires so you could see everything.
ok. Now test 74LS244.
When connect red wire whole CPC halted, screen too.
You have to be sure that you have drawn 0V on Pin1 LS244,
if not, you connect again.
Then check if D0-D7 on the left and right are the same.
Work for 6 hands.
Quote from: McArti0 on 21:14, 18 April 24ok. Now test 74LS244.
How do I test it? Do I start with the same ROMDIS and RAMDIS steps, then measure voltages?
no, I added it above. Sorry :blank:
Quote from: McArti0 on 21:14, 18 April 24ok. Now test 74LS244.
When connect red wire whole CPC halted, screen too.
You have to be sure that you have drawn 0V on Pin1 LS244,
if not, you connect again.
Then check if D0-D7 on the left and right are the same.
Work for 6 hands.
Should I do the same ROMDIS and RAMDIS steps first?
And 40031/IC118 is still replaced by 4 wires?
NO
YES
Thanks. I had to have the red wire connected before switching on, or it didn't do anything. I hope that is correct.
Results are interesting I think. I will share the full measurements across the IC, and then my comparisons. Maybe I got them wrong, so it is better you see everything.
IC114 Pin Measurements
----------------------
pin voltage
1 0
d0 2 1.4
3 0.09 d7
d1 4 4.15
5 0.09 d6
d2 6 0
7 0.09 d5
d3 8 4.15
9 5 d4
10 0
d4 11 4
12 5 d3
d5 13 0
14 0 d2
d6 15 0
16 5 d1
d7 17 0
18 5 d0
19 0
20 5
Comparisons
-----------
left right
D0 1.4 5
D1 4 5
D2 0 0
D3 4 5
D4 4 5
D5 0 0
D6 0 0
D7 0 0
Everything matches, except D0 has a strange 1.4v value.
I double checked these to make sure. But I can do the same test again, if it is good to have two sets of results.
Quote from: mmldrm on 10:50, 20 April 24Thanks. I had to have the red wire connected before switching on, or it didn't do anything. I hope that is correct..
This is an indication that after a certain point there are no writes to GA 40010.
Quote from: McArti0 on 12:49, 20 April 24This is an indication that after a certain point there are no writes to GA 40010.
Do I need to check traces and signals now?
You have done an amazing job guiding me with a multimeter, but I expect the oscilloscope to arrive in 5 days. I hope that helps to find the fault (or faults).
much better will be to buy Dandanator with test of components.
now we have 1.4v on D0. test it again and see if READY is 0
Quote from: McArti0 on 17:31, 20 April 24much better will be to buy Dandanator with test of components.
now we have 1.4v on D0. test it again and see if READY is 0
I seem to be very good at buying the wrong things (RAM, oscilloscope) at the wrong times. 😅
Ran the test again. With 1.4v on D0, READY (pin22 on 40010) is 0.
We won't stop where we should.
Look Fig. 8 here... https://bread80.com/2021/06/03/understanding-the-amstrad-cpc-video-ram-and-gate-array-subsystem/
N244EN have 0 two times. We find the first meaningless one. :picard:
Ok first We must short IORQ and READY , and turn on CPC.
pin 20 Z80 should be 0
First instruction is:
LD BC,#7F89
OUT (c),c
Our Z80 is stopped at write to GA
next we add RED connect and check if Pin1 244 is 0. If not, RED to reconnect.
GA is stopped.
now 244 is open and Left and Right side should be 89h 1000 1001.
After I short IORQ and READY, then turn on the CPC, pin20 of Z80 is 0 (well, 0.14v so I guess 'low' is correct).
Should I continue to short IORQ and READY? Or stop?
I removed IORQ->READY and added the RED connection. But voltage was 5v.
I expect you will say I must keep IORQ->READY so the Z80 remains stopped, while I do RED connect and measurements. But I wanted to confirm.
More simply, should I continue to short IORQ->READY while I also do IC115->R143 (red wire)? So both wires at the same time. (4 hands!)
(Also, I now have an oscilloscope, if that is useful during these tests.)
Yes permanetly stop Z80 by continue iorq-ready and next permanetly stop GA by continue Red.
Thanks. I thought that must be correct.
Is there a way of doing this with less than 3 people? 😅 I did see that I could use a little solder to fix the wires to the pins, but I'm not doing this because I don't own this 6128.
If not, it's ok, I have two teenagers that can help.
MacGyver could do it himself with one hand.
You can do It on stiff wires. z80 wait line (Ready) and iorq pin 20
Quote from: McArti0 on 07:46, 21 April 24Ok first We must short IORQ and READY , and turn on CPC.
pin 20 Z80 should be 0
First instruction is:
LD BC,#7F89
OUT (c),c
Our Z80 is stopped at write to GA
next we add RED connect and check if Pin1 244 is 0. If not, RED to reconnect.
GA is stopped.
now 244 is open and Left and Right side should be 89h 1000 1001.
I'm back! Sadly no MacGyver here, but a few kind family members are better than nothing.
Left and right sides were:
Left Right
D0 1.5 5
D1 0 0
D2 0 0
D3 0 0
D4 5 5
D5 0 0
D6 5 1.5
D7 0 0Maybe that is right and left? Left=pin2-17. Right=pin3-18.
Anyway, 10001010 I think. 8Ah? 🤔 Not quite right.
I will try again when my helpers are home, to get two sets of data .
Have you often confirmed that pin1 244 is 0?
I am not sure I do understand what you mean by stopping GA, GA will only stop if you stop the clock. Otherwise it will continue to output catch clock an will send RAS CAS to memory. And that will influence what you see on the right side of LS244.
You may hunt a ghost here esp. with the only tool available being a voltmeter.
Also if you see 1.5V on the left side, you have either not stopped the CPU or something is influencing the D7 line.
And again a Voltmeter is not good to troubleshoot digital logic.
I'm starting to think that this is some sort of never ending April fools joke. The initial failure you showed in the very first post is a classic symptom of a failed RAM and by far the most likely culprit. But instead of just swapping them and getting on with life, you've now spent over a month doing ends tests of questionable usefulness, which don't really tell you anything for certain and some of which were definitely totally pointless.
So I really have to ask. Why don't you just swap the RAMs?
Bryce.
Quote from: Bryce on 13:35, 30 April 24I'm starting to think that this is some sort of never ending April fools joke. The initial failure you showed in the very first post is a classic symptom of a failed RAM and by far the most likely culprit. But instead of just swapping them and getting on with life, you've now spent over a month doing ends tests of questionable usefulness, which don't really tell you anything for certain and some of which were definitely totally pointless.
So I really have to ask. Why don't you just swap the RAMs?
I genuinely apologise if this comes across as trolling or something. It isn't. I'm just trying to follow instructions from whoever is willing to take the time to help me.
As it isn't my 6128, nor my budget, I've been trying to avoid purchasing anything unnecessarily. For example, I'd love to go buy a Dandanator, but I can't justify it for this one-off investigation.
I did buy 64Kb of RAM (and sockets), but I think McArti0 managed to diagnose that the fault lies elsewhere (IC114/IC115 maybe?).
I could replace the RAM. I just hoped that we could get a definite diagnosis of where the fault lies first, rather than risk my soldering skills introducing more doubt.
I did buy a oscilloscope, so if that in any way helps to diagnose at this point then I'm more than willing to justify the purchase by using it.
Quote from: SerErris on 12:46, 30 April 24I am not sure I do understand what you mean by stopping GA, GA will only stop if you stop the clock. Otherwise it will continue to output catch clock an will send RAS CAS to memory. And that will influence what you see on the right side of LS244.
You may hunt a ghost here esp. with the only tool available being a voltmeter.
Also if you see 1.5V on the left side, you have either not stopped the CPU or something is influencing the D7 line.
And again a Voltmeter is not good to troubleshoot digital logic.
I do have an oscilloscope now (the one that you suggested), if that gives more options to try.
(I might also buy those mini grabber clips, rather than trust the assistance of my kind but inexperienced family members.)
Quote from: McArti0 on 07:12, 30 April 24Have you often confirmed that pin1 244 is 0?
I just bought some hook probes (now that I know that the are suitable) and evicted my family members from the team.
These should arrive by Friday, and will allow more reliable results.
Quote from: Bryce on 13:35, 30 April 24I'm starting to think that this is some sort of never ending April fools joke..
Then prove to him that his memory is faulty. So far I have found out that the 3rd byte of the Rom has the value 61 instead of 89. If at all he did it well with 3 people. For now, it turns out that z80 writes to frames. And that the ram has the correct contents. Maybe you could stop being mean and start helping.
Quote from: SerErris on 12:46, 30 April 24I am not sure I do understand what you mean by stopping GA, GA will only stop if you stop the clock.
Take a look at the illustration in post no. 100. GA stops itself due to the Lo signal on pin 1 of 244. This freezes the clock generator. I'll never believe you could be as blind as Bryce It's not like you.
A very cheap option would be to desolder the rom and put in a socket and a diagnostic eeprom.
That will tell you which ram chip is the problem here.
For all the RAM chips of bank1 check each output pin with the oscilloscope. This may show a stuck bit. However it might be also a problem with addressing. For instance a ram chip might have a singled dead or shorted address line. That would deliver wrong results upon reading as well.
But now with an oscilloscope you can start looking att the 244 enable line
What you are looking for is a square wave of some kinds when CPU wants to write to gate array. At best you solder a button from reset line to gnd to be able to reset the machine while having the oscillator running.
You can also check the other signals from gate array like crtc clock , ras and cas signals. They all need to form nice square waves with 5 volts. Any of those signals going to anything other than 0v or 5V is an indicator for a problem. Also any of those lines permanently stuck to 5V or 0v is as well a problem.
Quote from: McArti0 on 14:04, 30 April 24Quote from: SerErris on 12:46, 30 April 24I am not sure I do understand what you mean by stopping GA, GA will only stop if you stop the clock.
Take a look at the illustration in post no. 100. GA stops itself due to the Lo signal on pin 1 of 244. This freezes the clock generator. I'll never believe you could be as blind as Bryce It's not like you.
I am not sure what excuse you have to offend people here.
Neither is Bryce blind, nor is me. You might be a genius that we have been missing here all the time, but from what you are writing, it is not the case.
The signal on pin one of 244 is normally generate by the gate array, which means that pin23 of the gate array is an output. It will not react to whatever you do to the line. The worst case if you ground that line is, that you will create a direct short and damage the output buffer in the GA.
The gate array does not stop if you pull pin 23 low. It will actually not result in any change of the ga operation whatever you do to pin 23 of the gate array or pin1 of the 244.
You may want to read some of the available documentation.
Quote from: SerErris on 16:50, 30 April 24Neither is Bryce blind, nor is me. You might be a genius that we have been missing here all the time, but from what you are writing, it is not the case.
The signal on pin one of 244 is normally generate by the gate array, which means that pin23 of the gate array is an output. It will not react to whatever you do to the line.
Genius McArti for BLINDs.
ForBlind.png
Quote from: McArti0 on 13:58, 30 April 24Quote from: Bryce on 13:35, 30 April 24I'm starting to think that this is some sort of never ending April fools joke..
Then prove to him that his memory is faulty. So far I have found out that the 3rd byte of the Rom has the value 61 instead of 89. If at all he did it well with 3 people. For now, it turns out that z80 writes to frames. And that the ram has the correct contents. Maybe you could stop being mean and start helping.
I don't have proof, I have experience. I've repaired 100's of CPC's over many, many years and despite owning an armada of expensive test equipment, if I get a start screen that looks like that I swap the RAM after just a few basic voltage checks. 99% of the time it fixes the problem. Time is more expensive than a set of 4164's.
To put it another way: If it looks like a duck and quacks like a duck, it's most likely a duck.
I am being helpful. I'm passing my experience on, and my experience says swap the RAMs.
Bryce.
And the client wants proof without premonitions, because it's NOT HIS CPC.
He doesn't have the tools, so I help him the way he is capable of doing.
And don't insult my work.
Quote from: Bryce on 19:20, 30 April 24To put it another way: If it looks like a duck and quacks like a duck, it's most likely a duck.
If it looks like a duck and quacks like a duck, sometimes it's not a duck.
Quote from: McArti0 on 13:58, 30 April 24. Maybe you could stop being mean and start helping.
He did. He said very early in this process that it's most likely the RAM. Even if it's not the RAM there are only 6 more ICs that can be the culprit. Even if he would have swapped all relevant ICs it would have been maybe €20 and max 2h of work in total.
Quote from: eto on 20:18, 30 April 24Even if he would have swapped all relevant ICs it would have been maybe €20 and max 2h of work in total.
Ask mmldrm how many times he has desoldered an integrated circuit in other equipment in his life. ::)
@McArti0 , I really don't care whether you're right or wrong. Be careful before insulting people next time.
Quote from: Gryzor on 07:54, 01 May 24Be careful before insulting people next time.
Quote from: Bryce on 13:35, 30 April 24I'm starting to think that this is some sort of never ending April fools joke.
Way to keep it up.
Quote from: eto on 20:18, 30 April 24Even if he would have swapped all relevant ICs it would have been maybe €20 and max 2h of work in total.
If you have sources for the ICs (UK would be best for me) then I would love to know them.
The 64Kb of RAM that I bought was around £10, and so far I only saw a 40031 for £18 on eBay.
It would be good to know the best websites for CPC parts.
Quote from: mmldrm on 08:58, 01 May 24If you have sources for the ICs (UK would be best for me) then I would love to know them.
The 64Kb of RAM that I bought was around £10, and so far I only saw a 40031 for £18 on eBay.
It would be good to know the best websites for CPC parts.
I did not factor in the HAL as it is almost certainly not your problem. Especially since you already bridged it (after message #6 in this thread) and got no change. So even if it would be damaged, something else would be too. But just to be sure: bridge the HAL and replace the RAM, then you can be 100% sure that it's not the cause and once your computer works (don't forget to change the bridge so you can test the second RAM bank too), put in the HAL again and see if it works.
In case this HAL is the problem, you don't need the original. You can replace it by an ATF16V8. Not sure what it costs in the UK but here I can get it for about 2€ per piece in my favorite shop - or 5 pieces for 4-6€ from China. Programming is easy if you have an Eprom programmer or access to one. Even if not, I would be surprised if there is not someone on the forum who could program it for you.
There are no websites for CPC parts unfortunately. But that is no surprise as almost all ICs are standard ICs that can be sourced easily on Ebay or AliExpress for cheap. E.g. all the other 6 ICs that can be the culprit in your case are usually below 1€ per piece.
@McArti0 It's obvious that you have thought about what you suggest - however it's not clear what exactly you want to achieve with your ideas - and if they are correct or not. It would be good if you could not only write what test to perform, but also what purpose this test has. Without that context it's impossible to distinguish if your test is useless - or genius.
E.g. what do you achieve with the connection to CE of IC115?
@eto 1) iorq to Ready/wait (better by diode)
2) start cpc
Z80 executes LD BC,#7F89. OUT(C),C
OUT Produces iorq which does an eternal wait.
3) GA reads the number 89h a million times a second.
4) When the first clock inverter is blocking by HI or Lo. The clock stops working.
Attention. The old mainboard has the first inverter on pin 5 of the 74hcu04 but the new one on pin 13.
5) When connected pin 1. 244 to pin 5 (13) of the first clock inverter, the clock will stand and GA will be stopped in its tracks. If we draw Lo on pin 1 244, we have stopped CPC from 89h on the z80 side and gate 244 is open. (Of course, the diode helps connect only the LO state to the clock)
6) You can easily check whether the number 89h is also on the GA side on the date lines.
Quote from: McArti0 on 13:26, 01 May 241) iorq to Ready/wait (better by diode)
what will that do?
@etoDuring the wait line test, the TW z80 encounters a low state from IORQ in each clock. Therefore, the write execution of the first OUT instruction never completes.
How to test 74LS373 without desoldering.
The pictures show the procedure for stopping CPC on a single read from the internal RAM memory. at the end we have the state of open 74LS373. RAMRD and READY are low.
ORG #0638
LD HL,#B100
LD DE,#B101
LD BC,#07F9
LD (HL),A
.L0642
LDIR <----- here we are stoping CPC
By setting the data pins of the internal bus, you can check whether these states pass to the external bus side. RAM pin 14 set to Lo (grounded) should show the same on pin 2.
If you are surprised by the polarization of diodes, know that I am surprised too.
(WRONG IMAGES REMOVED UPON REQUEST)
Where is catode?
my multimeter works according to alternative physics. It's strange that the NPN transistor shows correctly.
Back to real physics, the previous pictures have incorrectly drawn diodes.
Quote from: McArti0 on 23:56, 02 May 24How to test 74LS373 without desoldering.
The pictures show the procedure for stopping CPC on a single read from the internal RAM memory. at the end we have the state of open 74LS373. RAMRD and READY are low.
ORG #0638
LD HL,#B100
LD DE,#B101
LD BC,#07F9
LD (HL),A
.L0642
LDIR <----- here we are stoping CPC
By setting the data pins of the internal bus, you can check whether these states pass to the external bus side. RAM pin 14 set to Lo (grounded) should show the same on pin 2.
If you are surprised by the polarization of diodes, know that I am surprised too.
Just out of interest. Have you actually tried to do this setup in reality and confirmed it works? Or is this all based on theory?
The reason I ask, is that connecting anything at all directly to a crystal pin will usually dis-balance the capacitance enough so that
the clock will either not start at all or will be unstable.
Bryce.
Quote from: Bryce on 10:25, 03 May 24Just out of interest. Have you actually tried to do this setup in reality and confirmed it works? Or is this all based on theory?
I did exactly that yesterday. Everything I write in this thread is tested (on real CPC16128)
Quote from: Bryce on 10:25, 03 May 24The reason I ask, is that connecting anything at all directly to a crystal pin will usually dis-balance the capacitance enough so that
the clock will either not start at all or will be unstable.
And that's how it should work. GA is supposed to permanently turn off the clock and thereby freeze itself in a specific state.
Quote from: McArti0 on 10:32, 03 May 24Quote from: Bryce on 10:25, 03 May 24Just out of interest. Have you actually tried to do this setup in reality and confirmed it works? Or is this all based on theory?
I did exactly that yesterday. Everything I write in this thread is tested (on real CPC16128)
Quote from: Bryce on 10:25, 03 May 24The reason I ask, is that connecting anything at all directly to a crystal pin will usually dis-balance the capacitance enough so that
the clock will either not start at all or will be unstable.
And that's how it should work. GA is supposed to permanently turn off the clock and thereby freeze itself in a specific state.
Well that's at least good to know. However, there's a reason why those capacitors and the 74 are extremely close to the crystal with very short traces. Just the additional capacitance and inductance of the extra wire is enough to disturb the clock. If the jumper wire is lying across the PCB and (as is the case here), the user doesn't have a scope to confirm the clock signal, then they have no way of knowing if their test is running as expected or not and the results can't be trusted.
Bryce.
Quote from: Bryce on 10:41, 03 May 24If the jumper wire is lying across the PCB and (as is the case here), the user doesn't have a scope to confirm the clock signal, then they have no way of knowing if their test is running as expected or not and the results can't be trusted.
I do have an oscilloscope now! And pin grabbers/clips should arrive today.
I know my kit was woefully inadequate initially (and still isn't ideal now) but hourly these will provide more reliable test results.
Thanks again for putting up with this situation.
@Bryce.
Notice that the clock inverter gets a heavy zero at the input - it has no chance of ticking even once. The freeze is sure and strong.On the address lines there is &B100 or &B101. I use rectifier diodes so they have a 60ns propagation time, they may not stop at the first LDIR address.
Quote from: Bryce on 10:41, 03 May 24no way of knowing if their test is running as expected or not and the results can't be trusted.
Test is Pin 24 z80 WAIT is permanent Lo after Step 3
Test 74LS373 by spider hardware ;D
Quote from: McArti0 on 11:01, 03 May 24@Bryce.
Notice that the clock inverter gets a heavy zero at the input - it has no chance of ticking even once. The freeze is sure and strong.On the address lines there is &B100 or &B101. I use rectifier diodes so they have a 60ns propagation time, they may not stop at the first LDIR address.
Hi McArti0,
you may have misunderstood what I meant (or I explained it badly?).
Yes, the clock will definitely stop as planned with your setup, that's certain. My query was whether it runs properly before that point
and it seems you've just answered that question yourself with the screenshot. If you take a look at the diagram, the clock glitched
a few cycles earlier. So the clock was unstable and it can't be said with certainty that the CPU acted correctly from that point onwards
and the entire system was in an unknown state there after.
Bryce.
Quote from: Bryce on 11:54, 04 May 24it can't be said with certainty that the CPU acted correctly from that point onwards
and the entire system was in an unknown state there after.
This diagram is not mine. It is borrowed from Bread80. 8)
https://bread80.com/2021/06/03/understanding-the-amstrad-cpc-video-ram-and-gate-array-subsystem/
Fig.5
I understand what you are talking about, but for now it is not important to us because even if I have disturbed the program code, for now we want GA to stop with READY Lo and RAMRD Hi or Lo. And that's exactly what's happening. even the address is correct. You can statically check whether 373 is open and output responds to input and 373 save state. The next test will be to catch 373 in latch. i.e. the first RAM reading, READY Lo, RAMRD Lo without steps, using an external OR gate made on the 74LS02. the reading should be 00h.
Quote from: Bryce on 11:54, 04 May 24the clock glitched
a few cycles earlier. So the clock was unstable
I tried this. My tests show that the clock is only wrong when touching the contacts with a bare hand and rubbing the wires against each other when the clock is active. there is no interference from the wires as the antenna MW radio.
never connect the pins this way.
I pushed the IORQ pin apart and now it doesn't connect to the socket without it.
Any update? Did the RAM ever arrive and get installed?
Bryce.
We are wating for 74LS02 and Breadboard for test 373. We have diods to test 244. We are waiting for some time.
mmldrm is reading z80 manual Fig 4-8.
Quote from: Bryce on Yesterday at 12:06Did the RAM ever arrive and get installed?
If mmldrm fixes this CPC, he will have to give it back. Would you give away your first CPC in your life? ;D Besides, here mmldrm learns digital electronics.
By the time it's fixed (when he gets around to replacing the RAM), he'll have spent so much money and time, that he could have bought his own one! :D
Bryce.
@Bryce He started by buying an oscilloscope, I'm afraid to ask what kind, but I think it was RIGOL, so the CPC costs went first. ;D
Rigol is a very good mid-range brand. I'd highly recommend them for hobby electronics. I use some of their devices too.
(but I already had my CPC when I bought them :) ).
Bryce.
A new memory test occurred to me.
RAMDIS HI, ROMDIS HI (of course after plugin wired version PAL)
and grounded D5,D4,D1.
Z80 always takes the CDh,CDh,CDh,CDh... i.e. CALL #CDCD (push to stack CDCD+3=CDD0)
Whole of memory fills by CDD0
1 1 0 0 1 1 0 1
1 1 0 1 0 0 0 0
_________________
1 1 0½ ½½0½
Its test other bits than FF (RST 38h)
I'll check if it works :D
@mmldrmTry one think. Cross Pin21 Z80 RD to other RD like RD expansion port.