[Simh] DMA access to the IO page

[Timothe Litt]

On 06-Sep-18 15:04, Mark Pizzolato wrote:
> 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.
Yes.  It's a hybrid.

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. 

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.


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

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.



> - Mark

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