[Simh] DMA access to the IO page

[Johnny Billquist]

On 2018-09-06 08:32, Lars Brinkhoff wrote:
>> Apparently, the GT40 does this. So... problems.
> 
> Yes, the boot ROM includes instructions for the VT11 display processor.
> 
> Admittedly, I'm quite clueless when it comes to details about the PDP-11
> and Unibus.  The vt_fetch function in pdp11_vt.c does go through the I/O
> map, but apparently that by itself isn't enough to access the ROM
> region.  The GT40 is built on a 11/05 which doesn't have an I/O map,
> right?
> 
> I worked around this by adding a direct call to iopageR.  It's a
> temporary solution for running the GT40 ROM code, and as such it works.
> I apologize if this makes anyone cringe.  I'll be happy to throw it out
> when a real solution appears.

It seems like a rather unfortunate design quirk in simh.
A real Unibus don't distinguish between the I/O page any anything else. 
In fact, from the Unibus point of view, there is no "I/O page". It's a 
flat 18-bit address space where everything works the same.

Memory is a bit special in that it is always just a slave on the Unibus, 
and never master. And memory usually appear anywhere.
Many other devices can be both masters and slaves, and are usually 
addressed in the high 8Kbyte, but there is nothing that says they have to.
Finally, the CPU is always master, and never slave. So no other devices 
can access the CPU.

The I/O page concept, as such, is a construction in the CPU. It's just 
so that the high 8K of the 64K address space on a PDP-11 without MMU 
gets converted to the high 8K of the Unibus address space when 
referenced. And of course, if the PDP-11 have an MMU, then you'll have 
to make sure you have such a mapping yourself.

So, of course DMA can happen to the high 8K of the Unibus. No different 
than any other address.

>> CPUs, in general, didn't need to monitor DMA activity, except for
>> systems with internal caches, like the 11/70.
> 
> I'll take this opportunity to also mention that I tested something
> labelled "PDP-11/60, 70 Console/Diagnostic ROM".  It checks bit 0 in the
> 177752 register, which is related to the cache.  Doing "set hitmiss 1"
> in SIMH makes the ROM happy, but I'm sure that's only an approximation
> of the real hardware function.  Secondly, it retrieves an address from
> 704 and jumps to that address added by two.  I don't know what's
> supposed to be there.

The 11/60 and 11/70 diagnostics rom do a test that the cache is working 
by doing accesses twice to some memory and checking that you are getting 
cache hits registered.
And yes, 177752 is the cache hit/miss register, which holds the hit/miss 
state of the last 6 memory accesses.

As for the start address, the diagnostics ROM is supposed to be jumped 
to from the device specific bootstrap. The first thing the diagnostics 
does is preserving registers R0,R1,R4 in 700,702,704.
R4 is supposed to hold the address from where the diagnostics were 
called, and so at the end of the diagnostics, the code returns from 
where it was called, but without making use of the stack.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol