2 Dec
2012
2 Dec
'12
8:50 p.m.
I have a bootable 100MB RSX-11M image in SIMH
that I'd like to blast onto a Zip disk and boot through my
CQD-220. I'm running a build on SIMH that's essentially
identical to my machine, so it should be straightforward,
but when I try to boot my disk, I get a "not bootable"
response from the ROM (the activity light on the Zip
drive does flash momentarily, so I know something is
going on, but it doesn't look like it's taking enough time
to actually seek anything (and when I boot through the
bootstrap provided by the CQD-220 ROM, I get a HALT
at 000002, which tells me it's probably getting all zeroes).
I know at least some of you boot your -11s off of Zip disks,
probably with similar cards. What am I missing? As far
as I can tell, the SIMH disk image format is a headerless
binary blob, but it doesn't look like I'm getting to the point
where that even matters yet.
- Dave
2 Dec
2 Dec
9:05 p.m.
This is actually the first I've heard of anyone trying to use a Zip
Disk for a PDP-11. I think Jerome Fine uses MO disks. I have SCSI
drive trays (like you used to see in PC's) for my PDP-11's, and just
slide in the right hard drives. I'm using a Viking QDT SCSI Adapter
though. I also have a Plextor SCSI CD-ROM drive in my /73 (one of
the old ones that uses Caddies). I've successfully burned SIMH
images to CD-R and booted them on my /73.
Zane
At 8:50 PM -0500 12/2/12, David Riley wrote:
I have a bootable 100MB RSX-11M image in SIMH
that I'd like to blast onto a Zip disk and boot through my
CQD-220. I'm running a build on SIMH that's essentially
identical to my machine, so it should be straightforward,
but when I try to boot my disk, I get a "not bootable"
response from the ROM (the activity light on the Zip
drive does flash momentarily, so I know something is
going on, but it doesn't look like it's taking enough time
to actually seek anything (and when I boot through the
bootstrap provided by the CQD-220 ROM, I get a HALT
at 000002, which tells me it's probably getting all zeroes).
I know at least some of you boot your -11s off of Zip disks,
probably with similar cards. What am I missing? As far
as I can tell, the SIMH disk image format is a headerless
binary blob, but it doesn't look like I'm getting to the point
where that even matters yet.
- Dave
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
| My Photography Website |
| http://www.zanesphotography.com |
10:32 p.m.
At 7:54 PM -0700 12/2/12, Eric Smith wrote:
Zane H. Healy wrote:
Wow! I'll admit that having been hit by the 'click of death', they
scare the **** out of me.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
| My Photography Website |
| http://www.zanesphotography.com |
This is actually the first I've heard of
anyone trying to use a Zip
Disk for a PDP-11.
I've pretty much *only* used ZIP disks on my various 11s (Unibus and
Qbus) for more than ten years. At this point they're much more
reliable than the legacy drives.
10:54 p.m.
On Dec 2, 2012, at 22:32, "Zane H. Healy" <healyzh at aracnet.com> wrote:
At 7:54 PM -0700 12/2/12, Eric Smith wrote:
I've used them since they first came out and have never
experienced the CoD. Anecdotal evidence suggests
that the later (i.e., 250 and up) drives and/or disks suffered
Zane H. Healy wrote:
Wow! I'll admit that having been hit by the 'click of death', they scare the
**** out of me. This is actually the first I've heard of
anyone trying to use a Zip Disk for a PDP-11.
I've pretty much *only* used ZIP disks on my various 11s (Unibus and Qbus) for more
than ten years. At this point they're much more reliable than the legacy drives.
from either engineering shortcomings or a total lack of
QA.
I've never used anything other than the 100s, largely because
those were all the SCSI ones I ever had and I primarily used
them on Macs (somehow I have an ATA internal one
and a SCSI external one as well; I don't recall hearing
good things about the USB ones, even the early ones).
That said, I don't usually put anything important on them
anymore, because why risk it? But almost all of my
spare SCSI hard drives have died at this point, and I
just bought 18 disks at a yard sale for a dollar, so this is
my best bet for hobbyist stuff at the moment.
- Dave
3 Dec
3 Dec
1:05 a.m.
At 10:54 PM -0500 12/2/12, David Riley wrote:
On Dec 2, 2012, at 22:32, "Zane H. Healy"
<healyzh at aracnet.com> wrote:
I had one of the very first SCSI ones for my PowerBook 520c. It was
great while it lasted. IIRC, my G4/450 AGP came with one built in, I
never used it, except to recover some data.
OTOH, I rather liked the Syquest drives I've had.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
| My Photography Website |
| http://www.zanesphotography.com |
Wow! I'll admit that having been hit by the
'click of death',
they scare the **** out of me.
I've used them since they first came out and have never
experienced the CoD. Anecdotal evidence suggests
that the later (i.e., 250 and up) drives and/or disks suffered
from either engineering shortcomings or a total lack of QA.
I've never used anything other than the 100s, largely because
those were all the SCSI ones I ever had and I primarily used
them on Macs (somehow I have an ATA internal one
and a SCSI external one as well; I don't recall hearing
good things about the USB ones, even the early ones). 
3 Dec
3 Dec
10:03 a.m.
On 12/2/12 8:01 PM, Eric Smith wrote:
Zane H. Healy wrote:
Same here. Much handier to sneakernet recovered media with a ZIP.
Wow! I'll admit that having been hit by the
'click of death', they scare the **** out of me.
I think I bought all of my ZIP drives and media after that problem was resolved.
I've used them heavily, and never had a problem.
12:02 p.m.
On Mon, 3 Dec 2012, Al Kossow wrote:
On 12/2/12 8:01 PM, Eric Smith wrote:
Zane H. Healy wrote:
Same here. Much handier to sneakernet recovered media with a ZIP. Wow! I'll admit that having been hit by the
'click of death', they
scare the **** out of me.
I think I bought all of my ZIP drives and media after that problem was
resolved. I've used them heavily, and never had a problem. From what I remember, the main problem was a
cost-reduced batch of drives
made during a very specific timeframe. To cut costs
some idiot decided to
leave out a small rubber washer which normally kept the head actuator from
hitting the end of the stop. Without it, the servo could damage the head
if the drive was powered down while the head was still over the media.
Once the head was damaged, any media inserted would be damaged, and that
media could then damage the heads of other Zip drives. The details can
probably be found with a Google search.
Even though the number of defective drives was very small compared to the
millions of drives made, that mess severely damaged the reputation of both
Iomega and Zip drives. All because some idiot wanted to save a penny or
less per drive...
12:25 p.m.
GRC still has their "click of death" test utility -
http://www.grc.com/tip/clickdeath.htm
it's free, but hasn't been updated, don't know of any other utility or if this
actually works (never tested it myself)
Dan.
Date: Mon, 3 Dec 2012 11:02:47 -0600
From: tothwolf at concentric.net
To: cctalk at classiccmp.org
Subject: Re: SIMH images to Zip Disks
On Mon, 3 Dec 2012, Al Kossow wrote:
On 12/2/12 8:01 PM, Eric Smith wrote:
From what I remember, the main problem was a cost-reduced batch of drives
made during a very specific timeframe. To cut costs some idiot decided to
leave out a small rubber washer which normally kept the head actuator from
hitting the end of the stop. Without it, the servo could damage the head
if the drive was powered down while the head was still over the media.
Once the head was damaged, any media inserted would be damaged, and that
media could then damage the heads of other Zip drives. The details can
probably be found with a Google search.
Even though the number of defective drives was very small compared to the
millions of drives made, that mess severely damaged the reputation of both
Iomega and Zip drives. All because some idiot wanted to save a penny or
less per drive... Zane H. Healy wrote:
Same here. Much handier to sneakernet recovered media with a ZIP. Wow! I'll admit that having been hit by the
'click of death', they
scare the **** out of me.
I think I bought all of my ZIP drives and media after that problem was
resolved. I've used them heavily, and never had a problem. 
5 Dec
5 Dec
12:09 a.m.
On Mon, Dec 3, 2012 at 11:25 AM, Dan Gahlinger <dgahling at hotmail.com> wrote:
GRC still has their "click of death" test utility -
http://www.grc.com/tip/clickdeath.htm
it's free, but hasn't been updated, don't know of any other utility or if
this actually works (never tested it myself)
It runs but reports that it was set to expire on 1/1/2010 and please
visit grc.com (where I got it) for the latest version :(
And yeah, setting the OS date back works.
j
3 Dec
3 Dec
1:38 p.m.
Here is a 1998 article from CNET, "Click of death" strikes Iomega
http://news.cnet.com/2100-1001-207628.html
Michael Holley
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Tothwolf
Sent: Monday, December 03, 2012 9:03 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: SIMH images to Zip Disks
On Mon, 3 Dec 2012, Al Kossow wrote:
On 12/2/12 8:01 PM, Eric Smith wrote:
Zane H. Healy wrote:
Same here. Much handier to sneakernet recovered media with a ZIP. Wow! I'll admit that having been hit by the
'click of death', they
scare the **** out of me.
I think I bought all of my ZIP drives and media after that problem
was resolved. I've used them heavily, and never had a problem. From what I remember, the main problem was a
cost-reduced batch of drives
made during a very specific timeframe. To cut costs
some idiot decided to
leave out a small rubber washer which normally kept the head actuator from
hitting the end of the stop. Without it, the servo could damage the head if
the drive was powered down while the head was still over the media.
Once the head was damaged, any media inserted would be damaged, and that
media could then damage the heads of other Zip drives. The details can
probably be found with a Google search.
Even though the number of defective drives was very small compared to the
millions of drives made, that mess severely damaged the reputation of both
Iomega and Zip drives. All because some idiot wanted to save a penny or less
per drive...
9:11 p.m.
Michael Holley wrote:
Here is a 1998 article from CNET, "Click of
death" strikes Iomega
http://news.cnet.com/2100-1001-207628.html
Michael Holley
-----Original Message-----
From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org]
On Behalf Of Tothwolf
Sent: Monday, December 03, 2012 9:03 AM
To: General Discussion: On-Topic and Off-Topic Posts
Subject: Re: SIMH images to Zip Disks
On Mon, 3 Dec 2012, Al Kossow wrote:
On 12/2/12 8:01 PM, Eric Smith wrote:
Zane H. Healy wrote:
Same here. Much handier to sneakernet recovered media with a ZIP.
Wow! I'll admit that having been hit by the
'click of death', they
scare the **** out of me.
I think I bought all of my ZIP drives and media after that problem
was resolved. I've used them heavily, and never had a problem.
From what I remember, the main problem was a
cost-reduced batch of drives
made during a very specific timeframe. To cut costs
some idiot decided to
leave out a small rubber washer which normally kept the head actuator from
hitting the end of the stop. Without it, the servo could damage the head if
the drive was powered down while the head was still over the media.
Once the head was damaged, any media inserted would be damaged, and that
media could then damage the heads of other Zip drives. The details can
probably be found with a Google search.
Even though the number of defective drives was very small compared to the
millions of drives made, that mess severely damaged the reputation of both
Iomega and Zip drives. All because some idiot wanted to save a penny or less
per drive...
2 Dec
2 Dec
10 p.m.
David Riley wrote:
I have a bootable 100MB RSX-11M image in SIMH
that I'd like to blast onto a Zip disk and boot through my
CQD-220. I'm running a build on SIMH that's essentially
identical to my machine, so it should be straightforward,
but when I try to boot my disk, I get a "not bootable"
response from the ROM (the activity light on the Zip
drive does flash momentarily, so I know something is
going on, but it doesn't look like it's taking enough time
to actually seek anything (and when I boot through the
bootstrap provided by the CQD-220 ROM, I get a HALT
at 000002, which tells me it's probably getting all zeroes).
How are you transferring the image to the ZIP? With Linux, I can dd an
image created with E11 to the ZIP, and it boots fine with a CQD.
10:19 p.m.
On Dec 2, 2012, at 10:00 PM, Eric Smith wrote:
David Riley wrote:
I'm just dd'ing it as well. No problems reported, the image is
slightly smaller than the disk itself (which I wouldn't expect
to be a problem), and all that. It's an image with which I can
do a "boot rq0" from SIMH and it starts up with no problem, but
when I do the CQD's bootstrap (which looks like it just reads
the first block to address 0 and goes with it), I can verify
that I get 512 bytes of zeroes, which isn't what's on the first
block of the disk.
It's bedtime here, but in the morning I'll hook up the serial
port and make sure I haven't done anything funky with the CQD's
partitioning setup. If there's anything else to check up on,
I'd be glad to hear about it. This is the first time I've
gotten around to trying to boot anything off the CQD since I
fixed the firmware bug last year, so I'm working a bit blind.
- Dave
I have a bootable 100MB RSX-11M image in SIMH
that I'd like to blast onto a Zip disk and boot through my
CQD-220. I'm running a build on SIMH that's essentially
identical to my machine, so it should be straightforward,
but when I try to boot my disk, I get a "not bootable"
response from the ROM (the activity light on the Zip
drive does flash momentarily, so I know something is
going on, but it doesn't look like it's taking enough time
to actually seek anything (and when I boot through the
bootstrap provided by the CQD-220 ROM, I get a HALT
at 000002, which tells me it's probably getting all zeroes).
How are you transferring the image to the ZIP? With Linux, I can dd an image created with
E11 to the ZIP, and it boots fine with a CQD.
11:12 p.m.
On Dec 2, 2012, at 23:00, Eric Smith <eric at brouhaha.com> wrote:
David Riley wrote:
An IBM partition map wouldn't do me much good on a
PDP-11, now, would it? :-) See my other email; turns
out I was writing without a disk inserted and Linux's block
layer was happily throwing away my data at 12.5 MB/s.
Not sure what I verified my first block against that made
me think the data was written correctly, but my daughter
woke us up every two hours last night, so my cognitive
facilities aren't running at 100% right now.
- Dave
I'm just dd'ing it as well.
And you're dding to something like /dev/sdb? *Not* /dev/sdb1?
10:47 p.m.
On Dec 2, 2012, at 22:00, Eric Smith <eric at brouhaha.com> wrote:
How are you transferring the image to the ZIP? With
Linux, I can dd an image created with E11 to the ZIP, and it boots fine with a CQD.
*sigh* This was a PEBKAC problem. Turns out Linux had
a different idea of what /dev/sdb was than I did; I realized
something was amiss when I was getting 12 MB/s transfer
rates (absurdly high for a Zip 100). Seems Linux will
happily accept data when you don't have a disk in the
drive (which I didn't realize somehow).
Anyway, now that I've written my image to something other
than the bit bucket, I have RSX booting happily from the
Zip disk. Sorry for the noise; next time I'll try sleeping on
the problem first. :-)
- Dave
10:53 p.m.
On 12/2/2012 8:47 PM, David Riley wrote:
Anyway, now that I've written my image to
something other
than the bit bucket, I have RSX booting happily from the
Zip disk. Sorry for the noise; next time I'll try sleeping on
the problem first. :-)
Can you give the details, of the Zip setup. I remember they
came out with several Zip Disk interfaces, PC printer port,
Mac and some sort of internal card.
- Dave
11:08 p.m.
On Dec 2, 2012, at 22:53, ben <bfranchuk at jetnet.ab.ca> wrote:
Can you give the details, of the Zip setup. I remember
they
came out with several Zip Disk interfaces, PC printer port,
Mac and some sort of internal card.
Sure, it's actually pretty simple (getting there may not
be, though). I have a CMD CQD-220 QBUS SCSI card
that acts as an MSCP host. I have an external SCSI Zip
drive attached and mapped as DU0: in the CQD-220
firmware (the card emulates a separate DUn: for each
SCSI ID or partition thereof).
On the Linux side, it's just an internal ATA Zip 100 drive,
nothing special there.
The real pain is probably finding a SCSI card these days.
I got super-lucky a few years ago and landed this one
on eBay for a good price (from another list member, as it
turned out, though I wasn't on the list then). If you're
looking on eBay, expect to pay upwards of $200
if you can find one. SCSI Zip 100s are somewhat easier
to find and will probably run anywhere between $50 and
$100 (or, of course, less if you're lucky).
Zip 100s came in parallel (external), SCSI (internal and
external), ATA (internal), and later USB. I have one of
the big boxy early USB models floating around somewhere,
but I don't hear great things about their reliability; the ones
with lots of verifiable problems are the later "slim" models
which (IIRC) came about with the 250 MB disks.
- Dave
11:10 p.m.
ben wrote:
Can you give the details, of the Zip setup. I remember
they
came out with several Zip Disk interfaces, PC printer port,
Mac and some sort of internal card.
"Bare" 100 MB ZIP drives were available in three variants, IDE (rare),
ATAPI (attaches to IDE port, common), and SCSI.
External were available in parallel, SCSI, "Plus" (could connect to
either parallel or SCSI), or USB.
I've used both the internal and external SCSI ZIP drives on the PDP-11.
The external has the disadvantage that it only has two choices for ID.
The ZIP 250 was available for SCSI, but I haven't tried it. The ZIP 750
was not offered in a SCSI version.
I strongly recommend against the Iomega Jaz drive; the media seems to
develop a lot of bad spots over a period of months. And the Syquest
SyJet, Sparq, and Quest were even worse; my employer at the time chose
them against my advice, and they rarely lasted more than a week.
3 Dec
3 Dec
1:06 a.m.
At 9:10 PM -0700 12/2/12, Eric Smith wrote:
I strongly recommend against the Iomega Jaz drive; the
media seems
to develop a lot of bad spots over a period of months. And the
Syquest SyJet, Sparq, and Quest were even worse; my employer at the
time chose them against my advice, and they rarely lasted more than
a week.
I actually had pretty good luck with my Syquest SyJet drive.
Zane
--
| Zane H. Healy | UNIX Systems Administrator |
| healyzh at aracnet.com | OpenVMS Enthusiast |
| | Photographer |
+----------------------------------+----------------------------+
| My flickr Photostream |
| http://www.flickr.com/photos/33848088 at N03/ |
| My Photography Website |
| http://www.zanesphotography.com |
2:19 a.m.
Zane H. Healy wrote:
I actually had pretty good luck with my Syquest SyJet
drive.
I was the third engineer hired at one of the first DVR companies. The
one most people have NOT heard of, though we shipped our first product
the same week as the more famous one, and IMNSHO ours was better in many
ways.
We had >99% failure rate on hundreds of the Syquest drives (mix of Syjet
and Sparq). MTBF was somewhere under 2 weeks. Many failed on the first
day of use. We had people returning failed drives to Fry's on a daily
basis.
I had recommended that we use the ATAPI ZIP drive as the boot device for
software development, and an ordinary hard drive to store the MPEG
files. The ZIP drive worked quite reliably, but wasn't big enough for
the MPEG files. There was no reason that the MPEG files needed to be on
removeable media, even during development. However, someone in
management thought that it was a better idea to have a single removable
media drive. That was arguably the second dumbest technical decision
made during development, and it wasted hundreds of man hours.
The dumbest was that the software developers wanted an Ethernet port for
debug use, which didn't need to be stuffed for production. (This was
well before the whole-house sharing idea was given serious consideration
as a product feature.) The hardware engineer said that it would add an
extra two days to the hardware schedule, so management killed it. The
software developers said that having the Ethernet port would have shaved
weeks off the software schedule, but apparently management didn't
believe it. On the other hand, management insisted that the hardware
engineer put a 1394 port in the product, while they didn't budget any
time for software or even testing. The product shipped with the 1394
port, which actually never worked.
Years later I saw Matt Blaze wearing a T-shirt with this company logo:
http://blog.ontrac.com/Portals/53780/images/waste-management-logo.jpg
He explained that the reason he wore the shirt was that the company name
was a complete sentence. Really made me wish I'd had that shirt back
when I'd worked at the DVR company.
3 Dec
3 Dec
8:21 a.m.
On Dec 2, 2012, at 11:13 PM, Earl Evans wrote:
Yes; I could have sworn I said that in the original message.
Have my subsequent clarifications been getting lost? I don't
get "feedback" of the messages I send to the list (perhaps
there's an option for that), so I have no way of knowing if
they've been lost.
- Dave
Can you give the details, of the Zip setup. I remember they
came out with several Zip Disk interfaces, PC printer port,
Mac and some sort of internal card.
Seconded. Is this done with a SCSI Zip drive, and associated QBus or
Unibus SCSI adapter? 
3 Dec
3 Dec
7:21 a.m.
On Sun, 2 Dec 2012, Fred Cisin wrote:
On Sun, 2 Dec 2012, ben wrote:
The "internal card" for Zip drives was a barebones Adaptec SCSI card for
PC compatibles that had no BIOS or boot support. The earlier Zip drives
shipped with an ISA card and some of the later drives had a PCI card. All
the Jaz cartridge drives that I used that included an interface card all
had a PCI card but apparently they had some with ISA cards as well.
The later external USB Zip drives could also make use an optional
Firewire/1394 interface module accessory.
At one time I made heavy use of both the 100MB and 250MB Zip disks and 1GB
and 2GB Jaz cartridges for disk image backups. I had only one failure of a
1GB Jaz cartridge and that was due to the metal tab on the shutter
breaking. They were used in a relatively dust free environment though,
which I'm sure had something to do with it.
I do distinctly remember Jaz drives needing a BIOS update from a Windows
95 computer prior to use with a non-Windows OS in order to properly deal
with Tagged Command Queuing. The drives themselves didn't support TCQ (or
at least not properly) but the earlier BIOS versions would happily agree
to use it, which of course caused all sorts of havoc with higher end SCSI
cards. IIRC some drives also needed to be pre-configured with a
Windows-only software utility to enable support for disconnect-reconnect
(although now that I'm thinking about it, I may be thinking about a
different drive).
Here is an example of what these drives would do if the BIOS wasn't
updated so that the drive would decline to use TCQ:
http://groups.google.com/group/linux.dev.scsi/tree/browse_frm/month/1996-11…
Can you give the details, of the Zip setup. I
remember they came out
with several Zip Disk interfaces, PC printer port, Mac and some sort of
internal card.
also SCSI,
IDE? 
8:39 a.m.
On Sunday (12/02/2012 at 08:00PM -0700), Eric Smith wrote:
David Riley wrote:
I can second that. Trivial bit image copy with 'dd'.
Of course you dd it to the raw device, /dev/sdb, /dev/sdc, etc. not one
of the partitions (ie, not /dev/sdb1, /dev/sdb2, etc).
I've got an ATAPI ZIP drive in a Linux box for making the copies and
then a pair of SCSI ZIP on the CQD controller in my 11/34. Works great.
I have also booted XXDP from CDROM attached to this CQD controller but
that is a really, really slow solution.
--
Chris Elmquist
I have a bootable 100MB RSX-11M image in SIMH
that I'd like to blast onto a Zip disk and boot through my
CQD-220. I'm running a build on SIMH that's essentially
identical to my machine, so it should be straightforward,
but when I try to boot my disk, I get a "not bootable"
response from the ROM (the activity light on the Zip
drive does flash momentarily, so I know something is
going on, but it doesn't look like it's taking enough time
to actually seek anything (and when I boot through the
bootstrap provided by the CQD-220 ROM, I get a HALT
at 000002, which tells me it's probably getting all zeroes).
How are you transferring the image to the ZIP? With Linux, I can dd
an image created with E11 to the ZIP, and it boots fine with a CQD. 
11:06 a.m.
On Dec 3, 2012 5:42 AM, "Chris Elmquist" <chrise at pobox.com> wrote:
I've got an ATAPI ZIP drive in a Linux box for making the copies and
then a pair of SCSI ZIP on the CQD controller in my 11/34. Works great.
I assume you really mean CDU controller there, not CQD. I've got a couple
CDU-720 controllers and no Unibus systems to put that in. I'll have to
correct that some day...
5 Dec
5 Dec
11:24 a.m.
On Monday (12/03/2012 at 08:06AM -0800), Glen Slick wrote:
On Dec 3, 2012 5:42 AM, "Chris Elmquist"
<chrise at pobox.com> wrote:
Actually, I think I meant CMD (brand) controller. I'm drawing a blank
on the exact model number but it's the one that does disk only and not
also tape. It could be CDU-720... that does ring a bell.
It's got firmware on it that the '11 executes when you enable the ROM
and then jump to that from ODT. That firmware provides a user interface
for configuring the card and each of the target devices as well as the
means to then boot from a specific device. I use that user interface
to ge it to boot from one of the ZIPs.
I wonder if anyone has attempted to archive the firmware and PALs on
these SCSI cards?
I have a second card that was injured in a horrible accident (I plugged
it into the Unibus, justified the wrong way... so, it was off by two in
all the edge connectors. This promptly fried the card because the +20V
core voltage ended up in all the wrong places. That was the quickest
$300 I ever burned. It was however, educational.
I've since repaired most of the damage, replacing buffers, burned traces,
etc. however a couple PALs were affected and need to be replaced.
I am chicken to take them from my working board and try to read them
out unless there's a high likelihood it can be done.
Or, if they've already been read, then I could just burn new ones from
the images and try them.
For some reason, I've put most of this whole event out of my mind :-)
Chris
--
Chris Elmquist
I've got an ATAPI ZIP drive in a Linux box for making the copies and
then a pair of SCSI ZIP on the CQD controller in my 11/34. Works great.
I assume you really mean CDU controller there, not CQD. I've got a couple
CDU-720 controllers and no Unibus systems to put that in. I'll have to
correct that some day...
12:02 p.m.
On Dec 5, 2012, at 11:24 AM, Chris Elmquist wrote:
It's got firmware on it that the '11 executes
when you enable the ROM
and then jump to that from ODT. That firmware provides a user interface
for configuring the card and each of the target devices as well as the
means to then boot from a specific device. I use that user interface
to ge it to boot from one of the ZIPs.
The CQD-220 (QBUS) one is similar, though my 11/23+ has the
capability to boot MSCP/TMSCP devices directly, so I use that.
I wonder if anyone has attempted to archive the
firmware and PALs on
these SCSI cards?
Haha, funny you should mention that. I had to dump and disassemble
it to figure out why my card was bricked (helpful hint: NEVER set
the number of disks and tapes to zero). The CQD-220, which may or
may not be related to the CDU-720, is a pretty standard 8086 design
with a small amount of SRAM. The ROM image is actually a DOS
executable, which makes me wonder if their development machines
were 8086 PCs.
I believe someone (who can name himself if he'd like, though I don't
want to run the risk of incurring the wrath of the Attack Lawyers on
someone else) has a bunch of images of various firmware versions, at
least for the CQD-220. He also has a reverse-engineered PAL equation
set for the CSR decode PAL (which is a pretty simple combinatorial
decode circuit), but the rest of the PALs (on the CQD-220, at least)
are probably somewhat more complicated. I'm willing to bet that they
have the security fuses blown, as well, but I haven't checked.
I have a second card that was injured in a horrible
accident (I plugged
it into the Unibus, justified the wrong way... so, it was off by two in
all the edge connectors. This promptly fried the card because the +20V
core voltage ended up in all the wrong places. That was the quickest
$300 I ever burned. It was however, educational.
I've since repaired most of the damage, replacing buffers, burned traces,
etc. however a couple PALs were affected and need to be replaced.
I am chicken to take them from my working board and try to read them
out unless there's a high likelihood it can be done.
You might have some luck replicating them if you can find (or make) a
schematic, because most of their functions should be pretty apparent
from that. It takes an awfully long time to trace out
a board like
that, though, especially with components still on (and if it's
like
the CQD-220, it's a four-layer board with at least some of the signal
traces buried in inner layers).
Or, if they've already been read, then I could
just burn new ones from
the images and try them.
I'd be thrilled if they were reverse-engineered, or if someone can
persuade CMD (now owned by Silicon Image) to release the materials
needed to repair vintage hardware.
- Dave
1:38 p.m.
The CMD CQD and CDU firmware images I have were available on CMD's FTP
site. Those are still lurking out there in the archives from 1996.
I reverse engineered the CSR decode PALs on the CQD-200, 220, and
220A. It was fairly obvious after tracing the bus signals through the
bus transcievers to the CSR decode PAL along with the decode select
jumpers. I am 100% sure about the 200 and 220. The 220A is less
obvious. I believe in the 220A the main address decoding is done
elsewhere, maybe in an ASIC, and the CSR decode PAL is only used to
enable additional non-standard CSR addresses, plus output a model code
(/TM vs /E, where /E is either MSCP or TMSCP, but not both at the same
time).
The CDU-720 I have is an /M. I don't currently have a UNIBUS system
to use it in. Someday when I acquire one I'll try the exercise of
reverse engineering the CSR decode PAL on that one to use it as a /TM.
There are about 10 other socketed PALs on the 720. I assume they are
all security protected as well. I wouldn't want to have to try to
reverse engineer any of the other PALs.
-Glen
4247
days inactive
4249
days old
32 comments
14 participants
participants (14)
-
aek＠bitsavers.org -
bfranchuk＠jetnet.ab.ca -
chrise＠pobox.com -
cisin＠xenosoft.com -
dgahling＠hotmail.com -
earl＠retrobits.com -
eric＠brouhaha.com -
fraveydank＠gmail.com -
glen.slick＠gmail.com -
healyzh＠aracnet.com -
jhfinedp3k＠compsys.to -
silent700＠gmail.com -
swtpc6800＠comcast.net -
tothwolf＠concentric.net