On 06-Sep-18 16:17, Paul Koning wrote:
>
>> On Sep 6, 2018, at 3:59 PM, Bob Supnik <b...@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.
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
