VAX PDP11 Compatibility Mode

[David Wade]

Folks,

I remember being taught on an Introduction to VMS course that whilst
VMS versions prior to 4.0 relied on PDP-11 compatibility mode, this was
no longer needed.

I also see from the VAX Architecture Reference manual from bitsavers

EY-3459E-DP_VAX_Architecture_Reference_Manual_1987

that PDP11 emulation is an optional feature, and that it may also be
implemented by software for systems which did not have it.

... but looking through the OpenVMS manuals I can't find any reference
to PDP-11 compatibility mode.

So my questions are:-

1. Is there a matrix somewhere that shows which models of VAX have which
feature, especially the PDP11 compatibility mode.

2. Did any versions of VMS implement software emulation of the PDP11

3. If you have an old VMS and an old VAX how did you invoke
compatibility mode? Was there a flag in the file to show it was a PDP11
executable?

I have tried googling but the results get so entangled with VAX and
PDP11 emulation pages its hard to drill down to the real info.

Also sorry for the historicial question. This is something I have long
wanted to know the answers too, but have been distracted by other
things. Some one mentioned this on the CCTALK list so it re-kindled my
curiosity.. Thanks for any replies...

Dave

[Jan-Erik Söderholm]

Den 2019-08-06 kl. 11:03, skrev David Wade:
> Folks,
>
>  I remember being taught on an Introduction to VMS course that whilst VMS
> versions prior to 4.0 relied on PDP-11 compatibility mode, this was no
> longer needed.
>
> I also see from the VAX Architecture Reference manual from bitsavers
>
> EY-3459E-DP_VAX_Architecture_Reference_Manual_1987
>
> that PDP11 emulation is an optional feature, and that it may also be
> implemented by software for systems which did not have it.
>
> ... but looking through the OpenVMS manuals I can't find any reference to
> PDP-11 compatibility mode.
>
> So my questions are:-
>
> 1. Is there a matrix somewhere that shows which models of VAX have which
> feature, especially the PDP11 compatibility mode.
>
> 2. Did any versions of VMS implement software emulation of the PDP11
>

$ mcr
%DCL-W-ACTIMAGE, error activating image RSX
-CLI-E-IMAGEFNF, image file not found $1$DKA0:[SYS0.SYSCOMMON.][SYSEXE]RSX.EXE;
$

I would guess that this (missing) RSX.EXE has something to do
with the PDP11 emulation...

[Jeffrey H. Coffield]

Try this:

https://comp.os.vms.narkive.com/N4yPsEEV/a-simple-question-what-the-h-ll-is-mcr

Jeff C.

[Bob Gezelter]

Dave,

Early VAX processors had hardware/firmware support for PDP-11 compatibility mode. The systems software component of the support was the RSX-11 Applications Migration Executive (AME).

Early versions of VAX/VMS took advantage of this support. Ar first ship, many utilities and compilers ran in compatibility mode (e.g., PIP, FORTRAN, and others).

If memory serves, the MicroVAX was the first VAX without PDP-11 support. At that point, the RSX-11 AME was repackaged as an optional layered product, including software emulation of the PDP-11 non-privileged instruction set.

RSX-11 and VAX executables have different headers, and can be distinguished. My recollection is that this is described in the image activation section of the IDSM.

- Bob Gezelter, http://www.rlgsc.com

[Lee Gleason]

"David Wade" wrote in message news:qibfpd$joq$1...@dont-email.me...

>3. If you have an old VMS and an old VAX how did you invoke compatibility
>mode? Was there a flag in the file to show it was a PDP11 executable?

At the lowest level, it is invoked by doing an REI when you have the
compatibility mode bit set in the PSL that is on the stack. PSL bits
FPD,ISPL,IV, FU and DV must be 0. CURMOD and PRVMOD must be 3.

It is exited when an interrupt or exception occurs.

--
Lee K. Gleason N5ZMR
Control-G Consultants
lee.g...@comcast.net

[David Wade]

interesting thread which implies its a VMS feature but I can see it
documented in the manuals. Time for some more searching...

.. and thanks for all the replies. Very interesting..

Dave

[Chris Scheers]

