<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 06-Sep-18 15:04, Mark Pizzolato
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:03006E3FC39B5A48AB9DBCCC101090A8344A084CA5@REDROOF2.alohasunset.com">
<pre wrap="">On Thursday, September 6, 2018 at 11:33 AM, Timothe Litt wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">On 05-Sep-18 22:13, Bob Supnik wrote:
Apparently, the GT40 does this. So... problems.
</pre>
</blockquote>
<pre wrap="">
The KDP (KMC/DUP) and KDZ (KMC/DZ) also do this. Once the KMC11
was available, this became a fairly popular method to off-load character
processing & turn character interrupts into DMA. When I did the KDP
emulation, Mark & I negotiated a private API rather than emulate NPR
to the DUP. See pdp11_kmc.c. (In the hardware, the KMC ucode runs
the dup (or dz) with interrupts disabled & polls the DUP/DZ CSRs often
enough to catch individual characters. It then DMAs validated messages
into memory. The polling would have been pretty expensive to emulate.)
</pre>
</blockquote>
<pre wrap="">
Along the way, while doing this, you had added the ability to access the
I/O page via DMA.
</pre>
</blockquote>
Yes. It's a hybrid. <br>
<br>
The private interface handles DDCMP message transport, avoiding the
character overhead. You do the framing, CRC & deliver (or
accept) messages. The KMC does the DMA. <br>
<br>
However, the DUP CSRs are accessed by DMA for resetting/configuring
the DUP, modem control, loopback, and also to detect (via NXM) cases
where the OS tries to activate a non-existent DUP. These are
infrequent, and didn't merit a private interface.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:03006E3FC39B5A48AB9DBCCC101090A8344A084CA5@REDROOF2.alohasunset.com">I'm
assuming the GT40 either generates 18b addresses via Address
<blockquote type="cite">
<pre wrap="">Extension bits or does the 16b -> 18b conversion itself, including
the IO page test. The "Unibus" does NOT do the IO page
recognition/sign extension to 18b. In all Unibus systems, that's
done in the CPU.
</pre>
</blockquote>
<pre wrap="">
That is the core problem that raised this discussion and illuminated
the potential problems with the initial simulator DMA access to the
I/O page.
The case we were seeing only had a 16 bit addresses presented for a
DMA memory reference. The lack of high bits 16 and 17 was either
an implementation problem in the VT11 simulation or a bug in the
program we're running which never programmed the high bus
address bits. I'm leaving it to Lars to explore which of these is the
cause. The code that is running was not captured directly from ROMs
but was typed in from a listing in a manual. That precise code may
not have ever actually run from a ROM in the I/O page...
</pre>
</blockquote>
Probably the former. The 11/05 doesn't have a MMU and uses 16 bit
addresses. The bus master (CPU or device) must set bits 16 & 17
for any access to the I/O page. This is required for any Unibus
peripheral to work. <br>
<br>
This isn't a function of where the code resides. There are two
things going on. The CPU has to fetch code from I/O space - this
isn't DMA, but it does require the CPU to set the upper PA bits.
The display processor does DMA to get graphics data - this is DMA.
If the ROM code tells the display processor to fetch from ROM,
that's DMA to I/O space. In that case, the display processor is
responsible for setting the upper PA bits.<br>
<br>
<br>
<br>
<blockquote type="cite"
cite="mid:03006E3FC39B5A48AB9DBCCC101090A8344A084CA5@REDROOF2.alohasunset.com">
<pre wrap="">
- Mark
</pre>
</blockquote>
<br>
</body>
</html>