19 Jan
2007
19 Jan
'07
2:35 p.m.
Actually, I've never needed to try this - but is
it reasonable to expect a
"modern" system to be able to archive (using dd) a SCSI drive that's been
formatted to something other than a 512 byte block size?
I think it is. Modern systems will be the ones that have mass storage systems
and networks capable of dealing with disc dumps.
When I've done this, though, I've written my own disc dumping code using SCSI
command blocks to the low-level interface.
This was necessary for archiving TI Explorer discs, which have 256 byte blocks
but are SCSI devices (MFM drive and ACB 4000 host adapter).
19 Jan
19 Jan
3:53 p.m.
In article <45B11D81.3090603 at bitsavers.org>,
Al Kossow <aek at bitsavers.org> writes:
When I've done this, though, I've written my
own disc dumping code using SCSI
command blocks to the low-level interface.
Is this tool available, should it be necessary?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7:18 p.m.
New subject: macintosh retrospect 2.0 backup
Someone approached me about some "prior art" and I am now looking at
some 1/4" carts marked "quadra 950 retrospect 2.0 mac os" I made in the
early 1990's.
If somehow I could find a working 1/4" drive (scsi) and got it connected
to a macintosh,
Is there any hope I could find a copy of retrospect 2.0?
anyone else ever try this?
it's probably hopeless, but it might be a fun ride. hard to say.
good thing I saved that powerbook 145b :-)
-brad
8:17 p.m.
New subject: macintosh retrospect 2.0 backup
I have a legit copy of Retrospect 2.1 on my shelf and plenty of Quadra 950's
as well but no 1/4" (QIC I would think) drives, just DDS 1,2,4 DAT Drives. I
can make a few disk images if you want the Retrospect program (should work
on 68K as well as PPC Mac). There is Retrospect sold for the PC as well that
should read the Mac versions tape, QIC drives are cheap and plentiful for
the PC. If you try to read them on a PC just make sure that the restore
drive does not use FAT for formatting since it will screw up the Mac data
fork making the files unusable (unless they were compressed with something
like Stuffit before they were backed up). NTFS will not harm old Mac files.
PS My copy of Retrospect could read files saved on the Apple Workgroup
Server 95 which was an Apple 950 plus a special PDS SCSI card that ran A/UX
3 which had a unix version of Retrospect built in (I have that as well).
TZ
----- Original Message -----
From: "Brad Parker" <brad at heeltoe.com>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Friday, January 19, 2007 7:18 PM
Subject: macintosh retrospect 2.0 backup
Someone approached me about some "prior art" and I am now looking at
some 1/4" carts marked "quadra 950 retrospect 2.0 mac os" I made in the
early 1990's.
If somehow I could find a working 1/4" drive (scsi) and got it connected
to a macintosh,
Is there any hope I could find a copy of retrospect 2.0?
anyone else ever try this?
it's probably hopeless, but it might be a fun ride. hard to say.
good thing I saved that powerbook 145b :-)
-brad
4 p.m.
Al Kossow wrote:
Interesting. What OS platform and HBA was this for?
I've been on the lookout for some sort of solution for a few years, but so far
haven't found anything for Linux, DOS, or Windows that'll do the job. I don't
mind coding SCSI commands in C using such as Linux's 'sg' interface, but I
wouldn't know where to start when it came to programming a HBA itself.
I know that Linux "offlines" any device that doesn't meet more modern SCSI
protocols (in particular it hates anything that doesn't support a native
Inquiry command at boot time - which rules out a lot of vintage SCSI devices
even though they're otherwise compatible electrically). Perhaps other OSes are
better suited though and I've just not stumbled across the right code anywhere.
It may be that you were just "lucky" though. I have a feeling that the ACB4000
may well be unusual for devices of that sort of time period, in that it's
"proper" SCSI rather than SASI or "SCSI with bits missing". It well
just
cooperate with low-level drivers well enough to allow the user access once the
OS has booted.
Devices from Emulex, Xebec and OMTI are probably less-compliant (and the most
recent I've found is the Philips VP-415 laserdisc player), but as a community
we could do with a way of talking to them from "modern" hardware.
cheers
Jules
Actually,
I've never needed to try this - but is it reasonable to
expect a
"modern" system to be able to archive
(using dd) a SCSI drive that's
been
formatted to something other than a 512 byte
block size?
I think it is. Modern systems will be the ones that have mass storage systems
and networks capable of dealing with disc dumps.
When I've done this, though, I've written my own disc dumping code using
SCSI command blocks to the low-level interface.
This was necessary for archiving TI Explorer discs, which have 256 byte
blocks but are SCSI devices (MFM drive and ACB 4000 host adapter).
5:18 p.m.
Al Kossow wrote:
yes, I found linux to be incapable of dealing with scsi disks formatted
to non-512 byte multiple blocks...
you end up having to write your own code or hack the o/s to deal with it.
-brad
Actually,
I've never needed to try this - but is it reasonable to expect a
"modern" system to be able to archive (using dd) a SCSI drive that's been
formatted to something other than a 512 byte block size?
I think it is. Modern systems will be the ones that have mass storage systems
and networks capable of dealing with disc dumps.
When I've done this, though, I've written my own disc dumping code using SCSI
command blocks to the low-level interface.
5:27 p.m.
In article <200701192218.l0JMIOPV028667 at mwave.heeltoe.com>,
Brad Parker <brad at heeltoe.com> writes:
yes, I found linux to be incapable of dealing with
scsi disks formatted
to non-512 byte multiple blocks...
How about Solaris/SunOS?
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://www.xmission.com/~legalize/book/download/index.html>
Legalize Adulthood! <http://blogs.xmission.com/legalize/>
7:39 p.m.
Richard wrote:
In article <200701192218.l0JMIOPV028667 at mwave.heeltoe.com>,
Brad Parker <brad at heeltoe.com> writes:
never tried that. interesting - is solaris (or sunos) more tolerant?
-brad
yes, I found linux to be incapable of dealing
with scsi disks formatted
to non-512 byte multiple blocks...
How about Solaris/SunOS? 
10:03 p.m.
On 1/19/07, Brad Parker <brad at heeltoe.com> wrote:
Never tried it with Solaris, but Sun used to ship SCSI drives based on
ESDI bridges, etc., that I doubt supported the SCSI IDENT packet. I
have a couple of these old disk boxes around, but I have yet to try to
use one - I'd rather wrestle with the OS than some cantankerous disks
when I can find embedded SCSI drives from a similar era (I still have
a few 200MB Maxtors, for example).
SunOS, unlike Linux, isn't as particular about certain details (like
the whole IDENT requirement). It's not that Linux _couldn't_ support,
say, an ACB4000 w/MFM drives, but AFAIK, it never has., even back in
the old days (I started with 0.97 with an embedded SCSI drive).
-ethan
How about
Solaris/SunOS?
never tried that. interesting - is solaris (or sunos) more tolerant?
10:03 p.m.
On 1/19/07, Ethan Dicks <ethan.dicks at gmail.com> wrote:
On 1/19/07, Brad Parker <brad at heeltoe.com>
wrote:
Never tried it with Solaris, but Sun used to ship SCSI drives based on
ESDI bridges, etc., that I doubt supported the SCSI IDENT packet...
Whoops... responded to the wrong thread. Sorry.
-ethan
How about
Solaris/SunOS?
never tried that. interesting - is solaris (or sunos) more tolerant? 
20 Jan
20 Jan
8:41 a.m.
Ethan Dicks wrote:
On 1/19/07, Brad Parker <brad at heeltoe.com>
wrote:
Never tried it with Solaris, but Sun used to ship SCSI drives based on
ESDI bridges, etc., that I doubt supported the SCSI IDENT packet. I
have a couple of these old disk boxes around, but I have yet to try to
use one - I'd rather wrestle with the OS than some cantankerous disks
when I can find embedded SCSI drives from a similar era (I still have
a few 200MB Maxtors, for example).
They used to use the ACB4000A SCSI-MFM bridge (in Sun-2, and
early Sun-3), then the Emulex MD-21 in Sun-3, and early Sun-4.
The ACB-4000A is weak on the command side, and doesn't support
IDENT... the MD-21 was better... not sure on IDENT, but it was
'more standard'. Although I wasn't able (at the time anyway) to
get an MD-21 working on a PC ISA SCSI card.... I ended up getting
an MD-25A (late prototype I believe from an (ex?) Emulex employee).
The MD-25A worked great on the PC, and I used it to drive 4 300M
Micropolis ESDI drives in an external case... they appeard on 4 LUNs
on 1 target... I thought that was awesome back when I did it (1 G on a
PC...
for a great price (the drives were free... only had to buy the case and the
MD-25)).
I still have several bridge controllers around...
-- Curt
How about
Solaris/SunOS?
never tried that. interesting - is solaris (or sunos) more tolerant?
SunOS, unlike Linux, isn't as particular about certain details (like
the whole IDENT requirement). It's not that Linux _couldn't_ support,
say, an ACB4000 w/MFM drives, but AFAIK, it never has., even back in
the old days (I started with 0.97 with an embedded SCSI drive).
-ethan
28 Jan
28 Jan
12:21 p.m.
On Fri, 19 Jan 2007, Ethan Dicks wrote:
SunOS, unlike Linux, isn't as particular about
certain details (like
the whole IDENT requirement). It's not that Linux _couldn't_ support,
say, an ACB4000 w/MFM drives, but AFAIK, it never has., even back in
the old days (I started with 0.97 with an embedded SCSI drive).
Actually, someone did write a Linux device driver module for the ACB
series SCSI-MFM bridges. It dates from kernel 2.0.x days, but might be
useful if anyone is enterprising enough to pen an update.
Steve
--
19 Jan
19 Jan
8:21 p.m.
Brad Parker wrote:
That does surprise me. I can well believe that certain filesystems won't work
except at a fixed (typically 512) byte block size, but with my other post in
mind about CDROM drives I would have expected the low-level access to stand a
reasonable chance of working.
I wonder what the problem is - I hope there's not some hack in there which
runs along the lines of "if it's a non-removeable mass storage device then we
expect it to use 512 bytes per block only".
When I've
done this, though, I've written my own disc dumping code using SCSI
command blocks to the low-level interface.
yes, I found linux to be incapable of dealing with scsi disks formatted
to non-512 byte multiple blocks...
8:48 p.m.
Jules Richardson wrote:
Brad Parker wrote:
That does surprise me. I can well believe that certain filesystems won't work
except at a fixed (typically 512) byte block size, but with my other post in
mind about CDROM drives I would have expected the low-level access to stand a
reasonable chance of working.
I wonder what the problem is - I hope there's not some hack in there which
runs along the lines of "if it's a non-removeable mass storage device then we
expect it to use 512 bytes per block only".
there's a case statement in the code which.... ah yes:
...
if (sector_size != 512 &&
sector_size != 1024 &&
sector_size != 2048 &&
sector_size != 4096 &&
sector_size != 256) {
printk("%s : unsupported sector size %d.\n",
nbuff, sector_size);
...
Pretty much hard codes it. (this from a 2.4.29 kernel - 2.6.x is the same)
-brad
> When I've done this, though, I've
written my own disc dumping code using SC
SI
command
blocks to the low-level interface.
yes, I found linux to be incapable of dealing with scsi disks formatted
to non-512 byte multiple blocks...
6421
days inactive
6430
days old
13 comments
8 participants
participants (8)
-
aek＠bitsavers.org -
brad＠heeltoe.com -
ethan.dicks＠gmail.com -
julesrichardsonuk＠yahoo.co.uk -
legalize＠xmission.com -
rescue＠hawkmountain.net -
shirsch＠adelphia.net -
teoz＠neo.rr.com