Re: [Simh] VAX 750 and 730 (was Is it possible to simulate the first Vaxen I ever used?)

[Matt Burke]

On 23/03/2020 19:16, Bob Supnik wrote:
> One of the problems with simulating the non-VLSI VAXen, other than the
> 780, is that the microcode is not available. Back at DEC, I had the
> 730 microcode in a huge notebook (it was 16KW), but I discarded it
> when I moved out of Hudson and downsized my document collection. We
> really need the microcode for the 750, 730, 8600/8650, 8200 (V11), and
> 8800.
>
> The various microcodes may be available in the DEC fiche collection at
> CHM, but I haven't been able to get out there to do the research, and
> travel is out of the question right now.
>
The 11/750 microcode listing is available on Bitsavers (not under the
directory you might expect though):

http://www.bitsavers.org/pdf/dec/pdp11/xxdp/fiche_200dpi/0187_CMT098.MCX_750uCod.pdf

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

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

[Paul Koning]

> On Mar 23, 2020, at 5:49 PM, Ray Jewhurst  wrote:
> 
> Slightly off topic, could someone explain more about what microcode is and 
> how it works? The fact that the CPU instructions are they themselves 
> programmed in seems unfathomable. 
> 
> Ray 

It's about a cost vs. performance tradeoff.  Many computers have quite complex 
instructions.  While it's always possible to implement them as big hunks of 
logic circuitry, that isn't necessarily the economically best answer.  The 
PDP-11/20 was done that way.  Supercomputers are often done that way because 
performance trumps cost.  And machines with simple instruction sets (RISC) are 
hardwired because the instruction set is specifically designed to make that 
efficient.

But a PDP-11, never mind a VAX or x86 PC CPU, has a very hairy instruction set 
with many variations.  If you think of executing these as a programming 
problem, you can decompose each instruction into a sequence of simpler 
operations.  SIMH does this, of course.  But you can also construct a simple 
computer that contains a well-chosen set of simple primitives, and construct 
complex instruction sets from those.

You can also do what van der Poel did in Holland ca. 1948, which is to expose a 
"horizontal microprogramming" instruction set directly to the application 
programmer.  But that makes the programmer's job rather hard, which is why it 
didn't catch on.

paul

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

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

[Gregg Levine]

Hello!
I agree with you Tim, that's an excellent book on the subject.
The AM2901 was used in some DEC designs that I know of. In fact in the
databook I have here, AMD mentions that some part numbers were
themselves designed for those DEC designs. And that some LSI-11
designs found themselves fully built using the AM2901. The sequencing
parts that the company made were in all probability not used inside
them. But were used elsewhere.

Oh and some of the DEC designs did also use the Series 74 ALU ,the
SN74181 one. I remember that from some reading about the entire design
process. In fact that TI ALU is itself a complex part, perhaps almost
as complex as the 74S481 that Mentec would attempt to use many years
later.
-
Gregg C Levine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."

On Mon, Mar 23, 2020 at 6:06 PM Tim Shoppa  wrote:
>
> The Mick and Brick book is THE BEST and 100% applicable to the 2901-based  
> 11/730 and KS discussions here. 
> http://bitsavers.org/components/amd/Am2900/Mick_Bit-Slice_Microprocessor_Design_1980.pdf
>
> On Mar 23, 2020, at 5:49 PM, Ray Jewhurst  wrote:
>
> Slightly off topic, could someone explain more about what microcode is and 
> how it works? The fact that the CPU instructions are they themselves 
> programmed in seems unfathomable.
>
> Ray
>
> On Mon, Mar 23, 2020, 5:33 PM Clem Cole  wrote:
>>
>>
>>
>> On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist  wrote:
>>>
>>> The VAX-11/750 used 2901 though...
>>
>> 750 was made out of custom CMOS gate arrays.  The main adder was analyzed as 
>> part of my thesis [long story - not for here, but a very clever circuit.  I 
>> would later get to know the guy that did it]. Paul Gilbeau and Dick 
>> Monroe were the main microcoders on the 750.  I'm pretty sure that Paul was 
>> also one of the 780 microcode folks.   Very interesting guy. I used to say 
>> he had a worm's eye view of the world -- perfect for his job as lead 
>> microcoder; but trying to get up a level could be difficult.  I've lost 
>> track of them both, although I still talk to Dave Cane a couple of times a 
>> year and I think he knows how to find most of the HW team.
>>
>> I'm fairly sure that the 750 used te BLISS based Micro2 tools as Tim 
>> suggested and as I said, we cloned them at Masscomp in C (which later it 
>> went west). Tim, you tell me, I thought the Masscomp version got sent to the 
>> Jupiter team, but I'm pretty sure it was used for Prism.  I remember us 
>> getting a 'bug report' because VAX-11/C didn't like something BSD's yacc had 
>> generated at one of the Hatfield/McCoy parties. I remember changing what it 
>> was and email it the next day.
>>
>> FWIW:   All of the Masscomp FP/AP and the DACP used that set of microcode 
>> tools since they were all AMD 29xx based.   IIRC, Chuck Palmer overhauled 
>> the original hack we did for Paul and Dick because a few Masscomp customers 
>> wanted to write custom DACP microcode and originally it was not too easy.   
>> I probably have a manual for that still around and maybe even the tools. 
>> But, since I don't have a DACP on the MC500 I still have,  I never bother 
>> scooping up the tools.
>>
>> Also, I know that there was an Intel 808x processor (85 I think) that 
>> shipped in the 750, but it was not an FEP.  It was limited to running the 
>> cartridge tape controller.  I don't remember how the console serial port was 
>> done (the 780 it was part of the FEP).  The 750 microcode did the boot as 
>> someone else pointed out.  I've forgotten how the microcode was loaded on a 
>> cold start.   I thought there was something in a ROM/EPROM, but I've 
>> forgotten.  I do know the cartridge tape unit was needed to update the 
>> microcode and that was the only way to do it.  But I don't remember you need 
>> to have the tape on a cold reboot the like floppies on a 780, but I could 
>> have forgotten.
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2020-03-23 22:32, Clem Cole wrote:



On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist > wrote:


The VAX-11/750 used 2901 though...

750 was made out of custom CMOS gate arrays.  The main adder was 
analyzed as part of my thesis [long story - not for here, but a very 
clever circuit.  I would later get to know the guy that did it].


Now that you say it, it rings a bell. I must totally be mixing the 750 
and 730 up...


Also, I know that there was an Intel 808x processor (85 I think) that 
shipped in the 750, but it was not an FEP.  It was limited to running 
the cartridge tape controller.  I don't remember how the console serial 
port was done (the 780 it was part of the FEP).  The 750 microcode did 
the boot as someone else pointed out.  I've forgotten how the microcode 
was loaded on a cold start.   I thought there was something in a 
ROM/EPROM, but I've forgotten.  I do know the cartridge tape unit was 
needed to update the microcode and that was the only way to do it.  But 
I don't remember you need to have the tape on a cold reboot the like 
floppies on a 780, but I could have forgotten.


Looking a bit at the documentation, both the console and the TU58 are 
run directly by the VAX CPU. They are both just serial ports anyhow, so 
not much to do for either, actually.


The microcode is in ROM, so not loaded at all. But there was a bit of 
patch ram available to correct bugs in the microcode.


And NetBSD still have that microcode patch file in the distribution. It 
originally came with Ultrix, I believe. And if NetBSD boots on an 
11/750, it will patch the microcode. But I don't know what the patches 
actually fix. Maybe someone else knows...


Not sure if you could update the full microcode on the machine. I 
haven't seen anything suggesting it is possible in the documentation...


  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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Tim Shoppa]

The Mick and Brick book is THE BEST and 100% applicable to the 2901-based  
11/730 and KS discussions here. 
http://bitsavers.org/components/amd/Am2900/Mick_Bit-Slice_Microprocessor_Design_1980.pdf

