News:

Printed Amstrad Addict magazine announced, check it out here!

Main Menu
avatar_Bryce

Running out of ideas.

Started by Bryce, 15:21, 19 June 14

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Bryce

Hi all,
     I'm currently fixing a few 6128s and one of them is driving me crazy. It experienced an over-voltage and at the moment it displays a white screen with black border on most starts, but sometimes the screen area is filled with a flashing pattern. The RAM had already been replaced before I got it, but the repairer had damaged some tracks at the RAM, so they were fixed first. The AY was getting very hot, so I swapped that too. Here's the situation since then:

- Voltages are good and stable to all ICs.
- Clock signals present.
- Reset circuitry is working.
- All passive components are tested and were ok.
- A known good CPU didn't help.
- A known good Gate Array didn't help.
- A known good PAL didn't help.
- Known good RAM didn't help.
- Checked all data and address lines for stuck/missing bits - none found.
- Checked most control signals - All present.
- Sensible looking data is being written and read to/from the RAM.
- Replaced ROM 0 - Didn't help.

At this stage I'm running out of ideas, if anyone has any tips I'd be glad to hear them. The only thing left to swap would be the 8255 and the CRTC, but my own suspicion is that I have missed a damaged track somewhere, but all visual inspections and tests haven't found it.

Bryce.

gerald

- Did you check the voltage with a oscilloscope, to be sure that it is really stable? all chip ?
- when you swapped for know good component, did you used one at a time, or did you swapped more tha one ? Did you test them on a working CPC, one, multiple ?
- Do you have a logic analyser ? tracing the boot process could help.

Side note : we really need to have a test ROM tu put on XMEM/LowerROM to test a CPC, using the parallel port as 1st display interface (LED) to at least diagnostic RAM/ROM(CRC)/CRTC/GA ...

Bryce

Quote from: gerald on 22:25, 19 June 14
- Did you check the voltage with a oscilloscope, to be sure that it is really stable? all chip ?
- when you swapped for know good component, did you used one at a time, or did you swapped more tha one ? Did you test them on a working CPC, one, multiple ?
- Do you have a logic analyser ? tracing the boot process could help.

Side note : we really need to have a test ROM tu put on XMEM/LowerROM to test a CPC, using the parallel port as 1st display interface (LED) to at least diagnostic RAM/ROM(CRC)/CRTC/GA ...

- Yes, voltages were checked with a scope (and were fine)
- Yes, swapped parts one at a time. The parts came from my socketed CPC which works fine.
- Yes, I used a logic analyser to check the data, address bus and reset process, but I didn't check the entire boot process. I just checked that "sensible data" is being sent and that the CPC didn't freeze or go into a permanent loop. Even when the CPC has been running for a few minutes, there is (varying) data being transmitted all the time. What I really need is a list of what (address and data) is being sent during the boot process, then I could trigger the LA on those words to see how far the process is getting.

I'm all with you on the diagnostic ROM, but I think it should be a stand-alone device with ROM and LEDs/LCD on its own PCB. That way it could check signals that are normally needed for normal ROMboard etc. If these signals were missing the diagnostic ROM on an X-Mem / MegaFlash or whatever would be useless.

Bryce.

arnoldemu

Quote from: gerald on 22:25, 19 June 14
- Did you check the voltage with a oscilloscope, to be sure that it is really stable? all chip ?
- when you swapped for know good component, did you used one at a time, or did you swapped more tha one ? Did you test them on a working CPC, one, multiple ?
- Do you have a logic analyser ? tracing the boot process could help.

Side note : we really need to have a test ROM tu put on XMEM/LowerROM to test a CPC, using the parallel port as 1st display interface (LED) to at least diagnostic RAM/ROM(CRC)/CRTC/GA ...
very useful and I have some test code I could adapt for this.

I do plan to test the startup state of all the crtcs already.

If you had to order the tests what would you want and which order?

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Bryce

