<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 05-Sep-18 22:13, Bob Supnik wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a2341d3e-64a9-e898-470e-1567656c4b3f@supnik.org">Apparently,
the GT40 does this. So... problems.
<br>
</blockquote>
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.)<br>
<br>
I can't speak to whether any Qbus device does DMA to the IO page -
off-hand, I can't think of a DEC device that would have done that.
<br>
<br>
It's certainly true that if CPU internal registers were accessible
to DMA writes, bad things could happen. However, it may not be
necessary to fence them off in the emulator. In the hardware, I'd
expect such<br>
a device to get a NXM (bus timeout). Or maybe the write is
ignored. So unless a device exists that expects that behavior,
which seems doubtful, the issue can probably be ignored. Of course,
having said that, there'll probably be some diagnostic that tests
NPR timeouts that way :-( <br>
<br>
(Even more evil would be that some early (unibus) 11's had the GPRs
in I/O space -- I think an implementation artifact, but it was handy
to be able to read them directly off the switches for debugging.)<br>
<br>
<br>
<blockquote type="cite"
cite="mid:a2341d3e-64a9-e898-470e-1567656c4b3f@supnik.org">
<br>
1. The original simulator I wrote didn't support DMA to IO space.
Code for this was added in V4, but the code conformed to the
internal simulator convention that all addresses are 22b wide.
This is certainly not the case for Unibus DMA devices; those
addresses are 18b wide. So the V4 code to test for the IO page
needs to be bus-type sensitive.
<br>
<br>
I'm assuming the GT40 either generates 18b addresses via Address
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.
<br>
<br>
On Qbus systems, IO page references are distinguished by the
assertion of BBS7, and only address bits <12:0> matter.
Either the CPU or a DMA device can assert BBS7, but I don't think
the standard Qbus chips ever assert BBS7, so I don't think
standard Qbus DMA devices can access the IO page. I could be wrong
on this.
<br>
<br>
2. More critically, while all IO space addresses are accessible
from the CPU, not all are accessible from DMA. In particular,
internal CPU registers are not, at least on the systems I'm
familiar with. (And I think Unibus map registers aren't either.)
CPUs, in general, didn't need to monitor DMA activity, except for
systems with internal caches, like the 11/70. I know for a fact
that the F11 and J11 simply ignored DMA activity. The cache, if
any, was external to the CPU, and it was the responsibility of the
cache controller to deal with DMA activity.
<br>
<br>
At the moment, the PDP11 simulator makes no distinction between IO
page addresses that are CPU-internal vs bus-external. Without
this, DMA devices can do truly evil things, like overwrite the PSW
or memory management registers, that they couldn't do on a real
system. So a data structure needs to be added to distinguish
internal from external IO space addresses, code needs to be added
to distinguish internal DIB entries from external, and call flags
added to the IO page read/write routines to distinguish CPU access
from DMA access.
<br>
<br>
/Bob
<br>
<br>
<br>
_______________________________________________
<br>
Simh mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Simh@trailing-edge.com">Simh@trailing-edge.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://mailman.trailing-edge.com/mailman/listinfo/simh">http://mailman.trailing-edge.com/mailman/listinfo/simh</a>
<br>
</blockquote>
<br>
</body>
</html>