On 30 January 2015 at 23:43, js at cimmeri.com <js at cimmeri.com> wrote:
>
>
> On 1/30/2015 5:35 PM, Jules Richardson wrote:
>>
>>> And "whilst" I'm at it, why do some insist on using "blinkenlights" in re
>>> CPU front panels instead of correct English -- blinking lights?
>>
>>
>> Because it's mildly amusing.
>
>
> Maybe the first time it was... :)
It's not only that. It's because 'blinking lights' is generic, it
could mean anything. But 'blinkenlights'.. you'll *know* what it
means.
Here:
http://www.ebay.com/itm/141300893919
The seller has them listed at 'Buy-It-Now' for $1,800, but the listing does
say 'make an offer', so you might be able to get it down a ways, to something
more reasonable. They seem like they have an interesting (non-identical) set
of peripheral cards. However, I know nothing of HP's, so take this all with a
large grain of salt!
Noel
-----Original Message-----
>From: Noel Chiappa <jnc at mercury.lcs.mit.edu>
>Sent: Jan 30, 2015 5:19 AM
>To: cctalk at classiccmp.org
>Cc: jnc at mercury.lcs.mit.edu
>Subject: Re: strange number corruption on pdp11/34
>
> > From: Don North
>
> > So here is the octal print routine in the M9312 console boot prom for
> > the '34:
>
>I'm curious, is that the 'original' source, or is this dis-assembled from the
>PROM contents? Is the complete program available somewhere?
Disassembled and re-commented source. Available here:
http://ak6dn.dyndns.org/PDP-11/M9312/
along with most all of the other M9312 boot and device PROMS.
>
> > So I would speculate either 'rol' or 'rolb' are always rotating in a 0
> > bit instead of the c-bit, or possibly the c-bit is stuck at zero.
>
>Yup, good suggestion. And that would likely explain why things boot; I can't
>see too many OS's using 'ROLB'!
>
> Noel
>ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND
POPPENCORKEN MIT SPITZENSPARKEN.
This is hilarious (particularly if you know German)! I didn't know about it,
thanks for posting! I'll hang it above my collection!
Marc
------------------
Because the Faux German Blinkenlights is so much cooler to say. It?s a
corruption of Blinenlichten from an old joke:
ACHTUNG!
ALLES TURISTEN UND NONTEKNISCHEN LOOKENPEEPERS!
DAS KOMPUTERMASCHINE IST NICHT F?R DER GEFINGERPOKEN UND MITTENGRABEN!
ODERWISE IST EASY TO SCHNAPPEN DER SPRINGENWERK, BLOWENFUSEN UND
POPPENCORKEN MIT SPITZENSPARKEN.
IST NICHT F?R GEWERKEN BEI DUMMKOPFEN. DER RUBBERNECKEN SIGHTSEEREN KEEPEN
DAS COTTONPICKEN H?NDER IN DAS POCKETS MUSS.
ZO RELAXEN UND WATSCHEN DER BLINKENLICHTEN.
which dates to the 1950?s?
See also the insistence on the plural of VAX being VAXEN.
Warner
-----------------
Has anyone used this software
ftp://minnie.tuhs.org/pub/PDP-11/Vtserver/README against a real pdp11? I'm
trying to use it to install a disk image on my 11/34, now, and after keying
in the initial code, it appears to happily upload the first file
(standalone 'copy') quite successfully, but then hangs. Since Warren has
no real pdp11s, I'm wondering if the emulators he used whilst authoring
this VTserver do something different than a real '11 that keeps the program
>from proceeding.
thx
jake
I've been working on a software emulation of the Extended Arithmetic
Element for the PDP-8/E. I've been struggling a little with the multiply
(MUY) instruction in particular.
I don't have an actual EAE to test this all with, but I'd appreciate anyone
with one to test out a bit of code to confirm.
In any event, both SimH and the OS X PDP-8/E Simulator exhibit the same
symptoms, which seem to multiply (PC + 1) by MQ and add AC, placing that
result into AC, MQ. Expected behavior, best I can tell from the Maintenance
Manual Volume 2, would be (PC + 1) * MQ -> AC, MQ, without the addition of
the previous AC prior to executing MUY. If this is the case, then clearing
AC would be essentially required, unless you want to add that value after
the multiply (which could be a useful mathematical operation in some
circumstances).
There is a little code found on bitsavers that seems to emulate these EAE
instructions:
http://bitsavers.trailing-edge.com/bits/DEC/pdp8/From_Vince_Slyngstad/digit…
You'll
note that there is no DCA at the top of the MUY subroutine to save AC in
order to add it to MQ (and complete the carry) afterward.
I've been writing a comparison tool after finding that one program changed
to support the software EAE failed to function correctly, hence attempting
to track down some differences.
If you're interested in trying on real hardware (which would be
appreciated), here's what I'm running:
MUY=7405
DVI=7407
NMI=7411
SHL=7413
ASR=7415
LSR=7417
MQL=7421
SCL=7403
SCA=7441
MQA=7501
CAM=CLA MQL
*200
CLA CLL
TAD MQVAL
MQL
TAD ACVAL
HLT
MUY
7777
HLT
MQVAL, 7777
ACVAL, 7777
$
After the first halt, AC=MQ=7777, as expected. After continuing, AC=7777,
MQ=0000. This would be equivalent to 7777*7777+7777=77770000, rather than
the expected value of 7777*7777=77760001.
Any help would greatly ease my concerns!
Kyle
> From: jws
> I sent a bit of this thread along to Ken Omohundro who founded Able ..
> If he sends anything else along, I'll get it to somewhere people can
> find out about it.
Neat! Thanks!
> I probably have data sheets archived and I will scan them as a PDF file
Those would be great - I hope they include enough detail to explain how the
ENABLE hooked up the various busses, cache, etc! I live in hope that someone
finds a manual, because that may be the only way these questions get answered.
Also, I wonder if the product called the "ENABLE/34" (per various brochures,
Muuss' email, etc) and the "ENABLE" we ran in the 11/45 were actually the same
thing, and they had just changed the name, perhaps because people might have
assumed, from the "ENABLE/34" name, that it was only for /34's, when in fact
it could run in any UNIBUS machine? The name change may have opened up a
bigger market for them. Anyway, another mystery about these things!
Noel
Woohoo, I finally, after over a decade of being somewhat out of the pdp11
hobby, have managed to bring back to life one of my pdp11/34s!
It's a plain 11/34 with dl11-w, ky11-lb, ms11-L, rl11 and a M9312
terminator/boot rom board. I have an emulex controller and some fuji 160s
I'll tack on later so I can run 2.9BSD once I get the basic build confirmed
safe.
It's not in great shape at the moment, apparently, as these xxdp 2.5 diags
are crashing left and right. But it at least boots the os and tries.
I initially had, but mysteriously lost the console emulator/ODT
functionality, seems it's starting at 165000 instead of 165200 at poweron.
Maybe a 9312 switch mis-set... So I'm booting from the panel by calling
the address of the ODT or the rl02 boot rom, which does the trick.
Would anyone care to recommend some xxdp diags I should be running or next
steps to isolate what's wrong / right with it?
thx
jake
P.S.
I tried to boot rsx11m v4.1, but got a strange crash with all zeroes in the
stack and registers. What might that indicate?
@DL0
DEVICE DD000: NOT IN CONFIGURATION
DEVICE DD100: NOT IN CONFIGURATION
DEVICE DY002: NOT IN CONFIGURATION
DEVICE DY102: NOT IN CONFIGURATION
MEVICE NI002: NOT IN CONFIGURATION
RSX-11M V4.1 BL35 124.K MAPPED
SYSTEM CRASH AT LOCATION 000000
REGISTERS
R0=000000 R1=000000 R2=000000 R3=000000
R4=000000 R5=000000 SP=000000 PS=000000
SYSTEM STACK DUMP
LOCATION CONTENTS
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
000000 000000
CRASH -- CONT WITH SCRATCH MEDIA ON DY0
I just can't seem to figure out the right XXDP file to run for a straight memory test.
I've got a new (for me) pdp11/23+ with M8044 memory boards, and I'd like to run memory tests, but I'm damned if I can figure out what, exactly, to run.
This is XXDP 2.5
Thanks for any advice.
> From: Don North
> So here is the octal print routine in the M9312 console boot prom for
> the '34:
I'm curious, is that the 'original' source, or is this dis-assembled from the
PROM contents? Is the complete program available somewhere?
> So I would speculate either 'rol' or 'rolb' are always rotating in a 0
> bit instead of the c-bit, or possibly the c-bit is stuck at zero.
Yup, good suggestion. And that would likely explain why things boot; I can't
see too many OS's using 'ROLB'!
Noel