A PC with a SCSI card in 'Target Mode' as a replacement HDD?

[IBM Portable PC]

I've been meaning to try SCSI Target mode for years and have finally had a brief but highly successful play i.e. setting up a PC (Pentium running PCDOS 7) to appear as a SCSI hard drive to any machine connected to it's SCSI port i.e. one computers SCSI port to another. The virtual drive, which is a RAM drive on the host, is currently limited to about 65MB. This of course is more than enough for many vintage machines. The RAM drive can of course be easily saved and reloaded and appears as a single fine on the host.

Look at:

https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q="8xxtarg.zip"&safe=off

and you will easily find 8xxtarg.zip which contains the sample code that was released by Symbios Logic in the 90's. You may also like to download some product manuals for suitable Symbios Logic SCSI controller chips.

After setting up a PC with an appropriate Symbios Logic PCI based SCSI controller and ASPI driver, you simply run the 8xxtarg.exe. It asks for various options and then the PC appears on the SCSI bus as a hard drive. The simulated drive is in RAM on the PC and can be saved and loaded.

Symbios Logic supplied full source code in c and so now what I need, is for someone to make the required change/s to support 256 byte sectors (currently only; 512, 1024, 2048 and 4096 are supported) for use with and Acorn BBC Model B and perhaps another system or two. Adding a menu option to enable/disable SCSI parity would also be wonderful.

8xxtarg.exe appears quite stable, from another vintage PC I've been able to happily FDISK and FORMAT /S to my hearts content and can also verify that the saving and loading of the virtual drive works well. These can then be readily uploaded and shared.

 

[IBM Portable PC]

Here's a little more......

Few SCSI adaptors appear to have supported SCSI Target mode, however Symbios Logic had several SCSI controller chips that did:

"The SYM53C7XX/8XX/10XX family of chips run on target as well as host devices. Target operation is very similar to host operation, except that the SCRIPTS processor responds to SCSI commands from the host rather than initiating the commands. " Symbios® SCSI SCRIPTSTM Processors Programming Guide Version 2.2 page 11-1

Unfortunately 53C7XX onward do not support an ISA bus I.e. We have to use a new fangled PCI bus machine as the virtual drive.

Lastly, I am now very pleased to be able to report that I can now repeatedly boot my Tandy 1000 XT clone with PCDOS 7 from the Pentium 166 Hosts Target 65MB RAM based simulated drive.

 

[mbbrutman]

That is pretty clever. I was aware of target mode and have heard of it being used on other systems, but I also thought that it was not implemented on many low end PC class SCSI cards. (I think I had heard about it being used to connect two SUN systems.)

SCSI was a wonderful bus at the time. I've owned SCSI hard drives, CD-ROMs, Zip drives, tape drives, and a scanner. I know that some early Macs used SCSI to connect Ethernet controllers, and that there was a SCSI printer floating around somewhere.

 

[IBM Portable PC]

...........SCSI was a wonderful bus at the time........

If you're into Vintage kit, then that 'time' is now!? IDE and CF etc is great, but a little too contemporary for my liking. Also for system that require 256 Byte Sector drives, a solution needs to be found. Hacking the vintage OS would perhaps be ideal, however it could lead to other issues. For my part, The Acorn BBC Model B DFS ( http://en.wikipedia.org/wiki/Disc_Filing_System ) and a couple of Microware OS9 ( http://en.wikipedia.org/wiki/OS-9 ) systems are my focus, both strictly supporting 256 byte sectors.

 

[mbbrutman]

No, I think SCSI's time has passed.

I have my stockpile of SCSI drives, but realistically they are all getting pretty old. The last parallel SCSI drive was probably made over 10 years ago. For mass storage, some sort of FLASH based device with emulation will probably be the long term solution.

IDE and SATA interfaces won for mass storage uses on home systems. SAS is SCSI at heart, but too expensive for most home users. And the non-mass storage uses are pretty limited; nobody is making SCSI scanners, Ethernet adapters, or printers anymore. ;-0

SCSI had a few advantages, including being able to handle 256 byte sectors. My older Bernoulli Boxes use that sector size too. It's hard to find anything that will talk to them.


Mike

 

[lowen]

... For mass storage, some sort of FLASH based device with emulation will probably be the long term solution.

Such as: http://shop.codesrc.com/index.php?route=product/product&path=59&product_id=50 ?

IDE and SATA interfaces won for mass storage uses on home systems. SAS is SCSI at heart, but too expensive for most home users. And the non-mass storage uses are pretty limited; nobody is making SCSI scanners, Ethernet adapters, or printers anymore. ;-0

