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 :) )
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.
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!
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 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!
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.
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.
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 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 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.
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 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
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.
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.
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!
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
@@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.
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.
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.
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 TH-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.
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
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
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.
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.
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.
I must re-watch this.. but I couldn't figure out if it supports 1024-byte long sectors. Not all SCSI emulators do. My minicomputer uses 1024-byte sectors (512 is what's mostly used elsewhere). As for SCSI host ID.. there were systems out there where the host ID would be zero and 7 was used for a regular disk.
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.
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.
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?
why the WIFI version, and when was the last time SCSI drive was made with status LED, the there not exactly the normal the so unless the SCSI with a LED that flash for data actively and not just its power on? HOW ARE YOU MEANT NOW ITS DOING ANY THINK ?
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.
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!
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.
I wonder if some of the issues could be due to a SCSI version mismatch, from memory SCSI 2 suppose more ID than SCSI1 (0-7 vs 0-15) and possibly some commands do not answer in the way the BlueSCSI expect them to reply.
Where would I go to have three Macintosh PM9500 SCSI drives and about 70 Apple II floppy discs imaged? I would hate to lose all those old games and shareware I had.
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 am desperate. I need to pull a few old resumes off of Amiga SCSI drives. Can I use this solution to spool the data off to SDHC or microSD cards? (I can check the SDHC for the files if I can just get all the data.)
making two backup copies at the same time if time not thing that seam like good idea? (your backing up data more than likely failing media in a format you can not read, making at least two copies, and doing just what you did check two agents each over, any getting result of they are the same? would be interesting if the BLUEscsi could do this it's self write report file how it went, and failing to get match, an option start over, do second or third time, until it gets a match, or runs out SD card place? but the out of anything happening ome at least one led light or something?
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?
Sorry if this has alrready been asked, but does the external LED indicator work forcstatus? Or is it directly tied to the Pico? I ask as I always hook that up to the front panel on (for instance) a Mac SE.
I have an Atari STE and a Proline SCSI hard drive case with a broken hard drive. Would the BlueSCSI 2 Desktop 50 pin version replace the broken drive in this case? I still have the cable from the computer to the case and the ribbon cable in the case. The case power supply etc still seem to work. I have an SD4ST and it works well but it blocks access to the external floppy drive socket.
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.
When it freezes, it's probably a termination problem. I see the exact same problem on modern scsi pcie cards, when there is the wrong/bad Terminator connected to the bus, it just freezes when booting and trying to scan for devices
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.
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…..?
concerning the second image: if you look at the 'Date modified' it's exactly the same time as the first image. Could it be that the BlueSCSI detects itself (the 1st HDA image) as a second hard drive and then copies the contents?
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.
What happens if you let one ZIP eject and then put another one in, does it make a new image on the next disc? That would be cool as you could just make individual images of a stack of Zip discs by just inserting each disc after the previous one is ejected.
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.
I wonder if it's possible to take these images and use them with emulators. It would be nice for example to take an old Amiga hard drive image and boot it in WinUAE.
Why is the BlueSCSI using ID0 and also imaging a disk at ID0 ? Either it is a drive or it is mimicking the controller. Not both... Also that collides with the disk at ID0...
The issue is when you send enter the SELECTION phase you send one byte of the target and the initiator (thats it) - so when you select target 0 and initiator 7 it is 1000001 - and when you select target 7 with initiator 0 it's 1000001 (again!) so the drive says "ok you selected me again, lets go! - but thats not what we meant to do. I've got a fix for the next release.
@@helfire23 Ahh! Brilliant! I was wondering where in the protocol it was. So it is a bit level thing. So in essence the drives that get confused may be the SCSI-1 devices that do not do arbitration? In non-arbitration mode it appears the initiator id bit is optional (and I assume optional could mean their implementation might not bother with handling it?).
Why doesn't anyone make a simple, straightforward adapter for 50-pin (IDC) SCSI drives (and other devices) to USB or at least a converter to SATA??? 🤔 Yes, Adaptec USB2XCHANGE did exist, but it is now only history. I have an old Quantum Pro Drive LPS 540 S hard drive that I would like to connect normally to another PC. It works fine on the original IBM Model 77i. But if I connect it to another motherboard with an Adaptec AHA-2940AU, it doesn't work. The BIOS sees it, Win98 and WinXP see it too, but it always stops spinning. I only see its ID position and basic info in Device Manager.
I think if the drive is dying they do spin down and up. I had a 50pin SCSI HD that did just that and later on that mechanism just died, The one I had on my CMD HD series it was a 2gig
My suspicions as well. I came across 1 or 2 of these in my box of cables in the past and immediately tossed them in the trash. Hard enough troubleshooting something not knowing you've been sabotaged from the start.
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.
![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!
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.
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....
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 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!
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 :)
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.
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!
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 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.
Love using multiple picos to emulate parts of a machine that one pico is faster. BRILLIANT!
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 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
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.
That's a really neat feature of those SCSI emulator devices! Super neat devices!
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.
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!
Holy smokes, I have a BlueSCSIv2 and I had no idea this was a thing!
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.
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.
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.
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.
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!
It's much easier on the PiSCSI. Great to see the video and as usual covered very well.
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.
love this i hope in some point will be able to support scsi 68 pin
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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 TH-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.
Great Video. Small tip: standard multimeter probes fit perfectly in the Molex connectors and might be a little safer :)
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.
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
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
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 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.
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.
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.
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'...
I must re-watch this.. but I couldn't figure out if it supports 1024-byte long sectors. Not all SCSI emulators do. My minicomputer uses 1024-byte sectors (512 is what's mostly used elsewhere).
As for SCSI host ID.. there were systems out there where the host ID would be zero and 7 was used for a regular disk.
More power, Scotty.
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.
Did you try reading the big drives using the bigger power supply?
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.
On the page when you updated the firmware, it mentioned that one change was disabling the onboard LED in the Pico W.
Maybe those few HDDs, which fails on initialization had the same power issue as that SyQuest, did you try them with PC power supply?
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.
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?
why the WIFI version, and when was the last time SCSI drive was made with status LED, the there not exactly the normal the so unless the SCSI with a LED that flash for data actively and not just its power on? HOW ARE YOU MEANT NOW ITS DOING ANY THINK ?
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.
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 must be missing something with the PCIe SCSI adaptors.
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.
What about other devices that use SCSI? Will they work? Scanner for example?
I wonder if some of the issues could be due to a SCSI version mismatch, from memory SCSI 2 suppose more ID than SCSI1 (0-7 vs 0-15) and possibly some commands do not answer in the way the BlueSCSI expect them to reply.
Where would I go to have three Macintosh PM9500 SCSI drives and about 70 Apple II floppy discs imaged?
I would hate to lose all those old games and shareware I had.
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 am desperate. I need to pull a few old resumes off of Amiga SCSI drives. Can I use this solution to spool the data off to SDHC or microSD cards? (I can check the SDHC for the files if I can just get all the data.)
making two backup copies at the same time if time not thing that seam like good idea? (your backing up data more than likely failing media in a format you can not read, making at least two copies, and doing just what you did check two agents each over, any getting result of they are the same? would be interesting if the BLUEscsi could do this it's self write report file how it went, and failing to get match, an option start over, do second or third time, until it gets a match, or runs out SD card place? but the out of anything happening ome at least one led light or something?
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?
15:44 ACT light is blinking on the board
Separate power supplies work fine, as long as you common the grounds. 49:01
Fun video. Thank you.
Please check if your 5 pin cable allows data transfer. I think that's the reason why the serial connection wasn't working.
Sorry if this has alrready been asked, but does the external LED indicator work forcstatus? Or is it directly tied to the Pico? I ask as I always hook that up to the front panel on (for instance) a Mac SE.
I have an Atari STE and a Proline SCSI hard drive case with a broken hard drive. Would the BlueSCSI 2 Desktop 50 pin version replace the broken drive in this case? I still have the cable from the computer to the case and the ribbon cable in the case. The case power supply etc still seem to work.
I have an SD4ST and it works well but it blocks access to the external floppy drive socket.
Is it not possible to do this with the DB25 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.
When it freezes, it's probably a termination problem. I see the exact same problem on modern scsi pcie cards, when there is the wrong/bad Terminator connected to the bus, it just freezes when booting and trying to scan for devices
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.
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…..?
concerning the second image: if you look at the 'Date modified' it's exactly the same time as the first image. Could it be that the BlueSCSI detects itself (the 1st HDA image) as a second hard drive and then copies the contents?
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.
What happens if you let one ZIP eject and then put another one in, does it make a new image on the next disc? That would be cool as you could just make individual images of a stack of Zip discs by just inserting each disc after the previous one is ejected.
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.
Wonder if some of your drives that did not work might be drawing more power. Have you tried them on the atx supply?
I wonder if it's possible to take these images and use them with emulators. It would be nice for example to take an old Amiga hard drive image and boot it in WinUAE.
I think he showed that exact thing in 2922- look for his "using 90's tech to connect scsi devices to modern computers in 2022" video
Why is the BlueSCSI using ID0 and also imaging a disk at ID0 ? Either it is a drive or it is mimicking the controller. Not both...
Also that collides with the disk at ID0...
The issue is when you send enter the SELECTION phase you send one byte of the target and the initiator (thats it) - so when you select target 0 and initiator 7 it is 1000001 - and when you select target 7 with initiator 0 it's 1000001 (again!) so the drive says "ok you selected me again, lets go! - but thats not what we meant to do. I've got a fix for the next release.
@@helfire23 Ahh! Brilliant! I was wondering where in the protocol it was. So it is a bit level thing.
So in essence the drives that get confused may be the SCSI-1 devices that do not do arbitration? In non-arbitration mode it appears the initiator id bit is optional (and I assume optional could mean their implementation might not bother with handling it?).
Why doesn't anyone make a simple, straightforward adapter for 50-pin (IDC) SCSI drives (and other devices) to USB or at least a converter to SATA??? 🤔 Yes, Adaptec USB2XCHANGE did exist, but it is now only history. I have an old Quantum Pro Drive LPS 540 S hard drive that I would like to connect normally to another PC. It works fine on the original IBM Model 77i. But if I connect it to another motherboard with an Adaptec AHA-2940AU, it doesn't work. The BIOS sees it, Win98 and WinXP see it too, but it always stops spinning. I only see its ID position and basic info in Device Manager.
I think if the drive is dying they do spin down and up. I had a 50pin SCSI HD that did just that and later on that mechanism just died, The one I had on my CMD HD series it was a 2gig
wonder if the reason the USB over serial didn't work was because of USB cable being a power only micro b cable. 🤔
My suspicions as well. I came across 1 or 2 of these in my box of cables in the past and immediately tossed them in the trash. Hard enough troubleshooting something not knowing you've been sabotaged from the start.
@@xredhead7135x is a pain, I spent hours tossing data only usb cables.
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.
You need to post the Manf. dates of the drives also, SCSI was around for a LONG time, even on the same pinset.