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

Timothe Litt litt at ieee.org
Mon Mar 23 15:54:40 EDT 2020


On 23-Mar-20 15:29, Eric Smith wrote:
> On Mon, Mar 23, 2020 at 1:01 PM Timothe Litt <litt at ieee.org
> <mailto:litt at ieee.org>> wrote:
>
>     The PDP-11s, like the 11/05 were ttl, the CPU ALU was something
>     like 74181 4 bit slices.  I don't count them as "real" microcoded
>     machines for some reason - perhaps because the ucode was all ROM,
>     and IIRC there was no assembler for it. 
>
>
> All PDP-11 models except the original KA11 CPU used in the PDP-11/20
> were microcoded. There were microassemblers for many of the models,
> but for most models the microassemblers never were provided to
> customers, and were probably not readily available even inside DEC.

I didn't see them, but that wasn't my world.  I do remember that
printouts of the ROMs were in some of the printsets.  And some of the
people I talked with said that the ROMS were hand generated.  For some
value of "hand".  Anyhow, right or wrong, I thought of those microcodes
more like PLA equations than "microcode" as used in the KL, IBM, and
other systems where there was significant flexibility.

> Later, general-purpose microassemblers were used, such as MICRO and
> MICRO2. (It appears to me that there were two different DEC
> microassemblers that both used the name MICRO2; the one from LCG
> appears to be significantly different than the one used for VAXen.)
>
Micro came first, developed by Tim Leonard for the KL-10 in PDP-10
assembler.  It introduced the constraint syntax, comma-separated fields,
defaults, / for contents (like DDT) and most of the pseudo-ops.  It
knows about two simultaneous control stores - U and D.  (You need that
when one contains a dispatch address in another.)  It was also used for
the KS10.

Meantime, Micro2 started as a clone re-written in BLISS for the VAX.  It
uses somewhat different syntax, handles more simultaneous control
stores, generally more flexible.

I don't recall there being a second LCG-developed Micro2 - however, we
did use Micro2 for Jupiter (IIRC) and the VAX 9000 (for sure).  (Not
sure about the 8600; I didn't have much to do with it.)  It is possible
that it forked - at times and for some tools there was cooperation
between the CAD groups.  At other times, not so much.  DECsim went back
and forth.  Microcode tools tended to be frozen early in a project - too
much risk of breakage by changing them (including taking latest updates)
mid-stream.  Micro2 definitely kept evolving.  You may have seen such a
frozen snapshot.

> The 11/03 (AKA LSI-11) and the 11/60 were the only PDP-11 models for
> which DEC actually "supported" customer-written microcode, for small
> values of "support": a WCS, microassembler, and microcoding
> documentation were sold, but beyond that you were on your own.

Yup - I'd add "reluctantly" to "sold".  Wasn't there a WCS option for
the 11/34?  Memory fails..

> The 11/03 and 11/60 had sufficiently general hardware data paths to
> make custom microcoding worthwhile; for most other PDP-11 models the
> data paths were very limited, reducing the utility that a WCS would
> have provided. That's why the aftermarket WCS option for the PDP-11/40
> also added additional hardware such as a field extractor and a
> hardware stack, with the microword width increased by 24 bits to
> control the addtional hardware.
>
I'm not sure what the market was for WCS - at that time, attached FP
boxes (e.g. Floating Point Systems) were in vogue, and probably provided
better acceleration for most purposes.  For real-time, the PDP-11 pretty
much kept up with the outside world.  You could maybe eliminate some bus
traffic/memory references - but in development time and cost of moving
to the next generation, it never seemed like a win.  Plus there was a
mystique about ucode - the tight coupling to hardware took some rare
talent to actually make it work.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20200323/7f162da2/attachment.html>


More information about the Simh mailing list