#4
I'd like to know exactly what data is sent to the CRTC Data bus at startup, that would at least let me know that it is being fully initialised. After that it would be handy to know a few key addresses such as: When BASIC starts to initialise, what address is written to and what value is placed there?

Bryce.

P.s. I've gone back to fixing this CPC again after discovering that on the second 6128 (also an over-voltage problem) I had to fix EVERY SINGLE IC is getting very hot, so I suspect the entire board is fried. Not sure if this is worth fixing at all.

Bryce

Ok, this is really starting to annoy me!! Just once it suddenly booted to half the Amstrad Logo, but didn't make it as far as the Ready prompt. I restarted and it's back to white screen and black border! Resoldering all joints now, as it's probably a dry joint.

Bryce.

MacDeath


Bryce

I'm not giving up that easily!

Bryce.

gerald

Quote from: Bryce on 08:38, 20 June 14
- Yes, I used a logic analyser to check the data, address bus and reset process, but I didn't check the entire boot process. I just checked that "sensible data" is being sent and that the CPC didn't freeze or go into a permanent loop. Even when the CPC has been running for a few minutes, there is (varying) data being transmitted all the time. What I really need is a list of what (address and data) is being sent during the boot process, then I could trigger the LA on those words to see how far the process is getting.
I think your best friend is http://cpctech.cpc-live.com/docs/os.asm
1st part of the boot is ROM overlay/CTRC/GA init  [from 0x0591 to 0x05e5 ]
Then there is the actual boot [from 0x61f]  where some HW init and FW init are done
   - 0x0638-0x0642 quite long LDIR init
   - From  0x0652 the stack will be used for return address, so if RAM is dead, the CPC may crash on return.
   - ....

Quote from: Bryce on 08:38, 20 June 14
I'm all with you on the diagnostic ROM, but I think it should be a stand-alone device with ROM and LEDs/LCD on its own PCB. That way it could check signals that are normally needed for normal ROMboard etc. If these signals were missing the diagnostic ROM on an X-Mem / MegaFlash or whatever would be useless.
A dedicated device is ideal, but with the XMEM/LowerRom availability a single ROM is easier to distribute : see this as 1st aid kit. For sure, if the GA is dead to the point of not issuing proper signal the ROM may not start. A dedicated device for detecting these failure is tricky.
Quote from: Bryce on 12:12, 20 June 14
Ok, this is really starting to annoy me!! Just once it suddenly booted to half the Amstrad Logo, but didn't make it as far as the Ready prompt. I restarted and it's back to white screen and black border! Resoldering all joints now, as it's probably a dry joint.
These intermittent failures are a paint to debug !!! However, there is a good chance that your problem is on the memory side. By memory side I mean the datapath (address/data + buffers).

Bryce

That's what I've been concentrating on: Data path. especially as the RAMs were swapped by someone else. I even replaced the 100nf Caps on the lower 64K to make sure they weren't the problem (some of them were cracked). Still no luck though. I'll try again tomorrow.

Regarding the diagnostic tool. A ROM image would cover quite a bit for most users, a stand-alone device would be the next level for serious failures. I think both would be useful, depending on whether it's for the casual user or someone who regularly fixes CPCs.

Bryce.

Joseman

Hi

sorry for the interference  ;) , what kind of oscilloscope are you guys using?

I want to buy one, any recomendation? (it'll be used for laptop repairing, pcb's and of course, CPC)

Thankyou!!

Bryce

I have several. My trusty analogue is a classic Tektronix 2465, old but still unbeatable, I've used these since my University days. My digital scope is an Agilent DS3100 Series. Relatively cheap, but very reliable.

For you it depends what frequencies you intend working with and what your budget is. Scopes have got a lot cheaper in the last years. You get a lot for your money these days. A simple scope cost a fortune back then, now you can get a very good scope for under €1000.

Bryce.

SyX

