> 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
Hi folks,
I have a question about floating CSR allocation on PDP-11s. Both the 1976 and 1981 versions of the PDP-11 peripherals handbook indicate the floating CSRs are to be allocated starting at address 760010. However, both the XXDP FLOAT program and simh's autoconfig suggest I should set my DZ11 (first floating CSR device in my config) to 760100. Anyone know what gives?
thanks,
--FritzM.
Hi folks,
I have found it very convenient to maintain a simh configuration that parallels the physical hardware configuration of my PDP-11/45. I'm just about to add a DR11-C for a physical interface that I am building -- this will "grab" a floating interrupt ahead of a DZ11 that I already have in the machine.
Does anyone here know of convenient way to inform simh's autoconfig that I wish to insert a DR11-C?
cheers,
--FritzM.
> From: Allison
> you have to pull the panel apart to replace them, gets tiring. Modern
> yellow LEDs are nice and bright, and don't burn out.
> Less digging in the box is a good thing as over time fumble errors can
> hurt it.
Agree about replacing lamps - we switched to LEDs BITD because replacing
burned-out lamps (especially when you're trying to fix some _other_ problem)
when there's something better available is just, silly.
> Modern red leds at 8mA are very much brighter. However the yellow look
> more like lamps.
What about warm white LEDs, though? The ones we used in the QSIC indicator
panel are, to me, pretty much indistinguishable from the lights as I recall
them from BITD. I mean, maybe if I had them sitting next to each other, I
could tell, but... Those are SMD, though, but maybe they are available
in bulb replacement form?
Noel
I am the temporary caretaker of a Sperry UTS-40 "intelligent" terminal (very
green screen, Z-80 based terminal from the late 70's or early 80's) which I
grabbed on eBait for sending parts to Dominique Carlier over in Belgium. The
CRT, power supply and character generator seem to work (gives a very sharp
semi-random geometric display on power-on, sometimes with a few nicely drawn
characters interspersed), but the darn thing does not seem to boot on reset.
The picture goes away and weird sound is emitted from the speaker after a
long beep-of-death. I was wondering if anyone had service documentation. Or
a dump of the firmware. Al, anything that crossed your desk?
Marc
I have a BA11-M box with the usual front panel control, however it was
damaged and all three switches have been sheared off.? The LED's and the
circuit card that connects to the power supply appear to be OK.? I would
like to repair it and put it back into service.? Is there a replacement
for those switches?
Doug
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. In my mis-guided youth I resorted so
sawing them off perfectly good boards. I would rather not do that
again.
If anyone has prototype boards they have designed with fingers or dead
boards they would part I will take them. My methods are crude, but
effective.
-chuck