Gordon Bell, who was Vice-President of Engineering at DEC 1972-83 is
still alive and documenting much of his life on the web. There's DEC
stuff at https://gordonbell.azurewebsites.net/Digital/DECMuseum.htm

Something particularly interesting is this document on DEC strategy as of
1979:

https://gordonbell.azurewebsites.net/Digital/VAX%20Strategy%20c1979.pdf

At the time, DEC's other active product ranges were PDP-8, DEC-10/DEC-20
and PDP-11. They had decided in 1975 to create an architecture that built
upwards from the PDP-11, rather than building lower-cost DEC-10 machines.
The reasons for doing that were the large installed base of PDP-11s and
the convenience of 8-bit bytes for data communications, especially with
IBM mainframes.

As of 1978/70 they had achieved this and were deciding what to do next.
The strategy expressed in this document is to continue to sell the other
ranges, but concentrate development efforts on the VAX family, and that's
what basically happened. Using a single architecture is seen as a
competitive advantage against IBM's proliferation of incompatible
architectures, which is pretty reasonable, since IBM saw the same problem.

Bell regards competition from "zero cost" microprocessors such as the
8086 and 68000 as likely more significant than other minicomputer
companies, but fails to make a plan to deal with them. DEC was eventually
defeated by 80386 and later PCs and RISC workstations, and that failure
seems to start here. He assumes that DEC can dominate the market for
terminals for its minis by using PDP-11 and VAX microprocessors, but
doesn't seem to realise that compatible terminals can be built at much
lower cost using third-party microprocessors. In any case, the
replacement of minis by PCs and workstations meant that the terminal
market basically vanished.

The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
in 1982 seems implausible now, but it seems to have been the reason for
512-byte pages. Bell praises the extremely compact VAX instruction set
and its elaborate function calls, without appreciating the ways they will
come to inhibit pipelining and out-of-order execution, and thus doom the
architecture to uncompetitive performance.

John

On 2023-09-24 16:10, John Dallman wrote:
> Gordon Bell, who was Vice-President of Engineering at DEC 1972-83 is
> still alive and documenting much of his life on the web. There's DEC
> stuff at https://gordonbell.azurewebsites.net/Digital/DECMuseum.htm
>
> Something particularly interesting is this document on DEC strategy as of
> 1979:
>
> https://gordonbell.azurewebsites.net/Digital/VAX%20Strategy%20c1979.pdf
>
> At the time, DEC's other active product ranges were PDP-8, DEC-10/DEC-20
> and PDP-11. They had decided in 1975 to create an architecture that built
> upwards from the PDP-11, rather than building lower-cost DEC-10 machines.
> The reasons for doing that were the large installed base of PDP-11s and
> the convenience of 8-bit bytes for data communications, especially with
> IBM mainframes.
>
> As of 1978/70 they had achieved this and were deciding what to do next.
> The strategy expressed in this document is to continue to sell the other
> ranges, but concentrate development efforts on the VAX family, and that's
> what basically happened. Using a single architecture is seen as a
> competitive advantage against IBM's proliferation of incompatible
> architectures, which is pretty reasonable, since IBM saw the same problem.
>
>
> Bell regards competition from "zero cost" microprocessors such as the
> 8086 and 68000 as likely more significant than other minicomputer
> companies, but fails to make a plan to deal with them. DEC was eventually
> defeated by 80386 and later PCs and RISC workstations, and that failure
> seems to start here. He assumes that DEC can dominate the market for
> terminals for its minis by using PDP-11 and VAX microprocessors, but
> doesn't seem to realise that compatible terminals can be built at much
> lower cost using third-party microprocessors. In any case, the
> replacement of minis by PCs and workstations meant that the terminal
> market basically vanished.
>
> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
> in 1982 seems implausible now, but it seems to have been the reason for
> 512-byte pages. Bell praises the extremely compact VAX instruction set
> and its elaborate function calls, without appreciating the ways they will
> come to inhibit pipelining and out-of-order execution, and thus doom the
> architecture to uncompetitive performance.

It's always easy to see mistakes after the fact.
When the VAX was designed, as well as around 1980, memory was still
rather expensive. An instruction set that lead to smaller binaries was a
big win at that point in time.

What you could possibly argue was that DEC didn't enough see or
anticipate the drop in price of memory, which would lead to totally
different constraints and optimal points.

