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
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.
Peace... Sridhar
On Mon, Oct 19, 2009 at 06:01:05PM +0200, Johnny Billquist wrote:
Well, it was just a suggestion, and one that I found easily human
readable and editable. :-)
Well, that's actually why LDIF was created the way it was. It's easily human
AND machine readable and editable.
Unlike XML, which they CLAIM is easily human readable but every time I look
at it I see red and want to stab people.
I've recently started using Apache's ANT build system. Yes, my brain hurts.
But I don't have a problem with something looking like LDIF, as long as
noone ever expects me to actually feed something into LDAP, or even use
LDAP. :-)
What do you have against LDAP? :)
-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 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.
-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)
John Wilson wrote:
From: Johnny Billquist <bqt at softjar.se>
Modifying RSX to use the TSTSET instead of ASRB for spin locks would be easy. It's just a macro in the sources. Not sure what WRTLCK would be used for, though. But it's been a while since I looked at these instructions, so I don't remember the details of them.
Yeah I know what you mean, how is a write not already interlocked? So I
figure what they're getting at is, TSTSET and WRTLCK are interlocked with
regard to *each other*. Well that would work anyway ...
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. But maybe there is something here that I don't remember right. I guess I really should go read the doc on the WRTLCK instruction. :-)
now I'm trying
to picture which is easier to design, a multi-port Q-bus memory, or some
kind of shim which isolates a CPU card and negotiates bus masterhood on
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!
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. If you have several CPUs on the Qbus, all can access the memory.
The problem is that all CPUs think they are bus masters, and all try to control the grant lines, which they cannot.
Wasn't it the 11/03 CPU where you could disable this by a jumper?
Also, the KXJ11 card will play without acting as bus arbiter, so multiple of those cards would work in the same Qbus.
I wonder if anyone ever tried a KXJ11 in combination with a KDJ11? DEC only released software to have the KXJ11 as a slave to a uVAX, but I can't see a problem with having it on a Qbus with a KDJ11 master. You'd need to write some software to be able to interrupt the other CPU, but otherwise I think you'd be halfway happy.
As for peripherials, they'd be accessible by all CPUs. In the normal setup, only one CPU at a time would be logically connected to the device, though. But you'd be free to pick which one, since the Qbus is shared.
The only "private" devices would be the ones located on the CPU card, which means the console interface.
This should be doable with one 11/83 CPU, and then KXJ11s. Write an alternative to the IIST driver, and modify RSX to use the J11 instructions for spinlocks, and you should be ready to go in fact. Unless the KXJ11 have some other funny stuff, such as local memory on the card...
Johnny
On Mon, 19 Oct 2009, Sampsa Laine wrote:
Got an idea for that too :)
Make the file human readable, but have a standardised "tag line" with all the relevant data on it in a simple-to-parse format (in this case pipe | separated), e.g.
!HNINFO:1.401|CHIMPY|AlphaServer 800|OpenVMS 8.3|Comments go here|
Or something.
Here is the format I use.
=INFO MONK XP1000/667, OpenVMS 8.3
=SERVICES MONK DEC Notes Conference MONK::HOBBYIST_DECNET
=SERVICES MONK DEC Notes Conference MONK::PDP-10
=SERVICES MONK DEC Notes Conference MONK::PDP11
=SERVICES MONK DEC Notes Conference MONK::TEST
=SERVICES MONK DEC Notes Conference MONK::VMS
=INFO PDXVAX VAXstation 4000/60, VAX/VMS 5.5-2, Area Router
=SERVICES PDXVAX Guest Login
=SERVICES PDXVAX DEC Notes Client installed
=SERVICES PDXVAX Multinet Bridge to area 2
I don't actually have any need to record the node number.
Zane
From: Johnny Billquist <bqt at softjar.se>
Modifying RSX to use the TSTSET instead of ASRB for spin locks would be
easy. It's just a macro in the sources. Not sure what WRTLCK would be
used for, though. But it's been a while since I looked at these
instructions, so I don't remember the details of them.
Yeah I know what you mean, how is a write not already interlocked? So I
figure what they're getting at is, TSTSET and WRTLCK are interlocked with
regard to *each other*. Well that would work anyway ... now I'm trying
to picture which is easier to design, a multi-port Q-bus memory, or some
kind of shim which isolates a CPU card and negotiates bus masterhood on
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!
John Wilson
D Bit
John Wilson wrote:
From: Johnny Billquist <bqt at softjar.se>
John, did you notice that the IIST documentation now is available at bitsavers?
I noticed that some kind of doc on the IIST showed up there shortly after I'd
spent many months tearing my remaining hair out reverse-engineering it --
skimming through it though, I couldn't find anything significant that I'd
missed (there are lots of things that RSX doesn't touch). Obviously I need
to go over it with a fine-toothed comb though ...
There might be something missing from E11 for the IIST. I have gotten a few sanity timer timeouts since I upgraded to E11 5.2. But apart from that, I don't get the feeling that we're having problems with the IIST.
I have CPUs that gets into a catatonic state, that can't be woken up again. That would be interesting to investigate. It might be related to IIST, but it might be something else just as well.
And then we have the funny actions when getting the fourth CPU online, where the console don't get online most of the time. But that feels more like timing issues.
Johnny
John Wilson wrote:
From: Brian Hechinger <wonko at 4amlunch.net>
I wonder how hard/impossible it would be to implement this entirely in an
FPGA of some sort. That would be a LOT of work, but extremely cool.
This could be a really neat project -- much easier with J11s than PDP-11/70s
though. The J11 has the TSTSET and WRTLCK interlocked instructions which
are obviously intended to take the place of the ASRB kludge on the PDP-11/74
(which is used by RSX11M+ to implement spinlocks). So you'd need some kind
of shared memory (doesn't have to emulate the MKA11 at all, shouldn't be
complicated enough to need an FPGA), and some kind of IIST emulation (which
could be mostly done with microcontrollers), and that's it. Somewhere on
the web there's a quote from one of the RSX guys which basically says that
all of this has already been done, but never released, and it was no sweat
at all.
The TSTSET and WRTLCK instructions are obviously for possible mP implementations using the J11. Also, the J11 already have the cache bypass bit implemented in the PDR.
So, in short, the J11 was already designed to be used in mP systems. All you need is just shared memory. Since early J11 machines used normal Qbus memory, the only thing you actually needed was CPU cards that didn't assume to do bus arbitration. Qbus memory is already shared.
Modifying RSX to use the TSTSET instead of ASRB for spin locks would be easy. It's just a macro in the sources. Not sure what WRTLCK would be used for, though. But it's been a while since I looked at these instructions, so I don't remember the details of them.
The quote was something like (from a DECUS session, about possible performance of multiprocessor PDP-11s):
Q: If you were to build a multiprocessor system based on J11 CPUs, how long would it take to perform a SYSGEN on such a machine?
A: It took about two hours.
I might remember the time wrong, and there might possibly also be other quotes out there, but this out implicitly admitted that they had already done it, and had a machine operational.
Johnny
From: Johnny Billquist <bqt at softjar.se>
John, did you notice that the IIST documentation now is available at
bitsavers?
I noticed that some kind of doc on the IIST showed up there shortly after I'd
spent many months tearing my remaining hair out reverse-engineering it --
skimming through it though, I couldn't find anything significant that I'd
missed (there are lots of things that RSX doesn't touch). Obviously I need
to go over it with a fine-toothed comb though ...
John Wilson
D Bit
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. :)
Well, it was just a suggestion, and one that I found easily human readable and editable. :-)
But I don't have a problem with something looking like LDIF, as long as noone ever expects me to actually feed something into LDAP, or even use LDAP. :-)
Johnny
From: Brian Hechinger <wonko at 4amlunch.net>
I wonder how hard/impossible it would be to implement this entirely in an
FPGA of some sort. That would be a LOT of work, but extremely cool.
This could be a really neat project -- much easier with J11s than PDP-11/70s
though. The J11 has the TSTSET and WRTLCK interlocked instructions which
are obviously intended to take the place of the ASRB kludge on the PDP-11/74
(which is used by RSX11M+ to implement spinlocks). So you'd need some kind
of shared memory (doesn't have to emulate the MKA11 at all, shouldn't be
complicated enough to need an FPGA), and some kind of IIST emulation (which
could be mostly done with microcontrollers), and that's it. Somewhere on
the web there's a quote from one of the RSX guys which basically says that
all of this has already been done, but never released, and it was no sweat
at all.
John Wilson
D Bit
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)
John, did you notice that the IIST documentation now is available at bitsavers?
Johnny
John Wilson wrote:
From: "Bob Armstrong" <bob at jfcl.com>
So can E11 actually use multiple processors on the host (aka Intel) side
so that the emulated 11/74 CPUs can really run in parallel?
Exactly. It also commits some atrocities (making CPUs wait for each other
while sending/receiving inter-CPU interrupts) to ensure that it'll still
basically work even on Linux/Windows systems which don't have enough
(available) 80x86 CPUs/cores to cover all the PDP-11/74 CPUs (and more
importantly, doesn't crash just because of occasional latency problems on a
heavily loaded host PC). The DOS and stand-alone versions DO need enough
80x86 CPUs though, since there's no time-slicing there (there are different
atrocities there -- all I/O is done on the boot processor since DOS and the
BIOS aren't mP-safe).
The bugginess is annoying (occasional hangs) but part of the problem is
that there are no real manuals for the IIST (the inter-processor interrupt
device) and obviously I don't have access to a real mP system to test on.
So I just did the best I could. RSX comes with sources of course, and the
IIST diag listings are in the PDP-11 fiche kit, but as always the diags
themselves mostly focus on little details (evidently the IIST used some kind
of serial bus so there's parity and other weirdness) which are hard/pointless
to emulate, and doesn't point towards whatever I'm getting wrong, so it's
not as if it's just a simple matter of ironing things out until the diag
makes it all the way through.
Anyway I would love it if more people tried out the mP feature. There's a
chapter in the Ersatz-11 manual which tells how to turn it on, and how
to configure RSX to use it. The more users, the more bug reports, and the
sooner the mP parts of E11 get all the kinks worked out. It's a lot of fun to
play with! DEC sort of pretended mP PDP-11s never happened (there was never
any official support) but only after they'd already done *all* of the work.
The mP stuff is in the real printed RSX manuals, and the diags are on the
regular XXDP packs, it's great! And lots of fun to play with...
John Wilson
D Bit
Brian Hechinger wrote:
On Mon, Oct 19, 2009 at 05:37:39PM +0200, Johnny Billquist wrote:
But all the pieces are documented, and the documents are available on the internet...
I wonder how hard/impossible it would be to implement this entirely in an
FPGA of some sort. That would be a LOT of work, but extremely cool.
Start with the basic PDP-11/70 in that case. Once you have that down, extending it to an 11/74 should be less of a problem.
I know of several attempts in the past to do PDP-11s in FPGA. I don't know if any of them have reached a working stage, but they have also been aiming a bit lower. Going for 11/40 type machines.
But it should all be doable, I think. Just given enough time and energy. :-)
Johnny
From: "Bob Armstrong" <bob at jfcl.com>
So can E11 actually use multiple processors on the host (aka Intel) side
so that the emulated 11/74 CPUs can really run in parallel?
Exactly. It also commits some atrocities (making CPUs wait for each other
while sending/receiving inter-CPU interrupts) to ensure that it'll still
basically work even on Linux/Windows systems which don't have enough
(available) 80x86 CPUs/cores to cover all the PDP-11/74 CPUs (and more
importantly, doesn't crash just because of occasional latency problems on a
heavily loaded host PC). The DOS and stand-alone versions DO need enough
80x86 CPUs though, since there's no time-slicing there (there are different
atrocities there -- all I/O is done on the boot processor since DOS and the
BIOS aren't mP-safe).
The bugginess is annoying (occasional hangs) but part of the problem is
that there are no real manuals for the IIST (the inter-processor interrupt
device) and obviously I don't have access to a real mP system to test on.
So I just did the best I could. RSX comes with sources of course, and the
IIST diag listings are in the PDP-11 fiche kit, but as always the diags
themselves mostly focus on little details (evidently the IIST used some kind
of serial bus so there's parity and other weirdness) which are hard/pointless
to emulate, and doesn't point towards whatever I'm getting wrong, so it's
not as if it's just a simple matter of ironing things out until the diag
makes it all the way through.
Anyway I would love it if more people tried out the mP feature. There's a
chapter in the Ersatz-11 manual which tells how to turn it on, and how
to configure RSX to use it. The more users, the more bug reports, and the
sooner the mP parts of E11 get all the kinks worked out. It's a lot of fun to
play with! DEC sort of pretended mP PDP-11s never happened (there was never
any official support) but only after they'd already done *all* of the work.
The mP stuff is in the real printed RSX manuals, and the diags are on the
regular XXDP packs, it's great! And lots of fun to play with...
John Wilson
D Bit
