[Simh] Is it possible to simulate the first Vaxen I ever used?

[Timothe Litt]

On 23-Mar-20 13:09, Eric Smith wrote:
> On Mon, Mar 23, 2020 at 7:34 AM Robert Armstrong <bob at jfcl.com
> <mailto:bob at jfcl.com>> wrote:
>
>     The 730 was interesting in that ALL of the CPU microcode was in
>     RAM and was loaded by the CFE at boot time.  It was possible to
>     locally modify the 730 microcode, and DEC even had a set of
>     microcode development tools for the 730.  I've never seen them
>     except in references.
>
> [snip]
> The first two DEC machine to use entirely RAM control store were the
> KL10 and KS10 36-bit PDP-10 CPUs, in 1975 and 1978, both used in
> DECsystem-10 and DECSYSTEM-20 systems. The KL10 was the biggest and
> most expensive PDP-10, and the KS10 was the smallest and least
> expensive.  The earlier 36-bit CPUs, the 166 (PDP-6), KA10, and KI10,
> were hardwired rather than microcoded.
>
Yes, with module and wire-wrap backplanes. The could be (and were) ECOed
in the field.

The KL10 was the first microcoded machine.  And first and most
complicated in other dimensions.  Bugs were expected, and reducing the
cost of dealing with them was a consideration.  It was a good call. 
Besides that, having a fully programmable microstore allowed us to do
functional upgrades too.  Like the CI/NI, and the GFloating support. 
GFloat was pure ucode.

> Since the KL10 was DEC's biggest, most expensive machine at the time,
> it wasn't nearly as cost sensitive as their other CPUs, so there
> probably wasn't even any consideration given to using PROM for the
> control store.

I don't think you could have found fast enough PROMs.  The KL is an ECL
machine.  The RAMs are ECL, and the timing is hairy enough that the
modules are only populated 1/2 way back - to fill the board would break
timing.  The boards also have loops of etch that serve as delay lines. 
Manufacturing would short the loops at the right place for each board -
depending on how the board (and RAMs) turned out.  Today we take for
granted process controls and tolerances that were, if not unattainable,
unaffordable at that time.


>
> The decision to use RAM control store on the KS10 is less obvious. It
> was still an expensive machine, maybe 20% or 25% of the cost of a
> KL10, so it may still have not been considered cost sensitive, and the
> benefits of easy microcode updates may have been considered more
> important than they would have been on e.g. the PDP-11 CPUs.
>
We learned from the KL that it was worthwhile.  TCO (DEC's as well as
the customers').

The KS did compromise, however.  While the control store is all RAM, the
dispatch microcode is in metal PROMs.  I still have a few.  And, I found
a bug in a privileged instruction that required a DROM change to fix. 
We redefined the instruction instead.  Luckily, no other issues effected
the DROM, though it did prevent adding some instructions that the KL had
(and the OS liked).

> The KS10 control store RAM has parity, and RAM parity errors were
> apparently fairly common. A control store parity error would halt the
> CPU and interrupt the 8085 front end, which would reload the control
> store and restart the machine. DEC patented that.
>
>
The 8085 code is crammed into UV EPROMs.   Quite a few coding tricks to
save bytes and make it fit.  It required several rounds of changes -
which meant swapping boards.  FLASH at that time was not available in
the required densities, was insanely expensive - and had an annoying
habit of being forgetful.  I have some neat stories about the latter -
for another day.


> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20200323/97570672/attachment.html>