[Simh] RT-11 Storage Strategy

[Will Senn]

All,

The array of simulated disks available to simh is a little confusing to 
wade through. I tend to use RL02 and RK05, but really, I don't have a 
solid rationale for one over the other. In RT-11 these are available 
when attached, so their what I use. I'm hoping someone can offer some 
more informed storage advice/strategy.


Here are some questions to get the juices flowing:

In SimH with a PDP-11 running RT-11:

* Is there a preferred disk controller/device?
* Is there a controller that supports more disk devices than another (RL 
vs RK, etc)?
* Does one device have more capacity than another (either via single 
disk raw capacity or via overall capacity of attached units)?

* Is one device/controller more reliable in SimH than another?
* Do disks need to be formatted before initializing?
* Are there some known best practice configurations (so many RL 
controller, with so many drives, or so many RL and so many RK, etc.)?


Here's where I'm coming from as background. I have been studying 
Macro-11 programming in RT-11. I save all of my files on a storage disk 
that is separate from the SY: volume (DK:, etc.). I have found working 
Pascal, BASIC, and FORTRAN distributions that can be installed. Rather 
than installing them into SY:, It seems reasonable to attach a disk, 
assign the disk a logical name, and copy each distribution onto its own 
vol, something along the lines of SY:, PAS:, BAS:, FOR:, and MAC:, with 
5 disks attached. But, before I headed down this road, I thought I would 
get some advice.


Thanks for reading and thanks in advance for responding with your sage 
advice :).


Regards,

Will
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 145, Issue 52

[Mark Pizzolato]

On Tuesday, February 16, 2016 at 10:51 AM Johnny Billquist wrote:
> On 2016-02-16 17:54, li...@openmailbox.org wrote:
> > On Tue, 16 Feb 2016 17:49:27 +0100
> > Johnny Billquist  wrote:
> >
> >> On 2016-02-16 17:43, li...@openmailbox.org wrote:
> >> For a lot of embedded, low power stuff, it would have made more sense
> >> to use PDP-11s. But DEC had those chips as well, and was somewhat
> >> unwilling in that market too. Imagine if they had tries to really
> >> push for getting PDP-11s out there in all kind of devices, and made
> >> one or two more implementations to shrink and reduce power... That
> could have been nice.
> >
> > You're just saying that because you want to run an RSX-based
> > smartphone ;-)
> 
> Of course, that would be nice. :-)

Well, of course an RSX-based smartphone isn't going to happen, BUT
with an Android based phone you could run a simh PDP11 simulator 
running RSX and likely have it talk to the internet via your (Johnny's)
TCP/IP package.  I haven’t tried to build using the Android cross 
development tools for a couple of years, but the github makefile 
worked fine the last time I tried.  :-)

- Mark
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] License File

[Bill Cunningham]

  - Original Message - 
  From: Robert Thomas
  To: simh@trailing-edge.com
  Sent: Tuesday, February 16, 2016 5:40 PM
  Subject: Re: [Simh] License File


  Rather than fight file transfers prior to installing licenses, use the 
following command:

  $ @SYS$UPDATE:VMSLICENSE

  The command procedure will guide one through the license data entry in the 
order and format as on the hardcopy license.

  The format for a command file is as below.  The various options will 
differ based on the type of license.

  $ LICENSE REGISTER xx -
  /ISSUER=yyy -
  /AUTHORIZATION=zz -
  /PRODUCER= -
  /UNITS= -
  /OPTIONS=(cc) -
  /CHECKSUM=ddd
  $ LICENSE LOADxxx/LOG/PRODUCER=aa
  $!
  $ exit
  $!
  $! [End of File]

  The thing is I always get down to the checksum and enter it correctly and 
get an error that something isn't typed right. With every PAK I've tried so 
far. My hobbyist ID number is always the same, bu the checksum is always 
different.

  [...]
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Clement T. Cole]

Depends on how you look at it,  AMD did developed an early 64 bit extensions on 
to the 32 bit ISA. But that was over 10 years ago and I was not there at the 
time.   IMO thankfully when Core/INTEL*64 was developed much of it made to be 
the same in the desire to keep user binaries to run.   Since that time Intel 
has taken and continues to extend the ISA. Simply put, INTEL*64 is different - 
there are whole sections of the ISA that are not implemented on all processors 
(even at Intel). For instance Intel's Phi brings in a number of new 
instructions.  INTEL*64 is the official name (trademark name) for the ISA 
(although some folks refuse to acknowledge that fact). 

Also in the case of privileged ISA features there are some significant 
difference which the OS's have to handle.  For instance the VT subsystems have 
some differences.

As Tim points out the real cost of compatibly is the architectural tests suites 
and effort to ensure that things just work across the board.  In the case of 
x86 it's even more difficult then just the instructions and BIOS because it 
means whole HW sections have to be made virtual also so that old code (like 
ones for DOS) do keep working.  

Similarly, Regardless of which Intel produced processor for that ISA is the 
output target,
Intel's compilers generate code for the INTEL*64 ISA and perform optimization 
for same.  When user mode binaries are run on non-intel manufactured processors 
they should "just work" if the others manufactures have implemented equivalent 
functionality (There is no truth to the sometimes stated comment that Intel's 
compilers check for non-intel manufactured and do bad things).  That said the 
Intel development suite does not do specific optimizations for non intel 
manufactured processors but they do make an attempt to ensure things execute 
correctly. 

The neutral term is x86_64 which does not acknowledge either AMD or Intel.  But 
in print, I am fairly certain that the ISA's trademarked name is INTEL*64 when 
referring to that ISA.  

Sent from my iPad

> On Feb 16, 2016, at 5:02 PM, Rhialto  wrote:
> 
>> On Tue 16 Feb 2016 at 11:25:37 -0500, Clem Cole wrote:
>> Unless you are using a cell phone, I'm willing to bet that you are typing
>> your messages on a INTEL*64 architecture system, even if the processor is
>> not made by Intel.
> 
> Was the 64-bit mode not designed by AMD? I'm typing this on NetBSD/amd64
> after all...
> 
> -Olaf.
> -- 
> ___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
> \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] License File

[Robert Thomas]

Rather than fight file transfers prior to installing licenses, use the 
following command:

$ @SYS$UPDATE:VMSLICENSE

The command procedure will guide one through the license data entry in the 
order and format as on the hardcopy license.

The format for a command file is as below.  The various options will differ 
based on the type of license.

$ LICENSE REGISTER xx - 
/ISSUER=yyy - 
/AUTHORIZATION=zz - 
/PRODUCER= - 
/UNITS= -  
/OPTIONS=(cc) - 
/CHECKSUM=ddd
$ LICENSE LOADxxx/LOG/PRODUCER=aa
$!
$ exit
$!
$! [End of File]

VMS attempts to "strong type" files, i.e. it has many supported formats and one 
must ensure that the file being used corresponds to a viable format.  It is not 
unusual for a file to have  but not the proper attributes.  The method 
for correcting such is VMS version specific, in that the earlier versions used 
different command/utilities to modify the file header for the various possible 
file formats.  The VMS file system is not PC or Unix compatible.

Typing DIR/FULL  will show the major file attributes.

The bulk of the VMS documentation is available online from HP.

Sincerely,
Robert F. Thomas

 44 Industrial Way 
Norwood, MA USA 02062
N  Office Phone - (781) 329-9200
O mail to: r...@asthomas.com
 


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] license error

[Bill Cunningham]

I successfully copied the license to vms as lic.com. Then a typed 
@lic.com. This is a logged result by simh. cut a bit.


 $ @lic.com

%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first character
%DCL-W-NOCOMD, no command on line - reenter with alphabetic first 

Re: [Simh] VAX/VMS

[Rhialto]

On Tue 16 Feb 2016 at 15:56:05 -0500, Paul Koning wrote:
> Amazing.  974 pages, 131 claims.  And yes, a long listing of
> microcode.  And flow charts.  And schematics.  It clearly is a 360.

I leafed through the American version, and the UK one is twice the size!
It even includes a binary microcode dump with comments (or maybe it's a
listing from a microcode assembler). The flowcharts are "more readable"
though.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 145, Issue 52

[khandy21yo]

Like a RSTS watch?





 Original message 
From li...@openmailbox.org 
Date: 02/16/2016  9:54 AM  (GMT-07:00) 
To simh@trailing-edge.com 
Subject Re: [Simh] Simh Digest, Vol 145, Issue 52 
 
On Tue, 16 Feb 2016 17:49:27 +0100
Johnny Billquist  wrote:

> On 2016-02-16 17:43, li...@openmailbox.org wrote:
> > On Tue, 16 Feb 2016 11:40:09 -0500
> > William Pechter  wrote:
> >
> >> Actually, one of DEC's biggest mistakes was not OEMing the uVax
> >> chips... They would've killed the 68k had they had the uVaxII chipset
> >> available for early workstations.
> >
> > I'm not so sure about that. The 68k was used in an awful lot of devices
> > from handhelds (Palm) to TI calculators and a whole lot more than
> > workstations. Could handheld devices in that day run microVax chips?
> 
> For a lot of embedded, low power stuff, it would have made more sense to 
> use PDP-11s. But DEC had those chips as well, and was somewhat unwilling 
> in that market too. Imagine if they had tries to really push for getting 
> PDP-11s out there in all kind of devices, and made one or two more 
> implementations to shrink and reduce power... That could have been nice.

You're just saying that because you want to run an RSX-based smartphone ;-)

In all seriousness with today's FPGAs and microcontrollers you can probably
make just about any battery-powered device you could think up.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Rhialto]

On Tue 16 Feb 2016 at 11:25:37 -0500, Clem Cole wrote:
> Unless you are using a cell phone, I'm willing to bet that you are typing
> your messages on a INTEL*64 architecture system, even if the processor is
> not made by Intel.

Was the 64-bit mode not designed by AMD? I'm typing this on NetBSD/amd64
after all...

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] What is CDC OS?

[Paul Koning]

> On Feb 16, 2016, at 4:04 PM, Nelson H. F. Beebe  wrote:
> 
> Will Senn  asks on the list on Tue, 16 Feb 2016
> 12:47:12 -0600 about CDC operating systems.
> 
> I worked quite happily on a CDC 6400 from 1973 to 1977.  Initially, we
> had the SCOPE operating system, and later, KRONOS.  
> ...
> The interactive features of the CDC 6400 had a huge beneficial impact
> on my software productivity, compared to my previous batch
> environment, and I regret that I have yet to find a CDC [67]x00
> simulator with either SCOPE or Kronos.  I have one that boots up to
> ROM level, but cannot get further with it.

DtCyber is a full 6000 series emulator that runs pretty much all the 6000 
series 60 bit software (including nearly all diagnostics).  It doesn't emulate 
the 7600; I haven't seen anything that does.  Nor does it emulate the 64 bit 
mode of the later machines.  There is a mailing list ("controlfreaks") for 
working on/with that.  Due to licensing limitation it isn't world-readable but 
if you're interested, ask to join.

There's a PLATO system on-line (see www.cyber1.org) running in emulation on 
DtCyber, using NOS 2.8.7 as the underlying OS.  (Not that PLATO makes much use 
of the OS services... it's barely more than a program loader as far as it's 
concerned.)

> The CDC machines had a small instruction set (64 different opcodes).
> All integer arithmetic was done with floating-point instructions,

Not quite.  Mul and div, yes.  But there are separate full 60 bit integer add 
and subtract ("long add") instructions.

> ...
> The address space was 2**18 = 262_144 words, and each process had a
> contiguous block.  

17 bits in the 6000 series (18 bits in the 170 series).

> The CDC [67]x00 family CPUs have no interrupts: instead, there are
> several peripheral processors (PP's) that interface to external
> devices such as disks and serial terminal lines.  The PP's are 12-bit
> computers, each with 4096 words of memory. They communicate with the
> main CPU by monitoring a couple of privileged memory locations that
> hold data for a device operation.  At our site, the PPs were never
> accessible to end users, so no one outside the computer center ever
> knew their instruction set.

The PPs have a way to interrupt the CPU, or more precisely, to do a context 
switch.  It feels a bit like the VAX instructions to save and load process 
context, except that the whole job is done in one instruction, not two.  And 
that instruction is blindingly fast: the whole operation runs at memory speed, 
100 ns per word (thanks to interleaving) so a process switch would take about 3 
to 4 microseconds.

> Niklaus Wirth and Urs Ammann have interesting, and sometimes negative,
> comments about the CDC 6600 on which they developed the first Pascal
> implementation.  Like Fortran and the IBM 709, and C and the DEC
> PDP-11, the Pascal language also contains several influences of the
> CDC 6600 architecture, although Wirth tried as much as possible to
> hide the hardware from the programmer.

I don't think Dijkstra liked it much either.  One of them objected to the weird 
floating point rounding, which (according to what they said, I haven't checked) 
rounds at 1/3rd rather than the proper 1/2 LSB.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] What is CDC OS?

[Timothe Litt]

On 16-Feb-16 16:04, Nelson H. F. Beebe wrote:
> Will Senn  asks on the list on Tue, 16 Feb 2016
> 12:47:12 -0600 about CDC operating systems.
>
>
> The CDC [67]x00 family CPUs have no interrupts: instead, there are
> several peripheral processors (PP's) that interface to external
> devices such as disks and serial terminal lines.  The PP's are 12-bit
> computers, each with 4096 words of memory. They communicate with the
> main CPU by monitoring a couple of privileged memory locations that
> hold data for a device operation.  At our site, the PPs were never
> accessible to end users, so no one outside the computer center ever
> knew their instruction set.
>
>
http://ygdes.com/CDC/60141900_Codes_Rev-A_May65.pdf



smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] What is CDC OS?

[Nelson H. F. Beebe]

Will Senn  asks on the list on Tue, 16 Feb 2016
12:47:12 -0600 about CDC operating systems.

I worked quite happily on a CDC 6400 from 1973 to 1977.  Initially, we
had the SCOPE operating system, and later, KRONOS.  The latter was,
from our viewpoint, a step back, because it had a flat file system
that in our case had to serve our entire campus.  As a result, we had
to adopt prefixes that encoded the department name and user name on
all filenames.

For its time, the CDC 6400 (and its bigger brothers, the 6600 and
7600) was quite fast.  It had interactive access, and a Unix-top-like
process display that you could run without logging in.

My previous machines were IBM and Amdahl mainframes that were only
accessible with batch jobs submitted on punched cards: for a long
time, users at that university were forbidden from storing files on
disks.  We solved that in our research group by renting our own IBM
2311 disk drive, and buying eventually a dozen or so removable disks.
According to Wikipedia,


https://en.wikipedia.org/wiki/History_of_IBM_magnetic_disk_drives#IBM_2311

those disks with six LP-record-sized platters held about 7MB.  I did
hundreds of mounts of those disks myself.

The interactive features of the CDC 6400 had a huge beneficial impact
on my software productivity, compared to my previous batch
environment, and I regret that I have yet to find a CDC [67]x00
simulator with either SCOPE or Kronos.  I have one that boots up to
ROM level, but cannot get further with it.

The CDC machines had a small instruction set (64 different opcodes).
All integer arithmetic was done with floating-point instructions,
which offered both rounding and truncating modes.  The
integer-to-float-to-integer conversion meant that integers were
effectively limited to 48 bits of data stored in a 60-bit word.  There
were 18-bit An and Bn (n = 0..7) registers, and associated 60-bit Xn
registers.  A0 and X0 were scratch registers.  Loading an address into
A1 through A5 loaded a word from that memory word address into X1
through X5.  Putting an address in A6 or A7 stored the word in X6 or
X7.  All instruction mnemonics have hard-coded register names, so
there was no reasonable possibility of a macro language that could
usefully give symbolic names to registers.

The CDC floating-point arithmetic had both Indefinite and Infinity:
they were the inspiration for NaN and Infinity in IEEE 754 arithmetic
on almost all new post-1985 machine designs.

One nice feature of Indefinite was that with a job-control statement
immediately before your job, you could initialize all memory words to
Indefinite, with the word's address in the lower 18 bits.  Then, if
you accidentally used an uninitialized variable, you got a
floating-point exception, and the traceback showed where it came from,
and thus, which variable was unset.  We used that feature heavily, and
only a few modern systems provide something similar.

The address space was 2**18 = 262_144 words, and each process had a
contiguous block.  All physical addresses were computed dynamically
from the sum of a job base address and a relative-to-0 address, so the
O/S could slide entire jobs around in memory to achieve optimal
packing.  You could, and we did, adjust the process upper bound
dynamically during execution to free core memory for others.

The CDC [67]x00 family CPUs have no interrupts: instead, there are
several peripheral processors (PP's) that interface to external
devices such as disks and serial terminal lines.  The PP's are 12-bit
computers, each with 4096 words of memory. They communicate with the
main CPU by monitoring a couple of privileged memory locations that
hold data for a device operation.  At our site, the PPs were never
accessible to end users, so no one outside the computer center ever
knew their instruction set.

Niklaus Wirth and Urs Ammann have interesting, and sometimes negative,
comments about the CDC 6600 on which they developed the first Pascal
implementation.  Like Fortran and the IBM 709, and C and the DEC
PDP-11, the Pascal language also contains several influences of the
CDC 6600 architecture, although Wirth tried as much as possible to
hide the hardware from the programmer.

Here are some literature references about those machines, and early
Pascal:

papers: James E. Thornton
The CDC 6600 Project
http://dx.doi.org/10.1109/MAHC.1980.10044

Niklaus Wirth
The Design of a PASCAL Compiler
http://dx.doi.org/10.1002/spe.4380010403

Urs Ammann
On Code Generation in a PASCAL Compiler
http://dx.doi.org/10.1002/spe.4380070311

book:   James E. Thornton
Design of a Computer: the Control Data 6600
Scott, Foresman (1970)
LCCN TK7889.C6 T5 1970

Thornton was part of the 6600 architecture team.

---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- 

Re: [Simh] VAX/VMS

[Paul Koning]

> On Feb 16, 2016, at 2:58 PM, Rhialto  wrote:
> 
> On Tue 16 Feb 2016 at 08:58:11 -0500, Clem Cole wrote:
>> Dave be careful --   S/360 Model 67 has VM in the late 1960's - TSS and
>> it's brother MTS, both rely on it.   The 67 is a Model 65 with a  Data
>> Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which
>> is in a cabinet that t'ed off the main CPU and is about the same size en
>> entire Vax 780 which would follow 10 years later.
> 
> Note that I have rescued at some point in the past an IBM patent (it was
> the UK version) of a computer with microcode, and maybe Virtual Memory
> too. Although they didn't call it that I think. After reading, it
> described something remarkably like the S/360. It lists the full
> microcode and has extensive hardware schematics.
> 
> The patent number is 1,108,800. Inventors: Gene Myron Amdahl et al.
> USA patent application number 357372, 6 April 1964. The issued patent
> number is US003400371.

Amazing.  974 pages, 131 claims.  And yes, a long listing of microcode.  And 
flow charts.  And schematics.  It clearly is a 360.

paul

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Dave Wade]

> -Original Message-
> From: Rhialto [mailto:rhia...@falu.nl]
> Sent: 16 February 2016 19:58
> To: Clem Cole 
> Cc: Dave Wade ; SIMH 
> Subject: Re: [Simh] VAX/VMS
> 
> On Tue 16 Feb 2016 at 08:58:11 -0500, Clem Cole wrote:
> > Dave be careful --   S/360 Model 67 has VM in the late 1960's - TSS and
> > it's brother MTS, both rely on it.   The 67 is a Model 65 with a  Data
> > Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB
> > which is in a cabinet that t'ed off the main CPU and is about the same
> > size en entire Vax 780 which would follow 10 years later.
> 
> Note that I have rescued at some point in the past an IBM patent (it was
the
> UK version) of a computer with microcode, and maybe Virtual Memory too.
> Although they didn't call it that I think. After reading, it described
something

Perhaps relocation. Allows code to run from any start address. Also storage
keys which allow memory to be protected. 
Virtual Memory was first patented by Manchester University and implemented
in Atlas. I believe IBM later acquired this patent.

There are many later patents for virtual memory improvements.

> remarkably like the S/360. It lists the full microcode and has extensive
> hardware schematics.
> 
> The patent number is 1,108,800. Inventors: Gene Myron Amdahl et al.
> USA patent application number 357372, 6 April 1964. The issued patent
> number is US003400371.
> 

I believe that Amdahl (as a company) also came up with the patent for a
control processor
... so IBM paid them for every mainframe with a control processor, and
Amdahl paid IBM for the Virtual Memory Patents...

> -Olaf.
> --
> ___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
> \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'

Dave
G4UGM

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Rhialto]

On Tue 16 Feb 2016 at 08:58:11 -0500, Clem Cole wrote:
> Dave be careful --   S/360 Model 67 has VM in the late 1960's - TSS and
> it's brother MTS, both rely on it.   The 67 is a Model 65 with a  Data
> Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which
> is in a cabinet that t'ed off the main CPU and is about the same size en
> entire Vax 780 which would follow 10 years later.

Note that I have rescued at some point in the past an IBM patent (it was
the UK version) of a computer with microcode, and maybe Virtual Memory
too. Although they didn't call it that I think. After reading, it
described something remarkably like the S/360. It lists the full
microcode and has extensive hardware schematics.

The patent number is 1,108,800. Inventors: Gene Myron Amdahl et al.
USA patent application number 357372, 6 April 1964. The issued patent
number is US003400371.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'


signature.asc
Description: PGP signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] DBG-11 on RT-11

[Will Senn]

All,

Does anyone know where the bits for DBG-11 for RT-11 v5+ reside? I found 
an ancient post on alt.sys.pdp11 referring to an extant version Y01.16.


If I understand the docs correctly, the files that represent the 
debugger are:


SDH.SYS, SDS.SYS, SDHX.SYS, or SDSX.SYS

There's some discussion about mapped/unmapped monitors. I use the XM 
monitor, but can also run FB or SJ as needed.


Thanks,

Will
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] What is CDC OS?

[Will Senn]

Thanks Clem and I agree with Bill's quip - greatness.

On 2/16/16 1:01 PM, Clem Cole wrote:


On Tue, Feb 16, 2016 at 1:49 PM, Clem Cole > wrote:


However, the book has some programs that claim to take advantage
of the CDC OS and utilize a card reader.

​Yup, IMO, part of why Pascal I/O was dorked was because he used the 
read/write semantics of the CDC systems.   It very screwy and simple 
in nature.  Don't expect much.


It's been a while since I used them, but my memory is that the Kronos, 
NOS and SCOPE all used the same semantics for batch programs.   I 
never ran COS or MACE.


I still know a couple of folks that might remember - Tektronix had two 
CDC systems (1) and I one of my old colleagues from those days that 
was a programmer for the CDC Center(2), I'm working with again.  If 
you have specific questions send them to me off list and I'll see if I 
can get you in contact.


Clem

1) As I have mentioned I helped to write the original IP/TCP 
implementation for VMS, besides our 11/70 running Unix.  The other 
side of that link was these CDC systems.


2) In one of my favorite all time quotes that I wish I had said.  Bill 
Price who had been one of the B5000 designers and was then working 
with us in Tek Labs when the Tek CDC team was renamed from the 
"Scientific Computer Center" to the "Computer Science Center".  Bill 
hears this and quips:  "That's like calling a strip mine and 
archeology dig."


​




___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] What is CDC OS?

[Clem Cole]

On Tue, Feb 16, 2016 at 1:49 PM, Clem Cole  wrote:

> However, the book has some programs that claim to take advantage of the
> CDC OS and utilize a card reader.

​Yup, IMO, part of why Pascal I/O was dorked was because he used the
read/write semantics of the CDC systems.   It very screwy and simple in
nature.  Don't expect much.

It's been a while since I used them, but my memory is that the Kronos, NOS
and SCOPE all used the same semantics for batch programs.   I never ran COS
or MACE.

I still know a couple of folks that might remember - Tektronix had two CDC
systems (1) and I one of my old colleagues from those days that was a
programmer for the CDC Center(2), I'm working with again.  If you have
specific questions send them to me off list and I'll see if I can get you
in contact.

Clem

1) As I have mentioned I helped to write the original IP/TCP implementation
for VMS, besides our 11/70 running Unix.  The other side of that link was
these CDC systems.

2) In one of my favorite all time quotes that I wish I had said.  Bill
Price who had been one of the B5000 designers and was then working with us
in Tek Labs when the Tek CDC team was renamed from the "Scientific Computer
Center" to the "Computer Science Center".  Bill hears this and quips:
 "That's like calling a strip mine and archeology dig."

​
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] What is CDC OS?

[Clem Cole]

below

On Tue, Feb 16, 2016 at 1:47 PM, Will Senn  wrote:

> Hi,
>
> I'm reading a book (among many such books) that is entitled, "A Primer on
> PASCAL," by Richard Conway, David Gries, and E. C. Zimmerman, written in
> 1976 with a Foreward by Niklaus Wirth. The book has a lot of PASCAL
> examples that run just fine on my PDP-11/70 with RT-11 or RSX-11, or... you
> get the idea. However, the book has some programs that claim to take
> advantage of the CDC OS and utilize a card reader. The author refers to the
> operating system as "The CDC OS" as if it were singular and obvious, but
> doesn't speak of hardware beyond the card reader. I looked and found
> references to Control Data Corporation's COS, SCOPE, MACE, KRONOS,  and
> NOS, but have no idea if these are "The CDC OS"...
>
​Yup and they have a N different code sets -- its a real mess.​



>
> Does anyone know what "The CDC OS" would refer to and what hardware it
> would run on (hopefully simulated).
>
​IIRC, Cyber 72 running NOS, I believe was what he used.​
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] What is CDC OS?

[Will Senn]

Hi,

I'm reading a book (among many such books) that is entitled, "A Primer 
on PASCAL," by Richard Conway, David Gries, and E. C. Zimmerman, written 
in 1976 with a Foreward by Niklaus Wirth. The book has a lot of PASCAL 
examples that run just fine on my PDP-11/70 with RT-11 or RSX-11, or... 
you get the idea. However, the book has some programs that claim to take 
advantage of the CDC OS and utilize a card reader. The author refers to 
the operating system as "The CDC OS" as if it were singular and obvious, 
but doesn't speak of hardware beyond the card reader. I looked and found 
references to Control Data Corporation's COS, SCOPE, MACE, KRONOS,  and 
NOS, but have no idea if these are "The CDC OS"...


Does anyone know what "The CDC OS" would refer to and what hardware it 
would run on (hopefully simulated).


Regards,

Will
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Timothe Litt]

On 16-Feb-16 12:12, li...@openmailbox.org wrote:
> On Tue, 16 Feb 2016 11:52:17 -0500
> Paul Koning  wrote:
>
>>> On Feb 16, 2016, at 9:56 AM, Timothe Litt  wrote:
>>>
>>> ...
>>> Nonetheless, Brooks (@IBM) definitely gets credit for the first
>>> commercial line of architecturally (forward) compatible machines.  Prior
>>> to that inspiration, every new machine was unique and most software
>>> started over (including compilers).
>> I'm not sure that "first" is accurate.  If in the sense of a series of
>> machines for which that feature is specifically marketed, perhaps.  But
>> the PDP4/7/9/15 is another example that started somewhat earlier.  (PDP1
>> doesn't quite match, as I understand it.)  CDC 6000 series definitely
>> fits your definition, and those came out at the same time as the 360.
>> The Burroughs B5000 series is somewhat older (1961, says Wikipedia).
> More correctly we should say the IBM S/360 was the first series of
> computers to be designed around an architecture so that the smallest and
> largest models in the lineup were all architecturally identical (mostly!)
> and that could all run the same OS (mostly). The upward compatibility came
> later, but was enabled by a lot of sound architecture decisions including
> one design regardless of capacity.
>
>> Of all those, the IBM 360 descendants are perhaps the most commercially
>> successful, and also probably the longest lived.
> Not perhaps or probably, but certainly.
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
If you're going to use a generic address like "li...@openmailbox.org",
please add a
name comment (e.g. "Fred Brooks" ) and/or a
signature.

Everyone else makes it clear who they are

Thanks.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[lists]

On Tue, 16 Feb 2016 11:52:17 -0500
Paul Koning  wrote:

> 
> > On Feb 16, 2016, at 9:56 AM, Timothe Litt  wrote:
> > 
> > ...
> > Nonetheless, Brooks (@IBM) definitely gets credit for the first
> > commercial line of architecturally (forward) compatible machines.  Prior
> > to that inspiration, every new machine was unique and most software
> > started over (including compilers).
> 
> I'm not sure that "first" is accurate.  If in the sense of a series of
> machines for which that feature is specifically marketed, perhaps.  But
> the PDP4/7/9/15 is another example that started somewhat earlier.  (PDP1
> doesn't quite match, as I understand it.)  CDC 6000 series definitely
> fits your definition, and those came out at the same time as the 360.
> The Burroughs B5000 series is somewhat older (1961, says Wikipedia).

More correctly we should say the IBM S/360 was the first series of
computers to be designed around an architecture so that the smallest and
largest models in the lineup were all architecturally identical (mostly!)
and that could all run the same OS (mostly). The upward compatibility came
later, but was enabled by a lot of sound architecture decisions including
one design regardless of capacity.

> Of all those, the IBM 360 descendants are perhaps the most commercially
> successful, and also probably the longest lived.

Not perhaps or probably, but certainly.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 145, Issue 52

[Paul Koning]

> On Feb 16, 2016, at 11:49 AM, Johnny Billquist  wrote:
> 
> On 2016-02-16 17:43, li...@openmailbox.org wrote:
>> On Tue, 16 Feb 2016 11:40:09 -0500
>> William Pechter  wrote:
>> 
>>> Actually, one of DEC's biggest mistakes was not OEMing the uVax chips...
>>> They would've killed the 68k had they had the uVaxII chipset
>>> available for early workstations.
>> 
>> I'm not so sure about that. The 68k was used in an awful lot of devices
>> from handhelds (Palm) to TI calculators and a whole lot more than
>> workstations. Could handheld devices in that day run microVax chips?
> 
> For a lot of embedded, low power stuff, it would have made more sense to use 
> PDP-11s. But DEC had those chips as well, and was somewhat unwilling in that 
> market too. Imagine if they had tries to really push for getting PDP-11s out 
> there in all kind of devices, and made one or two more implementations to 
> shrink and reduce power... That could have been nice.

One complication was that, until around the 3rd generation Ethernet chip, DEC's 
inhouse chip business made chips that cost much, much more than anyone else's.  
There's a reason the networking products stuck to LANCE chips for quite some 
time.  I think it was the TGEC ("third generation Ethernet chip") that finally 
became cost-competitive (as well as being functionally superior to every 
alternative).

DEC got very seriously into low power with the StrongARM (SA110) chip, but that 
was much later.  It was quite amazing, though; I don't remember how much lower 
power per MHz than every other processor out there, but it was quite 
significant and set the stage for the lower power processor technology that 
enabled smartphones.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Paul Koning]

> On Feb 16, 2016, at 9:56 AM, Timothe Litt  wrote:
> 
> ...
> Nonetheless, Brooks (@IBM) definitely gets credit for the first
> commercial line of architecturally (forward) compatible machines.  Prior
> to that inspiration, every new machine was unique and most software
> started over (including compilers).

I'm not sure that "first" is accurate.  If in the sense of a series of machines 
for which that feature is specifically marketed, perhaps.  But the PDP4/7/9/15 
is another example that started somewhat earlier.  (PDP1 doesn't quite match, 
as I understand it.)  CDC 6000 series definitely fits your definition, and 
those came out at the same time as the 360.  The Burroughs B5000 series is 
somewhat older (1961, says Wikipedia).

Not as well known and perhaps not quite close enough to be called "forward 
compatible" are the Electrologica EL-X1 (1958) and EL-X8 (1964), with more 
planned but not shipped before the company was bought & closed down.

Of all those, the IBM 360 descendants are perhaps the most commercially 
successful, and also probably the longest lived.

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 145, Issue 52

[Johnny Billquist]

On 2016-02-16 17:43, li...@openmailbox.org wrote:

On Tue, 16 Feb 2016 11:40:09 -0500
William Pechter  wrote:


Actually, one of DEC's biggest mistakes was not OEMing the uVax chips...
They would've killed the 68k had they had the uVaxII chipset
available for early workstations.


I'm not so sure about that. The 68k was used in an awful lot of devices
from handhelds (Palm) to TI calculators and a whole lot more than
workstations. Could handheld devices in that day run microVax chips?


For a lot of embedded, low power stuff, it would have made more sense to 
use PDP-11s. But DEC had those chips as well, and was somewhat unwilling 
in that market too. Imagine if they had tries to really push for getting 
PDP-11s out there in all kind of devices, and made one or two more 
implementations to shrink and reduce power... That could have been nice.


Johnny


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Simh Digest, Vol 145, Issue 52

[William Pechter]

simh-requ...@trailing-edge.com wrote:
> Send Simh mailing list submissions to
>   simh@trailing-edge.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://mailman.trailing-edge.com/mailman/listinfo/simh
> or, via email, send a message with subject or body 'help' to
>   simh-requ...@trailing-edge.com
>
> You can reach the person managing the list at
>   simh-ow...@trailing-edge.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Simh digest..."
>
>
> Today's Topics:
>
>1. Re:  VAX/VMS (Timothe Litt)
>
>
> --
>
> Message: 1
> Date: Tue, 16 Feb 2016 10:23:12 -0500
> From: Timothe Litt 
> To: simh@trailing-edge.com
> Subject: Re: [Simh] VAX/VMS
> Message-ID: <56c33ee0.3070...@ieee.org>
> Content-Type: text/plain; charset="utf-8"
>
> On 16-Feb-16 10:16, Dave Wade wrote:
>> I
>>
>>
>> I think it is also interesting to compare the Intel architecture which
>> was designed to be economical with Silicon against the M6800, M6809
>> and the M68000 which were designed to be programmer friendly, and of
>> course note the similarities between the 68000 & S/360 with 16 general
>> purpose registers and orthogonal instruction set) and wonder where we
>> would be today had IBM chosen them for its PC rather than the 8086
>> which I assume was cheaper…
>>
>>
> I worked with IBM in Boca Raton at one point.  This is where the IBM PC
> was developed, and I talked with some of the originators.
>
> They told me that they considered the 8086, the 68000 & the T11 for the
> PC.  They really, really wanted the -11.  IBM had the largest population
> of -11 programmers in the world at one time.  They used the 11 for
> manufacturing and real-time.  There was a huge amount of software.  But
> DEC wouldn't sell the -11 to them.  So they went for price and that deal
> with Gates to write DOS.  Neither was supposed to last...
>
Boy -- that could've been a saving thing for DEC in '86 or so.   A lot
of $$$ for chip sales and maybe IBM second sourcing the T11.

Actually, one of DEC's biggest mistakes was not OEMing the uVax chips...
They would've killed the 68k had they had the uVaxII chipset
available for early workstations. 

That revenue could've given them the cash they needed to push the Alpha
and 64 bit computing.


Bill

-- 
Digital had it then.  Don't you wish you could buy it now!
pechter-at-gmail.com  http://xkcd.com/705/

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Johnny Billquist]

On 2016-02-16 17:25, Clem Cole wrote:


On Tue, Feb 16, 2016 at 10:54 AM, > wrote:

Every new IBM machine and OS was designed to preserve the investment
in all
​ ​
the software and development skills the customer already had. In
terms of
​ ​
architectural and implementation purity with compatability as a
fundamental
principle and a 52 year track record of success, IBM wrote the book.


​I agree, but I suggest that you don't sell Intel short.  To be honest,
I used to think the folks @ Intel had to be brain dead until I thought
it about and looked more carefully.  Once I started to work for them, I
really understood.   They deal with with an ugly architecture, but they
make the best of it for their customers.

You are right Intel killed compatibility many times between lots of
different impure attempts ( 432, ​
​all of their RISC systems etc...), but to Intel's credit - they always
did a good enough job on compatibility in the
4004-8080-8086-80386-INTEL*64 transitions to move the customers programs
over somehow (again you are right, sometimes easier than others)​.

But the trick is that economics of the Intel family, along with
compatibility - drove the price of computing down. And Intel was
compatible enough to have people keep doing it.  The fact is you can
still boot and old copy of DOS and the programs will run.

As was brought up in this thread, if you take the last VAX made it will
not boot VMS 1.x and I suspect it will not even run user code compiled
for it for any really sophisticated user code.


More over before DOS, Intel (while hardly perfect) did manage to bring
8080 programs to 8086 systems (and 4004 to 8008 and 8008 to 8080).
Yes, IBM and DEC did it better than Intel did early on and on many
threads, but over the long haul of their flagship architecture, stuff
just works.

The bottom line is ugly as it may be, Intel did, does it and the
ecosystem for their compatible architecture is frankly worth a great
deal more than S/360 or anything DEC did.  The economics puts Intel in
the leadership position here.


You can agree or not, but my point is not that 8080/x86/INTEL*64 is a
great architecture (it is not); but that Intel has done an incredible
job of moving it forward, with binaries continuing to "just work" and
all while dropping the price all the time.

Unless you are using a cell phone, I'm willing to bet that you are
typing your messages on a INTEL*64 architecture system, even if the
processor is not made by Intel.


I agree with all Clem wrote here. Intel can't be blamed for the effort 
in keeping compatibility working. It does work.


However, maybe Intel is not to credit for this (or at least not fully), 
sine the x86-64 is actually a creation from AMD. Intel was trying to 
kill the product by introducing the incompatible Itanium. AMD showed 
that it was feasible to extend the old pig to 64 bits, and the market 
went with them.


In a way, Intel is trapped by its own success. Nothing can replace the 
x86, no matter how ugly the architecture is. The point is, that any new 
CPUs needs to be backwards compatible all the way to the 8088, or else 
they will not fly.


Johnny


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[lists]

On Tue, 16 Feb 2016 11:25:37 -0500
Clem Cole  wrote:

> Unless you are using a cell phone, I'm willing to bet that you are typing
> your messages on a INTEL*64 architecture system, even if the processor is
> not made by Intel.

Nope! Sun Blade!

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Clem Cole]

On Tue, Feb 16, 2016 at 10:54 AM,  wrote:

> Every new IBM machine and OS was designed to preserve the investment in all
> ​ ​
> the software and development skills the customer already had. In terms of
> ​ ​
> architectural and implementation purity with compatability as a fundamental
> principle and a 52 year track record of success, IBM wrote the book.
>

​I agree, but I suggest that you don't sell Intel short.  To be honest, I
used to think the folks @ Intel had to be brain dead until I thought it
about and looked more carefully.  Once I started to work for them, I really
understood.   They deal with with an ugly architecture, but they make the
best of it for their customers.

You are right Intel killed compatibility many times between lots of
different impure attempts ( 432, ​

​all of their RISC systems etc...), but to Intel's credit - they always did
a good enough job on compatibility in the 4004-8080-8086-80386-INTEL*64
transitions to move the customers programs over somehow (again you are
right, sometimes easier than others)​.

But the trick is that economics of the Intel family, along with
compatibility - drove the price of computing down. And Intel was compatible
enough to have people keep doing it.  The fact is you can still boot and
old copy of DOS and the programs will run.

As was brought up in this thread, if you take the last VAX made it will not
boot VMS 1.x and I suspect it will not even run user code compiled for it
for any really sophisticated user code.


More over before DOS, Intel (while hardly perfect) did manage to bring 8080
programs to 8086 systems (and 4004 to 8008 and 8008 to 8080).   Yes, IBM
and DEC did it better than Intel did early on and on many threads, but over
the long haul of their flagship architecture, stuff just works.

The bottom line is ugly as it may be, Intel did, does it and the ecosystem
for their compatible architecture is frankly worth a great deal more than
S/360 or anything DEC did.  The economics puts Intel in the leadership
position here.


You can agree or not, but my point is not that 8080/x86/INTEL*64 is a great
architecture (it is not); but that Intel has done an incredible job of
moving it forward, with binaries continuing to "just work" and all while
dropping the price all the time.

Unless you are using a cell phone, I'm willing to bet that you are typing
your messages on a INTEL*64 architecture system, even if the processor is
not made by Intel.


Clem
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Timothe Litt]

On 16-Feb-16 10:58, li...@openmailbox.org wrote:
> On Tue, 16 Feb 2016 10:28:27 -0500
> Clem Cole  wrote:
>
>> The using
>> EBCDIC
>> ​instead of​
>>  ASCII
>> ​ was a sad thing.   IBM had been heavy in development of ASCII and I
>> believe even chaired the ANSI committee creating it.   In fact if you look
>> at marketing literature, S360 was supposed to be the
>> first commercial system to support it.   But with OS/360 being so late,
>> Brooks was said to make the decision to keep the primary code EBCDIC (for
>> compatibility).   Until the switch to Power years 25+ years later, IBM
>> (and its users) would pay that price.
> There was no switch to POWER. The very latest z Archicture machines still
> use EBCDIC and it has never been an issue. Yeah, we prefer big-endian too.
>
Not to fan the architecture religious wars, but that's a rather insular
point of view.

EBCDIC *is* an issue for users outside the IBM sphere.

It's a pain for interchange with the rest of the world.

The different collating sequence confounds people who expect digits
before letters (or vice-versa).

Languages end up with different pain points as a result of trying to
paper this over.   Look at Perl, which is reasonably portable.  EBCDIC
still trips up library modules regularly. 

Regular expressions frequently are coded as though ASCII were the only
codeset.  So are sorts.  The few characters in one but not the other are
an annoyance - now lessened by Unicode.  But that has its own issues.

Yes, people in the EBCDIC world learn to code 'properly' to accommodate
these difference.  People in the rest of the world are regularly
tripped-up by them.  It's a lot harder to deal with code-set independent
coding than portable C.  Neither is fun.  But at least there are lots
more tools for detecting the issues.  And few non-IBM development
platforms support an EBCDIC locale for people to validate their code -
if they are even aware they should care.

I knowingly code stuff for myself with alarm bells going off "that won't
work for EBCDIC".  But I don't care to take the time for code that will
"never leave my house".  Until it does :-)

That's not to say that one codeset is better than the other.  At one
time, either was a sane choice between legacy compatibility and
technology.  IBM made one.  Unfortunately, the rest of the world didn't
follow IBM.   And IBM, for sensible business, if not technical reasons
stuck with its choice.

Today, there still is pain.  It's not which one is 'better'.  It's that
they're *different*.

Unicode has its own coding and migration issues.  But at least within
the UTF-8 subset, your collating sequence doesn't change.  And you can
bring in applications without a porting effort.

I'm endian-neutral.  I like bit 0 always being a sign bit & network
compatibility of BE.  And I like the easy multi/variable-precision math
of LE.

I'm also a PDP-10 person -  where byte size and codeset are whatever you
want.  (1-36 bits for the byte size.)  And COBOL supported ASCII, EBCDIC
and SIXBIT equally as far back as the 70s... As did sort, and tape labels.





smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Johnny Billquist]

On 2016-02-16 16:54, li...@openmailbox.org wrote:

On Tue, 16 Feb 2016 08:58:11 -0500
Clem Cole  wrote:


As for what started this thread.   I think it is interesting that the long
term successful architectures in the market did have a excellent
compatibility stories. IBM with system 360 certainly set a high bar, and
DEC has nothing to be ashamed of, the different DEC lines, particularly
the Vax, did a great job here.In truth, probably the best of pure
compatibility story has to be Intel.


No offense, but to even suggest Intel has the best compatibility or that
pure and Intel go together in the same sentence is completely over the top.
 From every angle I can see, Intel has about the worst track record of
upward or backward compatibility and the least amount of design integrity
or purity of any vendor still in business and probably in the history of
modern computing.


[...]

I think you need to keep the OS and the processor separate in this 
discussion.


As far as I'm aware, you can still boot an old version of MS-DOS on the 
latest x86-64 based PC you can grab. However, that demands not only that 
the CPU is backwards compatible (it is), but that you also have a BIOS 
that is compatible, since MS-DOS depends on that.


But there is no point ranting about the upgrades and enhancements to the 
CPU not being backward compatible. That would never be expected. The 
crucial question is if you can boot that old OS, and run your old 
programs. And the answer to that one is, I believe, yes.


Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] EXT :Re: VAX/VMS

[Hittner, David T (IS)]

This is the beauty of the SIMH VAX and VAX780. The simulators allow running 
much larger resource capacities than were affordable at the time. And run it 
faster.

While it is possible to run VMS 7.3 on the resource constrained 11/725, 11/730, 
MicroVAX I, and MicroVAX 2000 systems, the challenge is getting it there in the 
first place. Memory limits can be addressed by SYSGEN tweaks, disk limits can 
be addressed by installation tailoring and having multiple or external disks, 
but it's still hard to load the OS on resource-constrained hardware.

My company bought one of the backplane-epoxied MicroVAX I's to "double" the 
processing power of our production 11/730, by getting the programmers and our 
"damn compiler runs" off of the main production system. This MicroVAX I system 
was extremely resource-limited with 2MB memory and a 31MB disk drive. But it 
ran VMS well enough for two programmers.  When the MicroVAX II came along, the 
11/730 was replaced and moved from the shop floor to the office space. This 
allowed us to upgrade the file transfer between the systems from serial Kermit 
to always-up Asynchronous DECnet. When the programmers complained about the 
relative speed of the MicroVAX I vs. the MicroVAX II, the MicroVAX I got a few 
upgrades: an un-epoxied backplane to allow more boards, an RQDX3/RD54 
controller/disk combination, and the maximum 4MB memory. Eventually, it was 
upgraded to a MicroVAX II board and memory, and an Ethernet controller was 
added to both systems to allow a small VAXCluster as incremental funding became 
available.

As a Digital VAR, my company always faced the resource-constrained limits when 
selling. Most manufacturing companies buying our package couldn't afford really 
good systems, and settled for resource-constrained versions.

Dave

-Original Message-
From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Ethan Dicks
Sent: Tuesday, February 16, 2016 2:18 AM
To: simh@trailing-edge.com
Subject: EXT :Re: [Simh] VAX/VMS

On Tue, Feb 16, 2016 at 1:57 AM, Wilm Boerhout  wrote:
> More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780.
> This level of backwards compatibility is unique.

I'm sure 7.3 has a very broad list of what it runs on, but (considering I own 
the hardware in question), does it run on the smallest of the small?  
VAX-11/725?  MicroVAX 2000?  In the case of the 11/725 (and the 11/730), 
minimum memory requirements come to mind.
They are limited to 5MB (the MicroVAX 2000 can take far more memory than that 
and is not a problem there)  The 11/725, by default, comes with the RC25 as its 
disk, but you can stick a different disk controller on the Unibus (a SCSI 
controller does nicely if you can find an affordable one, but an SMD controller 
is easier to locate), and I do know someone who did some sheetmetal cutting and 
added an external BA11 to their 11/725 where they could put any number of 
Unibus disk interfaces.  In the case of the MicroVAX 2000, it's a busless 
design and comes with the equivalent of an RQDX3, so is limited to one internal 
RD54 and one external RD54, though you could give it a go to MOP boot it via 
Ethernet.  The MicroVAX I also has its place on the small end, with Qbus memory 
and 4MB max, but at least you can toss a Qbus SCSI controller in one and not 
suffer with the limitations of its RQDX1.

So if 7.3 fits on a ~150MB disk and in 4MB or 5MB of RAM, it'll fit on any of 
these except perhaps an unexpanded 11/725 (but to be fair, not much fit on an 
RC25, even when it _was_ on the supported list).

I'm not decrying 7.3 at all, but having tried to shoehorn 6.2 on a standard 
MicroVAX II (9MB RAM, 154MB RD54), I do wonder about the small, 
hardware-constrained machines.  For my own collection, I tend to run whatever 
was common in the day for that specific hardware, anywhere from MicroVMS 
4.whatever through VMS 4.7 through VMS 5.5 or so.  Again, nothing wrong with 
6.x or 7.x if you have memory and disk to handle it, but not having some of the 
more expandable models, I didn't do much with the more recent versions and the 
VAX (but plenty with more recent versions and Alpha.  Talk about needing more 
RAM!)

-ethan
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Clem Cole]

On Tue, Feb 16, 2016 at 9:56 AM, Timothe Litt  wrote:

> Nonetheless, Brooks (@IBM) definitely gets credit for the first
> ​ ​
> commercial line of architecturally (forward) compatible machines.  Prior
> ​ ​
> to that inspiration, every new machine was unique and most software
> started over (including compilers).
>

​Amen -- I credit ​

​Brooks for 3 things good things and one bad

Good:
1.) architectural compatibility
2.) ​a 32 bit word size with an large address space (24 bits in this case)
3.) 8 bit byte

Bad:
  EBCDIC over ASCII

I used to work with the Chief Designer of Model 50 at one of my start ups.
He had some very interesting stories.   Gordon Bell always said the single
worst mistake you can make in an architecture is too few address bits.
 Russ said that the word and bytes sizes that Brooks wanted, Amdahl thought
were "wasteful and frivolous" but Brooks one the war. Supposedly Amdahl
wanted a 6 bit byte, but Brooks was said to thrown him out of office until
he came back with something that was a power of two "that he could
program."

FWIW:  Around the same time, Seymour Cray would use a 6 bit byte at CDC and
not embrace 8 bits until the Cray-1 10 years later --- and look at the
craziness that their systems had to handle with N different codes - you
actually see some of impact in design of Pascal by Wirth years later.


The using
EBCDIC
​instead of​
 ASCII
​ was a sad thing.   IBM had been heavy in development of ASCII and I
believe even chaired the ANSI committee creating it.   In fact if you look
at marketing literature, S360 was supposed to be the
first commercial system to support it.   But with OS/360 being so late,
Brooks was said to make the decision to keep the primary code EBCDIC (for
compatibility).   Until the switch to Power years 25+ years later, IBM (and
its users) would pay that price.

​Clem​
​
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Ken Cornetet]

I think IBM chose the 8088 over the Motorola offerings because it would be 
easier for software vendors to port their z80 CPM software to the 808x given 
the (mostly) same instruction set and the 808x segmented memory looked like a 
z80’s 64k memory space if you ignored the segment registers.

The 8088 was chosen over the 8086 because it was easier (and cheaper) to 
interface the then common 8 bit peripheral chips.

From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Dave Wade
Sent: Tuesday, February 16, 2016 10:16 AM
To: 'Clem Cole'
Cc: 'SIMH'
Subject: Re: [Simh] VAX/VMS

I was deliberately ignoring the 67 (&47) as they were very much “specials”. I 
cut my teeth on the 360/67 at Newcastle Upon Type under MTS, (and OS/MVT) but 
MTS was never generally available, MVS and later won’t run on the 360/67, and 
TSS pretty much died a death. Even CP/47 and CP/67 had a major re-write to 
become VM/370… The 360/67 actually had 32 bit addressing rather than 31-bit 
that’s XA and S/390. Also as for comparison with the VAX on memory cabinet 
which I think had 64K Bytes is about the same size as a large VAX.

This is the Newcastle 360/67 with 512K of Core and the DAT gate open…

http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/slide07.jpg

and a close view of the core cabinet here:-

http://history.cs.ncl.ac.uk/anniversaries/40th/images/ibm360_672/21.html

I think it is also interesting to compare the Intel architecture which was 
designed to be economical with Silicon against the M6800, M6809 and the M68000 
which were designed to be programmer friendly, and of course note the 
similarities between the 68000 & S/360 with 16 general purpose registers and 
orthogonal instruction set) and wonder where we would be today had IBM chosen 
them for its PC rather than the 8086 which I assume was cheaper…

Dave
G4UGM

From: Clem Cole [mailto:cl...@ccc.com]
Sent: 16 February 2016 13:58
To: Dave Wade >
Cc: SIMH >
Subject: Re: [Simh] VAX/VMS

Dave be careful --   S/360 Model 67 has VM in the late 1960's - TSS and it's 
brother MTS, both rely on it.   The 67 is a Model 65 with a  Data Address 
Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which is in a 
cabinet that t'ed off the main CPU and is about the same size en entire Vax 780 
which would follow 10 years later.

Think about that for a minute -- an 8 word TLB.   At Intel we regularly examine 
the different sizes of the different parts of the memory system.  Core 7 (aka 
Nehalem of a few years ago) has a two-level TLB: the first level of TLB is 
shared between data and instructions. The level 1 data TLB now stores 64 
entries for small pages (4K) or 32 for large pages (2M/4M), while the level 1 
instruction TLB stores 128 entries for small pages (the same as with Core 2) 
and seven for large pages. The second level is a unified cache that can store 
up to 512 entries and operates only with small pages.

Also it is also interesting to consider that while the AT folks came off of 
Multics, a number of us university types that would work on earlier Unix came 
from TSS and MTS (one 360/67).   In fact, TSS is still the only system I ever 
used that lived in the debugger as your command system - which I always thought 
was a cool idea.


As for what started this thread.   I think it is interesting that the long term 
successful architectures in the market did have a excellent compatibility 
stories. IBM with system 360 certainly set a high bar, and DEC has nothing to 
be ashamed of, the different DEC lines, particularly the Vax, did a great job 
here.In truth, probably the best of pure compatibility story has to be 
Intel.  The H/L registers of the 4004 are still there ;-)   Seriously, the 
INTEL*64 is from an computer science standpoint, not an architecture you would 
create from scratch.   But Intel has completely understood the economics of SW 
compatibility.

Also, if you peeked inside a modern processor, you would discover they are 
dataflow engines and put together with all of the modern computer science; but 
there is about a 5% silicon tax paid for compatibility.  Clearly, my siblings 
at Intel believe it's worth tax and the customers seem to keep wanting it.

Clem

On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade 
> wrote:
> -Original Message-
> From: Simh 
> [mailto:simh-boun...@trailing-edge.com]
>  On Behalf Of Wilm
> Boerhout
> Sent: 16 February 2016 11:58
> To: simh@trailing-edge.com
> Subject: Re: [Simh] VAX/VMS
>
> Johnny Billquist schreef op 16-2-2016 om 12:49:
> >
> > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen

S/360 compatibility is only forward, and only to a certain point. S/360 and 
S/370 are both 24-bit addressing and fairly compatible, but S/370 (Mostly) has 

Re: [Simh] VAX/VMS

[Timothe Litt]

On 16-Feb-16 10:16, Dave Wade wrote:
>
> I
>
>
> I think it is also interesting to compare the Intel architecture which
> was designed to be economical with Silicon against the M6800, M6809
> and the M68000 which were designed to be programmer friendly, and of
> course note the similarities between the 68000 & S/360 with 16 general
> purpose registers and orthogonal instruction set) and wonder where we
> would be today had IBM chosen them for its PC rather than the 8086
> which I assume was cheaper…
>
>
I worked with IBM in Boca Raton at one point.  This is where the IBM PC
was developed, and I talked with some of the originators.

They told me that they considered the 8086, the 68000 & the T11 for the
PC.  They really, really wanted the -11.  IBM had the largest population
of -11 programmers in the world at one time.  They used the 11 for
manufacturing and real-time.  There was a huge amount of software.  But
DEC wouldn't sell the -11 to them.  So they went for price and that deal
with Gates to write DOS.  Neither was supposed to last...




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] [SimH] VAX/VMS

[Timothe Litt]

On 16-Feb-16 10:10, Bob Supnik wrote:
> Okay, I'll bite - what's a VXT1200? I see references to it on Google,
> but I can't find a clear description.
>
It was the X windows terminal.

> Tim Litt said rtVAX was never intended to run VMS, but its history is
> a bit more complicated. 
Yes.  I described the external effect/story.  As usual, you version of
the internal details matches my (less precise) memories.





smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Timothe Litt]

On 16-Feb-16 08:58, Clem Cole wrote:
>
> Also it is also interesting to consider that while the AT folks came
> off of Multics, a number of us university types that would work on
> earlier Unix came from TSS and MTS (one 360/67).   In fact, TSS is
> still the only system I ever used that lived in the debugger as your
> command system - which I always thought was a cool idea.  
>
ITS (MIT PDP-6/10) did that too.  I wasn't a frequent user, but the CLI
was DDT.

> Also, if you peeked inside a modern processor, you would discover they
> are dataflow engines and put together with all of the modern computer
> science; but there is about a 5% silicon tax paid for compatibility. 
> Clearly, my siblings at Intel believe it's worth tax and the customers
> seem to keep wanting it.
5% is probably fair as as an estimate of silicon area.

Actually, the real tax is in processor validation.  I worked briefly in
that group.  It costs more than 5% in manpower to keep making sure that
the compatibility modes (yes, 's') work.  The older modes have lots of
quirks and errata that have to be kept bug-compatible in the face of new
implementations.

The other taxes are more subtle; things like the memory ordering model
and i-stream modification have real performance costs.   So does the
limited opcode space, which has resulted in ever more opcode prefixing. 
Intel tries to minimize these with ever increasing cleverness, but
they're still there.  And probably always will be.

Alpha tried to wipe these out with one swell foop, but failed to grok
the software costs.  (I did point them out at the time, but the general
belief was that the migration tools would be good enough and that
customers would pay the price for the performance.  They weren't, and
they didn't.)




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] [SimH] VAX/VMS

[Bob Supnik]

Okay, I'll bite - what's a VXT1200? I see references to it on Google, 
but I can't find a clear description.


Tim Litt said rtVAX was never intended to run VMS, but its history is a 
bit more complicated. The original intent of the uVAX chip program, 
which kicked off in the spring of 1982, was to establish an 
chip-and-software industry standard in the IBM PC sense, at the 32b 
level. The uVAX program office under Roy Moffa had a clearly stated and 
approved goal to sell uVAX as a chip, a board, and a system, to all 
comers, with appropriate licensing for VMS. As a result, the definition 
of the chip was limited in three ways, to minimize the competitive 
impact on DEC's own products.


1. The chip would implement only a subset of the instructions (also 
needed to get the microcode to fit).

2. The chip would support only 16MB of physical memory.
3. The chip would have physical system space and physical process page 
tables. Because of the physical memory limitation, this would limit the 
size of virtual memory as well.


Dave Cutler's MicroVAX I (code name Seahorse) would be even more 
limited, because it would only support 4MB of physical memory.


As the project went on, the software cost of limitation #3 became 
increasingly clear. In the fall of 1982, Dave Cutler asked that system 
space be made virtual, with an independent mapping enable bit. The uVAX 
team wasn't happy about this but eventually agreed. Then, in the spring 
of 1983, the VMS team concluded that getting VMS to support physical 
process page tables was really, really hard. Dick Hustvedt asked if full 
VAX memory management could be supported. Dave was able to do that for 
MicroVAX I, and after some minimal redesign work, the uVAX team was able 
to support full memory management as well.


But with the virtual memory limitation removed, and evidence that uVAX 
would perform almost as well as a 780 except on COBOL apps, Ken Olsen 
became increasingly unhappy about selling the chip and setting up 
competitors to DEC's own VAX line. In 1984, he reversed the decision to 
sell the chip but allowed the program to sell boards to continue. Then, 
on the day of the MicroVAX II system announcement, /at the announcement 
site/, he reversed the decision about selling boards and had all the OEM 
material removed from the announcement. The chip and board teams were 
devastated.


In order to have  32b to sell in the real-time market, the 
real-time business resurrected the original uVAX definition, now to be 
known as rtVAX. At first, Ken demanded that rtVAX be incapable of 
running Ultrix/Unix as well, but any changes that prevented that also 
made it impossible to run VAXELN, Dave Cutler's real-time OS. 
Eventually, Ken concluded that preventing rtVAX from running VMS was 
sufficient, and it was allowed to proceed. Because changes had to be 
confined to microcode, rtVAX included mapped system space and physical 
process page tables, with a single enable bit.


I don't recall if there was a CVAX real-time variant. There's no 
evidence in the CVAX microcode of alternative memory management flows. 
The 1987 Semiconductor Handbooks don't mention rtVAX at all.


/Bob

On 2/16/2016 8:53 AM, simh-requ...@trailing-edge.com wrote:

Message: 7
Date: Tue, 16 Feb 2016 14:53:40 +0100
From: Johnny Billquist
To:simh@trailing-edge.com
Subject: Re: [Simh] VAX/VMS
Message-ID:<56c329e4.7090...@softjar.se>
Content-Type: text/plain; charset=utf-8; format=flowed

On 2016-02-16 13:58, Timothe Litt wrote:

>On 16-Feb-16 06:49, Johnny Billquist wrote:

>>More precisely, V7.3 will run on*any*  VAX, including the primal

>>>VAX-11/780. This level of backwards compatibility is unique.

>>
>>And there are some VAXen on which V7.3 will definitely not run. How
>>about rtVAX for example.

>Not fair.  No version of VMS ever ran on rtVAX - it was designed that
>way. (For yes, marketing reasons.)

Oh, I definitely agree that I wasn't fair. But on the other hand, Wilm
did claim that VMS ran on*any*  VAX.
I was also tempted to drag up the VXT1200. But since that one does not
have the name "VAX" in it, it could perhaps technically be disqualified
on that basis... The rtVAX on the other had is without a doubt a VAX,
even in name.

Johnny



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Timothe Litt]

On 16-Feb-16 08:53, Johnny Billquist wrote:
> On 2016-02-16 13:58, Timothe Litt wrote:
>> On 16-Feb-16 06:49, Johnny Billquist wrote:
>>> More precisely, V7.3 will run on *any* VAX, including the primal
 VAX-11/780. This level of backwards compatibility is unique.