VMS was never expected to run on something with 64K. You couldn't even
run a reasonable PDP-11 on that little memory at that point. (I said
responable, for anyone dragging out a minimal RT-11 system.)

But VAX was most definitely designed for getting programs more memory
efficient. More addressing modes, more things done in microcode to deal
with things in a single instruction. Very variable length
instructions... All was about memory cost. Which made a lot of sense
between 1970 and 1985. After that, memory was becoming so cheap there
was no reason for the optimization angle the VAX had taken. And you had
the rise of RISC.

Johnny

On 9/24/2023 10:29 AM, Johnny Billquist wrote:
> On 2023-09-24 16:10, John Dallman wrote:
>> Gordon Bell, who was Vice-President of Engineering at DEC 1972-83 is
>> still alive and documenting much of his life on the web. There's DEC
>> stuff at https://gordonbell.azurewebsites.net/Digital/DECMuseum.htm
>>
>> Something particularly interesting is this document on DEC strategy as of
>> 1979:
>>
>> https://gordonbell.azurewebsites.net/Digital/VAX%20Strategy%20c1979.pdf
>>
>> At the time, DEC's other active product ranges were PDP-8, DEC-10/DEC-20
>> and PDP-11. They had decided in 1975 to create an architecture that built
>> upwards from the PDP-11, rather than building lower-cost DEC-10 machines.
>> The reasons for doing that were the large installed base of PDP-11s and
>> the convenience of 8-bit bytes for data communications, especially with
>> IBM mainframes.
>>
>> As of 1978/70 they had achieved this and were deciding what to do next.
>> The strategy expressed in this document is to continue to sell the other
>> ranges, but concentrate development efforts on the VAX family, and that's
>> what basically happened. Using a single architecture is seen as a
>> competitive advantage against IBM's proliferation of incompatible
>> architectures, which is pretty reasonable, since IBM saw the same problem.
>>
>>
>> Bell regards competition from "zero cost" microprocessors such as the
>> 8086 and 68000 as likely more significant than other minicomputer
>> companies, but fails to make a plan to deal with them. DEC was eventually
>> defeated by 80386 and later PCs and RISC workstations, and that failure
>> seems to start here. He assumes that DEC can dominate the market for
>> terminals for its minis by using PDP-11 and VAX microprocessors, but
>> doesn't seem to realise that compatible terminals can be built at much
>> lower cost using third-party microprocessors. In any case, the
>> replacement of minis by PCs and workstations meant that the terminal
>> market basically vanished.
>>
>> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
>> in 1982 seems implausible now, but it seems to have been the reason for
>> 512-byte pages. Bell praises the extremely compact VAX instruction set
>> and its elaborate function calls, without appreciating the ways they will
>> come to inhibit pipelining and out-of-order execution, and thus doom the
>> architecture to uncompetitive performance.
>
> It's always easy to see mistakes after the fact.
> When the VAX was designed, as well as around 1980, memory was still rather
> expensive. An instruction set that lead to smaller binaries was a big win at
> that point in time.
>
> What you could possibly argue was that DEC didn't enough see or anticipate the
> drop in price of memory, which would lead to totally different constraints and
> optimal points.
>
> VMS was never expected to run on something with 64K. You couldn't even run a
> reasonable PDP-11 on that little memory at that point. (I said responable, for
> anyone dragging out a minimal RT-11 system.)
>
> But VAX was most definitely designed for getting programs more memory efficient.
> More addressing modes, more things done in microcode to deal with things in a
> single instruction. Very variable length instructions... All was about memory
> cost. Which made a lot of sense between 1970 and 1985. After that, memory was
> becoming so cheap there was no reason for the optimization angle the VAX had
> taken. And you had the rise of RISC.
>
> Johnny
>

Well, you're right about "after the fact" ...

I cannot remember exactly when the first C-VAX came out, but when it did, DEC
then made the fatal mistake. I'm not sure they actually had any options. The
company was rather "top heavy" with many employees to support.

If DEC had went after the low end market with the C-VAX, I really feel that DEC
would still be with us today. Since PC users don't have large budgets for
support and such, DEC would have had to downsize the labor force, and that was
something they would have a hard time with.

Doesn't matter, cause that was and is the direction the market was heading, even
back then. It could not be resisted.

