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 :) )

@adriansdigitalbasement2

3 ай бұрын

Of course! Hopefully more people can test this so we can get an even larger dataset!

@glonch

3 ай бұрын

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.

@helfire23

3 ай бұрын

Fixes are now in the "Nightly" release. Pico-W LED/Serial, Logging, Double Image, etc.

@glonch

3 ай бұрын

Awesome!! @@helfire23

@adriansdigitalbasement2

3 ай бұрын

@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.

@111smd

3 ай бұрын

that is what i was going to say

@316diag

3 ай бұрын

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.

@AndyAKratz

3 ай бұрын

This ^ and what others here pointed out. I can't tell you how many times the guy who handled the inventory at an old computer shop would order the external HDD adapter over and over again simply because the USB HDD adapters were good, but those A/C adapters they provide are JUNK! I no longer trust those bricks and ALWAYS use a dedicated AT or ATX power supply when using them to eliminate any possible power fluctuations. I hate to say it, but don't rely on those A/C adapter power supplies they include or you're just asking for a bad time.

A thought; you may have already tried it, but maybe worth retesting the drives that failed with that ATX power supply. Just incase the drives drag one of the rails down enough to crash the pico and stop it logging anything. A spin-up-related drain on the 12v could affect the 5v and in turn the 3.3V powering the pico. A really curious individual might stick a scope on 5V to watch for dips or ripple.

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.

@Davemte34108

3 ай бұрын

Yes, that is my memory of helping customers with this drives as well.

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.

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!

@Davemte34108

3 ай бұрын

Yeah, that was driving me nuts. He does good videos and I like him, but sometimes....

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.

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!

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.

@andrewlittleboy8532

3 ай бұрын

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.

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.

@nickwallette6201

3 ай бұрын

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.)

@Qyngali

3 ай бұрын

@@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.

@nickwallette6201

3 ай бұрын

@@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.

@Qyngali

3 ай бұрын

@@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.

That's a really neat feature of those SCSI emulator devices! Super neat devices!

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.

@argvminusone

3 ай бұрын

I think the EZ-Drive didn't catch on because CD-RW arrived only a couple of years later.

@DwellerBenthos

3 ай бұрын

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.

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.

@pelculator

3 ай бұрын

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)

@nickwallette6201

3 ай бұрын

@@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.

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 am also very satisfied with the initiator mode of BlueSCSIv2. With this I was able to read most of my SCSI disks from old Unix workstations. It is important that the power supply for termination (TERM_POWER) only comes from one source. But to connect SCSI disks to a modern computer, I recommend the SCSI adapter "LSI SCSI Ultra-320 Controller LSI20320IE". It is a PCIe card for which there are signed drivers for Windows 7, which also work without any problems under Windows 10 and of course also for Linux. With an appropriate adapter, you can also connect ancient SCSI1 devices to this ultrawide SCSI card.

So amazing to have an open source project that offers so many features for emulating and archiving SCSI drives. KUDOS to the hard working people on this project!

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.

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.

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.

@helfire23

3 ай бұрын

Oh... i like this - will give it a try :)

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 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.

@me15.738

3 ай бұрын

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

It's much easier on the PiSCSI. Great to see the video and as usual covered very well.

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.

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!

@rutabagasteu

3 ай бұрын

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.

@whomigazone

3 ай бұрын

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.

@whomigazone

3 ай бұрын

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.

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.

@ickipoo

3 ай бұрын

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.

Great Video. Small tip: standard multimeter probes fit perfectly in the Molex connectors and might be a little safer :)

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

3 ай бұрын

When you were using Linux, did you use ddrescue as your image software or plain dd?

@tommythorn

3 ай бұрын

@@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).

@ffsireallydontcare

3 ай бұрын

@@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.

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.

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.

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.

@helfire23

3 ай бұрын

Yep! this makes it frustrating to deal with.

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.

Holy smokes, I have a BlueSCSIv2 and I had no idea this was a thing!

More power, Scotty.

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.

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'...

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.

