Defunct AKA31 (sob!)

[IanJeffray]

I've received an AKA31 SCSI card but it doesn't seem to work

The card shows up via *podules, presents its modules, I can *scsi and then *devices and then ... it just hangs.
If I let the machine boot to desktop, the desktop hangs (even with no SCSI drive configured).
I've popped the AKA35 ROM on there also - no change in behaviour.
Connecting internal/external drives doesn't change behaviour.

I think the chances of me diagnosing and fixing this right now are pretty low -- but has anyone else (steve3000?) managed to ressurect an AKA31 ?
Whilst I could start randomly replacing the 74 series chips on here, I'd probably bet that one or more of the 5 PAL/GALs has gone futt -- and whilst I do have another AKA31 I could nominally swap these over from, I'm pretty reluctant to do so in case the board itself is faulty and may kill such.
Smart ideas gratefully received.

A dead AKA31. It's tearful.

[Boydie]

Would it be safer to swap from the bad card, into the good, to see if any reproduce the fault in the good card?

ISTR these were devils for termination. Acorn used to supply both internal and external terminator packs for whichever port had nothing connected, but I expect you’ve already thought of this.

[steve3000]

Yes, I had a couple of dead AKA31s a few years ago, with slightly different symptoms and I did fix one at the time. I thought I posted about the fix, but can’t find it now. As I recall the one I fixed had similar issue to yours - it still allowed the computer to boot though to desktop and was visible in the list of podules, just wouldn’t recognise any devices and would hang on issuing *devices.

I took a punt that the static RAM might have failed, and as I had two spares of exactly the right size (32kb?) I desoldered, socketed and swapped in the new RAM. Then the AKA31 was much happier - responded to *devices and recognised my ancient 40mb SCSI drive…(although the drive later failed!)

I didn’t attempt to fix my second card at the time, so I’ll need to dig that out again to have a look at it.

[SarahWalker]

IIRC I had similar issues with my AKA31 when fuse FS1 blew.

[IanJeffray]

I took a punt that the static RAM might have failed, and as I had two spares of exactly the right size (32kb?) I desoldered, socketed and swapped in the new RAM.

Interesting punt! Replacements are cheap enough, but I was wondering about poking the SRAM directly for some testing beforehand. There's good detail in the A540/R260 service manual ... trying to get my noodle around this -- the parts are two 32KByte (256Kbit) parts. But the aperture is only 4KB in 16bits. So I believe that means I need to poke bits 0-4 of the MPR at 3343000 to select a page before reading / writing 4KB from either 3000000 or 3001000 and ignoring the top 16bits of each 32bit data word.
What I'm not clear on is the "Every 4th address" note? Is this just saying that you step 32bits at a time because of LA2=A0 ?

Probably want to kill the SCSI modules before doing this I guess, and no drive attached, etc

So this is some quick ugly crude test code I cooked up...

Code: Select all

DIM P% 1024
pod%=&3000000
[OPT 3
.write%
SWI "OS_EnterOS"
MOV 2,#pod%
STR 1,[2,0]
TSTP PC,#&f0000000
MOV 0,0
MOV PC,14
.read%
SWI "OS_EnterOS"
MOV 2,#pod%
LDR 0,[2,0]
TSTP PC,#&f0000000
MOV 0,0
MOV PC,14
]
x%=0
FOR page%=0 TO 15
 A%=&343000
 B%=page%
 CALL write%

 FOR addr%=0 TO 8188 STEP 4
  A%=addr%
  B%=x%<<16
  CALL write%
  A%=addr%
  y%=USR read%
  IF (y%>>16)<>x% PRINT addr%
  x%+=1
 NEXT

 PRINT page%
NEXT

Runs fine on my good card, but on the knackered card it prints up to 6 failed addresses per page, on every page. Maybe not precise/exhaustive, but good enough to show up a fault / difference. Does this mean it's definitely the SRAM that's fubar? I don't think so (could be latches/buffers/blah I guess - not looked deeply at the podule design). Does it seem likely is the SRAM? Well based on @steve3000's success, I'd say it's worth the 10 quid for me to get new RAMs as a first step at least! Thanks for the suggestion, steve3000

[steve3000]

Great idea to write some test code!

Is there a pattern in the failed addresses? You might be able to track down which RAM IC is at fault or if it’s something else, by desoldering and swapping the RAMs over? I had intended to test my bad RAM ICs to see which was at fault (using my TL866ii programmer)…but as the replacement worked first time, I didn’t get round to it.

[IanJeffray]

Is there a pattern in the failed addresses? You might be able to track down which RAM IC is at fault or if it’s something else, by desoldering and swapping the RAMs over?

The two RAMs are x8 and look like they must be active simultaneously to provide the 16bit data output:

The SRHI and SRLO signals are separate enables driven by the IC9 PAL - presumably only used when the SCSI controller needs to access the data (it's only got an 8bit interface and IC8 connects the upper and lower halves of the data bus together so it can access the 'high' RAM).

So if we see errors only and always in a single byte lane, that'll indicate the RAM at fault. Tweak the test code to print the data results:

Code: Select all

 IF (y%>>16)<>x% PRINT addr%,~x%,~(y%>>16),~(x% EOR (y%>>16))

The results are not consistent every time, not in a single bit position or even just in a single byte lane. Often many bits at once differ.
Example output:

Code: Select all

      3984        3E4       2E4       100
      5220       519       319       600
      5892       5C1      7EC1      7B00
      6084       5F1       5F0         1
      7456       748      7548      7200
      8048       7DC       700        DC
         0
      4844       CBB       CB8         3
      5600       D78       D10        68
      7016       EDA       ED8         2
      7652       F79       F78         1
         1
      5536      1568      7568      6000
      5584      1574      1174       400
      7528      175A      1758         2
         2
      4532      1C6D      1C6C         1
      4588      1C7B      1B7B       700
      5340      1D37      1037       D00
      5664      1D88      1C88       100
      6324      1E2D      1E00        2D
      7000      1ED6      1EC0        16
      7732      1F8D      168D       900
      7792      1F9C      1B9C       400
         3
      3256      232E      222E       100
      5088      24F8      2410        E8
      5336      2536      1F36      3A00
      7276      271B      2710         B
         4
      4728      2C9E      2C9C         2
      7316      2F25      2B25       400
      7548      2F5F        5F      2F00
         5
      4324      3439      3410        29
      5232      351C      301C       500
      6904      36BE      36BC         2
      7656      377A      3760        1A
         6
      5876      3DBD         0      3DBD
      6616      3E76      3D76       300
      7224      3F0E      3D0E       200
      7880      3FB2      3BB2       400
         7
      4936      44D2      43D2       700
      5704      4592      3E92      7B00
      5776      45A4      43A4       600
      5824      45B0      43B0       600
      5872      45BC      4500        BC
      6352      4634      3D34      7B00
      6976      46D0      4680        50
      7032      46DE      44DE       200
      7952      47C4      44C4       300
         8
      4688      4C94      4C80        14
         9
      5960      55D2      54D2       100
        10
      4716      5C9B      5B9B       700
      5492      5D5D      5D58         5
      6360      5E36      5736       900
      7080      5EEA      56EA       800
      7892      5FB5      5BB5       400
        11
      4724      649D      649C         1
      5496      655E      655C         2
      6004      65DD      65DC         1
      7324      6727      6627       100
      7848      67AA      62AA       500
      8172      67FB         0      67FB
        12
      4660      6C8D      5E8D      3200
      6096      6DF4      6DE0        14
      6756      6E99      6E98         1
      7736      6F8E      6F80         E
        13
      4680      7492      5E92      2A00
      5464      7556      6656      1300
      5672      758A      738A       600
      6324      762D      702D       600
      6980      76D1      76C0        11
      7596      776B      7760         B
      7768      7796      7496       300
        14
      7040      7EE0      65E0      1B00
      7088      7EEC      7BEC       500
      7800      7F9E      7E9E       100
        15

I think it's still possible that the address or data buffers could be dozy here. It's possible that IC8 latch is dozy. I thought about reading the ROM back, but actually we know that's all good as RISC OS sees it just fine -- it's driven somewhat differently too though.

Yes, this is an extremely shoddy and lightweight memory test, so I don't think it's worth trying to draw too many conclusions directly from these results. We'll see what happens when the slow boat from China arrives with the new RAMs!

[IanJeffray]

New (older!) SRAMs have arrived...

...new sockets added and new chips in place:

Essentially the same results though! Well that was a complete waste of time then.

[steve3000]

Essentially the same results though! Well that was a complete waste of time then.

That's disappointing Any change in results from your test code?

Between Sarah's, yours and mine, it seems these cards have multiple different failures.

I do have a second failed AKA31 in a box somewhere, will try to locate that for a comparison.

[sirbod]

Have you checked the 74's? I recall one of my machines had a malfunctioning gate on a 74.

You probably need a donor card so you can systematically swap components until you find the problem if there's custom logic involved.

[IanJeffray]

Have you checked the 74's? I recall one of my machines had a malfunctioning gate on a 74.

You probably need a donor card so you can systematically swap components until you find the problem if there's custom logic involved.

That's my next plan - replace the latches to start with. Not swapping from a 2nd card, just putting fresh parts in; they're cheap enough.

[gazzaD]

I had pretty much the same symptoms when messing about with different device configurations and unintentially ending up with a the SCSI bus was not terminated correctly. Including the machine not booting to desktop if only the card was was plugged in without the termination pack on the external connector.

As mentioned earlier, there is a fuse on the card which can blow. I also has the same symptoms when it blew as it provides termination power to the bus. Thankfully I was using an active terminator with a power LED, so it was obvious when the termination power had failed.

[IanJeffray]

I had pretty much the same symptoms when messing about with different device configurations and unintentially ending up with a the SCSI bus was not terminated correctly. Including the machine not booting to desktop if only the card was was plugged in without the termination pack on the external connector.

As mentioned earlier, there is a fuse on the card which can blow. I also has the same symptoms when it blew as it provides termination power to the bus. Thankfully I was using an active terminator with a power LED, so it was obvious when the termination power had failed.

I think we need to be careful conflating general issues and behaviour with specific investigations and causes.
There's really no way the flaky SRAM behaviour I'm seeing here can possibly be caused by SCSI termination issues, and the fuse is definitely out of the question (and is fine anyway).

[IanJeffray]

That's my next plan - replace the latches to start with. Not swapping from a 2nd card, just putting fresh parts in; they're cheap enough.

Swapped a couple of the 245s - IC2 and IC6. That's enough to make the SRAM test pass now. But *devices still hangs.
EDIT: Replaced the other 245s also - IC4 and IC8. No difference. Hohum.
EDIT2: Found that I had a 273 in hand, so, though the EPROM was working fine (via the 273) I swapped it anyway. No difference.

I guess maybe I need to do the thing I'm most scared to do... try swapping over the PALs from a good card. (Scared because I don't want to damage a good card...)