But, figure a low cost VAX vs the PCs of the day. With good marketing, and
pricing, Intel would not have become what they are today.

It was going to happen anyway, DEC resisting, just killed the company.

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

In article <ueph3e$lj1$1@news.misty.com>, bqt@softjar.se (Johnny
Billquist) wrote:

> What you could possibly argue was that DEC didn't enough see or
> anticipate the drop in price of memory, which would lead to totally
> different constraints and optimal points.

Indeed. Nor did they look at the history of the art of making computers
faster. The VAX architecture was implemented readily enough at first, but
made pipelining, out-of-order and other ideas that had been invented in
the 1950s and 1960s hard to add.

> VMS was never expected to run on something with 64K. You couldn't
> even run a reasonable PDP-11 on that little memory at that point.
> (I said responable, for anyone dragging out a minimal RT-11 system.)

I agree it seems crazy, but that's what the paper says, on page 14:

. . . a range of 64 Kbytes of RAM and ROM for VMS in the terminal
to as much as 32 Mbytes in the large configuration . . .

John

On Sunday, September 24, 2023 at 7:10:45 AM UTC-7, John Dallman wrote:

(snip)

> As of 1978/70 they had achieved this and were deciding what to do next.
> The strategy expressed in this document is to continue to sell the other
> ranges, but concentrate development efforts on the VAX family, and that's
> what basically happened. Using a single architecture is seen as a
> competitive advantage against IBM's proliferation of incompatible
> architectures, which is pretty reasonable, since IBM saw the same problem..

(snip)

> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
> in 1982 seems implausible now, but it seems to have been the reason for
> 512-byte pages. Bell praises the extremely compact VAX instruction set
> and its elaborate function calls, without appreciating the ways they will
> come to inhibit pipelining and out-of-order execution, and thus doom the
> architecture to uncompetitive performance.

I was thinking not so long ago, and wrote it into some thread, about how
bad VAX design is for pipelining and OoO execution.

A tiny change would have made a bid difference, if someone thought
about it earlier.

The way VAX addressing modes work, is each operand has a mode byte
followed by any offsets that go with it. Then the next mode byte and offset.
If instead, all mode bytes were together, followed by the offsets, it
would have been much easier to do OoO processing.

The most important thing you want, when you start reading an instruction,
is to know where the next one is. For IBM S/360, you always know from the
first byte where the next instruction is. Even with the above change, it isn't
easy for VAX, but would be close.

You could put the first 8 or so bytes in a register, and then enough logic
to decode the address mode bytes, and know where the next one was.

VAX is very well designed for serial, microprogrammed processing,
where you read a mode byte, process it along with its offset, then go on
to the next one. There are probably even better ways to change it, but
that one would have been (if done early) so easy, and yet wasn't.

VAX is also nicely designed to make it easy for assembly programmers,
just at the time that just about everyone was moving away from assembly
programming. And the 512 byte page size was too small.

On 24/09/2023 17:09, John Dallman wrote:
> In article <ueph3e$lj1$1@news.misty.com>, bqt@softjar.se (Johnny
> Billquist) wrote:
>
>> What you could possibly argue was that DEC didn't enough see or
>> anticipate the drop in price of memory, which would lead to totally
>> different constraints and optimal points.
>
> Indeed. Nor did they look at the history of the art of making computers
> faster. The VAX architecture was implemented readily enough at first, but
> made pipelining, out-of-order and other ideas that had been invented in
> the 1950s and 1960s hard to add.
>
>> VMS was never expected to run on something with 64K. You couldn't
>> even run a reasonable PDP-11 on that little memory at that point.
>> (I said responable, for anyone dragging out a minimal RT-11 system.)
>
> I agree it seems crazy, but that's what the paper says, on page 14:
>
> . . . a range of 64 Kbytes of RAM and ROM for VMS in the terminal
> to as much as 32 Mbytes in the large configuration . . .
>
> John

My first Vax (after PDP 11/44) was 8530 with a massive 32Mb, and 3 off
428Mb disks

hat handles 60 to 80 production users, 2 test systems (not my idea) and
a backup for our Central Ingres set up!

It was still way faster than the old PDP

--
Chris

In article <uepms6$1ds91$1@dont-email.me>, davef@tsoft-inc.com (Dave
Froble) wrote:

