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