On 11/4/10 11:20 PM, Brian Lanning wrote: Maybe, but its styling suggests that it predates widespread use of SCSI, and SCSI didn't make big inroads into the PC world anywhere near that era. That's kinda sick. I like it. :) Wasn't someone here looking for a PC- or XT-styled expansion chassis like this recently? -Dave -- Dave McGuire Port Charlotte, FL

On 11/4/10 11:46 PM, jim s wrote: Yebbut...That's a PC- or XT-styled chassis. Am I putting too much stock in that fact? -Dave -- Dave McGuire Port Charlotte, FL

On 11/4/10, Brian Lanning <brianlanning at gmail.com> wrote: Count carefully - if it's 60, not 50, and the smaller connector is 26 (I think), it could be SMD. I did that with one of those cases about 20 years ago when they were really cheap. I dropped in an early SCSI CD-ROM and a SyQuest 44MB drive in it and used them on an Amiga 3000. Still populated that way, though I haven't powered it on in a number of years. -ethan

On 11/4/10, Dave McGuire <mcguire at neurotica.com> wrote: Really? ISTR that chassis style was in vogue from about 1981-1986 or so. I'm not asserting that 5.25" SMD wasn't later, but I'm wondering about how much later. If it _is_ 60/26, I'd be surprised if it turned out to be something other than SMD. I think it's not enough pins for an ISA extension, but that's another possibility. I'm mostly speculating about what fits the external appearance based on all sorts of products that were available at one point. It really would help to know more about the internal cabling to make a more targeted guess. -ethan

How hard is it to fake out a SCSI tape drive interface with an FPGA/controller so that the tape data can be streamed from a file on another system? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Did I heard on the back "SCSI-to-SD-card-Adapter-open-source"????? :oD

This is something I always wanted to do. Maybe now I have enough free time :oD

That is what I say. Phillip is doing one for floppies (great work, man! :oD) and maybe it can be expanded somehow for ST-506 drives and - who knows - SCSI :o)

On 11/5/10, Dave McGuire <mcguire at neurotica.com> wrote: For drives that have 512-bytes-per-block (which is most of them), that's true, but there is the kink that really early SCSI devices, specifically many non-embedded drive controllers with attached drives (commonly MFM or ESDI) don't support the SCSI INQUIRE packet, so can't be easily connected to modern Linux/UNIX boxes. Probably nearly everything made since about 1990, though, "plug it in and use dd" works great. And, yeah, it was a PITA to connect them up back then too. That's why INQUIRE exists. -ethan

Ethan Dicks wrote: It's a bit more murky than that (albeit a related issue) because a lot of the bridge boards expect a vendor-specific command to tell them the drive geometry of the attached drive, and there's no opportunity for the system drivers to inject the necessary command. I did have a look at adding such a facility to Linux a few years ago - kind of "at init, consult list and throw these params at device xxx via vendor command yyy" - but looking at the spaghetti that is the Linux kernel source is probably what gave me so many grey hairs ;-) I've got a *lot* of stuff that just won't talk to a modern system. It's either almost-SCSI (i.e. lacking inquiry or other quirks), or SASI. I got most of the way through building my own interface board that I could just drive from my own software, but that was the point I moved to the US, and it's all still in storage back in the UK. cheers Jules

Dave McGuire wrote: I think the Adaptec was one of the most sane boards out there - IIRC it stores the drive geometry on block zero of the drive at format time, then at power-on fetches that block back and initialises itself with the loaded geometry. I can't remember if it just hides the first block from the user, or hides the whole track. I think the board responds to Inquiry, too (although it just returns "ACB 4000" rather than anything to do with the geometry of the attached drives) I've not played with the Emulex boards - I think the only ones I have are tape bridges rather than disk. The Xebec and Omti boards seemed reliable, but their SCSI implementations were a little lacking (one of them I think had the option of a user-supplied ROM with the expected disk geometry encoded into it, but it still wasn't "SCSI enough" to work with a modern system) Hmm, that's good to know. I'm hoping to get all my stuff moved here toward the start of next year, so maybe I can find a spare system and have a mess around with that then... cheers Jules

On Fri, 5 Nov 2010, Alexandre Souza - Listas wrote: I certainly hope you didn't miss the opportunity to beat the theif half-dead as an example to his peers... g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.

On Fri, 5 Nov 2010, Alexandre Souza - Listas wrote: Ye gods man. Get yourself a Desert Eagle .50 :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.

On Fri, 5 Nov 2010, Alexandre Souza - Listas wrote: Might I suggest an MP5K? :) g. -- Proud owner of F-15C 80-0007 http://www.f15sim.com - The only one of its kind. http://www.simpits.org/geneb - The Me-109F/X Project ScarletDME - The red hot Data Management Environment A Multi-Value database for the masses, not the classes. http://www.scarletdme.org - Get it _today_! Political correctness is a doctrine, fostered by a delusional, illogical minority, and rabidly promoted by an unscrupulous mainstream media, which holds forth the proposition that it is entirely possible to pick up a turd by the clean end.