> On Mar 23, 2020, at 5:49 PM, Ray Jewhurst  wrote:
> 
> Slightly off topic, could someone explain more about what microcode is and 
> how it works? The fact that the CPU instructions are they themselves 
> programmed in seems unfathomable. 
> 
> Ray 
> 
>> On Mon, Mar 23, 2020, 5:33 PM Clem Cole  wrote:
>> 
>> 
>>> On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist  wrote:
>>> The VAX-11/750 used 2901 though...
>> 750 was made out of custom CMOS gate arrays.  The main adder was analyzed as 
>> part of my thesis [long story - not for here, but a very clever circuit.  I 
>> would later get to know the guy that did it]. Paul Gilbeau and Dick 
>> Monroe were the main microcoders on the 750.  I'm pretty sure that Paul was 
>> also one of the 780 microcode folks.   Very interesting guy. I used to say 
>> he had a worm's eye view of the world -- perfect for his job as lead 
>> microcoder; but trying to get up a level could be difficult.  I've lost 
>> track of them both, although I still talk to Dave Cane a couple of times a 
>> year and I think he knows how to find most of the HW team. 
>> 
>> I'm fairly sure that the 750 used te BLISS based Micro2 tools as Tim 
>> suggested and as I said, we cloned them at Masscomp in C (which later it 
>> went west). Tim, you tell me, I thought the Masscomp version got sent to the 
>> Jupiter team, but I'm pretty sure it was used for Prism.  I remember us 
>> getting a 'bug report' because VAX-11/C didn't like something BSD's yacc had 
>> generated at one of the Hatfield/McCoy parties. I remember changing what it 
>> was and email it the next day. 
>> 
>> FWIW:   All of the Masscomp FP/AP and the DACP used that set of microcode 
>> tools since they were all AMD 29xx based.   IIRC, Chuck Palmer overhauled 
>> the original hack we did for Paul and Dick because a few Masscomp customers 
>> wanted to write custom DACP microcode and originally it was not too easy.   
>> I probably have a manual for that still around and maybe even the tools. 
>> But, since I don't have a DACP on the MC500 I still have,  I never bother 
>> scooping up the tools.
>> 
>> Also, I know that there was an Intel 808x processor (85 I think) that 
>> shipped in the 750, but it was not an FEP.  It was limited to running the 
>> cartridge tape controller.  I don't remember how the console serial port was 
>> done (the 780 it was part of the FEP).  The 750 microcode did the boot as 
>> someone else pointed out.  I've forgotten how the microcode was loaded on a 
>> cold start.   I thought there was something in a ROM/EPROM, but I've 
>> forgotten.  I do know the cartridge tape unit was needed to update the 
>> microcode and that was the only way to do it.  But I don't remember you need 
>> to have the tape on a cold reboot the like floppies on a 780, but I could 
>> have forgotten.
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Toby Thain]

On 2020-03-23 5:49 PM, Ray Jewhurst wrote:
> Slightly off topic, could someone explain more about what microcode is
> and how it works? The fact that the CPU instructions are they themselves
> programmed in seems unfathomable. 
> 

Here's a decent start:
https://people.cs.clemson.edu/~mark/uprog.html

--Toby


> Ray 
> 
> On Mon, Mar 23, 2020, 5:33 PM Clem Cole  > wrote:
> 
> 
> 
> On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist  > wrote:
> 
> The VAX-11/750 used 2901 though...
> 
> 750 was made out of custom CMOS gate arrays.  The main adder was
> analyzed as part of my thesis ... The
> 750 microcode did the boot as someone else pointed out.  I've
> forgotten how the microcode was loaded on a cold start.   I thought
> there was something in a ROM/EPROM, but I've forgotten.  I do know
> the cartridge tape unit was needed to update the microcode and that
> was the only way to do it.  But I don't remember you need to have
> the tape on a cold reboot the like floppies on a 780, but I could
> have forgotten.
> ___
> Simh mailing list
> Simh@trailing-edge.com 
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> 
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> 

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

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

[Jonathan Welch]

https://en.m.wikipedia.org/wiki/Microcode

On Mon, Mar 23, 2020, 5:49 PM Ray Jewhurst  wrote:

> Slightly off topic, could someone explain more about what microcode is and
> how it works? The fact that the CPU instructions are they themselves
> programmed in seems unfathomable.
>
> Ray
>
> On Mon, Mar 23, 2020, 5:33 PM Clem Cole  wrote:
>
>>
>>
>> On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist  wrote:
>>
>>> The VAX-11/750 used 2901 though...
>>>
>> 750 was made out of custom CMOS gate arrays.  The main adder was analyzed
>> as part of my thesis [long story - not for here, but a very clever
>> circuit.  I would later get to know the guy that did it]. Paul Gilbeau
>> and Dick Monroe were the main microcoders on the 750.  I'm pretty sure that
>> Paul was also one of the 780 microcode folks.   Very interesting guy. I
>> used to say he had a worm's eye view of the world -- perfect for his job as
>> lead microcoder; but trying to get up a level could be difficult.  I've
>> lost track of them both, although I still talk to Dave Cane a couple of
>> times a year and I think he knows how to find most of the HW team.
>>
>> I'm fairly sure that the 750 used te BLISS based Micro2 tools as Tim
>> suggested and as I said, we cloned them at Masscomp in C (which later it
>> went west). Tim, you tell me, I thought the Masscomp version got sent to
>> the Jupiter team, but I'm pretty sure it was used for Prism.  I remember us
>> getting a 'bug report' because VAX-11/C didn't like something BSD's yacc
>> had generated at one of the Hatfield/McCoy parties. I remember changing
>> what it was and email it the next day.
>>
>> FWIW:   All of the Masscomp FP/AP and the DACP used that set of
>> microcode tools since they were all AMD 29xx based.   IIRC, Chuck Palmer
>> overhauled the original hack we did for Paul and Dick because a few Masscomp
>> customers wanted to write custom DACP microcode and originally it was
>> not too easy.   I probably have a manual for that still around and maybe
>> even the tools. But, since I don't have a DACP on the MC500 I still
>> have,  I never bother scooping up the tools.
>>
>> Also, I know that there was an Intel 808x processor (85 I think) that
>> shipped in the 750, but it was not an FEP.  It was limited to running the
>> cartridge tape controller.  I don't remember how the console serial port
>> was done (the 780 it was part of the FEP).  The 750 microcode did the boot
>> as someone else pointed out.  I've forgotten how the microcode was loaded
>> on a cold start.   I thought there was something in a ROM/EPROM, but I've
>> forgotten.  I do know the cartridge tape unit was needed to update the
>> microcode and that was the only way to do it.  But I don't remember you
>> need to have the tape on a cold reboot the like floppies on a 780, but I
>> could have forgotten.
>> ___
>> Simh mailing list
>> Simh@trailing-edge.com
>> http://mailman.trailing-edge.com/mailman/listinfo/simh
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Ray Jewhurst]

Slightly off topic, could someone explain more about what microcode is and
how it works? The fact that the CPU instructions are they themselves
programmed in seems unfathomable.

Ray

On Mon, Mar 23, 2020, 5:33 PM Clem Cole  wrote:

>
>
> On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist  wrote:
>
>> The VAX-11/750 used 2901 though...
>>
> 750 was made out of custom CMOS gate arrays.  The main adder was analyzed
> as part of my thesis [long story - not for here, but a very clever
> circuit.  I would later get to know the guy that did it]. Paul Gilbeau
> and Dick Monroe were the main microcoders on the 750.  I'm pretty sure that
> Paul was also one of the 780 microcode folks.   Very interesting guy. I
> used to say he had a worm's eye view of the world -- perfect for his job as
> lead microcoder; but trying to get up a level could be difficult.  I've
> lost track of them both, although I still talk to Dave Cane a couple of
> times a year and I think he knows how to find most of the HW team.
>
> I'm fairly sure that the 750 used te BLISS based Micro2 tools as Tim
> suggested and as I said, we cloned them at Masscomp in C (which later it
> went west). Tim, you tell me, I thought the Masscomp version got sent to
> the Jupiter team, but I'm pretty sure it was used for Prism.  I remember us
> getting a 'bug report' because VAX-11/C didn't like something BSD's yacc
> had generated at one of the Hatfield/McCoy parties. I remember changing
> what it was and email it the next day.
>
> FWIW:   All of the Masscomp FP/AP and the DACP used that set of microcode
> tools since they were all AMD 29xx based.   IIRC, Chuck Palmer overhauled
> the original hack we did for Paul and Dick because a few Masscomp
> customers wanted to write custom DACP microcode and originally it was not
> too easy.   I probably have a manual for that still around and maybe even
> the tools. But, since I don't have a DACP on the MC500 I still have,  I
> never bother scooping up the tools.
>
> Also, I know that there was an Intel 808x processor (85 I think) that
> shipped in the 750, but it was not an FEP.  It was limited to running the
> cartridge tape controller.  I don't remember how the console serial port
> was done (the 780 it was part of the FEP).  The 750 microcode did the boot
> as someone else pointed out.  I've forgotten how the microcode was loaded
> on a cold start.   I thought there was something in a ROM/EPROM, but I've
> forgotten.  I do know the cartridge tape unit was needed to update the
> microcode and that was the only way to do it.  But I don't remember you
> need to have the tape on a cold reboot the like floppies on a 780, but I
> could have forgotten.
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Clem Cole]