That description is a bit backwards. It wasn't that compatibility mode
was no longer needed. It was that VMS 4.0 was meant to support the new
MicroVAX models, which did not have compatibility mode. So any VMS
utilities that used compatibility mode had to be rewritten as VAX code
for VMS 4.0.

IIRC, the models that supported PDP-11 compatibility mode were: 730,
750, 780, 785, 8600.

I never used it, but for VMS 4.0 there was a layered product that
activated the MCR function for compatibility mode. I don't know if it
just allowed execution on hardware that had compatibility mode or if it
included an emulator.

--
-----------------------------------------------------------------------
Chris Scheers, Applied Synergy, Inc.

Voice: 817-237-3360 Internet: ch...@applied-synergy.com
Fax: 817-237-3074

[Bob Gezelter]

Chris,

The RSX-11 AME definitely included the emulator.

At a client site, I had the RSX-11 FORTRAN-77 compiler hosted on a MicroVAX 2000, cross-compiling for a J-11-based system.

One has to be careful referring to "MCR" on OpenVMS. It refers to the MCR CLI, which as I recall is part of the AME package. However, it is also a shorthand for SYS$SYSTEM:, as in MCR AUTHORIZE.

[Bill Gunshannon]

Hmmm.... Is this the origin of the original Bob Supnik PDP-11
emulator? It would certainly explain the Paragraph in the Mentec
license that requires :

"software owned by Digital Equipment Corporation
that emulates the operation of a PDP-11 processor
and allows PDP-11 programs and operating systems
to run on non-PDP-11 systems"

which people have always tried to claim meant SIMH.

bill

[John Reagan]

More than that, the parameter processing is more like a foreign command.

You cannot do

$ run sys$system:authorize show jreagan

but you can do

$ mcr authorize show jreagan

[Bob Koehler]

In article <qic89q$q8s$1...@dont-email.me>, David Wade <g4...@dave.invalid> writes:
>
> interesting thread which implies its a VMS feature but I can see it
> documented in the manuals. Time for some more searching...
>
> .. and thanks for all the replies. Very interesting..
>

The obsolete Obsolete Features Manual?

Or a VMS 2.x doc set.

[Terry Kennedy]

On Tuesday, August 6, 2019 at 3:01:01 PM UTC-4, Chris Scheers wrote:

> That description is a bit backwards. It wasn't that compatibility mode
> was no longer needed. It was that VMS 4.0 was meant to support the new
> MicroVAX models, which did not have compatibility mode. So any VMS
> utilities that used compatibility mode had to be rewritten as VAX code
> for VMS 4.0.

By the time the uV II and 86xx had come out, enough instruction traces had been gathered to prove the general "10% of the code is used 90% of the time" and a number of instruction subsets had been investigated, with microcode assist for VAX code implementation of the missing instructions.

That is also what caused (mostly*) the PDP-11 CIS options (11/23, 11/24, 11/44) to get dropped on later models - they implemented a superset of the VAX string, packed decimal, etc. instructions which were some of the first to be thrown overboard when the VAX architecture was subsetted. I think there's a couple of those instructions that were used frequently enough that they were retained even in the subsets.

* The late / slow / buggy nature of the J-11 chipset also didn't help. There were provisions for CIS microms on the underside of the ceramic carrier. But it seems DEC was "happy" enough to get chips that worked (although not at the original design speed**) that they abandoned CIS for both implementation difficulty and lack of usefulness reasons.

** The original top bin was 5Mhz with a 20MHz crystal. The fastest "official" J-11 speed was 18MHz. The support chipset DEC used didn't work*** at 20MHz, so that was dropped as a product goal. The PDP-11/93 and /94 CPU board (designed by ROI, sold by DEC) didn't use the DEC support chipset and didn't have those limitations. My "Report from the field (test)" DECUS Symposium presentation (arranged by DEC, not some massive non-disclosure violation by me) originally had benchmark results at 20, 24 and 26MHz (28MHz was flakey) but when I ran it by DEC I was politely asked to remove those if I didn't mind.

*** This was when PDP-11 related semiconductor fab was getting squeezed by VAX designs in the pipeline, leading to a raft of "it's broke, but we'll ship it anyway" silicon. The 2MB PMI memory board that didn't work in one of Unibus or Q-bus (I forget which) was another example that needed to wait a long time for fixed chips.

