🚀 go-pugleaf

On Thu, 9 Aug 2018 15:31:31 -0500, Charles Richmond wrote:
>
> On 8/9/2018 1:45 PM, Rich Alderson wrote:
>> Elliott Roper <nos...@yrl.co.uk> writes:
>>
>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>> PDP-11?
>>
>> Yes, many.
>
> *Not* that I disagree...  but which other computers do you find elegant???

Personally I would say the Zenith Z-100 from 1982
<https://en.wikipedia.org/wiki/Zenith_Z-100>. Because it had two CPUs
(8085 8Bit and 8088 16Bit) so the user could run either CP/M or the so
called Z-DOS. Although this was not compatible with MS-DOS there was a
nice software library available.
-- 
Andreas

My random toughts and comments
https://news-commentaries.blogspot.com/

On Thu, 09 Aug 2018 17:47:11 -0400, Andreas Kohlbach wrote:

> On Thu, 9 Aug 2018 15:31:31 -0500, Charles Richmond wrote:
>>
>> On 8/9/2018 1:45 PM, Rich Alderson wrote:
>>> Elliott Roper <nos...@yrl.co.uk> writes:
>>>
>>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer
>>>> than a PDP-11?
>>>
>>> Yes, many.
>>
>> *Not* that I disagree...  but which other computers do you find
>> elegant???
> 
> Personally I would say the Zenith Z-100 from 1982
> <https://en.wikipedia.org/wiki/Zenith_Z-100>. Because it had two CPUs
> (8085 8Bit and 8088 16Bit) so the user could run either CP/M or the so
> called Z-DOS. Although this was not compatible with MS-DOS there was a
> nice software library available.

More of a kludge than elegant. That could be done with an NEC V20 or V30, 
on one chip. Although a bit later on!

But the DEC Rainbow did the same.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Charles Richmond <nume...@aquaporin4.com> writes:
>On 8/9/2018 1:45 PM, Rich Alderson wrote:
>> Elliott Roper <nos...@yrl.co.uk> writes:
>> 
>>> On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
>>> (in article<21aaeee8-c41a-4442...@googlegroups.com>):
>> 
>>>> Bitsavers uploaded the system manual for the PDP 11/40.
>> 
>>>> http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_System_
>>>> manual.pdf
>> 
>>>> 358 pages, undated.
>> 
>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>> PDP-11?
>> 
>> Yes, many.
>> 
>
>*Not* that I disagree...  but which other computers do you find elegant???

B6700.  B3500.  HP-3000.

And the epitome of the CISC processor, the VAX-11.

On Thu, 09 Aug 2018 17:47:11 -0400, Andreas Kohlbach wrote:

> On Thu, 9 Aug 2018 15:31:31 -0500, Charles Richmond wrote:
>>
>> On 8/9/2018 1:45 PM, Rich Alderson wrote:
>>> Elliott Roper <nos...@yrl.co.uk> writes:
>>>
>>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer
>>>> than a PDP-11?
>>>
>>> Yes, many.
>>
>> *Not* that I disagree...  but which other computers do you find
>> elegant???
> 
> Personally I would say the Zenith Z-100 from 1982
> <https://en.wikipedia.org/wiki/Zenith_Z-100>. Because it had two CPUs
> (8085 8Bit and 8088 16Bit) so the user could run either CP/M or the so
> called Z-DOS. Although this was not compatible with MS-DOS there was a
> nice software library available.


I had a Xerox 16/8 - z80 and 8088 with their own RAM, HD, a very nice cp/
m machine. It had a mouse port on the back of the keyboard - which 
worked, one of the standard Logitech units plugged right in.

> Charles Richmond<nume...@aquaporin4.com>  writes:
> > On 8/9/2018 1:45 PM, Rich Alderson wrote:
> > > Elliott Roper <nos...@yrl.co.uk> writes:
> > >
> > > > On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
> > > > (in article<21aaeee8-c41a-4442...@googlegroups.com>):
> > >
> > > > > Bitsavers uploaded the system manual for the PDP 11/40.
> > >
> > > > > http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_Sy
> > > > > stem_
> > > > > manual.pdf
> > >
> > > > > 358 pages, undated.
> > >
> > > > Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
> > > > PDP-11?
> > >
> > > Yes, many.
> >
> > *Not* that I disagree... but which other computers do you find elegant???

I quite liked the PDP-11 (we ran Unix on a /40 and a /45), and thought the 
VAX-11
(Unix on a /780 and a /750) was generally better; neither would rate as 
favourites.

I agree with the nominations of the Ferranti Pegasus, and of the MU5/ICL 
2900;
and propose the very different English Electric KDF9:

<http://www.findlayw.plus.com/KDF9/>

People tend to focus on the arithmetic stack of the KDF9.
In my view the hardware multiprogramming support and the
internal parallelism are more significant advances.

BTW None of these was the first computer I used.
That was an ICT/ICL 1903. I like that too. 8-)

-- 
Bill Findlay

On Fri, 10 Aug 2018 17:01:56 +0100, Bill Findlay wrote:

> BTW None of these was the first computer I used.
> That was an ICT/ICL 1903. I like that too. 8-)

The first one I used was an Elliott 4130. It had some quite advanced 
features such as the ability to share programs between virtual machines, 
and good multiprogramming support.

I know this because I hacked it a lot.



-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Charles Richmond <nume...@aquaporin4.com> writes:

> On 8/9/2018 1:45 PM, Rich Alderson wrote:
>> Elliott Roper <nos...@yrl.co.uk> writes:

>>> On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
>>> (in article<21aaeee8-c41a-4442...@googlegroups.com>):

>>>> Bitsavers uploaded the system manual for the PDP 11/40.

>>>> http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_System_manual.pdf

>>>> 358 pages, undated.

>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>> PDP-11?

>> Yes, many.

> *Not* that I disagree...  but which other computers do you find elegant???

My first computer was the IBM 1401.  *Not* an elegant architecture, but not
without points of interest.

The first I fell in love with was the IBM System/360, thanks to a high school
graduation gift from a sweetheart, Germain's _Programming the IBM 360_.  One of
these days I'm going to put his simulator on Hercules and go through the
exercises just for giggles.

When introduced to the PDP-10, 8 years later, I found it annoying:  No base
register, only a single index register per instruction, so some of my favorite
tricks simply did not work.  No condition codes; what's with all these SKIPx
and JUMPx and Txxx (test) instructions?  And then a miracle happened.

I still think in EBCDIC, nearly 50 years later, rather than ASCII, which I sort
of learned less than 40 years ago, and I still have a fondness for the 360
instruction architecture, but the orthogonality of the PDP-10 instruction set,
the uniform use of bits 7-8 to indicate no-modification/immediate/memory/self
on all the data movement instructions, the elegance of single instructions to
conditionalize the execution path rather than a sequence in which you have to
be careful of changes to the condition codes you're checking, even the word
addressing rather than byte addressing, have forever spoiled me for lesser
systems.

"But that's just my opinion, I could be wrong." --Dennis Miller

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

On Fri, 10 Aug 2018 15:01:06 -0400, Rich Alderson wrote:

> I still think in EBCDIC, nearly 50 years later, rather than ASCII, which
> I sort of learned less than 40 years ago, and I still have a fondness
> for the 360 instruction architecture, but the orthogonality of the
> PDP-10 instruction set, the uniform use of bits 7-8 to indicate
> no-modification/immediate/memory/self on all the data movement
> instructions, the elegance of single instructions to conditionalize the
> execution path rather than a sequence in which you have to be careful of
> changes to the condition codes you're checking, even the word addressing
> rather than byte addressing, have forever spoiled me for lesser systems.

I was going to mention the PDP-10, but forgot. I did quite a lot of 
assembly language programming on one.

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

Bob Eager <news...@eager.cx> wrote:
> On Fri, 10 Aug 2018 15:01:06 -0400, Rich Alderson wrote:
> 
>> I still think in EBCDIC, nearly 50 years later, rather than ASCII, which
>> I sort of learned less than 40 years ago, and I still have a fondness
>> for the 360 instruction architecture, but the orthogonality of the
>> PDP-10 instruction set, the uniform use of bits 7-8 to indicate
>> no-modification/immediate/memory/self on all the data movement
>> instructions, the elegance of single instructions to conditionalize the
>> execution path rather than a sequence in which you have to be careful of
>> changes to the condition codes you're checking, even the word addressing
>> rather than byte addressing, have forever spoiled me for lesser systems.
> 
> I was going to mention the PDP-10, but forgot. I did quite a lot of 
> assembly language programming on one.
> 

Yes, I loved the -10 too, although I didn't program it extensively. I was
sorry when it was canceled, although I suspect it would have been difficult
to expand the architecture to larger memory sizes.

-- 
Pete

In article <1173318279.555679658.757...@news.eternal-september.org>,
Peter Flass  <peter...@yahoo.com> wrote:
>Yes, I loved the -10 too, although I didn't program it extensively. I was
>sorry when it was canceled, although I suspect it would have been difficult
>to expand the architecture to larger memory sizes.

We don't have to guess.  They did expand the addressing for the DEC-20
and it was pretty ugly.  The extra address bits were called the
section number, with some addressing being within the current section
and some being global.  TOPS-20 supported it but I don't recall many
programs using it.



-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Friday, August 10, 2018 at 4:10:47 PM UTC-6, John Levine wrote:
 
> The PDP-8, on the other hand, was close to perfectly elegant.

The Honeywell H-112, which, unfortunately, was only implemented once, and that 
in a serial machine like the PDP-8/S, had it beat in one way.

It didn't reserve an entire 3-bit opcode for input-output instructions, but put 
them in with the operate microinstructions.

Because of that, instead of DAC and TAD, in addition to an addition instruction, 
it could also have a load instruction and a store instruction.

John Savard

On Saturday, August 11, 2018 at 9:23:08 AM UTC-6, John Levine wrote:
> In article <1173318279.555679658.757...@news.eternal-september.org>,
> Peter Flass  <peter...@yahoo.com> wrote:
> >I was
> >sorry when it was canceled, although I suspect it would have been difficult
> >to expand the architecture to larger memory sizes.

> We don't have to guess.  They did expand the addressing for the DEC-20
> and it was pretty ugly.  The extra address bits were called the
> section number, with some addressing being within the current section
> and some being global.  TOPS-20 supported it but I don't recall many
> programs using it.

The Sigma 9 from Xerox/SDS also took an existing architecture with a full-length 
address in the instruction, and modified it to use more memory than that address 
could support.

I think it was ugly too; but I suppose that it could still be said that if the 
memory expansion method actually used was a kludge, that doesn't prove th at 
something better might not be possible.

John Savard

Quadibloc <jsa...@ecn.ab.ca> wrote:
> On Saturday, August 11, 2018 at 9:23:08 AM UTC-6, John Levine wrote:
>> In article <1173318279.555679658.757...@news.eternal-september.org>,
>> Peter Flass  <peter...@yahoo.com> wrote:
>>> I was
>>> sorry when it was canceled, although I suspect it would have been difficult
>>> to expand the architecture to larger memory sizes.
> 
>> We don't have to guess.  They did expand the addressing for the DEC-20
>> and it was pretty ugly.  The extra address bits were called the
>> section number, with some addressing being within the current section
>> and some being global.  TOPS-20 supported it but I don't recall many
>> programs using it.
> 
> The Sigma 9 from Xerox/SDS also took an existing architecture with a full-length 
> address in the instruction, and modified it to use more memory than that address 
> could support.
> 
> I think it was ugly too; but I suppose that it could still be said that if the 
> memory expansion method actually used was a kludge, that doesn't prove th at 
> something better might not be possible.
> 

The Sigma address space was limited by the use of memory map registers
instead of segment and page tables (unless the 9 did something with this
too). The address space was plenty big enough for programs of the time, but
big databases, photos, or videos would probably have been a stretch.


-- 
Pete

In article <0897e059-0b26-4334...@googlegroups.com>,
Quadibloc  <jsa...@ecn.ab.ca> wrote:
>> >sorry when it was canceled, although I suspect it would have been difficult
>> >to expand the architecture to larger memory sizes.
>
>> We don't have to guess.  They did expand the addressing for the DEC-20
>> and it was pretty ugly. ...

>I think it was ugly too; but I suppose that it could still be said that if the 
>memory expansion method actually used was a kludge, that doesn't prove th at 
>something better might not be possible.

The people who did it were pretty smart.  An obvious alternative would
be a mode bit, like 16 vs 32 bit segments on the 386, and different
instruction formats, but if it's not backward compatible with 18 bit
code, you might as well switch to a Vax, which is what everyone did.

The Vax was a mistake, too, beautifully optimized for a hardware and
software environment that was immediately obsolete, but that's a
different argument.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On Thu, 09 Aug 2018 22:16:29 GMT, scott@slp53.sl.home (Scott Lurndal) wrote:
>Charles Richmond <nume...@aquaporin4.com> writes:
>>On 8/9/2018 1:45 PM, Rich Alderson wrote:
>>> Elliott Roper <nos...@yrl.co.uk> writes:
>>> 
>>>> On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
>>>> (in article<21aaeee8-c41a-4442...@googlegroups.com>):
>>> 
>>>>> Bitsavers uploaded the system manual for the PDP 11/40.
>>> 
>>>>> http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_System_
>>>>> manual.pdf
>>> 
>>>>> 358 pages, undated.
>>> 
>>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>>> PDP-11?
>>> 
>>> Yes, many.
>>
>>*Not* that I disagree...  but which other computers do you find elegant???
>
>B6700.  B3500.  HP-3000.
>
>And the epitome of the CISC processor, the VAX-11.

Sixteen addressing modes, single instructions to calculate CRCs and polynomials,
string translation instructions... the VAX had just about everything except an
opcode for "phase of the moon."  Too many bells and whistles to be considered
elegant, IMO.

On Sun, 12 Aug 2018 15:20:18 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>In article <0897e059-0b26-4334...@googlegroups.com>,
>Quadibloc  <jsa...@ecn.ab.ca> wrote:
>>> >sorry when it was canceled, although I suspect it would have been difficult
>>> >to expand the architecture to larger memory sizes.
>>
>>> We don't have to guess.  They did expand the addressing for the DEC-20
>>> and it was pretty ugly. ...
>
>>I think it was ugly too; but I suppose that it could still be said that if the 
>>memory expansion method actually used was a kludge, that doesn't prove th at 
>>something better might not be possible.
>
>The people who did it were pretty smart.  An obvious alternative would
>be a mode bit, like 16 vs 32 bit segments on the 386, and different
>instruction formats, but if it's not backward compatible with 18 bit
>code, you might as well switch to a Vax, which is what everyone did.
>
>The Vax was a mistake, too, beautifully optimized for a hardware and
>software environment that was immediately obsolete, but that's a
>different argument.

Possibly a result of trying to maintain a bridge to the PDP-11 world.

On 2018-08-13 09:56, Questor wrote:
> On Sun, 12 Aug 2018 15:20:18 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>> In article <0897e059-0b26-4334...@googlegroups.com>,
>> Quadibloc  <jsa...@ecn.ab.ca> wrote:
>>>>> sorry when it was canceled, although I suspect it would have been difficult
>>>>> to expand the architecture to larger memory sizes.
>>>
>>>> We don't have to guess.  They did expand the addressing for the DEC-20
>>>> and it was pretty ugly. ...
>>
>>> I think it was ugly too; but I suppose that it could still be said that if the
>>> memory expansion method actually used was a kludge, that doesn't prove th at
>>> something better might not be possible.
>>
>> The people who did it were pretty smart.  An obvious alternative would
>> be a mode bit, like 16 vs 32 bit segments on the 386, and different
>> instruction formats, but if it's not backward compatible with 18 bit
>> code, you might as well switch to a Vax, which is what everyone did.
>>
>> The Vax was a mistake, too, beautifully optimized for a hardware and
>> software environment that was immediately obsolete, but that's a
>> different argument.
> 
> Possibly a result of trying to maintain a bridge to the PDP-11 world.

I'd disagree. The reason for most of the things in VAX was a result of 
memory being expensive, and people programming in assembler. So, you 
optimized the machine for being able to write programs that used as 
little memory as possible. There are lots of things in the VAX that 
comes from this. And it's definitely targeted at people still writing 
programs in assembler.

But, as mentioned, this was just at the time when this was all becoming 
obsolete. Memory prices continued to drop, while sized grew. Which meant 
that the whole effort at being memory efficient was moot. And people 
started writing less and less in assembler. Instead it started becoming 
more relevant how to make things faster and simpler, memory be damned.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Questor <usenet@only.tnx> wrote:
> On Thu, 09 Aug 2018 22:16:29 GMT, scott@slp53.sl.home (Scott Lurndal) wrote:
>> Charles Richmond <nume...@aquaporin4.com> writes:
>>> On 8/9/2018 1:45 PM, Rich Alderson wrote:
>>>> Elliott Roper <nos...@yrl.co.uk> writes:
>>>> 
>>>>> On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
>>>>> (in article<21aaeee8-c41a-4442...@googlegroups.com>):
>>>> 
>>>>>> Bitsavers uploaded the system manual for the PDP 11/40.
>>>> 
>>>>>> http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_System_
>>>>>> manual.pdf
>>>> 
>>>>>> 358 pages, undated.
>>>> 
>>>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>>>> PDP-11?
>>>> 
>>>> Yes, many.
>>> 
>>> *Not* that I disagree...  but which other computers do you find elegant???
>> 
>> B6700.  B3500.  HP-3000.
>> 
>> And the epitome of the CISC processor, the VAX-11.
> 
> Sixteen addressing modes, single instructions to calculate CRCs and polynomials,
> string translation instructions... the VAX had just about everything except an
> opcode for "phase of the moon."  Too many bells and whistles to be considered
> elegant, IMO.
> 
> 

I probably didn't program it enough to form good habits, but ISTR I spent
an inordinate amount of time deciding whether I  wanted to use the one- 
two-, or three-address instruction forms.

-- 
Pete

usenet@only.tnx (Questor) writes:
>On Thu, 09 Aug 2018 22:16:29 GMT, scott@slp53.sl.home (Scott Lurndal) wrote:
>>Charles Richmond <nume...@aquaporin4.com> writes:
>>>On 8/9/2018 1:45 PM, Rich Alderson wrote:
>>>> Elliott Roper <nos...@yrl.co.uk> writes:
>>>> 
>>>>> On 8 Aug 2018, hanc...@bbs.cpcn.com wrote
>>>>> (in article<21aaeee8-c41a-4442...@googlegroups.com>):
>>>> 
>>>>>> Bitsavers uploaded the system manual for the PDP 11/40.
>>>> 
>>>>>> http://www.bitsavers.org/pdf/dec/pdp11/1140/DEC-11-H40SA-A-D_PDP-11_40_System_
>>>>>> manual.pdf
>>>> 
>>>>>> 358 pages, undated.
>>>> 
>>>>> Thanks. Unbounded nostalgia. Was there ever a more elegant computer than a
>>>>> PDP-11?
>>>> 
>>>> Yes, many.
>>>
>>>*Not* that I disagree...  but which other computers do you find elegant???
>>
>>B6700.  B3500.  HP-3000.
>>
>>And the epitome of the CISC processor, the VAX-11.
>
>Sixteen addressing modes, single instructions to calculate CRCs and polynomials,
>string translation instructions... the VAX had just about everything except an
>opcode for "phase of the moon."  Too many bells and whistles to be considered
>elegant, IMO.
>

As a Macro-32 programmer, I thought it _was_ elegant.   MOVC5!

As for CISC vs RISC, the line has blurred.  Just take a look at the
ARM64 RISC architecture specification (6,666 pages).   Instructions
for CRC, SHA-1, SHA-256, SHA-512, AES, SM3.   2048 bit wide data SIMD
instructions (SVE), etc. at alia. u.s.w.

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0487c.a/index.html

In article <44627835.555851238.7102...@news.eternal-september.org>,
Peter Flass  <peter...@yahoo.com> wrote:
>>> And the epitome of the CISC processor, the VAX-11.
>> 
>> Sixteen addressing modes, single instructions to calculate CRCs and polynomials,
>> string translation instructions... the VAX had just about everything except an
>> opcode for "phase of the moon."  Too many bells and whistles to be considered
>> elegant, IMO.

It suffered from a surprising degree of technical myopia.  The VAX was
designed to be implemented in serial microcode, and was quite painful
to overlap or pipline.  The instruction format was an opcode and a series
of variable length operand descriptors which had to be decoded in order since
one decriptor could modify the register used in a subsequent one, e.g.

 ADDW2 (R3)+,(R3)

It can't fetch the second operand until it's decoded the first one,
since the first one modifies R3.  There were also a lot of absurdly
complex instructions like evaluate polynomial which would have made
a lot more sense as subroutines, at least if they had a lighter
weight subroutine call instruction.

I gather the later Vaxen did complex pipelines with interlocks but it
was a lot of effort to solve a problem that they needn't have created
in the first place.  Compare it to the 360/370 which is carefully
designed so that as soon as you've looked at the opcode you can
evaluate all of the operands in parallel.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <jo...@taugh.com> writes:

> In article <0897e059-0b26-4334...@googlegroups.com>,
> Quadibloc  <jsa...@ecn.ab.ca> wrote:

>> I think it was ugly too; but I suppose that it could still be said that if
>> the memory expansion method actually used was a kludge, that doesn't prove
>> th at something better might not be possible.

> The people who did it were pretty smart.  An obvious alternative would be a
> mode bit, like 16 vs 32 bit segments on the 386, and different instruction
> formats, but if it's not backward compatible with 18 bit code, you might as
> well switch to a Vax, which is what everyone did.

Speaking from personal experience here, no, that's not what they did.

Most PDP-10 customers (where that's a cover term for the entire line) were so
pissed at Digital for the Jupiter cancellation that when they moved off of the
36-bit architecture, they went with anything available which wasn't a Digital
product.

I can say this as the former sales support manager for the manufacturer of an
extended clone of the KL-10 processor in the DECSYSTEM-20.  When we brought the
XKL Toad-1 System to market in 1996, the VP of sales and I did a phone survey
of every potential customer he had ever spoken to, and learned just how many
systems had been decommissioned in the preceding 12 months in favor of one or
another high-end Unix offering or IBM system.  Almost none of them had gone to
VMS or OSF/1 on Alpha (by then, Digital's only hardware offering).

(NB:  Translating titles above, I was the entire customer/sales support
 organization at the time, and he was the entire sales force.  We expected to
 grow.)

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

On Monday, August 13, 2018 at 3:48:10 PM UTC-4, Rich Alderson wrote:
> Most PDP-10 customers (where that's a cover term for the entire line) were so
> pissed at Digital for the Jupiter cancellation that when they moved off of the
> 36-bit architecture, they went with anything available which wasn't a Digital
> product.

I remember talking to a fellow system administrator at another university who said they were going to an entirely Unix-based environment. When I asked why, he replied "We will have a large choice of which vendor we want to be screwed by".

OTOH, if Jupiter had delivered, my understanding (from the far outside) is that it would have been rather late, unacceptably slow, and extremely non-price-competitive.

Wasn't Jupiter from the (approximately) same part of DEC that produced the VAX 86x0 (missed its performance goals, shipped late) and 8650 (fixing the few remaining problems that cause the 8600 to not operate at the design speed)? And the 8670, which should have been the "mid-life kicker" upgrade for the 8600, assuming it shipped at the design speed? And the same (approximate) group that brought us the VAX 9000 family (repeat mantra of late, slow, expensive)?

It would seem in retrospect that the best thing to do would be to give the Jupiter group some sort of award and stick them in another building where they couldn't do any harm, and then make a deal with one of the many non-DEC vendors that already had fast systems. I know the second part (make a deal with a non-DEC vendor) got at least to the discussion phase, as the meeting minutes are over on Bitsavers.

On 2018-08-13 19:07, John Levine wrote:
> In article <44627835.555851238.7102...@news.eternal-september.org>,
> Peter Flass  <peter...@yahoo.com> wrote:
>>>> And the epitome of the CISC processor, the VAX-11.
>>>
>>> Sixteen addressing modes, single instructions to calculate CRCs and polynomials,
>>> string translation instructions... the VAX had just about everything except an
>>> opcode for "phase of the moon."  Too many bells and whistles to be considered
>>> elegant, IMO.
> 
> It suffered from a surprising degree of technical myopia.  The VAX was
> designed to be implemented in serial microcode, and was quite painful
> to overlap or pipline.  The instruction format was an opcode and a series
> of variable length operand descriptors which had to be decoded in order since
> one decriptor could modify the register used in a subsequent one, e.g.
> 
>   ADDW2 (R3)+,(R3)

Decoding is not the problem, and can be done without anything blocking 
anything else.
Evaluation is where you get into "problems", as there can be 
interdependencies. But that has no relevance for the decoding as such.

> It can't fetch the second operand until it's decoded the first one,
> since the first one modifies R3.  There were also a lot of absurdly
> complex instructions like evaluate polynomial which would have made
> a lot more sense as subroutines, at least if they had a lighter
> weight subroutine call instruction.

The VAX do have more light weight subroutine calls than the generic 
CALLS/CALLG. I don't know why people never seem to know this. There is 
the JSB/RSB pair, which is just the simple push the return address and 
jump and nothing more opcodes (and the return is obviously just a pop 
the return address).

> I gather the later Vaxen did complex pipelines with interlocks but it
> was a lot of effort to solve a problem that they needn't have created
> in the first place.  Compare it to the 360/370 which is carefully
> designed so that as soon as you've looked at the opcode you can
> evaluate all of the operands in parallel.

The pipelines VAX implementation happened already in 1984 with the VAX 
8600. Yes, it did take some effort, but it was not as complicated as you 
seem to imply. And all later VAXen was pipelined.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On 2018-08-14 05:47, terry-...@glaver.org wrote:
> On Monday, August 13, 2018 at 3:48:10 PM UTC-4, Rich Alderson wrote:
>> Most PDP-10 customers (where that's a cover term for the entire line) were so
>> pissed at Digital for the Jupiter cancellation that when they moved off of the
>> 36-bit architecture, they went with anything available which wasn't a Digital
>> product.
> 
> I remember talking to a fellow system administrator at another university who said they were going to an entirely Unix-based environment. When I asked why, he replied "We will have a large choice of which vendor we want to be screwed by".

Yeah, that sounds similar to what I heard/saw. They pretty universally 
went with Unix. VMS never got a foot in the door anywhere at any of 
those sites.

> OTOH, if Jupiter had delivered, my understanding (from the far outside) is that it would have been rather late, unacceptably slow, and extremely non-price-competitive.

That's the story, at least (as I remember it). Jupiter was having 
problems with performance and was way late. It was sharing technology 
with Venus (the 8600). And Venus was also late and had performance 
problems. At one point they decided that the were going to rescue Venus 
at the expense of Jupiter, so they pooled the people and resources in 
order to solve the problems on one side at least.

> Wasn't Jupiter from the (approximately) same part of DEC that produced the VAX 86x0 (missed its performance goals, shipped late) and 8650 (fixing the few remaining problems that cause the 8600 to not operate at the design speed)? And the 8670, which should have been the "mid-life kicker" upgrade for the 8600, assuming it shipped at the design speed? And the same (approximate) group that brought us the VAX 9000 family (repeat mantra of late, slow, expensive)?

Yes. Although, the 8600 didn't miss the performance goals, as far as I 
can remember, but it was *way* late. But as far as I can remember, the 
goal was 4x 11/780, and that is what they achieved.

That said though, since it was delayed so much, one could argue that the 
bar should have been raised from the original plans.

8670 don't ring any bells in my head right now, so I can't comment. The 
9000 was done by the same group though, yes. And while it was fast, and 
I don't know if it was late or not, it was certainly way too expensive, 
and the NVAX came out not long after with the same performance on a 
chip, making the 9000 immediately obsolete.

That was one costly adventure...

My brain keeps saying "LCG", for Large systems computer group, as the 
ones being responsible for those machines, along with PDP-10s. Not sure 
if I'm misremembering something, though.

> It would seem in retrospect that the best thing to do would be to give the Jupiter group some sort of award and stick them in another building where they couldn't do any harm, and then make a deal with one of the many non-DEC vendors that already had fast systems. I know the second part (make a deal with a non-DEC vendor) got at least to the discussion phase, as the meeting minutes are over on Bitsavers.

Cancelling the PDP-10 was maybe a mistake in one sense, but at the same 
time, it's hard to believe that the architecture had much of a future 
anyway, even with all the nice bits.

Ultimately, I suspect it was the right decision to kill it. But DEC did 
it in a really bad way. Making a deal with a non-DEC vendor would have 
been a wise move for the short term.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
> Yes. Although, the 8600 didn't miss the performance goals, as far as I 
> can remember, but it was *way* late. But as far as I can remember, the 
> goal was 4x 11/780, and that is what they achieved.

It shipped with some internal optimizations disabled, some of which were fixed by the regular shipment of microcode updates. I think the serial sense bus (that gathered data from each pin of each macrocell array) and wrote it to a state dump file on the console RL02 was more a statement about how nervous they were about the machine's reliability than the declared reason of letting them know exactly which board to bring when a system failed.

The only difference between an up-to-rev-level 8600 and an 8650 are the clock and mbox cache control boards. Every other board in the system is the same, if up to an acceptable rev level. I think that shows pretty clearly that the 8600 didn't meet its internal design goal. The marketing material may have said "4 times a 780" but that came along at a later date. The planned (and dropped) 8670 would have been a more major board swap (think 11/780 to 11/785 upgrade). But by then the writing on the wall was quite clear that "complete" VAX systems (w/ PDP11 mode, full instruction set support in microcode, etc,) were on the way out. 

An undocumented CE mode let you change the fundamental clock in the 86x0, presumably for margin tests when running diagnostics. But some customers found they could run jobs 20% faster. 

> 8670 don't ring any bells in my head right now, so I can't comment. The 
> 9000 was done by the same group though, yes. And while it was fast, and 
> I don't know if it was late or not, it was certainly way too expensive, 

It used to be fun to read the listing fiche (or the equivalent STARLET library) to find out the names of un-announced products. Unfortunately Charlie Matco exposing these caused DEC to change them to filler codes.

The 9000 family was DEC acquiring every company they could find that had something remotely useful, in the theory that DEC could pull off a major architectural triumph (pun semi-intended) the way IBM did with their new packaging on 3090-class CPUs. DEC never did seem to understand that they weren't IBM.

> and the NVAX came out not long after with the same performance on a 
> chip, making the 9000 immediately obsolete.

And making Ken's head explode, once he finally understood.

> My brain keeps saying "LCG", for Large systems computer group, as the 
> ones being responsible for those machines, along with PDP-10s. Not sure 
> if I'm misremembering something, though.

LSG (Large Systems Group), I think.

On Tue, 14 Aug 2018 11:17:31 +0200, Johnny Billquist wrote:

> The VAX do have more light weight subroutine calls than the generic
> CALLS/CALLG. I don't know why people never seem to know this. There is
> the JSB/RSB pair, which is just the simple push the return address and
> jump and nothing more opcodes (and the return is obviously just a pop
> the return address).

One could argue that BSB/RSB are even slightly lighter! :)

-- 
Using UNIX since v6 (1975)...

Use the BIG mirror service in the UK:
 http://www.mirrorservice.org

On 2018-08-14 15:21, Bob Eager wrote:
> On Tue, 14 Aug 2018 11:17:31 +0200, Johnny Billquist wrote:
> 
>> The VAX do have more light weight subroutine calls than the generic
>> CALLS/CALLG. I don't know why people never seem to know this. There is
>> the JSB/RSB pair, which is just the simple push the return address and
>> jump and nothing more opcodes (and the return is obviously just a pop
>> the return address).
> 
> One could argue that BSB/RSB are even slightly lighter! :)

Yes. You win. :-)
I'll blame it on a parity error in my brain.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

terry-...@glaver.org writes:

> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:

>> My brain keeps saying "LCG", for Large systems computer group, as the
>> ones being responsible for those machines, along with PDP-10s. Not sure
>> if I'm misremembering something, though.

> LSG (Large Systems Group), I think.

No, Johnny is correct:  LCG = "Large Computer Group" was the 10/20/Venus crowd.

-- 
Rich Alderson					  ne...@alderson.users.panix.com
      Audendum est, et veritas investiganda; quam etiamsi non assequamur,
	  omnino tamen proprius, quam nunc sumus, ad eam perveniemus.
									--Galen

Rich Alderson <ne...@alderson.users.panix.com> wrote:
> terry-...@glaver.org writes:
> 
>> On Tuesday, August 14, 2018 at 5:43:37 AM UTC-4, Johnny Billquist wrote:
> 
>>> My brain keeps saying "LCG", for Large systems computer group, as the
>>> ones being responsible for those machines, along with PDP-10s. Not sure
>>> if I'm misremembering something, though.
> 
>> LSG (Large Systems Group), I think.
> 
> No, Johnny is correct:  LCG = "Large Computer Group" was the 10/20/Venus crowd.
> 

Where is Barb when you need her?

-- 
Pete

On Friday, August 10, 2018 at 6:10:47 PM UTC-4, John Levine wrote:

> The S/360 was a tour de force but it had plenty of uglies that people
> have been dealing with ever since, the worst of which was 24 bit
> addressing.

I think in the very early 1960s when they envisioned S/360, 24
bit (16 meg) was deemed more than adequate.  Storage was very
expensive back then. I don't believe S/360 ever existed 16 meg,
indeed, I think it took a long time until S/370 even exceeded it.

Our 370-158 had all of 6 meg, serving a large organization and
500 terminals.

On 2018-08-15, hanc...@bbs.cpcn.com <hanc...@bbs.cpcn.com> wrote:

> On Friday, August 10, 2018 at 6:10:47 PM UTC-4, John Levine wrote:
>
>> The S/360 was a tour de force but it had plenty of uglies that people
>> have been dealing with ever since, the worst of which was 24 bit
>> addressing.
>
> I think in the very early 1960s when they envisioned S/360, 24
> bit (16 meg) was deemed more than adequate.  Storage was very
> expensive back then. I don't believe S/360 ever existed 16 meg,
> indeed, I think it took a long time until S/370 even exceeded it.
>
> Our 370-158 had all of 6 meg, serving a large organization and
> 500 terminals.

I never heard of a 360 having a full 16MB, and I suspect that
nobody could justify the cost.  A while after the 370 line came
out, I remember reading in a trade rag how IBM rocked the industry
by slashing the price of a megabyte of memory from $75,000 to a
mere $15,000.  (And those were early-'70s dollars.)

And now SD cards are a dollar a gigabyte.  <shakes head in wonder>

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

In article <pl2en...@news3.newsguy.com>,
Charlie Gibbs  <cgibbs@kltpzyxm.invalid> wrote:
>I never heard of a 360 having a full 16MB, and I suspect that
>nobody could justify the cost.

You couldn't  The /65 had a max of 2M of regular core and 8M of slow LCS core.

The 85 and 195 could have 4M of fast core.  The 91 could have 2M of
fast core and/or 4M of not quite so fast core although I don't know of
anyone who got the 4M.

On the other hand, they were planning for technical evolution at the
time, and it would not have cost them very much to reserve the high
byte of addresses rather than letting the system programmers who were
trying to squash every byte out of OS stick flags there.

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

On 15 Aug 2018 23:58:51 GMT
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:

> And now SD cards are a dollar a gigabyte.  <shakes head in wonder>

	They're way cheaper than that, you can get a decent 128GB micro SD
card from a reputable supplier for less than €35.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Mon, 13 Aug 2018 12:36:49 +0200, Johnny Billquist <b...@softjar.se> wrote:
>On 2018-08-13 09:56, Questor wrote:
>> On Sun, 12 Aug 2018 15:20:18 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>>> In article <0897e059-0b26-4334...@googlegroups.com>,
>>> Quadibloc  <jsa...@ecn.ab.ca> wrote:
>>>>>> sorry when it was canceled, although I suspect it would have been difficult
>>>>>> to expand the architecture to larger memory sizes.
>>>>
>>>>> We don't have to guess.  They did expand the addressing for the DEC-20
>>>>> and it was pretty ugly. ...
>>>
>>>> I think it was ugly too; but I suppose that it could still be said that if the
>>>> memory expansion method actually used was a kludge, that doesn't prove th at
>>>> something better might not be possible.
>>>
>>> The people who did it were pretty smart.  An obvious alternative would
>>> be a mode bit, like 16 vs 32 bit segments on the 386, and different
>>> instruction formats, but if it's not backward compatible with 18 bit
>>> code, you might as well switch to a Vax, which is what everyone did.
>>>
>>> The Vax was a mistake, too, beautifully optimized for a hardware and
>>> software environment that was immediately obsolete, but that's a
>>> different argument.
>> 
>> Possibly a result of trying to maintain a bridge to the PDP-11 world.
>
>I'd disagree. The reason for most of the things in VAX was a result of 
>memory being expensive, and people programming in assembler. So, you 
>optimized the machine for being able to write programs that used as 
>little memory as possible. There are lots of things in the VAX that 
>comes from this. And it's definitely targeted at people still writing 
>programs in assembler.

I can't speak to the intentions of the designers of the VAX instruction set, but
what you said isn't reflected in DEC's own practices.  Most of VMS and its
system software was written in BLISS.  And certainly by the early 1980s, the
overwhelming majority of programmers in Spit Brook (home of the VMS software
groups(s)) were BLISS programmers.  Lots of bits were spent in discussions on
internal message boards about all manner of BLISS arcana; VAX assembly, not so
much.


>But, as mentioned, this was just at the time when this was all becoming 
>obsolete. Memory prices continued to drop, while sized grew. Which meant 
>that the whole effort at being memory efficient was moot. And people 
>started writing less and less in assembler. Instead it started becoming 
>more relevant how to make things faster and simpler, memory be damned.

Coming to the VAX from the PDP-10 world, my own view was that they were
influenced by what seemed like "big" from the PDP-11 point of view.  DEC
certainly had a kind of near-sightedness when it came to imagining the future of
computing which proved fatal over the long term.  That myopia was a contributing
factor to the failure of the Jupiter.  Much of this was hashed out and discussed
ad nausem in alt.sys.pdp10 about fifteen years ago, as you well know.

On 2018-08-16 10:41, Questor wrote:
> On Mon, 13 Aug 2018 12:36:49 +0200, Johnny Billquist <b...@softjar.se> wrote:
>> On 2018-08-13 09:56, Questor wrote:
>>> On Sun, 12 Aug 2018 15:20:18 -0000 (UTC), John Levine <jo...@taugh.com> wrote:
>>>> In article <0897e059-0b26-4334...@googlegroups.com>,
>>>> Quadibloc  <jsa...@ecn.ab.ca> wrote:
>>>>>>> sorry when it was canceled, although I suspect it would have been difficult
>>>>>>> to expand the architecture to larger memory sizes.
>>>>>
>>>>>> We don't have to guess.  They did expand the addressing for the DEC-20
>>>>>> and it was pretty ugly. ...
>>>>
>>>>> I think it was ugly too; but I suppose that it could still be said that if the
>>>>> memory expansion method actually used was a kludge, that doesn't prove th at
>>>>> something better might not be possible.
>>>>
>>>> The people who did it were pretty smart.  An obvious alternative would
>>>> be a mode bit, like 16 vs 32 bit segments on the 386, and different
>>>> instruction formats, but if it's not backward compatible with 18 bit
>>>> code, you might as well switch to a Vax, which is what everyone did.
>>>>
>>>> The Vax was a mistake, too, beautifully optimized for a hardware and
>>>> software environment that was immediately obsolete, but that's a
>>>> different argument.
>>>
>>> Possibly a result of trying to maintain a bridge to the PDP-11 world.
>>
>> I'd disagree. The reason for most of the things in VAX was a result of
>> memory being expensive, and people programming in assembler. So, you
>> optimized the machine for being able to write programs that used as
>> little memory as possible. There are lots of things in the VAX that
>> comes from this. And it's definitely targeted at people still writing
>> programs in assembler.
> 
> I can't speak to the intentions of the designers of the VAX instruction set, but
> what you said isn't reflected in DEC's own practices.  Most of VMS and its
> system software was written in BLISS.  And certainly by the early 1980s, the
> overwhelming majority of programmers in Spit Brook (home of the VMS software
> groups(s)) were BLISS programmers.  Lots of bits were spent in discussions on
> internal message boards about all manner of BLISS arcana; VAX assembly, not so
> much.

True. VMS is a lot of BLISS, and quite some MACRO, and some sprinkling 
of other languages.
So, DEC at least partially did not so as much assembler as was probably 
expected when the design was made.
There is an awful lot of MACRO in there though, which forces every port 
to this day to first of all create a compiler for the new target, for 
MACRO, which is too much to rewrite in some other language.

However, I suspect that with regards to memory use, they probably also 
anticipated that a compact machine code would also be beneficial for 
code generated from compilers, if the compilers were just clever enough. 
Memory prices were definitely a factor no matter what language you might 
be writing in.

>> But, as mentioned, this was just at the time when this was all becoming
>> obsolete. Memory prices continued to drop, while sized grew. Which meant
>> that the whole effort at being memory efficient was moot. And people
>> started writing less and less in assembler. Instead it started becoming
>> more relevant how to make things faster and simpler, memory be damned.
> 
> Coming to the VAX from the PDP-10 world, my own view was that they were
> influenced by what seemed like "big" from the PDP-11 point of view.  DEC
> certainly had a kind of near-sightedness when it came to imagining the future of
> computing which proved fatal over the long term.  That myopia was a contributing
> factor to the failure of the Jupiter.  Much of this was hashed out and discussed
> ad nausem in alt.sys.pdp10 about fifteen years ago, as you well know.

Yup. :-)

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: b...@softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

On Thursday, August 9, 2018 at 6:16:31 PM UTC-4, Scott Lurndal wrote:

> >*Not* that I disagree...  but which other computers do you find elegant???
> 
> B6700.  B3500.  HP-3000.
> 
> And the epitome of the CISC processor, the VAX-11.

Here's an article on the B3500 (right side)
https://books.google.com/books?id=Q5obAAAAIBAJ&lpg=PA30&dq=burroughs%20b3500&pg=PA30#v=onepage&q&f=false

hanc...@bbs.cpcn.com writes:
>On Thursday, August 9, 2018 at 6:16:31 PM UTC-4, Scott Lurndal wrote:
>
>> >*Not* that I disagree...  but which other computers do you find elegant???
>> 
>> B6700.  B3500.  HP-3000.
>> 
>> And the epitome of the CISC processor, the VAX-11.
>
>Here's an article on the B3500 (right side)
>https://books.google.com/books?id=Q5obAAAAIBAJ&lpg=PA30&dq=burroughs%20b3500&pg=PA30#v=onepage&q&f=false
>

The B3500 in that article hosts a compiler that generates
object code for the E8000 accounting system.  It really doesn't
discuss the B3500 much at all.    The smaller B2500 shipped in
Feb 1967, the larger B3500 in May 1967.  As of 1970, 69 had
been shipped and there was a backlog of 190 (many of which went
to the Navy stockpoints program).

The first link for a google search on "Navy stockpoints b3500"
brings up a DTIC document on the B3500, which can also be found
here:

https://archive.org/stream/systemintegratio00klin/systemintegratio00klin_djvu.txt

In article <ff3f1240-fe97-479a...@googlegroups.com>,
 <hanc...@bbs.cpcn.com> wrote:
>On Thursday, August 9, 2018 at 6:16:31 PM UTC-4, Scott Lurndal wrote:
>
>> >*Not* that I disagree...  but which other computers do you find elegant???
>> 
>> B6700.  B3500.  HP-3000.

Here's the B3500 reference manual:

http://bitsavers.org/pdf/burroughs/B2500_B3500/1025517_B2500_B3500_Characteristics_Mar70.pdf

-- 
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

John Levine <jo...@taugh.com> writes:
>In article <ff3f1240-fe97-479a...@googlegroups.com>,
> <hanc...@bbs.cpcn.com> wrote:
>>On Thursday, August 9, 2018 at 6:16:31 PM UTC-4, Scott Lurndal wrote:
>>
>>> >*Not* that I disagree...  but which other computers do you find elegant???
>>> 
>>> B6700.  B3500.  HP-3000.
>
>Here's the B3500 reference manual:
>
>http://bitsavers.org/pdf/burroughs/B2500_B3500/1025517_B2500_B3500_Characteristics_Mar70.pdf
>

And here's a coldstart (IPL) of the penultimate member of the B3500
family (V380).

http://vseries.lurndal.org/doku.php?id=simulator:installation:tarball

On Wednesday, August 15, 2018 at 1:03:44 PM UTC-6, han...@bbs.cpcn.com wrote:
> Storage was very
> expensive back then. I don't believe S/360 ever existed 16 meg,
> indeed, I think it took a long time until S/370 even exceeded it.

Since 16 megabytes was their address space, it's hard to see how any System/360 
(other than a 360/67) _could_ have exceeded it.

John Savard

On 2018-08-16, Ahem A Rivet's Shot <ste...@eircom.net> wrote:

> On 15 Aug 2018 23:58:51 GMT
> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>
>> And now SD cards are a dollar a gigabyte.  <shakes head in wonder>
>
> 	They're way cheaper than that, you can get a decent 128GB micro SD
> card from a reputable supplier for less than €35.

And the beat goes on...

A dollar a gigabyte is so easy to say, though -
even though it is already becoming a bit dated.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

On 2018-08-17, Quadibloc <jsa...@ecn.ab.ca> wrote:

> On Wednesday, August 15, 2018 at 1:03:44 PM UTC-6, han...@bbs.cpcn.com wrote:
>
>> Storage was very
>> expensive back then. I don't believe S/360 ever existed 16 meg,
>> indeed, I think it took a long time until S/370 even exceeded it.
>
> Since 16 megabytes was their address space, it's hard to see how any
> System/360 (other than a 360/67) _could_ have exceeded it.

However, my original point was that nobody could justify the
cost of a 360 that even reached (as opposed to exceeding) the
16MB theoretical limit.

"16MB ought to be enough for anybody."  (Hmmm, where did I hear that?)

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  Fight low-contrast text in web pages!  http://contrastrebellion.com

Quadibloc <jsa...@ecn.ab.ca> wrote:
> On Wednesday, August 15, 2018 at 1:03:44 PM UTC-6, han...@bbs.cpcn.com wrote:
>> Storage was very
>> expensive back then. I don't believe S/360 ever existed 16 meg,
>> indeed, I think it took a long time until S/370 even exceeded it.
> 
> Since 16 megabytes was their address space, it's hard to see how any System/360 
> (other than a 360/67) _could_ have exceeded it.
> 

Cable length was the big problem. If you put the core too far from the CPU
you had to go with slow memory. Each <mumble>K of core needed its own
frame. One of the larger machines had the boxes of core arranged in an "X"
around the CPU to try to reduce cable length. I'm not sure about core, but
I think some large shops put disk controllers one floor down from the CPU
and dropped the channel cables thru the floor to reduce distance.

-- 
Pete

Peter Flass <peter...@yahoo.com> writes:
>Quadibloc <jsa...@ecn.ab.ca> wrote:
>> On Wednesday, August 15, 2018 at 1:03:44 PM UTC-6, han...@bbs.cpcn.com wrote:
>>> Storage was very
>>> expensive back then. I don't believe S/360 ever existed 16 meg,
>>> indeed, I think it took a long time until S/370 even exceeded it.
>> 
>> Since 16 megabytes was their address space, it's hard to see how any System/360 
>> (other than a 360/67) _could_ have exceeded it.
>> 
>
>Cable length was the big problem. If you put the core too far from the CPU
>you had to go with slow memory. Each <mumble>K of core needed its own
>frame. One of the larger machines had the boxes of core arranged in an "X"
>around the CPU to try to reduce cable length. I'm not sure about core, but
>I think some large shops put disk controllers one floor down from the CPU
>and dropped the channel cables thru the floor to reduce distance.

We had a burroughs B6800 with global memory at one of the plants.  To
keep cable lengths in play, they had the memory on the floor immediatly
above the cpu complex and ran the cables down.

Peter Flass <peter...@yahoo.com> writes:
> Cable length was the big problem. If you put the core too far from the CPU
> you had to go with slow memory. Each <mumble>K of core needed its own
> frame. One of the larger machines had the boxes of core arranged in an "X"
> around the CPU to try to reduce cable length. I'm not sure about core, but
> I think some large shops put disk controllers one floor down from the CPU
> and dropped the channel cables thru the floor to reduce distance.

packaging distance ... happened for 3090 ... plus some 3880 disk
controller channel overhead. 3880/3380 increased transfer speed but also
doubled max. channel cable distance (by expanding number of bytes
transferred in single handshake). however they went from a very fast
horizontal microcode controller for 3830 to a very slow verticial
microcode controller for 3880 ... with a hardware side-path for data
transfer. The increased data transfer reduced channel busy, but the
increased 3880 controller overhead more than offset the increased
transfer speed.

3090 assumed 3880 would be same as 3830 controller but with 3380
3mbyte/sec transfer ... however 3880 controller operations were
significantly slower ... significantly driving up channel busy.  As a
result, 3090 trying to have balanced throughput configuration had to
significantly increase number of channels as (partial) offset to the
signifciantly higher 3880 channel busy (which required additional
expensive TCM, joke was 3090 would charge off the manufacturing cost for
the additional TCM to the 3880 controller group). Marketing then try to
resping the enormous increase as channels as terrific I/O capability
(when it was somewhat the opposite).

Also needed significantly more real storage for caching more data &
pages ... helping reduce needed 3880 disk I/O. However, the packaging
distance for the additional real storage exceeded processor memory spec
latency. As a result they came up with "expanded store" wide fast bus
with the higher latency but treated as electronic paging devices with
syncronous 4k move to/from instruction (elapsed time for syncrhonous
move instruction was orders of magnitude less than MVS IO+interrupt
pathlength).

Note 3090 trying to move into scientific market ... addeded vector
processing feature/registers/instructions ... but scientific market also
had HIPPI (100mbyte/sec channel) disk arrays
https://en.wikipedia.org/wiki/HIPPI

3090 I/O wasn't even remotely capable of handling HIPPI speeds. They
finally came up with rube goldberg hack that cut HIPPI into the side of
expanded store bus ... using the synchronous transfer instruction for
peak/poke i/o paradigm.

3090
http://www.bitsavers.com/pdf/ibm/3090/G580-1005-0_The_IBM_3090_Processor_Family_Jul87.pdf
3090 principles of op (1403/3211 printer version)
http://www.bitsavers.org/pdf/ibm/370/princOps/GA22-7000-10_370_Principles_of_Operation_Sep87.pdf

about the time the scientific group in kingston was cutting HIPPI into
the 3090 expanded store bus, I was also working with high-speed access
into Clementi's engineering & scientific kingston lab with half dozen
floating post system boxes (with disk arrays, which may have helped spur
the effort to hook disk arrays into 3090). misc. past posts mentioning
Clementi:
http://www.garlic.com/~lynn/2013i.html#14 The cloud is killing traditional hardware and software
http://www.garlic.com/~lynn/2014b.html#4 IBM Plans Big Spending for the Cloud ($1.2B)
http://www.garlic.com/~lynn/2014c.html#63 11 Years to Catch Up with Seymour
http://www.garlic.com/~lynn/2014c.html#72 11 Years to Catch Up with Seymour
http://www.garlic.com/~lynn/2014j.html#35 curly brace languages source code style quides
http://www.garlic.com/~lynn/2016e.html#95 IBM History
http://www.garlic.com/~lynn/2017h.html#50 System/360--detailed engineering description (AFIPS 1964)
http://www.garlic.com/~lynn/2017j.html#92 mainframe fortran, or A Computer That Never Was: the IBM 7095
http://www.garlic.com/~lynn/2018b.html#47 Think you know web browsers? Take this quiz and prove it

past posts mentioning having HSDT project doing T1 & faster links
http://www.garilc.com/~lynn/subnetwork.html#hsdt
including working with director of NSF for high speed links for
NSF supercomputer centers ... misc. old email
http://www.garlic.com/~lynn/lhwemail.html#nsfnet


-- 
virtualization experience starting Jan1968, online at home since Mar1970

On Sat, 18 Aug 2018 04:27:07 GMT, Anne & Lynn Wheeler <ly...@garlic.com>
wrote: 

> Peter Flass <peter...@yahoo.com> writes:
>> Cable length was the big problem. If you put the core too far from
>> the CPU you had to go with slow memory. Each <mumble>K of core needed
>> its own frame. One of the larger machines had the boxes of core
>> arranged in an "X" around the CPU to try to reduce cable length. I'm
>> not sure about core, but I think some large shops put disk
>> controllers one floor down from the CPU and dropped the channel
>> cables thru the floor to reduce distance. 
> 
> packaging distance ... happened for 3090 ... plus some 3880 disk
> controller channel overhead. 3880/3380 increased transfer speed but
> also doubled max. channel cable distance (by expanding number of bytes
> transferred in single handshake). however they went from a very fast
> horizontal microcode controller for 3830 to a very slow verticial
> microcode controller for 3880 ... with a hardware side-path for data
> transfer. The increased data transfer reduced channel busy, but the
> increased 3880 controller overhead more than offset the increased
> transfer speed.


When I started there was an old chap, nearing retirement, whose main job 
(it seemed) was juggling bits of paper on a plan of the computer room to 
get a new piece of kit and the existing stuff reconfigured for best 
performance.


-- 
Bah, and indeed, Humbug.

On 8/17/2018 1:08 PM, Charlie Gibbs wrote:
> On 2018-08-16, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
> 
>> On 15 Aug 2018 23:58:51 GMT
>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>
>>> And now SD cards are a dollar a gigabyte.  <shakes head in wonder>
>>
>> 	They're way cheaper than that, you can get a decent 128GB micro SD
>> card from a reputable supplier for less than €35.
> 
> And the beat goes on...
> 
> A dollar a gigabyte is so easy to say, though -
> even though it is already becoming a bit dated.
> 

Back 25 years or so ago, I was oblivious to the memory explosion.  In a 
Target store near the toy department, I saw a "memory expansion" for a 
video game console.  The claim on the package said you could save more 
game information about games in progress.

The little memory cartridge had 16 megabytes of memory!  And I recalled 
that was the *max* memory complement for an IBM 370...  We are well 
beyond that now, I realize... but even that shocked me!

-- 
numerist at aquaporin4 dot com

On Sat, 18 Aug 2018 14:04:55 -0500, Charles Richmond
<nume...@aquaporin4.com> wrote:
>On 8/17/2018 1:08 PM, Charlie Gibbs wrote:
>> On 2018-08-16, Ahem A Rivet's Shot <ste...@eircom.net> wrote:
>> 
>>> On 15 Aug 2018 23:58:51 GMT
>>> Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
>>>
>>>> And now SD cards are a dollar a gigabyte.  <shakes head in wonder>
>>>
>>> 	They're way cheaper than that, you can get a decent 128GB micro SD
>>> card from a reputable supplier for less than €35.
>> 
>> And the beat goes on...
>> 
>> A dollar a gigabyte is so easy to say, though -
>> even though it is already becoming a bit dated.
>> 
>
>Back 25 years or so ago, I was oblivious to the memory explosion.  In a 
>Target store near the toy department, I saw a "memory expansion" for a 
>video game console.  The claim on the package said you could save more 
>game information about games in progress.
>
>The little memory cartridge had 16 megabytes of memory!  And I recalled 
>that was the *max* memory complement for an IBM 370...  We are well 
>beyond that now, I realize... but even that shocked me!

Mine came from watching a documentary on the Apollo Space Program. One
of the Apollo astronauts pointing to his watch with calculator, and
mentioning it had more memory than the computer on the Apollo craft.

On Sat, 18 Aug 2018 14:04:55 -0500
Charles Richmond <nume...@aquaporin4.com> wrote:

> The little memory cartridge had 16 megabytes of memory!  And I recalled 
> that was the *max* memory complement for an IBM 370...  We are well 
> beyond that now, I realize... but even that shocked me!


	My moment of shock like that came when I first held a megabyte RAM
module in my hand and remembered standing next to a megabyte that was
taller than me.

-- 
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
The computer obeys and wins.                |    licences available see
You lose and Bill collects.                 |    http://www.sohara.org/

On Thursday, August 9, 2018 at 6:16:31 PM UTC-4, Scott Lurndal wrote:

> >*Not* that I disagree...  but which other computers do you find elegant???
> 
> B6700.  B3500.  HP-3000.

Here's an illustrated 1966 ad for the 3500:  (lower right)

https://books.google.com/books?id=pfFfAAAAIBAJ&lpg=PA53&dq=burroughs%20b%203500&pg=PA53#v=onepage&q=burroughs%20b%203500&f=false

There are other references to the above machines on googlebooks/
newspapers but I'm having trouble bringing them up.