IDE does not equal ATA (even though common usage wants to make it that way.....). SATA has won for consumers; SAS has won in the enterprise, even in areas formerly dominated by fibrechannel. But SATA drives can be used most of the time with SAS controllers (the reverse is of course not true).

SCSI had a few advantages, including being able to handle 256 byte sectors. ...

I don't know if M-Systems old FFD's can do 256 byte sectors or not (I have an 896M Wide SCSI FFD-350-896-TC15 here... pic follows) :



M-Systems also made ISA flash disk cards; older Cisco PIX used them, among others. There are several on eBay right now; search for "M-systems PC-FD" in Computers (the 'similar items' search will show up a lot of non-computer-related items, some of which may be NSFW.....).

 

[IBM Portable PC]

......... I don't know if M-Systems old FFD's can do 256 byte sectors or not (I have an 896M Wide SCSI FFD-350-896-TC15 here... pic follows)...........

M-Systems also made ISA flash disk cards; older Cisco PIX used them, among others. There are several on eBay right now; search for "M-systems PC-FD" in Computers (the 'similar items' search will show up a lot of non-computer-related items, some of which may be NSFW.....).

Even if they do support 256 Byte Sectors, how do we back them up or share them etc? With a SCSI Target solution, and as a starting point 8xxtarg.exe as supplied by Symbios Logic, we can not only create a very fast RAM drive but we can easily backup or share the resulting drive as it's simply a single file on the host.

I'm about to begin playing with Borland C++ 4.5 with a view to pursuing this further..............

 

[IBM Portable PC]

Such as: http://shop.codesrc.com/index.php?route=product/product&path=59&product_id=50 ?

This is clearly another solution, however, again how do we create a backup or share an 'image' of the 256 Byte Sector virtual drive it will simulate?

 

[gslick]

After setting up a PC with an appropriate Symbios Logic PCI based SCSI controller and ASPI driver, you simply run the 8xxtarg.exe. It asks for various options and then the PC appears on the SCSI bus as a hard drive.

What model card did you use? Which version of the controller chip is on it?

I wonder how hard it would be to implement a SCSI tape drive target, at least with read only tape images.

 

[IBM Portable PC]

What model card did you use? Which version of the controller chip is on it?

I wonder how hard it would be to implement a SCSI tape drive target, at least with read only tape images.

As I only had an ISA based 8088 system whilst the Symbios Logic SCSI controller chips supporting Target Mode all require the PCI bus (53C6XX onward I believe), I purchased a HP 800CT Omnibook. It's a Pentium 166 90's style sub-notebook with a Symbios Logic 53C810 on the motherboard, making it a very compact self contained 'hard drive'. I replaced its hard drive with a compact flash card and loaded PCDOS 7, which it runs rather well to say the least......

 

[IBM Portable PC]

A few manuals:

http://www.cebix.net/downloads/bebox/53c810a.pdf

http://www.causeuse.org/hauke/macbsd/symbios_53cXXX_doc/symbios_8xxpg_21.pdf

http://www.causeuse.org/hauke/macbsd/symbios_53cXXX_doc/

http://www.tenox.net/docs/scsi/the_programmers_guide_to_scsi_brian_sawert.pdf

http://bitsavers.informatik.uni-stuttgart.de/pdf/ncr/scsi/NCR_53C810_PCI-SCSI_IO_Processor_Nov92.pdf

http://bitsavers.informatik.uni-stuttgart.de/pdf/ncr/scsi/

 

[lowen]

This is clearly another solution, however, again how do we create a backup or share an 'image' of the 256 Byte Sector virtual drive it will simulate?

As the SD interface also uses 512 byte sectors, the simulator shim must be doing something like what EMC's Emulex-based fibrechannel to SATA shims do.

A bit of background:
EMC, NetApp, HP, and many SAN vendors use host-based error correction for drives, so that they can better track sector errors and predict failures, many times weeks before the drive actually fails. I've seen this this past week on our EMC Clariion ( https://en.wikipedia.org/wiki/Clariion ) CX4-480 here; Bus 3 Enclosure 1 Disk 5 was beginning to fail, and the storage processor e-mailed me suggesting I proactively hot-spare the drive. I was curious as to how far ahead it would actually predict, and got an interesting answer: it was over a month later that the drive actually faulted (as it was in a RAID6 RAID group I wasn't worried about data integrity). (Incidentally, our CX4-480 has about 200TB of storage, split up among 73GB 15,000 RPM and 500GB 7,200 RPM FC drives; over 400 drives in total in the array.)

