Amongst other things, I picked up a SGI Indigo2 system yesterday. It turned
out that it had the original packaging, and that it's an Impact 10000 machine.
For graphics however it has a four-board set; does anyone know what this
might be? Wikipedia talks about a three-board set for the Maximum Impact,
and fewer cards for lesser options, but I've not seen mention anywhere of a
machine using four (unless they're just not counting the analog output
board as part of the three?)
I'm not sure what it has for RAM; all of the sockets are filled. Someone
had scribbled 32MB and 1GB of disk on the box, but it has 2 x 4GB drives
fitted, so that's not necessarily correct.
I need to clean the dust out before I try powering up, but does anyone know
what a minimum config would be? Can I power up with no disks and
framebuffer, and expect to get a serial console? I'd like to not stress the
PSU (or risk the framebuffer cards) initially if possible - the previous
owner said they never ran it, although it was supposedly working when they
got it.
cheers
Jules
So I may have been a bit premature in my declaration earlier this week
that letting the 4014 warm up for a few minutes solves the storage problems.
For the time being, I have it hooked up to a Linux box (so I can 'cat'
various files at it and stare in awe as it draws random things) and it
seems to be performing flawlessly; everything works (including the
discrete plot extensions). But I've noticed that over time as I clear
the screen that garbage starts accruing around the edges of the screen
-- only the middle gets properly erased.
At first power-on, the area that gets cleared is a circle maybe 10" in
diameter; this increases slowly over time and if I let it run for 15-20
minutes *most* of the screen gets cleared but there's always a bit on
the edges that remains.
I went through the portions of the alignment procedure outlined in the
service manual related to storage, and all voltages were within a
percentage point or two even after all these years, so not much required
adjustment.
There are two adjustments for the Collimation that control the size and
shape of the flood that erases the screen; the service manual suggests
adjusting these until the flood covers the screen. Adjusting the pots
all the way counter-clockwise causes the flood to get *slightly* larger
and cover more of the screen, but it's still not enough.
From reading the circuit description for the erase circuits (starting
on page 5-82 of the service manual), I note that the duration of the
flood (as controlled by the Collimation circuits) is controlled by an RC
network and I suppose it's possible that one or more of the capacitors
is out of spec -- but I don't know if the length of the flood has
anything at all to do with the area it covers -- can anyone shed some
light on this?
I suppose it's more likely that the tube's just showing its age. I
suppose I should be happy it works as well as it does.
At any rate, if anyone has any insight here, I'd love to learn more...
- Josh
Having a poke around Wikipedia, I found the following interesting
detail in the 3278 entry:
"3278 terminals continued to be manufactured in Hortolandia, near
Campinas, Brazil as far as late 1980s, having its internals redesigned
by a local engineering team using modern CMOS technology, while
retaining its external look and feel."
That sounds right up my street. Anyone know any more? Ever seen one?
http://www.corestore.org
'No greater love hath a man than he lay down his life for his brother.
Not for millions, not for glory, not for fame.
For one person, in the dark, where no one will ever know or see.'
Dave wrote...
----
What is the symptom with the CRT? I think that was the achilles heel of the MDS. It usually was the connectors on the cable to the CRT control board. Some of the pins carry too much current and the heat made them go intermittent. The other problem that I found was on the control board inside of the CRT module. It was usually cold solder joints and a little touch up usually fixed it.
----
I'm in the midst of a classiccmp-related project with a deadline that will take many months, but eventually I'll get back to the MDS.
As I recall when I pulled out the mds a few months ago, half the time on powerup there was no crt display, and when it would come up, the diagnostic firmware indicated a problem with the crt control board. Sometimes during the powerup sequence the display would work but then go blank.
I also recall that maybe a year ago when I pulled it off the shelf, I could not find my diskettes for the system :( I know they were in the basement, but I looked for a couple days and could not find it. I'd gladly pay something reasonable for some 8" floppies with ISIS2, ASM, PLM, etc.
J
Does anyone have experience with the hpdrive project?
I'm wondering if the following card might work with it:
http://www.ebay.com/itm/HP-Agilent-82350A-E2078A-PCI-GPIB-Interface-Card-/3…
I'm not sure what chipset it uses, and I can't find info from the project page on whether the hp card will work.
thanks.
-Bob
Today I mailed off a couple HP 2100A/S front panel keys (they are the round
tubular "security key" type) to a fellow listmember in need. I thought I had
a whole box of them, but it turned out virtually all of those were DEC keys.
So I had 3 copies of the key made today (two for the listmember, one extra
for me). When I tested them before dropping them in the mail, 2 worked and 1
did not (of course, I sent off the 2 that worked to the listmember).
Since I have to go back to the locksmith to get the 1 key redone, I thought
I'd offer to get keys for the 2100A/S made for anyone that wants them. I
guess it is possible that your 2100A/S may use a different key, but at least
every 2100 I've come across uses the same key. The locksmith charges $8 per
key, and figure $2 bucks for shipping. I'll probably head back to the
locksmith Monday so if anyone is in need, let me know.
Please note - the keys for HP 1000 aka 21MX M/E/F are completely different
and not what I'm talking about here. Just the 2100A or 2100S. But I guess if
anyone needs keys for those, I can get some made as well. If it's for a 1000
or MX key, let me know if it's a M series (dual edge key, switch has standby
position) or E/F (single edge key, not a switch just a front door latch).
Best,
J
Does anyone want a copy?
It includes the Tandon TM-848-1E, TM848-2E operating and service manual and the Tandon TM501, TM502, TM503 OEM service manual.
Al, would you like a copy for bitsavers? If so, how to upload?
It is about 34 megabytes and 416 pages long.
It is already in PDF format. That's what my scanner produces.
Thanks,
Kelly
While sorting through some Unibus cards I've had on a dusty shelf for
years, I came across a strange card (picture at
https://www.flickr.com/photos/pnt103/17011635052/).
It has no maker's name, but what looks like a zigzag triple S logo near
the centre of the top edge, and the legends "2010-60", "2010-6001 C835"
and "EM PC" next to that.
Apart from 74LS series, it has the following noteworthy ICs:
10 x Texas 74S2472 PROMs on left
4 x 20-pin and 1 x 16-pin ICs look like PALs at lower right
2 x 74LS181 (4-bit ALU) near the centre, with
2 x AMD 27S03 (16x4-bit bipolar RAM) and 4 x AM2907 (quad bus xcvr)
2 x white ceramic gold-top ICs 93L422-DC (256x4 static RAM)
12.5MHz crystal
2 x 7439 (marked "SEL"), 2 x DS8837, 5 x DS8641
12 x 75452 (high current high speed dual-NAND peripheral drivers)
and a 50-pin 3M IDC connector and a 2x15-way edge connector on the top edge.
Any suggestions as to what it is or who made it?
Being a hex-height card but having only CDEF fingers, it's the exception
that proves the rule that all Unibus hex cards have all six sets of
contacts ;-)
--
Pete
Pete Turnbull
> From: Paul Koning
> The general rule of device drivers is to assume that the hardware is
> misbehaving, and double check everything.
Right, but it needs to _actively log_ when it has to fix something, otherwise
you wind up in the situation of the semi-famous old Multics problem where
(IIRC) the system was running slower and slower... finally someone looked at
the Disk DIM (driver) counters, and one drive was slowly failing, but the
industrial-strength recovery code in the Multics Disk DIM was masking the
problem (except for the performance degradation). The DIM was thereupon
modified to notify the operator if 'too many' retries had to be done 'too
often'.
Noel