On 11/5/10, Alexandre Souza - Listas <pu1bzz.listas at gmail.com> wrote: Is that the Telebit Trailblazer-compatible version of the BFG-9000? ;-) (not that anyone ever really called it that, but you could probably slap a "BFM-9600" label on the Trailblazer and someone would get the joke). -ethan

On 11/5/10, Alexandre Souza - Listas <pu1bzz.listas at gmail.com> wrote: That's pretty neat - a bit low on the capacity side, but it's cool to watch it log SCSI activity. Obviously a redesign of the storage-end of it wouldn't be a big deal. Could go FLASH, could go SDRAM. Could even do what some 3rd-party DEC drive emulators did - copy non-volatile to RAM at boot time, then RAM back to non-volatile when powering down. -ethan

On 11/5/10 5:13 PM, Ethan Dicks wrote: In fact there's at least one DEC product that does that. I have an ESE50, which is an RA90-form-factor drive, 640MB capacity. There's a 3.5" hard drive in the box along with a bank of batteries. When it loses AC power, it runs from the batteries and copies the contents of the RAMdisk over to the hard drive, and does the opposite on powerup. Neat stuff. I may try to put it on the PDP-11/70 at some point. -Dave -- Dave McGuire Port Charlotte, FL

Personally I've always felt Glocks were overrated. For casual carry I prefer a small Beretta, and if I can get away with it (in terms of concealment) a Sig-Sauer.

