[Simh] More on DMA to IO page

[Bob Supnik]

Looking at the DEC ChipKit documentation, it seems fairly clear that a
device implemented with the DC003/5/6/10/21 series of chips never drives
BBS7. BBS7 is an input to the address matching logic implemented in the
DC005, but that's it.

On the other hand, the DEC Standard for the LSI11 bus says that devices
are allowed to do DMA to the IO page, and that testing with the
mandatory 'missing words' (the first 8 words are reserved) is a standard
diagnostic technique for testing the NXM logic on a DMA device.

On the other, other hand, Qbus configuration standards also say that the
last 8KB of physical address space must not be implemented as memory. So
if the IO page doesn't respond to DMA requests, then the device will
<still> get an NXM, because there's no memory.

I've looked through the available Qbus DMA device schematics (there
aren't many), and I see no evidence of devices doing the 9b AND to
detect IO space and assert BBS7. However, many devices use complex gate
arrays, and who knows what's going on inside them?

So my tentative conclusion stands: the LSI11 bus did not do DMA to IO
space, even if it was theoretically possible.

Next, chips. I reread the J11 specification. As I thought, there's no
way to access any of the registers implemented inside the chipset itself
from outside. The J11 has no "snoop" function.

On the other hand, there is a small space of "system" registers which
are expected to be implemented, if at all, in the surrounding CPU logic,
which was always a gate array. I suspect, but can't prove, that the gate
arrays didn't respond to DMA requests on these registers either, only on
DMA requests to real memory. That was certainly true of the first J11
module, the KDJ11A.

Now, as to bus maps. The 11/70 bus map has a jumper-adjustable upper
limit for what parts of Unibus address space go through the map, and
what parts are resolved on the Unibus itself. The maximum value is
760000; that is, the IO page can never be mapped to memory. The 11/44
bus map has a jumper adjustable upper and lower limit of unmapped Unibus
space in addition to the IO page, which is always off limits. The 11/84
bus map is similar, but the jumpers have been replaced by configuration
registers.

So my conclusion is that IO mapped PDP11s (which are, of course, always
Unibus) do support DMA to IO space, so you could put a GT40 (in theory)
on a Unibus J11, and it would work.

Okay, here's the bottom line, then.

1. There's no need to support DMA to IO space on Qbus systems. It wasn't
done.
2. Therefore, the ba limit test can be for the 18b Unibus limit on
Unibus systems, that is,

if (UNIBUS && (ba >= unibus_io_base_page)) {then read/write IO space}

3. It's still necessary to keep DMA access away from the CPU and system
registers, with all the hair that implies.

Personally, I like Tim's solution of a private interface between
consenting devices. That would certainly work for the GT40 and its ROM too.

/Bob

[Paul Koning]

...
Personally, I like Tim's solution of a private interface between consenting devices. That would certainly work for the GT40 and its ROM too.

But if it's a private interface, that means you couldn't do a KMC emulation which runs KMC microcode that talks to some device you aren't already covering as a "consenting" partner. And my "disk refresh of a display device" wouldn't work, though that's not likely to be code found in the wild.

Did any KMC based comms software use the KG11 for its CRC? Or does the KMC do that internally well enough?

paul

[Timothe Litt]

Post by Paul Koning

...
Personally, I like Tim's solution of a private interface between consenting devices. That would certainly work for the GT40 and its ROM too.

But if it's a private interface, that means you couldn't do a KMC emulation which runs KMC microcode that talks to some device you aren't already covering as a "consenting" partner. And my "disk refresh of a display device" wouldn't work, though that's not likely to be code found in the wild.

That's correct.  I did not implement the KMC microarchitecture; it's a
functional emulation.  In fact, I only implemented the DDCMP variant of
COMIOP-DUP - though there are hooks for SDLC.  The KMC does accept (and
verify) microcode loads - if it's not COMIOP-DUP, it fails.  I also let
the micro PC wander so that host errorlogs and keep-alives are less boring.

This is analogous to the way we emulate CPUs - we don't emulate the
microarchitecture, just the instruction results.  And other smart
peripherals (e.g. MSCP controllers, ethernet) that have microcode.

