The long-awaited dyan drive crate! I remember once replacing a couple of the failed SCSI Seagate drives, with spares that had been sent to us from Quantel. One of the replacement drives had its main 12-volt and 5-volt capacitors installed backwards. I replaced the drives, restarted everything, and made sure the RAID rebuild process had begun correctly. I then left for lunch, and returned an hour later, to see the entire equipment room filled with smoke from the failed caps! Of course, the entire system had now crashed, and the rebuild process had failed as well. I ended up talking with CS tech support for the rest of the afternoon so that the data could be recovered. That made for an interesting couple of days!

"Spinning up the Dylan drives" was a thing back in 1993. :)

If you're willing to hack the PCB, what you could do is effectively swap two SCSI controllers by cutting the CS PCB trace to them and adding a bodge wire to cross-connect them. (So e.g. route CS for chip1 to the CS pin for chip 12 and vice versa.) If the problem switches along with it, it's on the side of the SCSI controller; if it's on the side of the common control logic, the problem will stay the same. Edit: Ah, you said below you managed to do the same by swapping the 'wings' cards. That would accomplish the same. On a more software-wise approach, perhaps it's an option to grab the Transputer firmware from the HAL, disassemble it to figure out how it talks to the SCSI controllers, then write a custom payload that allows you to poke those chips manually? Combined with a scope to see what the actual signals look like if the Transputer 'orders' them, it may give a wealth of insight.

Would it be remotly possible to get the designs to an interview, so they can maybe tell a view story designing such beasts. Just would be unbelivable!

The way it distributes the Thunk could get a bit confusing, but it does make sense. It's great you are in touch with the designers. It's also a shame you can't get Dylan running.

I think there were some ISDN modem cards for the German telephone network that were using Transputer chips - IIRC old cards were quite popular for playing with the chip, as you could upload your own firmware.

Fantastic stuff Mark! When you said to grab a brew and settle down, I was already one step ahead of you :) It'd be a bit of a pain (and probably too late now), but you could try swapping out chip 12 for chip 11 to see where it stops.

I have six pieces of Peak test gear and I've never regretted buying any of them plus it's a bonus buying British. No I've no connection, I believe in credit where its due.

I hope it‘s not an issue with one of the cpld‘s. I guess if the addressing is splitted over four chips as there were no big enough ones it might be that drive 0 to 12 are receiving their cs from one cpld as the remaining chip selects come from another one… might be interesting to trace the cs lines to verify this theory… as the cpld‘s are socketed it wouldn‘t be too hard… Can you attach a logic analyser to the data bus on the transputer? Even without actual code the steps configuring the 20 scsi controllers should look quite repetitove, also with the stuff written to the cplds for choosing the proper cs lines. Perhaps this gives some insight to when and why it stops executing, perhaps it just waits for an ack that never comes

I'm guessing that no other Dyan drive crates to compare with are available? can you swap around the CPLDs so they feed different SCSI controller CS locations? I'm guessing you have already checked the traces from the CPLDs to the SCSI control CS pins for continuity

My memory is fuzzy but it seems to me that the Dylan only worked with the Ramcorder, not the image library. Not sure if that is relevant to your issue here.

If anyone living in Oregon looking PCBs what about Osh Park PCB Fabrication Plant.

Just to clarify - is it that there's an absence of the chip select signal, or is it not being pulled low? As for dumb ideas, has the connecting cable been continuity tested to ensure proper connectivity with the HAL? Since you mentioned replacing some of the surface-mount caps, did you see any electrolyte damage in that area?

Very interesting video. A couple of ideas on what you could still try (but I'm sure these have all been suggested to you before) a) When you disconnect the drive+cable from chip #12 does it still fail? b) It could still be bad memory (maybe only the part of the memory responsible for chip #12 is bad). ZIP memory was very fragile and sensitive, I have seen lots of bad chips on the Amiga (ZIP memory was used extensively there). You can test the memory with e.g. the RetroChipTester Pro but you'd have to unsolder them all c) what's the connector PL4 for? Maybe there's some serial debugging port or something similar on there? d) What happens when you disconnect the whole "upper" daughter PCB from the main PCB? Maybe the system will boot further with a reduced number of disks available? (I have no idea if there were units sold that had less than 20 drives, but even if it later errors out, it might be worth trying) e) any other of these diagnostic commands could be helpful? INISYS, COMMS, FIFOS, ...? f) have you dumped the code and analyzed what it does? That might lead to some clues. The instruction set of these transputers is reasonably well-documented, even if not a lot of tooling seems to exist...

Desolder all the ram and test It’s the only thing I can think of

se podra emular el programa de quantel hal en tu pc con tarjeta grafica, me encantaria probar el programa :(

Love this series :) Did you try swapping disks / controllers to see if the problem also moved? e.g swap disk 12 with disk 2 etc

Can you use 4x 5TiB SSDs as I think you can get a SCSI LVD RAID adapter.