> IIRC, the models that supported PDP-11 compatibility mode were: 730,
> 750, 780, 785, 8600.

All 7xx, 8600/8650 had hardware compatibility mode.

> I never used it, but for VMS 4.0 there was a layered product that
> activated the MCR function for compatibility mode. I don't know if it
> just allowed execution on hardware that had compatibility mode or if it
> included an emulator.

Trivia - TECO was not rewritten in VAX assembler, so it carried its own PDP-11 support (or there was a magic exemption for it in the AME licensing, I forget which but think it was the former).

VSI folks might know if Itanium TECO is on Itanium emulating Alpha emulating VAX emulating PDP-11 8-}

[Stephen Hoffman]

On 2019-08-06 09:03:40 +0000, David Wade said:

Here's the VAX architecture standard: start reading:
https://archive.org/details/bitsavers_decvaxarch32Jan90_36555387

There are various (partial) collections of DEC standards and related
materials around, including:
https://manx-docs.org/collections/antonio/dec/standards/
http://decdoc.itsx.net/dec94mds/
http://www.mcmanis.com/chuck/computers/vaxen/

> 1. Is there a matrix somewhere that shows which models of VAX have
> which feature, especially the PDP11 compatibility mode.

See DEC Standard 32—also known as DECSTD032—above. That's the
canonical description of a VAX, including describing some
never-released VAX designs.

The VAX-11 series systems have PDP-11 support in hardware. That's the
VAX-11/725, VAX-11/730, VAX-11/750, VAX-11/751, VAX-11/780, VAX-11/782
(ASMP), VAX-11/785, the largely-hypothetical and rarely-seen VAX-11/787
(ASMP), and the VAX-11/790 series that was released as the VAX 8600 and
a later upgrade was known as the VAX 8650 series.

VAX systems after the VAX-11 series do not have PDP-11 hardware
support, and these VAX systems have PDP-11 support via emulation.

The MicroVAX series was the first subset VAX, IIIRC. It had less than
what had been considered the full VAX instruction set. No MicroVAX had
PDP-11 hardware support.

Again, see DECSTD032, above.

> 2. Did any versions of VMS implement software emulation of the PDP11

VAX/VMS or OpenVMS itself? No. The RSX layered product did implement
that. There were some instruction emulations latent in OpenVMS, such
as VVIEF. Again, DECSTD032.

> 3. If you have an old VMS and an old VAX how did you invoke
> compatibility mode? Was there a flag in the file to show it was a PDP11
> executable?

The last of the V3.0 bits that were in compatibility mode included SYE
error formatter tool, and a few other giblets. V4.0 got rid of all of
those, and moved PDP-11 support into the aforementioned layered product.

The Monitor Console Routine command verb MCR was something that I was
working to remove from the OpenVMS documentation set years ago as the
choices there were to either document and support MCR, or to work to
expunge it from the documentation. MCR has some "interesting"
behaviors, too. Removing references to MCR and other related
references from the OpenVMS documentation happened when the particular
OpenVMS manual was "open" for changes, and which wasn't all that
often—if at all—for some of the OpenVMS manuals. Even back then. The
more actively-updated manuals got most (all?) of the references to MCR
expunged. No, there were no plans to remove the MCR command verb
itself. That was to be left latent. Just to deprecate it, save for
anyone that was still using the RSX compatibility mode product, or had
existing uses in their code. And as I've commented before, the OpenVMS
obsolete features manual was itself marked as obsolete. So there have
been no updates made there in many years. And IIRC, the removal of MCR
was after the obsolete-features manual was made obsolete.



--
Pure Personal Opinion | HoffmanLabs LLC

[Jan-Erik Söderholm]

> to remove the MCR command verb itself. That was to be left latent...

I often use the MC command. Nice not to have symbols for all *CP.EXE
programs in SYS$SYSTEM. "MC LATCP SHOW ...", "MC LANCP SHOW ..." and
so on. Used if not daily so at least weekly...

[Stephen Hoffman]

On 2019-08-06 22:53:00 +0000, Jan-Erik S derholm said:

> I often use the MC command. Nice not to have symbols for all *CP.EXE
> programs in SYS$SYSTEM. "MC LATCP SHOW ...", "MC LANCP SHOW ..." and so
> on. Used if not daily so at least weekly...