The KMC+Unibus device pairings were expedient, but not particularly
efficient.  They offload the CPU at the expense of a lot of Unibus
traffic.  ("Pair" isn't quite right - KDP supports multiple DUPs/KMC). 

The DMC/DMR also use the KMC, but with a private bus between the KMC &
the line card - and with ROM instead of RAM microcode store.  The
private bus is what enabled megabaud links.

Before single-chip microprocessors (like the 808x) became available &
cheap, the KMC was our universal uP - besides KDP, KDZ, and DMx, it was
used for the AN22, the DX20 (Massbus->IBM storage), and a DMA controller
for printers whose name escapes me at the moment.  And probably more.

Sometimes I think it would be fun to support random microcodes, but then
I remember how closely most of them are tied to hardware minutiae -- for
example the KMC is fast enough relative to the Unibus that its ucode has
delays for signal settling time.   It has cycle/instruction timing
that's faster than the CPU, which in SimH works (mostly) on
instructions.  So a faithful emulation would require two sets of
"instruction" timing.  And for ucode to work, it has to be pretty
faithful.  You don't want to go there.

Post by Paul Koning
Did any KMC based comms software use the KG11 for its CRC? Or does the KMC do that internally well enough?

Not that I recall.  The KDP = KMC + DUP; the DUP has CRC hardware.  KDZ
didn't require a KG11; the DZ doesn't have CRC hardware, so the KMC or
host must have done it - I don't have that ucode handy.  The KDZ
provided DMA output & basic line input (with break chars and flow
control).  I didn't find the input useful for TTYs - I looked into it
for the KS.  DECnet has KDZ support for DDCMP.

[Eric Smith]

Now, as to bus maps. The 11/70 bus map has a jumper-adjustable upper limit
for what parts of Unibus address space go through the map, and what parts
are resolved on the Unibus itself. The maximum value is 760000; that is,
the IO page can never be mapped to memory.

By coincidence I was recently looking over the 11/70 (KB11-C CPU) and MK11
(semiconductor memory box) documentation. The latter claims that if you
fill an MK11 with the M8722 storage array boards (256KB/128KW each), to
have 4MB/2MW of memory in a single MK11 box, the 11/70 will not work. I was
surprised; I expected that the KB11-C would simply not perform memory
requests for physical addresses in the I/O page, whether those accesses
originated from the CPU or the Unibus. The MK11 docs say that you have to
omit two storage array boards (if using interleaving) or one board (if
not), so the maximum is 3584KB/1792KW interleaved or 3840KB/1920KW
non-interleaved, rather than 4088KB/2044KW that would otherwise be possible.

Eric

[Johnny Billquist]

Post by Bob Supnik
Now, as to bus maps. The 11/70 bus map has a jumper-adjustable upper
limit for what parts of Unibus address space go through the map, and
what parts are resolved on the Unibus itself. The maximum value is
760000; that is, the IO page can never be mapped to memory.
By coincidence I was recently looking over the 11/70 (KB11-C CPU) and
MK11 (semiconductor memory box) documentation. The latter claims that if
you fill an MK11 with the M8722 storage array boards (256KB/128KW each),
to have 4MB/2MW of memory in a single MK11 box, the 11/70 will not work.
I was surprised; I expected that the KB11-C would simply not perform
memory requests for physical addresses in the I/O page, whether those
accesses originated from the CPU or the Unibus. The MK11 docs say that
you have to omit two storage array boards (if using interleaving) or one
board (if not), so the maximum is 3584KB/1792KW interleaved or
3840KB/1920KW non-interleaved, rather than 4088KB/2044KW that would
otherwise be possible.

Hmm. There is a potential side issue problem that might be the reason
for this limitation, and that don't have anything to do with memory as such.

The problem is that the MK11 memory boxes also have CSRs, and those are
living in that last 8K space. If you have memory mapping those same
addresses, I have no idea what happens, but either way is not good.
Either you have the memory, in which case the CSRs are unaccessible, and
they control how the memory box works. Or else you have the CS‰s, but
what then happens to those memory cells?

Johnny

[Eric Smith]

Post by Johnny Billquist
The problem is that the MK11 memory boxes also have CSRs, and those are
living in that last 8K space. If you have memory mapping those same
addresses, I have no idea what happens, but either way is not good.

Either you have the memory, in which case the CSRs are unaccessible, and

Post by Johnny Billquist
they control how the memory box works. Or else you have the CS‰s, but what
then happens to those memory cells?

You're right. The Unibus does not go to the MK11, which only connects via
the memory bus to the KB11-C cache, so at least some I/O page accesses have
to go across the memory bus for the MK11 CSRs. Rather than decoding and
only sending the specific MK11 CSR I/O page accesses to the memory page,
the KB11-C cache system most likely just sends all I/O page accesses to
both Unibus and the memory bus, expecting only one to acknowledge.

If I was desperate to have 4088KB/2044KW, I could probably kludge up
additional logic to the MK11 control modules to explicitly disable the RAM
operation for the entire I/O page range. However, I have only ten M8722
modules (2.5MB/1.25MW), so it isn't something I actually need.

[Johnny Billquist]

Post by Johnny Billquist
The problem is that the MK11 memory boxes also have CSRs, and those
are living in that last 8K space. If you have memory mapping those
same addresses, I have no idea what happens, but either way is not
good.
Either you have the memory, in which case the CSRs are unaccessible,
and they control how the memory box works. Or else you have the
CS‰s, but what then happens to those memory cells?
You're right. The Unibus does not go to the MK11, which only connects
via the memory bus to the KB11-C cache, so at least some I/O page
accesses have to go across the memory bus for the MK11 CSRs. Rather than
decoding and only sending the specific MK11 CSR I/O page accesses to the
memory page, the KB11-C cache system most likely just sends all I/O page
accesses to both Unibus and the memory bus, expecting only one to
acknowledge.

Actually, it's more complex than that.
If you access the I/O page on the 11/70, it will only get directed to
the Unibus. No transaction happens on the memory bus.
To get to the MK11 CSRs, you have to be really tricky. You need to
enable the unibus map, pointing that to the I/O page, and then access
memory in the Unibus map space (the high 256K), with the map enabled,
which will then remap your memory access to the I/O page, but will run
it over the memory bus, thereby getting access to the MK11 CSRs.

Like I said - it's complicated... :-)

Post by Johnny Billquist
If I was desperate to have 4088KB/2044KW, I could probably kludge up
additional logic to the MK11 control modules to explicitly disable the
RAM operation for the entire I/O page range. However, I have only ten
M8722 modules (2.5MB/1.25MW), so it isn't something I actually need.

Well, you'd probably also need to deal with the Unibus map handling,
since those addresses also do not generate accesses directly on the
memory bus...

Johnny

[Eric Smith]

Well, you'd probably also need to deal with the Unibus map handling, since
those addresses also do not generate accesses directly on the memory bus...

Really? What's the highest physical address the Unibus map supports?

[Johnny Billquist]

Post by Johnny Billquist
Well, you'd probably also need to deal with the Unibus map handling,
since those addresses also do not generate accesses directly on the
memory bus...
Really? What's the highest physical address the Unibus map supports?

Uh? The Unibus map is for translating 18-bit addresses to 22-bit
addresses. And it can translate all of it. In fact, you can (at least in
theory) go a bit above 22 bits that way.

If you look at the physical address space of the 11/70 however, the low
3840 bytes are doing on to the memory bus. 3840 to 4088 is going to the
Unibus memory space, which is remapped by the Unibus map, if enabled.
And the last 8K goes to the Unibus.

Johnny

[Mark Pizzolato]

Post by Bob Supnik
Looking at the DEC ChipKit documentation,

[...]

Post by Bob Supnik
So my conclusion is that IO mapped PDP11s (which are, of course, always
Unibus) do support DMA to IO space, so you could put a GT40 (in theory) on a
Unibus J11, and it would work.
Okay, here's the bottom line, then.
1. There's no need to support DMA to IO space on Qbus systems. It wasn't
done.

OK.

Post by Bob Supnik
2. Therefore, the ba limit test can be for the 18b Unibus limit on Unibus
systems, that is,
if (UNIBUS && (ba >= unibus_io_base_page)) {then read/write IO space}

Done now.

Post by Bob Supnik
3. It's still necessary to keep DMA access away from the CPU and system
registers, with all the hair that implies.

Done previously.

Post by Bob Supnik
That would certainly work for the GT40 and its ROM too.

The register interface to the VT11 really has only one register which is a 16 bit
value that sets the PC of the graphics processor to an address in the PDP11's
memory where the graphics program that it was to run existed. Once the
graphics PC is set, it fetches instructions from PDP11 RAM (or ROM in the
I/O page) and continues on its merry way. I've changed the code which
performs graphics processor memory fetch to sign extend all addresses >=
0160000 before being passed into the Map_ReadW().

- Mark