Repairing a 6128 and looking for a 40025 to test

[endangermice]

Hi Guys,


I'm currently in the process of repairing a CPC 6128, it looks like the previous owner had a stab at placing the 40015 and 40025 in sockets but failed somewhat miserably. I have managed to fit the sockets correctly and repair the broken tracks (using the circuit diagrams). Right now when I switch on the machine, I get a blank screen, though sometimes I get a sort of red strobing effect and sometimes a scrolling green screen covered in what look like random black squares (possibly CPU executing garbage). To cut a long story short, removing the OS and Basic ROM (40025) I can verify by hooking up equipment to the CPU address lines that it seems to be executing NOPs, so I know the CPU is good. I suspect the fact that I get random screen effects sometimes suggests that the video circuits are also fine.


When I place the 40025 into the board, the CPU starts executing about two instructions then seems to halt. This would suggest issues with either the RAM or the ROM. I'm more inclined to think ROM due to the fact it has clearly been removed before and has quite possibly been damaged in the process. It could of course be the RAM but with 16 of the little chaps to remove I'd rather test the ROM first.


Does anyone have a known good 40025 they would be willing to sell me or alternatively can anyone burn a 32K EPROM with the code? I can supply the required code for an EPROM burn - though I'd imagine you'd be able to source this as easily as I did.


Many thanks for your time, I'm keen to get this 6128 up and running - diagnosing and fixing it has been a fun project and I'm keen to end up with a resulting machine that actually works!!


PS - Great Wiki site, I have been browsing the site / forums for a few weeks now and have been very impressed by the amount of knowledge on display here!

[Bryce]

Hi Dame1701,
       If the original butcher managed to damage tracks, then he definitely fried the two ROMs aswell, I doubt anything is wrong with the RAM or anything else. I can send you two new EPROMs with the 6128 Firmware / Basic. Where are you based?

Send me a PM and we can organise this.

Bryce.

[endangermice]

Bryce that would be absolutely fantastic - please let me know how much I owe you and I'll send you some money through PayPal. I'm based in Cheltenham (England) and can PM you my address.


I have a replacement DISC ROM (Parados) so I should only need the 40025 which is 32K I believe? Presumably the machine will boot without the 40015 but would just issue a Press Play on TAPE message when I try to access the disc drive due to missing firmware..?


Cheers,


Damien.

[Bryce]

Correct. PM on its way.

Bryce.

[endangermice]

Excellent and I have responded. With any luck I'll have the old girl up and running again soon!

[Badstarr]

I just recently repaired a 6128, when I had replaced the fried components as some of the tracks the machine would power up properly but I had similar problems (black and white screen and other colour randomness when power cycling). I suspected it could be the ROMs not being initialised, however it turns out that the GATE ARRAY was dead, after swapping it with a spare one the machine burst into life with our favourite blue and yellow screen. So if you have no luck with the ROMs it may be worth checking the GA. Good luck with the repair!

[endangermice]

Interesting if the rom doesn't work that will be my next port of call - at least it's socketed! What's interesting is that CPU activity halts almost immediately with the ROM plugged in. Would a broken gate array cause this too - I guess it might since it's involved in the initialisation routine... Hmmm damn shame I don't have a spare one to test with! Oh well first things first I guess - Bryce I may well be after some more spare parts soon....


Cheers for the heads up!

[Badstarr]

I would suspect a faulty Gate Array could cause this sort of fault as when I was modifying my GX4000 I had a bit of a short on the ASIC ROM Enable pin which (although not all the time) caused some psychedelic crashes upon power up and with some games. Once I discovered this I fixed the shorted connection and it all worked properly again. I wouldn't automatically assume that the Gate Array is faulty if replacing the ROMs doesn't solve the problem. It could simply be caused by some over zealous previous modder (/loony with a soldering iron) breaking a connection to it, so checking the continuity etc might reveal the problem. The 6128 board I fixed had some pretty ham fisted modified power connections which had shorted to a 74LS and blown that and a few other things as well as the GA it seems so I know what a headache fixing these sorts of things can be .


Which model Gate Array do you have fitted to your 6128 board by the way? I do have a spare functional one somewhere but it might be a 40007 so might not be that useful as a replacement without rerouting a few pins.

[endangermice]

Ah yes - might be worth checking continuity between the pins too - as you well know a lot of the repair journey is trying one thing then another until you finally discover the solution!


I do have the full circuit diagram from the service manual so hopefully that will reveal which Logic chips etc. are connected to it.


Unfortunately, this one uses the latter 40010 so although i could modify it to test with a 40007 it would be easier if i could source a 40010. Bryce might be able to help me out with that! For now he has fixed me up with a new ROM which should arrive next week. Right now i'm attempting to take the path of least resistance but of course it almost certainly won't work out that way .


I'll let you know how I get on!


Cheers,

Damien.

[Badstarr]

