3lectr1cPPC
Well-known member
My 180c should rest easy then
thank you for the work you do on this as well as the portable hybrid project!
-
Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.
Slow SPI (Half Speed) BlueSCSI DB25
- Thread starter 68kPlus
- Start date
thank you for the work you do on this as well as the portable hybrid project!
cheesestraws
Well-known member
CircuitBored
Well-known member
Consider your wait over. I had a pair of them in two separate SE/30s, installed on the same day and used for the same amount of time over a two month period.
One morning I powered the two machines up and poof! BlueSCSI down. The thing is entirely dead. It cannot be powered up and cannot be reflashed. Therefore, it is beyond saving. I promptly put it in the bin and bought a better SD-based SCSI device.
With its dyed-in-the-wool reliability issues and generally underwhelming compatibility (completely unusable on my Quadra 650, for instance) I have just about all the ammunition I need to justify not wasting any more money on BlueSCSI. It is interesting that there are some variants emerging with solutions to the issues highlighted by @cheesestraws, however.
erichelgeson
Well-known member
If you still had it I'd like to get my hands on it to diagnose the failure (send me a DM if you do). There are other components on there - maybe as simple as the LDO failed. I'm not saying things never fail - I'm saying that this issue being discussed hasn't been the root cause.
Yes they've been out for quite a while - and I've talked to you about them. There are many boards and forks, check them out!
You may know "pull-up" as active termination. Two of the five regulators on MacSD are for this purpose. Here's more about FPT and termination in general.
Signal integrity doesn't care about user experience. This is one way to eliminate removable nets:
Then my comments apply equally to RaSCSI: It shouldn't be used mid-chain either. Cloning open source designs is not without risk.
I'm not concerned with your board's driver strength or longevity. However, your users should be aware that BlueSCSI termination is never "off". Therefore, in multi-device buses, BlueSCSI belongs at the end of the chain and other devices should have their termination disabled. Documenting this in your manual would reduce "SCSI voodoo" and headaches for everyone involved. Do you plan to do this?
3lectr1cPPC
Well-known member
I do own a RaSCSI, what procedure should I take in this case when using it with my 180c with an F4Lite BlueSCSI in it? This would be with just the internal BlueSCSI and external RaSCSI connected. I have had some inconsistent issues with the BlueSCSI not working sometimes when the RaSCSI was connected, although those cleared up when I changed power adapters for the PowerBook.
It sounds like it may have more to do with termination power rather than actual termination, but @androda could probably give you a better answer.
@erichelgeson
The conversation we had about termination took place nearly three months ago. What have you done since then to let your users know about the problem?
androda
Well-known member
I actually don't have a RaSCSI, and might not be able to help very much. PowerBooks don't provide termination power to the external SCSI bus, so the RaSCSI has to be powered by a USB cable in this scenario to my understanding.
It's a little unclear why changing the power adapter for the powerbook could help. Maybe termination power (for the internal BlueSCSI) was running too low for the system to be totally happy when talking externally and the new adapter shored things up.
3lectr1cPPC
Well-known member
May have been a coincidence but the first adapter was an aftermarket 2A (the 180c needs 3A) that I was overdriving. It did boot the system but my OEM 3A is better suited
chiptripper
Well-known member
I have seen the BlueSCSI reliability argument (and inevitable @erichelgeson pile-on) play out several times and it's getting tedious.
Frankly, most BlueSCSIs use a knockoff bluepill to begin with so I never assume they're going to be ultra reliable. They're an affordable option to replace failing HDDs and for that reason they're useful.
I have not lost a single BlueSCSI to this point (though I had a knockoff bluepill fail as I was flashing it), but if I ever do have one fail, I will just pop the SD card out and build another. That's my attitude and I think it's fine?
Frankly, most BlueSCSIs use a knockoff bluepill to begin with so I never assume they're going to be ultra reliable. They're an affordable option to replace failing HDDs and for that reason they're useful.
I have not lost a single BlueSCSI to this point (though I had a knockoff bluepill fail as I was flashing it), but if I ever do have one fail, I will just pop the SD card out and build another. That's my attitude and I think it's fine?
cheesestraws
Well-known member
Then don't participate in it.
If you have data contribute it. If you do not have data, do not.
I deliberately cite standards and datasheets because these are not marketing materials and they allow my conclusions to be verified independently of my own opinions.
The original BlueSCSI design is defective hardware, per the standards, and the BlueSCSI peddlers are knowingly selling defective hardware as good.
If you have data contribute it. If you do not have data, do not.
I deliberately cite standards and datasheets because these are not marketing materials and they allow my conclusions to be verified independently of my own opinions.
The original BlueSCSI design is defective hardware, per the standards, and the BlueSCSI peddlers are knowingly selling defective hardware as good.
Skate323k137
Well-known member
I'm actually pleased to see discourse with datasheets etc., as opposed to generic statements, and I hope this can stay civil and result hopefully in improvements to the BlueSCSI.
chiptripper
Well-known member
I can't help but participate when every other BlueSCSI thread (a project I'm interested in) is hijacked in this way. I've seen the discourse with datasheets at least three times now, the issue is well understood. Frankly, I could say the same thing to you: don't participate in it.
As for your frustration with Eric's responses, bear in mind your own. In this thread alone you suggest he should be ashamed of his work, call him insecure and a cult leader, and
Don't view this as a personal attack, I like you. But yeah it's tedious.
As for your frustration with Eric's responses, bear in mind your own. In this thread alone you suggest he should be ashamed of his work, call him insecure and a cult leader, and
Don't view this as a personal attack, I like you. But yeah it's tedious.
You're free to take that risk, but the termination issue is not fine.
pfuentes69
Well-known member
There's a huge number of users that just want a single device in their Macs and don't care about termination.
The good thing here is to have different solutions for different needs, and for different budgets... There's people (like me) that just enjoy more building themselves a BlueSCSI or RASCSI and using what they built, instead of just purchasing a finished device. I made for myself several and my only issues where with a couple of bad bluepills.
The bad thing is to have to see here so many personal issues and hate messages that aren't positive in a hobbyists forum...
The good thing here is to have different solutions for different needs, and for different budgets... There's people (like me) that just enjoy more building themselves a BlueSCSI or RASCSI and using what they built, instead of just purchasing a finished device. I made for myself several and my only issues where with a couple of bad bluepills.
The bad thing is to have to see here so many personal issues and hate messages that aren't positive in a hobbyists forum...
Then the correct thing to do would be to document the limitations of the hardware so that users aren't risking their data, wasting their time and casting blame where it doesn't belong.
chiptripper
Well-known member
I think it's reasonable to expect that they update the BlueSCSI documentation to reflect that limitation, sure.
But yeah agreed. I have no time for personal vendetta stuff.
Maybe there should be a pinned BlueSCSI thread that outlines hardware concerns and limitations.
pfuentes69
Well-known member
Yes, I totally agree that every xxxSCSI alternative deserves independent and unbiased reviews, exposing pros and cons.
This information belongs in the manual of the product. Still waiting to hear if @erichelgeson will put it there.
If anyone would like to defend hanging a resistor net off the middle of the bus, I welcome all debate.
It's always a bummer how these threads go. A thing I have to remind myself a lot is "what am I adding, how am I helping?" and I think several of us lost sight of that here.
That said, I do think we also need to be mindful of context when we bring this these kinds of things up. People who have been around for a long time will remember "security patches" and perhaps more recently "iomega zip" -- poor examples for me to set, I'm aware.
This thread may not be the venue for it, whether that means the venue is "github" or the venue is a new thread in, say, hacks/dev, but it does appear the technical criticisms have been substantiated and should be looked into.
That said, I do think we also need to be mindful of context when we bring this these kinds of things up. People who have been around for a long time will remember "security patches" and perhaps more recently "iomega zip" -- poor examples for me to set, I'm aware.
This thread may not be the venue for it, whether that means the venue is "github" or the venue is a new thread in, say, hacks/dev, but it does appear the technical criticisms have been substantiated and should be looked into.
