CPC 6128 - white screen, black border

[mmldrm]

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.

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.

[eto]

Are the RAM chips a likely cause?

yes. it's just not clear which one(s).

[McArti0]

Pin30 pin37 expansion port. Z80 pin 28,25 Sorry.

[mmldrm]

Pin30 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. 

[McArti0]

All what i write to You  I was tested on my real 6128. Still live.
Quick short touch.

[eto]

Pin30 pin37 expansion port. Z80 pin 28,25 Sorry.

what do you want to achieve by that?

[eto]

Connecting 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?

[McArti0]

artifacts resulting from accidental writes to frames that I see on my screen

[mmldrm]

Connecting 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

[mmldrm]

All what i write to You  I was tested on my real 6128. Still live.
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?

[SerErris]

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.

[McArti0]

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.

[McArti0]

SerErris. RAMRD is near 5V Ram is never read by Z80.

[SerErris]

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.

[SerErris]

What 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:

Code Select Expand

        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.

[McArti0]

Voltage on Data line of Rom is not any info, because always R-rfresh is on this line. 

[mmldrm]

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.

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.

[eto]

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.

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.

[McArti0]

When z80 has no data connected, does it read command 00 or FF?

[eto]

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. 

[SerErris]

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.

[mmldrm]

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.

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.

Code Select Expand

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.74
I will now go check the data pins on bank 1. (Thanks again for the help.)

[eto]

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.

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.

[mmldrm]

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.

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.)

[mmldrm]

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.

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.