Slow A4000 after overhaul

[Kin Hell]

Originally Posted by Boing-Ball

80ns Chip and 70ns RAM

For a start the speed rating for the Chip = Not good! Ideally you should try 60NS.

Fast RAM 70NS EDO. Again try 60NS FPM. I’m guessing the system could be compensating for the lowest denomination of 80NS.. therefore possibly the slow speeds.

EDO will also mean 36-bit Data checking which can mean slow down compared with Fast Page Memory.

Won’t know until you try.

@ OP

Don't even bother trying. The difference between 60, 70 & 80ns is negligible & will not trash your CPU & System performance to the extent yours is showing. 60ns just refreshes faster than 70 or 80 & that is all.

Can you post a clear picture of the A3630 card please?

[Screechstar]

Thanks for all the help and suggestions… I appreciate it a lot!

So, checked continuity of the resistors and power lines for /DSACK0, /DSACK1 and /STERM and the resistor values and yeah, these are all good.

That’s great to know the ‘16’ designated bustest results don’t apply to the 68030, thanks for that

I’ll run some benchmarks in Sysspeed and bustest tomorrow to see if they repeat the Sysinfo trend of slowing down within the same session after repeated speed tests. I’ll test with a minimal system too. It was fairly stark as the board isn’t in the case yet, but I’ve removed the FPU too now.

I have replaced U891 F245 buffer chip as that got splatted by some electrolyte. I did wonder if one of the other 3 may have gone wrong as I do have 2 spare new chips… might think about that. Anyway, I’ve traced them all and the connections are good.

I’ll keep checking via’s in what was the acid / electrolyte zone… but if one was broken I would have thought that would just cause corruption or an error rather than a slowdown? Are there any other lines like DSACK and STERM though that impact memory or CPU bandwidth or speed?

I’ve attached an image of the A3630 card too… note, those capacitors are 22uF and not 220! The manufacturer used three figures no matter what which always freaks me out for a second!

I think there are some better equipped people than in my local area that *may be able to test these things at a logic or oscilloscope level as I don't have the equipment or expertise for that - I met some at Amiga Ireland this year… it may be a case of getting some more detailed testing, if they’d be accommodating... or open to a beer or chocolate bribe, haha!

[pandy71]

Perhaps stupid question but did you eliminated for 100% that this is not software issue? disconnected HDD and booted A for testing from clean floppy?

[Screechstar]

I've just run some Sysspeed & Bustest memory tests... the results are... varied.
I ran two test runs back-to-back after a fresh power cycle.

Sysspeed spots quite a slow down in FAST ram speed which maybe backs up the SysInfo results I get (slowing with multiple speed tests in the same session).
ROM & Cache speed are all over the place between the runs but CHIP speed is pretty consistent.

Bustest has slightly different ideas. FAST ram arguably is most slowed but CHIP ram also slows and now the ROM is pretty steady.

Patrik - your comment about bus size looking halved got me researching...
The doc linked below also mentions SIZ0 and SIZ1 signals. As far as I can tell, these signals should be generated by the 030 and go to Ramsey (and buster etc.) and define bus size, if I understand correctly... I'll check these lines and their power / pull-up resistors too.

I'm not sure that SIZ0 and SIZ1 would explain the variability of the RAM speeds but is something to eliminate from the pool of potential issues.

The other consideration to keep in mind is the CF HD speed also seems very low <1mb/s.
Perhaps the Sysinfo test may be writing data from RAM and reading it back to RAM but the current CF HD speed I get is no where near the fastram speed limits so perhaps it is more of universal issue to the whole board.

https://amiga.net.au/files/Tech_Amig..._v1.11_ocr.pdf

And yes Pandy71 - it's a good point to raise but I have duplicated the results with just a floppy connected.
These tests were with a pretty minimal system too... motherboard + processor, 2mb FPM chip & 8mb fast & the CF HD.

[Screechstar]

Haha... I was just looking for the Ramsey schematic and Google found it on your website Patrik!
I'm not sure if this is necessary but I'll check the Ramsey /RSPEED lines too, just in case RAMSEY thinks it's in a 16MHz system rather than 25MHz, as controlled by this signal.

[patrik]

Haha, cheers . Unfortunately, that would actually make it faster as it cuts a fastram waitstate at the 16MHz setting. It’s a bit like the software controlled skipramsey feature, but hardware set and works with ramsey 4 in A3000.

Good to double check, but +-1 fastram waitstate would not account for half the expected speed at 32-bit read/writes to fast, rom and chip (there were some exceptions to that with chip, right?).

[hooverphonique]

Originally Posted by Screechstar

I'm not sure if this is necessary but I'll check the Ramsey /RSPEED lines too, just in case RAMSEY thinks it's in a 16MHz system rather than 25MHz, as controlled by this signal.

I would think Ramsey would insert fewer waitstates in that case, thus making ram access "faster" (until you hit the chip latency limit).

[thebajaguy]

68EC030 - means no MMU, so the cache control (allowed/denied) of various 16MB address chunks is limited to the TTx register settings.