Yes, something as the PCW diagnostic board used by official Amstrad repair services.

Bryce

I'd go further than that. I'd use a PIC with a set of standard tests that it goes through and tells you the situation on the LCD. There's a lot you can test from there. If the CPC boots you could then offer further tests on ROM.

Bryce.

Joseman

Hi

Thanks Bryce for the answer, i think that i'll not ask more questions in this thread about an oscilloscope.

Bryce, i'll send you a PM with 2 o 3 questions if you don't mind...

Thanks!



Bryce


MacDeath

I guess it could actually be a nice excuse to develop a system to perform efficient diagnostics for those old Amstrads.

Be it a checklist or a few test hardware or both.

Bryce

So this 6128 turned out to be a complete bastard of a failure. After probing signals all over the place and getting nowhere, I started comparing startup sequences and realised that there were random bits appearing on the address bus, but only between the RAM and the multiplexer IC104. I was about to replace it when I accidently discovered something else. I had just moved the PCB from one desk to the other when all of a sudden it booted. The only difference was that this time there was a plastic pen on the desk under the PCB. When I removed the pen it wouldn't boot. After a bit of experimenting, I discovered the PCB would boot if it was slightly flexed downwards at each end, so I suspected a dry joint or a cracked track, but none were found.
The owner had replaced the RAM already and had caused 5 or 6 broken tracks in the prcoess, so I decided the problem must be under the sockets he'd added although all testing said the tracks there were fine. After removing all the sockets I discovered that a single pin of the original RAMs had been left in one of the holes, when the socket was added, this had bent over and was touching the pad next to it, but it wasn't shorting, due to the amount of dirt and oxidation, it was just causing a capacitance, hence chaos on the address lines. Bending the board even slightly had been parting the capacitor and removing the problem. Once this was removed the CPC booted properly every time.

However, the problems aren't over. The CPC still hangs if AMSDOS is installed. It will start with a different ROM in ROM 7, but not with AMSDOS (or ParaDOS),  so I suspect there's still a problem in the FDC circuitry. Time to go looking for that.

Bryce.

P.s. Thanks Gerard and Arnoldemu for the tips on what it could be.

pelrun

Yikes! I guess the lesson is if you're trying to fix someone else's botched repair, start by removing *everything* they've done and start over...

arnoldemu

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

arnoldemu

I answered Bryce privately.

When AMSDOS starts up, it first checks if it is ROM 0. It will be ROM 0 if /EXP (connected to 8255) has been set to 5V. 0V makes it rom 7.

If it's ROM 0 it will automatically try |CPM.

If it's not ROM 0, it will setup the FDC and quit the ROM to eventually get to basic.

Setting up the FDC:

It writes 3 bytes. First is "3". Now it checks if the FDC is ready by reading fb7e. It expects bit 7 of fb7e to be 1, if it's not it will hang until it is.
To write the command byte it also expects bit 6 to be 0. Only then will it write the byte to fb7f.

If it tries to boot CPM it still sets up the FDC, so it'll hang for the same reasons, but it will also hang if the drive is broken and is reporting ready all the time and there is no disc in the drive.

My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Bryce

Quote from: arnoldemu on 14:00, 14 July 14
It writes 3 bytes. First is "3". Now it checks if the FDC is ready by reading fb7e. It expects bit 7 of fb7e to be 1, if it's not it will hang until it is.

Ok, and what does the FDC need to be ready? Is it checking external signals or is it just that its internal routines are ready?

Bryce.

arnoldemu

Quote from: Bryce on 15:32, 14 July 14
Ok, and what does the FDC need to be ready? Is it checking external signals or is it just that its internal routines are ready?

Bryce.
it's internal. it means the fdc is ready to receive the command (i.e. it's not processing one currently)
My games. My Games
My website with coding examples: Unofficial Amstrad WWW Resource

Gryzor

What an investigative process, damn it :D

Powered by SMFPacks Menu Editor Mod