[Simh] DMA access to the IO page

[Tim Shoppa]

Bob, a completely supported configuration for Q-bus RT-11 was 30K words (up
to 170000) RAM on a MSV11D on a 11/23 or 11/03.

This started with, I think, V3B of RT-11 and continued through RT-11 5.7.

Similar systems could be configured with third party memory and would work
on Unibus 11/24's as well.

I never knew of any issues with DMA to the high memory addresses using DEC
DMA peripherals (16 bit or 18 bit address bus) or clones (almost all 18 bit
address bus).

The Falcon documentation shows how to enable memory even further up and a
patch in the RT-11 release notes shows how to configure a monitor to use
memory up higher than 30K.

I was told RSX-11S had support for 30K as well but I'm not as well versed
in RSX-11S configuration.

Tim

On Wed, Sep 5, 2018 at 10:14 PM Bob Supnik <bob at supnik.org> wrote:

> Apparently, the GT40 does this. So... problems.
>
> 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/e4b8c6d3/attachment-0001.html>