> Well, you're right about "after the fact" ...

Yup.

> I cannot remember exactly when the first C-VAX came out, but when
> it did, DEC then made the fatal mistake. I'm not sure they
> actually had any options. The company was rather "top heavy" with
> many employees to support.

CVAX systems were available in 1987, according to Wikipedia. But it's a
multi-chip set, more expensive to manufacture and build boards for than
an Intel 80386.

> If DEC had went after the low end market with the C-VAX, I really
> feel that DEC would still be with us today.

Maybe. The MS-DOS hardware and software industry was already very well
established, and competition had driven hardware prices down a lot. DEC
would have had to pick some niches to target and win several of them.

> Since PC users don't have large budgets for support and such, DEC
> would have had to downsize the labor force, and that was something
> they would have a hard time with.

They'd also have to make system administration easy for first-timers, and
condense the documentation a lot. It's a hard thing to do while you're
cutting staff.

John

On 9/24/2023 1:43 PM, Chris Townley wrote:
>
>
> My first Vax (after PDP 11/44) was 8530 with a massive 32Mb, and 3 off
> 428Mb disks
>
> hat handles 60 to 80 production users, 2 test systems (not my idea) and
> a backup for our Central Ingres set up!
>
> It was still way faster than the old PDP
>

That's like comparing an IBM 1401 and 4331. The first VAX I worked
with was an 11/750 and compared to my 11/44's it was a real dog.

bill

On 9/24/2023 10:29 AM, Johnny Billquist wrote:
> On 2023-09-24 16:10, John Dallman wrote:
>> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
>> in 1982 seems implausible now, but it seems to have been the reason for
>> 512-byte pages.

> VMS was never expected to run on something with 64K. You couldn't even
> run a reasonable PDP-11 on that little memory at that point. (I said
> responable, for anyone dragging out a minimal RT-11 system.)

What was the smallest VAX memory wise?

I think I have heard about 256 KB VAX 780's. Can anyone confirm?

Arne

On Sunday, September 24, 2023 at 6:48:56 PM UTC-4, Arne Vajhøj wrote:
> On 9/24/2023 10:29 AM, Johnny Billquist wrote:
> > On 2023-09-24 16:10, John Dallman wrote:
> >> The idea of running VMS on a terminal with a total of 64KB of RAM and ROM
> >> in 1982 seems implausible now, but it seems to have been the reason for
> >> 512-byte pages.
> > VMS was never expected to run on something with 64K. You couldn't even
> > run a reasonable PDP-11 on that little memory at that point. (I said
> > responable, for anyone dragging out a minimal RT-11 system.)
> What was the smallest VAX memory wise?
>
> I think I have heard about 256 KB VAX 780's. Can anyone confirm?
>
> Arne
The 780 had hex height boards that were 256KB each. Ours was one of the largest of those at the universities at the time with 1-1/4 MB (5 boards) when it first arrived. Supported 50+ terminals with it too!!

Dan

In article <6c594b48-68c2-4400-9f79-9fc15635ceefn@googlegroups.com>,
gah4@u.washington.edu (gah4) wrote:

> The most important thing you want, when you start reading an
> instruction, is to know where the next one is. For IBM S/360,
> you always know from the first byte where the next instruction
> is. Even with the above change, it isn't easy for VAX, but
> would be close.

I wonder if that was deliberate for S/360? The original paper on the
architecture does not mention anything about the encoding; a really old
copy of the "Principles of Operation" would be interesting.

John

On Sunday, September 24, 2023 at 11:48:43 PM UTC-7, John Dallman wrote:
> In article <6c594b48-68c2-4400...@googlegroups.com>,

(I wrote)
> > The most important thing you want, when you start reading an
> > instruction, is to know where the next one is. For IBM S/360,
> > you always know from the first byte where the next instruction
> > is. Even with the above change, it isn't easy for VAX, but
> > would be close.

> I wonder if that was deliberate for S/360? The original paper on the
> architecture does not mention anything about the encoding; a really old
> copy of the "Principles of Operation" would be interesting.
Some parts were amazingly lucky in that virtual machines work well.

One interesting one is that when S/360 machines have nothing else to
do, they stop executing instructions. There is no idle loop.

