[Simh] DMA access to the IO page

[Mark Pizzolato]

On Thursday, September 6, 2018 at 11:33 AM, Timothe Litt wrote:
> > 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.)

Along the way, while doing this, you had added the ability to access the 
I/O page via DMA.

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

As it turns out, fencing them off wasn't hard at all and is now in the 
master branch along with bus size bounds checking to more robustly
identify I/O page references.

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

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

- Mark