But in order for the storage processor to do this kind of low-level drive management, the drive itself cannot do its own error correcting, which all consumer drives do. That's one reason an EMC drive with EMC firmware would make a lousy drive for a PC, since the drive's customized (by EMC) firmware does absolutely no error correction, but leaves it up to the storage processor. This requires a 520-byte sector size, which SCSI, SAS, and real FC drives can do. (512 bytes plus 8 bytes of storage-processor-generated ECC). It takes up the same space on the disk, since part of the process is to turn off the disk's built-in ECC.

SATA drives cannot do the real 520-byte sectors, but EMC does actually produce SATA drives for their fibrechannel arrays. The 520 byte sectors are blocked and deblocked by either the shim card that also adapts from FC-AL to SATA or by the storage processor itself (I'm not sure which).

So I would assume that the SCSI2SD card's 'shim' (it does more than that, of course) does the blocking and deblocking into 512 byte sectors on the SD card. I'm not familiar with the specifics of the SCSI2SD card's image format; you'd have to dig a bit deeper.

The FreHD for the TRS-80 does the same thing; the TRS-80 uses 256-byte sectors, but the SD card on which the images are stored uses 512-byte sectors and the images are stored as files in a FAT filesystem on the SD card. The images can be backed up as regular files on a Linux box, PC, or Mac without problem.

Advanced Format 4K sector drives can typically do the same thing, blocking and deblocking 512 byte logical sectors into the 4K physical sectors; the concept is still the same.

Oh, and do note that the original Clariions were, I think, basically what you're wanting to do but in a proprietary form, using target-mode SCSI interfaces on the front end ports to the storage processors. (Target mode is also supported by many fibrechannel cards).

 

[mbbrutman]

This is a bit off topic, but all enterprise class drives do their own error correction in the drive hardware and firmware. And they do a lot of it; the error detection and correction is very robust compared to consumer quality drives.

The additional 8 bytes you are referring to that makes the sector size 520 bytes on those storage arrays is added by the SAN hardware and it is not low level error correction data. In a stand-alone system those eight bytes could be used for T10 "end to end" protection. In a SAN environment the SAN provider can use those eight bytes for whatever they want. No doubt it is used to detect mis-reads from the drive, but the drive still does all of its normal error detection and correction too.


As for the poor vintage machines with 256 byte sectors, a simple solution is just to only use half the storage capacity of the drive. Write the host data down, and then pad the rest of the sector with zeros, a duplicate copy of the data, or whatever.


Mike

 

[lowen]

This is a bit off topic,

Yes, it is, I know.

but all enterprise class drives do their own error correction in the drive hardware and firmware. And they do a lot of it; the error detection and correction is very robust compared to consumer quality drives.

This is true of most enterprise class drives; but EMC-branded FC drives (with the possible exception of the 7200 RPM FC units), while they do more robust error detection they also don't put forth as much effort into the error correction, but leave that to the storage processor (it's what RAID is for, after all). I can't tell you how I know that or from whom I heard that information, sorry. But I wasn't fully correct stating it in a way that made it sound like the drive did no error correction; that is incorrect.

The additional 8 bytes you are referring to that makes the sector size 520 bytes on those storage arrays is added by the SAN hardware and it is not low level error correction data. In a stand-alone system those eight bytes could be used for T10 "end to end" protection. In a SAN environment the SAN provider can use those eight bytes for whatever they want. No doubt it is used to detect mis-reads from the drive, but the drive still does all of its normal error detection and correction too.

EMC documents what they put in those 8-bytes; see: http://storageinternals.com/emc-storage/35-clariion/54-data-integrity-in-the-flare-environment for a plain HTML version (there is a PDF out there called 'Clariion Consolidation and Data Integrity' that is a set of slides from EMC, but I would be careful loading a random PDF in Adobe Reader (NoScript detects a javascript embedded in the PDF; could be a virus, so view with care).

But the reason I brought it up was simply to show how odd sector sizes can be supported on devices with a fixed 512 byte (or 4K byte) sector by blocking and deblocking.

As for the poor vintage machines with 256 byte sectors, a simple solution is just to only use half the storage capacity of the drive. Write the host data down, and then pad the rest of the sector with zeros, a duplicate copy of the data, or whatever.

