[Simh] DMA access to the IO page

[Timothe Litt]

On 05-Sep-18 22:13, Bob Supnik wrote:
> Apparently, the GT40 does this. So... problems.
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.)

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. 

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
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 :-( 

(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.)


>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> /Bob
>
>
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180906/5a565662/attachment-0001.html>