Automatic foreign commands were to be (are) an approach that avoids MCR
for that sort of thing.

[David Wade]

Ok I will look at that. Meanwhile I found an SPD for VAX-11 RSX

http://h30266.www3.hpe.com/masterindex/spd/spd_0000f67f.txt

which states it uses emulation when compatibility mode is not available.

However the software is not on the distribution CDs I have. I wonder if
it was removed when MEMTEC bought the VAX...

>> 3. If you have an old VMS and an old VAX how did you invoke
>> compatibility mode? Was there a flag in the file to show it was a
>> PDP11 executable?
>
> The last of the V3.0 bits that were in compatibility mode included SYE
> error formatter tool, and a few other giblets.  V4.0 got rid of all of
> those, and moved PDP-11 support into the aforementioned layered product.
>
> The Monitor Console Routine command verb MCR was something that I was
> working to remove from the OpenVMS documentation set years ago as the
> choices there were to either document and support MCR, or to work to
> expunge it from the documentation.  MCR has some "interesting"
> behaviors, too.  Removing references to MCR and other related references
> from the OpenVMS documentation happened when the particular OpenVMS
> manual was "open" for changes, and which wasn't all that often—if at
> all—for some of the OpenVMS manuals.  Even back then.  The more
> actively-updated manuals got most (all?) of the references to MCR
> expunged.  No, there were no plans to remove the MCR command verb
> itself. That was to be left latent.  Just to deprecate it, save for
> anyone that was still using the RSX compatibility mode product, or had
> existing uses in their code.  And as I've commented before, the OpenVMS
> obsolete features manual was itself marked as obsolete. So there have
> been no updates made there in many years. And IIRC, the removal of MCR
> was after the obsolete-features manual was made obsolete.
>
>

yes, its not in help or the 7.3 manuals but it seems to work as
advertised on VMS 7.3 under SIMH VAX emulation...

Dave

[Michael Moroney]

Terry Kennedy <terry-...@glaver.org> writes:

Interesting about the J11. That's where I started, and I knew there were "issues"
but not what they were, other than the original planned 20 MHz clock.

>> IIRC, the models that supported PDP-11 compatibility mode were: 730,
>> 750, 780, 785, 8600.

>All 7xx, 8600/8650 had hardware compatibility mode.

The 7xx series technically included the 8600. It was originally to be the
790.

I don't think the 8650 ever had a 7xx number, unlikely. If it did, I'd guess it
would be the VAX 795.

>Trivia - TECO was not rewritten in VAX assembler, so it carried its own PDP-11
>support (or there was a magic exemption for it in the AME licensing, I
>forget which but think it was the former).

No, there was a VAX TECO32 facility. Perhaps it was ported later, after everything
else was, but at some point it was ported to VAX.

>VSI folks might know if Itanium TECO is on Itanium emulating Alpha emulating
>VAX emulating PDP-11 8-}

The last step is false, the rest true.

Having X86 emulate Itanic emulating Alpha emulating VAX TECO is probably not in the
plans. :-)

[Dave Froble]

Would it not be more reasonable to have something on x86 emulate Alpha?
The VLW stuff on the itanic has got to be rather "foreign".

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

[Tim Sneddon]

Michael Moroney <mor...@world.std.spaamtrap.com> wrote:
> Terry Kennedy <terry-...@glaver.org> writes:
>
> Interesting about the J11. That's where I started, and I knew there were "issues"
> but not what they were, other than the original planned 20 MHz clock.
>
>>> IIRC, the models that supported PDP-11 compatibility mode were: 730,
>>> 750, 780, 785, 8600.
>
>>All 7xx, 8600/8650 had hardware compatibility mode.
>
> The 7xx series technically included the 8600. It was originally to be the
> 790.
>
> I don't think the 8650 ever had a 7xx number, unlikely. If it did, I'd guess it
> would be the VAX 795.
>
>
>>Trivia - TECO was not rewritten in VAX assembler, so it carried its own PDP-11
>>support (or there was a magic exemption for it in the AME licensing, I
>>forget which but think it was the former).
>
> No, there was a VAX TECO32 facility. Perhaps it was ported later, after everything
> else was, but at some point it was ported to VAX.

