<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 06-Sep-18 16:17, Paul Koning wrote:<br>
</div>
<blockquote type="cite"
cite="mid:E1162E73-D93E-4133-82B7-9B923BDC6415@comcast.net">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On Sep 6, 2018, at 3:59 PM, Bob Supnik <a class="moz-txt-link-rfc2396E" href="mailto:bob@supnik.org"><bob@supnik.org></a> 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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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). <br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:E1162E73-D93E-4133-82B7-9B923BDC6415@comcast.net">
<pre wrap="">
Did any KMC based comms software use the KG11 for its CRC? Or does the KMC do that internally well enough?
</pre>
</blockquote>
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.<br>
<br>
<br>
<br>
</body>
</html>