On Mon, Mar 23, 2020 at 3:57 PM Johnny Billquist  wrote:

> The VAX-11/750 used 2901 though...
>
750 was made out of custom CMOS gate arrays.  The main adder was analyzed
as part of my thesis [long story - not for here, but a very clever
circuit.  I would later get to know the guy that did it]. Paul Gilbeau
and Dick Monroe were the main microcoders on the 750.  I'm pretty sure that
Paul was also one of the 780 microcode folks.   Very interesting guy. I
used to say he had a worm's eye view of the world -- perfect for his job as
lead microcoder; but trying to get up a level could be difficult.  I've
lost track of them both, although I still talk to Dave Cane a couple of
times a year and I think he knows how to find most of the HW team.

I'm fairly sure that the 750 used te BLISS based Micro2 tools as Tim
suggested and as I said, we cloned them at Masscomp in C (which later it
went west). Tim, you tell me, I thought the Masscomp version got sent to
the Jupiter team, but I'm pretty sure it was used for Prism.  I remember us
getting a 'bug report' because VAX-11/C didn't like something BSD's yacc
had generated at one of the Hatfield/McCoy parties. I remember changing
what it was and email it the next day.

FWIW:   All of the Masscomp FP/AP and the DACP used that set of microcode
tools since they were all AMD 29xx based.   IIRC, Chuck Palmer overhauled
the original hack we did for Paul and Dick because a few Masscomp customers
wanted to write custom DACP microcode and originally it was not too easy.
 I probably have a manual for that still around and maybe even the tools. But,
since I don't have a DACP on the MC500 I still have,  I never bother
scooping up the tools.

Also, I know that there was an Intel 808x processor (85 I think) that
shipped in the 750, but it was not an FEP.  It was limited to running the
cartridge tape controller.  I don't remember how the console serial port
was done (the 780 it was part of the FEP).  The 750 microcode did the boot
as someone else pointed out.  I've forgotten how the microcode was loaded
on a cold start.   I thought there was something in a ROM/EPROM, but I've
forgotten.  I do know the cartridge tape unit was needed to update the
microcode and that was the only way to do it.  But I don't remember you
need to have the tape on a cold reboot the like floppies on a 780, but I
could have forgotten.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX 750 and 730 (was Is it possible to simulate the first Vaxen I ever used?)

[Johnny Billquist]

Bob, are we talking microcode source or binaries here?

I certainly have the binaries for the 86x0. I also previously pointed 
you to a person who had put at least the source for (I think) the I-box 
microcode for the 86x0 on the net, and he had more that he hadn't scanned...


  Johnny

On 2020-03-23 20:16, Bob Supnik wrote:
One of the problems with simulating the non-VLSI VAXen, other than the 
780, is that the microcode is not available. Back at DEC, I had the 730 
microcode in a huge notebook (it was 16KW), but I discarded it when I 
moved out of Hudson and downsized my document collection. We really need 
the microcode for the 750, 730, 8600/8650, 8200 (V11), and 8800.


The various microcodes may be available in the DEC fiche collection at 
CHM, but I haven't been able to get out there to do the research, and 
travel is out of the question right now.


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


--
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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2020-03-23 19:36, Paul Koning wrote:


On the VAX 730: as far as I'm aware it's the only VAX built out of standard LSI 
CPU components.  The guts of the CPU is AMD 2901 bit-slice chips.  All other 
DEC microprogrammed machines I can think of had their own purpose-designed 
logic.


I was pretty sure the VAX-11/780 was standard TTL stuff. Not even any 
2901 in there.

The VAX-11/750 used 2901 though...
730 I don't know, but I would assume 2901 there too.
The 86x0 is way more complex with lots of ECL...

But I could of course be confused about all this (as usual).

  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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Timothe Litt]

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

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

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

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

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

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

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

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


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

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

[Johnny Billquist]

On 2020-03-23 19:29, Ethan Dicks wrote:

On Mon, Mar 23, 2020 at 1:30 PM Robert Armstrong  wrote:



Johnny Billquist  wrote:
The memory bus on the VAX-11/750 is the same as for the MK11 box for the
PDP-11/70, and they shared some memory cards.


   Same memory was used on the 730 too.  The 730 memory cards were always 1MB 
though - never saw any other size.


Yes.   The 11/70 supported the 256K cards only, the 11/750 supported
either the 256K cards or the 1MB cards (early 11/750s lacked one
address wire on the memory bus - I added it to our machine S/N
BT354), and the 11/730 (and 11/725!) supported only the 1MB cards,
but I don't know if that was because of memory controller limitations
or because you could only stuff 5 cards in the box and 1.25MB wasn't
enough to run VMS.


Actually, there are also 64K cards. But with 256K cards, one MK11 is 
enough to fully populate the memory of an 11/70. So there was no obvious 
need to make the MK11 capable of taking larger cards.


However, that did not prevent some from doing a hardware hack to allow 
the MK11 to use 1M cards. I used to run an 11/70 with that about 25 
years ago.


But it requires a small custom PCB to be made and inserted into the MK11.

I would suspect for the 11/730, it might just have assumed that it was 
1M cards. Makes the logic a bit simpler, since you then know how to 
address each card with very simple decoding.



   I don't know the actual number of physical address bits implemented on the 
730, but as a practical matter 5x 1Mb cards was the most you could fit in the 
chassis.


I remember looking into this a few years back - ISTR the PALs only
generate 5 memory select lines (that go to each memory-capable slot)
and there were no unused pins on that PAL.

It seems possible to rework this, but I don't think it would be a
trivial mod.  An 8MB 11/730 wouldn't be all that much better than a
5MB 11/730.  Some.  I remember using ours as mostly a single-user
machine in the late 80s because by the time a third person logged in,
it started swapping like a fiend.


Obviously with more memory, it would swap less. But since the machine is 
slow as molass anyway, and if you were to add more card select lines, 
you also would need a larger backplane, which is definitely non-trivial, 
I very much doubt the point of ever doing this...


  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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Tim Shoppa]

Bob, the October 1978 LCG product strategy red book, shows the 2901-based
Minnow as a direct follow-on to the KS in the same technology lineage.

Many technology aspects (including R80 and RL02 peripheral system) in the
11/730 are exactly as they were in the planned Minnow. IIRC the R80
drawings referred to Minnow interface in several places?

Tim.

On Mon, Mar 23, 2020 at 3:00 PM Robert Armstrong  wrote:

> > Paul Koning  wrote:
> >2901 bitslices do appear in other DEC products, the UDA comes to mind
>
>   The KS was built with 2901s, right?  Or at least some 29xx family parts?
>
>   Actually the KS and the 730 implementations have a lot in common.  I
> always wondered if the same engineers worked on both, but that's probably
> unlikely.
>
> Bob
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

[Simh] VAX 750 and 730 (was Is it possible to simulate the first Vaxen I ever used?)

[Bob Supnik]

One of the problems with simulating the non-VLSI VAXen, other than the 
780, is that the microcode is not available. Back at DEC, I had the 730 
microcode in a huge notebook (it was 16KW), but I discarded it when I 
moved out of Hudson and downsized my document collection. We really need 
the microcode for the 750, 730, 8600/8650, 8200 (V11), and 8800.


The various microcodes may be available in the DEC fiche collection at 
CHM, but I haven't been able to get out there to do the research, and 
travel is out of the question right now.


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

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

[Eric Smith]

On Mon, Mar 23, 2020 at 12:34 PM Ethan Dicks  wrote:

> The 11/60 microcoded to run PDP-8 instructions is the story I remember
> from the early 80s.
>
> Now I have an 11/60 so I am sad that hack was lost.
>

I exchanged email with Richie Lary some years back, and he did not have a
copy, so it likely is gone for good.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Timothe Litt]

On 23-Mar-20 14:36, Paul Koning wrote:
>
>> On Mar 23, 2020, at 1:29 PM, Timothe Litt  wrote:
>>
>> ...
>> On the VAX 730: as far as I'm aware it's the only VAX built out of
>> standard LSI CPU components. The guts of the CPU is AMD 2901
>> bit-slice chips. All other DEC microprogrammed machines I can think
>> of had their own purpose-designed logic. 

