CPC6128+ repair job

[Spirantho]

Hi everybody,
I have a problem. Well, actually my 6128Plus has a problem.
I finally managed to score this machine on eBay at a worthwhile price, and - of course - it's dead. That's why it was £20.
First thing I did was plug it in and nothing happened. That turned out to be because the power switch had one of the wires come off.
Plugging this in, I found that it now did absolutely nothing, except at least now the power light came on. My first suspect was of course the RAM, and I began to desolder the first one and noticed it was very hot! In fact all four chips were getting much hotter than they should.
So, they all came out. I tested them in my Commodore C16 and sure enough each of the 4 4x64Kbit didn't work.
Putting in 4 nice new (tested) 41464, fired her up and... still nothing. Sometimes my TV displays a badly synced red screen, sometimes it's unable to sync (I'm using the correct 6128Plus kit from eBay to power and display).
I was wondering if anyone had any suggestions? Note I don't want this machine repaired, so sending it away isn't an option - I need to repair it myself, but obviously any help would be great to help my learning!
Thanks people! And a fantastic site this is, too.


Edit: I should point out that the data lines and lower address lines are all fluctuating more or less as I'd expect, and I'm testing with a Burnin' Rubber and a Robocop II cart.

[Bryce]

Hi Spirantho,
      it sounds like you have a good idea of what to do and also have the equipment to test the machine. So a few questions first:

1 - Is anything else getting hot? The ASIC?
2 - Have you checked that you have a clean clock signal (Pin 125 of the ASIC)
3 - Is the 5V supply to the ICs stable and at least 4.75V ?
4 - Have you tried connecting a speaker and seeing if holding the backspace / del gives a beep?

Bryce.

[Spirantho]

Thanks for the help!
Now I have the new RAM in, yes, the ASIC gets warm, but no more than I'd expect. The Z80 also gets warm. The RAM chips are vaguely warm but nowhere near as hot as the old ones.
My oscilloscope isn't fast enough to cope with the 40MHz crystal, but measuring with my multimeter, the voltage rises to 2.4V, so I'd guess it's ok. The clock on the CPU (pin 6) seems to be correct, anyway, so I don't think it's that.
The +5V line is running at +5.1V, and is smooth.
I'm currently running without the keyboard - but even so as I'm running with Burnin' Rubber, am I right in thinking it should be producing sound anyway, and the DEL button wouldn't have that effect. Nonetheless I just tried it and it still did nothing.

[Bryce]

Well if you connect the keyboard and press F1 at startup it will be in basic and then it should make the beep. The reason for this is I wanted to find out whether it's just the display that's not working or something more. Pin 125 of the ASIC is a 4Mhz CLK output, not the 40Mhz input. If the 4Mhz is working, there's a good chance that the ASIC is ok.

The next thing you can check is the cartridge port, because if the cartridge isn't being read properly, then the machine isn't going to start anyway. Do a continuity check between each cartridge pin and some spot on the PCB that they should be connected to. If all connections are ok, then move on to the Graphics:

The ASIC has 4 digital outputs per colour. Red0 -> Red3 (pins 113 to 116), Green0 -> Green3 (pins 109 to 112) and Blue0 -> Blue3 (pins 104 to 107). You should be able to read a fluctuating digital signal on most of these pins (depending on what the screen is meant to be displaying). These 12 signals are going to the 40464 (IC115 triple DAC) and you should also be able to read the analogue RGB signals on pins 15 to 17 of IC115.

Let me know how it goes....

Bryce.

[Spirantho]

Do I not need a BASIC cart for BASIC? I'm using a Burnin' Rubber cart from my GX4000 at the moment.
Pin 125 appears to be oscillating correctly.... I really hope this means the ASIC is working because I can't change this chip!
I'll do the cartridge continuity presently, but looking at the pins, there's data flying around just fine, and if it were a bad connection, there should be a difference depending on which cart I put in, and there isn't (BR, Robocop II or no cartridge, same effect).
The 40464 has pins 2,3,4 with a low voltage with occasional spikes (multimeter reads at 0.3V). Pin 5 is set constantly high (+5V). All other video inputs are set very low, with no discernable spikes.
Thanks again for this, it's appreciated!


Edit: Something that may be interesting....
A0 thru A6 are all working correctly if the CPU is accessing its bus sequentially. Lines A7-A15 are always low. In other words, address $0000 to $007F are being used in order by the CPU, at which point it seems to return to $0000. The oscilloscope is showing A0 changing twice as fast as A1, which is twice as fast as A2, etc. etc., until you get to A6... which is exactly what you expect in a binary counter.

[Bryce]

Oh, it's a red GX4000 cartridge I thought it came with the Plus and had Basic and Burning Rubber on it.

As far as the signals are concerned, if the ACID isn't making proper contact, there will be lots of data flying about, but the CPC still won't work properly. Check whether the SIN signal (Pin A3 of the cartridge socket) is switching at all (when a cartridge is connected).

The fact that only the Red pins 2,3,4,5 isn't a good sign though. This points back to the ASIC having problems and as you say, swapping this isn't an option.

Bryce.

[Spirantho]