TECO on VMS was compatability mode, until it was bashed with a hammer until
it became TECO32. Ironically though, this is how TECO-11 was developed, by
bashing TECO-8 with a hammer until it ran on the '11.

>
>>VSI folks might know if Itanium TECO is on Itanium emulating Alpha emulating
>>VAX emulating PDP-11 8-}
>
> The last step is false, the rest true.

TECO on the Alpha is VEST'd (so, VAX emulation on the Alpha). Getting there
though required a number of passes through VEST and there are even comments
in the source to give pointers to the TECO macros that generate the input
files for VEST.

On the Itanium, well...that is an AEST'd image. However, it is obviously
a static translation of the Alpha translation of the VAX image (nasty stuff).

Thankfully other avenues are being investigated for x86. Back to a real
native TECO again :-)

Regards, Tim.

[Stephen Hoffman]

On 2019-08-07 01:31:25 +0000, Dave Froble said:

> Would it not be more reasonable to have something on x86 emulate Alpha?
> The VLW stuff on the itanic has got to be rather "foreign".

It'd probably be most reasonable to start with the existing TECO
rewrite presuming that works well enough, and avoid the layers of
translations.

The original TECO implementation on OpenVMS became a test of the image
translation tools.

Here, maybe use that TECO C rewrite, and contribute back—or fork and
publish—any changes and updates. The rewrite has a permissive license,
by all appearances.
http://almy.us/teco.html

Not sure about the license(s) for the TECO C updates and subsequent
platform ports, though. That'd likely require some discussions with
the folks involved, as I don't see a license listed.
https://github.com/blakemcbride/TECOC

TECO and EDT customizations for an IDE would be a modern expectation,
not that I'd expect that to become available in the near term.

[Dennis Boone]

> Ok I will look at that. Meanwhile I found an SPD for VAX-11 RSX

> http://h30266.www3.hpe.com/masterindex/spd/spd_0000f67f.txt

> which states it uses emulation when compatibility mode is not available.

> However the software is not on the distribution CDs I have. I wonder if
> it was removed when MEMTEC bought the VAX...

It's on the 5.5 CDs:

VAX-11 RSX 2.5 382AA 2 [RSX025]

De

[Dave Froble]

On 8/6/2019 7:35 PM, David Wade wrote:

> when MEMTEC bought the VAX...

Did I miss something? I was not aware that DEC or Compaq sold any parts
of the VAX.

[Bill Gunshannon]

On 8/6/19 7:35 PM, David Wade wrote:
>
>
> However the software is not on the distribution CDs I have. I wonder if
> it was removed when MEMTEC bought the VAX...
>
>

If you actually mean MENTEC, they never had anything to do with the
VAX. The VAX lived and died with Digital.

bill

[Bill Gunshannon]

On 8/7/19 12:04 PM, Dave Froble wrote:
> On 8/6/2019 7:35 PM, David Wade wrote:
>
>> when MEMTEC bought the VAX...
>
> Did I miss something?  I was not aware that DEC or Compaq sold any parts
> of the VAX.
>

They did not.

bill

[David Wade]

On 07/08/2019 17:04, Dave Froble wrote:
> On 8/6/2019 7:35 PM, David Wade wrote:
>
>> when MEMTEC bought the VAX...
>
> Did I miss something?  I was not aware that DEC or Compaq sold any parts
> of the VAX.
>

Sorry Dave. Not enough beer. When Memtec bought PDP-11...

Dave

[Dave Froble]

Uh, who said it died? Got an old MicroVAX 3100 running on the table
here beside me.

:-)

[Bill Gunshannon]

On 8/7/19 4:51 PM, Dave Froble wrote:
> On 8/7/2019 12:26 PM, Bill Gunshannon wrote:
>> On 8/6/19 7:35 PM, David Wade wrote:
>>>
>>>
>>> However the software is not on the distribution CDs I have. I wonder
>>> if it was removed when MEMTEC bought the VAX...
>>>
>>>
>>
>> If you actually mean MENTEC, they never had anything to do with the
>> VAX.  The VAX lived and died with Digital.
>>
>> bill
>>
>
> Uh, who said it died?  Got an old MicroVAX 3100 running on the table
> here beside me.
>
> :-)
>

