On Mon, 19 Oct 2009, Bob Armstrong wrote:
so we can look at satellite map and see real location of node :)
I'm not sure I want to tell :-)
I have to question how many people want to let out that level of detail.
Zane
On Mon, Oct 19, 2009 at 07:17:18PM +0200, Johnny Billquist wrote:
You don't do DMA from CPU to a device. Remember what DMA stands for? :-)
Oh, duh. I knew that. I blame a lack of coffee. ;)
Hmm, I realized one thing, though. With a common Qbus, all interrupts
will probably go to the bus master arbiter, which means that all devices
actually must be attached to CPA, except such devices that are local to
each CPU, such as the console terminal.
That solves that problem. :)
And in RSX speak, the CPUs are called CPA, CPB, CPC and CPD. Here is how
it looks on MIM::
.con dis full att for sys
SYS SYS Online,Accpath
PDP-11/74mP, EIS,UNIBUS_Map,D-Space,SWR,Cache,FPP,
Clock=KW11-L, $TKPS=50., $TTPRM=000002
.con dis full att for cp
CPA CPA Online,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
CPB CPB Offline,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
CPC CPC Online,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
CPD CPD Offline,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
.con dis full att for du
DUA CPA Online,Accpath,Driver
Csr=172150, Vector=000154, Pri=000005, Urm=000001
DU0: CPA DUA0: Online,Accpath,Context,Driver,Type=RZ29
DU1: CPA DUA1: Online,Accpath,Driver,Type=RD53
DU2: CPA DUA2: Online,Accpath,Driver,Type=RD52
DU3: CPA DUA3: Offline,Accpath,Driver
DU4: Online,Accpath,Context,Driver,Type=VRA82
.
Notice that CPA and CPC are online.
And DUA is attached to CPA, and so on...
That's nifty. I can't wait to get mine setup. :)
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Johnny Billquist wrote:
Makes you wish you had a real PDP-11/74 around... :-)
Hmm, we have several 11/70 you know. Could we build one? Or would we have to rebuild the whole cache/memory tingies?
Hehe. Yes, we have three PDP-11/70 machines.
I have two myself.
Cool. Any of them running? Between us here, we are now up to five PDP-11/70 machines. That is pretty impressive.
They're not running, but at least one of them is in running condition. I still need to find time to perform a detailed examination of the other one. It is probably runnable too.
Update have two 11/70 in the high cabinets, and one in corporate cabinet.
I have one in standard racks (H960?), and the other is a DECdatasystem 570.
Peace... Sridhar
Let me rephrase the "human readable file" to "free-flowing prose meant for human readers".
Sampsa
On 19 Oct 2009, at 18:32, Sampsa Laine wrote:
Guys, the reason I suggested a one line format was that I thought it would just sit at the end of a human readable file. We could have a second info file that is machine readable.
On 19 Oct 2009, at 16:58, Brian Hechinger wrote:
On Mon, Oct 19, 2009 at 05:45:27PM +0200, Johnny Billquist wrote:
Such as (just as an example):
======
HOST: MIM
HARDWARE: E11 (PDP-11/74)
OS: RSX-11M-PLUS V4.6
LOCATION: UPPSALA, SWEDEN
MANAGER: Johnny Billquist
EMAIL: bqt at update.uu.se
EMAIL: MIM::BILLQUIST
======
Keep the format simple, and very relaxed. Let software figure out if
they can do anything with it or not.
Uppercase, lowercase, free flowing text. Just keep the tags standard to
start with. Maybe we can have some tags with a more formalized value, if
needed, such as a POS: value with LAT/LONG if people want to add that?
Hmm, that looks a LOT like an LDIF file. :)
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Guys, the reason I suggested a one line format was that I thought it would just sit at the end of a human readable file. We could have a second info file that is machine readable.
On 19 Oct 2009, at 16:58, Brian Hechinger wrote:
On Mon, Oct 19, 2009 at 05:45:27PM +0200, Johnny Billquist wrote:
Such as (just as an example):
======
HOST: MIM
HARDWARE: E11 (PDP-11/74)
OS: RSX-11M-PLUS V4.6
LOCATION: UPPSALA, SWEDEN
MANAGER: Johnny Billquist
EMAIL: bqt at update.uu.se
EMAIL: MIM::BILLQUIST
======
Keep the format simple, and very relaxed. Let software figure out if
they can do anything with it or not.
Uppercase, lowercase, free flowing text. Just keep the tags standard to
start with. Maybe we can have some tags with a more formalized value, if
needed, such as a POS: value with LAT/LONG if people want to add that?
Hmm, that looks a LOT like an LDIF file. :)
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Mon, Oct 19, 2009 at 01:19:30PM -0400, John Wilson wrote:
OK I'll try to control myself now -- PDP-11 stuff probably isn't that
interesting to most HECnet people.
I'm all for it, I think most of us here are PDP-11 junkies. :-D
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
On Mon, Oct 19, 2009 at 07:19:52PM +0200, Johnny Billquist wrote:
Any more 11/70 machines around?
I've got one. Dave McGuire has two.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Sridhar Ayengar wrote:
Johnny Billquist wrote:
Pontus Pihlgren wrote:
Makes you wish you had a real PDP-11/74 around... :-)
Hmm, we have several 11/70 you know. Could we build one? Or would we have to rebuild the whole cache/memory tingies?
Hehe. Yes, we have three PDP-11/70 machines.
I have two myself.
Cool. Any of them running? Between us here, we are now up to five PDP-11/70 machines. That is pretty impressive.
Update have two 11/70 in the high cabinets, and one in corporate cabinet.
Any more 11/70 machines around?
Johnny
From: Johnny Billquist <bqt at softjar.se>
The TSTSET is both a test, and a write. So it will do both. I can't
imagine that WRTLCK was to be used in combination with TSTSET.
I was picturing TSTSET for testing/acquiring a spinlock, and WRTLCK for
releasing it, but obviously other combinations could work too.
You are thinking too complex. A Qbus memory is always multiported. It's
just a slave on the bus. Any master can access it. So it is multiported.
Well OK I guess I meant multiported as it, multiple separate Q-bus interfaces
so it can be present on otherwise disjoint Q-bi.
The problem is that all CPUs think they are bus masters, and all try to
control the grant lines, which they cannot.
A little snippage would fix that part, but the problem is that CPUs won't
normally try to negotiate for bus mastership. So that's what I meant
by that -- CPU starts a bus cycle w/o warning, interface becomes bus
master on the shared Q-bus (where the memory lives) and *then* passes
the bus cycle through, hopefully before the CPU gets tired of waiting.
Wasn't it the 11/03 CPU where you could disable this by a jumper?
Sounds vaguely familiar. 11/20 too? Or was it the 11/05?
Unless the KXJ11 have some other funny stuff, such as local memory on
the card...
Beats me, I've never even seen a KXJ -- sounds like potential fun though.
OK I'll try to control myself now -- PDP-11 stuff probably isn't that
interesting to most HECnet people.
John Wilson
D Bit
Brian Hechinger wrote:
On Mon, Oct 19, 2009 at 12:31:41PM -0400, John Wilson wrote:
its behalf instead of assuming the CPU card is The Decider. I'm trying to
picture where per-CPU peripherals go in that case so the I/O page is still
private but DMA isn't ... ow my head!
If you are talking multiple CPUs on a single QBus is there much benefit to
assigning peripherals to CPUs other than CPU0? That wouldn't disallow you
to do DMA from another CPU to that peripherals I wouldn't think.
You don't do DMA from CPU to a device. Remember what DMA stands for? :-)
The benefit of assigning different devices to different CPUs are that you can balance the CPU load of the different CPUs.
For each I/O operation, the CPU have to run through the driver, which takes a non-zero amount of time. And the same is true when the I/O completes.
Hmm, I realized one thing, though. With a common Qbus, all interrupts will probably go to the bus master arbiter, which means that all devices actually must be attached to CPA, except such devices that are local to each CPU, such as the console terminal.
And in RSX speak, the CPUs are called CPA, CPB, CPC and CPD. Here is how it looks on MIM::
.con dis full att for sys
SYS SYS Online,Accpath
PDP-11/74mP, EIS,UNIBUS_Map,D-Space,SWR,Cache,FPP,
Clock=KW11-L, $TKPS=50., $TTPRM=000002
.con dis full att for cp
CPA CPA Online,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
CPB CPB Offline,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
CPC CPC Online,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
CPD CPD Offline,Accpath
Cache_control=000001, Timer=Off, Alarm=Off
.con dis full att for du
DUA CPA Online,Accpath,Driver
Csr=172150, Vector=000154, Pri=000005, Urm=000001
DU0: CPA DUA0: Online,Accpath,Context,Driver,Type=RZ29
DU1: CPA DUA1: Online,Accpath,Driver,Type=RD53
DU2: CPA DUA2: Online,Accpath,Driver,Type=RD52
DU3: CPA DUA3: Offline,Accpath,Driver
DU4: Online,Accpath,Context,Driver,Type=VRA82
.
Notice that CPA and CPC are online.
And DUA is attached to CPA, and so on...
Johnny
