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.
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.
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.
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!
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 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.
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.
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 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.
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.
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.
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!
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.
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.
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
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!
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.
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 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
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.
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!
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.
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.
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.
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.
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.
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 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
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.
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.
@@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.
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.
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.
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.
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.
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 :)
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 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.
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.
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.
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
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 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.
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)
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.
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.
One thing to remember about Zip drives is if the disk is not reading or recognising properly, it could also just be that the disk is borked rather than a failed PSU, my venture into Zip disks I found the disks I got in my ebay purchase were all ruined from poor storage and they had mould on them, so they would never work and just gave the COD issues, but, some shiny new still sealed disks, worked perfect, apart form on one drive but I think that drive is just dead...
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.
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 just watched a TH-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 had the SCSI Zip drive for use with my Mac LC475 and first PC. My PC only friends with parallel port versions of the Zip drive were amazed at the speed difference between the two. That was before "the click of death" happened to the drive.
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’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+.
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?
yes, similar issues are present with the initiator mode of the ZuluSCSI. I had much better success with just attaching SCSI disks to a regular Linux machines and dump the disks with just dd.
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.
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
Ha! I went through the exact same baffled process. Pico W (USB C version) no blinking LED. I thought it just didn’t work. Then I realised it had dumped some images anyway. A half sized image from a plug-pulled attempt and a full one. Mine succeeded though. A 40Mb Macintosh drive which took seconds! You should get WiFi with DaynaPort working next. (That works too, with less bemusement and way more wonder!)
Blue SCSI, great, termination allmost always necesary with the wide variety of devices. What this device doesn´t cover are 50 or 58 wide scsi devices ? SCSI at severe level still might excist, mac older probalby, 25 Pin with ZIP´s, HD
Hi Adrian, it happens extremely rarely, but I caught an error ;) . The IDE Zip drives do not work with (modern) USB to IDE adapters. I spent years looking for a compatible one, only found one, from the 90’s. Any and all adapters that also support SATA, do not allow the Zip to work. During research, I found out that the cause is the protocols used. The Zip is ATAPI and apparently that’s a variant of scsi over an ATA connection ???? Could be a fun deep dive video ;). Thanks again for a very insightful video, looking forward to the next one!
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.
So, am I correct is saying the Bluescsi does NOT save files as executables, like you would find on a floppy or scsi device? So dumping the contents will convert the original files to some kind of bluescsi files? This seems to be much like using the floppy emulator devices where the files MUST be played on the floppy emulators, so the files on the bluescsi cannot be used on anything but a bluescsi device, do I have that correct?
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 don't think the "dual images" bug had anything to do with the SCSI drives. I can't imagine a scenario where a drive controller (the controller board on the disk) would respond to both ID 0 and ID 7, much less being able to function if it had such a peculiar fault. Pretty sure it's an issue with the BlueSCSI. I was surprised to see it work with removable disks, especially since you powered on the BlueSCSI before inserting a disk. I would have expected it to scan the drive, receive a "not ready" error, and then proceed to the next ID. However, the giveaway came at the end, when it ejected the Zip disk; this thing clearly has specific support for removable media.
When the BlueSCSI is reading the drive from ID 7 it changes its own ID to ID 0. This causes an addressing conflict when the drive is also set to ID 0. I don't know all the details of how SCSI works but perhaps the drive is responding because the "from" address matches its own. The way to test this is to set the drive to ID 7. I'm guessing this would give you 8 copies of the image.
When you have enthusiast projects, you have to expect "not ready for prime time" software. You have to realize these people are working on this without being paid. They are doing it because they love it. You definitely have to give these guys a pass. Because there is professionally developed software that you have to pay for, that isn't any better.
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 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.
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
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.
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
![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.
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.
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.
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.
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....
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 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!
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.
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 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.
Thank you for the detailed testing of this feature, this will be very helpful to the Digital Preservation community!
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.
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.
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!
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.
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.
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
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!
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.
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 :)
Holy smokes, I have a BlueSCSIv2 and I had no idea this was a thing!
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
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.
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!
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.
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.
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.
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'...
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.
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.
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 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
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.
That's a really neat feature of those SCSI emulator devices! Super neat devices!
It's much easier on the PiSCSI. Great to see the video and as usual covered very well.
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.
Great Video. Small tip: standard multimeter probes fit perfectly in the Molex connectors and might be a little safer :)
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.
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.
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.
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.
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.
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 :)
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 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.
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.
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
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.
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
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.
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 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.
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 like the desktop background with the DeLorean. Too bad the instrument cluster is completely wrong. :)
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.
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.
One thing to remember about Zip drives is if the disk is not reading or recognising properly, it could also just be that the disk is borked rather than a failed PSU, my venture into Zip disks I found the disks I got in my ebay purchase were all ruined from poor storage and they had mould on them, so they would never work and just gave the COD issues, but, some shiny new still sealed disks, worked perfect, apart form on one drive but I think that drive is just dead...
Did you try reading the big drives using the bigger 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.
Separate power supplies work fine, as long as you common the grounds. 49:01
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 just watched a TH-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 had the SCSI Zip drive for use with my Mac LC475 and first PC.
My PC only friends with parallel port versions of the Zip drive were amazed at the speed difference between the two.
That was before "the click of death" happened to the drive.
I remember the click of death...
Maybe those few HDDs, which fails on initialization had the same power issue as that SyQuest, did you try them with PC power supply?
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’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+.
Their extraction mode needs to be more like ddrescue. The norm of this thing will be old unreliable disks and the expectation is that it'll work.
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?
yes, similar issues are present with the initiator mode of the ZuluSCSI. I had much better success with just attaching SCSI disks to a regular Linux machines and dump the disks with just dd.
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.
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.
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
Ha! I went through the exact same baffled process. Pico W (USB C version) no blinking LED. I thought it just didn’t work. Then I realised it had dumped some images anyway. A half sized image from a plug-pulled attempt and a full one. Mine succeeded though. A 40Mb Macintosh drive which took seconds!
You should get WiFi with DaynaPort working next. (That works too, with less bemusement and way more wonder!)
Wonder if some of your drives that did not work might be drawing more power. Have you tried them on the atx supply?
On the page when you updated the firmware, it mentioned that one change was disabling the onboard LED in the Pico W.
The dual imaging is due to the hardware in the drive. Did they all re-read at 0? Almost like a reset line?
Blue SCSI, great, termination allmost always necesary with the wide variety of devices. What this device doesn´t cover are 50 or 58 wide scsi devices ? SCSI at severe level still might excist, mac older probalby, 25 Pin with ZIP´s, HD
That's how I would have setup SCSI in the past, the card at ID 0 and the drives down the chain. That way the card is always hit first in the cycle.
The cycle that the initiator itself is driving?
Hi Adrian, it happens extremely rarely, but I caught an error ;) . The IDE Zip drives do not work with (modern) USB to IDE adapters. I spent years looking for a compatible one, only found one, from the 90’s. Any and all adapters that also support SATA, do not allow the Zip to work. During research, I found out that the cause is the protocols used. The Zip is ATAPI and apparently that’s a variant of scsi over an ATA connection ???? Could be a fun deep dive video ;). Thanks again for a very insightful video, looking forward to the next one!
Might be worth trying the adapter boards from older external CD rom drives, since IDE CD drives also use ATAPI.
@@petermichaelgreen Yes, sorry, theoretically those should work, but I never got my hands on one as I was looking for a smaller solution ;)
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.
The Pico W has the blinky led on a different spot and the firmware should take this into account.
So, am I correct is saying the Bluescsi does NOT save files as executables, like you would find on a floppy or scsi device? So dumping the contents will convert the original files to some kind of bluescsi files? This seems to be much like using the floppy emulator devices where the files MUST be played on the floppy emulators, so the files on the bluescsi cannot be used on anything but a bluescsi device, do I have that correct?
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 had that blue Zip drive as my old job that was USB. You should find one of those.
I don't think the "dual images" bug had anything to do with the SCSI drives. I can't imagine a scenario where a drive controller (the controller board on the disk) would respond to both ID 0 and ID 7, much less being able to function if it had such a peculiar fault. Pretty sure it's an issue with the BlueSCSI.
I was surprised to see it work with removable disks, especially since you powered on the BlueSCSI before inserting a disk. I would have expected it to scan the drive, receive a "not ready" error, and then proceed to the next ID. However, the giveaway came at the end, when it ejected the Zip disk; this thing clearly has specific support for removable media.
When the BlueSCSI is reading the drive from ID 7 it changes its own ID to ID 0. This causes an addressing conflict when the drive is also set to ID 0. I don't know all the details of how SCSI works but perhaps the drive is responding because the "from" address matches its own. The way to test this is to set the drive to ID 7. I'm guessing this would give you 8 copies of the image.
When you have enthusiast projects, you have to expect "not ready for prime time" software. You have to realize these people are working on this without being paid. They are doing it because they love it. You definitely have to give these guys a pass. Because there is professionally developed software that you have to pay for, that isn't any better.
I decided to name my dog SCSI "Scuzzy". Perfect timing!
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 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.
I must be missing something with the PCIe SCSI adaptors.
Nice feature, but an LCD would be handy for status reports. Anything with a serial console will be bulky.
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 always use ddrescue to image old drives like these, and I guess you should be able to do that with this device in a modern computer.
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.
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