The reason for that, is that for rented machines they charged based on
actual usage. There is a meter that measures how often it is not in
a wait state.

But S/360 came not so long after Stretch, designed to be fast and where
many pipelined processor ideas started. Early on, there was the 360/92,
later replaced by the model 91, using pipelining techniques.

One not talked about much, but that I have known for a long time, is
that hexadecimal floating point is more convenient for pipelining.

S/360 has three instruction lengths, which you know from the first
two bits of the opcode, Even if you are not designing a fancy processor,
it is nice to know where the next instruction is. While S/360 is not RISC,
compared to VAX, it looks very RISCy.

The book by Blaauw and Brooks, "Computer Architecture" describes
many architectures, but includes some details that actually went
into S/360, because they designed it.

The one I am remembering now is the big endian choice, which they
believe is the right choice. The VMS DUMP program shows why.

It might be in there.

Arne Vajhøj <arne@vajhoej.dk> wrote:
> What was the smallest VAX memory wise?
> I think I have heard about 256 KB VAX 780's. Can anyone confirm?

I system managed VAX 11/780 serial 000047 in 1979. The original order was
for 256K memory, but we upped it to 768K (3/4 MB) before delivery. It ran
the complete computing of the company, including six programmers, and we
sold time on it to at least four other high tech Cambridge companies -
Shape Data, GDS, Nine Tiles, and whatever Dick Newell’s company was called
at the time (CIS?).

--
Paul at the paulhardy.net domain

On Mon, 2023-09-25 at 14:37 +0100, Paul Hardy wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote:
> > What was the smallest VAX memory wise?
> > I think I have heard about 256 KB VAX 780's. Can anyone confirm?
>
> I system managed VAX 11/780 serial 000047 in 1979. The original order
> was for 256K memory, but we upped it to 768K (3/4 MB) before
> delivery. It ran the complete computing of the company, including six
> programmers, and we sold time on it to at least four other high tech
> Cambridge companies
> -
> Shape Data, GDS, Nine Tiles, and whatever Dick Newell’s company was
> called at the time (CIS?).

I seem to remember Microsoft also used VAX machines to build Windows in
the early days. Was that true?
--
Tactical Nuclear Kittens

In article <cb83004a-46f6-424f-8b3d-6879af803e86n@googlegroups.com>,
gah4@u.washington.edu (gah4) wrote:

> One not talked about much, but that I have known for a long time, is
> that hexadecimal floating point is more convenient for pipelining.

Do you have a citation for that? I've been updating Wikipedia's page on
hexFP, simply because I'd dug into the idea a bit, and started to realise
why it lost more precision than the architects had expected.

> The book by Blaauw and Brooks, "Computer Architecture" describes
> many architectures, but includes some details that actually went
> into S/360, because they designed it.

Ordered a used volume 1.

John

On 9/25/2023 10:14 AM, Single Stage to Orbit wrote:
> On Mon, 2023-09-25 at 14:37 +0100, Paul Hardy wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> What was the smallest VAX memory wise?
>>> I think I have heard about 256 KB VAX 780's. Can anyone confirm?
>>
>> I system managed VAX 11/780 serial 000047 in 1979. The original order
>> was for 256K memory, but we upped it to 768K (3/4 MB) before
>> delivery. It ran the complete computing of the company, including six
>> programmers, and we sold time on it to at least four other high tech
>> Cambridge companies
>
> I seem to remember Microsoft also used VAX machines to build Windows in
> the early days. Was that true?

Create cross-compiler/cross-assembler for VMS VAX and run
on a VAX 8000 series or 6000 series?

I have never heard about it. And I am skeptical about it - it seems
like lot of extra development and more upload/download for a
modest speed advantage.

Arne

On Monday, September 25, 2023 at 11:29:39 AM UTC-7, John Dallman wrote:
> In article <cb83004a-46f6-424f...@googlegroups.com>,
> ga...@u.washington.edu (gah4) wrote:
> > One not talked about much, but that I have known for a long time, is
> > that hexadecimal floating point is more convenient for pipelining.

> Do you have a citation for that? I've been updating Wikipedia's page on
> hexFP, simply because I'd dug into the idea a bit, and started to realise
> why it lost more precision than the architects had expected.

I don't, though there is a little in the Blaauw and Brooks book.

