Robertdkeys(a)aol.com wrote:
> It was Q0A. Has there been any later development
> of it, of interest?
Yes, there has been. The only problem is that I still haven't managed (in 3
years) to find time to spin it into a release. :-( There is some hope, though,
that I'll find a bit of time (enough to spin out the 4.3-QJ0b release) this
winter.
MS
Sorry. Wrong list. That was meant for PUPS.
Andru
--
Andru Luvisi, Programmer/Analyst
Quote Of The Moment:
Just once, I wish we would encounter an alien menace that wasn't
immune to bullets.
-- The Brigadier, "Dr. Who"
Robertdkeys(a)aol.com wrote:
> [...] I just used the quasijarus
> 0a source tarball (that is supposed to be Tahoe) [...]
It is.
> Out of curiosity, anyone still running a 4.3BSD
> box? I had a couple microVAXes up with it until
> my ESDI drives went bellyup a few days back.
Do you mean the plain original 4.3 or enhanced versions like 4.3-Quasijarus?
The plain original 4.3 doesn't run on MicroVAXen, so if you had 4.3 on yours,
it must have been *some* enhanced version.
MS
>From Warren:
>
> These file are now in the Unix Archive on minnie.tuhs.org in
> PDP-11/Boot_Images/2.11_on_Simh
>
> The mirror sites should pick them up soon.
>
The src tarball in the archives is only 35k or
something like that, so it is mostly gone. At
one time, I thought it was more there.
Since I was only needing the dwb section out
of the sources, to power up a dwb suite on an
ancient ultrix box, I just used the quasijarus
0a source tarball (that is supposed to be Tahoe)
for the bits I needed. It worked.
But, for the record, it might be nice to have a
complete, unbroken set, if it still exists, and
the bits can be rounded up.
Out of curiosity, anyone still running a 4.3BSD
box? I had a couple microVAXes up with it until
my ESDI drives went bellyup a few days back.
(Ice storms and power glitches ate the drives.)
I have maybe 30mb of ports of this and that
(gzip, gmake, psroff, TeX, and other things)
that I would donate to the archives if there
was any interest. MicroVAXen are a cheap way
of playing old BSD....(:+}}...
Thanks
Bob
Warren,
Oh, I see Andru already uploaded it to Minnie as well.. OK..
Thanks, Andru!
--fred
> -----Original Message-----
> From: Warren Toomey [mailto:wkt@minnie.tuhs.org]
> Sent: Saturday, December 07, 2002 6:08 AM
> To: Andru Luvisi
> Cc: pups(a)minnie.tuhs.org
> Subject: Re: [pups] Boot_Images and the networking activated
> version of
> Simh
>
>
> In article by Andru Luvisi:
> > All righty. I have:
> > A working boot image for a networked 2.11BSD system inside simh.
> > Some perl scripts for working with simh tape images.
> > simh startup script for booting the networked image.
> > simh startup script for booting from the install tape.
> > Some basic instructions for how to get the thing going
> (not a substitute
> > for reading the simh docs and knowing something about UNIX).
> >
> > I emailed Warren but he seems to be unavailable right now.
> >
> > So, who's got an archive I can upload it to?
>
> Try anonymous ftp to minnie.tuhs.org, directory incoming/unix.
>
> Sorry, I've been busy!
> Warren
> _______________________________________________
> PUPS mailing list
> PUPS(a)minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/pups
>
Hi,
While studying the V6 kernel, I search for some rules as when to raise
the interrupt priority level (IPL). I came up with something like this:
A kernel process needs to raise the IPL if a change of data must be atomic and might
be accessed (not necessarily changed) by an IRS.
In light of this rule, some raising of interrupts seem unnecessary:
- In m40.s changes of the user space segmentation registers are bracketed by raising
and lowering the IPL, although these registers are never accessed by an ISR.
- Likewise, in m40.s, just before the trap routine checks the runrun flag and
restores r0, r1 and the user stackpointer, it raises the IPL. I can't see what
possibly should go wrong, if being interrupted while restoring the values.
I'd appreciate any help from someone with more experience in kernel programming.
Greetings,
Wolfgang Helbig
People,
DO note that the Ethernet operations of SimH heavily depend on the proper
workings AND configuration of a Packet Filter driver for your platform,
so, something like BPF, EFILT, NetFLT or WinPCAP (for Win32). Try running
a test app for that stuff BEFORE trying to run SimH/ENET stuff.. if the
test app works OK, you can start figuring out why SimH/ENET doesn't work
on your system.
I have *three* network cards the drivers of which DO NOT support promisc
mode. Which obviously results in WinPCAP (they're PCI cards under Win2K)
not functioning properly, and, thus, same for SimH/ENET.
--fred
> -----Original Message-----
> From: Andru Luvisi [mailto:luvisi@andru.sonoma.edu]
> Sent: Friday, November 29, 2002 8:02 AM
> To: gregg(a)levine.name
> Cc: pups(a)minnie.tuhs.org
> Subject: Re: [pups] Boot_Images and the networking activated
> version of
> Simh
>
>
> On Thu, 28 Nov 2002, Gregg C Levine wrote:
> > Hello from Gregg C Levine
> > Just out of curiosity, can the boot images stored in the
> folders that
> > are under that name, actually support this new version of
> Simh? That is
> > the PDP-11 emulator. What would be necessary to enable that
> function? It
> > looks as if one of them, is aware of the device, since I believe the
> > image was made on a machine which has the appropriate card
> installed in
> > it, but after that I'm lost.
>
> I would be happy to share mine, but it doesn't work. ;-)
>
> The thing that strikes me as really weird is that I know a guy who is
> running VMS with networking on the simh VAX emulator. As I
> understand it,
> the the VAX and PDP-11 emulators use the same code for the ethernet
> controller.
>
> Andru
> --
> Andru Luvisi, Programmer/Analyst
>
> Quote Of The Moment:
> Truth is hard to find and harder to obscure.
>
> _______________________________________________
> PUPS mailing list
> PUPS(a)minnie.tuhs.org
> http://minnie.tuhs.org/mailman/listinfo/pups
>
Hi -
> From: Andru Luvisi <luvisi(a)andru.sonoma.edu>
> I have gotten 2.11 installed on simh, I have it recognizing the simulated
> ethernet card, and everything appears correct except the packets just
> aren't getting in and out. The simh documentation says that the DELQA
> card is better than the DEQNA, but I was unable to get the DELQA (qt)
> driver to recognize the card. When I compiled the kernel to use the DEQNA
There are TWO variants of the DELQA as I recall. One was referred
to as the "turbo" verion (I think it was called the DELQA-YM) and
the if_qt driver was developed and tested specifically for, and only
for, that variant. The normal DELQA and DEQNA should use the if_qe
driver.
> I have configured 2.11BSD with:
> A valid IP address on the network the host is on.
> The same netmask, broadcast, and gateway as the host.
> I am running the emulator as root.
>
> The docs say you won't be able to talk between the host and the emulated
Hmmm, that seems strange. Using P11 I talk between the host (the
machine running the emulator program) and the "PDP11" all the time.
Ah, it has to do with ARP handling I suspect. I know that with P11
it's IP only and thus ARP packets do not traverse the emulated ethernet
card. If that is the case with simh as well then on the PDP11 side
you might have to do what I did and install arp entries for everything
on the local lan with which the PDP11 is going to communicate. That
way the 11 already knows the 'mac' address and does not need ARP (which
doesn't work thru the emulated ethernet) at all.
> machine, so my test for each configuration has been pinging the gateway,
> which I know responds to pings since I can ping it from the host.
Ah, but on the host did you publish an ARP entry so that the host
will arp for the PDP11? I think that is required.
I would tinker around with installing published/proxy arp entries and
seeing what happens.
Cheers,
Steven Schultz
sms(a)2bsd.com