If you're worried about issues with backfeeding, you can get a USB cable and cut the 5V wire, but keep ground, D+ and D-, it should work fine with a device that has it's own power. Found this by accident with a cheap USB hub with power switches for each port, that just disconnect the 5V line for that port. If I connect a cable from the hub to my MiSTer's serial port and leave that port on the "off" position, it still shows up on the computer when I power up the MiSTer.

The 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.

Adrian, you don’t have an Adaptec AHA1542B? That was THE SCSI host adapter back in the day!

@Jackpkmn

3 ай бұрын

AHA2940 owner chiming in, it also works great for imaging these old drives.

@pgriggs2112

3 ай бұрын

@@Jackpkmn Wait, was that the VLB version?

@Jackpkmn

3 ай бұрын

@@pgriggs2112Naw it's PCI.

@pgriggs2112

3 ай бұрын

@@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.

@tommythorn

3 ай бұрын

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.

Fun video. Thank you.

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.

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.

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.

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.

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.

Maybe those few HDDs, which fails on initialization had the same power issue as that SyQuest, did you try them with PC power supply?

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 :)

On the page when you updated the firmware, it mentioned that one change was disabling the onboard LED in the Pico W.

Did you try reading the big drives using the bigger 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.

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

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!)

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.

@ffsireallydontcare

3 ай бұрын

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.

Feature request: have the BlueSCSI emit audio replicating the racket the original SCSI HDs made!

@helfire23

3 ай бұрын

We have a noise maker called Beleths Drum :) Google it plus bluescsi to see it in action

I like the desktop background with the DeLorean. Too bad the instrument cluster is completely wrong. :)

I just watched a KZread 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

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)

A quick hint for whoever is writing the software. That LED on the Pi could be used to blink morse code status and error codes. It would at least give a clue as to where in the process the thing is.

I 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.

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.

Separate power supplies work fine, as long as you common the grounds. 49:01

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’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+.

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

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.

@eDoc2020

3 ай бұрын

Yeah, you're mostly wrong. Unless power supplies are specifically designed to be run in parallel you should not run them in parallel. If both supplies are not perfectly matched you could cause backfeed currents. A pair of diodes (in a diode-OR configuration) isolates both supplies and prevents any possible backfeed.

I 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.

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.

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...

I never used SCSI back in the day, but any chance that there’s a cable select? So having the BlueSCSI connected to what I would call the drive end with the 2 connectors close to each other is causing the issue?

@nyckid

3 ай бұрын

Only IDE had the cable select feature.

@leighbellouny3904

3 ай бұрын

@@nyckidI knew IDE did, thank you for clarifying for SCSI

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.

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.

The amiga drive is likely partitioned, each partition may a LUN on scsi ID .

@wbfaulk

2 ай бұрын

Partitions and LUNs are very different things. Very few drives had the capability of responding with a LUN ID other than 0.

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.

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…..?

Just curious if you tried doing a image copy using linux and dd ??

It kinda sounds like the firmware crashed when trying to image sector by sector with the way the log abruptly ends. Issues aside, this BlueSCSI is pretty neat.

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

I had that blue Zip drive as my old job that was USB. You should find one of those.

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.

Pretty sure you need a driver for the Pico COM over USB to work. At least I remember installing one.

one thought. make sure you have the serial driver for the USB UART. not sure which one is on that board, but the FT232 and CP2102 and CH340 are all out there and sometimes I have needed to install a driver when using different boards.

@awd42

3 ай бұрын

Without the drivers, it should still show up in device manager as an unknown USB device, or as an identified but not-working device, but it didn't show up at all for Adrian. Seems to be a known issue with the current firmware and the WiFi Pico, which they hope to fix in the next version.

I decided to name my dog SCSI "Scuzzy". Perfect timing!

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.

You need to post the Manf. dates of the drives also, SCSI was around for a LONG time, even on the same pinset.

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.

@eDoc2020

3 ай бұрын

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.

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.

@RG-gk4yi

2 ай бұрын

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

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.

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.

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.

The dual imaging is due to the hardware in the drive. Did they all re-read at 0? Almost like a reset line?

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?

The Pico W has the blinky led on a different spot and the firmware should take this into account.