The PDP-11s, like the 11/05 were ttl, the CPU ALU was something like
74181 4 bit slices.  I don't count them as "real" microcoded machines
for some reason - perhaps because the ucode was all ROM, and IIRC there
was no assembler for it. 

The KS10 uses 2901 for its CPU - because of the 1/2 word arithmetic,
it's actually 40 bits wide.

The 780 is TTL.  The 785 is the same machine, upgraded to 74S.

The UDA data mover used 2901s so cleverly that it went into several more
generations of disk controllers.  It  timeslices the 2901 such that it
runs two programs - one on the A and one on the B phase of each clock cycle.

> 2901 bitslices do appear in other DEC products, the UDA comes to mind.  And 
> that has, for running on-board diagnostic tools, a small PDP11-like 
> instruction set implemented in a little bit of 2901 microcode.  By Richie 
> Lary, wizard of compact software...
>
>   paul
>
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Robert Armstrong]

> Paul Koning  wrote:
>2901 bitslices do appear in other DEC products, the UDA comes to mind

  The KS was built with 2901s, right?  Or at least some 29xx family parts?

  Actually the KS and the 730 implementations have a lot in common.  I always 
wondered if the same engineers worked on both, but that's probably unlikely.

Bob


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

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

[Tim Shoppa]

BTW... great interview of Richie Lary:
https://www.youtube.com/watch?v=lp2NSbJ2H1k

On Mon, Mar 23, 2020 at 2:36 PM Paul Koning  wrote:

>
>
> > On Mar 23, 2020, at 1:29 PM, Timothe Litt  wrote:
> >
> > ...
> >> Since the KL10 was DEC's biggest, most expensive machine at the time,
> it wasn't nearly as cost sensitive as their other CPUs, so there probably
> wasn't even any consideration given to using PROM for the control store.
> > I don't think you could have found fast enough PROMs.  The KL is an ECL
> machine.  The RAMs are ECL, and the timing is hairy enough that the modules
> are only populated 1/2 way back - to fill the board would break timing.
> The boards also have loops of etch that serve as delay lines.
> Manufacturing would short the loops at the right place for each board -
> depending on how the board (and RAMs) turned out.  Today we take for
> granted process controls and tolerances that were, if not unattainable,
> unaffordable at that time.
>
> Was there such a thing as ECL ROM?  I don't remember.
>
> It's interesting to watch the evolution of high speed computers.  There's
> a continuous back and forth between memory and logic, depending on where
> the limitations are in the year or two when the design was frozen.  RAM and
> ROM have generally been different.
>
> One example that comes to mind is the character stroke generator for the
> CDC 6000 series mainframes.  That has a 10 MHz waveform step clock, so it
> needs a ROM with an access time comfortably below 100 ns (unless you want
> to use multiple banks).  In 1964 that was problematic, and the 6000 series
> display controller instead uses a massive logic chain to produce all the
> waveform data for all the character codes.  5-ish years later, in the Cyber
> 170 series, all that was replaced by a ROM.  Same data, but one chip
> instead of 100 or so plug-in logic modules.
>
> Another example, also from that machine: the memory access and scheduling
> machinery is quite complex, with 32 memory banks operating concurrently.
> That's because many of the instructions complete in far less than a memory
> cycle time: 300 or 400 ns for the simpler instructions, and even a multiply
> takes only 1000 ns, while memory cycles in 1000 ns.  By 1964 standards,
> 1000 ns was amazingly fast, I don't think anyone else came close, and the
> core memory wiring and circuitry is quite exotic to make it go so fast.
>
> On the VAX 730: as far as I'm aware it's the only VAX built out of
> standard LSI CPU components.  The guts of the CPU is AMD 2901 bit-slice
> chips.  All other DEC microprogrammed machines I can think of had their own
> purpose-designed logic.
>
> 2901 bitslices do appear in other DEC products, the UDA comes to mind.
> And that has, for running on-board diagnostic tools, a small PDP11-like
> instruction set implemented in a little bit of 2901 microcode.  By Richie
> Lary, wizard of compact software...
>
> paul
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Paul Koning]

> On Mar 23, 2020, at 1:29 PM, Timothe Litt  wrote:
> 
> ...
>> Since the KL10 was DEC's biggest, most expensive machine at the time, it 
>> wasn't nearly as cost sensitive as their other CPUs, so there probably 
>> wasn't even any consideration given to using PROM for the control store.
> I don't think you could have found fast enough PROMs.  The KL is an ECL 
> machine.  The RAMs are ECL, and the timing is hairy enough that the modules 
> are only populated 1/2 way back - to fill the board would break timing.  The 
> boards also have loops of etch that serve as delay lines.  Manufacturing 
> would short the loops at the right place for each board - depending on how 
> the board (and RAMs) turned out.  Today we take for granted process controls 
> and tolerances that were, if not unattainable, unaffordable at that time.

Was there such a thing as ECL ROM?  I don't remember.

It's interesting to watch the evolution of high speed computers.  There's a 
continuous back and forth between memory and logic, depending on where the 
limitations are in the year or two when the design was frozen.  RAM and ROM 
have generally been different.

One example that comes to mind is the character stroke generator for the CDC 
6000 series mainframes.  That has a 10 MHz waveform step clock, so it needs a 
ROM with an access time comfortably below 100 ns (unless you want to use 
multiple banks).  In 1964 that was problematic, and the 6000 series display 
controller instead uses a massive logic chain to produce all the waveform data 
for all the character codes.  5-ish years later, in the Cyber 170 series, all 
that was replaced by a ROM.  Same data, but one chip instead of 100 or so 
plug-in logic modules.

Another example, also from that machine: the memory access and scheduling 
machinery is quite complex, with 32 memory banks operating concurrently.  
That's because many of the instructions complete in far less than a memory 
cycle time: 300 or 400 ns for the simpler instructions, and even a multiply 
takes only 1000 ns, while memory cycles in 1000 ns.  By 1964 standards, 1000 ns 
was amazingly fast, I don't think anyone else came close, and the core memory 
wiring and circuitry is quite exotic to make it go so fast.

On the VAX 730: as far as I'm aware it's the only VAX built out of standard LSI 
CPU components.  The guts of the CPU is AMD 2901 bit-slice chips.  All other 
DEC microprogrammed machines I can think of had their own purpose-designed 
logic.

2901 bitslices do appear in other DEC products, the UDA comes to mind.  And 
that has, for running on-board diagnostic tools, a small PDP11-like instruction 
set implemented in a little bit of 2901 microcode.  By Richie Lary, wizard of 
compact software...

paul

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

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

[Ethan Dicks]

On Mon, Mar 23, 2020 at 9:47 AM Paul Koning  wrote:
> > On Mar 23, 2020, at 9:33 AM, Robert Armstrong  wrote:
> >
> > ...for years I've heard a persistent rumor that the PDP-8/WPS-8 group at 
> > DEC had a 730 with microcode that had been hacked to include a PDP-8 
> > compatibility mode, which they used for development.  It was faster than 
> > real -8 and supported timesharing to boot.
>
> I can refute that.  The WPS group sat right next to my first DEC group 
> (Typeset-11).  Yes, they had a machine with extended microcode to run PDP-8 
> code faster.  But it was an 11/60 running RSTS/E.  That was in 1978; the 730 
> didn't exist yet back then.

The 11/60 microcoded to run PDP-8 instructions is the story I remember
from the early 80s.

Now I have an 11/60 so I am sad that hack was lost.

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

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

[Ethan Dicks]

On Mon, Mar 23, 2020 at 1:30 PM Robert Armstrong  wrote:
>
> > Johnny Billquist  wrote:
> >The memory bus on the VAX-11/750 is the same as for the MK11 box for the
> >PDP-11/70, and they shared some memory cards.
>
>   Same memory was used on the 730 too.  The 730 memory cards were always 1MB 
> though - never saw any other size.

Yes.   The 11/70 supported the 256K cards only, the 11/750 supported
either the 256K cards or the 1MB cards (early 11/750s lacked one
address wire on the memory bus - I added it to our machine S/N
BT354), and the 11/730 (and 11/725!) supported only the 1MB cards,
but I don't know if that was because of memory controller limitations
or because you could only stuff 5 cards in the box and 1.25MB wasn't
enough to run VMS.

>   I don't know the actual number of physical address bits implemented on the 
> 730, but as a practical matter 5x 1Mb cards was the most you could fit in the 
> chassis.

I remember looking into this a few years back - ISTR the PALs only
generate 5 memory select lines (that go to each memory-capable slot)
and there were no unused pins on that PAL.

It seems possible to rework this, but I don't think it would be a
trivial mod.  An 8MB 11/730 wouldn't be all that much better than a
5MB 11/730.  Some.  I remember using ours as mostly a single-user
machine in the late 80s because by the time a third person logged in,
it started swapping like a fiend.

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

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

[Timothe Litt]

On 23-Mar-20 13:53, Eric Smith wrote:
> On Mon, Mar 23, 2020 at 11:35 AM Robert Armstrong  > wrote:
>
> > Timothe Litt mailto:l...@ieee.org>> wrote:
> > KS10 ... The 8085 code is crammed into UV EPROMs.
>
>   Was all of the KS CFE code in EPROM?  On the 730 only a small
> kernel of 8085 code (about 2K as I remember) was in ROM/EPROM and
> the rest of the 8085 memory was RAM.  The first thing the 8085 did
> at power on was to load the rest of the 8085 code from the TU58. 
> That made it possible to issue updates to the CFE code as well as
> the microcode.
>
>
> All the KS10 front end 8080 code (not 8085!) was in EPROM, up to four
> 2716 EPROMs for 8KB of code. There only RAM was two 2114 chips (each
> 1Kx4), for 1KB of RAM. The 8080 code would load the KS10 microcode
> from mass storage.
>
Typo on my part.  You are correct, the KS CSL is an 8080.  And all 4
EPROMs are full.  The code uses INT instructions with a function code
following to save bytes on subroutine calls.  Yet it provides full
remote diagnosis support, as well as a lot of RAMP (Reliability,
Availability, Maintainability, and Performance) features that were a
challenge on the KL.  The KL has a whole 11/40 FE with an OS...

Did I mention that when one of my colleagues came back from (LCG)
European DECUS when RAMP was announced, he reported that after the
session a helpful customer pointed out that in Dutch, "ramp" means
"disaster"...


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

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

[Eric Smith]

On Mon, Mar 23, 2020 at 11:35 AM Robert Armstrong  wrote:

> > Timothe Litt  wrote:
> > KS10 ... The 8085 code is crammed into UV EPROMs.
>
>   Was all of the KS CFE code in EPROM?  On the 730 only a small kernel of
> 8085 code (about 2K as I remember) was in ROM/EPROM and the rest of the
> 8085 memory was RAM.  The first thing the 8085 did at power on was to load
> the rest of the 8085 code from the TU58.  That made it possible to issue
> updates to the CFE code as well as the microcode.
>

All the KS10 front end 8080 code (not 8085!) was in EPROM, up to four 2716
EPROMs for 8KB of code. There only RAM was two 2114 chips (each 1Kx4), for
1KB of RAM. The 8080 code would load the KS10 microcode from mass storage.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Timothe Litt]

On 23-Mar-20 13:35, Robert Armstrong wrote:
>> Timothe Litt  wrote:
>> KS10 ... The 8085 code is crammed into UV EPROMs.
>   Was all of the KS CFE code in EPROM? 

Yes, it is.  There are a couple of microwords in the CRAM that deal with
console responses (single step, console interrupts for the serial
lines).  But that's it.

The KS can, and does initiate some bus cycles to get an RH11 tape or
disk to load a record into PDP-10 memory.  That record contains the CRAM
ucode.  The 8080 reads it from -10 memory and load the CRAM.  And once
it's a PDP-10, the next stage of boot (again, a few instructions) loads
the monitor bootstrap.

The CSL has no dedicated mass storage - and that was an issue of
reliability even more than cost.  The other issue is that CSL didn't
have a lot of space.  At the time, you wouldn't put DRAM on an 8085. 
(And if you did, you needed yet another few chips of refresh controller,
address decoders, etc.)  SRAMs were small and expensive.  And once you
took up the space for an EPROM socket, you might as well make it big
enough to hold everything...

One nice thing about the KS is that it was very well documented.  (Had
to do something with the time while internal politics prevented its
release before the 780...)  There's a copy of the technical manual on
bitsavers, which you can read for more entertainment.

>  On the 730 only a small kernel of 8085 code (about 2K as I remember) was in 
> ROM/EPROM and the rest of the 8085 memory was RAM.  The first thing the 8085 
> did at power on was to load the rest of the 8085 code from the TU58.  That 
> made it possible to issue updates to the CFE code as well as the microcode.
>
> Bob
>
>
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Anders Magnusson]

Den 2020-03-23 kl. 17:58, skrev Robert Armstrong:

I think the 11/750 might have had an 8085 as well.

   I'm pretty sure the 750's console functions were implemented in microcode.  It was the only one 
of the "big" VAXes that didn't have a separate "computer" as the front end.  
Quotations used because the 730 wasn't all that big and an 8085 is not much of a computer.

Actually, the 11/750 _might_ have an 8085 IIRC :-)  There were an 
optional "Remote field service" card (I think it was called L0006) which 
were connected to a modem (or something) which DEC field service could 
call and diagnose the machine.


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

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

[Eric Smith]

On Mon, Mar 23, 2020 at 11:29 AM Timothe Litt  wrote:

> The KL10 was the first microcoded machine.
>

The first DEC microcoded 36-bit computer, but _not_ the first DEC
microcoded computer!

The PDP-9 (1966, core rope memory for control store), PDP-11/05 (1972),
PDP-11/40 (1973), and PDP-11/45 (1973)) were all microcoded and predate the
KL10.

I'm not sure whether the PDP-15 (1970) was microcoded or hardwired.

Some PDP-16 systems, including the PDP-16/M (1972), were microcoded.

Since the KL10 was DEC's biggest, most expensive machine at the time, it
wasn't nearly as cost sensitive as their other CPUs, so there probably
wasn't even any consideration given to using PROM for the control store.

I don't think you could have found fast enough PROMs.  The KL is an ECL
machine.

There were ECL PROMs that were fast enough.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Robert Armstrong]

> Timothe Litt  wrote:
> KS10 ... The 8085 code is crammed into UV EPROMs.

  Was all of the KS CFE code in EPROM?  On the 730 only a small kernel of 8085 
code (about 2K as I remember) was in ROM/EPROM and the rest of the 8085 memory 
was RAM.  The first thing the 8085 did at power on was to load the rest of the 
8085 code from the TU58.  That made it possible to issue updates to the CFE 
code as well as the microcode.

Bob


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

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

[Robert Armstrong]

> Johnny Billquist  wrote:
>The memory bus on the VAX-11/750 is the same as for the MK11 box for the 
>PDP-11/70, and they shared some memory cards. 

  Same memory was used on the 730 too.  The 730 memory cards were always 1MB 
though - never saw any other size.

  I don't know the actual number of physical address bits implemented on the 
730, but as a practical matter 5x 1Mb cards was the most you could fit in the 
chassis.

Bob

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

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

[Timothe Litt]

On 23-Mar-20 13:09, Eric Smith wrote:
> On Mon, Mar 23, 2020 at 7:34 AM Robert Armstrong  > wrote:
>
> The 730 was interesting in that ALL of the CPU microcode was in
> RAM and was loaded by the CFE at boot time.  It was possible to
> locally modify the 730 microcode, and DEC even had a set of
> microcode development tools for the 730.  I've never seen them
> except in references.
>
> [snip]
> The first two DEC machine to use entirely RAM control store were the
> KL10 and KS10 36-bit PDP-10 CPUs, in 1975 and 1978, both used in
> DECsystem-10 and DECSYSTEM-20 systems. The KL10 was the biggest and
> most expensive PDP-10, and the KS10 was the smallest and least
> expensive.  The earlier 36-bit CPUs, the 166 (PDP-6), KA10, and KI10,
> were hardwired rather than microcoded.
>
Yes, with module and wire-wrap backplanes. The could be (and were) ECOed
in the field.

The KL10 was the first microcoded machine.  And first and most
complicated in other dimensions.  Bugs were expected, and reducing the
cost of dealing with them was a consideration.  It was a good call. 
Besides that, having a fully programmable microstore allowed us to do
functional upgrades too.  Like the CI/NI, and the GFloating support. 
GFloat was pure ucode.

> Since the KL10 was DEC's biggest, most expensive machine at the time,
> it wasn't nearly as cost sensitive as their other CPUs, so there
> probably wasn't even any consideration given to using PROM for the
> control store.

I don't think you could have found fast enough PROMs.  The KL is an ECL
machine.  The RAMs are ECL, and the timing is hairy enough that the
modules are only populated 1/2 way back - to fill the board would break
timing.  The boards also have loops of etch that serve as delay lines. 
Manufacturing would short the loops at the right place for each board -
depending on how the board (and RAMs) turned out.  Today we take for
granted process controls and tolerances that were, if not unattainable,
unaffordable at that time.


>
> The decision to use RAM control store on the KS10 is less obvious. It
> was still an expensive machine, maybe 20% or 25% of the cost of a
> KL10, so it may still have not been considered cost sensitive, and the
> benefits of easy microcode updates may have been considered more
> important than they would have been on e.g. the PDP-11 CPUs.
>
We learned from the KL that it was worthwhile.  TCO (DEC's as well as
the customers').

The KS did compromise, however.  While the control store is all RAM, the
dispatch microcode is in metal PROMs.  I still have a few.  And, I found
a bug in a privileged instruction that required a DROM change to fix. 
We redefined the instruction instead.  Luckily, no other issues effected
the DROM, though it did prevent adding some instructions that the KL had
(and the OS liked).

> The KS10 control store RAM has parity, and RAM parity errors were
> apparently fairly common. A control store parity error would halt the
> CPU and interrupt the 8085 front end, which would reload the control
> store and restart the machine. DEC patented that.
>
>
The 8085 code is crammed into UV EPROMs.   Quite a few coding tricks to
save bytes and make it fit.  It required several rounds of changes -
which meant swapping boards.  FLASH at that time was not available in
the required densities, was insanely expensive - and had an annoying
habit of being forgetful.  I have some neat stories about the latter -
for another day.


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

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

[Robert Armstrong]

> Hunter Goatley  wrote:
>... kick back and read a few chapters from one of the SF novels while 
> waiting for their build to complete. 8-) 

  I had a job in the early 80s for a company that wrote EDA software, and we 
used a 750 as the development platform.  Linking a new EXE (_linking_!!) took 
about 15 minutes, and and there were many paperback books scattered around.  
Management was not happy, but we had a good excuse until they eventually bought 
us a used 785.  Compiling all the source code on the 750 took more than a day 
and was normally done once a week, over the weekend.

> The day we got our first VAXstation 2000, everybody was fighting
> over it, because it blew the 730 away.

  I think the 730/725 was the second slowest VAX ever made.  It beat the 
performance of a MicroVAX-I (I, not II) by just a hair.

Bob




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

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

[Johnny Billquist]

On 2020-03-23 17:58, Robert Armstrong wrote:

I think the 11/750 might have had an 8085 as well.


   I'm pretty sure the 750's console functions were implemented in microcode.  It was the only one 
of the "big" VAXes that didn't have a separate "computer" as the front end.  
Quotations used because the 730 wasn't all that big and an 8085 is not much of a computer.


You're probably right. Took a quick peek at some documents, and couldn't 
find anything like a microprocessor in there.


Two other fun facts I know about the 11/750:

This was the only VAX for many years that actually used a boot block on 
disks. All other VAXen had the FE provide VMB for the VAX, so that 
booting was handled through VMB.


The memory bus on the VAX-11/750 is the same as for the MK11 box for the 
PDP-11/70, and they shared some memory cards. However, the MK11 never 
handled larger than 256K cards, while the VAX-11/750 was extended to 
handle 1MB cards, and eventually even had a 4MB card that could be used.


  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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Hunter Goatley]

Pardon the reminiscing, but all of this talk about the 11/730 reminds me 
of my first job after college. At WKU, we had a VAX 11/785. After 
graduating, I went to work for Clyde Digital Systems. When I got there, 
I was surprised at the several bookcases full of SF novels scattered 
around the programmers' cubicles.


Turns out that Clyde had an 11/750 for business stuff and an 11/730 for 
the developers. I was the sixth or seventh programmer hired. I quickly 
learned that the 730 was seriously underpowered for that many 
developers. The coders would kick off builds of their products, then 
kick back and read a few chapters from one of the SF novels while 
waiting for their build to complete. 8-) I started going in to the 
office at 6 AM to have a couple of hours of the 730 to myself, and I 
also made use of the 750 when no one was paying attention. (The 750 
didn't have compilers, but most of my work was done in MACRO-32, so I 
could do assembly on the 750. The privileged code had to be tested on 
the 730, though, because I couldn't risk crashing the 750.)


The day we got our first VAXstation 2000, everybody was fighting over 
it, because it blew the 730 away.


Fun times. Now. 8-)

Hunter


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

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

[Eric Smith]

On Mon, Mar 23, 2020 at 7:34 AM Robert Armstrong  wrote:

> The 730 was interesting in that ALL of the CPU microcode was in RAM and
> was loaded by the CFE at boot time.  It was possible to locally modify the
> 730 microcode, and DEC even had a set of microcode development tools for
> the 730.  I've never seen them except in references.
>

The 11/785 and 8600/8650 also used RAM for the entire control store, loaded
by the front end. The 11/785 front end was a PDP-11/03, like the 11/780,
but on the 11/780 the front end only had to load the patch store, not the
entire microcode.

Fast static RAM was considerably more expensive per bit than PROM in the
1970s and early 1980s. As the price of fast static RAM came down in the
1980s, the trend was to use entirely RAM control store, but later in the
1980s as they developed single-chip CPUs, it once again became impractical
to use all-RAM control store. RAM bits require approximately six times the
die area per bit as masked ROM. That drove the microprocessors to use
mostly ROM, with a small RAM patch area, just like the 11/780.

The first two DEC machine to use entirely RAM control store were the KL10
and KS10 36-bit PDP-10 CPUs, in 1975 and 1978, both used in DECsystem-10
and DECSYSTEM-20 systems. The KL10 was the biggest and most expensive
PDP-10, and the KS10 was the smallest and least expensive.  The earlier
36-bit CPUs, the 166 (PDP-6), KA10, and KI10, were hardwired rather than
microcoded.

Since the KL10 was DEC's biggest, most expensive machine at the time, it
wasn't nearly as cost sensitive as their other CPUs, so there probably
wasn't even any consideration given to using PROM for the control store.

The decision to use RAM control store on the KS10 is less obvious. It was
still an expensive machine, maybe 20% or 25% of the cost of a KL10, so it
may still have not been considered cost sensitive, and the benefits of easy
microcode updates may have been considered more important than they would
have been on e.g. the PDP-11 CPUs.

The KS10 control store RAM has parity, and RAM parity errors were
apparently fairly common. A control store parity error would halt the CPU
and interrupt the 8085 front end, which would reload the control store and
restart the machine. DEC patented that.
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2020-03-23 16:35, Bob Eager wrote:

On Mon, 23 Mar 2020 08:10:17 -0700
"Robert Armstrong"  wrote:


FUBAR is the name of a 780 CSR (in the UBA: failed unibus address
register);
perhaps it was used in the 730 as well.


   The 730 certainly had a UBA; don?t know if had a specific "FUBAR"
register though.  But as far as a physical bar inside the chassis
I've never seen nor heard of anything like that.  I have a 730 in the
garage and it doesn't have any such thing.  The 730 fit into a single
10-1/2" chassis anyway, so there wasn't even a specific cabinet or
rack dedicated to the 730.  And the 730 chassis was basically the
same box as was used for the 11/44, but with a somewhat different
backplane.

   I suspect the "FUBAR" at Dan's high school may have been a local
joke :)


Not at all. It existed on the 780, at the very least, so most likely
elsewhere. Mentioned in the VAX11/780 Hardware Handbook (e.g. the
1979-80 edition).

See:http://www.tavi.co.uk/FUBAR.jpg


Yes, the DW780 have a FUBAR register, just as Bob notes. But the thing 
is, you will not see anything about it if you open up the cabinet. It is 
not a "physical" bar inside the cabinet.


I strongly suspect Bob is right that it might have been some local joke 
or hack at Dan's high school.


  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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2020-03-23 15:44, Paul Koning wrote:




On Mar 23, 2020, at 10:34 AM, Dan Gahlinger  wrote:

...
I remember they opened the chassis a number of times to show off that bar, the part was 
indeed labelled "FUBAR", it was the source of some laughs.


FUBAR is the name of a 780 CSR (in the UBA: failed unibus address register); 
perhaps it was used in the 730 as well.  I'm sure the engineers got a kick out 
of being able to sneak that acronym past the writers and managers.