Does the data cache turned on or off make a difference when you do BusTest to FastRAM? If no, then your TTx register setting is marking FastRAM as non-cache.

I'm not sure if MuLibs is installed, but if it is, then I believe it will set the TTx registers to enable cache against motherboard FastRAM. By the nature of the TTx register address granularity, all of the lower 16MB, inclucing ChipRAM, gets natively marked as nocache as the shared access ChipRAM and I/O devices on the motherboard require nocache.

[Screechstar]

So a little update
/SIZ0 /SIZ1 (and /RSPEED haha!) all have continuity, power connections and pull up resistors are good.

I am using a WB3.0 build with Mulibs at the moment but the same thing happens with a stock 3.0 floppy or full-on WB3.1 build.

BusTest with datacache disabled only actually slows one result - FASTreadw. It just about halves. All others are the same! Darn it… I had run this test but missed the detail between all the chip and ROM results too (I do have tonsillitis and a temperature above 38.5C (101.3F) so hope I can be forgiven!

So is this not normal - is cache for readw only? And if not, anyone know which chip do I need to give a stern talking to with a soldering iron?

See the attached pic. Enabled data cache on top, no data cache on the bottom.

… to give myself a cheap thrill of actually fixing something, I did just repair the single key on the keyboard that wouldn’t work. It was the @ key so thankfully, I was not planning on sending emails!

[Screechstar]

And sorry - forgot to ask... what are the 'w', 'l' & 'm' read / write modes in the test? Sorry, I should have asked!!

… oh, forgot to say I had the classic slow down I mentioned within the same Sysinfo session again…
Freshly booted and it gave me 2800 Dhry. Not good but ok… pressed the button a few more times and got 2660, then 2500, 2200, 2000, 1900.

Sometimes on fresh boot it just goes straight to 1900 sysinfo Dhrystones. Very curious.

[patrik]

.w is read/write using the move.w instruction (word) which does 16-bit accesses
.l is read/write using the move.l instruction (longword) which does 32-bit accesses
.m is read/write using the move.m instruction (multiple longword) which does many 32-bit accesses, how many depends on the code, the bustest docs would say

In general if you had no data cache/data cache disabled and a 32-bit bus, .w would this always be approx half the speed of .l as it then needs to do double number of bus accesses for same amount of data and .m might be a bit faster than .l if the bus is quite fast and the cpu is not able to execute enough .l to saturate the bus as it is easier to saturate the bus with move.m as there will be fewer instructions to execute for same amount of data to transfer.

[giantclam]

Looks suspiciously like a heat related problem ~ boot machine, wait for the go slow, start spraying each IC in turn with instant cooling spray, hope the cold flushes out a culprit =)

[Screechstar]

Thanks for the memory info Patrik that makes everything a lot more clear now how that works.
I just ran Bustest on my '030 A1200 too as a comparison and saw a similar fast ram speed trend - that ram speed reduces for fast readw only when data cache is disabled.

Heat could be an issue for sure... the weirdness is though that I've never had a the machine running at full speed ever, even from cold boot.

I just bought a basic logic probe, so will plan to start testing around parts of the circuit to see if there is anything within the memory buffers, bus-size lines and timing circuitry that seems particularly unusual (I'm not so experienced with what's normal but should be able to spot if something is unusually held high/low).
After that a borrowed oscilloscope may be needed for sure.

Whatever is the cause, it seems to impact across the whole memory/HD/CPU/FPU system, which is what made me think memory or CPU clock signals may be the issue?


I thought a quick summary may be useful (for me mainly ) as there's a lot going on here;

- Sysinfo & AIBB system speed is normally about ~50% of a 'normal' A4000
- ... but very OCCASIONALLY Sysinfo can be only ~25% slower after a power/reset cycle but then slows down with back-to-back tests to the 50% 'normal speed' result it typically shows.
- Sysinfo & AIBB FPU speed is also reduced by ~30%, but will follow the same 'slowing' trend as per the system speed.
- Sysinfo 'Chipspeed vs A600' is also reduced by about 50% and will follow the same 'slowing' system speed trend.
- Bustest Fast, Chip & ROM memory speeds are variable but typically about 50% lower than a typical A4000 and Sysspeed memory speed results demonstrate the same 'slowing effect with back to back tests IF the system is running faster again after a power cycle/reset.
- Memory speeds do respond if data cache is disabled (Fastram readw slows)
- HD (or rather CF card) access is about 50% or a normal A4000 at <1mb/s.
- The system is stable. I can play some demos & games & utilities for over an hour with no crashes or glitches.
- Various FPM and EDO memory sticks in chip & fast ram produce the same results.
- Amigatestkit and Diagrom all appear to show everything works (memory tests good, CIA timing, audio and video test good, HD and floppy work great)

... on the plus side, it does 'work'!

[pandy71]

Originally Posted by giantclam

Looks suspiciously like a heat related problem ~ boot machine, wait for the go slow, start spraying each IC in turn with instant cooling spray, hope the cold flushes out a culprit =)

Valid point but for modern IC's - in Amiga times there was no thermal management and clock throttling - in Amiga it works till thermal runout then it hangs or begin to be unstable and as such Guru...