This is what the 'Cheap-o' TRS-80 IDE interface ( http://www.vintage-computer.com/vcforum/showthread.php?37717-Cheapo-IDE-interface-for-Model-4p-running-MM-CP-M ) basically does, but using every other byte (using 8 bit transfers instead of 16 bit ones).

 

[lowen]

Well, in a bit more on-topic mode, I decided to pull the cover and boards of the M-sys FFD SCSI Flash drive. I got a bit of a surprise.

Look at the photos and see how close the idea of a 'PC with a target-mode HBA' is to reality:


A bit closer look at the processor:


(yes, it is what you think it is.... and here's the wikipedia article on it: https://en.wikipedia.org/wiki/Intel_80386EX)

A look at the three-board stack on it's side, and with the processor/interface card flipped over:

 

[IBM Portable PC]

Look at the photos and see how close the idea of a 'PC with a target-mode HBA' is to reality..........

A SCSI Target mode is a reality thanks to Symbios Logic 8xxtage.exe which works very well, see below).

I'm just working toward adding:
- 256 byte sector support.
- SASI / SCSI 1 support, if required.
- Parity enabling/disabling.

Borland C++ 4.5 here I come.........

 

[gslick]

I might have to pick up a cheap Symbios NCR8100S 53C810 adapter to give this a try. Looks like an interesting way to experiment with SCSI.

 

[IBM Portable PC]

Here's the c source for 8xxtarg.exe.

View attachment MAIN.C.zip

I'm a virgin to c, however even I can see the block size variable. I've spent 10 minutes on this, however I suspect that allowing 256 (and perhaps 128 and 64 [I believe some vintage systems went down to 64) byte sectors may be simpler than I thought. It's 'simply' sending data to Target SCSI Host, on which the 'drive' is 100% in RAM and so we're not writing 256 byte sectors directly to the hosts drive etc. 8xxtarg.exe then saves the data in RAM as a file and I suspect that it doesn't care whether the block size variable was; 4096, 2048, 1024, 512 or for that matter 256,128 or 64.

I overlooked the fact that the 'drive' size is simply limited by the amount of RAM on the host system. I can live with the 64MB on my HP Omnibook 800CT for now, most SASI systems had only 5,7,12 or perhaps 20MB drives attached.

The SCSI Parity Enable/Disable option will require a little thought whilst ensuring compatibility with SASI/SCSI1 may best be achieved by 'simply' ensuring that no SCSI-2 commands are used and of course this may not be a trivial exercise.

This will have to wait now until I receive my Borland C++ CD from Amazon (it includes PDF's of all manuals i.e. iPad food) for about $20.

 

[IBM Portable PC]

I might have to pick up a cheap Symbios NCR8100S 53C810 adapter to give this a try. Looks like an interesting way to experiment with SCSI.

I think so and more importantly I can't see a better solution to replacing, or creating, 256 Byte SASI drives. SD/CF are well and good, but how do we back them up whilst I love the idea of being able to share the 'drive' files from 8xxtarg.exe.

 

[lowen]

I think so and more importantly I can't see a better solution to replacing, or creating, 256 Byte SASI drives. SD/CF are well and good, but how do we back them up whilst I love the idea of being able to share the 'drive' files from 8xxtarg.exe.

I believe that you may be misunderstanding something rather basic here. To the best of my current knowledge, neither SD nor CF support non 512-byte sectors in the 'ATA disk' version (linear flash might, but I'm not sure SD is available as Linear flash, while PCMCIA and CF are). Any adapter that is using SD or CF for non-512-byte sector sizes will be doing the blocking and deblocking I mentioned before, or will be just throwing away capacity as has been mentioned. You would be able to back up the SD or CF card just like any other SD or CF card, but you might have to deal with geometry issues, depending entirely upon how the non-512 byte sector size is being supported by the controller that is doing the adaptation to CF or SD.

SCSI target mode is, incidentally, available for the Linux kernel in two forms, with support for a number of different interfaces. See http://scst.sourceforge.net/ for one of them; the other, in-kernel-default, one is http://linux-iscsi.org/wiki/Main_Page

Do realize that Symbios' code is intended as sample code, not a comprehensive bug-fixed server.

It is cool, though, and that same code could easily be used with an embedded processor to, I don't know, make a flash drive with a SCSI interface... oh wait, M-systems did do that.

But again note that Apple did this; when I first posted I erroneously thought that it was Firewire only; but it's not. See https://en.wikipedia.org/wiki/Target_Disk_Mode

Both the M-systems embedded i386 case and the Macintosh case lend validity to what you're working on, by the way. I'm not bringing these up to try to discourage you in any way, just to let you know that it has been done before and can be done.

Also note that the SCS2SD code is completely open, and you could read it to see how the non-512 byte sector support is actually implemented; see http://www.codesrc.com/mediawiki/index.php?title=SCSI2SD