I think the FUBAR was only in the DW780. I think I looked at some point 
around the 11/750 and couldn't even find a FUBAR there.


But anyway, the DW780 FUBAR would not be worthy of a label inside the 
cabinet, so I think this FUBAR Dan saw must have been something else...



...
there was what I'd call a bug in the vms on that system.  you could rename a 
.dir that had files within it to say .dat then delete the .dat if you set it 
/nodirectory, and all the files within the dir would still use up disk space, 
even though there was now no longer any way to work with them. so you'd have 
this missing disk space basically forever, still counting against the users 
quota.
I know because I did that at least twice.


VMS is like Unix: directories are name to inode number maps (not called 
"inode"; I forgot the correct name).  A file doesn't need a name.  I remember 
RSX had an explicit way to reference a file by its number, don't remember what VMS did.


File ID, or FID for short.
And I think it's possible to refer to files by ID in VMS as well. 
Especially from programs, but it might have been possible from DCL as 
well, with various tools.


But anyway, yes, files can get lost. That is one task of fsck (under 
Unix), VFY (under RSX), or ANALYZE (I think it's under VMS). Finding 
lost files and enter them into some known directory.


I wouldn't even call this a bug. Files-11, which is what VMS and RSX 
uses, do not reference count files. You can have multiple entries for 
them in different directories, just like any hard link in Unix, but 
removing such entries have no bearing on the existence of the file or 
not. And likewise, you can also delete a file while still having 
directory entries that refers to it.

It's part of the design of the Files-11 file system.

And that is why file IDs have two numbers. The first one is the 
equivalent of the inode number. The second number is a generation 
number, so that you don't confuse files when a file ID is reused, since 
you can retain, and refer to files by file ID.


  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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Johnny Billquist]

On 2020-03-23 14:33, Robert Armstrong wrote:

Ethan Dicks  wrote:
Using a PDP-8 as an FEP on any VAX definitely sounds odd.


   The console front end for the 730 was an 8085 (just like the KS10, FWIW).


Trying to remember. Not sure, but I think the 11/750 might have had an 
8085 as well.



   The 730 was interesting in that ALL of the CPU microcode was in RAM and was 
loaded by the CFE at boot time.  It was possible to locally modify the 730 
microcode, and DEC even had a set of microcode development tools for the 730.  
I've never seen them except in references.


The 86x0 also loaded all microcode from storage by the FE at boot. In 
this case, the RL02. I think I have enough documentation that it could 
be possible to do something with it, but I have never tried...


The 11/750 could patch the microcode, but only a limited amount of it. 
Ultrix (as well as NetBSD) comes with a patch set for the VAX-11/750 
microcode. Not sure exactly how it worked on the VAX-11/78x.



   This is relevant because for years I've heard a persistent rumor that the 
PDP-8/WPS-8 group at DEC had a 730 with microcode that had been hacked to 
include a PDP-8 compatibility mode, which they used for development.  It was 
faster than real -8 and supported timesharing to boot.

   I wonder if this is the source of the original poster's memory?  Can anybody 
confirm or deny this rumor?


Paul already commented this, and my understanding matches his actual 
observations. This was all on an 11/60. Said to have been the fastest 
PDP-8 around.


  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
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Bob Eager]

On Mon, 23 Mar 2020 08:10:17 -0700
"Robert Armstrong"  wrote:

> >FUBAR is the name of a 780 CSR (in the UBA: failed unibus address
> >register);
> > perhaps it was used in the 730 as well.  
> 
>   The 730 certainly had a UBA; don?t know if had a specific "FUBAR"
> register though.  But as far as a physical bar inside the chassis
> I've never seen nor heard of anything like that.  I have a 730 in the
> garage and it doesn't have any such thing.  The 730 fit into a single
> 10-1/2" chassis anyway, so there wasn't even a specific cabinet or
> rack dedicated to the 730.  And the 730 chassis was basically the
> same box as was used for the 11/44, but with a somewhat different
> backplane.
> 
>   I suspect the "FUBAR" at Dan's high school may have been a local
> joke :)

Not at all. It existed on the 780, at the very least, so most likely
elsewhere. Mentioned in the VAX11/780 Hardware Handbook (e.g. the
1979-80 edition).

See:http://www.tavi.co.uk/FUBAR.jpg

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

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

[Robert Armstrong]

>FUBAR is the name of a 780 CSR (in the UBA: failed unibus address register);
> perhaps it was used in the 730 as well.

  The 730 certainly had a UBA; don’t know if had a specific "FUBAR" register 
though.  But as far as a physical bar inside the chassis I've never seen nor 
heard of anything like that.  I have a 730 in the garage and it doesn't have 
any such thing.  The 730 fit into a single 10-1/2" chassis anyway, so there 
wasn't even a specific cabinet or rack dedicated to the 730.  And the 730 
chassis was basically the same box as was used for the 11/44, but with a 
somewhat different backplane.

  I suspect the "FUBAR" at Dan's high school may have been a local joke :)

Bob

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

Re: [Simh] Simh Digest, Vol 194, Issue 56

[dave porter]

Paul Koning wrote

RSTS/E had a general mechanism called "run-time system", vaguely like a 
cross between a shell and a shared library.


Or in more modern jargon an "operating system personality".  Take *that*, 
Windows NT !


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

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

[Paul Koning]

> On Mar 23, 2020, at 10:34 AM, Dan Gahlinger  wrote:
> 
> ...
> I remember they opened the chassis a number of times to show off that bar, 
> the part was indeed labelled "FUBAR", it was the source of some laughs.

FUBAR is the name of a 780 CSR (in the UBA: failed unibus address register); 
perhaps it was used in the 730 as well.  I'm sure the engineers got a kick out 
of being able to sneak that acronym past the writers and managers.

> ...
> there was what I'd call a bug in the vms on that system.  you could rename a 
> .dir that had files within it to say .dat then delete the .dat if you set it 
> /nodirectory, and all the files within the dir would still use up disk space, 
> even though there was now no longer any way to work with them. so you'd have 
> this missing disk space basically forever, still counting against the users 
> quota.
> I know because I did that at least twice.

VMS is like Unix: directories are name to inode number maps (not called 
"inode"; I forgot the correct name).  A file doesn't need a name.  I remember 
RSX had an explicit way to reference a file by its number, don't remember what 
VMS did.

paul

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

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

[Dan Gahlinger]

all I can tell you is the vax 11/730 I used in high school, I was told had a 
pdp-8 fep.

william Dukelow was the primary admin, teacher, in charge of the system.  
unfortunately he has just recently passed away.

I remember they opened the chassis a number of times to show off that bar, the 
part was indeed labelled "FUBAR", it was the source of some laughs.

the system had a mag tape drive and maybe a dozen terminals for student use, 
comprising of both xt and vt models 52, I think 82, and 100.  I still have my 
escape sequence cheatsheet for those from those days.

there was what I'd call a bug in the vms on that system.  you could rename a 
.dir that had files within it to say .dat then delete the .dat if you set it 
/nodirectory, and all the files within the dir would still use up disk space, 
even though there was now no longer any way to work with them. so you'd have 
this missing disk space basically forever, still counting against the users 
quota.
I know because I did that at least twice.

the 730 was at a high school in London Ontario called H.B. Beal Secondary, the 
vax served two other high schools as well, with terminals at those locations. 
I'm not sure how the links were done, except it was by phone.

from what I recall, they bought the 730 from the university, Western (UWO).  
but I don't recall UWO ever having a 730.
I started at Western in 1976 at Alumni Hall which was using pdp-10 and/or 
topps-10.
I'm not clear on the distinction there.
computing at Western moved to Middlesex College in 1978 which housed the Vaxen, 
the 782 which might have just been two 780s clustered. that distinction may not 
matter.

the only surviving photos may be from yearbooks, not the best quality or 
detailed. but I'll check them and see if there's anything I can find.

three of the four teachers that were at Beal have now passed away.
Mr. Rudy Specht, Mr. Ron Collyer, and now Mr. William Dukelow.
the surviving teacher is the only link I now have to this past.

I've been trying to convince him to sell me some things, or barter, so 
hopefully in time I'll have something to share and maybe replicate.

these are things I don't want lost to the winds of time. by posting here, in 
some ways it'll live forever somewhere on the net

those times were the best days of my life...

Dan


Try: https://www.grammarly.com

From: Simh  on behalf of Robert Armstrong 

Sent: Monday, March 23, 2020 10:03:33 AM
To: simh@trailing-edge.com 
Subject: Re: [Simh] Is it possible to simulate the first Vaxen I ever used?