>>>
>>> And there are some VAXen on which V7.3 will definitely not run. How
>>> about rtVAX for example.
>> Not fair.  No version of VMS ever ran on rtVAX - it was designed that
>> way. (For yes, marketing reasons.)
>
> Oh, I definitely agree that I wasn't fair. But on the other hand, Wilm
> did claim that VMS ran on *any* VAX.
> I was also tempted to drag up the VXT1200. But since that one does not
> have the name "VAX" in it, it could perhaps technically be
> disqualified on that basis... The rtVAX on the other had is without a
> doubt a VAX, even in name.
It would have been more accurate for WIlm to say "any VAX that VMS was
ever was released to run on"(1), which is still a strong statement.

As pointed out, somewhat stronger than the IBM forward compatibility
story.  DEC was obsessive about forward and backward compatibility.  I
even made sure that you could run vectorized programs on a 780.  Or SimH
(via the OS-delivered transparent instruction emulation.)

And the architecture was managed to ensure that there are very few
differences at the hardware level for the OS to paper over, even in
privileged modes.  (Mostly I/O bus evolution and error handling.  Not
layers of microcode and emulation required by others, including IBM and
Intel.)  This was also visible in the small effort required to port
other VAX OSs (Ultrix, System V, and ELN) , though some of them chose to
require kernel builds rather than the VMS approach of loadable kernel
modules.  Diagnostics were also beneficiaries.  And the I/O devices
[including disk and network adapters] that used VAXes (rarely rtVAXes,
bTW) as embedded controllers.  Most of those ran no OS, just a
polling/tasking loop.

Architecture management was a big effort.  It delivered remarkable
results.  It wasn't free.  It did slow innovation.  And hardware always
had to have a power-up mode that was backward-compatible where that was
physically possible.  (We didn't insist that you be able to plug an XMI
peripheral directly into a 780 Unibus.  Though you could have a UBA on a
BI on an XMI on a JBox, and aside from a few registers initialized by
the OS, your old device driver didn't know the difference.)

Inside DEC, the PDP-6/10/20 line made similar guarantees and results. 
However, the process for accomplishing that was less rigorous.  We
didn't have the architectural conformance verification infrastructure
(e.g. axe, paxe and max) that was developed for VAX from day one.

The PDP-11 carried an instruction set forward in the same tradition. 
Mostly compatibly, but with a lot more user-visible variation.  Multiple
floating point add-ons and the commercial instruction set.  Some
instruction oddities, not all intentional.  Not to mention memory
management variations.  It was a *lot* more work for an OS to adapt to a
new -11.  The VAX architecture process was a reaction to that.

The PDP-8 family also provided a lot of compatibility via an ad-hoc
process.  It, too, had a fair bit of user-visible variation.  You could
write code that would run on any family member, but it wasn't
automatic.  With VAX, it is.

Nonetheless, Brooks (@IBM) definitely gets credit for the first
commercial line of architecturally (forward) compatible machines.  Prior
to that inspiration, every new machine was unique and most software
started over (including compilers).

rtVAX *is* architecturally *almost* a VAX.  It is listed in the
architecture documents as "the rtVAX variant",
and was a separate product line.  The VAX name, and the ability for user
level code (at least in the VAX/ELN
supported languages) to run on it were valid technical and marketing
features.

But you would no more expect VMS to run on ANY rtVAX than you would
expect a gasoline-powered
auto to run on diesel.  Yes, there is a lot of similarity.  The engines
even look very similar.  But the
design is explicitly for one or the other.


(1) Phrased that way to cover the cases of machines that ran VMS
internally at one point, but were killed and the provisional support
removed from VMS.
(2) As for VXT, I don't remember what it used internally.  But there
were a couple of versions of that device, and if there was a processor
upgrade, its software also benefited from the strong forward and
backward compatibility of the VAX.  It might have shipped different
firmware because of the graphics upgrades or other choices it made.  But
the processor wouldn't have driven that.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VMS FIles

[Robert Thomas]

The usual situation when installing VMS on a real machine whether VAX, AXP, or 
IA64 was to manually type in the initial licenses as given on the license 
sheets from DEC/COMPAQ/HP.  Depending on the hardware, operating system version 
and license bundles, either one, two or more licenses needed to be entered to 
get a "minimally" functional system (VMS, VAXCLUSTER, DECWINDOWS, UCX/TCPIP).

The UCX/TCPIP implementation all support basic functionality, i.e. FTP, TELNET, 
RLOGIN, REXEC, and RSH.  If the host system supports FTP, files can be readily 
transferred onto the simulated system.

The freeware CD's/DVD's contain SAMBA in source and binary for VAX, AXP and 
IA64.  Such can be installed on VMS to provide core functionality.

Putty is a very small footprint telnet client that plays well with VMS.

If one wants to work in an X-Windows environment, one can install DECWindows on 
the VMS system and connect using eXcursion or any other X-Windows servers via 
TCPIP.

Additionally, the simh VAXen, work well as members of a VAX/VMSCLUSTER.  We 
have a simh microVAX3900 running VMS 7.3 (host hardware a 4-core AMD PC running 
Windows-7) as a member of our AXP and IA64 cluster.  The performance of the 
simh microVAX3900 is noticeably better than our original hardware.

Sincerely,
Robert F. Thomas

 44 Industrial Way 
Norwood, MA USA 02062
N  Office Phone - (781) 329-9200
O mail to: r...@asthomas.com
 



___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Johnny Billquist]

On 2016-02-16 13:58, Timothe Litt wrote:

On 16-Feb-16 06:49, Johnny Billquist wrote:

More precisely, V7.3 will run on *any* VAX, including the primal

VAX-11/780. This level of backwards compatibility is unique.


And there are some VAXen on which V7.3 will definitely not run. How
about rtVAX for example.

Not fair.  No version of VMS ever ran on rtVAX - it was designed that
way. (For yes, marketing reasons.)


Oh, I definitely agree that I wasn't fair. But on the other hand, Wilm 
did claim that VMS ran on *any* VAX.
I was also tempted to drag up the VXT1200. But since that one does not 
have the name "VAX" in it, it could perhaps technically be disqualified 
on that basis... The rtVAX on the other had is without a doubt a VAX, 
even in name.


Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Clem Cole]

Dave be careful --   S/360 Model 67 has VM in the late 1960's - TSS and
it's brother MTS, both rely on it.   The 67 is a Model 65 with a  Data
Address Translation unit (DAT box) - is supplied by a 8 x 32 bit TLB which
is in a cabinet that t'ed off the main CPU and is about the same size en
entire Vax 780 which would follow 10 years later.

Think about that for a minute -- an 8 word TLB.   At Intel we regularly
examine the different sizes of the different parts of the memory system.
Core 7 (aka Nehalem of a few years ago) has a two-level TLB: the first
level of TLB is shared between data and instructions. The level 1 data TLB
now stores 64 entries for small pages (4K) or 32 for large pages (2M/4M),
while the level 1 instruction TLB stores 128 entries for small pages (the
same as with Core 2) and seven for large pages. The second level is a
unified cache that can store up to 512 entries and operates only with small
pages.

Also it is also interesting to consider that while the AT folks came off
of Multics, a number of us university types that would work on earlier Unix
came from TSS and MTS (one 360/67).   In fact, TSS is still the only system
I ever used that lived in the debugger as your command system - which I
always thought was a cool idea.


As for what started this thread.   I think it is interesting that the long
term successful architectures in the market did have a excellent
compatibility stories. IBM with system 360 certainly set a high bar, and
DEC has nothing to be ashamed of, the different DEC lines, particularly the
Vax, did a great job here.In truth, probably the best of pure
compatibility story has to be Intel.  The H/L registers of the 4004 are
still there ;-)   Seriously, the INTEL*64 is from an computer science
standpoint, not an architecture you would create from scratch.   But Intel
has completely understood the economics of SW compatibility.

Also, if you peeked inside a modern processor, you would discover they are
dataflow engines and put together with all of the modern computer science;
but there is about a 5% silicon tax paid for compatibility.  Clearly, my
siblings at Intel believe it's worth tax and the customers seem to keep
wanting it.

Clem

On Tue, Feb 16, 2016 at 8:15 AM, Dave Wade  wrote:

> > -Original Message-
> > From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Wilm
> > Boerhout
> > Sent: 16 February 2016 11:58
> > To: simh@trailing-edge.com
> > Subject: Re: [Simh] VAX/VMS
> >
> > Johnny Billquist schreef op 16-2-2016 om 12:49:
> > >
> > > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen
>
> S/360 compatibility is only forward, and only to a certain point. S/360
> and S/370 are both 24-bit addressing and fairly compatible, but S/370
> (Mostly) has Virtual Memory as standard.
>
> Then came the "great divide" S/370XA. XA mode has 31-bit addressing and
> different I/O instructions. Some of the XA boxes will work is S/370 mode,
> but many won't.
>
> More recently IBM moved to 64-bit hardware. Again some will boot in 31-bit
> mode but more recent boxes need a 64-bit OS.
>
> So the earliest incarnations of "OS", which were I guess "MFT" which is
> basically a fixed number of partitions will run on later machines until you
> get to systems which will only run in 31bit mode. (XA Mode).
>
> OS/VS2 and its siblings MVS (This is the free version), MVS/SP (The paid
> for version) will only run on S/370 or later, not on 360, as they need
> Virtual Memory and it stops working at the same point as MFT when 31 bit
> only machines appear. There are also issues of Virtual Memory Page size
> which may stop MVS (the free version working) working on some hardware
> (there are patches to work round this).
>
> You also have issues over disk (DASD in IBM speak) support. So whilst MFT
> was written for a 1996 S/360 it would in theory run on an P390E from 1996
> so 30 years of computability. However, it would need older disks, which the
> P/390E cannot support.
>
> Of course these changes are really only to do with programs that run in
> supervisor state. User mode programs generally will run unchanged from 1966
> through to the present day, and the latest zOS a descendant of MVS will
> still run 24-bit applications.  I am pretty sure that until a few years
> many commercial sites, so mostly Cobol, still used the older "free"
> Fortran-66 compiler for the odd Fortran job.
>
> > > on which V7.3 will definitely not run. How about rtVAX for example.
> > >
> > I stand corrected. Please note that I had a marketing job once. It
> sticks...
>
> ... I also believe that some of the in-compatibility in IBM kit is to
> drive the hardware->software->Hardware->Software upgrade chain and keep the
> dollars rolling in...
>
> Dave G4UGM
>
>
>
>
> > ___
> > Simh mailing list
> > Simh@trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> 

