18 Mar
2015
18 Mar
'15
8:16 a.m.
From: Paul Koning
if the CPU generates an address in the range 17000000
to 17577777, it
lands on the Unibus and is then mapped by the Unibus map.
Umm, I think you meant "to 17 757 777", no? (Too many 7's - I find it
helpful
to break them up into groups of 3, the way DEC does, to prevent that kind of
confustion.)
More precisely, it works that way for 11/44 and 11/70
- but not for the
J-11. That's a difference not documented in the PDP-11 Architecture
handbook model differences table
But, but, but... the J-11 doesn't _have_ a UNIBUS map! Well, the 11/84 and
11/94 do, but not other J-11 machines. (And the Architecture Handbook table
does not have separate columns for the 11/73, 11/84, etc.) So an 11/73 can't
have a reference in the range 17 000 000 to 17 757 777 go out the UNIBUS -
there isn't one! :-)
So what happens if one does a reference to something in the range 17 000 000
to 17 757 777 on the 11/84? The 11/84 _does_ support having memory on the
UNIBUS (up to 248KB), _but_ how it appears depends on how much there is. (See
section 3.13.2, EK-1184-TM-PR2.) There's a special register to configure it
(the 'KTJ11-B Memory Configuration Register', KMCR), which includes _how
much_ UNIBUS memory there is.
If there is _no_ UNIBUS memory, then PMI memory appears (to the CPU) at 0 up,
and the UNIBUS Map is enabled. References to 17 000 000 to 17 757 777 go to
PMI memory ("PMI memory, as seen by the CPU, resides in contiguous locations
from 0 up to as high as 17 757 777"), and
presumably if there is no PMI
memory there, they fail, they don't even go out
the UNIBUS to see if anyone's
home.
If there is _no_ PMI memory, then _UNIBUS_ memory appears (to the CPU) at 0
up, and the UNIBUS Map is _disabled_. (And I assume references to the range
01 000 000 to 17 757 777 just immediately fail.)
If, on the other hand, there is a _mix_ of PMI and UNIBUS memory, things get
really wierd. UNIBUS memory does not appear at 0, _or_ at 17 000 000 up to 17
577 777; instead, that memory appears to the CPU (depending on how much there
is) from 17 757 777 _downwards_ to (17 600 000-UNIBUS_memory_size); UNIBUS
memory apparently has to be assigned UNIBUS addresses from 757 777 _down_
("[UNIBUS] DMA Address XXX XXX accesses the same UNIBUS Memory location
accessed by CPU addresses 17 XXX XXX").
(Which is slightly odd because in the case where there is no PMI memory, the
UNIBUS memory needs to be assigned UNIBUS addresses from 0 up, which is quite
different from how to assign UNIBUS addresses to that memory in the 'mixed'
case. But never mind... :-)
The UNIBUS map will not respond to UNIBUS cycles in the address range
assigned to the UNIBUS memory.
And, to look at the original point, I would _guess_ that references to
locations in the range 17 000 000 to 17 757 777, but below the configured
UNIBUS memory, again don't go out the UNIBUS, but try and perform a PMI
cycle, which may or may not fail.
Basically, it seems like DEC was determined not to waste any address space on
the J-11/UNIBUS machines. Either it's configured as UNIBUS memory, or it's
PMI.
The KTJ11-B can also be configured to operate in 18-bit mode, with a mix of
PMI and UNIBUS memory, but I will leave the ugly details unless someone is
particularly interested in them! :-)
Noel
18 Mar
18 Mar
8:28 a.m.
On Mar 18, 2015, at 11:16 AM, Noel Chiappa <jnc at
mercury.lcs.mit.edu> wrote:
Oops. Yes.
From: Paul Koning
if the CPU generates an address in the range
17000000 to 17577777, it
lands on the Unibus and is then mapped by the Unibus map.
Umm, I think you meant "to 17 757 777", no? (Too many 7's - I find it
helpful
to break them up into groups of 3, the way DEC does, to prevent that kind of
confustion.) More precisely, it works that way for 11/44 and
11/70 - but not for the
J-11. That's a difference not documented in the PDP-11 Architecture
handbook model differences table
But, but, but... the J-11 doesn't _have_ a UNIBUS map! Well, the 11/84 and
11/94 do, but not other J-11 machines. (And the Architecture Handbook table
does not have separate columns for the 11/73, 11/84, etc.) So an 11/73 can't
have a reference in the range 17 000 000 to 17 757 777 go out the UNIBUS -
there isn't one! :-)
So what happens if one does a reference to something in the range 17 000 000
to 17 757 777 on the 11/84? The 11/84 _does_ support having memory on the
UNIBUS (up to 248KB), _but_ how it appears depends on how much there is. (See
section 3.13.2, EK-1184-TM-PR2.) There's a special register to configure it
(the 'KTJ11-B Memory Configuration Register', KMCR), which includes _how
much_ UNIBUS memory there is.
...
Basically, it seems like DEC was determined not to waste any address space on
the J-11/UNIBUS machines. Either it's configured as UNIBUS memory, or it's
PMI.
Interesting. I was referring to what I learned by reading the RSTS/E memory size
determination code. That code says that the main memory limit is 2M - 128kW for 11/44 and
11/70, and 2M - 4kW for J-11 Unibus. So it looks like RSTS/E doesn?t support the mixed
case you mentioned, only the ?just PMI? flavor.
paul
11:07 a.m.
On 2015-03-18 16:28, Paul Koning wrote:
I'm not sure RSTS/E needs to explicitly know if there are Unibus memory,
except if you end of with non-contiguous memory because of this.
Johnny
So what happens if one does a reference to
something in the range 17 000 000
to 17 757 777 on the 11/84? The 11/84 _does_ support having memory on the
UNIBUS (up to 248KB), _but_ how it appears depends on how much there is. (See
section 3.13.2, EK-1184-TM-PR2.) There's a special register to configure it
(the 'KTJ11-B Memory Configuration Register', KMCR), which includes _how
much_ UNIBUS memory there is.
...
Basically, it seems like DEC was determined not to waste any address space on
the J-11/UNIBUS machines. Either it's configured as UNIBUS memory, or it's
PMI.
Interesting. I was referring to what I learned by reading the RSTS/E memory size
determination code. That code says that the main memory limit is 2M - 128kW for 11/44 and
11/70, and 2M - 4kW for J-11 Unibus. So it looks like RSTS/E doesn?t support the mixed
case you mentioned, only the ?just PMI? flavor.
11:15 a.m.
On Mar 18, 2015, at 2:07 PM, Johnny Billquist <bqt
at Update.UU.SE> wrote:
On 2015-03-18 16:28, Paul Koning wrote:
I'm not sure RSTS/E needs to explicitly know if there are Unibus memory, except if
you end of with non-contiguous memory because of this.
RSTS doesn?t need to know, and it actually supports non-contiguous memory (it looks for
memory at every 1k address, until it hits the top of the address space it is told to use
for the given processor model). But apparently the decision was not to support Unibus
memory in 22 bit systems, since the scan stops at the top of the main memory address
space. Given that it goes all the way to the 4k I/O page on J-11 systems, that would
allow it to recognize Unibus memory if any were there, but whether the RSTS team would
consider such a config unsupported is a question I no longer know how to answer.
paul
So what happens if one does a reference to
something in the range 17 000 000
to 17 757 777 on the 11/84? The 11/84 _does_ support having memory on the
UNIBUS (up to 248KB), _but_ how it appears depends on how much there is. (See
section 3.13.2, EK-1184-TM-PR2.) There's a special register to configure it
(the 'KTJ11-B Memory Configuration Register', KMCR), which includes _how
much_ UNIBUS memory there is.
...
Basically, it seems like DEC was determined not to waste any address space on
the J-11/UNIBUS machines. Either it's configured as UNIBUS memory, or it's
PMI.
Interesting. I was referring to what I learned by reading the RSTS/E memory size
determination code. That code says that the main memory limit is 2M - 128kW for 11/44 and
11/70, and 2M - 4kW for J-11 Unibus. So it looks like RSTS/E doesn?t support the mixed
case you mentioned, only the ?just PMI? flavor. 
9:57 a.m.
On Wed, Mar 18, 2015 at 11:16:02AM -0400, Noel Chiappa wrote:
The UNIBUS map will not respond to UNIBUS cycles in the
address range
assigned to the UNIBUS memory.
Just to state the obvious: I assume the whole point of this "Unibus fence"
concept is really for things that *aren't* memory. Mixing in some Unibus
memory that's slower than PMI etc. and needs to use real addresses for DMA
(vs. mapped ones) seems like a giant hassle for just 6.5% more RAM, so I
figure it's really for bus windows or ROM boards or frame buffers or any
oddball device that looks like memory and is too big to fit in the I/O page.
(Even more obvious in case this is greek to anybody: the Unibus map acts
as a RAM emulator for DMA accesses, passing those to real memory after
remapping the addresses, and the "fence" optionally sets a Unibus address
range in the low 248 KB where the map is disabled from doing that and steps
aside to let any real Unibus devices at those addresses respond -- or not,
so timeouts are still possible.)
John Wilson
D Bit
10:29 a.m.
On 2015-03-18 17:57, John Wilson wrote:
On Wed, Mar 18, 2015 at 11:16:02AM -0400, Noel Chiappa
wrote:
(And it's not giving you more RAM. PMI memory already gives you 4M minus
the I/O page)
Johnny
The UNIBUS map will not respond to UNIBUS cycles
in the address range
assigned to the UNIBUS memory.
Just to state the obvious: I assume the whole point of this "Unibus fence"
concept is really for things that *aren't* memory. Mixing in some Unibus
memory that's slower than PMI etc. and needs to use real addresses for DMA
(vs. mapped ones) seems like a giant hassle for just 6.5% more RAM, so I
figure it's really for bus windows or ROM boards or frame buffers or any
oddball device that looks like memory and is too big to fit in the I/O page.
3518
days inactive
3518
days old
5 comments
4 participants
participants (4)
-
bqt＠update.uu.se -
jnc＠mercury.lcs.mit.edu -
paulkoning＠comcast.net -
wilson＠dbit.com