Place your wagers...
How many more years do you think it'll take before decent, practical-sized Alphas, like the DS15, and to some degree, the DS10, will be obtainable at hobbyist-friendly prices?
I have an ES47 I got for a price I could stomach, but it's sans rail kit, drinks power like it's going out of style, and can anchor a 40-ft yacht.
Anyone out there do Alphas anymore?
Hello!
I have four unibus boards that came in a 11/34 which was used for radiation
dose measurement at a hospital.
Three of them are made by Computer Design & Application inc and is a three
board set interconnected with over the top flat cables. It has some kind of
AMD 29xx based bitslice processor with 2903,2910 and 2914 chips. One board
has some kind of dedicated memory one board has 4 TRW chips which I think
are AD converters.
https://i.imgur.com/lMvhxOp.jpg?1https://i.imgur.com/LEVN5Qp.jpghttps://i.imgur.com/kcSnDRy.jpghttps://i.imgur.com/ZfFrq3j.jpg
Then there is some kind of serial com board with four UARTs on it.
https://i.imgur.com/YvnTlxq.jpg
Is there any interest in these boards? Trade for something interesting DEC
stuff maybe? Or something else?
/Mattis
I'm cleaning out my accumulation of "stuff" and there are several
things that aren't worth the effort of putting on ebay. If
anyone on this list wants them, they are yours for the cost of
shipping. The first item is:
QB-5JCAG-SA
Compaq Storageworks
RAID Array 450 V5.4A Platform Software Kit for SUN Solaris
Contains:
AG-R20SE-BE Software CD "RAID Array 450 V5.4A for SUN Solaris"
AE-RBDYB-TE Software Product Description SPD 64.64.05
AA-R20TD-TE Release Notes
AA-R20RD-TE RAID Array 450 V5.4 for Solaris 2.x Installation Guide
AA-R24LA-TE StorageWorks Command Console (v1.1) User's Guide
EK-HSZ50-CG HSZ50 HSOD v5.1 Array Controller Configuration Manual
EK-HSZ50-SV HSZ50 HSOD v5.1 Array Controller Service Manual
EK-HSCLI-RM HSZ50 HSOD v5.1 Array Controller CLI Reference Manual
It weighs just under 5 pounds, so I estimate the shipping cost
would be $10 to $20.
Send me an email if you want it. If I don't hear from anyone
in a few days, it goes into the dumpster.
Alan Frisbie
Ethan Dicks <ethan.dicks at gmail.com> wrote:
> I don't happen to have a VR201 here right now to measure directly (or
> I would just do that), but IIRC, there's a threaded mounting insert on
> the bottom (for the "E.T. Stand", if nothing else), I want to
> fabricate a shelf clip for a VR201 and am seeking the diameter/thread
> pitch for the insert. Does anyone have that info handy? It's likely
> larger than 1/4-20 from what I remember.
There are four brass inserts in a trapezoidal pattern, each threaded
1/4-20 (National Coarse). The trapezoid is 7.0" center-to-center
for the two nearest the screen, and the rear ones are 5.0" center-to-center.
It is 5.0" between the front (screen) pair and the rear pair.
This is for a VR201-B -- other dash-variants may be different.
If there is a base with a single large threaded insert, it may be
an adapter that goes between the VR201 and the stand.
Now, could someone please tell me the pinouts for the 15-pin connector?
I would like to use it to view RS-170 video, if possible.
Alan Frisbie
Hello Folks.
In the continuing saga of sorting through a big batch of Commodore stuff
>from my collection, I've listed 6 different early revision Commodore 64
computers for sale. Complete details and links to photographs are on the
VCFed forums here:
http://www.vcfed.org/forum/showthread.php?62641-Sellam-s-Commodore-Sales-Th…
Please do inquire directly to me by private e-mail for fastest response.
Thanks!
Sellam
Hi, All,
I don't happen to have a VR201 here right now to measure directly (or
I would just do that), but IIRC, there's a threaded mounting insert on
the bottom (for the "E.T. Stand", if nothing else), I want to
fabricate a shelf clip for a VR201 and am seeking the diameter/thread
pitch for the insert. Does anyone have that info handy? It's likely
larger than 1/4-20 from what I remember.
-ethan
> From: Allison
>> What about warm white LEDs, though? ... maybe they are available in
>> bulb replacement form?
> I used a supply of dead bulbs to make mine. a little heat and the glass
> goes, a resistor and a 3mm led and good to go.
Urr, I'm not up to making them! I was really hoping for the plug-in
replacement ones in white... They used to make replacements in red (we
replaced the bulbs in our -11/45 with them, BITD), so I was hoping.
Anyone know of a contemporary source for LED replacements for front panel
bulbs? (Of any colour!)
Noel
> I'll have to redo my kludgy fix to gmtime() ... I guess I'll have to fix
> it for real, instead of my kludgy fix (which extended it to work for
> 16-bit results). :-)
> ...
> And on the -11/23:
> Note that the returned 'quotient' is simply the high part of the dividend.
Heh. I had decided that the easiest clean and long-lived fix was to just to do
it right, using the long division routine used in the V7 C compiler runtime:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V7/usr/src/libc/crt/ldiv.s
and I vaguely recalled reading a DMR story that talked about that, so just for
amusement I decided to re-read it, and looked it up:
https://www.bell-labs.com/usr/dmr/www/odd.html
(the section "Comments I do feel guilty about"), and it's lucky I did, because
I found this:
Addendum 18 Oct 1998
Amos Shapir of nSOF (and of long memory!) just blackened (or widened) the
spot a bit more in a mail message, to wit:
'I gather the "almost" here is because this trick almost worked... It has a
nasty bug which I had to find the hard way!
The "clever part" relies on the fact that if the "bvc 1f" is not taken, it
means that the result could not fit in 16 bits; in that case the long value
in r0,r1 is left unchanged. The bug is that this behavior is not documented;
in later models (I found this on an 11/34) when the result does fit in 16
bits but not in 15 bits ... which makes this routine provide very strange
results!'
So this code won't work on an 11/23 either (which bashes the low register of
the pair; above). I'd have been groveling in buggy math, again...
Caveat Haquur (if you're trying to run stock V7 on a /23 or /34)!
Noel
> From: Charles Dickman
> Does anyone have DEC bus edge connectors they are willing to sell?
> I would like to do some OMNIBUS interface prototyping and I need a way
> to connect to the bus back-plane.
Have you looked through Douglas Electronics' offerings? They have a lot of
DEC-backplane compatible boards that might be what you want, e.g.:
http://www.douglas.com/index.php/18-de-77.html
this one.
Noel
So, I have discovered, to my astonishment, that the double-word version of the
DIV instruction on the PDP-11 won't do a divide if the result won't fit into
15 bits. OK, I can understand it bitching if the quotient wouldn't fit into 16
bits - but what's the problem with returning an unsigned quotient?
And, just for grins, the results left in the registers which hold the quotient
and remainer is different in the -11/23 (KDF11-A) and the -11/73 (KDJ11-A).
(Although, to be fair, the PDP-11 Architecture Manual says 'register contents
are unpredictable if there's an overflow'.)
Oh well, guess I'll have to redo my kludgy fix to gmtime() (the distributed
version of which in V6 qhas a problem when the number of 8-hour periods since
the epoch overflows 15 bits)! I guess I'll have to fix it for real, instead of
my kludgy fix (which extended it to work for 16-bit results). :-)
I discovered this when I plugged in an -11/73 to make sure the prototype QSIC
(our RK11/etc emulator for the QBUS) worked with the -11/73 as well as the
-11/23 (which is what we'd mostly been using - when we first started working
on the DMA and interrupts, we did try them both). I noticed that with the
-11/73, the date printed incorrectly:
Sun Mar 10 93:71:92 EST 1991
After a certain amount of poking and prodding, I discovered the issue - and
on further reading, discovered the limitation to 15-bit results.
For those who are interested in the details, here's a little test program that
displays the problem:
r = ldiv(a, b, d);
m = ldivr;
printf("a: 0%o %d. b: 0%o %d. d: 0%o %d.\n", a, a, b, b, d, d);
printf("q: 0%o %d. r: 0%o %d.\n", r, r, m, m);
and, for those who don't have V6 source at hand, here's ldiv():
mov 2(sp),r0
mov 4(sp),r1
div 6(sp),r0
mov r1,_ldivr
rts pc
So here are the results, first from a simulator:
tld 055256 0145510 070200
a: 055256 23214. b: 0145510 -13496. d: 070200 28800.
q: 0147132 -12710. r: 037110 15944.
This is _mathematically_ correct: 055256,0145510 = 1521404744., 070200 =
28800., and 1521404744./28800. = 0147132.
And on the -11/23:
a: 055256 23214. b: 0145510 -13496. d: 070200 28800.
q: 055256 23214. r: 037110 15944.
Note that the returned 'quotient' is simply the high part of the dividend.
And on the -11/73:
a: 055256 23214. b: 0145510 -13496. d: 070200 28800.
q: 055256 23214. r: 037110 15944.
Note that in addition to the quotient behaviour, as with the /23, the
'remainder' is the low part of the dividend.
Noel