Hello, all:
I'm considering upgrading the server equipment in my house and before I
shift things around or consider selling stuff on eBay I wanted to see if
anyone may be interested in the system I have. I keep this equipment in the
shop, which in a ranch-style house, is below the bedrooms. The half-dozen
fans are pretty noisy and my kids complain about the drone. So, I'm want to
put together something a bit quiter :-)
The server is a Compaq ProLiant 800R rack-mounted dual Pentium Pro server
with 384mb of RAM, a 9gb boot drive and a Smart 2DH RAID controller. The
RAID array is in a Compaq ProLiant U1 rack-mounted array which contains 5
9.1gb hot-swap ultra-wide 7200RPM SCSI drives. I also have some spare system
components to go along with it.
The stuff is heavy but shippable by UPS in two boxes (I have the original
crate for the U1 enclosure). It's been in continuous service for two years
now. The server came off-lease from Ernst & Young. The U1 crate was new as
were the drives. It presently runs Windows NT4 Server.
If anyone might be interested, please contact me off-list. Shipping would
be from 11791 and figure that one box weighs 50 pounds and the other about
35. I'd be interested in swapping it for an IMSAI 8080...ha ha...just
kidding. About $300 plus shipping would do it.
Thanks.
Rich
Rich Cini
Collector of classic computers
Build Master for the Altair32 Emulation Project
Web site: http://highgate.comm.sfu.ca/~rcini/classiccmp/
/************************************************************/
der Mouse <mouse(a)rodents.montreal.qc.ca> wrote:
> Does anyone know of any doc on the protocol spoken by the LK401?
I have the LK201 spec, which appears in Appendix B of VCB02 Video Subsystem
Technical Manual (EK-104AA-TM, a scan is online and listed in
http://vt100.net/manx/), but nothing for LK401. But I like the LK201 better,
though. LK201 is more classic, more real. LK401 is a more flimsy plastic
thingy. I'm also quite pissed off by and won't tolerate the removal of the
Compose and Wait LEDs, and the PeeCee-smelling Alt keys are disgusting.
(What ASCII codes are they supposed to generate? A keyboard is by definition a
device for transferring ASCII codes from a human to a computer.)
> Specifically, both shift keys give me
> the same code, and both "Alt Function" keys and the right-hand "Compose
> Character" key are completely dead.
Yup, the LK401 is in LK201 compatibility mode. It's there so that those who
love LK201 but don't have one can use LK401 as a stopgap substitute until we
can seize state power in a Revolution and order resumed production of LK201s.
> While the shift keys could be
> wired together, the presence of an LK_KEY_R_SHIFT define argues against
> that,
They are wired together on LK201. Separate codes for left and right Shift keys
are an LK401 extension.
> I conjecture that at least some of this is because it's running in
> LK201 mode; on comparing it to an LK201 I note that the three dead keys
> have no obvious analogues on the LK201.
Exactly.
> There are defines which appear to imply that sending 0xe9
> and expecting 0xba in return might put it in LK401 mode,
That's what you need to do.
> but there's no
> indication of what changes (for example, how LK201-compatible it is).
> I can of course just try it and see, but I'd much rather have real doc
> if it's available.
Well, sorry, I don't have any LK401 docs, just LK201, so you'll have to just
experiment.
> I'm not sure whether this is
> strictly on-topic or not,
It definitely is!
Paul Koning <pkoning(a)equallogic.com> wrote:
> I can't offer LK401 specifics, but just in case it helps, you can find
> the complete LK201 description in the PRO 300 series technical
> manual. An online copy lives in
> http://www.bitsavers.org/pdf/dec/pdp11/EK-PC300-V1-001_pro300tecV1.pdf
> or ...V2.pdf. I don't remember which of the two volumes has this.
It's probably the same LK201 spec that I have from Appendix B of VCB02 TM. (I
can't look at it, though, as it's a PDF, and I don't look at PDFs. If you want
me to look at something, make it ASCII.)
MS
P.S. I'm right in the process of writing some code for LK201. Here is the
header comment describing what I'm doing:
/*
* This module turns the DEC LK201 keyboard into an IFCTF keyboard. All LK201
* keys are given their standard ASCII meaning, and Compose feature is supported
* for entry of 8-bit characters (see below). Arrow keys generate ISO standard
* control sequences. The keypad can operate in numeric or application mode
* like on VT100, generating the same codes/sequences as on VT100. All function
* keys generate control sequences like on VT220 with some extensions. In
* general, the LK201 operates like the input half of VT220.
*
* ASCII input from the keyboard goes into a UNIX tty. This module can be
* activated by any user on any given tty, in which case the tty line is to be
* connected to the LK201, and input goes into the input queue of the same tty
* via ttyinput. Workstation drivers in the kernel can also attach this module
* in different ways so that the hardware which talks to the LK201 doesn't have
* to presented as a tty, and the input can be routed to another tty that may
* also handle workstation display output.
*
* Input in three charsets is supported: ASCII, ISO Latin-1 and KOI-8. The base
* keyboard always inputs ASCII and supports all 128 possible 7-bit characters.
* If the tty receiving the input allows 8-bit input, Compose key is enabled and
* 8-bit ISO Latin-1 characters can be entered. Hex compose using the numeric
* keypad is supported like on VT340 and VT420, which allows all 8-bit codes to
* be entered, including C1. (While 7-bit characters can also be entered via
* Compose, it is intended for entering 8-bit ISO Latin-1 characters, and is
* enabled only when the receiving tty allows 8-bit input.)
*
* An additional feature not offered by DEC is provided to enter 8-bit input in
* Russian KOI-8 instead of Latin-1. If the tty receiving the input is
* configured for KOI-8, the Latin-1 Compose feature is not available (Latin-1
* characters are garbage in KOI-8 environment) and the Compose key is redefined
* as the KOI-8 RUS/LAT switch. LAT mode is ASCII and in RUS mode Russian KOI-8
* characters are entered per yawerty map. Also in KOI-8 mode a Meta mode is
* provided which temporarily supercedes the RUS/LAT mode, entered via
* Shift-Compose. In this mode the keyboard uses the standard 7-bit ASCII map
* (with Shift, Caps Lock, and Ctrl working normally), but bit 7 is set. Like
* hexadecimal compose in Latin-1 mode, this feature allows all 8-bit codes to
* be entered.
*
* The VT220-like operation of LK201 can be altered in two ways to make it more
* UNIX-friendly. One modification, originating in VT320, puts ESC at E00
* (upper left corner of main keypad), moves the `~ key to B00 where DEC has put
* <>, and puts '<>' over ',.'. This modification makes the keyboard more like
* traditional ASCII keyboards UNIX was designed for. The other modification
* makes the F11/12/13 keys generate ESC/BS/LF like in VT100 mode on VT2xx/3xx
* terminals, while all other function keys generate their "canonical" VT2xx-
* style control sequences. This modification allows people to start taking
* advantage of new VT2xx generation features while keeping the ESC/BS/LF
* function of F11/12/13 keys from VT100 mode. Finally, the character rubout
* key generates the erase character set on the receiving tty.
*
* Autorepeat, bell and keyclick can be customised like on DEC products. A note
* about keyclicks though. The LK201 is misdesigned in a way that makes very
* clear why keyboards should be designed and built as IFCTF keyboards in
* hardware. LK201 was designed so that the host needs to configure it and then
* for the most part let it take care of itself. It implements both autorepeat
* and keyclick internally so that in theory the host only needs to receive and
* accept its transmissions without sending anything back on every key.
*
* The problem is that the keyboard doesn't know whether any given key has any
* function or not in the application in use (in each combination of Ctrl and
* Shift modifiers), and with the VT2xx/3xx terminals we've grown used to the
* keyclick being generated only if the key is defined. The keyboard isn't
* really designed for host control of the keyclick either: while there is a
* command to generate a keyclick, the keyboard is clearly designed for
* automatic keyclick generation. So how do the terminals do it? Magic?
* Well, they do a real kludge. When the keyclicks are enabled in setup, the
* LK201 is configured with keyclicks disabled. When the terminal receives a
* code for a pressed key, it checks whether that key is defined and thus
* should sound a keyclick. If a keyclick is needed, it sends a sequence to
* the LK201 that enables the keyclicks (with the desired volume), sounds the
* keyclick, and disables the keyclicks right away. Of course this is ugly and
* basically defeats the LK201 design. (Actually this is so ugly that I just
* couldn't believe that DEC terminals do it. I had to sniff the traffic
* between VT340 and LK201 to convince myself that it really does this. It
* really does unfortunately.)
*
* In this implementation I've decided not to bother with this and to let LK201
* click on every key. In this implementation almost all keys are always
* defined and generate some code or sequence. The only exceptions are Compose
* in 7-bit only mode and some main keypad keys that are not defined with Ctrl.
* Since these are rare exceptions and they are the only ones, I have decided
* not to bother.
*/
Since this is actually my page, I should probably see what's going on...
admittedly, I've kind of let it lapse for the past couple of years,
(things got really busy for a while...). When I first put this together,
it was the only reference out there of this type for SGI stuff (which is why
I did it.) Now, there seem to be a whole host of SGI specific sites, so
I never really saw the need to update it... the new sites seemed to be
handling the newer systems quite adequately.
The last time I logged into Geocities, it was an independent company...
I just tried it a few minutes ago and I don't seem to have an
account anymore... Also, it seems that Geocities is now owned by
by Yahoo...
Also, I haven't had anyone contact me about a problem with the hacked-up
SGI logo I used, but it could be because the email link on that page seems
to have gone the way of my geocities acount... vanished.
In the past, I have received requests (freely granted) requests by people
to mirror the site, so there should be some copies available... I need to
see if I can dig up my original, or download one of the mirrors so that I
can see about restoring and/or rehosting it somewhere.
I'll see if I can figure out what is going on, and let everyone know...
-al-
-cordaaj(a)nswc.navy.mil
-----Original Message-----
From: ben franchuk [mailto:bfranchuk@jetnet.ab.ca]
Sent: Friday, February 20, 2004 10:48 AM
To: On-Topic and Off-Topic Posts
Subject: Re: "This old SGI" page - anyone have a copy?
James Rice wrote:
> Sgi has been methodically shutting down all of the hobbyist websites
> that make any reference to Sgi or use any form of any Sgi logos. You
> would think that a corporation that has as many problems as Sgi would
> have better things to do.
Well can we get people to burn CD-roms of web sites with old
computer information least it be forgottion or distroyed as
web sites change and Server's crash?
Does anyone know of any doc on the protocol spoken by the LK401? I've
got one, and while I can deduce some of the protocol from the NetBSD
driver, there are some problems. Specifically, both shift keys give me
the same code, and both "Alt Function" keys and the right-hand "Compose
Character" key are completely dead. While the shift keys could be
wired together, the presence of an LK_KEY_R_SHIFT define argues against
that, and surely the other three keys are not supposed to be dead.
I conjecture that at least some of this is because it's running in
LK201 mode; on comparing it to an LK201 I note that the three dead keys
have no obvious analogues on the LK201.
Looking at the driver I'm using, this appears to be the keyboard's
fault; I see very little translation going on between the keyboard and
the events reaching userland.
This leaves me looking for enough protocol docs to tell the keyboard to
do these. There are defines which appear to imply that sending 0xe9
and expecting 0xba in return might put it in LK401 mode, but there's no
indication of what changes (for example, how LK201-compatible it is).
I can of course just try it and see, but I'd much rather have real doc
if it's available.
I did some looking around and found a number of archived messages
talking about LK401s, but none that said anything about the protocol at
this level.
In case it matters, the keyboard I have is
MODEL NO. LK401-AA
REV. NO. A03
SERIAL NO. HJ203R6565
CAT. LIST. 108RX33S-1E
FCC I.D. A09-LK401
and I'm using it with a DEC 3000/300X. I'm not sure whether this is
strictly on-topic or not, but if not I think it's probably close. :)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML mouse(a)rodents.montreal.qc.ca
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
On Sat, 2004-02-07 at 23:35, Jules Richardson wrote:
> Oh, and if anyone's dishing out Perq wisdom there's also a Perq 1 with
> a
> display fault too - on that one the image is centered on the screen,
> but
> squashed into about 80% of the normal width, and maybe 10% of normal
> height. It's also very non-rectangular in nature.
Chatted with my good buddy who still makes a living repairing
terminals. His guess is that the horizontal yoke isolation cap is
leaking/bad. This will definitely make the horizontal squoosh. Many
terminals derive the drive voltage for the vertical from the horizontal
flyback - thereby causing the problem you are seeing.
His recommendations:
1. look for an oversized cap (electrolytic - yup one of those
beasties...) near the horizontal drive transistor (generally
heatsinked) that has a rating between 35 and 60 volts and a value
between 2.2 and 20 microfarads. This is the isolation cap. If it is in
the 2.2 to 4.7 volt range replace it with a film cap - you will never
have a problem again. You can't reform this one since they put AC
(albeit mostly DC) through the cap and once it goes it's gone.
2. Replace any electrolytic near anything that looks hot.
3. Inspect, clean, lubricate, and replace, if necessary, the yoke
connector socket. His experience is that when the cap goes, the current
through the yoke goes up and fries the connector. The bad connection
will cause early failures.
If the vertical problem persists, you probably have a similar problem
with a cap in the vertical drive or a power supply problem.
Good luck
Claude Ceccon
I have a Sigma floppy disk controller which I believe to be for Qbus.
The assembly number is 400255 rev B and S/N is 4331. It is a dual board
and has a pair of 2901 bit slices and an assortment of bipolar PROMs.
From the field guide, I found this entry:
SDC-RXV31 Q Sigma floppy disk controller. Emulates RXV21/RX02.
(Supports Mitsubishi M2696-63)
I assume this is the one.
Does anyone have a manual for this controller (copy or scan)?
--tnx
--tom
Hi!
A few month ago I acquired a VAXstation 3200. It runs runs very nicely
with a Emulex UC08 SCSI-Controller off a 1GB full-height SCSI-Disk.
There is one QBUS card in the system that I can't identify.
As far as I know the VAX has been used for measurement data aquisition
in a physics laboratory.
The only connector to the outside is for a 40-pin ribbon cable. I got a
very long (10m I guess) cable with the box so I suppose it is using some
kind of differential data transmission.
Unfortunately I don't know what was connected to the other end of the
cable. Probably the card is useless without that second part (maybe a
A/D-Converter?).
The board occupies all 4 slots and is populated mostly with small ICs of
the 74xxx series and some PALs.
The Label says:
KINETICSYSTEMS
MODEL D1571
MODEL 2922-Z1B
I did not find any usable information on he net. Does anyone of you know
what this board does?
Thanks in advance,
Sebastian
> > Rumor has it the Foothill flea market is gone (moving to Lockheed?)
>
> Somewhere near there, details at <http://www.asvaro.org/fleamarket.shtml>.
>
> -Frank McConnell
This isn't too bad, probably easier to get to (better freeway and
even Light Rail Access)....