Some time ago, I was thinking about how to do floating point,
and especially fast floating point, on an FPGA.
(Not much need for slow floating point.)

The biggest part of an adder is the barrel shifter for pre,
and post-normalization. That is, logic to shift N digits
in one operation. (No clocked shift register.) It is much easier
(and smaller) in a higher radix.

In an FPGA with LUT4 logic, that takes N levels for
pre-normalization, one level to do the add/subtract, and
N levels for post normalization.

As with the previous question, if they were planning the 360/91
(well, 92) from the beginning, that might have been considered.

The 91 does floating point addition in two clock cycles, multiply in three,
single precision divide in 12, and double precision in 18.
The divide algorithm is based on using the parallel multiplier
used for multiply. Normalization isn't the biggest part of
those, so it isn't quite as obvious as you might want.

The other advantage of hexadecimal floating point, is that it
is a lot easier to read in hex dumps.

In a microprogrammed machine, you can shift in hex digits.

On Monday, September 25, 2023 at 8:01:21 AM UTC-7, Single Stage to Orbit wrote:

(snip)

> I seem to remember Microsoft also used VAX machines to build Windows in
> the early days. Was that true?

The early days of MS were on PDP-10s. The Living Computer Museum
has the first KS-10 that MS used. Paul Allen really liked the PDP-10,
and that was the first computer Paul and Bill did much of the work on.

I suspect that as DEC went to VAX, MS would have done that, too,
but I don't know that one at all.

I suspect that if they had a choice, it would have been PDP-10 forever.

In article <01509bf320b2688f715eddaa48694ef329c67182.camel@munted.eu>,
alex.buell@munted.eu (Single Stage to Orbit) wrote:

> I seem to remember Microsoft also used VAX machines to build
> Windows in the early days. Was that true?

Using big machines would have been more plausible in the earlier days of
Microsoft, when they produced BASIC interpreters and other languages for
8- and 16-bit micros, and did a lot of CP/M implementations. By the time
they were developing Windows in the mid- to late 1980s, the machines that
it ran on were more adequate for development than in the early days.

John

On 9/25/2023 10:14 AM, Single Stage to Orbit wrote:
> On Mon, 2023-09-25 at 14:37 +0100, Paul Hardy wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> What was the smallest VAX memory wise?
>>> I think I have heard about 256 KB VAX 780's. Can anyone confirm?
>>
>> I system managed VAX 11/780 serial 000047 in 1979. The original order
>> was for 256K memory, but we upped it to 768K (3/4 MB) before
>> delivery. It ran the complete computing of the company, including six
>> programmers, and we sold time on it to at least four other high tech
>> Cambridge companies
>> -
>> Shape Data, GDS, Nine Tiles, and whatever Dick Newell’s company was
>> called at the time (CIS?).
>
> I seem to remember Microsoft also used VAX machines to build Windows in
> the early days. Was that true?
>

Alpha Ultimate workstations (AlphaServer 1200) were used for the initial 64 bit
WEENDOZE.

I seem to remember Gates and co using PDP-10 systems for some early stuff. The
early Basic for sure.

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

> -----Original Message-----
> From: Info-vax <info-vax-bounces@rbnsn.com> On Behalf Of Dave Froble via
> Info-vax
> Sent: Monday, September 25, 2023 8:53 PM
> To: info-vax@rbnsn.com
> Cc: Dave Froble <davef@tsoft-inc.com>
> Subject: Re: [Info-vax] Reading Gordon Bell's VAX strategy document
>
> On 9/25/2023 10:14 AM, Single Stage to Orbit wrote:
> > On Mon, 2023-09-25 at 14:37 +0100, Paul Hardy wrote:
> >> Arne Vajhøj <arne@vajhoej.dk> wrote:
> >>> What was the smallest VAX memory wise?
> >>> I think I have heard about 256 KB VAX 780's. Can anyone confirm?
> >>
> >> I system managed VAX 11/780 serial 000047 in 1979. The original order
> >> was for 256K memory, but we upped it to 768K (3/4 MB) before
> >> delivery. It ran the complete computing of the company, including six
> >> programmers, and we sold time on it to at least four other high tech
> >> Cambridge companies
> >> -
> >> Shape Data, GDS, Nine Tiles, and whatever Dick Newell’s company was
> >> called at the time (CIS?).
> >
> > I seem to remember Microsoft also used VAX machines to build Windows
> > in the early days. Was that true?
> >
>
> Alpha Ultimate workstations (AlphaServer 1200) were used for the initial 64
> bit WEENDOZE.
>
> I seem to remember Gates and co using PDP-10 systems for some early stuff.
> The early Basic for sure.
>
> --
[]

