[Simh] More on DMA to IO page

[Timothe Litt]

On 06-Sep-18 16:17, Paul Koning wrote:
>
>> On Sep 6, 2018, at 3:59 PM, Bob Supnik <bob at supnik.org> wrote:
>>
>> ...
>> 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.


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



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