<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>LingLing, as well as MRC's other 2020's made it out to Seattle
(Living Computer Museum). I had asked them whether they had been
able to recover any software off them, but I have yet to hear
anything. I ought to check in; they did some interesting recovery
work on a PDP-8 that I enjoyed reading about.</p>
<p>I don't have a series 5 monitor handy, but for 7, the symbols
live in section 5 and appear to be taking up about 253 pages of
space. That number may not be completely representative; the bug
strings might be in there, too. At any rate, you can get a feel
for what engineering must have been up against when they went with
symbol hiding in 4 and what MRC must have had to do to re-hide
them in 5 along with the new code.</p>
<p>I think once he re-hide them, he probably had plenty of space and
that 1 MW wouldn't have made any difference. I presume that for
two reasons:<br>
</p>
<ol>
<li>You can see what kind of space got freed up; he wouldn't have
needed the additional memory. The real work would have been
moving the .PSECT's and storage around to fit in a single
section as well as modifying the macros for intersection
transfer. One imagines that KDDT would have needed some
retrofitting to get at the other address space.<br>
</li>
<li>Move over, using additional sections in the monitor might have
been 'hard' because you are talking about switching address
spaces to transfer execution; essentially having the monitor
task switch itself into another part.<br>
</li>
</ol>
<p>As of 6, you get CFS support, which is a bucket load of code. I
think maybe Phase IV, if that only runs over NI; I think that may
be the case because I believe the DN20's remained at Phase III. I
seem to recall that we were actually thinking of removing them at
one point; that was mostly because of the potential saving in
cooling and power (which didn't turn out to be that much).<br>
</p>
<div class="moz-cite-prefix">On 4/29/20 3:55 AM, R. Voorhorst wrote:<br>
</div>
<blockquote type="cite"
cite="mid:012e01d61dfb$7f074cf0$7d15e6d0$@swabhawat.com">
<pre class="moz-quote-pre" wrap="">L.S.
By the way, I am pretty sure MRC attempted his variant of Tops20 (4.2? and 5.x?) on the 512 kB KS10 variant; the results might have turned out differently if he had a 1 MW variant available.
Is this work preserved somewhere?
R.V.
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-hecnet@Update.UU.SE">owner-hecnet@Update.UU.SE</a> [<a class="moz-txt-link-freetext" href="mailto:owner-hecnet@Update.UU.SE">mailto:owner-hecnet@Update.UU.SE</a>] On Behalf Of R. Voorhorst
Sent: Wednesday, 29 April, 2020 08:51
To: <a class="moz-txt-link-abbreviated" href="mailto:hecnet@Update.UU.SE">hecnet@Update.UU.SE</a>
Subject: RE: [HECnet] VMS/RSX Guest accounts --> 2020 Unibus(ses)
L.S.
Well, look in Tops10 monitor sources and in the engineering stuff: multiple Unibus adapters (up to 4, standard 2 provided) each which its own mapping hardware and registers.
It can easily expanded to even handle 4 MW memory space (I run here some 2 MW variants), but the current Tops10 single section monitor cannot handle the needed page mapping in monitor mapping space very well.
1 MW works fine though. 1 MW variants surfaced somewhat later than the 512k ones.
R.V.
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:owner-hecnet@Update.UU.SE">owner-hecnet@Update.UU.SE</a> [<a class="moz-txt-link-freetext" href="mailto:owner-hecnet@Update.UU.SE">mailto:owner-hecnet@Update.UU.SE</a>] On Behalf Of Johnny Billquist
Sent: Wednesday, 29 April, 2020 08:14
To: <a class="moz-txt-link-abbreviated" href="mailto:hecnet@Update.UU.SE">hecnet@Update.UU.SE</a>
Subject: Re: [HECnet] VMS/RSX Guest accounts
I should point out that I actually suspect the 2020 have a Unibus map, just as the big PDP-11s or any VAXen have.
Which then remaps the Unibus address space to the larger address space of the machine, so that DMA can go anywhere.
Johnny
On 2020-04-29 08:10, Johnny Billquist wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">Nope. Unibus can only address 128Kword, and in this context that is
128K of 18-bit words. So you cannot even DMA into a full 256K of 36 bit words.
Johnny
On 2020-04-29 05:51, Thomas DeBellis wrote:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">You know, I have been racking my brains from time to time and I can't
remember a thing about the ADP modifications to the 2020.
So, the 2020 came with a maximum of 512K words, 2**9. An addition
bit would have brought it up to a full megaword, 2**10, which is
quite reasonable for the target audience (some kind of installation
that didn't hold stock in the local power utility).
I guess there may have been modifications to the 2020 build of the
monitor to allow for the extra bit. I don't know if the Unibus
devices could do DMA into the full address space.
Did you pick up any software with these little jewels? The monitor
changes might be interesting.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">--------------------------------------------------------------------
---- On 4/24/20 12:12 AM, Dave McGuire wrote:
Nice!
One of our 2020s is in the brown color scheme. You know what
that
means: ADP, and one more address bit.
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">-------------------------------------------------------------------
-----
On 4/23/20 6:15 PM, Thomas DeBellis wrote:
The solution for 4.1 was one of the finest hacks I have ever heard
of; while the 2020 doesn't support extended addressing, it does
support multiple address spaces, so what they did was move all the
symbols into a separate address space. This was called 'hiding'
symbols and I thought it was great because it made them harder to
smash. However, all of that went out the window with 5.0, which
fully supported extended addressing.
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
</body>
</html>