I have a half dozen of them running VMS, Ultrix and BSD. Doesn't
change the fact that the company that created and owned them has
died, the hardware is unobtanium (except in scrapyards), the OSes
have been on life support for more than a decade (actually, they
have all had the plug onthe life support pulled at this point)
for more than a decade, etc, etc, etc. Time to get a grip on
reality Dave. :-)

bill

[Dave Froble]

All true, but, as long as you're breathing, walking, talking, etc,
you're alive. Dead is when none of those can happen. Would you declare
your children dead, just cause you're too old to produce more?

> Time to get a grip on
> reality Dave. :-)

Why would I ever want to do that? It's no fun. Without the "worlds of
if" things will never progress, get better, etc ....

[Stephen Hoffman]

On 2019-08-07 20:43:58 +0000, David Wade said:

> Sorry Dave. Not enough beer. When Memtec bought PDP-11...

Mentec.

And the associated IP is reportedly now at XX2247.

[Bill Gunshannon]

On 8/8/19 2:11 PM, Stephen Hoffman wrote:
> On 2019-08-07 20:43:58 +0000, David Wade said:
>
>> Sorry Dave. Not enough beer. When Memtec bought PDP-11...
>
> Mentec.
>
> And the associated IP is reportedly now at XX2247.
>
>

And appears to be even deader than it was at Mentec.

bill

[David Wade]

I am pretty sure that is well documented somewhere, so a fact as well as
a personal opinion...

... as for VAX being obsolete that is correct, I would never use one in
new production role, just as I would never have a classic car for
everyday use. I just love the safety features on my Merc., ESP,ABS etc.
In fact I could do with an upgrade to add parking cameras , adaptive
cruise control etc...

Any way I keep the VAXen to take Vintage events like DEC Legacy etc.
They are great fun....

Dave

[Jerry Eckert]

Here is some related trivia I did not see mentioned:

In early versions of VAX/VMS, the DCL file-related commands (e.g., DIR, COPY, RENAME, TYPE) invoked the image BACKTRANS.EXE that converted the DCL command into the equivalent PIP command and then chained to PIP in compatibility mode. BACKTRANS was used in V1 and V2; I don't recall if it was completely eliminated for V3.0.

Before BACKUP was implemented (I don't recall if it was in a late V2 release or in V3), the RSX utilities BCK and DSC (Disk Save and Compress) were used for online and standalone backups, respectively. I was working at the TSC at the time and, believe it or not, there were customers who refused to switch from BCK/DSC to BACKUP.

Jerry

[Jon Pinkley]

On Friday, August 9, 2019 at 9:45:18 AM UTC-4, Jerry Eckert wrote:
> Here is some related trivia I did not see mentioned:
>

> Before BACKUP was implemented (I don't recall if it was in a late V2 release or in V3), the RSX utilities BCK and DSC (Disk Save and Compress) were used for online and standalone backups, respectively. I was working at the TSC at the time and, believe it or not, there were customers who refused to switch from BCK/DSC to BACKUP.
>
> Jerry

It's been so long since I used RSX I am not sure, but I thought the "online backup" utility was BRU (backu/restore utility). I don't remember a BCK, but that was a long time ago. I do remember using DSC on VAX/VMS, but I can't remember if it ever supported ODS2.

[Bob Gezelter]

Jon,

There were several iterations of backup utility.

The original was PRESERV, if I recall.

Then there was DSC (Disk save/compress), and finally BRU (Backup/Restore Utility). BRU could work with individual files.

If I recall correctly, DSC2 was the original VAX utility, working on a volume basis. BACKUP appeared later.

[Jon Pinkley]

Bob,

You have a good memory. Found this about Disk Save and Compress Utility.

http://vaxhaven.com/images/2/26/AA-D739A-TE.pdf

There were two DSC programs, DSC1 (for ODS-1 disks) and the more often used DSC2 for ODS-2 disks. I remember booting the standalone DSC and backing up RP06 drives to a TU77 tape drive in 1980. I don't miss having to do that.

Things were much better after the BACKUP utility stabilized and we got a TU78.

I am reasonably sure that BACKUP was released in the with V3 or one of the V3 realeaes.

I first logged into a VAX in June of 1980, and I think it was V1.3 and we upgraded to V2 during the year end holidays.

Jon