Re: [Simh] VAX/VMS

[Johnny Billquist]

On 2016-02-16 14:33, Paul Koning wrote:



On Feb 16, 2016, at 6:49 AM, Johnny Billquist  wrote:

On 2016-02-16 07:57, Wilm Boerhout wrote:

Zane Healy schreef op 15-2-2016 om 18:20:

[snip]


There are plenty of good VAX and VMS manuals out there, including the
documentation set.  Check eBay and abebooks.com.

The last version of VMS that will run on a VAX is v7.3.

Zane

More precisely, V7.3 will run on *any* VAX, including the primal
VAX-11/780. This level of backwards compatibility is unique.


No, it is not. Talk to IBM about S/360... :-)


Nor is it unique at DEC.  Consider RT-11.  And possibly RSX-11/M (I don't know 
that one well enough -- does it run on an 11/20?)


Yes, unmapped RSX-11M would run on an 11/20. So you could claim that 
RSX-11M is runnable on almost any PDP-11 ever made. Of course, you would 
not be able to do program development on all of those platforms, but you 
could deploy an application.


But RSX-11M in some ways feels and behaves rather different if you have 
an MMU or not. So it would not give the same uniform feeling like VMS or 
RT-11 would.


Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Johnny Billquist]

On 2016-02-16 12:57, Wilm Boerhout wrote:

Johnny Billquist schreef op 16-2-2016 om 12:49:


No, it is not. Talk to IBM about S/360... :-)
And there are some VAXen on which V7.3 will definitely not run. How
about rtVAX for example.


I stand corrected. Please note that I had a marketing job once. It
sticks...


That's ok. The VAX is still a pretty good example of longevity, 
compatibility over the line and a generally good design, I think.

We don't have to exaggerate, the truth is pretty good as it is.

Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Paul Koning]

> On Feb 16, 2016, at 6:49 AM, Johnny Billquist  wrote:
> 
> On 2016-02-16 07:57, Wilm Boerhout wrote:
>> Zane Healy schreef op 15-2-2016 om 18:20:
>> 
>> [snip]
>> 
>>> There are plenty of good VAX and VMS manuals out there, including the
>>> documentation set.  Check eBay and abebooks.com.
>>> 
>>> The last version of VMS that will run on a VAX is v7.3.
>>> 
>>> Zane
>> More precisely, V7.3 will run on *any* VAX, including the primal
>> VAX-11/780. This level of backwards compatibility is unique.
> 
> No, it is not. Talk to IBM about S/360... :-)

Nor is it unique at DEC.  Consider RT-11.  And possibly RSX-11/M (I don't know 
that one well enough -- does it run on an 11/20?)

paul


___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Dave Wade]

> -Original Message-
> From: Simh [mailto:simh-boun...@trailing-edge.com] On Behalf Of Wilm
> Boerhout
> Sent: 16 February 2016 11:58
> To: simh@trailing-edge.com
> Subject: Re: [Simh] VAX/VMS
> 
> Johnny Billquist schreef op 16-2-2016 om 12:49:
> >
> > No, it is not. Talk to IBM about S/360... :-) And there are some VAXen

S/360 compatibility is only forward, and only to a certain point. S/360 and 
S/370 are both 24-bit addressing and fairly compatible, but S/370 (Mostly) has 
Virtual Memory as standard. 

Then came the "great divide" S/370XA. XA mode has 31-bit addressing and 
different I/O instructions. Some of the XA boxes will work is S/370 mode, but 
many won't.

More recently IBM moved to 64-bit hardware. Again some will boot in 31-bit mode 
but more recent boxes need a 64-bit OS.

So the earliest incarnations of "OS", which were I guess "MFT" which is 
basically a fixed number of partitions will run on later machines until you get 
to systems which will only run in 31bit mode. (XA Mode).  

OS/VS2 and its siblings MVS (This is the free version), MVS/SP (The paid for 
version) will only run on S/370 or later, not on 360, as they need Virtual 
Memory and it stops working at the same point as MFT when 31 bit only machines 
appear. There are also issues of Virtual Memory Page size which may stop MVS 
(the free version working) working on some hardware (there are patches to work 
round this).

You also have issues over disk (DASD in IBM speak) support. So whilst MFT was 
written for a 1996 S/360 it would in theory run on an P390E from 1996 so 30 
years of computability. However, it would need older disks, which the P/390E 
cannot support.

Of course these changes are really only to do with programs that run in 
supervisor state. User mode programs generally will run unchanged from 1966 
through to the present day, and the latest zOS a descendant of MVS will still 
run 24-bit applications.  I am pretty sure that until a few years many 
commercial sites, so mostly Cobol, still used the older "free" Fortran-66 
compiler for the odd Fortran job.

> > on which V7.3 will definitely not run. How about rtVAX for example.
> >
> I stand corrected. Please note that I had a marketing job once. It sticks...

... I also believe that some of the in-compatibility in IBM kit is to drive the 
hardware->software->Hardware->Software upgrade chain and keep the dollars 
rolling in...

Dave G4UGM 




> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Timothe Litt]

On 16-Feb-16 06:49, Johnny Billquist wrote:
> More precisely, V7.3 will run on *any* VAX, including the primal
>> VAX-11/780. This level of backwards compatibility is unique.
>
> No, it is not. Talk to IBM about S/360... :-)
Agree
> And there are some VAXen on which V7.3 will definitely not run. How
> about rtVAX for example.
Not fair.  No version of VMS ever ran on rtVAX - it was designed that
way. (For yes, marketing reasons.)

Any version of VAX/ELN should run on all previous rtVAXen.

For those who don't know, rtVAX  is used in the Realtime market. 
VAX/ELN is the OS used
with it.  Another Cutler OS - written largely in PASCAL.  You build an
image on VMS, where it's
a layered product.  Then deploy to your embedded system, often with a
MOP boot.  (Yes, another
protocol that wireless usually doesn't route.)

It is exactly a VAX, except that process page tables are in physical,
rather than virtual memory.
The difference is that the process base register contains a physical
address, and microcode can
omit the virtual -> physical translation on a TB refill.

This was sold as a performance optimization for Realtime.  It was - but
it wasn't strictly necessary.

It really allowed market differentiation; rtVAX could be sold in
embedded systems at an
affordable (for the time) price point without cannibalizing the
minicomputer/data center machine
pricing.

(Former DEC Realtime and VAX architect.  And no, not responsible for
this decision.)




smime.p7s
Description: S/MIME Cryptographic Signature
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Wilm Boerhout]

Johnny Billquist schreef op 16-2-2016 om 12:49:


No, it is not. Talk to IBM about S/360... :-)
And there are some VAXen on which V7.3 will definitely not run. How 
about rtVAX for example.



I stand corrected. Please note that I had a marketing job once. It sticks...
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] VAX-11/780 model case

[Wilm Boerhout]

Several people have asked me on and off the list about the VAX-11/780 
model case that is shown in one of my posts.


Althought it is not -as I believed earlier- one of a kind, the origins 
are unknown to me. It is an aluminum profile at the core, the panels are 
covered with pre-printed adhesive. The disk and tape "cabinets are 
really in "3D", with a rather rogh finish. One of my colleagues at VX 
Company knows of one other specimen owned by a friend of a friend. It 
may be distributed only in The Netherlands by DEC of DECUS in a small 
batch, or it may have come from abroad.


/Wilm
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Johnny Billquist]

On 2016-02-16 07:57, Wilm Boerhout wrote:

Zane Healy schreef op 15-2-2016 om 18:20:

[snip]


There are plenty of good VAX and VMS manuals out there, including the
documentation set.  Check eBay and abebooks.com.

The last version of VMS that will run on a VAX is v7.3.

Zane

More precisely, V7.3 will run on *any* VAX, including the primal
VAX-11/780. This level of backwards compatibility is unique.


No, it is not. Talk to IBM about S/360... :-)
And there are some VAXen on which V7.3 will definitely not run. How 
about rtVAX for example.



The other way around, each "newer" VAX in general needs a minimum
version of VMS to run. Sometimes special "hardware releases" were issued
(such as V5.5-H2) to support a new VAX model or variant.


Right.

Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

[Johnny Billquist]

On 2016-02-16 08:18, Ethan Dicks wrote:

On Tue, Feb 16, 2016 at 1:57 AM, Wilm Boerhout  wrote:

More precisely, V7.3 will run on *any* VAX, including the primal VAX-11/780.
This level of backwards compatibility is unique.


I'm sure 7.3 has a very broad list of what it runs on, but
(considering I own the hardware in question), does it run on the
smallest of the small?  VAX-11/725?  MicroVAX 2000?


The smallest of the small would be the MicroVAX I, and I have a 
suspicion that it won't run on that machine, but I have not tried...
You did mention it in your post, but it really deserves recognition for 
being a bit more cramped than anything else.


As far as VMS demands, I think VMS V6 was more of a hug than V7 is.

Johnny

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] Interdata OS/32: hello-world in CAL32

[lists]

Fascinating and very similar in syntax to the assembler for IBM OS/360 and
later. Does anybody know the history behind this?

On Mon, 15 Feb 2016 13:58:26 -0500 (EST)
dst...@execulink.com (Don Stalkowski) wrote:

> *L EDIT32
> TSKID = EDIT32
> *ST
> *13:19:38   EDIT32:PERKIN-ELMER OS/32 EDIT 03-145 R04-01
> *EDIT32>GET HELLO.CAL
> *EDIT32>T 1-12
> *13:19:48   EDIT32:1 SVC   1,SAY
> *13:19:48   EDIT32:2 SVC   3,0
> *13:19:48   EDIT32:3 ALIGN ADC
> *13:19:48   EDIT32:4SAY  DBX'28'
> *13:19:48   EDIT32:5 DBX'00'
> *13:19:48   EDIT32:6 DS2
> *13:19:48   EDIT32:7 DCA(SAY1)
> *13:19:48   EDIT32:8 DCA(SAY2)
> *13:19:48   EDIT32:9 DAS   2
> *13:19:48   EDIT32:   10SAY1 DCC'HELLO WORLD '
> *13:19:48   EDIT32:   11SAY2 EQU   *-1
> *13:19:48   EDIT32:   12 END
> *EDIT32>END
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh