9 Mar
2016
9 Mar
'16
10:26 a.m.
Dear all,
I have two VAXen that I'd like to resurrect simply for the sake of playing
around with The Real Thing[tm] running VMS. Note that I'm completely new
to VMS and DEC hardware -- hence the interest!
Box #1 is a VAX4000 model 400 with no working CPU (KA-675) and 2x 32Mb
RAM, an RF72 (wiped), plus a KZQSA QBUS controller. PSU is good, fans
squeal on startup but run silently once spun up. Have VMS installation
media in CD.
I have two KA-675s for this beast: Board #1 (originally installed) has a
failed B-cache (console reports SUBTEST_35_12, DE_B_Cache_diag_mode.LIS)
and crashes with an asynchronous write memory failure when booting VMS
from CD. Board #2 (DOA from eBay but fully refunded) has a dead DSSI bus 0
controller and crashes on SHOW DEV; I assume that's a write-off. Any
chance of identifying the flaky B-cache SRAM on board #1 and replacing it?
Alternatively, anyone out there have a KA-675 for sale?
Box #2 is a VAXstation 3200 with TK50, and an RD54. PSU and fans ok (and
very quiet), ditto CPU. The RD54 is unformatted; I understand this can
only be formatted in the field with a VS2000 or with some obscure field
diagnostics. There's no SCSI controller, so I can't install from CD. I
haven't been able to track down VMS installation media on TK50, and I
doubt they'd still be readable anyway. On top of that I have no idea what
condition the drive is in, as I have no blank tapes to test with. I've
found tape images online but see no way to dump these to TK50 (assuming
the drive is ok), unless I get a TZ30.
What are my options and chances of success for getting either of these
boxes up and running with VMS? A KA-675 and TZ30 can be obtained from
resellers, but I hesitate to invest several hundred in something this old
purely for the occasional mucking about. I have also considered selling
the units (or parts thereof) if nothing gives.
Any ideas much appreciated,
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a
lot of memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
9 Mar
9 Mar
11:29 a.m.
-----Original Message-----
From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Dr.
Roland Schregle
Sent: 09 March 2016 18:27
To: ClassicCmp Tech <cctech at classiccmp.org>
Subject: Options for resurrecting VAX 4000/400 and Vaxstation 3200
Dear all,
I have two VAXen that I'd like to resurrect simply for the sake of playing
around with The Real Thing[tm] running VMS. Note that I'm completely new
to VMS and DEC hardware -- hence the interest!
Box #1 is a VAX4000 model 400 with no working CPU (KA-675) and 2x 32Mb
RAM, an RF72 (wiped), plus a KZQSA QBUS controller. PSU is good, fans
squeal on startup but run silently once spun up. Have VMS installation media
in CD.
I have two KA-675s for this beast: Board #1 (originally installed) has a failed B-
cache (console reports SUBTEST_35_12, DE_B_Cache_diag_mode.LIS) and
crashes with an asynchronous write memory failure when booting VMS from
CD. Board #2 (DOA from eBay but fully refunded) has a dead DSSI bus 0
controller and crashes on SHOW DEV; I assume that's a write-off. Any chance
of identifying the flaky B-cache SRAM on board #1 and replacing it?
Alternatively, anyone out there have a KA-675 for sale?
Box #2 is a VAXstation 3200 with TK50, and an RD54. PSU and fans ok (and
very quiet), ditto CPU. The RD54 is unformatted; I understand this can only
be formatted in the field with a VS2000 or with some obscure field
diagnostics. There's no SCSI controller, so I can't install from CD. I
haven't
been able to track down VMS installation media on TK50, and I doubt they'd
still be readable anyway. On top of that I have no idea what condition the
drive is in, as I have no blank tapes to test with. I've found tape images online
but see no way to dump these to TK50 (assuming the drive is ok), unless I get
a TZ30.
What are my options and chances of success for getting either of these
boxes up and running with VMS? A KA-675 and TZ30 can be obtained from
resellers, but I hesitate to invest several hundred in something this old purely
for the occasional mucking about. I have also considered selling the units (or
parts thereof) if nothing gives.
Any ideas much appreciated,
You could run the 3200 by netbooting it from a SIMH instance of VMS. If the RD54 was
formatted (and working!) then you could transfer VMS onto the disk from the boot node. To
format the RD54 you would need to find a 2000 though, or at least borrow one. You should
tell the list where you live as there might be someone close by who could help out. It
might be though that the RD54 is formatted, worth trying once you netboot.
As for the KA675, I don't know really, I suspect you would be into surface mount work,
but with two boards you might be able to swap bits around to get a working board. Perhaps
if you got a KFQSA or a KZQSA you could get this to work?
Regards
Rob
12:38 p.m.
On Wed, 09 Mar 2016 20:29:56 +0100, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
You could run the 3200 by netbooting it from a SIMH
instance of VMS. If
the RD54 was formatted (and working!) then you could transfer VMS onto
the disk from the boot node.
G'day Rob, thanks for the quick reply.
I've contemplated the SIMH/netboot option (was made aware of it a while
ago), but I'm not even sure the 3200 can netboot; at least it does have a
DELQA, so correct me if I'm wrong. In any case, I'd have to set up DECnet
under Linux first.
To format the RD54 you would need to find a 2000
though, or at least
borrow one. You should tell the list where you live as there might be
someone close by who could help out.
The VS is located in Germany, but I'm currently working in Switzerland and
won't get at the thing until my next vacation, probably sometime after
Easter.
I know that Bernd Ulmann (alias VAXMAN!) has a VS2000 and is --more or
less-- close by, but I haven't managed to schedule a visit (yet).
It might be though that the RD54 is formatted, worth
trying once you
netboot.
I checked out the RD54 on an old ST506/412 controller a few years back,
and it did seek. Of course I couldn't read the format, so I can't tell
what's on it. It definitely doesn't boot on the VS. Any other way to check
for a format from the console?
As for the KA675, I don't know really, I suspect
you would be into
surface mount work, but with two boards you might be able to swap bits
around to get a working board. Perhaps if you got a KFQSA or a KZQSA you
could get this to work?
Yep, it's SMT, but replacing a 22 pin DIP shouldn't be a big deal with the
right tools and a bit of practice. But the console diags don't indicate
the faulty chip! :^(
The 4000 does have a KZQSA, and it boots from CD -- until it bails out
with the async write error, which I assume has to do with the failed
B-cache.
Thanks for the hints,
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a
lot of memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
12:59 p.m.
-----Original Message-----
From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Dr.
Roland Schregle
Sent: 09 March 2016 20:39
To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
Subject: Re: Options for resurrecting VAX 4000/400 and Vaxstation 3200
On Wed, 09 Mar 2016 20:29:56 +0100, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
If it has a DELQA then you should be able to netboot it without issue. You don't need
to set up DECnet under linux though. All you need is SIMH running DECnet (and possibly a
cluster, I do it with a cluster, but I am not 100% sure it *has* to be a cluster). You
just need a VMS ISO and you can get up and running.
You could run the 3200 by netbooting it from a
SIMH instance of VMS.
If the RD54 was formatted (and working!) then you could transfer VMS
onto the disk from the boot node.
G'day Rob, thanks for the quick reply.
I've contemplated the SIMH/netboot option (was made aware of it a while
ago), but I'm not even sure the 3200 can netboot; at least it does have a
DELQA, so correct me if I'm wrong. In any case, I'd have to set up DECnet
under Linux first. To format the RD54 you would need to find a 2000
though, or at least
borrow one. You should tell the list where you live as there might be
someone close by who could help out.
The VS is located in Germany, but I'm currently working in Switzerland and
won't get at the thing until my next vacation, probably sometime after
Easter.
I know that Bernd Ulmann (alias VAXMAN!) has a VS2000 and is --more or
less-- close by, but I haven't managed to schedule a visit (yet). It might be though that the RD54 is formatted,
worth trying once you
netboot.
I checked out the RD54 on an old ST506/412 controller a few years back, and
it did seek. Of course I couldn't read the format, so I can't tell what's on
it. It
definitely doesn't boot on the VS. Any other way to check for a format from
the console? As for the KA675, I don't know really, I
suspect you would be into
surface mount work, but with two boards you might be able to swap bits
around to get a working board. Perhaps if you got a KFQSA or a KZQSA
you could get this to work?
Yep, it's SMT, but replacing a 22 pin DIP shouldn't be a big deal with the right
tools and a bit of practice. But the console diags don't indicate the faulty chip!
:^(
The 4000 does have a KZQSA, and it boots from CD -- until it bails out with the
async write error, which I assume has to do with the failed B-cache.
Thanks for the hints,
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a lot of
memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
2:20 p.m.
On Wed, Mar 9, 2016 at 12:59 PM, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
I don't have a 3200, nor can I find a manual, but since it looks to be more modern
than a 2000, and apparently supports an RD54, then I would have thought the console
firmware could format it. On the 2000 TEST 71 will check the disk and tell you what it is,
TEST 70 will format it. Perhaps you could try those commands to see if they also work on
the 3200.
Should be an M7620 KA650 CPU in a BA23 box with an M7168 / M7169 VCB02
QDSS video subsystem. The storage controller should be an M7555 RQDX3.
Manual available here:
http://manx.classiccmp.org/collections/hcps/154aaow1.pdf
If you could swap a Q-Bus PDP-11 CPU and memory in for the KA650 VAX
CPU then you could run XXDP ZRQCH0 diagnostics to format the RD54 on
the RQDX3.
10 Mar
10 Mar
4:23 a.m.
On Wed, 09 Mar 2016 23:20:16 +0100, Glen Slick <glen.slick at gmail.com>
wrote:
On Wed, Mar 9, 2016 at 12:59 PM, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
Yep, it's in a BA23 with a ridiculously dense Q-Bus. I considered
installing the KZQSA from the 4000 in the 3200, but the edge connectors
won't fit even after removing the panel, plus I read in the list archives
that the 3200 won't boot from it. :^(
There's a QDSS as you point out, but I haven't tested it yet; need a
splitter cable and one of those elusive VSXXX mice. Do have an LK201
knocking about tho.
Wasn't aware the XXDP diags run on a PDP...
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a
lot of memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
I don't have a 3200, nor can I find a manual, but since it looks to be
more modern than a 2000, and apparently supports an RD54, then I would
have thought the console firmware could format it. On the 2000 TEST 71
will check the disk and tell you what it is, TEST 70 will format it.
Perhaps you could try those commands to see if they also work on the
3200.
Should be an M7620 KA650 CPU in a BA23 box with an M7168 / M7169 VCB02
QDSS video subsystem. The storage controller should be an M7555 RQDX3.
Manual available here:
http://manx.classiccmp.org/collections/hcps/154aaow1.pdf
If you could swap a Q-Bus PDP-11 CPU and memory in for the KA650 VAX
CPU then you could run XXDP ZRQCH0 diagnostics to format the RD54 on
the RQDX3.
12:37 p.m.
On Thu, Mar 10, 2016 at 4:23 AM, Dr. Roland Schregle
Yep, it's in a BA23 with a ridiculously dense Q-Bus. I considered installing
the KZQSA from the 4000 in the 3200, but the edge connectors won't fit even
after removing the panel, plus I read in the list archives that the 3200
won't boot from it. :^(
I just tried an M5976 KZQSA with an M7620 KA650, an M7624 KA640, and
an M7625 KA655 CPU. None of them would recognize the M5976 KZQSA as a
boot device.
I think you need at least an M7626 KA660 CPU or better to recognize a
SCSI CD-ROM attached to a M5976 KZQSA as a boot device, where it
should normally appear as DKA0.
The VAX 4000/200 M7626 KA660 CPU is the last VAX CPU which plugs
directly into a Q-Bus slot and you could in theory use it in a BA23
chassis, but wiring up the on board interfaces would take some work
without the cab kit for that. I've only seen one of those go buy on
eBay:
http://www.ebay.com/itm/151768446404
10:59 p.m.
Zitat von Glen Slick <glen.slick at gmail.com>:
I think you need at least an M7626 KA660 CPU or better
to recognize a
SCSI CD-ROM attached to a M5976 KZQSA as a boot device, where it
should normally appear as DKA0.
The KZQSA is supported only on the 4000 series.
The only "real" DEC QBUS Controller was the RQZX1,
good luck finding one cheap ;-)
Cheers
9 Mar
9 Mar
3:19 p.m.
If it has a DELQA then you should be able to netboot it without issue. You
don't need to set up DECnet under linux though. All you need is SIMH running
DECnet (and possibly a cluster, I do it with a cluster, but I am not 100% sure
it *has* to be a cluster). You just need a VMS ISO and you can get up and
running.
It's the other way around. Cluster communications is pretty much essential
and DECnet is not always required.
When you boot VMS over the network, the machine being booted normally ends up
clustered with the machine it is booted from. The machine being booted can
then obtain disk services from the boot node or any other cluster member using
cluster communications. DECnet is not strictly necessary for any of this
although it is recommended that DECnet be installed for the purpose of remote
management of cluster nodes.
Early versions of VMS need to have DECnet installed on the boot node because
DECnet includes support for MOP which is the protocol used for the initial
network boot request and response. Later VMS versions include LANCP which can
also provide MOP support without the presence of DECnet.
You definately do not need DECnet on a host machine running an emulator. You
don't need to install anything special to handle cluster communications or MOP
either. Typically, the emulator will require the installation of some network
interface package that allows it to inject/extract the required protocols
directly to/from the network.
Yep, it's SMT, but replacing a 22 pin DIP
shouldn't be a big deal with the
right tools and a bit of practice. But the console diags don't indicate the
faulty chip! :^(
10 Mar
10 Mar
4:39 a.m.
On Wed, 09 Mar 2016 21:59:27 +0100, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
I think one day I will have to equip myself and learn
how to desolder
and resolder surface mount chips. I don't know how many chips implement
the B-CACHE, but perhaps you could replace all of them, assuming you
know which ones they are. Perhaps some careful probing of the board with
a scope might show if there any chips that are perhaps completely dead.
You could do the same for the DSSI controller on the other board of
course, if you can identify that.
Our lab has an EE department with some pretty fancy SM gear, I just have
to practice on it (which would come in handy anyway). The B-cache consists
of 18x CY7C166-20 SRAM plus 5x CY7C170A-25 tag RAM, so they're easily
identified (the KA-675 manual infact points them out).
Replacing 18 SRAMs doesn't sound like a lot of fun, and I have no idea how
to probe the board in the cardcage without disassembling the chassis, in
which case the thing may overheat; opening the CPU bulkhead infact
triggers a prompt reaction from the fan controller.
FWIW, here's a thermography (hope the link works) of the B-cache section
of the KA-675 after being powered up for ca. 30 mins:
https://www.dropbox.com/s/2nsx1dfngp1jfq5/TH710065.BMP?dl=0
Note that the rightmost chip just below the CPU heatsink has a pin that's
ca. 2 degrees warmer than the others. I don't know if that says anything,
but it *is* reproducible. Maybe I should start with that one.
The dead DSSI controller on the other board is easily identified, as it
was physically destroyed in transit. I'm not inclined to transplant a
160-pin PGA as my first foray into SMT... :^\
Thanks for the feedback,
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a
lot of memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
5:23 a.m.
FWIW, here's a thermography (hope the link works) of the B-cache section
of the KA-675 after being powered up for ca. 30 mins:
https://www.dropbox.com/s/2nsx1dfngp1jfq5/TH710065.BMP?dl=0
Note that the rightmost chip just below the CPU heatsink has a pin that's
ca. 2 degrees warmer than the others. I don't know if that says anything,
but it *is* reproducible. Maybe I should start with that one.
I can't really make it out on the image but if it is just one pin that is
hot, maybe there is nothing more complicated wrong than a bad solder joint
at that pin, particularly if it is a power or ground pin.
Regards,
Peter Coghlan
8:50 a.m.
On Thu, 10 Mar 2016 14:23:34 +0100, Peter Coghlan
<cctalk at beyondthepale.ie> wrote:
Hi Peter,
I've already reworked that pin, but to no avail. :^(
I've converted the pic to grayscale for better contrast and highlighted
the pin in red:
https://www.dropbox.com/s/ss76hldqxziazyc/ka-675-1.png?dl=0
For comparison, here's a thermograph of the 2nd KA-675 with the dead DSSI
controller:
https://www.dropbox.com/s/8twvrytrr60mrb9/ka-675-2.jpg?dl=0
The artefact doesn't show up on the 2nd board. Might be a long shot tho.
I'm not sure a chip failure would even show here. This was more of a lame
experiment, since we have the thermal tracer in the lab anyway (and the
pix look cool).
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a
lot of memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
FWIW, here's a thermography (hope the link works) of the B-cache
section of the KA-675 after being powered up for ca. 30 mins:
https://www.dropbox.com/s/2nsx1dfngp1jfq5/TH710065.BMP?dl=0
Note that the rightmost chip just below the CPU heatsink has a pin
that's ca. 2 degrees warmer than the others. I don't know if that says
anything, but it *is* reproducible. Maybe I should start with that one.
I can't really make it out on the image but if it is just one pin that is
hot, maybe there is nothing more complicated wrong than a bad solder
joint
at that pin, particularly if it is a power or ground pin. 
10:32 a.m.
-----Original Message-----
From: cctech [mailto:cctech-bounces at classiccmp.org] On Behalf Of Dr.
Roland Schregle
Sent: 10 March 2016 12:39
To: General Discussion: On-Topic Posts <cctech at classiccmp.org>
Subject: Re: Options for resurrecting VAX 4000/400 and Vaxstation 3200
On Wed, 09 Mar 2016 21:59:27 +0100, Robert Jarratt
<robert.jarratt at ntlworld.com> wrote:
Just powering it on for a few seconds at a time while probing for any really obvious
failures would presumably be pretty low risk. Given that the components face to the right
though, you might be able to do some probing with just the memory removed?
I think one day I will have to equip myself and
learn how to desolder
and resolder surface mount chips. I don't know how many chips
implement the B-CACHE, but perhaps you could replace all of them,
assuming you know which ones they are. Perhaps some careful probing of
the board with a scope might show if there any chips that are perhaps
completely
dead.
You could do the same for the DSSI controller on
the other board of
course, if you can identify that.
Our lab has an EE department with some pretty fancy SM gear, I just have to
practice on it (which would come in handy anyway). The B-cache consists of
18x CY7C166-20 SRAM plus 5x CY7C170A-25 tag RAM, so they're easily
identified (the KA-675 manual infact points them out).
Replacing 18 SRAMs doesn't sound like a lot of fun, and I have no idea how to
probe the board in the cardcage without disassembling the chassis, in which
case the thing may overheat; opening the CPU bulkhead infact triggers a
prompt reaction from the fan controller.
FWIW, here's a thermography (hope the link works) of the B-cache section of
the KA-675 after being powered up for ca. 30 mins:
https://www.dropbox.com/s/2nsx1dfngp1jfq5/TH710065.BMP?dl=0
Note that the rightmost chip just below the CPU heatsink has a pin that's ca.
2 degrees warmer than the others. I don't know if that says anything, but it
*is* reproducible. Maybe I should start with that one.
Looks like you have access to some enviable stuff, so replacing the chips might not be too
bad. I get an occasional error on my 4000-500 at test 14 (also cache related), it
doesn't appear to affect operation, but I am worried something is failing that will
need replacement.
The dead DSSI controller on the other board is easily identified, as it was
physically destroyed in transit. I'm not inclined to transplant a 160-pin PGA as
my first foray into SMT... :^\
Thanks for the feedback,
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a lot of
memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
10 Mar
10 Mar
1:26 a.m.
I might have spare cpu and memory cards. Please contact me off list if you
are interested.
Paul
On Thu, Mar 10, 2016 at 1:25 AM, <emu at e-bbes.com> wrote:
Zitat von "Dr. Roland Schregle"
<roland.schregle at gmail.com>:
The VS is located in Germany, but I'm currently working in Switzerland
and won't get at the thing until my next
vacation, probably sometime
after Easter.
Where in Germany?
9 Mar
9 Mar
2:22 p.m.
Box #1 is a VAX4000 model 400 with no working CPU
(KA-675) and 2x
32Mb RAM, an RF72 (wiped), plus a KZQSA QBUS controller. PSU is good,
fans squeal on startup but run silently once spun up. Have VMS
installation media in CD.
If you can sort out the CPU issue, you probably have enough here to
achieve this in several different ways.
The KZQSA doesn't usually work well with hard drives, but I'm pretty
sure I installed my /600 from CD using its KZQSA and an older SCSI
CD-ROM drive (probably an older Toshiba).
The RF72 disk is a 1GB DSSI drive, and I think it's supported by the
base /400 machine. Once you have a working CPU, you can actually do
some testing on this disk drive with just the VAX console firmware,
because it's intelligent, and you can connect to it via a maintenance
protocol and give it commands.
Alternative to CD installation would be to install VMS in SimH and use
the virtual VAX to netboot and install the hardware VAX.
Box #2 is a VAXstation 3200 with TK50, and an RD54.
PSU and fans ok
(and very quiet), ditto CPU. The RD54 is unformatted; I understand
this can only be formatted in the field with a VS2000 or with some
obscure field diagnostics. There's no SCSI controller, so I can't
install from CD. I haven't been able to track down VMS installation
media on TK50, and I doubt they'd still be readable anyway. On top of
that I have no idea what condition the drive is in, as I have no
blank tapes to test with. I've found tape images online but see no
way to dump these to TK50 (assuming the drive is ok), unless I get a
TZ30.
After formatting the RD54 using the nearby VS2000, the way to get this
one online is probably to netboot it from the SimH VMS instance
described above. However, is the RD54 unformatted, or just empty of
data? It's _in_ a VS3200, after all.
De
10 Mar
10 Mar
4:32 a.m.
On Wed, 09 Mar 2016 23:22:04 +0100, Dennis Boone <drb at msu.edu> wrote:
The RF72 disk is a 1GB DSSI drive, and I think
it's supported by the
base /400 machine. Once you have a working CPU, you can actually do
some testing on this disk drive with just the VAX console firmware,
because it's intelligent, and you can connect to it via a maintenance
protocol and give it commands.
I've talked to it and run the diags; looks good. It is incredibly noisy
though with its intermittent recalibration grind.
Note that the console seems to do fine with the failed B-cache... until
you boot.
After formatting the RD54 using the nearby VS2000, the
way to get this
one online is probably to netboot it from the SimH VMS instance
described above. However, is the RD54 unformatted, or just empty of
data? It's _in_ a VS3200, after all.
I retrofitted the RD54, the VS was originally diskless. I had to run a
cable to the I/O bulkhead from the controller, so apparently it never had
a disk and may have indeed netbooted from a cluster node. I have no idea
what's on that disk, and the neither did the previous owner. BOOT
definitely fails, and the VS3200 console seems to lack any way of testing
it.
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a
lot of memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
9 Mar
9 Mar
3:09 p.m.
I have two KA-675s for this beast: Board #1 (originally installed) has a
failed B-cache (console reports SUBTEST_35_12, DE_B_Cache_diag_mode.LIS)
and crashes with an asynchronous write memory failure when booting VMS
from CD.
I wonder is there a way to disable the B-cache?
I mention this because I have more than one Alphaserver 1000A with failed
B-cache and I have found it is possible to work around this issue by moving a
jumper on the CPU board to disable the B-cache. The result is that the machine
works with reduced performance.
Regards,
Peter Coghlan.
10 Mar
10 Mar
4:40 a.m.
On Thu, 10 Mar 2016 00:09:02 +0100, Peter Coghlan
<cctalk at beyondthepale.ie> wrote:
I have two KA-675s for this beast: Board #1 (originally installed) has
a failed B-cache (console reports SUBTEST_35_12,
DE_B_Cache_diag_mode.LIS) and crashes with an asynchronous write memory
failure when booting VMS from CD.
I wonder is there a way to disable the B-cache? I mention this because I have more than one
Alphaserver 1000A with failed
B-cache and I have found it is possible to work around this issue by
moving a
jumper on the CPU board to disable the B-cache. The result is that the
machine
works with reduced performance.
Yeah, I wondered about that too, but there's no jumper on the KA-675.
Interestingly the console firmware has no problem with the failed B-cache,
or somehow bypasses it. Booting VMS fails though.
--GT
--
"END OF LINE" [MCP, 1982]
"... nowhere in the standards is it specified that 'programs that use a
lot of memory may randomly crash at any time for no apparent reason'"
[Stackoverflow forum, 2012]
9 Mar
9 Mar
4:07 p.m.
I have also considered selling the units (or parts
thereof) if
nothing gives.
If it comes to that, I am quite sure you will find buyers for at least
some of it; heck, for a QBus SCSI interface I'd pony up some cash
myself (and there aren't many things I'd be interested enough in to
more than cover shipping for, especially now that I'm as
physical-space-constrained as I am).
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
10:14 p.m.
On Wed, Mar 9, 2016 at 4:07 PM, Mouse <mouse at rodents-montreal.org> wrote:
An M5976 KZQSA can often be picked up cheap on eBay as they are not
MSCP compatible and are really only good for accessing SCSI CD-ROM
drives while running VMS, or while installing VMS. They do work well
for that.
For example this one sold for only $25 a month or two ago with only one bidder:
http://www.ebay.com/itm/111875354977
I have also
considered selling the units (or parts thereof) if
nothing gives.
If it comes to that, I am quite sure you will find buyers for at least
some of it; heck, for a QBus SCSI interface I'd pony up some cash
myself (and there aren't many things I'd be interested enough in to
more than cover shipping for, especially now that I'm as
physical-space-constrained as I am).
3208
days inactive
3210
days old
20 comments
8 participants
participants (8)
-
cctalk＠beyondthepale.ie -
drb＠msu.edu -
emu＠e-bbes.com -
glen.slick＠gmail.com -
mouse＠Rodents-Montreal.ORG -
robert.jarratt＠ntlworld.com -
roland.schregle＠gmail.com -
useddec＠gmail.com