@@Flofutz This made me laugh harder than it should have. I am going to save this for the future to tell to my tech buddies. Thank you for such an oh so true joke.
Atari's Serial I/O (SIO) bus was the USB of the '80s. It is credited as the basis of USB, allowing multiple peripherals to be accessed via a plug-and-play serial bus.
Agree but SIO was surely very similar for Atari, Commodore & Sinclair as all micros had a port that performed the function of a proto USB. Was it truly an Atari invention?
@@arostwocents Well the result was the same (you plug some stuff in and it works) but they were fairly different. The Commdore bus itself implemented a fairly simple interface, it had commands to tell a disk to listen or talk, then would send a command selecting which channel (each device had 15 or 32 channels). Everything on top of that was essentially ad-hoc, those making a Commode-compatible drive either had to reverse engineer the Commodore ROM or just copy it (in recent times, it's been found that many just copied it and swapped some instructions around a bit to try to obfuscate it.) In contrast, the SIO bus used a "command" pin, when that was pulled all devices would listen for a command. A 5-byte command was sent (1st byte is the device number, second is the command, 3rd and 4th could include data, like a sector number for a "read sector" command, and the 5th a checksum.) The device would send back a single-byte acknowledge (or negative acknowledge) along with sending or receiving a block of data as the case may be. It had a pre-defined set of commands to cover floppies, printers, serial devices, and casette drives and they were documented well enough that one could implement a compatible device just by following the SIO documentation. The OS also had a design that made it easy to extend existing device handlers and add new ones. That's what inspired USB. Electrically the bus was nothing unusual (although it was hot pluggable.) And having extensively documented specs was not unusual on large systems (over the years IBM has loved having thick thick manuals describing every aspect of the hardware internals). But having a small system, hot pluggable plugs, and enough protocol documentation so 3rd parties could easily make devices that follow the spec? That was rather unusual.
Apple had that port that could be used to plug up modems, printers, external drives even, with no drivers (that I recall)…. ADB I think it was called, without googling it…. also basically a higher speed aerial port…
I work a fair bit with low-level linux kernel code. And have written my fair share of USB device gadgets. USB Mass-storage devices actually are totally handed off to the SCSI subsystem in the linux kernel. (most of them - i should note that not all mass-storage devices identify as SCSI!!!!) It's just that their read/write function pointers are replaced with usb control messages and bulk transfers handlers. A lot of USB in the linux kernel works this way - where once the USB device and descriptors are enumerated - it is handed off to the subystem that was abstracted by USB code.
Excellent detailed overview. One minor additional detail - for multi-initiator systems, the SCSI ID was used to indicate which device should be prioritised during the arbitration phase of a SCSI transaction. That's why there are only 8 IDs on an 8-bit bus - each device asserted the bit corresponding to its ID, allowing multiple devices to be uniquely detected.
I grew up with SCSI as I worked on Mainframes out of High School. SCSI was amazing compared to ATA, being able to have 16+ devices on a single chain was always amazing. It still gives me a little bit of glee working with SAS devices and saying the name Serial Attached SCSI out loud. SCSI still lives with us.
SCSI was good, but it could sometimes be a little challenging, especially when trying to diagnose why the chain of scsi devices you’ve just plugged in isn’t being picked up, only to find it’s not properly terminated, or you’ve got a bad cable. Admittedly that last bit was more rare. After all done computer cables in the 90s were so well built you could pretty much use them to haul yourself up instead of rope.
That said, my boss did set fire to go a scsi ribbon cable once. He plugged it in to a motherboard with onboard SCSI once. Slightly misaligned the pins. In the process he kill the motherboard, set fire to the cable and set off the smoke alarm. As this was wired into the building fire alarm, this took some explaining.
7:33 There actually is somewhat of a "standard" internal USB connection. It's the header on the motherboard that front panel USB is connected to. There are actually two, one for USB 2, and a different one for USB 3.
There is also a different internal header between 3.0 (blue plastic, like the usb2 header but twice the size) and usb 3.1 (metallic and actually looks like a miniature SCSI 2 port!)
Here's the one that will surprise you. The Yamaha PMD1 console used SCSI to interface their DSP angine, console and audio interfaces to each other. The longest SCSI cables were 100 meters long, to connect from.stage to other devices at front of house. There you go. I had learned about SCSI with my Amigas so was surprised to see SCSI with the consoles.
That would definitely surprise me. The longest cables you can use on High-Voltage Differential SCSI were 25 meters, the standard didn't support anything longer than that. Are you sure it wasn't some other type of cabling? MIDI, or something proprietary perhaps?
Many '80s/'90s samplers used SCSI. Many that used floppy disks also had slots to add a SCSI interface. Look at the Akai S-1000, E-Mu 6400, Roland S-550 or Yamaha EX5. By the late '80s everybody was using sample CDs (like the Zero-G CDs that were used in thousands of songs), and that was accomplished by plugging a SCSI CD-ROM into a rackmount sampler. I don't know anything about Yamaha consoles, but I assume that when Yamaha needed an interface for digital consoles, they used SCSI because it had been a standard in music production for about 15 years. The PM1D is a 1999 console, so that means that at the time it was released, Yamaha's flagship sampler was the EX5R which used SCSI.
In my first job, I designed SCSI peripherals (mainly tape streamers though blocked tape devices too) at a small British company. I then went on to become a Field Applications Engineer for SCSI devices looking after the Symbios Logic (ex NCR) range of chips and RAID controllers. I still smile when I see how USB, SATA and other interfaces have taken the SCSI command set and use that in their interfaces. The box at 6:30 looks very much like one of the ones we used for our products, including a parallel port to SCSI tape interface. There are some interesting points about SCSI which you didn't pick up in the video. Initiators were often left at ID7 because that was the highest priority ID (7 -> 0 then 15 -> 8). Better than that, when you mixed wide (16 bit) and narrow (8 bit) devices on the same bus, they could all still talk because they could all see ID7 and then would negotiate the width of communication. This made it great for customers who didn't have to go out and buy all new kit when they changed bus sizes. Also, related to the DMA aspect, is that once the initiator selected the target, it was the target that ran the show by choosing what was going to happen and when. Your computer would say "I want blocks 100-105" but the hard drive would be responsible for fetching the data, and then calling back the computer, for the transfer. Assuming that the computer was boss was an all-too-common fault in software driver design for SCSI devices, though it did get me a few all-expenses paid trips to nice locations fixing the problems 🙂
Thank you! I had plenty of SCSI peripherals including a Symbios controller, and that was brilliant indeed - super-fast and reliable, it even had removable terminator resistors on the card if I recall correctly. Brilliant stuff!
I love your enthusiastic narration. I had a lot of dealings with SCSI back in the day. It was a running joke in the sysadmin community that, as well as selecting the right ID and ensuring the correct termination, you also had to perform the correct ritual sacrifice of chickens/goats/etc to appease the SCSI gods and get your devices to work properly. In my first job looking after unix workstations I had to deal with about 5 different versions of the standard all in use concurrently. Most of them could be made to talk to each other but if LVD was involved all bets were off (maybe we just didn't have the right adapter...) One small correction: it's SyQuest (pronounced like the psy in psychology) not SysQuest.
Ah, I was about to make a remark about the sacrifices required to appease the SCSI gods. Real life story from my last gig where I had to deal with SCSI (or any hardware other than what is on or below my desk): one day my manager and team lead headed to the server room to install several SCSI devices to a box. I asked them whether they sacrificed a goat, or at least brought some black candles to light during the work. I was met by glazed eyes, them unaware of the SCSI gods. An hour later, they came out, defeated. "I told you so", I said. They then asked me to go in and give it a try, to which I succeeded. When they asked me how, I replied "We have some spare memory. I put it on top of the box and told it if it helped me defeat the SCSI gods and behave over the weekend, it could have that extra memory on Monday".
Another feature that SCSI had before IDE/SATA was command queing. This allowed the drive to optimize access to the disk. A big feature of SAS was the expanders, which allowed networks of drives to be attached (somewhat similar to FC). Your video was very interesting to me as I worked as a firmware engineer for enterprise disk drives and saw the transitions from SCSI-1 to SAS.
SAS is serial attached SCSI. he also said that SCSI drives worked at the same speed as IDE drives and it was the bus that was faster yes i agree but many SCSI drives and SAS drives spin at a Higher RPM going all the way up to 15krpm thats 15000 RPM i think i have some drives that may even go higher, thus making the SCSI drives even better, Also I still have a PCI-E adaptec SCSI controller for my server for my TAPE drives as if you want a backup TAPES are still a thing. Plus there is DSSI and i have one no controller tho just the hard drives.
@@spikeevans1488 yes its sad from what i seen anything past 900GB is just 7.2k but i have many still kicking and screaming that been said it was very common in the era of Ultra wide SCSI, That been said the platters where also 2.5" but still in the 3.5" on many of the SAS and Ultra drives.
IDE (or, more accurately, ATA) originally wasn't anything remotely like a competitor to SCSI. ATA literally means "AT Attachment", with AT referring to the IBM PC/AT of course. In its original incarnation it was little more than just a way to plug hard drives into the ISA bus almost directly. A far cry from SCSI which was intended as a cross-platform standard from the beginning - so they were very different beasts, even putting performance aside. ATA only became cross-platform many years later, around the mid-90s.
“IDE” in this context stands for “Integrated Drive Electronics”. That means any system where the disk controller was not a separate card, but integrated with the drive. This included SCSI, I think ESDI as well, and PATA and SATA. Before that you had things like ST-406 and ST-512 with a separate controller card.
Well, you could lterally implement that on any 16 Bit bus and it only needs la handful of TTL chips. Even saw some cards like this on the Amiga. But then it involves alot of babysitting the drive.
@@lawrencedoliveiro9104 No. IDE came first. ATA was a result of improvements to IDE and technically the interface should have been referred to as ATA but people still continued to use the old name IDE.
ATA was crap in all honesty. It was too simplistic an interface. Although multiple devices could be connected to it concurrently, you could only access one device at a time. And if the device took time to complete the operation requested, you could not go and access the other device during that time, thereby impacting performance massively if you mixed a high speed device with a slow speed device.
I've been using my home server nas thing with a sas hba as well as a striped pair of nvme because of zfs. I'm quite impressed that all of this technology is able to talk to ancient crap still, like a floppy drive I have in the same server. This is mainly because it's also my ingest machine for literally any generation of tech, and I have retro and new machines hooked up simultaneously. I'm glad this work was done so I can play with stuff that has no right being together.
We had a SCSI laser printer on our Mac IIcx when I was growing up. Printing was the only thing besides a hard lockup that could stop the cursor moving; normally cursor movement is such a high priority on old Macs it would always work smoothly no matter how busy the CPU was.
Having worked a bit with SCSI for about 25 years, I expected this to be just a nice nostalgic trip down memory lane (which it is). But I was completely unaware of Ultra640. And SCSI printers. And I learned of Adaptec's fate literally yesterday, while researching RAID options for a budget build-your-own server. Fantastic video, thanks! (Oh yeah, had a nice chuckle at the fudge.) I would only add that from about the mid-to-late 90s on, SCSI hard drives themselves were higher-performance than EIDE, separate from the interface. Just because SCSI drives were already chosen for performance, they had 7200 RPM spindle speeds when EIDE had 5400; then SCSI had 10,000 RPM and EIDE/SATA 7200, then 15,000 RPM for higher-performance SCSI (or was 15k after SAS took over?) SCSI hard drives also had 5-year warranties, compared to 3-year for IDE.
@@SomeMorganSomewhere15k drives are weird. I had some hard drives i hooked up to see if they spun up to see if they were any good. The centrifucal force on them is huge and hard to move them when spinning
As a Mac user from 1985 I got real good at building SCSI chains, sometimes one needed to get pretty creative; between devices with 2 DB or Centronic connectors (or occasionally one of each), the odd device with only one connector, and varying ways to set the SCSI ID and whether the chain needed to be terminated made for an interesting time. I had so many cables, with either type of connector or one of each again, it got pretty confusing unless you understood the craziness.
I remember my Computer Studies teacher teaching us about SCSI. At the time I was still 14 years old and had IDE disks and ATAPI equipped optical drives in my computer. Later on I got SATA based machines. I suspect that all these still use the SCSI command set since the linux kernel implements most IO as part of the scsi driver coupled with ata drivers (for ide/sata)
Another feature of SCSI was Native Command Queueing which greatly improved performance by allowing out of sequence I/O. SATA drives can now do that as well. SCSI drives also had higher spin speed that IDE - not because of the technology, but because they were higher priced enterprise drives and those drives were usually SCSI. While PC users thought 7200rpm was fast, at work we only dealt with 10k and 15k drives.
What I hate is having on-disk caches. The drive makers do it to look good in benchmarks. But the downside is your OS does a cache-flush, the drive reports back that the data has been written, but really those bytes are still sitting in RAM on the drive, and if the power fails within, say, the next fraction of a second, that data will be lost.
@@lawrencedoliveiro9104 I had a RAID card with batteries on it, to deal with its own cache RAM in the case of a power failure. The on-drive cache came along as well, as it kept power to the drives until it finished writing everything and confirmed a graceful shutdown of the drives.
@@JohnDlugosz Having cache on the drive is just the dumbest thing. Because remember, that’s on the wrong side from the CPU of an interface that was never designed to run at RAM speeds.
The interesting connection between the Atari ST and SCSI is that the ST has a "SCSI light" called ACSI (Atari Computer System Interface) or DMA. It was inspired by the SASI bus interface, but with less signals and a slightly modified protocol. Both to reduce the pin count on the connector and the command overhead. The ability to change the bus master was removed and the first command byte also contains the device address beside the command (3 bit device address 5 bit command). But because both busses where so similar, a bridge made from discrete logic could be designed. Atari itself made a reference design for that later on. A result of that was that the ST was one of the few computer systems who implemented their own custom SCSI hardware. (TT and Falcon used Adaptec chips) Sadly there was an oversight in the design of the DMA Chip that dives the ACSI bus. When the Byte transmit counter reaches zero the chip didn't stop sending or receiving data. The slave device has to initiate an interrupt so that the software on the ST can stop the DMA transfer. An Interrupt from the DMA Chip itself would have made the hardware implementation of the slave devices much easier.
There definitely is an internal USB standard, it's used for headers on motherboards which are usually used to pass through to front panel connectors but there is no reason they couldn't attach actual devices. In fact, in some cases they are used for that; some servers use internal USB drives as boot devices that plug directly into motherboard headers.
USB was inspired a lot by Atari's SIO (Serial Input/Output) from 1978. The video also reminds me of HP-IB (Hewlett-Packard Interface Bus), a late 1960's parallel bus allowing daisy-chaining, later standardized as the IEEE-488 GPIB (General Purpose Interface Bus). It was used for floppy and hard disks (e.g. by the Commodore PET and the HP-85), but mostly for lab equipment (oscilloscopes, logic analyzers, programmable power sources, digital multimeters...)
My school had a IEEE-488 interface for the BBC micro we connected up to a couple of bits of lab equipment we had. The only one I remember using was an oscilloscope, I used it as an audio sampler, as you could capture about 10 seconds of data.
I tied a PDP11/94 to a modern UNIX system over that interface in the early 90s. It was the ugliest kludge I'd ever seen as it had to go out of the PDP, into a short haul modem to a channelized T1 / DS0, over the WAN into another short haul modem until it terminated into a Digiboard external adapter before finally residing on an OS/2 Warp machine that actually listened for the reports. e.g. keeping the syncronous timing was no fun
USB is a host-based system where each device needs its own port. While the IEE488 and Atari's SIO are connected to a BUS in the form of a daysy chain. I.e. Atari's SIO is not related to USB, but to IEE.
Thanks for the memories. I spent 20 years of my career in storage connectivity. I left 5 years ago to get into cloudy containerised stuff. Great memories of parallel SCSI and the early days of Fibre Channel. You mentioned the standardisation of SCSI, the T10 and T11 standards docs were my bible. However the problem with standards was the interpretation especially with optional features and then there was IBM who just seemed to do their own thing. I used protocol analysers on both FC and parallel SCSI to work with vendors to overcome interop issues. Average interesting time. You also raised multi-initiator SCSI, this was very tricky to get right. Often used in highly available clusters. You are absolutely right that locking was key, much helped by the persistent reserve SCSI command.
We got our first home computer in the 80's. It was a 286-16 with a 80 MB SCSI drive. Still remember our neighbor could not fathom how the computer could access the hard drive without a specified hard drive in BIOS, as you usually would do with IDE drives, and they'd show up in the system summary.
That entirely depends on who you ask and when. Towards the end of their life as Adaptec, the OpenBSD project ended up dropping all support for their RAID cards because they couldn't get the documentation needed to work around the firmware bugs. Also have a chat with Nick Holland about his experience with Adaptec cards - at one point they sent him firmware that damaged his card after sixty days.
As far as SCSI controller cards with RAID support, Mylex Corp was way ahead of Adaptec. Mylex's biggest customers on RAID SCSI were IBM, HP, and DEC. IBM eventually bought Mylex. I worked for Mylex in the 90s and then at Adaptec in the early 2000s.
When I started building systems back in the 80's, SCSI was all we used. Mostly because of the ease of having multiple devices without having to worry about drivers and incompatibility issues, and there were plenty. Just plugged stuff in and it worked, all the time. Thanks for the memories.
Amazing video! I remember accidentally buying a SCSI Zip drive on accident for a big chunk of change and not being able to use it for six months when I could afford a controller.
I still have these bits of hardware floating around in my stacks-o-stuff... - SCSI Zip Drive. I remember it only had a choice of two IDs, the other switch was termination. - Adaptec ISA bus SCSI card, for use with external devices only. This combo was fast enough to record and play .WAV files with no hesitation, and when MP2/MP3 came along it absolutely rocked. - Roland VS-880EX Virtual Studio Workstation. I got the model with six inputs. This also had the ability to work with Iomega's Zip and Jaz drives, even in live recording. I did that once.
That was wonderful - brought back a lot of (rusty) memories. Great overview! As for odd SCSI devices, we designed a medical ultrasound scanner (16 bit wide) for it...
The USB 3.0 (USB 3.1 Gen1) specification added UASP (USB Attached Storage Protocol) for large mass storage devices like external HDDs and drive arrays. This uses the SCSI command set instead of Bulk Object Transfer (BOT).
@@eDoc2020 I think it doesn't support command queueing in the same way and just uses the command set. UASP, as I understand it, operates SCSI control tunnelled through the USB interface, and appears (at least on macOS where I've probed the hardware interface) as SCSI, though under the IOUSBMassStorageInterface
@@samuell.foxton4177 This is true with Windows as well. I use Ultrastar external HDD's in USB caddies and are seen by the system as USB Attached SCSI (UAS) as the controller and the disks are seen as SCSI Disk Device.
Usb has an inside the machine standard. USB1/2 is mostly just pins, but 3.0 has the blue plastic connector and thunderbolt has its own funky connector.
16:00 Fun fact Tape Drives are still used in modern times to Store comically large amounts data because they're high density and low cost. The Highest Capacity Tape Drive has a Native capacity of 18TB and can store 45tb of compressed data. These are usually used for long term Archives and Infrequently accessed data because they're excruciatingly slow.
@@lawrencedoliveiro9104 Not really. Tape drive compression (or at least LTO, Linear Tape Open, since that's the one I know) is basically the same block-based compression that you'd find on compression-capable filesystems like BTRFS, or ZFS. NTFS is special and not the same). Every block, once transfered to the tape drive, is run through Streaming Lossless Data Compression, aka SLDC, aka ECMA-321, aka a derivative of LZS compression, so the same basic idea used in everything from Zip files, to PNG, GIF, and, funnily enough, NTFS compression. LTO6+ apply this compression to larger groups than just one data block but... not relevant. The compressed data is then written to tape, with an advertised 2-2.5x compression ratio *average* over the entire tape. They're expecting that some of your data will be incompressible, but most of it won't be, for example, *all* of the text documents describing a server's configuration tree. Because it's an LZ descendent, it's a dictionary compression scheme that works best on "repeated" sections of data (where data can be replaced by a pointer and length back to a previous occurence of the same pattern). LZS uses a 2 KiB window to accomplish this. The data transfer speeds are also assuming you're compressing data, as the advertised speed is the post-compression speed (aka, the data rate given is the amount of data that would be written uncompressed, not the amount of literal bytes being transfered). The tapes themselves aren't that slow once you're streaming out a backup (in relative terms), because it's all right there, and the drive itself has enough power to verify, uncompress, and transer by itself, but *seeking* is painful since tape is linear access, and that winding takes time. So it's much more painful to do a single-file restore, having to jump around in the archive to read whichever blocks have your file, then it is to just dump out the entire archive to disk somewhere, pick through it for that file, and delete the dump. Really though, compressible data or not, you really don't care about that much as a backup operator. Either it compresses well or it doesn't, either your tape is full or it's not, it makes no difference. Most places swap out their tapes before they're completely full anyways (or spread backups across multiple tapes, basically striping / RAID0 / JBOD'ing them, depending on the exact software controlling the storage transfers). Example: one of my VMs that has a lot of media on it (pictures / videos / audio), the last backup taken (of the entire filesystem) has a compression factor of 31%. In this context (me knowing what the logs mean to tell me), this means the end backup is 31% the size of the original, *not* that 31% *was saved.* The media might not compress well, but the rest of the files sure do.
Man this takes me back! Back in the 90's I had a real job while in college and overbuilt a PC centered around SCSI devices. It was the best CD copier/game server on campus :-P
I used a Yamaha sampler which relied on SCSI for it's peripherals, well after the time the IDE standard became popular. I resented every over-priced hard drive I plugged into that machine, and don't get me started on how expensive the CD-ROM was. 😨
I have a mixing desk, come multi channel sound recorder, it has a SCSI disk in it, and you can connect an external cd-writter to it. Its a very good device but the disks where expensive. Most of those used SCSI for the DMA features to avoid burdening the very low end CPU they had. As EIDE became a thing in the 90s they could have swapped over without everything going too wrong.
@@mudi2000a I would be surprised if it did not move over to IDE at some point, just as a way to keep costs down. After all they did have to compete with computers that where coming down in price, with studio grade outboard audio cards.
There were non-SCSI CD-ROM drives for Microsoft-compatibles in the early 1990s. Each one came with their own proprietary connector. Meanwhile, Apple Mac users had a range of SCSI-based drives to choose from.
I remember my mother used to work at the main office for a regional bank back in the late 90s. They still used the big single reels of tape. Whole room full of them, one wall of tapes always spooling and unspooling.
I'd really enjoy a video about fiber channel. It was something that existed on my university servers, but I never understood. Thanks for the video about SCSI. I had a lot of SCSI drives over the years, and now NVMe seems like magic to me.
I work with FC on the daily. It's neat in that it's a channel for moving packets. There have been implementations of IP over FC, but SCSI is the big one; also NVMe protocol over FC is available. FC's beauty is its inherent flow control through buffer-to-buffer credits, compared to something like IP where the endpoints manage themselves. There are trade offs in cost and port availability, but I've found FC to be bulletproof and simple to administer, basically set it and forget it. I'm told the prevalence of FC depends on where in the world you are. In the US, I see a lot of FC out there, and the customers are dedicated. I predict NVMe over ethernet, specifically TCP, combined with faster ports at lower cost will peel off the low end of FC.
I remember changing jumpers around with my scsi devices, thanks to the video brought me some memories. When I was a kid growing up, had scsi Iomega Zip drive, scanner, etc on Mac Quadra 650. Apple has their adb bus used for low speed devices such as mouse, printers and keyboards. It looks similar to the PC PS/2 port.
I remember “SCUZZY” being a Dilbert joke 😂 I had a SCSI internal CDRW drive on the basis that IDE was still deemed to be a bit flaky at the time - I had an Adaptec 2940 PCI SCSI card that an acquaintance in IT gave me - I don’t think it would have been financially viable otherwise 😮
One small note, modern IDE and SCSI hard drives do not use SCSI commands, it's only the optical disc drives that do. The reason why device names for them in Linux are sda, sdb, etc is because there is a translation layer (libATA) in the kernel.
@eDoc2020 - one typo in your post - I think you meant to type "modern IDE and SATA hard drives" ;) I figured someone else would have already got in with this correction to the video. The only type of IDE/SATA Direct Access Storage Device that uses SCSI commands would be an ATAPI removable disk drive like an LS-120 UHD floppy or maybe some late-model SyQuest/IOmega disks because ATAPI encapsulates SCSI commands in ATA ("IDE") ones. It is, of course, mainly used for ATA/SATA optical discs and tape drives. Before libata, there used to be a special SCSI host bus adaptor driver in the Linux kernel called ide-scsi which bridged the two subsystems, claiming any ATAPI devices you reserved for it (by passing something like "hdc=ide-scsi" to the kernel) and making them appear as SCSI devices by stuffing the SCSI commands into ATAPI packets. This was essential for using IDE CD writers as cdrecord worked by issuing SCSI commands directly over the "SCSI generic" device associated with them. I remember, though, that (at least with my IDE controller), DMA didn't work with ATAPI so my shiny new 48X CD writer would fall back to PIO mode, limiting its speed to no higher than that of the old 4X SCSI one that it was supposed to upgrade, making the computer run very slowly and causing frequent buffer under-runs. I worked around this by popping an old SCSI-2 PCI card into the machine and using a hardware IDE-SCSI converter (the ACard SCSIDE) on the back of the drive so it would work as a native SCSI unit. I've since re-used the converter to attach a (relatively) modern IDE CD-ROM drive to my old Archimedes A310. Parallel port IDE/ATAPI drives will soon be coming into the fold and appearing as SCSI disks (instead of /dev/pda etc.) too - the old PARIDE subsystem is soon to be no more and will be replaced with a libata driver. I should probably dig out my old SyQuest EZFlyer and test this.
@@molletts Yes I did mean SATA drives. Naturally SCSI drives use the SCSI command set. I think some early Zip drives were true IDE, but all the ones I've seen have been ATAPI. This gives full native support for disk swapping but has the downside that you can't boot them without specific BIOS support. I've never played with parallel port IDE devices. I don't think I knew that they would use device names like pda, pdb, etc.
I worked for Columbia Data Products, one of the first companies to clone the IBM PC. After selling of their computer branch we focused on SCSI device drivers and SW sold via Western Digital and designed some custom cards of our own. I used to get advanced versions of every new SCSI device to test my SW on -- so had the largest drives manufactured including Magneto Optics. So all of this is like home to me. We were also founding members on the ANSI X3T9. 2 Committee (SCSI standards) along with IBM & MS. One thing that is interesting is that the SCSI bus & protocols also evolved into the CAN standards for automobiles and are still used today in car computers. The specs are virtually identical. Plus we used SCSI for many NASA projects including the ISS & satellite data storage. I really enjoyed my time with SCSI and what it has become and am proud to have been a leading contributor to the tech. Even today I'm still trying to establish similar standard with other (new) computer hardware. I really enjoyed you video. Reminds me when i was in the center of the computer universe.
My original pet peeves with USB all the way up to USB2 was yes technically the bus transfer was "fast", but often its implementation at the OS level was absolutely dogshit slow and useless for file transfer where speed was a factor compared with SCSI at the time. SCSI also didn't load up the CPU in the same way as USB where CPU-intensive applications needed every clock cycle they could get. USB had a lot of catching up to do, even in the home market. HUGE improvement over serial and parallel ports at home but that was about it and all I cared about USB for a long time.
Yep - I remember in 2010 being ASTONISHED that between the PC and USB 2.0 HDDs we had, that we actually got sustained data transfers of 30MB/s! That's HALF of the USB2.0 standard speed, and until that moment in 2010, I would always watch the transfer speed jump up and down and rarely ever reach that half speed, due to the issues you'd mentioned, along with drive controllers and slow flash / HDDs. Nowadays I feel grateful when I can get 80MB/s or 100MB/s+ when using ANY storage - despite the USB3.2/4 and NVMe standards allowing ridiculous speeds these days. The past couple of years I've slowly been planning getting 10GBe to the main devices I have at home over either fibre or CAT6e, so we're in a different world these days.
At university I named my 1st hamster Scsi, late after university my second hamster was called Fast Scsi and my third hamster was called Fast Wide Scsi. When Fast Wide Scsi had babies they were called lba1 and lun1 and lun2
I remember building my first netware 3.11 server with adapter 1542 and later 1642. My last servers used the compaq proliant 1500 with the 68pin hot plug raid array and it still used the 1542 isa and ncr 801 pci controller for the tape drives. Btw I hated arcserve 6 for netware.
@@RetroBytesUK I remember I was running a network for the head office of a very large steel maker we only had 300 users in the building but I had 9 proliant 1500 (which were a brand new back then) running netware. I implemented a strict test environment before I moved configuration to the live boxes everything from the c library to the bios config for the eisa bus was under scrutiny. I ended up putting arcserve on a bunch of other netware servers then remotely backing up the main servers because arcserve was such a pain. I remember having 6 ibm model 95 servers running os2 and lotus notes server. And once noticing that if a user had left their mailbox or a database open it wouldn’t back up. So I designed an approach where we had a fairly generic server with a 9gb drive (.5 1/4 inch full height) it was considers huge back in 1995. And that box became the 7th notes server, during the day it replicated with all the other 6 servers and kept a copy of every database they had, then at 8pm every day it would shutdown notes back it’s self up with arcserve os/2 with two attached tape drives. Then restart notes. I called it the 3 2 1 backup 3 copies. 2 media 1 offsite 1 backup was on server 7 (no users attached) 2 tape backup were kept for 6 months 1of the tapes went off site outside London
I always find it fun to learn about tech that was obsolete before I was born. Edit: we do kinda have a standard for USB inside a PC but it is mostly used to just connect to the front panel.
Surprised you didn't cover the rather important advantage of SCSI is that they auto-negotiated transfer speed for each individual attached device. This allowed one to make long chains of devices with different transfer speeds, and a [good] controller will ... just figure it all out. It therefore afforded many choices about upgrade paths, because one had the option to retain an old-but-good device for an indefinite amount of time, until truly superior replacement technology became available.
I remember SCSI controllers in servers in the 80's and 90's. A friend bought a very expensive PC with SCSI controller because he wanted to "future proof" his PC. There were all kinds of problems getting stuff to run with that controller, cannot remember what exactly, but when stock standard PC's with IDE controller and devices just worked, his PC didn't. And a couple years later his computer was rather slow.
Yay! SASI gets some love. I have a SASI controller in an old Cifer 1887 CP/M computer from 1983(ish). A Xebec 1410 with a Winchester 21Mb hard disk that howls like a banshee when it spins up. 😁
In 1999 I went to a LAN Party, a guy had a Win98SE box running off a top end 15,000 rpm SCSI drive. He restarted and Windows rebooted in about 30 second flat. It blew our minds. This was 15+ years before SSDs.
Wow, I happen to be the minority that has Fibre Channel. :) Sun Blade 1000 and 2000 workstations have FC-AL disks and one of those is on my desk. Retro computing is fun indeed. Great video, I actually now have something to show to younger colleagues when trying to explain what is SCSI.
Great video! My first experience with SCSI was with a SCSI Zip drive in my 486 PC when the very first Zip drives launched. Why not the much more common parallel version? I had pre-ordered my Zip drive through CDW and they had a package deal for the SCSI version with a 16 bit ISA SCSI card included for only $25 more than the bare parallel drive. Plus the SCSI Zip drive was 20-50% faster than the parallel version to boot. Currently I have a HPE server in the next room humming away with a SAS RAID controller and 8 SAS HDD's in it with provisions to easily add 16 more drives externally if needed. I'm sort of glad the video didn't go too much into SAS since that by itself would have easily added 5-10+ minutes of length with the different versions of SAS and things like SAS Expanders, multipath I/O and so on.
@7:26 RE: where with USB we don't have a separate "for inside the machine" standard. Uhhh, yeah we do. We absolutely do. Old internal USB uses an IDC10 connector, and new USB3 uses a mini IDC20 connector. Many internal USB based devices (such as hubs or 5.25" bay SD Card readers, etc.) plug directly into these internal IDC style USB ports.
Hmm so that's what those 10 pin thingies are called; but its not like everything uses them exactly, well maybe modern motherboards do, feels more like an industry agreement. The actual usb port is using just 4 pins, with that feeding two ports. 20pins now? such a hassle...
The USB internal connectors are different to the external ones. They're just not used to connect anything internally, but typically only from front case USB or similar stuff.
Another fantastic video - I'm not sure if I missed it but I don't believe you mentioned that SCSI hard drives spun up to 10k and 15k rpm vs 5.6k and 7.2k rpm, improving access times and through put.
In the first decade of this millennium, I had a CD duplicator: I would put the original CD in the top drive, and it burned 8 copies simultaneously in the 8 writers within the same casing (I recorded speakers at conventions). These were all SCSI devices
Surprised that you didn’t include Apple computer. It is where I got my introduction to SCSI. It starting point for me at work, we had devices with SCSI and I needed to read up on it fast.
I worked with SCSI ever since it was first released as a standard and something that has always amazed me is the number of times I've been asked to troubleshoot a system only to find that the SCSI chain either didn't have any termination, termination only on one end or in some cases three terminators. To me it was so simple to understand. The first and last device on the SCSI chain has to be terminated. If a controller has both internal and external SCSI connectors but only one controller then everything is going to connect to one chain. So if there's internal HDD's and a external Scanner the chain has to be terminated on the physically first HDD in the chain and at the Scanner, and the controller cards terminator has to be disabled. This simple thing tripped people up all the time. Just to make it better if the external scanner or CD or whatever was the only device on the chain apart from the controller it would often kind of work without termination at the scanner. So when you got there and told the customer that they needed a terminator at the scanner end they'd often just look weirdly at you. Almost all scanners came with either a terminator you plugged in to the second SCSI port of the scanner, or a passthrough terminator that sat between the SCSI cable and the port on the scanner. But some had internal terminators that you enabled using a DIP switch. Next problem was people not assigning a free SCSI ID and wondering why it didn't work with two or three HDD's using ID0... Something that came late in the SCSI scanner market was scanners with only one SCSI connector. These could not sit at any other position than last in the chain. Weirdly enough some of these didn't have an internal terminator even though by design they were doomed to always be at the end of the chain. As for server use, there were quite early a standard for hot-swappable SCSI drives. The connectors position on the drives was standardized which made it a lot less fristrating than trying to use IDE drives. With IDE every manufacturer had their own idea of where exactly on the drive the IDE controller and power connector were. I worked with storage chassis that had several backplanes you could swap in that allowed you to use IDE drives from different manufacturers be used. But you couldn't use for instance a Conner drive and Seagate, Western Digital or Maxtor drive on the same backplane. The alternative was to have a drive sledge that had an interposer of some kind which adapted the drive I/O to a connector that then mated with the connector on the backplane. But then you had a new non standard connector that could introduce problems. All of this finally got solved with SATA as now the dimensions and exact positioning of the connectors were finally standardized. The controller situation was also interesting. As said SCSI was the grownup solution while IDE was the wannabee kids solution. But there were some who tried to make IDE controllers smarter early on. I remember a IDE controller with cache memory. I think it was 2 megabyte, and it had a battery backup. This was IDE, not EIDE or PATA. I can't say I noticed much of a difference but it was used in a server. No RAID functionality though. Still I think it was an interesting attempt. Now something not mentioned in the video was a big limitation with the parallel IDE, E-ID and P-ATA world. While you could have up to two drives on one IDE controller only one of them could be active at any time. That is even with the fastest and latest standard that supported DMA and so on only one drive was active at a time. Want to read something from one drive and write something to the other drive? Well send the read request to the first drive and wait for the data. Only then could the controller yell at the second drive that it had data to send to it. This meant that copying files between drives on the same controller was a lot slower than if the drives were on different controllers. Motherboards toward the end of the parallel IDE era tended to have two IDE channels which effectively was two separate controllers so choosing where to connect the drives could be important for performance. With SCSI this was never much of a problem. The controller sent commands to the drives whenever the bus was available and didn't have to wait for them to locate the data and read or write it only to tell the controller they were ready. SCSI devices can even send data directly between each other without involving the controller, though this was not often used.
In the early 90s my school had a setup where we had SCSI hard drives shared between groups or 4 or 5 Acorns. The SCSI cable would run from one machine to the next. The hard drives would often fall over when we all drived to access the drive.
During my us navy days as a submarine sonar tech, in the early 2000s we were transitioning from legacy bsy1 and q5 hardware to q10 arci (cots) hardware and everything HD related was scsi, for the servers and the raids etc. Everything ran on modified custom versions of Linux (various distros) It started to change in my final years around 2015 to other standards, fun video brought back some memories 😂
A couple notes about the relationship between IDE/SATA and SAS: All IDE and SATA CD/DVD drives actually use SCSI commands internally. This is what ATAPI actually does - it tunnels SCSI data over the IDE protocol allowing devices other than hard drives to work. SATA drives don't use SCSI commands. The reason SAS controllers can talk to both disks is that SAS was designed to use the existing SATA connector and electrical interface (but it can go faster), and SAS controllers have built-in support for both protocols.
I have only used linux for a timy bit so when you said that we may realized while using linux.. I was like “Nah, I didn’t used it enough for sure” and then I see /dev/sdc or /dev/sda and I was like “What the fudge? That’s how far back it goes?” Thank you for this video, it was a pleasure to learn a little more history of pre USB era :))
Still using u320 on a Lto4 tape external. Couldn't resist putting a terminator on it from the recycling centre even though it self terminates. It's never gremlined ever that I can remember,
The best bit about SCSI is the way you can have two controllers accessing the disks on the chain. Was handy to have an Amiga and a sampler both connected to the same disks, at the same time.
The initiator is normally ID 7 even on SCSI-II because at 7, it's halfway between the first seven and the last seven devices, making the access to both faster. I just replaced three 73 GB Ultra160 SCSI LVD 80-pin SCA drives with brand new 300 GB Ultra320 LVD drives at 75 euros per drive... brand new, and went for peanuts because nobody nowadays knows what to do with them. KNOWLEDGE IS POWER!
I've said it before, I love that this channel goes into retro tech that's not just home computers. Having messed with SCSI in most of its forms, I never knew there was an Ultra 640, I thought it pretty much ended at Ultra 320 before going to SAS. Thank you
Still use SCSI in the form of iSCSI for a VMWare cluster of 32 blade servers talking to a storage server at 25Gbps. It really is crazy how after all these years, we are still using SCSI.
USB absolutely has a separate "inside the machine standard". It's not just used for front panel connectors, either. You often see it used internally from one internal connector to another for things like Bluetooth modules on PCI-E wifi cards, Thunderbolt cards, etc.
Thank you for the comprehensive breakdown of the evolution of the SCSI standard. This goes a long way to explain why some of us considered that sacrificing a goat to the SCSI bus could be beneficial to getting a specific SCSI installation working!
I have no idea how widespread use of SCSI was in electronic music gear, but the Roland VP-9000 VariPhrase Processor (sampler) had a SCSI connection. I got a floor model of one of those from Guitar Center for a sixth of MSRP. I gave up on getting it to connect to my PC and just used Zip discs. At least my struggle to get SCSI to work resulted in coming up on an huge HP flatbed scanner for cheap that still gives modern scanners a run for their money.
Another occasional SCSI device in the 1990s was a slide camera. It literally had a photographic camera directed into a sealed compartment with some sort of high resolution image generator. Maybe a hi def CRT, I'm not sure. Could have been lasers. Each photograph would be exposed for some minutes while the image was scanned out. Later the finished film would be developed as 35mm colour slides for use in lectures etc. These were sharp as a tack, the thing was scanning thousands of lines per frame. The one we used had a choice of connections. SCSI was fastest, but there was also GPIB, maybe others.
Great memories! My first PC was an Epson Equity II+ (80286-12MHz) with 256k VGA and a 40MB SCSI HDD. The first CD-R I ever burnt was done on a Pinnacle SCSI CD-R around 1995 (Smart & Friendly media) and IT IS STILL READABLE in 2023.
In the mid 90’s the only way to do digital video editing on a computer was with using SCSI drives. Boy these where expensives! Almost 1k$ for only a 4 Go HD! The last SCSI card and drive i used where lvd type and the card and a 10g drive did cost close to 2000$! I even had a SCSI CD burner that cost 499$. 😮 That’s in 90’s dolllars… then firewire and usb came along…
Back in the 2010s, I visited a big old data center and ended up in their lab. All sorts of weird hardware, but what stood out was a SCSI SSD from late 90s, made by some obscure Silicon Valley company. Size of an APC Smart-UPS, packed full with 128 Mb ECC SDRAM sticks and lead-acid batteries. 18.6 Gb size, about 40 lb weight. Unfortunately, it died in 2003, according to the sticker, and was never fixed.
And SCSI still exists today, in SAS They're very much is a USB internal standard. It's the connector on the motherboard that the external port connects to. We're currently on version 3 of the port
UASP is a thing - USB Attached SCSI. It's basically SCSI command set over USB. It's used to stream data from storage devices over USB protocol in faster, more robust way than USB packets. It's used with SATA, SD and NVMe devices all the same.
There are reasons why FC got some advantages over iSCSI. Link aggregation over FC is giving a single datastream the full bundled bandwidth of those ports combined, unlike Ethernet. Although considering the amount of money you'll spend on everything... Like licensing every single port on a FC switch. Yet it's always interesting how and where different standards live on. Ceph cluster with SAS disks underneath and so forth. Time for another layer of abstraction!
Still have my working Mac Plus sitting here. I originally only had the Apple 20Mb HD that interfaced through the external floppy connector. When I got my first SCSI 100Mb HD and plugged it into the SCSI-1 port, my computer was transformed. It felt like when today you replace your laptop's HDD with a SSD. Also, loved the views of all the antique U.K. tech. It's not often in the 21st century that you get to see any technology with a "Made in England, Scotland, (or U.S.A., for that matter)" label. It makes me nostalgic for the days when cutting-edge technology made one think of words like Bletchley Park, Turing, and Colossus.
On the Amiga, SCSI meant the hard drives and other devices just worked. On the A600 and A1200, the IDE driver is called scsi.device. But it doesn't know CD ROM. I can still remember it well. First load the ATAPI driver with the scsi.device from the ROM of the first hard disk, patch scsi.decive and then use the ATAPI driver after the soft reset, which can also address large hard disks. With a real SCSI controller this was not necessary. It just works
Worked with Sun and Digital Equipment Corp and the SCSI equipment that connected to them for almost 20 years. Terrific working years! For my personal 486, built up on an Adaptec controller, 2 disk drives, QIC-525 drive, and CD Drive. Long live SCSI!
From the early 90s, thru till about 2010, I had a SCSI Card, or SCSI on the Motherboard of my computers. Several of my Scanners used the Interface, and I had a couple of SCSI Hard Drives. For the Time, they were quite a lot faster than the other HDs available then. Even my 1st CD Drive was SCSI thru the Sound Blaster Card
Back in 1999 I built a workstation that had a 3-channel SCSI RAID controller with its own onboard 68020 processor, memory and a real time OS to handle all HD I/O. Each channel was bandwidth saturated with 2 Seagate Cheetah hard drives. My SCSI card also had my Plextor CD R/W drive and a legacy SCSI floppy drive. The 6 Cheetahs were configured in RAID 0 with stripe sizes such that nearly all my file read/writes were distributed over all the HDs concurrently. The real time OS on the card managed the disk IO in a semi intelligent way, doing things like ladder sorting and prefetching into the onboard RAM.
I used SCSI a lot in the 90's, and the big advantage I saw that you really didn't touch on much is it was intended for EXTERNAL devices. IDE was fine for internal hard drives or even optical drives, or some niche interface for your floppy, but if you wanted ANY of that to be external, SCSI was really your only option. Being able to chain it (hook more than two hard drives to your computer) then again SCSI was the way to go. You could install another IDE controller, but it'd only get you two more drives. At one point I had six external drives, all plugged into the one SCSI port on my computer. But at about that point, SCSI drives were getting out-priced by IDE which were getting quite common. I think the biggest SCSI drive I owned was a 56GB IBM drive. But at that point IDE drives were about 40% cheaper than the same size SCSI. Sure, SCSI was faster, but it was hard to get past the low price. Also there's a lot of similarities when you compare SCSI-vs-IDE and USB-vs-FireWire. I think you missed out not including discussion of firewire. A very similar story where firewire was much better than USB, but lacked the ability to continue to scale up and was eventually surpassed by USB. My external storage evolved from SCSI drives in an external tower, to SCSI drives in a tower to IDE drives chained in a firewire tower. This allowed me to grow my storage using the cheaper IDE drives. The smallest IDE I had in the tower was 80gb (compared to the largest SCSI drive I ever owned at 56gb), and I continued to use that tower up to a mix of 250, 320, and 500gb IDE drives. That would not have been possible for me with scsi, as I never really ran into any larger SCSI drives.
I used to manage a 24x3 fibrechannel raid array. Loved the tech, hated having to rebuild it. It was like 10 TB. Which doesn't seem like much, but it was 10 TB of raid 5 with very smol drives in comparison to today.
IDE never adopted SCSI command set. It's partially true for ATAPI protocol but that is specific to removable media (CD/DVD, Zip, tape etc) - SCSI commands are tunneled over IDE/ATA. However normal hard drives have always used ATA command set, even to this day as SATA. On Linux side, there is a kernel translator that translates SCSI frontend commands to backend IDE/ATA commands. They're handled the same for the Linux kernel but backend drive command sets are still totally different.
Still have a SCSI CD-ROM drive that doubles as a portable CD player that my old dad uses when chilling in the back garden in summer. This video does answer one of the mysteries of the universe, that is why I always had to plug that drive in last and set it to device 7. It was self terminating.
The original Atari ST used ACSI, a sort of cheapo SCSI cousin. In 1991 the Mega STe came with an internal SCSI hard drive (with a small adapter board plugged internally to ACSI, if I remember correctly it might actually been an Adaptec). The (originally intended as a UNIX workstation) Atari TT had both ACSI for backwards compatibility with peripherals and proper SCSI with a 25pin connector. The final Atari computer, Falcon030, had an external micro 50pin SCSI port (intended for external SCSI drives for direct to disk recording due to DMA benefits) and an internal IDE port typically used for a system disk.
I named my dog SCSI. It's always fun to watch the increasingly distant stares of strangers as I explain how to pronounce "SCSI" and what it means.
And you know there is a soulmate when they go ‘Oh, I like that! What was your first device?’
If Dogs are SCSI then Cats are IDE.
Cats always demanding full attention and not easy to socialize with different species.
@@Flofutz This made me laugh harder than it should have. I am going to save this for the future to tell to my tech buddies. Thank you for such an oh so true joke.
Nice, i love it.
@@ninja011 My wife just asked me why I'm laughing, my explanation did not convince her it was funny.
Atari's Serial I/O (SIO) bus was the USB of the '80s. It is credited as the basis of USB, allowing multiple peripherals to be accessed via a plug-and-play serial bus.
Definitely, and the Commodore serial bus wasn't very different either.
Agree but SIO was surely very similar for Atari, Commodore & Sinclair as all micros had a port that performed the function of a proto USB. Was it truly an Atari invention?
@@arostwocents If you look up the original design patent for USB, they specifically credit Atari's SIO as the inspiration and basis of USB.
@@arostwocents Well the result was the same (you plug some stuff in and it works) but they were fairly different.
The Commdore bus itself implemented a fairly simple interface, it had commands to tell a disk to listen or talk, then would send a command selecting which channel (each device had 15 or 32 channels). Everything on top of that was essentially ad-hoc, those making a Commode-compatible drive either had to reverse engineer the Commodore ROM or just copy it (in recent times, it's been found that many just copied it and swapped some instructions around a bit to try to obfuscate it.)
In contrast, the SIO bus used a "command" pin, when that was pulled all devices would listen for a command. A 5-byte command was sent (1st byte is the device number, second is the command, 3rd and 4th could include data, like a sector number for a "read sector" command, and the 5th a checksum.) The device would send back a single-byte acknowledge (or negative acknowledge) along with sending or receiving a block of data as the case may be. It had a pre-defined set of commands to cover floppies, printers, serial devices, and casette drives and they were documented well enough that one could implement a compatible device just by following the SIO documentation. The OS also had a design that made it easy to extend existing device handlers and add new ones.
That's what inspired USB. Electrically the bus was nothing unusual (although it was hot pluggable.) And having extensively documented specs was not unusual on large systems (over the years IBM has loved having thick thick manuals describing every aspect of the hardware internals). But having a small system, hot pluggable plugs, and enough protocol documentation so 3rd parties could easily make devices that follow the spec? That was rather unusual.
Apple had that port that could be used to plug up modems, printers, external drives even, with no drivers (that I recall)…. ADB I think it was called, without googling it…. also basically a higher speed aerial port…
That was a lot of mindblows. From the origin of tar over where /dev/sda came from to the fact, that USB Mass Storage uses SCSI commands 🤯
I work a fair bit with low-level linux kernel code. And have written my fair share of USB device gadgets.
USB Mass-storage devices actually are totally handed off to the SCSI subsystem in the linux kernel. (most of them - i should note that not all mass-storage devices identify as SCSI!!!!) It's just that their read/write function pointers are replaced with usb control messages and bulk transfers handlers.
A lot of USB in the linux kernel works this way - where once the USB device and descriptors are enumerated - it is handed off to the subystem that was abstracted by USB code.
but there a USB attached SCSI introduced with USB 3.0
that uses actually SCSI commands
Excellent detailed overview. One minor additional detail - for multi-initiator systems, the SCSI ID was used to indicate which device should be prioritised during the arbitration phase of a SCSI transaction. That's why there are only 8 IDs on an 8-bit bus - each device asserted the bit corresponding to its ID, allowing multiple devices to be uniquely detected.
Multi initiator setups were possible?
@@webmonkey44Yep. The video talks about this briefly at 19:30. See also: VMSclusters.
I grew up with SCSI as I worked on Mainframes out of High School. SCSI was amazing compared to ATA, being able to have 16+ devices on a single chain was always amazing.
It still gives me a little bit of glee working with SAS devices and saying the name Serial Attached SCSI out loud. SCSI still lives with us.
And it finally got a bit of its sassiness back.
SCSI was good, but it could sometimes be a little challenging, especially when trying to diagnose why the chain of scsi devices you’ve just plugged in isn’t being picked up, only to find it’s not properly terminated, or you’ve got a bad cable. Admittedly that last bit was more rare. After all done computer cables in the 90s were so well built you could pretty much use them to haul yourself up instead of rope.
That said, my boss did set fire to go a scsi ribbon cable once. He plugged it in to a motherboard with onboard SCSI once. Slightly misaligned the pins. In the process he kill the motherboard, set fire to the cable and set off the smoke alarm. As this was wired into the building fire alarm, this took some explaining.
Glee?
I have never had this "glee".
Do you have this often?
How does it feel?
I named my first kid SCSI so i always had a legit reason to say SCSI outloud and even yell it!
7:33 There actually is somewhat of a "standard" internal USB connection. It's the header on the motherboard that front panel USB is connected to. There are actually two, one for USB 2, and a different one for USB 3.
There's also an internal USB-C connector as well.
I really hate the USB 3 headers, you have to be really careful when removing the connectors especially
There is also a different internal header between 3.0 (blue plastic, like the usb2 header but twice the size) and usb 3.1 (metallic and actually looks like a miniature SCSI 2 port!)
I just wanted to write the same thing, glad that I'm not the only one who thought about that xD
@@dasy2k1 Interesting, I haven't come across one of the 3.1 headers myself. Could be on my sons' computers though, I haven't looked.
Here's the one that will surprise you. The Yamaha PMD1 console used SCSI to interface their DSP angine, console and audio interfaces to each other. The longest SCSI cables were 100 meters long, to connect from.stage to other devices at front of house. There you go. I had learned about SCSI with my Amigas so was surprised to see SCSI with the consoles.
Your that one is suprising.
That would definitely surprise me. The longest cables you can use on High-Voltage Differential SCSI were 25 meters, the standard didn't support anything longer than that.
Are you sure it wasn't some other type of cabling? MIDI, or something proprietary perhaps?
Many '80s/'90s samplers used SCSI. Many that used floppy disks also had slots to add a SCSI interface. Look at the Akai S-1000, E-Mu 6400, Roland S-550 or Yamaha EX5.
By the late '80s everybody was using sample CDs (like the Zero-G CDs that were used in thousands of songs), and that was accomplished by plugging a SCSI CD-ROM into a rackmount sampler. I don't know anything about Yamaha consoles, but I assume that when Yamaha needed an interface for digital consoles, they used SCSI because it had been a standard in music production for about 15 years. The PM1D is a 1999 console, so that means that at the time it was released, Yamaha's flagship sampler was the EX5R which used SCSI.
In my first job, I designed SCSI peripherals (mainly tape streamers though blocked tape devices too) at a small British company. I then went on to become a Field Applications Engineer for SCSI devices looking after the Symbios Logic (ex NCR) range of chips and RAID controllers. I still smile when I see how USB, SATA and other interfaces have taken the SCSI command set and use that in their interfaces.
The box at 6:30 looks very much like one of the ones we used for our products, including a parallel port to SCSI tape interface.
There are some interesting points about SCSI which you didn't pick up in the video. Initiators were often left at ID7 because that was the highest priority ID (7 -> 0 then 15 -> 8). Better than that, when you mixed wide (16 bit) and narrow (8 bit) devices on the same bus, they could all still talk because they could all see ID7 and then would negotiate the width of communication. This made it great for customers who didn't have to go out and buy all new kit when they changed bus sizes.
Also, related to the DMA aspect, is that once the initiator selected the target, it was the target that ran the show by choosing what was going to happen and when. Your computer would say "I want blocks 100-105" but the hard drive would be responsible for fetching the data, and then calling back the computer, for the transfer. Assuming that the computer was boss was an all-too-common fault in software driver design for SCSI devices, though it did get me a few all-expenses paid trips to nice locations fixing the problems 🙂
Thank you! I had plenty of SCSI peripherals including a Symbios controller, and that was brilliant indeed - super-fast and reliable, it even had removable terminator resistors on the card if I recall correctly. Brilliant stuff!
I love your enthusiastic narration. I had a lot of dealings with SCSI back in the day. It was a running joke in the sysadmin community that, as well as selecting the right ID and ensuring the correct termination, you also had to perform the correct ritual sacrifice of chickens/goats/etc to appease the SCSI gods and get your devices to work properly. In my first job looking after unix workstations I had to deal with about 5 different versions of the standard all in use concurrently. Most of them could be made to talk to each other but if LVD was involved all bets were off (maybe we just didn't have the right adapter...)
One small correction: it's SyQuest (pronounced like the psy in psychology) not SysQuest.
I must have been thinking about the sysquest tape cartridge when I was recording 😂
Ah, I was about to make a remark about the sacrifices required to appease the SCSI gods. Real life story from my last gig where I had to deal with SCSI (or any hardware other than what is on or below my desk): one day my manager and team lead headed to the server room to install several SCSI devices to a box. I asked them whether they sacrificed a goat, or at least brought some black candles to light during the work. I was met by glazed eyes, them unaware of the SCSI gods. An hour later, they came out, defeated. "I told you so", I said. They then asked me to go in and give it a try, to which I succeeded. When they asked me how, I replied "We have some spare memory. I put it on top of the box and told it if it helped me defeat the SCSI gods and behave over the weekend, it could have that extra memory on Monday".
@@AbiGail-ok7fc 🤣🤣🤣🤣
Another feature that SCSI had before IDE/SATA was command queing. This allowed the drive to optimize access to the disk. A big feature of SAS was the expanders, which allowed networks of drives to be attached (somewhat similar to FC). Your video was very interesting to me as I worked as a firmware engineer for enterprise disk drives and saw the transitions from SCSI-1 to SAS.
That was later implemented in SATA as NCQ (Native Command Queuing).
SAS is serial attached SCSI. he also said that SCSI drives worked at the same speed as IDE drives and it was the bus that was faster yes i agree but many SCSI drives and SAS drives spin at a Higher RPM going all the way up to 15krpm thats 15000 RPM i think i have some drives that may even go higher, thus making the SCSI drives even better, Also I still have a PCI-E adaptec SCSI controller for my server for my TAPE drives as if you want a backup TAPES are still a thing.
Plus there is DSSI and i have one no controller tho just the hard drives.
@@blackIce504 SAS where else can you get nested acronyms.
If memory serves me well 15K drives faded away with the broad adoption os SAS.
@@spikeevans1488 yes its sad from what i seen anything past 900GB is just 7.2k but i have many still kicking and screaming that been said it was very common in the era of Ultra wide SCSI, That been said the platters where also 2.5" but still in the 3.5" on many of the SAS and Ultra drives.
@@blackIce504There are some new 10k rpm drives but not many
IDE (or, more accurately, ATA) originally wasn't anything remotely like a competitor to SCSI. ATA literally means "AT Attachment", with AT referring to the IBM PC/AT of course. In its original incarnation it was little more than just a way to plug hard drives into the ISA bus almost directly. A far cry from SCSI which was intended as a cross-platform standard from the beginning - so they were very different beasts, even putting performance aside. ATA only became cross-platform many years later, around the mid-90s.
“IDE” in this context stands for “Integrated Drive Electronics”. That means any system where the disk controller was not a separate card, but integrated with the drive. This included SCSI, I think ESDI as well, and PATA and SATA. Before that you had things like ST-406 and ST-512 with a separate controller card.
Well, you could lterally implement that on any 16 Bit bus and it only needs la handful of TTL chips. Even saw some cards like this on the Amiga. But then it involves alot of babysitting the drive.
@@lawrencedoliveiro9104 No. IDE came first. ATA was a result of improvements to IDE and technically the interface should have been referred to as ATA but people still continued to use the old name IDE.
ATA was crap in all honesty. It was too simplistic an interface. Although multiple devices could be connected to it concurrently, you could only access one device at a time. And if the device took time to complete the operation requested, you could not go and access the other device during that time, thereby impacting performance massively if you mixed a high speed device with a slow speed device.
@@deang5622 ATA came long after SCSI.
I've been using my home server nas thing with a sas hba as well as a striped pair of nvme because of zfs. I'm quite impressed that all of this technology is able to talk to ancient crap still, like a floppy drive I have in the same server. This is mainly because it's also my ingest machine for literally any generation of tech, and I have retro and new machines hooked up simultaneously. I'm glad this work was done so I can play with stuff that has no right being together.
We had a SCSI laser printer on our Mac IIcx when I was growing up. Printing was the only thing besides a hard lockup that could stop the cursor moving; normally cursor movement is such a high priority on old Macs it would always work smoothly no matter how busy the CPU was.
Having worked a bit with SCSI for about 25 years, I expected this to be just a nice nostalgic trip down memory lane (which it is). But I was completely unaware of Ultra640. And SCSI printers. And I learned of Adaptec's fate literally yesterday, while researching RAID options for a budget build-your-own server. Fantastic video, thanks! (Oh yeah, had a nice chuckle at the fudge.) I would only add that from about the mid-to-late 90s on, SCSI hard drives themselves were higher-performance than EIDE, separate from the interface. Just because SCSI drives were already chosen for performance, they had 7200 RPM spindle speeds when EIDE had 5400; then SCSI had 10,000 RPM and EIDE/SATA 7200, then 15,000 RPM for higher-performance SCSI (or was 15k after SAS took over?) SCSI hard drives also had 5-year warranties, compared to 3-year for IDE.
THIS! I came here to say I still haven't seen any 10,000 RPM SATA drives. So yeah, they did make them physically faster.
@@cpt_bill366 WD Raptor
They exists, but you would be better just to get SAS, as it would be cheaper
15k SCSI drives do exist but they're not terribly common as they started appearing about the time everything was moving to SAS anyway (IIRC anyway)
@@SomeMorganSomewhere I have had 10K Hitachi SCSI UW3 drive, from line which have had 15K models too
@@SomeMorganSomewhere15k drives are weird. I had some hard drives i hooked up to see if they spun up to see if they were any good. The centrifucal force on them is huge and hard to move them when spinning
As a Mac user from 1985 I got real good at building SCSI chains, sometimes one needed to get pretty creative; between devices with 2 DB or Centronic connectors (or occasionally one of each), the odd device with only one connector, and varying ways to set the SCSI ID and whether the chain needed to be terminated made for an interesting time. I had so many cables, with either type of connector or one of each again, it got pretty confusing unless you understood the craziness.
I remember my Computer Studies teacher teaching us about SCSI. At the time I was still 14 years old and had IDE disks and ATAPI equipped optical drives in my computer. Later on I got SATA based machines. I suspect that all these still use the SCSI command set since the linux kernel implements most IO as part of the scsi driver coupled with ata drivers (for ide/sata)
Another feature of SCSI was Native Command Queueing which greatly improved performance by allowing out of sequence I/O. SATA drives can now do that as well. SCSI drives also had higher spin speed that IDE - not because of the technology, but because they were higher priced enterprise drives and those drives were usually SCSI. While PC users thought 7200rpm was fast, at work we only dealt with 10k and 15k drives.
What I hate is having on-disk caches. The drive makers do it to look good in benchmarks. But the downside is your OS does a cache-flush, the drive reports back that the data has been written, but really those bytes are still sitting in RAM on the drive, and if the power fails within, say, the next fraction of a second, that data will be lost.
@@lawrencedoliveiro9104 I had a RAID card with batteries on it, to deal with its own cache RAM in the case of a power failure. The on-drive cache came along as well, as it kept power to the drives until it finished writing everything and confirmed a graceful shutdown of the drives.
@@JohnDlugosz Having cache on the drive is just the dumbest thing. Because remember, that’s on the wrong side from the CPU of an interface that was never designed to run at RAM speeds.
The sound of a set of 15k rpm SCSI drives starting up gave me goosebumps, like listening to a jet fighter start up....
I remember having a HP Scanner and Printer combo connected with SCSI as part of my first computer set. Really brings back memories.
The interesting connection between the Atari ST and SCSI is that the ST has a "SCSI light" called ACSI (Atari Computer System Interface) or DMA. It was inspired by the SASI bus interface, but with less signals and a slightly modified protocol. Both to reduce the pin count on the connector and the command overhead. The ability to change the bus master was removed and the first command byte also contains the device address beside the command (3 bit device address 5 bit command). But because both busses where so similar, a bridge made from discrete logic could be designed. Atari itself made a reference design for that later on.
A result of that was that the ST was one of the few computer systems who implemented their own custom SCSI hardware. (TT and Falcon used Adaptec chips)
Sadly there was an oversight in the design of the DMA Chip that dives the ACSI bus. When the Byte transmit counter reaches zero the chip didn't stop sending or receiving data. The slave device has to initiate an interrupt so that the software on the ST can stop the DMA transfer. An Interrupt from the DMA Chip itself would have made the hardware implementation of the slave devices much easier.
There definitely is an internal USB standard, it's used for headers on motherboards which are usually used to pass through to front panel connectors but there is no reason they couldn't attach actual devices. In fact, in some cases they are used for that; some servers use internal USB drives as boot devices that plug directly into motherboard headers.
Much more likely to be an onboard USB-A port than connecting directly the the 9 pin header. Those headers are just too fragile and finicky.
USB was inspired a lot by Atari's SIO (Serial Input/Output) from 1978.
The video also reminds me of HP-IB (Hewlett-Packard Interface Bus), a late 1960's parallel bus allowing daisy-chaining, later standardized as the IEEE-488 GPIB (General Purpose Interface Bus). It was used for floppy and hard disks (e.g. by the Commodore PET and the HP-85), but mostly for lab equipment (oscilloscopes, logic analyzers, programmable power sources, digital multimeters...)
Still find it on a lot of T&M kit, although largely replaced by USB and Ethernet. You can still buy USB-to-GPIB adapters (and they're not cheap new).
My school had a IEEE-488 interface for the BBC micro we connected up to a couple of bits of lab equipment we had. The only one I remember using was an oscilloscope, I used it as an audio sampler, as you could capture about 10 seconds of data.
I tied a PDP11/94 to a modern UNIX system over that interface in the early 90s.
It was the ugliest kludge I'd ever seen as it had to go out of the PDP, into a short haul modem to a channelized T1 / DS0, over the WAN into another short haul modem until it terminated into a Digiboard external adapter before finally residing on an OS/2 Warp machine that actually listened for the reports.
e.g. keeping the syncronous timing was no fun
@@satsuke That's...some impressive kludging. In a horrifying kind of way.
USB is a host-based system where each device needs its own port. While the IEE488 and Atari's SIO are connected to a BUS in the form of a daysy chain. I.e. Atari's SIO is not related to USB, but to IEE.
Thanks for the memories. I spent 20 years of my career in storage connectivity. I left 5 years ago to get into cloudy containerised stuff. Great memories of parallel SCSI and the early days of Fibre Channel. You mentioned the standardisation of SCSI, the T10 and T11 standards docs were my bible. However the problem with standards was the interpretation especially with optional features and then there was IBM who just seemed to do their own thing. I used protocol analysers on both FC and parallel SCSI to work with vendors to overcome interop issues. Average interesting time. You also raised multi-initiator SCSI, this was very tricky to get right. Often used in highly available clusters. You are absolutely right that locking was key, much helped by the persistent reserve SCSI command.
We got our first home computer in the 80's. It was a 286-16 with a 80 MB SCSI drive. Still remember our neighbor could not fathom how the computer could access the hard drive without a specified hard drive in BIOS, as you usually would do with IDE drives, and they'd show up in the system summary.
I was wondering why Adaptec cards were so robust. They invented the damn thing!
That entirely depends on who you ask and when. Towards the end of their life as Adaptec, the OpenBSD project ended up dropping all support for their RAID cards because they couldn't get the documentation needed to work around the firmware bugs. Also have a chat with Nick Holland about his experience with Adaptec cards - at one point they sent him firmware that damaged his card after sixty days.
As far as SCSI controller cards with RAID support, Mylex Corp was way ahead of Adaptec. Mylex's biggest customers on RAID SCSI were IBM, HP, and DEC. IBM eventually bought Mylex. I worked for Mylex in the 90s and then at Adaptec in the early 2000s.
Literally 1 min in and had to comment. "A time completely different to ours." Priceless. I literally slapped my knee as I laughed.
When I started building systems back in the 80's, SCSI was all we used. Mostly because of the ease of having multiple devices without having to worry about drivers and incompatibility issues, and there were plenty. Just plugged stuff in and it worked, all the time. Thanks for the memories.
Amazing video! I remember accidentally buying a SCSI Zip drive on accident for a big chunk of change and not being able to use it for six months when I could afford a controller.
I still have these bits of hardware floating around in my stacks-o-stuff...
- SCSI Zip Drive. I remember it only had a choice of two IDs, the other switch was termination.
- Adaptec ISA bus SCSI card, for use with external devices only. This combo was fast enough to record and play .WAV files with no hesitation, and when MP2/MP3 came along it absolutely rocked.
- Roland VS-880EX Virtual Studio Workstation. I got the model with six inputs. This also had the ability to work with Iomega's Zip and Jaz drives, even in live recording. I did that once.
@7:31 untrue, we have internal USB headers that can power stuff like Bluetooth chips on Wi-Fi cards, fan controllers, things like that :)
That was wonderful - brought back a lot of (rusty) memories. Great overview! As for odd SCSI devices, we designed a medical ultrasound scanner (16 bit wide) for it...
The USB 3.0 (USB 3.1 Gen1) specification added UASP (USB Attached Storage Protocol) for large mass storage devices like external HDDs and drive arrays. This uses the SCSI command set instead of Bulk Object Transfer (BOT).
The old BOT mass storage device protocol is also based on SCSI.
@@eDoc2020 I think it doesn't support command queueing in the same way and just uses the command set. UASP, as I understand it, operates SCSI control tunnelled through the USB interface, and appears (at least on macOS where I've probed the hardware interface) as SCSI, though under the IOUSBMassStorageInterface
@@samuell.foxton4177 This is true with Windows as well. I use Ultrastar external HDD's in USB caddies and are seen by the system as USB Attached SCSI (UAS) as the controller and the disks are seen as SCSI Disk Device.
Usb has an inside the machine standard. USB1/2 is mostly just pins, but 3.0 has the blue plastic connector and thunderbolt has its own funky connector.
Fantastic video, love the pacing and structure of these!
Starting my Saturday with a fascinating video about SCSI - you just made my day! #InstantLike
I had a SCSI scanner for years, which was what had me keeping SCSI around.
16:00
Fun fact Tape Drives are still used in modern times to Store comically large amounts data because they're high density and low cost. The Highest Capacity Tape Drive has a Native capacity of 18TB and can store 45tb of compressed data. These are usually used for long term Archives and Infrequently accessed data because they're excruciatingly slow.
I know that the Canadian National Film Board stores their archives as uncompressed video on tape. The math on that is terrifying.
I can’t imagine that 2½:1 compression ratio would work with data that is already compressed, like H.264/H.265 or JPEG.
@@lawrencedoliveiro9104 Not really. Tape drive compression (or at least LTO, Linear Tape Open, since that's the one I know) is basically the same block-based compression that you'd find on compression-capable filesystems like BTRFS, or ZFS. NTFS is special and not the same). Every block, once transfered to the tape drive, is run through Streaming Lossless Data Compression, aka SLDC, aka ECMA-321, aka a derivative of LZS compression, so the same basic idea used in everything from Zip files, to PNG, GIF, and, funnily enough, NTFS compression. LTO6+ apply this compression to larger groups than just one data block but... not relevant.
The compressed data is then written to tape, with an advertised 2-2.5x compression ratio *average* over the entire tape. They're expecting that some of your data will be incompressible, but most of it won't be, for example, *all* of the text documents describing a server's configuration tree. Because it's an LZ descendent, it's a dictionary compression scheme that works best on "repeated" sections of data (where data can be replaced by a pointer and length back to a previous occurence of the same pattern). LZS uses a 2 KiB window to accomplish this.
The data transfer speeds are also assuming you're compressing data, as the advertised speed is the post-compression speed (aka, the data rate given is the amount of data that would be written uncompressed, not the amount of literal bytes being transfered). The tapes themselves aren't that slow once you're streaming out a backup (in relative terms), because it's all right there, and the drive itself has enough power to verify, uncompress, and transer by itself, but *seeking* is painful since tape is linear access, and that winding takes time. So it's much more painful to do a single-file restore, having to jump around in the archive to read whichever blocks have your file, then it is to just dump out the entire archive to disk somewhere, pick through it for that file, and delete the dump.
Really though, compressible data or not, you really don't care about that much as a backup operator. Either it compresses well or it doesn't, either your tape is full or it's not, it makes no difference. Most places swap out their tapes before they're completely full anyways (or spread backups across multiple tapes, basically striping / RAID0 / JBOD'ing them, depending on the exact software controlling the storage transfers). Example: one of my VMs that has a lot of media on it (pictures / videos / audio), the last backup taken (of the entire filesystem) has a compression factor of 31%. In this context (me knowing what the logs mean to tell me), this means the end backup is 31% the size of the original, *not* that 31% *was saved.* The media might not compress well, but the rest of the files sure do.
@@teknikal_domain But if most of your data is video, then it won’t be able to achieve that “average”.
@@lawrencedoliveiro9104 if they store uncompressed bitmaps, that might actually work out.
Man this takes me back! Back in the 90's I had a real job while in college and overbuilt a PC centered around SCSI devices. It was the best CD copier/game server on campus :-P
I used a Yamaha sampler which relied on SCSI for it's peripherals, well after the time the IDE standard became popular. I resented every over-priced hard drive I plugged into that machine, and don't get me started on how expensive the CD-ROM was. 😨
I have a mixing desk, come multi channel sound recorder, it has a SCSI disk in it, and you can connect an external cd-writter to it. Its a very good device but the disks where expensive. Most of those used SCSI for the DMA features to avoid burdening the very low end CPU they had. As EIDE became a thing in the 90s they could have swapped over without everything going too wrong.
@@RetroBytesUK It's like "musician tax". 😁
@@RetroBytesUK didn’t the later Emu samplers have IDE disks?
@@mudi2000a I would be surprised if it did not move over to IDE at some point, just as a way to keep costs down. After all they did have to compete with computers that where coming down in price, with studio grade outboard audio cards.
There were non-SCSI CD-ROM drives for Microsoft-compatibles in the early 1990s. Each one came with their own proprietary connector. Meanwhile, Apple Mac users had a range of SCSI-based drives to choose from.
I remember my mother used to work at the main office for a regional bank back in the late 90s. They still used the big single reels of tape. Whole room full of them, one wall of tapes always spooling and unspooling.
I'd really enjoy a video about fiber channel. It was something that existed on my university servers, but I never understood. Thanks for the video about SCSI. I had a lot of SCSI drives over the years, and now NVMe seems like magic to me.
I work with FC on the daily. It's neat in that it's a channel for moving packets. There have been implementations of IP over FC, but SCSI is the big one; also NVMe protocol over FC is available. FC's beauty is its inherent flow control through buffer-to-buffer credits, compared to something like IP where the endpoints manage themselves. There are trade offs in cost and port availability, but I've found FC to be bulletproof and simple to administer, basically set it and forget it.
I'm told the prevalence of FC depends on where in the world you are. In the US, I see a lot of FC out there, and the customers are dedicated. I predict NVMe over ethernet, specifically TCP, combined with faster ports at lower cost will peel off the low end of FC.
SCSI FCP is just a way to getting the SCSI over a Fibre Channel transport. I spent 20 years working with FC
I remember changing jumpers around with my scsi devices, thanks to the video brought me some memories. When I was a kid growing up, had scsi Iomega Zip drive, scanner, etc on Mac Quadra 650.
Apple has their adb bus used for low speed devices such as mouse, printers and keyboards. It looks similar to the PC PS/2 port.
I remember “SCUZZY” being a Dilbert joke 😂 I had a SCSI internal CDRW drive on the basis that IDE was still deemed to be a bit flaky at the time - I had an Adaptec 2940 PCI SCSI card that an acquaintance in IT gave me - I don’t think it would have been financially viable otherwise 😮
For someone who didn't grow up in this generation, THIS IS AWESOME TO LISTEN TO
One small note, modern IDE and SCSI hard drives do not use SCSI commands, it's only the optical disc drives that do. The reason why device names for them in Linux are sda, sdb, etc is because there is a translation layer (libATA) in the kernel.
@eDoc2020 - one typo in your post - I think you meant to type "modern IDE and SATA hard drives" ;)
I figured someone else would have already got in with this correction to the video.
The only type of IDE/SATA Direct Access Storage Device that uses SCSI commands would be an ATAPI removable disk drive like an LS-120 UHD floppy or maybe some late-model SyQuest/IOmega disks because ATAPI encapsulates SCSI commands in ATA ("IDE") ones. It is, of course, mainly used for ATA/SATA optical discs and tape drives.
Before libata, there used to be a special SCSI host bus adaptor driver in the Linux kernel called ide-scsi which bridged the two subsystems, claiming any ATAPI devices you reserved for it (by passing something like "hdc=ide-scsi" to the kernel) and making them appear as SCSI devices by stuffing the SCSI commands into ATAPI packets. This was essential for using IDE CD writers as cdrecord worked by issuing SCSI commands directly over the "SCSI generic" device associated with them. I remember, though, that (at least with my IDE controller), DMA didn't work with ATAPI so my shiny new 48X CD writer would fall back to PIO mode, limiting its speed to no higher than that of the old 4X SCSI one that it was supposed to upgrade, making the computer run very slowly and causing frequent buffer under-runs. I worked around this by popping an old SCSI-2 PCI card into the machine and using a hardware IDE-SCSI converter (the ACard SCSIDE) on the back of the drive so it would work as a native SCSI unit. I've since re-used the converter to attach a (relatively) modern IDE CD-ROM drive to my old Archimedes A310.
Parallel port IDE/ATAPI drives will soon be coming into the fold and appearing as SCSI disks (instead of /dev/pda etc.) too - the old PARIDE subsystem is soon to be no more and will be replaced with a libata driver. I should probably dig out my old SyQuest EZFlyer and test this.
@@molletts Yes I did mean SATA drives. Naturally SCSI drives use the SCSI command set.
I think some early Zip drives were true IDE, but all the ones I've seen have been ATAPI. This gives full native support for disk swapping but has the downside that you can't boot them without specific BIOS support.
I've never played with parallel port IDE devices. I don't think I knew that they would use device names like pda, pdb, etc.
I worked for Columbia Data Products, one of the first companies to clone the IBM PC.
After selling of their computer branch we focused on SCSI device drivers and SW sold via Western Digital and designed some custom cards of our own.
I used to get advanced versions of every new SCSI device to test my SW on -- so had the largest drives manufactured including Magneto Optics.
So all of this is like home to me.
We were also founding members on the ANSI X3T9. 2 Committee (SCSI standards) along with IBM & MS.
One thing that is interesting is that the SCSI bus & protocols also evolved into the CAN standards for automobiles and are still used today in car computers. The specs are virtually identical.
Plus we used SCSI for many NASA projects including the ISS & satellite data storage.
I really enjoyed my time with SCSI and what it has become and am proud to have been a leading contributor to the tech.
Even today I'm still trying to establish similar standard with other (new) computer hardware.
I really enjoyed you video. Reminds me when i was in the center of the computer universe.
My original pet peeves with USB all the way up to USB2 was yes technically the bus transfer was "fast", but often its implementation at the OS level was absolutely dogshit slow and useless for file transfer where speed was a factor compared with SCSI at the time. SCSI also didn't load up the CPU in the same way as USB where CPU-intensive applications needed every clock cycle they could get. USB had a lot of catching up to do, even in the home market. HUGE improvement over serial and parallel ports at home but that was about it and all I cared about USB for a long time.
Yep - I remember in 2010 being ASTONISHED that between the PC and USB 2.0 HDDs we had, that we actually got sustained data transfers of 30MB/s! That's HALF of the USB2.0 standard speed, and until that moment in 2010, I would always watch the transfer speed jump up and down and rarely ever reach that half speed, due to the issues you'd mentioned, along with drive controllers and slow flash / HDDs.
Nowadays I feel grateful when I can get 80MB/s or 100MB/s+ when using ANY storage - despite the USB3.2/4 and NVMe standards allowing ridiculous speeds these days.
The past couple of years I've slowly been planning getting 10GBe to the main devices I have at home over either fibre or CAT6e, so we're in a different world these days.
Takes me back to my time in publishing the 90s. SCSI, SyQuest Drives, Macintosh G3s, Quark XPress and motorbike couriers
At university I named my 1st hamster Scsi, late after university my second hamster was called Fast Scsi and my third hamster was called Fast Wide Scsi. When Fast Wide Scsi had babies they were called lba1 and lun1 and lun2
I remember building my first netware 3.11 server with adapter 1542 and later 1642. My last servers used the compaq proliant 1500 with the 68pin hot plug raid array and it still used the 1542 isa and ncr 801 pci controller for the tape drives. Btw I hated arcserve 6 for netware.
Arcserve was an utter pain, but I agree the netware verison was some how worse than the other versions. It also caused a few abends for us too.
@@RetroBytesUK I remember I was running a network for the head office of a very large steel maker we only had 300 users in the building but I had 9 proliant 1500 (which were a brand new back then) running netware. I implemented a strict test environment before I moved configuration to the live boxes everything from the c library to the bios config for the eisa bus was under scrutiny. I ended up putting arcserve on a bunch of other netware servers then remotely backing up the main servers because arcserve was such a pain.
I remember having 6 ibm model 95 servers running os2 and lotus notes server. And once noticing that if a user had left their mailbox or a database open it wouldn’t back up. So I designed an approach where we had a fairly generic server with a 9gb drive (.5 1/4 inch full height) it was considers huge back in 1995. And that box became the 7th notes server, during the day it replicated with all the other 6 servers and kept a copy of every database they had, then at 8pm every day it would shutdown notes back it’s self up with arcserve os/2 with two attached tape drives. Then restart notes. I called it the 3 2 1 backup 3 copies. 2 media 1 offsite
1 backup was on server 7 (no users attached)
2 tape backup were kept for 6 months
1of the tapes went off site outside London
Amazingly the SCSI protocol is still in use today for various devices like NVME drive interfaces designed for external USB storage drives.
I always find it fun to learn about tech that was obsolete before I was born.
Edit: we do kinda have a standard for USB inside a PC but it is mostly used to just connect to the front panel.
I use it to connect to my aio watercooler to control the rgb
Thanks! Always a wonderful ride.
Thank you Keith.
Surprised you didn't cover the rather important advantage of SCSI is that they auto-negotiated transfer speed for each individual attached device. This allowed one to make long chains of devices with different transfer speeds, and a [good] controller will ... just figure it all out. It therefore afforded many choices about upgrade paths, because one had the option to retain an old-but-good device for an indefinite amount of time, until truly superior replacement technology became available.
I remember SCSI controllers in servers in the 80's and 90's. A friend bought a very expensive PC with SCSI controller because he wanted to "future proof" his PC. There were all kinds of problems getting stuff to run with that controller, cannot remember what exactly, but when stock standard PC's with IDE controller and devices just worked, his PC didn't. And a couple years later his computer was rather slow.
Yay! SASI gets some love. I have a SASI controller in an old Cifer 1887 CP/M computer from 1983(ish). A Xebec 1410 with a Winchester 21Mb hard disk that howls like a banshee when it spins up. 😁
In 1999 I went to a LAN Party, a guy had a Win98SE box running off a top end 15,000 rpm SCSI drive. He restarted and Windows rebooted in about 30 second flat. It blew our minds. This was 15+ years before SSDs.
Wow, I happen to be the minority that has Fibre Channel. :) Sun Blade 1000 and 2000 workstations have FC-AL disks and one of those is on my desk. Retro computing is fun indeed. Great video, I actually now have something to show to younger colleagues when trying to explain what is SCSI.
22:20 The transfer rates and names of the various SCSI versions are almost the same as for the USB standard, only with MB/s instead of GB/s 😂
Great video!
My first experience with SCSI was with a SCSI Zip drive in my 486 PC when the very first Zip drives launched. Why not the much more common parallel version? I had pre-ordered my Zip drive through CDW and they had a package deal for the SCSI version with a 16 bit ISA SCSI card included for only $25 more than the bare parallel drive. Plus the SCSI Zip drive was 20-50% faster than the parallel version to boot.
Currently I have a HPE server in the next room humming away with a SAS RAID controller and 8 SAS HDD's in it with provisions to easily add 16 more drives externally if needed.
I'm sort of glad the video didn't go too much into SAS since that by itself would have easily added 5-10+ minutes of length with the different versions of SAS and things like SAS Expanders, multipath I/O and so on.
@7:26 RE: where with USB we don't have a separate "for inside the machine" standard.
Uhhh, yeah we do. We absolutely do. Old internal USB uses an IDC10 connector, and new USB3 uses a mini IDC20 connector. Many internal USB based devices (such as hubs or 5.25" bay SD Card readers, etc.) plug directly into these internal IDC style USB ports.
Hmm so that's what those 10 pin thingies are called; but its not like everything uses them exactly, well maybe modern motherboards do, feels more like an industry agreement. The actual usb port is using just 4 pins, with that feeding two ports. 20pins now? such a hassle...
The USB internal connectors are different to the external ones. They're just not used to connect anything internally, but typically only from front case USB or similar stuff.
Yes, that is true you do have the connectors for the usb ports fitted to the case.
@@RetroBytesUK oh I bet you’re enjoying having this said a hundred times hence
Thanks!!
Another fantastic video - I'm not sure if I missed it but I don't believe you mentioned that SCSI hard drives spun up to 10k and 15k rpm vs 5.6k and 7.2k rpm, improving access times and through put.
There were non-SCSI hard drives available at those faster speeds as well.
only when SATA came along to handle them.
@@GoatTheGoat Raptors.
@@GoatTheGoat of they did, they are as rare as hen's teeth :) Got a link I can check out, thanks!?
@@scality4309 link? Thanks
In the first decade of this millennium, I had a CD duplicator: I would put the original CD in the top drive, and it burned 8 copies simultaneously in the 8 writers within the same casing (I recorded speakers at conventions). These were all SCSI devices
Surprised that you didn’t include Apple computer. It is where I got my introduction to SCSI. It starting point for me at work, we had devices with SCSI and I needed to read up on it fast.
It's because I don't have one of the right period to show of scsi. The only 1 I have is PPC uses IDE.
He clearly mentioned 68000 architecture macintosh used SCSI.
I worked with SCSI ever since it was first released as a standard and something that has always amazed me is the number of times I've been asked to troubleshoot a system only to find that the SCSI chain either didn't have any termination, termination only on one end or in some cases three terminators. To me it was so simple to understand. The first and last device on the SCSI chain has to be terminated. If a controller has both internal and external SCSI connectors but only one controller then everything is going to connect to one chain. So if there's internal HDD's and a external Scanner the chain has to be terminated on the physically first HDD in the chain and at the Scanner, and the controller cards terminator has to be disabled. This simple thing tripped people up all the time.
Just to make it better if the external scanner or CD or whatever was the only device on the chain apart from the controller it would often kind of work without termination at the scanner. So when you got there and told the customer that they needed a terminator at the scanner end they'd often just look weirdly at you. Almost all scanners came with either a terminator you plugged in to the second SCSI port of the scanner, or a passthrough terminator that sat between the SCSI cable and the port on the scanner. But some had internal terminators that you enabled using a DIP switch.
Next problem was people not assigning a free SCSI ID and wondering why it didn't work with two or three HDD's using ID0...
Something that came late in the SCSI scanner market was scanners with only one SCSI connector. These could not sit at any other position than last in the chain. Weirdly enough some of these didn't have an internal terminator even though by design they were doomed to always be at the end of the chain.
As for server use, there were quite early a standard for hot-swappable SCSI drives. The connectors position on the drives was standardized which made it a lot less fristrating than trying to use IDE drives. With IDE every manufacturer had their own idea of where exactly on the drive the IDE controller and power connector were. I worked with storage chassis that had several backplanes you could swap in that allowed you to use IDE drives from different manufacturers be used. But you couldn't use for instance a Conner drive and Seagate, Western Digital or Maxtor drive on the same backplane. The alternative was to have a drive sledge that had an interposer of some kind which adapted the drive I/O to a connector that then mated with the connector on the backplane. But then you had a new non standard connector that could introduce problems. All of this finally got solved with SATA as now the dimensions and exact positioning of the connectors were finally standardized.
The controller situation was also interesting. As said SCSI was the grownup solution while IDE was the wannabee kids solution. But there were some who tried to make IDE controllers smarter early on. I remember a IDE controller with cache memory. I think it was 2 megabyte, and it had a battery backup. This was IDE, not EIDE or PATA. I can't say I noticed much of a difference but it was used in a server. No RAID functionality though. Still I think it was an interesting attempt.
Now something not mentioned in the video was a big limitation with the parallel IDE, E-ID and P-ATA world. While you could have up to two drives on one IDE controller only one of them could be active at any time. That is even with the fastest and latest standard that supported DMA and so on only one drive was active at a time. Want to read something from one drive and write something to the other drive? Well send the read request to the first drive and wait for the data. Only then could the controller yell at the second drive that it had data to send to it. This meant that copying files between drives on the same controller was a lot slower than if the drives were on different controllers. Motherboards toward the end of the parallel IDE era tended to have two IDE channels which effectively was two separate controllers so choosing where to connect the drives could be important for performance. With SCSI this was never much of a problem. The controller sent commands to the drives whenever the bus was available and didn't have to wait for them to locate the data and read or write it only to tell the controller they were ready. SCSI devices can even send data directly between each other without involving the controller, though this was not often used.
In the early 90s my school had a setup where we had SCSI hard drives shared between groups or 4 or 5 Acorns. The SCSI cable would run from one machine to the next. The hard drives would often fall over when we all drived to access the drive.
17:04 The IDE tape drive was most likely using ATAPI, which is a way of sending SCSI commands over IDE :D
During my us navy days as a submarine sonar tech, in the early 2000s we were transitioning from legacy bsy1 and q5 hardware to q10 arci (cots) hardware and everything HD related was scsi, for the servers and the raids etc. Everything ran on modified custom versions of Linux (various distros) It started to change in my final years around 2015 to other standards, fun video brought back some memories 😂
A couple notes about the relationship between IDE/SATA and SAS:
All IDE and SATA CD/DVD drives actually use SCSI commands internally. This is what ATAPI actually does - it tunnels SCSI data over the IDE protocol allowing devices other than hard drives to work.
SATA drives don't use SCSI commands. The reason SAS controllers can talk to both disks is that SAS was designed to use the existing SATA connector and electrical interface (but it can go faster), and SAS controllers have built-in support for both protocols.
I have only used linux for a timy bit so when you said that we may realized while using linux.. I was like “Nah, I didn’t used it enough for sure” and then I see /dev/sdc or /dev/sda and I was like “What the fudge? That’s how far back it goes?” Thank you for this video, it was a pleasure to learn a little more history of pre USB era :))
Still using u320 on a Lto4 tape external. Couldn't resist putting a terminator on it from the recycling centre even though it self terminates. It's never gremlined ever that I can remember,
The best bit about SCSI is the way you can have two controllers accessing the disks on the chain. Was handy to have an Amiga and a sampler both connected to the same disks, at the same time.
The initiator is normally ID 7 even on SCSI-II because at 7, it's halfway between the first seven and the last seven devices, making the access to both faster. I just replaced three 73 GB Ultra160 SCSI LVD 80-pin SCA drives with brand new 300 GB Ultra320 LVD drives at 75 euros per drive... brand new, and went for peanuts because nobody nowadays knows what to do with them. KNOWLEDGE IS POWER!
*Well actually* USB does have an internal standard, often called the usb header on motherboards :) It's actually just like what was going on with SCSI
I've said it before, I love that this channel goes into retro tech that's not just home computers. Having messed with SCSI in most of its forms, I never knew there was an Ultra 640, I thought it pretty much ended at Ultra 320 before going to SAS. Thank you
Sigh, quest
Still use SCSI in the form of iSCSI for a VMWare cluster of 32 blade servers talking to a storage server at 25Gbps. It really is crazy how after all these years, we are still using SCSI.
USB absolutely has a separate "inside the machine standard". It's not just used for front panel connectors, either. You often see it used internally from one internal connector to another for things like Bluetooth modules on PCI-E wifi cards, Thunderbolt cards, etc.
Thank you for the comprehensive breakdown of the evolution of the SCSI standard. This goes a long way to explain why some of us considered that sacrificing a goat to the SCSI bus could be beneficial to getting a specific SCSI installation working!
I have no idea how widespread use of SCSI was in electronic music gear, but the Roland VP-9000 VariPhrase Processor (sampler) had a SCSI connection. I got a floor model of one of those from Guitar Center for a sixth of MSRP. I gave up on getting it to connect to my PC and just used Zip discs. At least my struggle to get SCSI to work resulted in coming up on an huge HP flatbed scanner for cheap that still gives modern scanners a run for their money.
As a Datacenter guy, I appreciated you even bothering to explain FC at all. GG on the vid
Another occasional SCSI device in the 1990s was a slide camera. It literally had a photographic camera directed into a sealed compartment with some sort of high resolution image generator. Maybe a hi def CRT, I'm not sure. Could have been lasers. Each photograph would be exposed for some minutes while the image was scanned out. Later the finished film would be developed as 35mm colour slides for use in lectures etc. These were sharp as a tack, the thing was scanning thousands of lines per frame.
The one we used had a choice of connections. SCSI was fastest, but there was also GPIB, maybe others.
Great memories! My first PC was an Epson Equity II+ (80286-12MHz) with 256k VGA and a 40MB SCSI HDD. The first CD-R I ever burnt was done on a Pinnacle SCSI CD-R around 1995 (Smart & Friendly media) and IT IS STILL READABLE in 2023.
In the mid 90’s the only way to do digital video editing on a computer was with using SCSI drives. Boy these where expensives! Almost 1k$ for only a 4 Go HD! The last SCSI card and drive i used where lvd type and the card and a 10g drive did cost close to 2000$! I even had a SCSI CD burner that cost 499$. 😮 That’s in 90’s dolllars… then firewire and usb came along…
Thanks for the flashback, I remember when SCSI was first adopted, was huge back then...once it was widely adopted that is.
Back in the 2010s, I visited a big old data center and ended up in their lab. All sorts of weird hardware, but what stood out was a SCSI SSD from late 90s, made by some obscure Silicon Valley company. Size of an APC Smart-UPS, packed full with 128 Mb ECC SDRAM sticks and lead-acid batteries. 18.6 Gb size, about 40 lb weight. Unfortunately, it died in 2003, according to the sticker, and was never fixed.
And SCSI still exists today, in SAS
They're very much is a USB internal standard. It's the connector on the motherboard that the external port connects to. We're currently on version 3 of the port
UASP is a thing - USB Attached SCSI. It's basically SCSI command set over USB. It's used to stream data from storage devices over USB protocol in faster, more robust way than USB packets. It's used with SATA, SD and NVMe devices all the same.
There are reasons why FC got some advantages over iSCSI.
Link aggregation over FC is giving a single datastream the full bundled bandwidth of those ports combined, unlike Ethernet.
Although considering the amount of money you'll spend on everything...
Like licensing every single port on a FC switch.
Yet it's always interesting how and where different standards live on. Ceph cluster with SAS disks underneath and so forth.
Time for another layer of abstraction!
Still have my working Mac Plus sitting here. I originally only had the Apple 20Mb HD that interfaced through the external floppy connector. When I got my first SCSI 100Mb HD and plugged it into the SCSI-1 port, my computer was transformed. It felt like when today you replace your laptop's HDD with a SSD.
Also, loved the views of all the antique U.K. tech. It's not often in the 21st century that you get to see any technology with a "Made in England, Scotland, (or U.S.A., for that matter)" label. It makes me nostalgic for the days when cutting-edge technology made one think of words like Bletchley Park, Turing, and Colossus.
On the Amiga, SCSI meant the hard drives and other devices just worked.
On the A600 and A1200, the IDE driver is called scsi.device. But it doesn't know CD ROM. I can still remember it well. First load the ATAPI driver with the scsi.device from the ROM of the first hard disk, patch scsi.decive and then use the ATAPI driver after the soft reset, which can also address large hard disks.
With a real SCSI controller this was not necessary. It just works
Worked with Sun and Digital Equipment Corp and the SCSI equipment that connected to them for almost 20 years. Terrific working years!
For my personal 486, built up on an Adaptec controller, 2 disk drives, QIC-525 drive, and CD Drive.
Long live SCSI!
From the early 90s, thru till about 2010, I had a SCSI Card, or SCSI on the Motherboard of my computers. Several of my Scanners used the Interface, and I had a couple of SCSI Hard Drives. For the Time, they were quite a lot faster than the other HDs available then. Even my 1st CD Drive was SCSI thru the Sound Blaster Card
FYI: I actually worked at HP with the engineer tasked with the [or "their"] implementation of the SCSI command set for ATA disks.
Back in 1999 I built a workstation that had a 3-channel SCSI RAID controller with its own onboard 68020 processor, memory and a real time OS to handle all HD I/O. Each channel was bandwidth saturated with 2 Seagate Cheetah hard drives. My SCSI card also had my Plextor CD R/W drive and a legacy SCSI floppy drive. The 6 Cheetahs were configured in RAID 0 with stripe sizes such that nearly all my file read/writes were distributed over all the HDs concurrently. The real time OS on the card managed the disk IO in a semi intelligent way, doing things like ladder sorting and prefetching into the onboard RAM.
I used SCSI a lot in the 90's, and the big advantage I saw that you really didn't touch on much is it was intended for EXTERNAL devices. IDE was fine for internal hard drives or even optical drives, or some niche interface for your floppy, but if you wanted ANY of that to be external, SCSI was really your only option. Being able to chain it (hook more than two hard drives to your computer) then again SCSI was the way to go. You could install another IDE controller, but it'd only get you two more drives. At one point I had six external drives, all plugged into the one SCSI port on my computer. But at about that point, SCSI drives were getting out-priced by IDE which were getting quite common. I think the biggest SCSI drive I owned was a 56GB IBM drive. But at that point IDE drives were about 40% cheaper than the same size SCSI. Sure, SCSI was faster, but it was hard to get past the low price.
Also there's a lot of similarities when you compare SCSI-vs-IDE and USB-vs-FireWire. I think you missed out not including discussion of firewire. A very similar story where firewire was much better than USB, but lacked the ability to continue to scale up and was eventually surpassed by USB. My external storage evolved from SCSI drives in an external tower, to SCSI drives in a tower to IDE drives chained in a firewire tower. This allowed me to grow my storage using the cheaper IDE drives. The smallest IDE I had in the tower was 80gb (compared to the largest SCSI drive I ever owned at 56gb), and I continued to use that tower up to a mix of 250, 320, and 500gb IDE drives. That would not have been possible for me with scsi, as I never really ran into any larger SCSI drives.
iSCSI is now used in cloud computing as well, it's one of the ways that Oracle Cloud Infrastructure attaches disks to instances.
I used to manage a 24x3 fibrechannel raid array. Loved the tech, hated having to rebuild it.
It was like 10 TB. Which doesn't seem like much, but it was 10 TB of raid 5 with very smol drives in comparison to today.
IDE never adopted SCSI command set. It's partially true for ATAPI protocol but that is specific to removable media (CD/DVD, Zip, tape etc) - SCSI commands are tunneled over IDE/ATA. However normal hard drives have always used ATA command set, even to this day as SATA. On Linux side, there is a kernel translator that translates SCSI frontend commands to backend IDE/ATA commands. They're handled the same for the Linux kernel but backend drive command sets are still totally different.
Still have a SCSI CD-ROM drive that doubles as a portable CD player that my old dad uses when chilling in the back garden in summer.
This video does answer one of the mysteries of the universe, that is why I always had to plug that drive in last and set it to device 7. It was self terminating.
The original Atari ST used ACSI, a sort of cheapo SCSI cousin. In 1991 the Mega STe came with an internal SCSI hard drive (with a small adapter board plugged internally to ACSI, if I remember correctly it might actually been an Adaptec). The (originally intended as a UNIX workstation) Atari TT had both ACSI for backwards compatibility with peripherals and proper SCSI with a 25pin connector. The final Atari computer, Falcon030, had an external micro 50pin SCSI port (intended for external SCSI drives for direct to disk recording due to DMA benefits) and an internal IDE port typically used for a system disk.