That's the Gate Array I had fitted to my board, fortunately I did have a spare. I do believe however that a 40008 is pin compatible with the 40010. Maybe Bryce can confirm this for you. If it is, it at least opens some options up to you if GA is suspected to be the cause of the problem. As you say, the path of least resistance is the best way forward, do the simple stuff first before going to the expense/trouble of obtaining a new part. This is how I went ahead with the repair on my 6128, deal with the obvious, then check the less obvious like continuity etc, the less obvious then having then been repaired/ruled out I fitted the new Gate Array and finally Success!

[endangermice]

Got the new ROM from Bryce this morning, fitted it and alas it made no difference. I then had a quick chat with Bryce who had me check all of the Address and Data connections again. Lo and behold, when checking the paths between the CPU and the Octal buffer (74LS 244 - which I think serves to isolate the Gate Array from the CPU (it could be used to amplify the input signal but since the gate array is an IC, I would imagine to be an unlikely purpose...?), I found that data bus D3 was not connected to the CPU or ROM chips. A quick examination if the board revealed that I'd already fixed a broken link between ROM and CPU so it looked like the damage had cut off the entire line. A quick wire patch from the CPU to the buffer and the machine booted up in all it's glory. While I was at it, I installed a Parados ROM I ordered a while back for 800K 3.5" floppy formatting.

In testing so far, the CPC it seems to work perfectly. The drive controller can handle the large 800k format on my external 3.5" drive and I've even had the machine playing the Batman Forever demo which I reckon is a good test. Compared against the same demo running in WinAPE, they seem identical (apart from a the fact the CPC is smooth as silk  ).

Thanks to everyone on this forum who has offered advice during this fascinating and often frustrating journey, especially Bryce who has boundless patience and has tolerated many questions from me!

I will be doing a complete writeup of my experience fixing this machine so look out for that over the next few weeks!

I'm now going to enjoy playing around with something I haven't touched for about 20 years!

[Bryce]

Great to see an old CPC being brought back to life. The 74LS244 is there to isolate the Gatearray and RAM Data lines from the the main data lines. This is needed during RAM refresh cycles and when the Gatearray is reading the screen RAM.

Bryce. 

[endangermice]

Ah I see so it essentially breaks the link between GateArray and CPU when RAM is being refreshed and screen memory read? Clever solution - I'm enjoying learning about the internal workings on an electrical level - a somewhat different angle!


Thanks again for your help it's a fantastic feeling to finally have it running and marks my first 8 bit repair!

[ralferoo]

Ah I see so it essentially breaks the link between GateArray and CPU when RAM is being refreshed and screen memory read? Clever solution - I'm enjoying learning about the internal workings on an electrical level - a somewhat different angle!

Kind of. At a cycle level, each Z80 instruction is broken down into a number of T-states. In normal operation of "simple" instructions, each of these is 4 T-states long, of which the CPU triggers a memory request between T1 and T2 and samples the data bus at the start of T3 or T4, depending on instruction. Not all instructions fit this format, but a surprising number do, so Amstrad used this to their advantage.

Stepping back a bit, the video needs to be fed data at 2MB/s, at least during the active display part of the screen. There are two solutions to this - allow the CPU to always access the bus when it needs to and allow the video to access memory the rest of the time (which for instance causes the snow on the original CGA text display if you access video memory during the visible portion of the screen), or you can allow the video hardware to have priority and force the processor to delay when the memory is being accessed (which causes timing to be unpredicatable unless you know your code is exactly synchronised to a known point on the screen). The spectrum's approach has the lower 16KB of RAM separate to the upper 32KB and memory contention happens if you access this lower 16KB. There is also no contention during the border period, which actually is over half the time!

So, Amstrad's approach was a bit simpler. Basically, the assume that every instruction is a multiple of 4 T-states long and that memory accesses will always occur during T2. So, T1 and T3 are then free for the video to access memory. Whenever the CPU tries to access memory on a state that isn't T2, it is forced to wait using the WAIT signal. However, there's still the issue that whilst the memory access occurs during T2, but the CPU is expecting it to remain on the bus until potentially the end of T4.

What happens is that the gate array controls the memory access - the address lines pass through multiplexing chips so either the address from the CPU or CRTC are used depending on whether the state is T1/T3 or T2/T4 and the data lines to the RAM chip are connected to the gate array. The CPU isn't directly connected to the RAM, but instead via a buffer and a latch.

If the CPU is reading memory, the latch is set to capture data during T2 and at the end of T2 it holds the data, so the CPU continues to be able to see that in T3 or T4 when it actually needs it. If the CPU is writing data, the gate array allows the buffer to output onto the RAM data bus for T2 only. The rest of the time, the gate array has full access to the RAM data bus so it can decode the video data and turn it into pixels.

There are some casualties in this scheme - there are some quite common instructions that are 5 or 6 cycles long that get stretched out to 8 cycles, but on the whole it's quite an elegant system. It also shows its roots as a 6502 design where the CPU is clocked at 2MHz but can use the bus on any cycle and on these systems, you'd run the system bus at 4MHz, alternating accesses.

[endangermice]

Ah that rings a lot of bells from my assembly days thank you for such a clear and well written explanation!