(Did you see my edit above?)
Just checked A3 and it's going all over the place, which I'd guess is correct...?

[Bryce]

Yeah, just read the edit. Strange. Maybe someone who knows the firmware routines better than I do could comment on this? What happens on startup at 7F? Is it expecting something it's not getting? Or is A7 shorted to ground somewhere which would reset the CPC everytime it sets A7 to "1" ?

Bryce.

[andycadley]

If you're using a GX cartridge there is no firmware, it'd just launch straight into Burnin' Rubber (the firmware is stored in the Loco BASIC cart).

[Spirantho]

Ah, I was slightly wrong.
A0-A6 are all that are being used *after* the first half-second or so. Before that, A10 is accessed which is what I believe should happen.
Looking in WinAPE, there is a bootstrap code:
LD BC,#7F89
OUT (C), C
JP #0591
so A10 should pulse high right at initialisation (the 0591), and indeed it does. That means the CPU is executing the program more or less correctly. The weird thing is it then jumps off into no-man's land, and just cycles those 7 lines.
If the ROM isn't being read correctly, then maybe the data lines aren't being held, and are floating. This would explain the erratic behaviour, as the CPU would be doing random stuff. I wouldn't expect it to carry on though, I'd expect it to HALT when it reaches an undefined opcode. It's not executing NOPs because the data lines are all with data, albeit not as regular as the address lines.
Perhaps therefore the problem is that the ROM data isn't getting through to the CPU, but the bootstrap code (assuming WinAPE is accurate) is being executed.
The /ROMENABLE line is fluctuating, so that seems ok.... but it seems like it's just not being used.


Next bit of 'progress'....
I just tried with no cartridge in. The other address lines are cycling like A0-A6! This means that presumably it's just executing NOPs, which is fine. At least it means it's executing. The odd thing is the shape of the curve:
[attach=2]
Sometimes because my 'scope is a cheapish digital one, it can be misleading. But I'm wondering if the obvious disparity in amplitudes of the curve could have anything to do with it? This was A13 (I think - one of the higher A lines).
Here's a close-up of A11:
[attach=3]
So with no ROM, it's doing what we expect. With a ROM in, it's just getting junk. But it seems like the lines may be unstable at the best of times....?

[Bryce]

I'd definitely clean all the cartridge socket contacts to be sure the problem isn't there. But the question I keep asking myself is: What killed all the RAMs? and what else might it have killed in the process. Unfortunately I come back with the answer I don't know, but it could easily have killed the ASIC in the process

The strange curve is interesting though, it doesn't look like it's really floating, but it's not good either. Are there any signs that any other parts might have been replaced during previous repair attempts? The "semi-floating" curve can occur if a pull-up resistor of the wrong value was used for example. With the machine turned off, you should measure the resistance between A13 and 5V and A13 and GND and compare it with A11 or another known good address line.

Bryce.

[Spirantho]

If it were a dirty contact, I'd expect at least some sporadic activity. I don't think it's that (and it all looks clean).
I measured the resistances but it's >2MOhm to both +5V and ground, so that doesn't tell me anything I'm afraid.
As for what killed the RAM - that's exactly what I want to know! It's really odd for all the RAM chips to go kablooie like that, and I'm keeping a very close eye on the replacement chips - but all seems well so far.
There's no signs of repair on the board - the only solder marks are those from myself - I changed the electrolytics to be sure of that, and I also socketed the RAM chips to replace them. Apart from that it's identical to normal.
I don't think there are any pull-up resistors on the address lines are there? There's some 33Ohm resistors on the RAM address lines but they all check out OK.
Very puzzling. How I wish I could just remove the ASIC and try it in a working machine!

[andycadley]

This would explain the erratic behaviour, as the CPU would be doing random stuff. I wouldn't expect it to carry on though, I'd expect it to HALT when it reaches an undefined opcode.

From the Z80's point of view there is no such thing as an undefined opcode. Every possible combination of bytes does something even if that isn't normally a useful thing.

[Spirantho]

Good point.
What I really need is a homebrew cartridge with a space for an EPROM on. I can only burn up to 27C256 though, so there's probably no easy way is there? If I could do that I could write my own test ROM which would do what I tell it to immediately.
A quick thought - the most obvious problem with the machine is that the display doesn't sync. If there's anything on screen at all, it's all red with no hsync, and occasional lines of white. The display sometimes starts yellow.
Is it possible for a bad program to corrupt the display like this? Or should it always be static? In other words - can the ASIC be told to give a corrupt sync (i.e. switching quickly between screen modes or something)? If the CPU is executing NOPs, why is there no sync? Shouldn't the display just be constant?

[arnoldemu]

Good point.
What I really need is a homebrew cartridge with a space for an EPROM on. I can only burn up to 27C256 though, so there's probably no easy way is there? If I could do that I could write my own test ROM which would do what I tell it to immediately.
A quick thought - the most obvious problem with the machine is that the display doesn't sync. If there's anything on screen at all, it's all red with no hsync, and occasional lines of white. The display sometimes starts yellow.
Is it possible for a bad program to corrupt the display like this? Or should it always be static? In other words - can the ASIC be told to give a corrupt sync (i.e. switching quickly between screen modes or something)? If the CPU is executing NOPs, why is there no sync? Shouldn't the display just be constant?