> Paul Koning  wrote:
>... extended microcode to run PDP-8 code faster.  But it was an 11/60
running RSTS/E.

  So it is true (well, sort of, but with a PDP-11/60 rather than a
VAX-11/730)??  Do you know any details of how it was implemented?  If it ran
RSTS then it was obviously still a PDP-11 at the same time it was emulating
a PDP-8.  Was there a -8 "compatibility" mode, something like the -11 mode
on the VAX?

Bob

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

Re: [Simh] Andy Hoffman's VMS 4.x packages

[Ray Jewhurst]

So I am trying to get this package to work on as many systems as possible
and now I wonder if on the VAXStation 2000 or 2 if there are are any copies
of VWS floating around. Simh is I guess is a really good way to handle
shelter in place...

Ray

On Sun, Mar 22, 2020, 8:39 PM Johnny Billquist  wrote:

> That shows how reliable my brain is...
>
>Johnny
>
> On 2020-03-23 01:09, Bob Eager wrote:
> > We were running V4.5 on 8200s. But nothing earlier.
> >
> > On Mon, 23 Mar 2020 00:03:05 +0100
> > Johnny Billquist  wrote:
> >
> >> Uh. VMS V4 will most likely not run on the 8200/8250.
> >> But if you did get it up, you will need the full AME product
> >> installed in order to run RSX software, as these machines don't have
> >> hardware PDP-11 compatibility. VMS V4 was right at the time when the
> >> first hardware appeared which did not have the PDP-11 compatibility
> >> (MicroVAX). All larger/earlier VAXen had it.
> >>
> >> Johnny
> >>
> >> On 2020-03-22 21:10, Ray Jewhurst wrote:
> >>> Just a couple of observations and a question about Andy's distros.
> >>> First, they WILL run on a simulated VAX-11 730 if RAM is set to 5
> >>> megabytes.  Also, on the 730 all lp behaviour is normal.  Now for
> >>> my question, is my intuition right in that the RSX package either
> >>> won't run or simply be useless on the 8200/8250?
> >>>
> >>> Thanks
> >>>
> >>> Ray
> >>>
> >>> ___
> >>> Simh mailing list
> >>> Simh@trailing-edge.com
> >>> http://mailman.trailing-edge.com/mailman/listinfo/simh
> >>>
> >>
> >
> > ___
> > Simh mailing list
> > Simh@trailing-edge.com
> > http://mailman.trailing-edge.com/mailman/listinfo/simh
> >
>
> --
> 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
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

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

[Clem Cole]

On Mon, Mar 23, 2020 at 9:33 AM Robert Armstrong  wrote:

>   The 730 was interesting in that ALL of the CPU microcode was in RAM and
> was loaded by the CFE at boot time.  It was possible to locally modify the
> 730 microcode, and DEC even had a set of microcode development tools for
> the 730.


One of my favorite underground engineering stories.

Masscomp forked from DEC and number the folks on the HW and microcode teams
that had worked on the 750/730 ended up Masscomp.  They wanted that set
same set of tools, but it required VMS which were did not have (and we were
not going to run in our 750 and were in BLISS of course).   As a compromise
to the HW team, a couple of us (Terry Hayes, tjt and I IIRC) got a manual
for those tools and with some oral directions from Dick Monroe and some of
the other microcode guys, using awk/lex/yacc *et al* - we cons'ed up a
replacement fairly quickly, of course, running on our 750/BSD and then
later self-hosted on the Masscomps running RTU.

Around the same time, Widdoes *et al* spun SCALD CAD tools out of Livermore
and Stanford creating Valid Logic design (which was a UNIX flavor under the
covers).   Both DEC West in particular and Masscomp started to use Valid
boxes for HW support.   DEC West had written a bunch of macros and tools
that made the Valid easier to use. And our HW guys knew about them.  DEC
West had heard we had new versions of the DEC tools in C and on UNIX.

So one night the Maui Kia parking lot (this is now Yankzee River in
Littleton), a tape swap was arranged.   We gave them our Unix based version
of the microcode tools and we got their additions/updates to Valid.
Management of neither company never knew the difference.

FWIW: I went looking for the tapes of both a couple of years ago, and sadly
I can not find either.  But its one my keep looking list when I get around
to cataloging some of the old SW from those days.

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

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

[Robert Armstrong]

> Paul Koning  wrote:
>... extended microcode to run PDP-8 code faster.  But it was an 11/60
running RSTS/E.

  So it is true (well, sort of, but with a PDP-11/60 rather than a
VAX-11/730)??  Do you know any details of how it was implemented?  If it ran
RSTS then it was obviously still a PDP-11 at the same time it was emulating
a PDP-8.  Was there a -8 "compatibility" mode, something like the -11 mode
on the VAX?  

Bob

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

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

[Paul Koning]

> On Mar 23, 2020, at 9:33 AM, Robert Armstrong  wrote:
> 
>> Ethan Dicks  wrote:
>> Using a PDP-8 as an FEP on any VAX definitely sounds odd.
> 
>  The console front end for the 730 was an 8085 (just like the KS10, FWIW).
> 
>  The 730 was interesting in that ALL of the CPU microcode was in RAM and was 
> loaded by the CFE at boot time.  It was possible to locally modify the 730 
> microcode, and DEC even had a set of microcode development tools for the 730. 
>  I've never seen them except in references.
> 
>  This is relevant because for years I've heard a persistent rumor that the 
> PDP-8/WPS-8 group at DEC had a 730 with microcode that had been hacked to 
> include a PDP-8 compatibility mode, which they used for development.  It was 
> faster than real -8 and supported timesharing to boot.
> 
>  I wonder if this is the source of the original poster's memory?  Can anybody 
> confirm or deny this rumor?

I can refute that.  The WPS group sat right next to my first DEC group 
(Typeset-11).  Yes, they had a machine with extended microcode to run PDP-8 
code faster.  But it was an 11/60 running RSTS/E.  That was in 1978; the 730 
didn't exist yet back then.

paul

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

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

[Robert Armstrong]

> Ethan Dicks  wrote:
>Using a PDP-8 as an FEP on any VAX definitely sounds odd.

  The console front end for the 730 was an 8085 (just like the KS10, FWIW).

  The 730 was interesting in that ALL of the CPU microcode was in RAM and was 
loaded by the CFE at boot time.  It was possible to locally modify the 730 
microcode, and DEC even had a set of microcode development tools for the 730.  
I've never seen them except in references.

  This is relevant because for years I've heard a persistent rumor that the 
PDP-8/WPS-8 group at DEC had a 730 with microcode that had been hacked to 
include a PDP-8 compatibility mode, which they used for development.  It was 
faster than real -8 and supported timesharing to boot.

  I wonder if this is the source of the original poster's memory?  Can anybody 
confirm or deny this rumor?

Bob


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

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

[Ethan Dicks]

On Sun, Mar 22, 2020 at 8:21 PM Dan Gahlinger  wrote:
> I believe it was a Vax 730 with a PDP-8 FEP, inside the main chassis it 
> actually had a part labelled (in big letters) "FUBAR"
>
> If I remember correctly, it ran VMS v2.4

I'm pretty sure VMS 3.0 was the first to support the 11/730 (the
11/730 came out in April, 1982 and VMS 3.0 release notes are dated
May, 1982, and mentions that the upgrade scripts do not work with the
11/730 - you have to follow the install procedure).

I _think_  VMS 2.3 and the 11/750 are contemporary.  There is
definitely an install guide for VMS 2.3 on the 11/750.  I don't recall
if you could load VMS 2.2 on a 11/750 or not.  What is clear is that
VMS 2.0 is documented in the release notes that the SID register has
to have a CPU type of '1' and a min ECO of '3' (the 11/750 is a CPU
type '2').

Using a PDP-8 as an FEP on any VAX definitely sounds odd.  The 11/780
(and 11/782 and 11/785) used a PDP-11 as the FEP.   The console medium
was the RX01.  The 11/750 has an embedded console processor; I'm not
quite sure how they implemented it (11/750 microcode?)  The 11/730 has
an 8085 that you talk to first that reads files off a console TU58 and
pokes shared resources on the VAX processor (much more like an 11/780
than the 11/750).  The differences made life in the 80s festive for a
new System Manager learning how they worked.

> Note: someone decades ago told me the plural for Vax was "Vaxen", and it just 
> stuck...

Yep.  That's normal usage.

Cheers,

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