On 11/5/10, Alexandre Souza - Listas <pu1bzz.listas at gmail.com> wrote: As I mentioned in my recent reply to this thread, most of the time (nearly all of the time for stuff we on this list are likely to be working with these days), there is no strange formatting that's relevant. Long ago, we used to worry about what cylinder filesystems started on and optimizing things for head switching vs track stepping, but embedded SCSI (and IDE) drives hid so many of those details (and in many cases interposed a large on-board RAM cache) from the host that the art of tuning filesystems by position. The blocks themselves are nearly always formatted to 512 bytes per block (though in the earliest days, 256 bytes per block was not unknown), and the blocks can be just read out sequentially starting with 0000000 (which is something 'dd' is exceptionally good at). Another thing that changed was handling bad blocks on the disk - now, it's all hidden behind the scenes so that your OS "sees" a field of good blocks (previously, it wasn't unusual to have the OS-level driver participate in the sparing mechanism for using unallocated blocks/tracks to replace bad ones, or at least have a way to ignore bad spots - DOS floppies are a good example of that). Drives with analog cables to distinct read/write electronics are a different matter, but that's exactly what went away when the world turned to embedded-controller drives. You have a I/O-bus-like interface directly to the drive (digital data bus of 8 or 16 or more bits, handshaking, virtual I/O registers to read/write, a packet-like command structure, etc) that is from the view of the driver essentially identical to talking to an older-style controller card with detached drives. That's why 'dd' handles so many cases - you are just slurping sequential blocks from the media - you don't have to worry about head and track details, about vectoring off for bad blocks - a "perfect" disk image (until things start to go bad, then they go really bad, really fast). Hopefully this helps illuminate the arrangement some. -ethan

On Sat, Nov 6, 2010 at 4:43 AM, Ethan Dicks <ethan.dicks at gmail.com> wrote: Out of curiosity what determines the 512-bytes per block setting on a common SCSI hard drive? Is this done with low-level formatting and is that in the drives firmware or an external utility? I understand that the IBM AS/400 machines for example use 520-byte sectors, so does it mean that a common SCSI hard drive with 512-byte sectors can never be used with an AS/400 or is just a matter of low-level formatting? has anyone ever attempted this? I have an old CISC AS/400 and I am wondering what the long term options are going to be for spinning storage.

On Sat, Nov 6, 2010 at 11:47 AM, Dave McGuire <mcguire at neurotica.com> wrote: Any suggestions of a name I should be seeking? I presume this means that there is not something already open-source or built-into Linux (a device driver that could be altered)? This latter aspect might need to be explored since if I want to 'dd' the contents for a backup then I would need to construct a way to save the extra bytes.

On 11/5/10 5:56 PM, Nigel Williams wrote: You need to write something to deal with non-512 byte blocks using low-level SCSI commands. I had to do this to archive TI Explorer drives with 256 byte sectors (done a LONG time ago as a Mac OS 9 app). It's not difficult to do, you have to remember to build in a way to continue and flag blocks that couldn't be read.

On Sat, 6 Nov 2010 11:56:24 +1100 Nigel Williams <nigel.d.williams at gmail.com> wrote: format [blocksize [immediate]] (Low level) format the named device. If the optional blocksize parameter is provided, the device geometry will be modified to use the specified blocksize. If this parameter is different form the Current or Default Mode Page 3 parameters, the device will update Mode Page 3 at the suc- cessful completion of the Format. Device geometry may change as a result of using a new device blocksize. When the optional blocksize parameter is specified, the Defect List on the drive will revert to the original primary defect list created at the time of manufacture if available. The drive will usually recertify itself during the Format and add any other defective blocks to the new Defect List. Some disks may not support the ability to change the blocksize and may enter a Degraded Mode when fed a Format command of this type. If this happens the standard recovery for the drive requires issuing a correct Format command, i.e. one without the blocksize parameter. -- \end{Jochen} \ref{http://www.unixag-kl.fh-kl.de/~jkunz/}

Never. That's why I'm so interested. Seems something interesting to loose some time. Who knows I can create a sd-card-to-scsi bridge? :) He had a 9mm pistol on his hand, I don't think it would be smart :( This is **VERY** interesting. I think I'll buy a zip drive tomorrow and one or two zip disks and begin to read/write things to see how it works. So bad I'll stay "grounded" for about 2 to 3 months before my new lab gets ready :( I'll do something even on kitchen table :D

scsi with avrs sounds interesting. found following links - i think this should be enough stuff for inspiration ;) http://micha.freeshell.org/ramdisk/index.php ^^^ there should be enough stuff in my grab-box; would be a nice project... http://instruct1.cit.cornell.edu/courses/ee476/FinalProjects/s2001/sjk26/De… http://micha.freeshell.org/pcmcia_drive/index.php 73s wolfgang -- Wolfgang Eichberger - OE5EWL Operating System Research Blog: 5ewl.blogspot.com Homepage: www.eichberger.org 2010/11/5 Dave McGuire <mcguire at neurotica.com>:

On Fri, Nov 5, 2010 at 11:45 AM, Dave McGuire <mcguire at neurotica.com> wrote: For us n00bs, what's the next step? If it's a drive from a (for example) SunOS box, you hook it up to a Solaris machine, mount it, identify it as something you want, dd it and it is preserved. What if you have (as I and probably most of you do) a pile of completely unknown SCSI drives? So you hook it to your nearest *nix machine, dd it to a file, and the drive is free to head crash and become scrap. Now what do you do with that image? I'd guess the next step is to try to mount that dd'd image somewhere. Is there an easy way to ID the filesystem of a foreign drive, or is it trial-and-error at that point? -- jht

Do you know of ANY drive that the continued operability isn't suspect? :oP

I don't believe someone (beyond Tony) would do that ;o) Maybe an open-source program which could open an image file and "autodetect" it, saying which format/os/etc it is? :)