without a cartridge installed you should see a coloured screen (purple or yellow or similar).
on the left side will be short black horizontal bars, spaced approx 4 scanlines apart. they will probably scroll up the screen.

what then should happen is that the asic and acid talk to each other and the cartridge is executed.

the display will probably look like this until the cartridge or basic/os program suitable values to the asic, a normal screen will then be shown, this may not be the correct colour, but should see a border.... if all is good it will be blue/yellow with text (if os).

if you *can* get burning rubber to work, and the cart is known good, then you can press r,t,g,5 to simulate joypad 2.
alternatively connect a joystick/pad if you have one for joypad 1.

[arnoldemu]

if you're seeing junk when a cart is in, it's probably the acid causing trouble and giving the z80 garbage to execute. 7f/7e or similar.. perhaps b1/b0.
if the cart is in and the acid is working correctly in it, you should see other data..

can you test with another cart?

[Bryce]

The sync signal is produced directly by the ASIC too. You should be able to measure this signal on pin 118 of the ASIC or direclty at the monitor port with your oscilloscope. If the ASIC isn't outputing anything on this pin, then it's definitely the ASIC that has died.

Bryce.

[Spirantho]

There definitely is *a* sync signal being produced, but the TV isn't syncing. It's almost like the VSYNC is valid but the HSYNC is wrong.
I think most sane people would probably write off this one, but - not being afflicted by "sanity" - I'm not giving up.
As luck would have it, there was this item on eBay:
http://www.ebay.co.uk/itm/250999218764
Now £30 for three Burnin' Rubber carts, one GX4000 box, two joypads and two manuals isn't that bad on its own, but when you consider the two dead GX4000s it's a bargain, even if it's just for parts! I reckon the chances of the ASIC being dead in both of these AND my 6128 are fairly low, so it's worth a shot.
I also bought myself a little Aoyue 8208 SMT rework station (not just for this - I'm not that crazy!), so with a bit of luck and a following wind, I may just get lucky. I'm going to try and repair one or both GX4000s first, and then I can try switching the ASIC from the 6128 into a GX4000.
Of course please don't stop with the ideas in the meantime! If I can get away without switching ASICs I'd like to.

[Spirantho]

@arnoldemu
I've tried with two carts and no carts, and it's identical each time. My understanding is that with no ROM in, the display should still be steady, whereas I'm getting no sync.... so I know it's not the ACID. But thanks for the help anyway!

[Bryce]

It looks like you know your stuff. I assume you know how difficult it is to swap one of these without damaging it, but I wish you luck.

The Sync signal coming from the ASIC is a csync signal so it should either have a good H and Vsync combined or nothing at all, so if you can record it on your osci, it's quite easy to see whether it's correct or not. Have you also checked that the signal is really making it to the monitor socket? And have you tested the SCART cable you're using on your good GX4000?

Bryce.

[Spirantho]

To be honest, I know my way around older machines well enough (I actually have a blog at mutantcaterpillar.wordpress.com but you may not like it because of the amount of Spectrums on it ), but I'm still learning about SMT.  I've learned enough to know I need a reworking station though!
I've not really looked at the sync signal, though - there doesn't seem much point because even if the sync is completely up the spout then the audio will still play - and it doesn't. That means that although the CPU is executing stuff, it's not doing anything.
One thing that I noticed but didn't verify is that the RAM data lines may be held low (or high?) but I need to look into that more tomorrow. It's possible the RAM controller in the ASIC is kaput, so that'll be my next tests....

[Bryce]

Although this site is 99% CPC, most of the guys here are general 8-bit fans (as long as you don't start praising the C64 ). Check out these threads: http://www.cpcwiki.eu/forum/other-retro/what-retro-hardware-do-you-have/
http://www.cpcwiki.eu/forum/other-retro/video-game-consoles-you-own-%28and-possibly-collect-games-for%29/

I dabble in everything from Acorn Electrons to ZX81s and everything 8 or 16 bit in between.... So I'm off to read your blog

Bryce.

[Bryce]

Seriously good blog. I suspect we are actually siamese twins who were separated at birth. I've bookmarked the site and have reading material for at least a week

Here's one of my patients that might give you some reading pleasure until your two GX4000s arrive.

Bryce.

P.s. If you do this much hardware repair, you really need to invest in a better oscilloscope.

[Spirantho]

Thanks for the compliment!
If you ever need a ZXVid module (a little board I make that fits inside the ZX81 modulator case, but gives a properly compliant composite video signal so you can connect to modern TFT TVs) then let me know and I'll give you a discount as you've been so generous with your help!
I would list all the machines I have at home and at work but it'd take a while. In terms of Amstrads, though, I don't have much - just two CPC464s at work, a CPC6128 of my own at home, and the 6128+ at work. And of course my GX4000 at home.

[fatbob]

I have a ZXVid - it was a godsend for one of my ZX81s that I couldn't get any other composite mod to work on.

Nice work & thanks for making them.