> From: asbesto <asbesto(a)freaknet.org>
> To: tuhs(a)tuhs.org
> Subject: [TUHS] PDP11/34 boot problems, here i am again :)
>
> well, i think now we have a more complete knowledge of the REAL
> problem !
>
> the M7891 board (128K x 18 bit MOS MEMORY MODULE) have the D2 red=20
> led light turned ON when turning on the CPU !
>
> this means PARITY ERROR on this board :(
>
> checking the board we found 2 problems:
>
> 1) a 74LS175 chip named E15 on our schematic diagram, that seem
> phisically BROKEN on an edge (there is a fessure on the plastic
> DIP package). i can't change it now because i don't have a=20
> soldering station here to do a nice job, but looking the chip i
> think it may work...
While you probably _do_ have a real hardware problem with the broken
IC, I think that the red Parity Error light on first turn-on is normal
behavior. The MOS memory comes up with random values, and about half
of them will have the wrong parity. Some software routine must turn
off parity error detection and write a known data pattern (all 0's) to
each memory location. I don't remember whether this is something that
is done by the boot ROM of an 11/34.
carl
--
carl lowenstein marine physical lab u.c. san diego
clowenst(a)ucsd.edu
"asbesto" wrote:
> 1) a 74LS175 chip named E15 on our schematic diagram, that seem
> phisically BROKEN on an edge (there is a fessure on the plastic
> DIP package). i can't change it now because i don't have a
> soldering station here to do a nice job, but looking the chip i
> think it may work...
I never remove IC's in *one* go. The chances that you damage the
multi-layer board beyond repair are real. This is what I do.
I use a dremel tool (small motor with sharp rotating blade) to
cut the pins of the IC one by one.
Don't use a cutting tool to cut the pins because the side force
might push the remainder of the pin through the solder joint
thus damaging the board.
After you have cut all the pins the IC just falls of the board.
Now, you can use a fine hot soldering iron and remove the pins
one by one use a pair of squeezers.
good luck with your repairs,
- Henk.
well,
some months ago i asked for help booting a pdp11/34 here at
freaknet medialab :)
well, i think now we have a more complete knowledge of the REAL
problem !
the M7891 board (128K x 18 bit MOS MEMORY MODULE) have the D2 red
led light turned ON when turning on the CPU !
this means PARITY ERROR on this board :(
checking the board we found 2 problems:
1) a 74LS175 chip named E15 on our schematic diagram, that seem
phisically BROKEN on an edge (there is a fessure on the plastic
DIP package). i can't change it now because i don't have a
soldering station here to do a nice job, but looking the chip i
think it may work...
2) a 5 Kohm 4-resistor bridge named R22 on our diagram, that is phisically
BROKEN. this bridge give +5V on signals named DATA OC L, CSR OC L, OC L
and X ADD OC L. i changed it with a 4.7Kohm 4-resistor bridge, without
any result. (maybe the 74ls175 is really broken :)
an other ipothesys may be: some electrolitic capacitor in short circuit.
we had this problem on a decwriter III ! :)
the real problem is: if we aren't able to repair the M7891 board, where
can we find a "new" one ???
can somebody help us ? it's a shame for us to have our pdp11/34 offline :((
any help is appreciated ! *:)
--
[asbesto : freaknet medialab : radio#cybernet : GPG key on keyservers]
[ MAIL ATTACH, SPAM, HTML, WORD, and msgs larger than 95K > /dev/null ]
[http://www.freaknet.org/asbesto :::::: http://kyuzz.org/radiocybernet]
Hi All,
I know that this isn't pdp related but the people are here who know :-). Is there
an available unix that supports lance and dssi on a VAX 3400 and/or is there anyone
working on this.
Regards
Robin
This email and any attachments are confidential and intended for the addressee
only. If you are not the named recipient, you must not use, disclose, reproduce,
copy or distribute the contents of this communication. If you have received this
in error, please contact the sender and then delete this email from your system.
while trying to build Franz Lisp (from 4.3 BSD) on VAX/ULTRIX 4.5,
I noticed its peculiar list of supported platforms:
use: lispconf type
where type is one of
vax_4_1 vax_4_1a vax_4_1c vax_4_2 vax_4_3
vax_eunice_vms
sun_4_1c sun_unisoft dual_unisoft pixel_unisoft
sun_4_2beta lisa_unisys3 mc500_2_0
I was especially surprised by "lisa_unisys3". is that Unisoft SysIII
for the Apple Lisa?! and does anyone know what
{dual,pixel}_unisoft and mc500_2_0 mean?
--
If I travelled to the end of the rainbow
As Dame Fortune did intend,
Murphy would be there to tell me
The pot's at the other end.
Lars Buitinck
I'll have to try this with the RQDX3 as primary and the SCSI as secondary.
Maybe BSD is smart enough to do it right. In any case, I have the source for
the BSD boot code, and I can fix it. It will be a pain, though, having to
type the alternate address every time I boot BSD. I'd probably have to
restructure /dev and /etc/fstab also, and who knows what else. Maybe it
would be easier to change the jumpers if I needed to run RT11. I don't use
RT11 that much, but I'd like to have it available.
--
Jonathan Engdahl
http://users.safeaccess.com/engdahl
"The things which are seen are temporary,
but the things which are not seen are eternal." II Cor. 4:18
----- Original Message -----
From: "Fred N. van Kempen" <Fred.van.Kempen(a)microwalt.nl>
To: "Jonathan Engdahl" <j.r.engdahl(a)adelphia.net>
Sent: Wednesday, April 02, 2003 5:58 AM
Subject: RE: [pups] booting RT11 from alternate controller
Jonathan,
> I have a PDP-11/53 with a SCSI controller at 172150, and an
> RQDX3 at 172144.
This works for the ROM, but most PDP-11 operating systems will
refuse to boot from anything but the "default" controller of
any kind, meaning, an MSCP controller it will only accept at
172150. The OS itself can deal with them, but not so for the
boot-level code that loads them.
I have tried similar setups with an 11/83 using an ESDI disk
controller at MSCP #0 (doing KDA50 emu), and an RQDX3 at
MSCP #1 (just for the floppies, indeed) and that didnt work
either, with RT11, MicroRSX and Ultrix.
--f
I have a PDP-11/53 with a SCSI controller at 172150, and an RQDX3 at 172144.
There are a couple SCSI drives on the primary controller, and an RX50 on the
RQDX3. Everything seems to work OK, and I can read the floppies, except I
cannot boot RT11 from a floppy. From the 11/53 boot ROM you can say
B/A DU0
It will then ask for the address of the alternate controller. It reads from
the floppy, then it reads from both hard drives, then hangs.
What I hunch is happening is that the boot ROM reads the RT11 boot sector
from the floppy, but then the boot sector tries to continue booting from the
hard drives, which isn't going to work, because they are 2.11BSD formatted.
The objective is to have some non-RQDX3 hard drive controller as the
primary, and a secondary RQDX3 for the floppy, and to be able to boot UNIX
from the hard drive, and RT11 from the floopy. Any ideas on how to
accomplish this?
--
Jonathan Engdahl
http://users.safeaccess.com/engdahl
"The things which are seen are temporary,
but the things which are not seen are eternal." II Cor. 4:18
Helbig remarked (quoting Davidson):
> >Yes, you are right - V7 restores the register variables to a state which
> >is consistent with the other auto variables in the function - ie the value
> >which they had when longjmp was called.
> >
> >The caveats about not relying on register variables applied to V6.
> Nope, even in V6, register variables are restored to the values they had
> when reset(III) was called! (reset() is the name of longjmp() in V6).
> By the way, reset() is much smaller than longjmp() but provides the same
> functionality.
> I wonder why longjmp() was rewritten.
Setjmp/longjmp do more (setjmp returns different values
for the initial call and the longjmp-invoked one).
But the thing that would become more important
is that the PDP-11 compiler's calling sequence was
especially friendly toward restoring register values--
it just worked automatically.
Other machines and compilers were not so friendly.
This is why ANSI and ISO had to put in special rules
about promising to preserve only things marked
volatile.
We've been through this before.
Dennis
>X-Unix-From: michael_davidson(a)pacbell.net Tue Dec 31 17:04:50 2002
>Date: Tue, 31 Dec 2002 08:02:37 -0800
>From: Michael Davidson <michael_davidson(a)pacbell.net>
>User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4)
Gecko/20011128 Netscape6/6.2.1
>X-Accept-Language: en-us
>MIME-Version: 1.0
>To: Wolfgang Helbig <helbig(a)Informatik.BA-Stuttgart.DE>
>CC: pups(a)minnie.tuhs.org
>Subject: Re: [pups] V7 setjmp/longjmp
>Content-Transfer-Encoding: 7bit
>
>Wolfgang Helbig wrote:
>>You can trust register variables when setjmp() returns the second time. Then
>>the registers are restored to the values they had when the "next" function was
>>called, that is the "values as of the time longjmp() was called" (quoted from
>>longjmp(3)'s man page. Thus any variable behaves the same, regardless of its
>>storage class.
>>
>Yes, you are right - V7 restores the register variables to a state which
>is consistent with the other auto variables in the function - ie the value
>which they had when longjmp was called.
>
>The caveats about not relying on register variables applied to V6.
Nope, even in V6, register variables are restored to the values they had
when reset(III) was called! (reset() is the name of longjmp() in V6).
By the way, reset() is much smaller than longjmp() but provides the same
functionality.
I wonder why longjmp() was rewritten.
Wolfgang.
On Mar 21, 19:31, Ian King wrote:
> Yup. I used to do that, but had an older version of sendmail and got
> 'co-opted' as a relay host for a spammer. :-(
I've seen a few attempts to do that. I should point out that even if
you only run sendmail for the benefit of machines on your own network,
and even if you use a dialup (rather than always-on) connection, you
want the ant-relay stuff. I see regular attempts to connect to port 25
on my hub, even though it's behind a dynamic IP address on an ISDN
dialup (I also see regular attempts to connect to the telnet, ssh, and
ftp ports, and others, maybe 2-3 times a week. If you run a common
operating system, don't assume that a dynamic IP address, or NAT, or
using a dialup, gives any worthwhile protection).
> FWIW: rather than update sendmail and hack another .cf, I bought a
> Windows-based mail server
Nowadays, it's easy to use m4 to set up sendmail.cf for the common
sorts of home use -- just define the settings for masquerading and
smarthost, and press go (more or less). The only time you need to hack
it a bit is if you want something unusual, like some mail going to the
local machine and some forwarded to other machines on your network, or
using UUCP.
> Instead, I use my free time to hack 2.11BSD and UNIX v6! :-)
I have to admit that sounds like a better use of the time :-)
--
Pete Peter Turnbull
Network Manager
University of York