[pandy71]

Originally Posted by Screechstar

... on the plus side, it does 'work'!

But it works like maximum wait states active - is there any timeout in Amiga for operation (like it end after maximum 8 WS) - don't have datasheets for A3000 bus IC's...

[Screechstar]

It's a good point about the timeout - I've been trying to read the Ramsey and 68030 manual but not quite sure about what it all means just yet!


I've used my logic probe a bit while running sysspeed memory tests and... well, maybe there's an issue, but my probe can only see up to 20MHz so I can't properly see clocks or small cycle flips, but...


- /DSACK0, /DSACK1 signals are active low - I can only see that they are high. Their pulses are smaller than some of the others in the memory cycle, so maybe my probe can't see them pulsing but I can only see a high signal.
- /STERM I can also only see as high (active low)
- /SIZ1 & /SIZ0 signals are pulsing and indicate the number of bytes to be transferred in a cycle so that's working
- /DMAEN (DMA enable) active low but I can only see this as high. Not sure if that's good or not really.

The 4x F245 memory buffers are all acting normally at least - pulsing on pins where they should.

Maybe it is these memory cycle signals getting lost and the system is timing out as such... or my logic probe is a bit rubbish!

[giantclam]

Originally Posted by pandy71

Valid point but for modern IC's - in Amiga times there was no thermal management and clock throttling - in Amiga it works till thermal runout then it hangs or begin to be unstable and as such Guru...

True, but I'm not purely focused on IC internals coming forward with my suggestion ~ I'm thinking more circumspect ..ie; when you hear hooves, think horses not zebras =)


Rationale: mainboard has been overhauled/repaired due to board level chemical damage...this is physical. As you point out, it is a valid observation ..given what's presented here...to hypothesize the heat may be participle to the fault situation ..ie; reading this thread, in my head I say "the problem seems to get worse, from cold temp startup as it runs and continues to heat up"...this too, is physical.


Then I posit to myself, how might it be a DMM/logic probe of the board, results in all board traces checking out OK .. when I'm hypothesizing heat is somehow involved? Well, that's easy ~ shot myself in the foot many times over the decades with these kinds of faults --- what one tends to overlook, is the pressure of the probe application is actually physically fixing the problem...


...the typical synopsis is there's a crack in the physical electrical path. On the Amiga boards, the worst of these was a cracked/eroded PCB 'via' ... this sort of damage is really surreptitious -- just the mainboard heating up, will cause expansion enough to pull these cracks further apart. In some many cases, these don't just go open circuit, but rather turn into a little R/C circuit in series with that datapath. Weird stuff happens when you apply frequency, something you'll only see with an oscilloscope, and that a DMM or logic probe will never tell you about =)


As said, I've been here before...runs good cold, glitches when it comes up to temp, and the first thing I think of to myself is "what have I missed during the rework?" ...ie; what part of the repair that needed physical reworking (resoldering, jumping) did I miss?", and call myself lucky that I'm at least left with a 'tailtale' of heat having something to do with it...



....I then throw Occam's razor into the mix ...ie; it's going to heat up and go silly of it's own accord, so all I have to do is cool down the silly thing while it's running, so grab my can of freeze spray and do just that, presuming a starting point to be around the original areas of chemical damage I initially had to rework to get it running in the first place =)


The via routing can easy catch you out, likewise on older boards, cracks/erosion in tracks connecting thru-hole IC sockets and other solder joints can trip you out (the corrosive chemical can ingress at the mask/solder edge) ...but whatever -- to myself and considering it's cheap/easy, it's as much an exercise towards determining whether or not heat has anything to do with it, as much as it might be a good diagnostic method towards finding the actual cause of the problem itself.

[Screechstar]

A bad via is still an option… I found 2 broken vias in the corrosion zone and there could be more.
I’ve been trying to understand the memory cycles and what drives certain signals since I’m struggling to detect with a logic probe any of the /DSACK and /STERM signals, which could totally be a limitation of my probe, rather than an actual absence of the signal, but I can’t rule it out yet that these signals are not working.

I’m wondering if another ‘bad’ signal (bad via etc.) could be interfering with these signals or another part of the memory access cycle (DMA / other bus interference from another chip?). I’ll do some more probing now I’ve a few more thoughts on this. It’s just funny that all memory and Rom (16 & 32 bit) is affected to some degree at all times.

… 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!

[giantclam]

I was just looking at the images you provided...

....could just be me, but this socket/IC fitment looks very dodgy... me, I'd be replacing that PLCC socket

[Screechstar]

What are you thinking - bad connections from the socket to buster?
I have removed buster, checked the socket and used some contact cleaner on it.
It looks ok close up - in that the socket appears to make good contact to the chip… but looks can be deceiving.
A few of the smaller chips had some corrosion to the legs next to buster but I was really happy to see the socket appeared really clean with shiny solder underneath.
I’ll check busters signals once the oscilloscope arrives. I’d love it if it was just the socket though as I’m worried a custom chip or gal chip is the culprit which is a bit more complex.