For a very interesting read about VAX architecture history

<https://ipfs.io/ipfs/QmdA5WkDNALetBn4iFeSepHjdLGJdxPBwZyY47ir1bZGAK/comp/vax.html>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com

In article <01509bf320b2688f715eddaa48694ef329c67182.camel@munted.eu>,
Single Stage to Orbit <alex.buell@munted.eu> wrote:
>On Mon, 2023-09-25 at 14:37 +0100, Paul Hardy wrote:
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> > What was the smallest VAX memory wise?
>> > I think I have heard about 256 KB VAX 780's. Can anyone confirm?
>>
>> I system managed VAX 11/780 serial 000047 in 1979. The original order
>> was for 256K memory, but we upped it to 768K (3/4 MB) before
>> delivery. It ran the complete computing of the company, including six
>> programmers, and we sold time on it to at least four other high tech
>> Cambridge companies
>
>I seem to remember Microsoft also used VAX machines to build Windows in
>the early days. Was that true?

The early days of Windows NT are well-documented in the book,
"Show Stopper!" by G. Pascal Zachary. In short, they used OS/2
and 386 machines; NT was self-hosting within a couple of years.

- Dan C.

On 26/09/2023 01:15, Dan Cross wrote:
> In article <01509bf320b2688f715eddaa48694ef329c67182.camel@munted.eu>,
> Single Stage to Orbit <alex.buell@munted.eu> wrote:
>> On Mon, 2023-09-25 at 14:37 +0100, Paul Hardy wrote:
>>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>>> What was the smallest VAX memory wise?
>>>> I think I have heard about 256 KB VAX 780's. Can anyone confirm?
>>>
>>> I system managed VAX 11/780 serial 000047 in 1979. The original order
>>> was for 256K memory, but we upped it to 768K (3/4 MB) before
>>> delivery. It ran the complete computing of the company, including six
>>> programmers, and we sold time on it to at least four other high tech
>>> Cambridge companies
>>
>> I seem to remember Microsoft also used VAX machines to build Windows in
>> the early days. Was that true?
>
> The early days of Windows NT are well-documented in the book,
> "Show Stopper!" by G. Pascal Zachary. In short, they used OS/2
> and 386 machines; NT was self-hosting within a couple of years.
>
> - Dan C.

I still miss OS/2 - it was great to use, but a bugger to program the
presentation layer, or whatever it was called

--
Chris

On Sunday, September 24, 2023 at 7:29:05 AM UTC-7, Johnny Billquist wrote:

(snip)

> VMS was never expected to run on something with 64K. You couldn't even
> run a reasonable PDP-11 on that little memory at that point. (I said
> responable, for anyone dragging out a minimal RT-11 system.)

> But VAX was most definitely designed for getting programs more memory
> efficient. More addressing modes, more things done in microcode to deal
> with things in a single instruction. Very variable length
> instructions... All was about memory cost. Which made a lot of sense
> between 1970 and 1985. After that, memory was becoming so cheap there
> was no reason for the optimization angle the VAX had taken. And you had
> the rise of RISC.

IBM S/360 was designed around about 1963.

There are machines down to 8K bytes, all magnetic core memory.

The first use of semiconductor RAM in a commercial computer is
the memory protection keys in the 360/91, four bits for every 2K
of core. That is built from 16 bit bipolar RAM chips.

On Monday, September 25, 2023 at 5:37:22 PM UTC-7, Chris Townley wrote:

(snip)

> I still miss OS/2 - it was great to use, but a bugger to program the
> presentation layer, or whatever it was called
I did character mode programming on OS/2 back to version 1.0.

One of the early ones that I did was to port GNU utilities including diff
and grep. That wasn't quite as nice as a full Unix system, but not so bad
for development and debugging.

Much of that was working on programs that would run under DOS for
others, but I ran mine on OS/2.

At some point, I would allocate segments directly from OS/2 instead
of using malloc(). That allowed for full memory protection, read or write,
outside of any array.