Slow A4000 after overhaul

[giantclam]

What I'm looking at...

blue arrow --- is that a crack in that corner of the PLCC socket?

green line --- I'm looking at the alignment between IC legs & socket contacts

yellow lines --- I'm looking at the PCB printing (IC outline) versus the PLCC socket edge (they should be parallel) -- the top yellow line I've having problems convincing myself to top side of the socket doesn't look straight either.

However, images can be deceiving ...it just looks dodgy from the .jpg perspective I have =)

Note: anywhere around here would be a prime area of concern wrt your issue

[Kin Hell]

Buster 9 shouldn't make a difference in terms of speed.

Bulge on sides of socket look about right for me. - Hairline crack/s to the walls of the buster socket would/could cause issues, though again, I would not have thought so in terms of overall system speed.

Above pic not clear enough to ascertain true condition of socket.

[pandy71]

Originally Posted by Screechstar

… and I’ve just spent an hour train journey trying to find a 50MHz capable logic probe available in the UK with no avail unless it’s a 2nd hand eBay job. I can get them in the US but shipping is more than the probe haha!
... and so now ordered a £55 (delivered) 100MHz AliExpress oscilloscope instead as it's cheaper than the decent logic probes. It's the one reviewed by Adrian's Digital Basement a while back so is basic but functional. This should help a lot. Once it get's here!

What with https://github.com/gusmanb/logicanalyzer ?

[Screechstar]

Hey, thanks for the info on that about the buster… good points to note and you’re right that is an area to look at as it was on the periphery of the capacitor leakage.
I’ve been checking some continuity around buster and some of its signals with the logic probe but there’s definitely more to check. I’ll put the oscilloscope to good use as even just a bad contact could scupper a signal here and there. I’ll likely re-seat it just to be sure when I’m doing those checks.
The socket does look ok to my untrained eyes… image attached.

And great project for the logic analyser, I didn’t realise that existed so good to know! Ta!

[giantclam]

Originally Posted by Screechstar

The socket does look ok to my untrained eyes… image attached.

Thanks for the better image (they can be deceiving =) ~ it does look OK in that image, no crack, some socket wipes look a little recessed (could be lighting), but nowhere near as dubious looking as in the original images.



As long as the acid creep didn't reach the socket, it's likely OK ...but that style of socket is very good at hiding damage underneath it (not just Amigas, I used to do industrial electronics repairs and they were a bane of trouble when something got splashed onto boards that shouldn't be).


Time to sit on hands and wait for the 'scope you have coming...

[hooverphonique]

Originally Posted by pandy71

What with https://github.com/gusmanb/logicanalyzer ?

I've looked at this project before, and it looks quite impressive - did you try it out?

[Screechstar]

Originally Posted by giantclam

Time to sit on hands and wait for the 'scope you have coming...

Thanks, yeah I'm really looking forward to getting the 'scope - it should be here before the end of the month and then I can hopefully really see what signals on the bus are being driven and which aren't.

It'll give me some time to try and get my head around the Ramsey / Gary / Super Buster interactions too, to know what signals I should even look at and try to work out what they should look like. Those DSACK & STERM memory lines and a number of the Buster signals are hot on my list so far!

For example, with my current probe, RESET (_IORST), HALT (_HLT) and (_BERR) bus exceptions seemed to stay high (active low). This seems a good start, I think.

For Buster bus arbitration, all active low - the Bus request (_BR) seems to stay high while Bus grant (_BG) and Bus control (_BGACK) distinctly pulse during each of the chip or fast or ROM memory speed tests. Still not sure if that's correct behaviour... but Buster is sure doing something there!

[pandy71]

Originally Posted by hooverphonique

I've looked at this project before, and it looks quite impressive - did you try it out?

Not yet i must sadly admit...

[Screechstar]

The cheap oscilloscope arrived It's a Zeeweii DSO1511G and it's really not bad. Single channel, square wave generator to calibrate the probe... it's ok.

It picks up the 25Mhz clock signals well enough. It's one ugly clock signal, but it's exactly 25Mhz.

Alas, I've yet to find the slow-down issue, but I'm also limited in my understanding of how it should work so any pointers are still much appreciated

I checked around the memory a lot and can now see the memory lines and and signals seem to be where there should be. I'm not sure if they are the right signals at the right time (single channel 'scope!), but they are there. (DSACK's, STERM... SIZ's were a bit funny, some signals didn't seem to go over about 2v, but maybe that a 'scope limitation?).

DMAEN always stays high.

Bus arbitration shows BG (bus grant) is pulsing away.

One possibly odd thing jumped out at me. All the fast ram data-lines have a background 1.7v to them. Anyone know if that's normal?
The chip ram doesn't have this.

When sending data, the signal does drop to 0v and up to 4-5v, but if I remove all fast ram, the 1.7v background voltage is there and I can see it between data pulses.

The fast ram data lines are inputs to the four 74F245 chips - now one of these is a new chip I installed but it acts no differently to the other three. That voltage is above it's 0.8v low level and below its 2v high level, so I wonder if it rests in-limbo, as such.

I noticed the four GAL's / PAL's on the ram side of the daughter board are getting hot - all around 50C. I hope that's ok!

[pandy71]

Originally Posted by Screechstar

One possibly odd thing jumped out at me. All the fast ram data-lines have a background 1.7v to them. Anyone know if that's normal?
The chip ram doesn't have this.

Active termination? Didn't checked schematics but this can be explanation.

Originally Posted by Screechstar

I noticed the four GAL's / PAL's on the ram side of the daughter board are getting hot - all around 50C. I hope that's ok!

True, they can be hot, some people replacing them with modern GAL devices...

[Screechstar]

Thanks Pandy71 that's great to know hot Gal's are not unusual and you may well be right that that background fast ram voltage is part of their standard operation.

I do have a few next steps... I've been reading through the MC68030 user guide and learning more about ram signals to really see if I can spot any issue with the 8,16 & 32 bit access with the oscilloscope.

I also will have access to a spare A3630 processor card next week so that'll be interesting to check!!!!

[Screechstar]

SOLVED (partially anyway!). The new A3630 CPU board has made all the difference and speeds are back to normal! I don’t know the root cause yet with the original board but will look into that.

With the new A3630 - Sysinfo, busspeed, AIBB… all show normal stock A4000/030 speeds. I’ve only run it for 50-60 mins so far and all is stable so far. The new card has a full-fat ‘030 with MMU as a bonus.

The original A3630 had no capacitor damage and looked great, but there’s something up with the card or CPU. I will check the original CPU connectivity and if all looks good I’ll get a new QFP ‘030 to try and resurrect this board.

What a weird issue!

Thanks to everyone for all their help and suggestions! I really appreciate it, as this was such a strange problem… I’m still amazed it was fully functional, just a bit slow!

[Screechstar]

FULLY SOLVED:
So did some checking around the original A3630 card, since swapping this card with another resolved the slow speeds of the A4000. I almost instantly found the real cause for the issue…

I can’t believe I missed this, but pins 18 (Vcc) and 20 (BR) of the 68EC030 had broken solder joins and were floating. I re-flowed all the cpu pins just to make sure all were ok and everything came to life and speeds were back to where they should be for the system!

I still can’t believe I missed this! I’d even spent time checking all the custom chip pins and buster socket were soldered properly, but didn’t do that for the cpu card since it was in such good condition and because I’d done so much repair work on the board, I focussed to much on it!

Thanks again for all the help and suggestions!
I really appreciate it! Another 4000 lives!

[Kin Hell]

Originally Posted by Screechstar

FULLY SOLVED:
So did some checking around the original A3630 card, since swapping this card with another resolved the slow speeds of the A4000. I almost instantly found the real cause for the issue…

I can’t believe I missed this, but pins 18 (Vcc) and 20 (BR) of the 68EC030 had broken solder joins and were floating. I re-flowed all the cpu pins just to make sure all were ok and everything came to life and speeds were back to where they should be for the system!

I still can’t believe I missed this! I’d even spent time checking all the custom chip pins and buster socket were soldered properly, but didn’t do that for the cpu card since it was in such good condition and because I’d done so much repair work on the board, I focussed to much on it!

Thanks again for all the help and suggestions!
I really appreciate it! Another 4000 lives!

Brilliant discovery.....

I guess you can be "God dammed" in a typical English-American way then bud!

[patrik]

Great work!

[Screechstar]

Originally Posted by Kin Hell

I guess you can be "God dammed" in a typical English-American way then bud!

Haha, thanks Kin Hell… yeah, it really was a proper palm to face moment! Cheers for your help looking into this!

Originally Posted by patrik

Great work!

Thanks Patrik - the memory data and potential areas to investigate were a real help in trying to narrow the search down!

On the plus side, if anyone has a 4000 in the future with a busted BR line and part of the cpu not getting enough voltage, we know what that symptoms are!!

[nogginthenog]

BR = Bus Request. I guess because it was floating it was locking up the bus.

[pandy71]

Originally Posted by Screechstar

FULLY SOLVED:
So did some checking around the original A3630 card, since swapping this card with another resolved the slow speeds of the A4000. I almost instantly found the real cause for the issue…

I can’t believe I missed this, but pins 18 (Vcc) and 20 (BR) of the 68EC030 had broken solder joins and were floating. I re-flowed all the cpu pins just to make sure all were ok and everything came to life and speeds were back to where they should be for the system!

I still can’t believe I missed this! I’d even spent time checking all the custom chip pins and buster socket were soldered properly, but didn’t do that for the cpu card since it was in such good condition and because I’d done so much repair work on the board, I focussed to much on it!

Thanks again for all the help and suggestions!
I really appreciate it! Another 4000 lives!

Congratulations!