[IanJeffray]

I guess maybe I need to do the thing I'm most scared to do... try swapping over the PALs from a good card. (Scared because I don't want to damage a good card...)

I put my big boy pants on and did that...
It appeared that it was PAL 0273,216-01 that's dead / malfunctioning. That's IC9, which according to the Service Manual does "all the address decoding". Humpfh. Pulling that PAL from a good card and putting it on this board makes *devices return a decent list, at any rate.

But after some further power-cycles - nope! What?

Ok, really sticking my neck out ... put ALL the PALs from the bad card on the good card ... good card still works just fine. (PHEW!!!)
Put ALL the PALs from the good card on the bad card ... still doesn't work.
Swap ALL the PALs over - good card still good, bad card still bad. Ok fair enough.

So the PALs themselves are possibly ok. Great! But why did I get two runs where just swapping IC9 seemed to fix things? Hmmm.
I can't repeat my initial apparent success - that's shoddy, and very annoying. Now I'm beginning to doubt myself.

There's some slight corrosion on a few DIP contacts, but cleaning those didn't change anything.
Then I thought about the same on the two PLCC parts that are on the board - sure enough, some of the sockets contacts look a bit shoddy, but after a good clean of all contacts and pads on the PLCCs, no change in behaviour (Not surprised about that, but still thought anything worth trying!)

I replaced the 100uF cap with something new. Nothing wrong with the old one (still measured 98uF) but another simple "may as well" task.
I've tried running with different SCSI external and internal terminators, cables, drive configurations etc "just because" - no changes.

[sirbod]

It's has to be a bad connection somewhere, dry joint or high resistance on a VIA perhaps? Sounds like you need to systematically reflow the board and check every trace....fun times!

[IanJeffray]

It's has to be a bad connection somewhere, dry joint or high resistance on a VIA perhaps? Sounds like you need to systematically reflow the board and check every trace....fun times!

Yeah, it's possible. There's no board corrosion though. I've noticed that the SRAM tests are failing again - always in the upper byte now. There are still a few 74 chips that I've not replaced yet (more 'exotic' parts).

[sirbod]

Yeah, it's possible. There's no board corrosion though. I've noticed that the SRAM tests are failing again - always in the upper byte now. There are still a few 74 chips that I've not replaced yet (more 'exotic' parts).

You've probably already thought of this, but you could desolder all the chips on both cards and socket them so you can swap all of them. That would at least rule out the chips, leaving the SMD, traces and VIAs.

As this sounds like a common issue, we probably want a sticky thread once you've found the root cause. With any luck its the same issue on the other two cards mentioned in this thread.

[IanJeffray]

You've probably already thought of this, but you could desolder all the chips on both cards and socket them so you can swap all of them. That would at least rule out the chips, leaving the SMD, traces and VIAs.

That's a rather dramatic suggestion. But actually, I'm as good as there already - all the PALs have been swapped over, the PLCCs are socketed, EPROM is socketed, SRAM has already been replaced (and now socketed), six of the 74 chips have been replaced by new parts -- I think that only leaves three parts yet to replace - and I'm still far more inclined to drop fresh silicon on the board than start hacking apart a perfectly functional board.

I'm also inclined to replace the PLCC sockets actually, because there is (was) quite a number of corroded pins - I believe I've cleaned them all up acceptably, and everything buzzes out, but it's still a ponderable.

Some random poking yesterday showed that the terminator power supply diode is no longer a diode - it's reading below 1KR in either direction. I got what I thought was a suitable replacement but it's a physically enormous part - I'm terrible at speccing physically compatible equivalents for things. I started looking in to this due to others repeatedly saying fuse/terminators caused the hang, and whilst I'm really not of the belief that's what's wrong here at all (SRAM fails can't be caused by poor termination) I did test two other AKA31s and they both reliably produce results from *devices irrespective of whether there's a cable / terminator / anything connected -- and if there's nothing connected, the fuse is running thin air, so it's irrelevant.