On Fri, Nov 5, 2010 at 2:08 PM, Ethan Dicks <ethan.dicks at gmail.com> wrote: Thanks Ethan and Dave McG! I suspected it would turn into a bit of forensics and sleuthing...which makes it more fun, even if it's a bit more work :) I have a lot of drives laying around that are totally unknown, either because I bought/received them as spare parts or they were (foolishly) removed from a machine that is now gone. I'd bet I've got IRIX, SunOS, Solaris, Amiga, Mac, DOS, HP/UX, VMS (those are kind of easier to spot)...the list goes on. Someday I'd like to offer data recovery as a paid service. Sounds like I've got a lot of practicing to do :)

On 11/5/10 12:34 PM, Jules Richardson wrote: I do. :) I don't much relish the idea of connecting a big thick SCSI cable between two computers when the connection is going to end up being temporary. It just sounds like a pain. That'd be pretty easy; it could basically be a transport layer translator to bridge parallel SCSI with iSCSI. -Dave -- Dave McGuire Port Charlotte, FL

On Nov 5, 2010, at 1:14 PM, "Alexandre Souza - Listas" <pu1bzz.listas at gmail.com Yes, but the SCSI ID of one needs to be changed. Yes. -Dave -- Dave McGuire Port Charlotte, FL

On 11/5/10 1:51 PM, Jules Richardson wrote: That'd be a high-level driver limitation. There was a project a long time ago in which the onboard SCSI interfaces of a group of SPARCstations was used as a cluster interconnect. It used an IP-over-SCSI driver that made things easy to configure. It's part of the spec. The interfaces will negotiate the best speed and width that both endpoints can support. It's all extremely clean and scalable. (which is why it's still around) -Dave -- Dave McGuire Port Charlotte, FL

At 12:43 PM 11/5/2010, you wrote: All you need to do is incorporate the blood sacrifice into the FPGA. That's the way we fixed SCSI issues in the old days. The advantage would be that there are iSCSI devices and implementations already out there. There are downloadable VMware appliances to handle it, which makes the contemporary end a snap. I think there'd be a reasonably big market for a USB breakout device of some kind. I've tried several USB to IDE/SATA gizmos on dozens of semi-flakey drives, and WinXP tends to go into la-la land if the USB side isn't responding the way it should (which it'll do if the hard drive isn't responding the way it should.) I'd pay $200-300 for a device that would show me in great detail what's wrong, allow for a write-protect to keep Windows from writing to it, and/or allow me some alternative methods of getting to the drive's data. Sounds almost like some forensic recovery devices, but with more debugging output. Same for old SCSI, no? Somewhere in my junk piles I have a SCSI pass-through board with an LCD display that showed a count of blocks read/written. Why not more info? - John

At 01:04 PM 11/5/2010, Dave McGuire wrote: Sure, I'd like one of those, too. What exists for IDE, SATA and USB-IDE/SATA? - John

In article <4CD425A8.2080902 at bitsavers.org>, Al Kossow <aek at bitsavers.org> writes: "SCSI target disk mode code" um.... are you talking about a code value in the SCSI command stream or are you referring to some piece of source code? If the latter, which source are you talking about? -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/> Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

Richard wrote: At the theoretical level, the SCSI part's probably not too difficult - software-wise, I don't think the minimal command set needed to look like a SCSI tape device is particularly complex. The physical interface is simple enough, too. What I have no clue about is anything to do with FPGAs, though, or how easy it'd be to do the "communicate with another system" bit (via what - ethernet? USB?). I've got a bunch of Torch Manta SCSI-floppy bridge boards in storage, and those were quite neat - they use a NCR 5380 IC as the SCSI controller and Hitachi 63B03 as the CPU (along with some local RAM and ROM, and a 2793 FDC). In this day and age though, maybe there's no benefit to having a dedicated SCSI chip, and a FPGA would be able to twiddle signals perfectly fast enough* to keep up with demand - but that would have been the old-school way of doing it. * ISTR there being some timing constraints in SCSI when acting as a target - the host can take as long as it wants about things, but for certain actions the target is expected to respond within a certain time. All of which perhaps doesn't really answer your question, other than to say "it's easy for someone who knows how" :-) cheers Jules

On 11/4/10, Dave McGuire <mcguire at neurotica.com> wrote: As was mentioned, that's one DB25 and one DD50. Without seeing the cables inside, one thing I thought of was it _could_ be an external ESDI or SMD case. DD50s were used for several things including Sun SCSI before SCSI-2 connectors. -ethan