UPDATE Feb 28, 2024: The latest firmware for the BlueSCSI fixes all of the issue I experienced! I broke out the troublesome drives and they work, all of them! Also, the LED issue and USB COM port issues are resolved too. Everything is fixed, so please give trhis awesome feature out a try but please update your firmware first.
Thanks for testing all these drives with BlueSCSI! We've only tested with a few drives so I really appreciate you gathering detailed bug reports. We'll have a beta release this weekend for everyone else who wants to try this out can avoid some of these issues (and report new ones :) )
Adrian (replying at 20:15) it doesn't surprise me that there are errors as you were picking up the drive and waving it around. I was always taught that you never ever move a drive while spinning even if you don't think it's active. Modern drives do seem more forgiving, probably because they often have inbuilt accelerometers to park heads when motion is too much, but the 1980s ones definitely didn't have those!
When I used to work on Macs, any SCSI drive that was having problems reading, including booting up, I always waved around to get the platters spinning, and then immediately backed them up. It almost always spins them up if they have bad bearings.
I LOOOOOVE that you're keeping and forwrding the log files and images for the developpers. It's so cool when youtubers actually PARNER with people, and be real community members instead of just grandstanders. Cheers!
yep, by the time those power bricks came out, HDDs had lower power requirements (watts) than the older drives. on my power brick like that one, which came with a cheap HDD to USB adapter, the AC cable didnt have the best connection to it. replacing the AC cable made it more reliable.
This ^ and what others here pointed out. I can't tell you how many times the guy who handled the inventory at an old computer shop would order the external HDD adapter over and over again simply because the USB HDD adapters were good, but those A/C adapters they provide are JUNK! I no longer trust those bricks and ALWAYS use a dedicated AT or ATX power supply when using them to eliminate any possible power fluctuations. I hate to say it, but don't rely on those A/C adapter power supplies they include or you're just asking for a bad time.
A thought; you may have already tried it, but maybe worth retesting the drives that failed with that ATX power supply. Just incase the drives drag one of the rails down enough to crash the pico and stop it logging anything. A spin-up-related drain on the 12v could affect the 5v and in turn the 3.3V powering the pico. A really curious individual might stick a scope on 5V to watch for dips or ripple.
I can see this being very good for the music industry backing up their many thousands of hard drives with original recordings after they switched from tape to computers.
The problem with the log file "just ending" is usually caused by buffering during write. Especially with solid state storage, one doesn't want to "just keep writing", and for magnetic media it was faster with a buffer. i.e. the "print line" that logs something is translated into bytes for the file, and added to the output buffer. If that buffer is full, it will be flushed to the file. Note that the buffer is in bytes, the lines are arbitrary, so the file will grow in blocks - e.g. 4kb - not lines. What most developers forget, is to issue a "flush" command at the end of the proccss, especially when something fails. Sometimes the file even gets closed before the buffer can be flushed... lots of possibilities :)
SCSI Zip drives are often problematic when they are the only device besides the initiator. They do not provide any termination power, and rely on it being present on the SCSI bus. They only switch the resistors on or off the bus. You need to have another device in the chain that adds term power. Initiators will usually see/identify the Zip, but be unable to do any data transfer. Ensoniq sampler users figured this out back in the 90's, as they didn't provide term power either. Attaching a rare powered active terminator to the other Zip port, or adding another device to the bus with term power would solve the issue. Ultimately most of us Ensoniq users ended up jumping 5v to the term power pin of the sampler's scsi port with a Schottky diode.
I LOVED my SyQuest Ez-Drive! It was great and for the day it's capacities were also great. And it was more durable for long-term backups and storage than Zip disks or other options.
Yeah I had one back in the day, it's still in my attic matter of fact. And I'm 99.9999999% sure it was an IDE drive as I didn't have any SCSI devices back then.
Good review! Feels like the behavior of dd_rescue should be implemented in the firmware, i.e. when reaching areas of bad sectors try to read in the other direction from the other end of the disk.
I think I'm going to need to get one of these things. Between the initiator mode and the recent addition of networking support it seems like one of the most useful SCSI devices ever created!
I like your channel. It is great how you are an expert but don’t try to hide your struggles. It it’s hard man. I do new stuff all the time that I barely understand and I get so frustrated with my constant failures but when I finally get it working it feels so good. Thanks for making videos
This is a great idea. I've been contemplating a PCB to do similar things with floppy and IDE drives -- image, media check, and format. PS: If you need SCSI ribbon cables .... just make one. You can get the 50-pin IDC ends (like the ones used for floppy and IDE, except 50-pin) and IDC D-Sub connectors at Digikey (or similar), as well as 50-conductor ribbon cable in whatever length you want. To crimp, there are cheap crimping tools (basically pliers with a plastic notched insert that the IDC connector fits on), OR just use a bench vise. You can also get a PCB adapter with a 50-pin pin header and a D-Sub or high-density connector on it (at your usual online cheap parts sources), then just use a normal internal SCSI ribbon cable to connect them. I never use stock ribbon cables anymore. Every build I make gets its own custom cables, at the length I need them, with the number of connectors I need at exactly the spacing I need. I then split the ribbon into groups of 5-10 conductors, and zip-tie them into a round-ish bundle. Internal cable management is no longer a problem.
I love projects like this. For archiving floppies I can really recommend a greaseweazle. i built a fluxengine setup as well but the greaseweazle is a lot easier to use. Bonus; you can read and write just about any format disk known to date. (Amiga, Apple, C64, you name it)
@@pelculator GW and KryoFlux are great, and between the two, I consider raw imaging a solved problem. What I wanted to build was a bit different -- I wanted it to understand the file system, so it could do higher-level things like format a disk, create sparse images, inject and remove files, and so on. I've been writing a FAT library in C for a few years, as one of a few puzzle projects that I work on when I get bored somewhere with my laptop and have a little time to kill and feel like coding. I figured I would add other FS libs to the collection, and then do something with them when they're done.
I found the video very instructive, and I am sold on the Blue SCSI enough that I ordered a wifi desktop version, and was seriously thinking of ordering 2. I guess you heard me yelling, that the D-Link power supply didn't have enough current capacity for those power hogs. Thanks
SCSI supports hotswapping at the protocol level, but, standard SCSI connectors do not. To use hotswapping on SCSI, you should have a 'backplane' and drives with 'sca' connectors. Those ensure there is a ground connection before anything else gets connected.
Thanks for this video. I have a ZuluSCSI in my Amiga 4000 (connected to a Cyberstorm) and It’s worked flawlessly for 18 months or so now. This however seems like a lot of hard work! I have a couple of old PCI Advansys and Adaptec SCSI cards and whilst Windows 10 doesn’t have drivers, both work fine under Ubuntu. I’ve imaged a number of old SCSI drives and have just used DD with gzip and SSH straight across my network from my old circa 2005 PC to my current machine.
I am also very satisfied with the initiator mode of BlueSCSIv2. With this I was able to read most of my SCSI disks from old Unix workstations. It is important that the power supply for termination (TERM_POWER) only comes from one source. But to connect SCSI disks to a modern computer, I recommend the SCSI adapter "LSI SCSI Ultra-320 Controller LSI20320IE". It is a PCIe card for which there are signed drivers for Windows 7, which also work without any problems under Windows 10 and of course also for Linux. With an appropriate adapter, you can also connect ancient SCSI1 devices to this ultrawide SCSI card.
So amazing to have an open source project that offers so many features for emulating and archiving SCSI drives. KUDOS to the hard working people on this project!
Can you check failed drives with the big psu? Those small ones are really crappy. I had problems with mine which came with isb2ide interface. Symptoms were like the drive was dead-clicking heads, strange behavior. Connecting proper psu fixed everything.
So nearly all SCSI initiators defaulted to address 7. Apple, Commodore, Sun, Adaptec, etc. Why 7? Because ID 7 is the highest priority device on an SCSI chain (even in later versions of SCSI that extended the ID range up to 15) and naturally you want the computer to be the highest priority device. BUT… all SGI computers (as far as I can remember) defaulted to using ID 0 for the controller. (There might have been other companies that did this too, but SGI is the only one I ever ran across.) Perhaps the drives that respond as both ID 0 and 7 were designed to work in an SGI without needing to set jumpers. I'd be willing to bet that these drives only exhibit this behavior if the jumpers are set to ID 0 _and_ they see a request coming from another device with ID 0.
That's a good hypothesis. I was wondering if it might have something to do with SCAM mode. (I don't know anything about how SCAM works, but it seemed possible that bus devices might listen on ID 7 to get their real assigned ID.)
@@nickwallette6201 it should be preferring what the drive is set to. What I think is happening is that the drive isn't fully spun up and ready on the first try, then for some reason the controller resets the bus and switches ID with the drive. Now the drive has had time to initialize fully and works as ID7 so gets imaged. After the imaging is complete, the BlueSCSI resets the bus, switches back ti ID7, and finds the drive as ID0 (because that's what is set on the drive), and promptly images it all over again. Firmware bug for sure, it should def. not switch the initiator ID like that. If something doesn't respond during scan, just keep going and retry ID0 on the next loop. SCAM should only be used in case of actual conflicts.
@@Qyngali I thought the point of SCAM was to make it unnecessary to set the ID at all? I've never used it, nor looked into how it works, so it could be that my assumptions are all wrong. But I've also never seen a specific jumper position to enable/disable SCAM support on a drive, so my intuition led me to the shot-in-the-dark guess that maybe the devices listen on ID7 for SCAM. (Quite likely not, it was just an idea.) But like the OP said, it's merely convention that we place the bus controller on ID7 -- it's not a hard rule, and while it's common, it's not a given. So, I think it's not a bug that the device scans all 8 IDs... that's actually kind of a clever feature. It just might need some smarter logic to avoid whatever it is that ends up probing the same device twice.
@@nickwallette6201 There are 2 levels of SCAM support, compliant, and tolerant. And no support of course. 1) SCAM-compliant drives allow a SCAM-compliant host adapter to set the drive's SCSI ID and termination status automatically. 2) SCAM tolerant devices report their SCSI ID and termination status to the adapter, but cannot reset SCSI ID or termination status automatically. Instead, you must change jumpers or switches on the drive manually to set SCSI ID and termination. 3: Non-SCAM drives do not even report their current settings to the adapter, let alone allow the adapter to reset them automatically. When using non-SCAM devices, you must manually verify settings and change them as necessary. Note that enabling SCAM on the host adapter may cause your computer to hang if you connect a non-SCAM drive because the adapter is unable to determine current settings for the non-SCAM device. So only way to fix is to disable SCAM on the initiator. The last point might be the reason some of the drives didn't show up at all on the BlueSCSI but worked on the laptop. I wonder if there's a way to turn off SCAM on the BlueSCSI via the INI file. That would probably fix both the ID swapping problem and potentially make the drives that didn't get identified but worked on the laptop work as well... Damn that was a wall of text lol.
The pico wifi version connects the led to the cypress wifi module and to use It requires to use a PIO program, so it is normal that in some projects is not used.
Can't wait to get one. The earlier version had some difficulties with machines like Digital VAX VMS and Silicon Graphics IRIX which, while SCSI command issuing machines, certainly had their own behaviours. This is due to the limited testing companies did with SCSI devices not supplied by them.
It was pretty common for some vendors to lock their drivers down to only talk to certain "blessed" peripherals back in the day, forcing you to buy additional hardware from them. Infuriating, because SCSI was otherwise very stable and compatible.
Hi Adrian, thanks for testing the BluSCSI. Allow me some remarks: 1. SCSI cables Here in Germany we still have Partsdata which I as an Atari user know since the nineties shortly after Dr. Zellmer opened his shop. Partsdata is still around and still sells a variety of SCSI cables although although the selection is smaller than 30 years ago. 2. Communication problems I remember that especially with early ACSI to SCSI adapters there were several issues: SCSI drives may want to see the parity handled correctly, furthermore there is an additional phase, the reselection phase. When the drive goes busy it can drop the transfer and do a relection when it's done. ACSI was quite limited and early ACSI to SCSI adapters didn't implement these features so that several drives failed. Although it's not important for the BlueSCSI many adapters had the problem that only the first command group (group 0) could be used. Does BlueSCSI implement parity and reselection correctly? Otherwise you may run into trouble.
I'm a simple person. I see Adrian and I click. That being said, I never had SCSI when I was growing up; all the PCs I had had IDE and ATAPI devices, so I really missed out.
Cool. I was wondering how I might be able to image an old Amiga SCSI drive that hasn't been power on in decades and IF it does spin up, might never do it again. I think I see a BlueSCSI in my future... Great video and work on this device from the community!
Hopefully this would work on my Amiga A3000 with a 105 meg drive, and one about 50 to 55 megs. I think 52 megs. Put one of the floppy emulator from Adafruit, and put all of my Fred Fish disks on that.
I made backups of all my Amiga drives years ago and the images are in an emulator. My main physical backups from the Amiga are on a large stack of Zip disks.
In the 80s, I worked for Systime Computers, developing 286 and 386 minicomputers - not PCs - that used SCSI. The system supported four full-height 5.25" SCSI disks, a SCSI QIC150 cartridge tape drive and a 5.25" SCSI floppy. Each device had different timing and "messing about" sequences at boot time to wait for them to become sufficiently ready to respond to a Request Sense command. I am entirely unsurprised by your experiences with your multiple drives.
on 9:00 you can see changes of latest fimware version, which literally says LED is disabled in this version. :-) Later into video I so wish I could tell you!
There is useful little software that will show you connected serial ports, show notifications and even allow to launch another program when specified serial port is connected, it's called Serial Port Notifier. I use it, and it's really useful.
Great, albeit a bit of a flaky device at the moment. I have an old Micropolis SCSI 175MB hard drive from my old Atari ST that I'd love to get the data off and this looks like it will be perfect to do that fairly soon. Please keep us updated as to how this BlueSCSI evolves and when it's mature I'll be grabbing one to get my data.
The Pi Pico isolates the USB power from the power to the Pico itself, since the Pico has a power manager chip. There is a USB power out on the Pico in case you want to power external devices directly off of the USB, but more likely the scsi board powers the Pico through the power in/out pin and has the USB power out pin open.
That was great and I have this exact need for a SGI Iris Indigo (my attempt with Linux and a SCSI adapter was abandoned after it got too gnarly). It definitely critical that it can deal with bad sectors and let us recover what we can. I guess I’ll buy yet more of the blue SCSI devices and try it out.
@@ffsireallydontcare Didn’t get there. I had trouble getting it to identify and at some point I got tired of messing with it (some kernel hacking involved).
@@tommythorn Oh wow, yeh that's weird. I could understand if it was the file system, it's been a while for me but I *think* some versions of SGI's XFS aren't supported by Linux's XFS implementation. But if the drive couldn't be detected at all then there's a deeper hardware issue.
Hi. The problem with drives that just did nothing could be amount of power provided by small black power brick. you should retest with ATX power supply. also you can use it with PC machine and have the same power rails on USB power.
The closest I came to owning a Scsi Device was when I had an Imperial Toys Slammer Whammer (Knock off pogs) that had a robot guy on it called the "Scuzzy Cable Terminator" But still I like to watch videos like this because things like this are so neat.
had to look it up, didn't disappoint, wonder how they actually came up with that name,, my theory is someone on the design team heard IT guy say something like that and thought it sounded pretty cool
30:00 I have a theory, it's imaging the 3 drives as ID7, and then starts checking ID0-7 again. Except now it's detecting something on ID0(itself) and thinks it's a drive. And then proceeds to read the drive again. The drives are just responding to the data requests the BlueSCSI are sending out. And the drives aren't smart enough to know it's requesting data from ID0. Which would explain why it's happening on some drives but not others. Either that OR the BlueSCSI is emulating a SCSI drive using the image it just made and is reading from itself.
@@JackpkmnI remember a whole bunch of versions, fast, wide, differential…. But the VLB version made me laugh as everyone knew it was a temporary bus solution. Props for them making it, of course.
I had this and Linux 0.12 didn’t support it so I borrowed an IDE based PC to write the very first SCSI driver for Linux with that. My first contribution to the kernel.
Back in the day, I ran into the same issue that manifests itself in your case as the two images. With some SCSI devices, if you set its ID the same as the controller (initiator), it shows up as EVERY ID. Simple fix for the BlueSCSI issue... after scanning IDs 0-6, set the initiator ID to an unused ID. I discovered this little issue at work, when I was setting up a 4 drive system. The ID of the controller card was set with jumpers, and one of the jumpers (bit 2) had come off and I didn't realize it. Install drive 0... test OK. Same for drives 1 and 2. Add drive 3... and the SCSI BIOS screen said I had 7 drives! SCSI troubleshooting 101 back in the '90s.
Using two separate power supplies will often cause a problem because they're not referenced to the same ground potential. Remember, 5 volts (or whatever) is only 5 volts _relative_ to something else, there's no "universal" 5 volts. Often you can fix this by connecting the grounds of both power supplies together but you need to be careful depending on exactly how the particular supplies you are using are set up in case you end up with a large current flowing between them. Best to use a single supply if possible.
44:50 Some of those 12 volts power supplies (the black brick) doesn't have both the ground in the molex connector and that can make the drive fail to run. I have noticed that by myself when using similar power supplies.
I had a SCSI drive on my Apple IIe years ago. As I recall, one of the symptoms of a SCSI bus problem is that drives start to show up at ALL addresses. When the BlueSCSI sets itself to ID 0, that would cause an address conflict with the physical drive. That might be why it sees the drive twice.
Adrian. The drives that did not work. Did you try using the at power supply your brick may not be big enough to supply power to some of those drives like you found out with the zip drive
If you're worried about issues with backfeeding, you can get a USB cable and cut the 5V wire, but keep ground, D+ and D-, it should work fine with a device that has it's own power. Found this by accident with a cheap USB hub with power switches for each port, that just disconnect the 5V line for that port. If I connect a cable from the hub to my MiSTer's serial port and leave that port on the "off" position, it still shows up on the computer when I power up the MiSTer.
The Pico W has a slightly different IO configuration from the regular PICO. All the externally accessible IOs are the same, but some of the onboard stuff was changed to make room for the wireless controller. VBUS sense, SMPS power save mode and the onboard LED must now be accessed via the wireless controller. Vsys voltage monitoring is still performed with the ADC on the RP2040, but this line is shared with a SPI line from the wireless chip, so some care is needed. This explains your LED problem, and may also explain why you can't get the serial over USB to work.
I was a big fan of the Zip disk. I still own both internal and parallel port versions. Don't know if any of my disks are still readable, and to be honest i don't care, it was all old internet stuff and pr0n. Never had the click of death, and i had/have at least 30-40 Zip disks. But considering how many people did have issues, Iomega didn't have a really solid product. Heck, i remember having to service the Bernoulli box, which was also probably not ready for prime time. But if you babied it, and expected occasional failures, they were a solution to "large removable" storage back in the 80's.
I used to use an EZ Drive as a boot drive back during the early Windows 95 days. I had DOS/Windows 3.1 on one and Windows 95 on another and programs/data on the main drive.
Hi! Great video! About the image files that are created: are you able to mount them using windows software or using the bluescsi? Also, can try using Linux windows "mount" command.
Will live serial/terminal output be a thing? It'd be really nice to have to see progress. Adrian, plug your power supply in to a watt meter. Then you can see when things are idle or are doing work. I got a Kuman energy meter from amazing.
As a professional software developer, I wish all the users of software system were as thorough and provided as much information as you did for the BlueSCSI team. I hope they appreciate the completeness of your bug report and testing. Thanks for continuing to be such an awesome role model for the community.
Some one can check me, but using more then 1 source of current it typically not a problem. Unless there is a diode in between them. FYI a transistor can act like a diode. If there is a diode, the current mismatch between the two sides can cause a current sink issue which will then turn the diode off when it should be on. Basically if the draw is more on the input, it will cause a kind of reverse bias, switching the diode off. if the grounds and two rails are tied together will usually prevent this. Most power supplies have multiple regulators to get the ampacity needed. Again has long has the grounds and rails at tied into 1, it works. Most likely the blue scis is not completely bonded together with drive, so the there is a bias problems. This could be as simple as incorrect values on termination.
Yeah, you're mostly wrong. Unless power supplies are specifically designed to be run in parallel you should not run them in parallel. If both supplies are not perfectly matched you could cause backfeed currents. A pair of diodes (in a diode-OR configuration) isolates both supplies and prevents any possible backfeed.
I could use one of those. I have a bunch of old Mac drives. Seems like it has a few SCSI comm bugs in it, but it beats all the alternatives. SCSI is a fine art, especially termination.
Read the log from 27:48 and a bit, drive reports not ready, then the controller sends STARTSTOP. Some lines down from that it says NO RESPONSE, then starts scanning for ID 1, 2 etc.
I can't remember ever seeing this kind of behaviour where a drive first responds to ID 0, then stop responding and switch to ID7 lol. The controller ID can be changed in software on most real controllers so it should be possible to have it change ID automatically and reset the bus followed by a rescan. I have never touched the BlueSCSI so this is just speculation from a general SCSI perspective. I can't for the life of me say why or how the drive responds to both 0 and 7 though... I'm commenting before watching the whole video so maybe you figured it out later on, but it's fun to follow along. :)
For some reason whenever I edit a post UA-cam gives an error and deletes the post, so have to make a new one. Fun. I just remembered that SCAM can autoset ID, so maybe the drives that did this supports that. I have no idea if the BlueSCSI supports SCAM though. If a drive doesn't support it it will get what's set on the drive no matter what. Still weird that the drive switches with the initiator though, the initiator should always be 7 unless a drive is set to that. I saw another comment mention that SGI and possibly some others set the controller as ID0, but that doesn't apply here as the BlueSCSI starts off at ID7. Possibly the firmware is a bit buggy and switch the IDs around for no apparent reason.
After some more thinking, I think what's happening is that the initiator doesn't give the drive enough time to spin up properly for the drives that give you 2 images. On the first try the drive isn't ready, so the controller moves on to ID1 and so on. When it reaches ID 6 and haven't found anything it for some reason reassign ID0 to ID7 and the initiator to 0. Then starts imaging the drive. When it finishes it resets the bus and the drive reverts to ID0 and the BlueSCSI images it. The only way this is possible would be that the drives (and initiator) that does this supports SCAM (SCSI Configured Auto-Magically). I think I saw an .ini option to set a delay so try to set it higher than default and see what happens.
This needs a few creature comforts for sure. an LED maybe that tells what mode its in, and one that shows that its actually imaging a drive.... A display would actually be better :)
5:55 backferd termination power... Alrighty then. Most of us are probably very very rusty on arcane SCSI non-standards and termination voodoo. I do recall vague memories of SCSI hell with various devices, computers and interfaces disagreeing on active/passive /other termination. Maybe you can refresh us on all varieties of SCSI termination concepts and why it is even an issue for scsi but apparently not other busses?
09:30 when you say "is actually going to my scan converter" ... it's the OSSC or another one? If it's the OSSC I would love to know how you manipulate it via com port
Are you sure the earlier problems with the HDD's weren't due to the cheapo hard driver power supply you were using? Might be worth retrying with the big old AT power supply that you used at the end, since I've had various problems with those hard drive power supplies that come with a IDE-USB adapters.
It occurs to me that the drives where it begins to have read errors may be trying to read from areas that were previously marked bad from low-level format
I’m surprised you didn’t try setting the drives to ID1? IME as a Mac tech in the 90’s, we always set hard drives to 1 or 2 and then CD drives to ID3. Any additional hard drives would be ID4+.
I just watched a UA-cam video about USB-C cables. Apparently, cables can be configured with more or less connections. There are 5V cables, and cables with all the bells & whistles wiring in them, that are far less flexible/bendy. I’m irritated that Adrian can get NO info out of the Pico USB serial port - and wonder whether it’s a USB-C cable issue? I.e. - is Adrian using the wrong USB-C cable? Just a thought. However, REALLY interesting video, as I have some old SCSI drives from OLD macs, and will be buying a BlueSCSI shortly. Certainly worth trying the tests again using the ATX supply. The smaller brick supplies are often not clean, and sometimes awfully regulated. Matt
I have some 7 or more SCSI disks that almost certainly have been used in RAID-5 combo. Your BlueSCSI interface seems to be 50-pin, if I can deem from the video. My SCSI drives are Ultra-SCSI, with 68 pin connectors, although I also have saved some from my own PC in the old days, before the IDE onslaught. These latter ones were with 50-pin connectors. So, my thoughts started to fly when seeng this video. Could I possibly…..?
Mayhaps i'm going crazy but this video had a lot hard cuts during dialog, doesnt it? Besides from that - kinda interesting having this backup-mode for these old drives.
I know this video is intended as an exploration of the BlueSCSI, however in general I'm skeptical of "black box" imagers with little-to-no real-time feedback. Personally, as I don't have any professional tools, I use ddrescue as the next best thing. Its tunable algorithm does a bulk sweep of the drive and notes problem areas, which it then revisits using different techniques to get out as much data as possible. Its operation is also able to be monitored using a graphical tool, so you can visually see when it's struggling to get any further data out and manually interrupt it. Edit: it's vs its... gets me every time.
Thinking about this further, if BlueSCSI could implement the ddrescue algorithm and provide a similar monitoring system it *could* be ideal. One of the biggest problems with ddrescue is when the controller locks up. This often requires manual intervention to power cycle devices then restart ddrescue, instructing it to continue where it left off or jump over a problem sector. As BlueSCSI could be designed to have total control over the interface hardware it could perform these hardware operations automatically.
SGI computers would default to SCID0 for the controller. The real solution here is to have the bluescsi find a serial number or something on the drive to determine if the device happens to listen to multiple addresses. This will work until you get to a point where a hardware RAID controller would be offering different volumes on different SCSI IDs but give the same serial and device information.
A quick hint for whoever is writing the software. That LED on the Pi could be used to blink morse code status and error codes. It would at least give a clue as to where in the process the thing is.
There's a reason that the phrase "SCSI Voodoo Magic" is used around terminating and cabling SCSI HD's. Used to be a master of that Black Art with many generations of Mac's. Firewire fixed all that, but now Apple and Sony have dropped it for USB (which has it's own issues... Version 1.1, 2., 3. etc... Mini/Micro B connector, USB-C, Thunderbolt, etc.... All still light years beyond Parallel and RS-232 and all the early buss's)
I dunno if it's related, but the SCSI CD-ROM drive I use with my A1200 will only work if set to ID 7, it has a small dial on the back of the drive to select ID, rather than jumpers.
Wait why does the Pico's LED need to be blinking when they've built an "ACT" LED onto the board next to "PWR"? And why isn't that LED actually working either, if the unit is actually doing the thing?
The problem I had with getting the COM [n] to get through the pico was using a USB micro with power AND data capabilities. Apparently the cheap ones from the corner store only charge devices!
I probably tested the HDD in the ATX power supply, this old HD need a loot of power. ( not knowing what is the consumption off bluescsi "assuming 1w , 0.5 for the pico and other 0.5 for the rest" Searching in google some SCSI are 900ma in 5v and 1,5a in 12v an other's only put 13w.
![Adrian's Digital Basement ][](http://yt3.ggpht.com/ytc/AIdro_k7CrQRe71qN6c0Ua7A1P_I8KkxjqLa70u0zYeCvdvnKw=s48-c-k-c0x00ffffff-no-rj)
UPDATE Feb 28, 2024: The latest firmware for the BlueSCSI fixes all of the issue I experienced! I broke out the troublesome drives and they work, all of them! Also, the LED issue and USB COM port issues are resolved too. Everything is fixed, so please give trhis awesome feature out a try but please update your firmware first.
Maybe time to revisit this with an update video?
@@saganandroid4175 That would be awesome! I hope Adrian will give this a try.
Would love an update video on this 🙂
Also the ID7 issue?
Thanks for testing all these drives with BlueSCSI! We've only tested with a few drives so I really appreciate you gathering detailed bug reports. We'll have a beta release this weekend for everyone else who wants to try this out can avoid some of these issues (and report new ones :) )
Of course! Hopefully more people can test this so we can get an even larger dataset!
Awesome. I ordered the BlueSCSI right after seeing this video. I have an IBM drive that I’ve been wanting to see what files are on it.
Fixes are now in the "Nightly" release. Pico-W LED/Serial, Logging, Double Image, etc.
Awesome!!
@@helfire23
@helfire23, you've been knocking out bugs so quickly! Simply amazing!
Adrian (replying at 20:15) it doesn't surprise me that there are errors as you were picking up the drive and waving it around. I was always taught that you never ever move a drive while spinning even if you don't think it's active.
Modern drives do seem more forgiving, probably because they often have inbuilt accelerometers to park heads when motion is too much, but the 1980s ones definitely didn't have those!
Yeah, that was driving me nuts. He does good videos and I like him, but sometimes....
When I used to work on Macs, any SCSI drive that was having problems reading, including booting up, I always waved around to get the platters spinning, and then immediately backed them up. It almost always spins them up if they have bad bearings.
I LOOOOOVE that you're keeping and forwrding the log files and images for the developpers. It's so cool when youtubers actually PARNER with people, and be real community members instead of just grandstanders. Cheers!
Should try all those hard drives again using the big power supply, that power brick doesn't seem to handle both BlueSCSI and a SCSI drive.
that is what i was going to say
yep, by the time those power bricks came out, HDDs had lower power requirements (watts) than the older drives.
on my power brick like that one, which came with a cheap HDD to USB adapter, the AC cable didnt have the best connection to it. replacing the AC cable made it more reliable.
This ^ and what others here pointed out. I can't tell you how many times the guy who handled the inventory at an old computer shop would order the external HDD adapter over and over again simply because the USB HDD adapters were good, but those A/C adapters they provide are JUNK! I no longer trust those bricks and ALWAYS use a dedicated AT or ATX power supply when using them to eliminate any possible power fluctuations. I hate to say it, but don't rely on those A/C adapter power supplies they include or you're just asking for a bad time.
A thought; you may have already tried it, but maybe worth retesting the drives that failed with that ATX power supply. Just incase the drives drag one of the rails down enough to crash the pico and stop it logging anything. A spin-up-related drain on the 12v could affect the 5v and in turn the 3.3V powering the pico. A really curious individual might stick a scope on 5V to watch for dips or ripple.
I can see this being very good for the music industry backing up their many thousands of hard drives with original recordings after they switched from tape to computers.
The problem with the log file "just ending" is usually caused by buffering during write. Especially with solid state storage, one doesn't want to "just keep writing", and for magnetic media it was faster with a buffer. i.e. the "print line" that logs something is translated into bytes for the file, and added to the output buffer. If that buffer is full, it will be flushed to the file. Note that the buffer is in bytes, the lines are arbitrary, so the file will grow in blocks - e.g. 4kb - not lines. What most developers forget, is to issue a "flush" command at the end of the proccss, especially when something fails. Sometimes the file even gets closed before the buffer can be flushed... lots of possibilities :)
Thank you for the detailed testing of this feature, this will be very helpful to the Digital Preservation community!
SCSI Zip drives are often problematic when they are the only device besides the initiator. They do not provide any termination power, and rely on it being present on the SCSI bus. They only switch the resistors on or off the bus. You need to have another device in the chain that adds term power. Initiators will usually see/identify the Zip, but be unable to do any data transfer. Ensoniq sampler users figured this out back in the 90's, as they didn't provide term power either. Attaching a rare powered active terminator to the other Zip port, or adding another device to the bus with term power would solve the issue. Ultimately most of us Ensoniq users ended up jumping 5v to the term power pin of the sampler's scsi port with a Schottky diode.
Yes, that is my memory of helping customers with this drives as well.
I LOVED my SyQuest Ez-Drive! It was great and for the day it's capacities were also great. And it was more durable for long-term backups and storage than Zip disks or other options.
I think the EZ-Drive didn't catch on because CD-RW arrived only a couple of years later.
Yeah I had one back in the day, it's still in my attic matter of fact. And I'm 99.9999999% sure it was an IDE drive as I didn't have any SCSI devices back then.
Good review! Feels like the behavior of dd_rescue should be implemented in the firmware, i.e. when reaching areas of bad sectors try to read in the other direction from the other end of the disk.
Oh... i like this - will give it a try :)
I think I'm going to need to get one of these things. Between the initiator mode and the recent addition of networking support it seems like one of the most useful SCSI devices ever created!
I like your channel. It is great how you are an expert but don’t try to hide your struggles. It it’s hard man. I do new stuff all the time that I barely understand and I get so frustrated with my constant failures but when I finally get it working it feels so good. Thanks for making videos
Love using multiple picos to emulate parts of a machine that one pico is faster. BRILLIANT!
This is a great idea. I've been contemplating a PCB to do similar things with floppy and IDE drives -- image, media check, and format.
PS: If you need SCSI ribbon cables .... just make one. You can get the 50-pin IDC ends (like the ones used for floppy and IDE, except 50-pin) and IDC D-Sub connectors at Digikey (or similar), as well as 50-conductor ribbon cable in whatever length you want. To crimp, there are cheap crimping tools (basically pliers with a plastic notched insert that the IDC connector fits on), OR just use a bench vise.
You can also get a PCB adapter with a 50-pin pin header and a D-Sub or high-density connector on it (at your usual online cheap parts sources), then just use a normal internal SCSI ribbon cable to connect them.
I never use stock ribbon cables anymore. Every build I make gets its own custom cables, at the length I need them, with the number of connectors I need at exactly the spacing I need. I then split the ribbon into groups of 5-10 conductors, and zip-tie them into a round-ish bundle. Internal cable management is no longer a problem.
I love projects like this. For archiving floppies I can really recommend a greaseweazle. i built a fluxengine setup as well but the greaseweazle is a lot easier to use. Bonus; you can read and write just about any format disk known to date. (Amiga, Apple, C64, you name it)
@@pelculator GW and KryoFlux are great, and between the two, I consider raw imaging a solved problem.
What I wanted to build was a bit different -- I wanted it to understand the file system, so it could do higher-level things like format a disk, create sparse images, inject and remove files, and so on. I've been writing a FAT library in C for a few years, as one of a few puzzle projects that I work on when I get bored somewhere with my laptop and have a little time to kill and feel like coding. I figured I would add other FS libs to the collection, and then do something with them when they're done.
I found the video very instructive, and I am sold on the Blue SCSI enough that I ordered a wifi desktop version, and was seriously thinking of ordering 2. I guess you heard me yelling, that the D-Link power supply didn't have enough current capacity for those power hogs. Thanks
SCSI supports hotswapping at the protocol level, but, standard SCSI connectors do not. To use hotswapping on SCSI, you should have a 'backplane' and drives with 'sca' connectors. Those ensure there is a ground connection before anything else gets connected.
Holy smokes, I have a BlueSCSIv2 and I had no idea this was a thing!
Thanks for this video. I have a ZuluSCSI in my Amiga 4000 (connected to a Cyberstorm) and It’s worked flawlessly for 18 months or so now. This however seems like a lot of hard work! I have a couple of old PCI Advansys and Adaptec SCSI cards and whilst Windows 10 doesn’t have drivers, both work fine under Ubuntu. I’ve imaged a number of old SCSI drives and have just used DD with gzip and SSH straight across my network from my old circa 2005 PC to my current machine.
I am also very satisfied with the initiator mode of BlueSCSIv2. With this I was able to read most of my SCSI disks from old Unix workstations. It is important that the power supply for termination (TERM_POWER) only comes from one source.
But to connect SCSI disks to a modern computer, I recommend the SCSI adapter "LSI SCSI Ultra-320 Controller LSI20320IE". It is a PCIe card for which there are signed drivers for Windows 7, which also work without any problems under Windows 10 and of course also for Linux. With an appropriate adapter, you can also connect ancient SCSI1 devices to this ultrawide SCSI card.
So amazing to have an open source project that offers so many features for emulating and archiving SCSI drives. KUDOS to the hard working people on this project!
That's a really neat feature of those SCSI emulator devices! Super neat devices!
Can you check failed drives with the big psu? Those small ones are really crappy. I had problems with mine which came with isb2ide interface. Symptoms were like the drive was dead-clicking heads, strange behavior. Connecting proper psu fixed everything.
I was thinking exactly the same thing once the Syquest drive began working. Old drives are power hungry!
So nearly all SCSI initiators defaulted to address 7. Apple, Commodore, Sun, Adaptec, etc. Why 7? Because ID 7 is the highest priority device on an SCSI chain (even in later versions of SCSI that extended the ID range up to 15) and naturally you want the computer to be the highest priority device. BUT… all SGI computers (as far as I can remember) defaulted to using ID 0 for the controller. (There might have been other companies that did this too, but SGI is the only one I ever ran across.) Perhaps the drives that respond as both ID 0 and 7 were designed to work in an SGI without needing to set jumpers. I'd be willing to bet that these drives only exhibit this behavior if the jumpers are set to ID 0 _and_ they see a request coming from another device with ID 0.
That's a good hypothesis. I was wondering if it might have something to do with SCAM mode. (I don't know anything about how SCAM works, but it seemed possible that bus devices might listen on ID 7 to get their real assigned ID.)
@@nickwallette6201 it should be preferring what the drive is set to. What I think is happening is that the drive isn't fully spun up and ready on the first try, then for some reason the controller resets the bus and switches ID with the drive. Now the drive has had time to initialize fully and works as ID7 so gets imaged. After the imaging is complete, the BlueSCSI resets the bus, switches back ti ID7, and finds the drive as ID0 (because that's what is set on the drive), and promptly images it all over again. Firmware bug for sure, it should def. not switch the initiator ID like that. If something doesn't respond during scan, just keep going and retry ID0 on the next loop. SCAM should only be used in case of actual conflicts.
@@Qyngali I thought the point of SCAM was to make it unnecessary to set the ID at all? I've never used it, nor looked into how it works, so it could be that my assumptions are all wrong. But I've also never seen a specific jumper position to enable/disable SCAM support on a drive, so my intuition led me to the shot-in-the-dark guess that maybe the devices listen on ID7 for SCAM. (Quite likely not, it was just an idea.)
But like the OP said, it's merely convention that we place the bus controller on ID7 -- it's not a hard rule, and while it's common, it's not a given. So, I think it's not a bug that the device scans all 8 IDs... that's actually kind of a clever feature. It just might need some smarter logic to avoid whatever it is that ends up probing the same device twice.
@@nickwallette6201 There are 2 levels of SCAM support, compliant, and tolerant. And no support of course.
1) SCAM-compliant drives allow a SCAM-compliant host adapter to set the drive's SCSI ID and termination status automatically.
2) SCAM tolerant devices report their SCSI ID and termination status to the adapter, but cannot reset SCSI ID or termination status automatically. Instead, you must change jumpers or switches on the drive manually to set SCSI ID and termination.
3: Non-SCAM drives do not even report their current settings to the adapter, let alone allow the adapter to reset them automatically. When using non-SCAM devices, you must manually verify settings and change them as necessary. Note that enabling SCAM on the host adapter may cause your computer to hang if you connect a non-SCAM drive because the adapter is unable to determine current settings for the non-SCAM device. So only way to fix is to disable SCAM on the initiator.
The last point might be the reason some of the drives didn't show up at all on the BlueSCSI but worked on the laptop.
I wonder if there's a way to turn off SCAM on the BlueSCSI via the INI file. That would probably fix both the ID swapping problem and potentially make the drives that didn't get identified but worked on the laptop work as well...
Damn that was a wall of text lol.
The pico wifi version connects the led to the cypress wifi module and to use It requires to use a PIO program, so it is normal that in some projects is not used.
Yep! this makes it frustrating to deal with.
Can't wait to get one. The earlier version had some difficulties with machines like Digital VAX VMS and Silicon Graphics IRIX which, while SCSI command issuing machines, certainly had their own behaviours. This is due to the limited testing companies did with SCSI devices not supplied by them.
It was pretty common for some vendors to lock their drivers down to only talk to certain "blessed" peripherals back in the day, forcing you to buy additional hardware from them. Infuriating, because SCSI was otherwise very stable and compatible.
Hi Adrian,
thanks for testing the BluSCSI. Allow me some remarks:
1. SCSI cables
Here in Germany we still have Partsdata which I as an Atari user know since the nineties shortly after Dr. Zellmer opened his shop. Partsdata is still around and still sells a variety of SCSI cables although although the selection is smaller than 30 years ago.
2. Communication problems
I remember that especially with early ACSI to SCSI adapters there were several issues: SCSI drives may want to see the parity handled correctly, furthermore there is an additional phase, the reselection phase. When the drive goes busy it can drop the transfer and do a relection when it's done. ACSI was quite limited and early ACSI to SCSI adapters didn't implement these features so that several drives failed. Although it's not important for the BlueSCSI many adapters had the problem that only the first command group (group 0) could be used. Does BlueSCSI implement parity and reselection correctly? Otherwise you may run into trouble.
I'm a simple person. I see Adrian and I click. That being said, I never had SCSI when I was growing up; all the PCs I had had IDE and ATAPI devices, so I really missed out.
Cool. I was wondering how I might be able to image an old Amiga SCSI drive that hasn't been power on in decades and IF it does spin up, might never do it again. I think I see a BlueSCSI in my future... Great video and work on this device from the community!
Hopefully this would work on my Amiga A3000 with a 105 meg drive, and one about 50 to 55 megs. I think 52 megs. Put one of the floppy emulator from Adafruit, and put all of my Fred Fish disks on that.
I made backups of all my Amiga drives years ago and the images are in an emulator. My main physical backups from the Amiga are on a large stack of Zip disks.
Did you try the failed drives with the beefier power supply that you had to use with the Syquest drive? Maybe the failed drives need more power.
In the 80s, I worked for Systime Computers, developing 286 and 386 minicomputers - not PCs - that used SCSI. The system supported four full-height 5.25" SCSI disks, a SCSI QIC150 cartridge tape drive and a 5.25" SCSI floppy. Each device had different timing and "messing about" sequences at boot time to wait for them to become sufficiently ready to respond to a Request Sense command. I am entirely unsurprised by your experiences with your multiple drives.
on 9:00 you can see changes of latest fimware version, which literally says LED is disabled in this version. :-) Later into video I so wish I could tell you!
There is useful little software that will show you connected serial ports, show notifications and even allow to launch another program when specified serial port is connected, it's called Serial Port Notifier. I use it, and it's really useful.
Great, albeit a bit of a flaky device at the moment. I have an old Micropolis SCSI 175MB hard drive from my old Atari ST that I'd love to get the data off and this looks like it will be perfect to do that fairly soon. Please keep us updated as to how this BlueSCSI evolves and when it's mature I'll be grabbing one to get my data.
It's much easier on the PiSCSI. Great to see the video and as usual covered very well.
The Pi Pico isolates the USB power from the power to the Pico itself, since the Pico has a power manager chip.
There is a USB power out on the Pico in case you want to power external devices directly off of the USB, but more likely the scsi board powers the Pico through the power in/out pin and has the USB power out pin open.
That was great and I have this exact need for a SGI Iris Indigo (my attempt with Linux and a SCSI adapter was abandoned after it got too gnarly). It definitely critical that it can deal with bad sectors and let us recover what we can. I guess I’ll buy yet more of the blue SCSI devices and try it out.
When you were using Linux, did you use ddrescue as your image software or plain dd?
@@ffsireallydontcare Didn’t get there. I had trouble getting it to identify and at some point I got tired of messing with it (some kernel hacking involved).
@@tommythorn Oh wow, yeh that's weird. I could understand if it was the file system, it's been a while for me but I *think* some versions of SGI's XFS aren't supported by Linux's XFS implementation. But if the drive couldn't be detected at all then there's a deeper hardware issue.
Hi. The problem with drives that just did nothing could be amount of power provided by small black power brick. you should retest with ATX power supply. also you can use it with PC machine and have the same power rails on USB power.
The closest I came to owning a Scsi Device was when I had an Imperial Toys Slammer Whammer (Knock off pogs) that had a robot guy on it called the "Scuzzy Cable Terminator"
But still I like to watch videos like this because things like this are so neat.
had to look it up, didn't disappoint, wonder how they actually came up with that name,, my theory is someone on the design team heard IT guy say something like that and thought it sounded pretty cool
love this i hope in some point will be able to support scsi 68 pin
30:00 I have a theory, it's imaging the 3 drives as ID7, and then starts checking ID0-7 again. Except now it's detecting something on ID0(itself) and thinks it's a drive. And then proceeds to read the drive again. The drives are just responding to the data requests the BlueSCSI are sending out. And the drives aren't smart enough to know it's requesting data from ID0. Which would explain why it's happening on some drives but not others.
Either that OR the BlueSCSI is emulating a SCSI drive using the image it just made and is reading from itself.
Adrian, you don’t have an Adaptec AHA1542B? That was THE SCSI host adapter back in the day!
AHA2940 owner chiming in, it also works great for imaging these old drives.
@@Jackpkmn Wait, was that the VLB version?
@@CandyGramForMongo_Naw it's PCI.
@@JackpkmnI remember a whole bunch of versions, fast, wide, differential…. But the VLB version made me laugh as everyone knew it was a temporary bus solution. Props for them making it, of course.
I had this and Linux 0.12 didn’t support it so I borrowed an IDE based PC to write the very first SCSI driver for Linux with that. My first contribution to the kernel.
Back in the day, I ran into the same issue that manifests itself in your case as the two images. With some SCSI devices, if you set its ID the same as the controller (initiator), it shows up as EVERY ID. Simple fix for the BlueSCSI issue... after scanning IDs 0-6, set the initiator ID to an unused ID.
I discovered this little issue at work, when I was setting up a 4 drive system. The ID of the controller card was set with jumpers, and one of the jumpers (bit 2) had come off and I didn't realize it. Install drive 0... test OK. Same for drives 1 and 2. Add drive 3... and the SCSI BIOS screen said I had 7 drives! SCSI troubleshooting 101 back in the '90s.
Using two separate power supplies will often cause a problem because they're not referenced to the same ground potential.
Remember, 5 volts (or whatever) is only 5 volts _relative_ to something else, there's no "universal" 5 volts.
Often you can fix this by connecting the grounds of both power supplies together but you need to be careful depending on exactly how the particular supplies you are using are set up in case you end up with a large current flowing between them.
Best to use a single supply if possible.
44:50 Some of those 12 volts power supplies (the black brick) doesn't have both the ground in the molex connector and that can make the drive fail to run. I have noticed that by myself when using similar power supplies.
I had a SCSI drive on my Apple IIe years ago. As I recall, one of the symptoms of a SCSI bus problem is that drives start to show up at ALL addresses. When the BlueSCSI sets itself to ID 0, that would cause an address conflict with the physical drive. That might be why it sees the drive twice.
There is diode protection on 5V between pico usb micro connector and the 5V_TPWR from 50 pin connector on the BlueSCSI V2 50 pin desktop PCB.
Great Video. Small tip: standard multimeter probes fit perfectly in the Molex connectors and might be a little safer :)
What about other devices that use SCSI? Will they work? Scanner for example?
Adrian. The drives that did not work. Did you try using the at power supply your brick may not be big enough to supply power to some of those drives like you found out with the zip drive
Did you try reading the big drives using the bigger power supply?
Spooky. I was literally using my BlueSCSI v2 to image a drive from my Torch Triple X just a couple of days ago. A bit 'Baader-Meinhof'...
If you're worried about issues with backfeeding, you can get a USB cable and cut the 5V wire, but keep ground, D+ and D-, it should work fine with a device that has it's own power. Found this by accident with a cheap USB hub with power switches for each port, that just disconnect the 5V line for that port. If I connect a cable from the hub to my MiSTer's serial port and leave that port on the "off" position, it still shows up on the computer when I power up the MiSTer.
The Pico W has a slightly different IO configuration from the regular PICO. All the externally accessible IOs are the same, but some of the onboard stuff was changed to make room for the wireless controller. VBUS sense, SMPS power save mode and the onboard LED must now be accessed via the wireless controller. Vsys voltage monitoring is still performed with the ADC on the RP2040, but this line is shared with a SPI line from the wireless chip, so some care is needed.
This explains your LED problem, and may also explain why you can't get the serial over USB to work.
I was a big fan of the Zip disk. I still own both internal and parallel port versions. Don't know if any of my disks are still readable, and to be honest i don't care, it was all old internet stuff and pr0n.
Never had the click of death, and i had/have at least 30-40 Zip disks.
But considering how many people did have issues, Iomega didn't have a really solid product.
Heck, i remember having to service the Bernoulli box, which was also probably not ready for prime time. But if you babied it, and expected occasional failures, they were a solution to "large removable" storage back in the 80's.
More power, Scotty.
On the page when you updated the firmware, it mentioned that one change was disabling the onboard LED in the Pico W.
Separate power supplies work fine, as long as you common the grounds. 49:01
I used to use an EZ Drive as a boot drive back during the early Windows 95 days. I had DOS/Windows 3.1 on one and Windows 95 on another and programs/data on the main drive.
Hi! Great video! About the image files that are created: are you able to mount them using windows software or using the bluescsi?
Also, can try using Linux windows "mount" command.
Fun video. Thank you.
This is so cool! Could you do this with an external SCSI drive and 25 pin external version of the BlueSCSI?
Will live serial/terminal output be a thing? It'd be really nice to have to see progress.
Adrian, plug your power supply in to a watt meter. Then you can see when things are idle or are doing work. I got a Kuman energy meter from amazing.
As a professional software developer, I wish all the users of software system were as thorough and provided as much information as you did for the BlueSCSI team. I hope they appreciate the completeness of your bug report and testing. Thanks for continuing to be such an awesome role model for the community.
Maybe those few HDDs, which fails on initialization had the same power issue as that SyQuest, did you try them with PC power supply?
Some one can check me, but using more then 1 source of current it typically not a problem. Unless there is a diode in between them. FYI a transistor can act like a diode. If there is a diode, the current mismatch between the two sides can cause a current sink issue which will then turn the diode off when it should be on. Basically if the draw is more on the input, it will cause a kind of reverse bias, switching the diode off. if the grounds and two rails are tied together will usually prevent this. Most power supplies have multiple regulators to get the ampacity needed. Again has long has the grounds and rails at tied into 1, it works. Most likely the blue scis is not completely bonded together with drive, so the there is a bias problems. This could be as simple as incorrect values on termination.
Yeah, you're mostly wrong. Unless power supplies are specifically designed to be run in parallel you should not run them in parallel. If both supplies are not perfectly matched you could cause backfeed currents. A pair of diodes (in a diode-OR configuration) isolates both supplies and prevents any possible backfeed.
I could use one of those. I have a bunch of old Mac drives. Seems like it has a few SCSI comm bugs in it, but it beats all the alternatives. SCSI is a fine art, especially termination.
Read the log from 27:48 and a bit, drive reports not ready, then the controller sends STARTSTOP. Some lines down from that it says NO RESPONSE, then starts scanning for ID 1, 2 etc.
I can't remember ever seeing this kind of behaviour where a drive first responds to ID 0, then stop responding and switch to ID7 lol. The controller ID can be changed in software on most real controllers so it should be possible to have it change ID automatically and reset the bus followed by a rescan. I have never touched the BlueSCSI so this is just speculation from a general SCSI perspective.
I can't for the life of me say why or how the drive responds to both 0 and 7 though...
I'm commenting before watching the whole video so maybe you figured it out later on, but it's fun to follow along. :)
For some reason whenever I edit a post UA-cam gives an error and deletes the post, so have to make a new one. Fun. I just remembered that SCAM can autoset ID, so maybe the drives that did this supports that. I have no idea if the BlueSCSI supports SCAM though. If a drive doesn't support it it will get what's set on the drive no matter what.
Still weird that the drive switches with the initiator though, the initiator should always be 7 unless a drive is set to that. I saw another comment mention that SGI and possibly some others set the controller as ID0, but that doesn't apply here as the BlueSCSI starts off at ID7. Possibly the firmware is a bit buggy and switch the IDs around for no apparent reason.
After some more thinking, I think what's happening is that the initiator doesn't give the drive enough time to spin up properly for the drives that give you 2 images. On the first try the drive isn't ready, so the controller moves on to ID1 and so on. When it reaches ID 6 and haven't found anything it for some reason reassign ID0 to ID7 and the initiator to 0. Then starts imaging the drive. When it finishes it resets the bus and the drive reverts to ID0 and the BlueSCSI images it.
The only way this is possible would be that the drives (and initiator) that does this supports SCAM (SCSI Configured Auto-Magically).
I think I saw an .ini option to set a delay so try to set it higher than default and see what happens.
for serial port , use a usb kabel for data
This needs a few creature comforts for sure. an LED maybe that tells what mode its in, and one that shows that its actually imaging a drive.... A display would actually be better :)
5:55 backferd termination power... Alrighty then. Most of us are probably very very rusty on arcane SCSI non-standards and termination voodoo. I do recall vague memories of SCSI hell with various devices, computers and interfaces disagreeing on active/passive /other termination. Maybe you can refresh us on all varieties of SCSI termination concepts and why it is even an issue for scsi but apparently not other busses?
I have had a few of those little drive power supplies fail on me,they don't seem ultra reliable. The conductors in the cable are tiny.
09:30 when you say "is actually going to my scan converter" ... it's the OSSC or another one? If it's the OSSC I would love to know how you manipulate it via com port
On the pi pico W the GPIO pin for the onboard LED is connected to the wifi chip not pin 25 as on the plain pico
Are you sure the earlier problems with the HDD's weren't due to the cheapo hard driver power supply you were using? Might be worth retrying with the big old AT power supply that you used at the end, since I've had various problems with those hard drive power supplies that come with a IDE-USB adapters.
It occurs to me that the drives where it begins to have read errors may be trying to read from areas that were previously marked bad from low-level format
I’m surprised you didn’t try setting the drives to ID1? IME as a Mac tech in the 90’s, we always set hard drives to 1 or 2 and then CD drives to ID3. Any additional hard drives would be ID4+.
You need to post the Manf. dates of the drives also, SCSI was around for a LONG time, even on the same pinset.
I just watched a UA-cam video about USB-C cables. Apparently, cables can be configured with more or less connections. There are 5V cables, and cables with all the bells & whistles wiring in them, that are far less flexible/bendy.
I’m irritated that Adrian can get NO info out of the Pico USB serial port - and wonder whether it’s a USB-C cable issue?
I.e. - is Adrian using the wrong USB-C cable?
Just a thought.
However, REALLY interesting video, as I have some old SCSI drives from OLD macs, and will be buying a BlueSCSI shortly.
Certainly worth trying the tests again using the ATX supply. The smaller brick supplies are often not clean, and sometimes awfully regulated.
Matt
I have some 7 or more SCSI disks that almost certainly have been used in RAID-5 combo. Your BlueSCSI interface seems to be 50-pin, if I can deem from the video. My SCSI drives are Ultra-SCSI, with 68 pin connectors, although I also have saved some from my own PC in the old days, before the IDE onslaught. These latter ones were with 50-pin connectors. So, my thoughts started to fly when seeng this video. Could I possibly…..?
Wonder if some of your drives that did not work might be drawing more power. Have you tried them on the atx supply?
Mayhaps i'm going crazy but this video had a lot hard cuts during dialog, doesnt it? Besides from that - kinda interesting having this backup-mode for these old drives.
The dual imaging is due to the hardware in the drive. Did they all re-read at 0? Almost like a reset line?
I know this video is intended as an exploration of the BlueSCSI, however in general I'm skeptical of "black box" imagers with little-to-no real-time feedback. Personally, as I don't have any professional tools, I use ddrescue as the next best thing. Its tunable algorithm does a bulk sweep of the drive and notes problem areas, which it then revisits using different techniques to get out as much data as possible. Its operation is also able to be monitored using a graphical tool, so you can visually see when it's struggling to get any further data out and manually interrupt it.
Edit: it's vs its... gets me every time.
Thinking about this further, if BlueSCSI could implement the ddrescue algorithm and provide a similar monitoring system it *could* be ideal. One of the biggest problems with ddrescue is when the controller locks up. This often requires manual intervention to power cycle devices then restart ddrescue, instructing it to continue where it left off or jump over a problem sector. As BlueSCSI could be designed to have total control over the interface hardware it could perform these hardware operations automatically.
SGI computers would default to SCID0 for the controller. The real solution here is to have the bluescsi find a serial number or something on the drive to determine if the device happens to listen to multiple addresses. This will work until you get to a point where a hardware RAID controller would be offering different volumes on different SCSI IDs but give the same serial and device information.
oh dear god, look at the video at 42:13.... the ribbon cable is not crimped into the connector properly on the pin 1 side....
I think it's OK, just uneven cut. I think these were hand made in a previous video.
A quick hint for whoever is writing the software. That LED on the Pi could be used to blink morse code status and error codes. It would at least give a clue as to where in the process the thing is.
I must be missing something with the PCIe SCSI adaptors.
There's a reason that the phrase "SCSI Voodoo Magic" is used around terminating and cabling SCSI HD's.
Used to be a master of that Black Art with many generations of Mac's.
Firewire fixed all that, but now Apple and Sony have dropped it for USB (which has it's own issues... Version 1.1, 2., 3. etc... Mini/Micro B connector, USB-C, Thunderbolt, etc.... All still light years beyond Parallel and RS-232 and all the early buss's)
15:44 ACT light is blinking on the board
The amiga drive is likely partitioned, each partition may a LUN on scsi ID .
Partitions and LUNs are very different things. Very few drives had the capability of responding with a LUN ID other than 0.
Nice feature, but an LCD would be handy for status reports. Anything with a serial console will be bulky.
I dunno if it's related, but the SCSI CD-ROM drive I use with my A1200 will only work if set to ID 7, it has a small dial on the back of the drive to select ID, rather than jumpers.
Please check if your 5 pin cable allows data transfer. I think that's the reason why the serial connection wasn't working.
Feature request: have the BlueSCSI emit audio replicating the racket the original SCSI HDs made!
We have a noise maker called Beleths Drum :) Google it plus bluescsi to see it in action
I like the desktop background with the DeLorean. Too bad the instrument cluster is completely wrong. :)
Wait why does the Pico's LED need to be blinking when they've built an "ACT" LED onto the board next to "PWR"? And why isn't that LED actually working either, if the unit is actually doing the thing?
The problem I had with getting the COM [n] to get through the pico was using a USB micro with power AND data capabilities. Apparently the cheap ones from the corner store only charge devices!
Is it not possible to do this with the DB25 version of the BlueSCSI?
I probably tested the HDD in the ATX power supply, this old HD need a loot of power. ( not knowing what is the consumption off bluescsi "assuming 1w , 0.5 for the pico and other 0.5 for the rest"
Searching in google some SCSI are 900ma in 5v and 1,5a in 12v an other's only put 13w.