[Info-vax] For sale: VAXstation 4000/90 128MB Fully Working and Tested

[Johnny Billquist]

On 2022-07-02 14:46, Bill Gunshannon wrote:
> On 7/2/22 06:16, Johnny Billquist wrote:
>> On 2022-07-02 00:50, Bill Gunshannon wrote:
>>> On 7/1/22 16:02, Arne Vajhøj wrote:
>>>> On 7/1/2022 2:31 PM, Bill Gunshannon wrote:
>>>>> Was it?  My guess is that the only improvement that might have been
>>>>> needed for Dave's application was a faster processor.  And that was
>>>>> done even after the death of the PDP-11 in DEC's eyes.
>>>>
>>>> I don't think PDP-11 not being available was the driver behind the
>>>> move to VAX.
>>>
>>> Not lack of availability at first, but complete stoppage of development
>>> played a major role.
>>
>> There wasn't. Last release of RSX was in 1999.
> 
> That's OS development, not CPU.  BSD for the PDP-11 continues to
> develop today as far as I know.

You said "complete stoppage of development". Now you say you only meant 
hardware. And actually just CPU development.
There wasn't any actual CPU development after about 1980. Way earlier. 
The last expansion was CIS, which noone ever actually even cared about.

Move to VAX happened primarily because of address space limitations on 
the PDP-11.

On the other hand, DEC never managed to successfully migrate customers 
away from the PDP-11 even through they tried. The PDP-11 was simply just 
better for some tasks.
So I don't really get what you are trying to claim.

>>>> PDP-11 production continue until 1997 when people were migrating
>>>> from VAX to Alpha - not to VAX.
>>>
>>> How much development was done during that period?  How many shrinks
>>> to increase speed?  How many new peripherals were made available?
>>> We didn't even get decent network cards or even disk controllers for
>>> things like SCSI except from third parties.  Trust me, people using
>>> PDP-11's could see the writing on the wall.
>>
>> There wasn't much demand for speed increase. 
> 
> I don't think there was ever demand for speed increases in any CPU.
> But users were always happy to see it.

There was definitely a demand for faster PDP-11s up to a point. But 
somewhere along the way, it became a non-issue as the effort in 
developing ever larger software solutions on the PDP-11 became a huge 
effort in just fitting it into the address space. And so large, complex 
software development moved away from the PDP-11 to the successor - VAX.
But the PDP-11 didn't die because of that. It just became a little more 
limited in what customers used it for, and for that, the speed was 
already acceptable. As was the other parameters.
The one thing asked for later in life was improvements in tools and 
networking, and reduction of price.

Demand for faster CPUs exists also today. But we've sortof hit a wall 
for single CPU speeds, so now we're mainly adding more and more cores.

>>                                               But DEC even did offer 
>> their own SCSI controller (RQZX1), so it wasn't just third party. You 
>> are drawing conclusions from incorrect data.
> 
> Was that SCSI developed for the PDP-11 or the MicroVAX and just
> happened to work on the PDP-11?  Why did they never release a DSSI
> card for the PDP-11? (Actually, I am sure the VAX module would have
> worked but I am not aware of any support for it in a PDP-11 OS.)

The controller was for Qbus, and talked the same MSCP as any other Qbus 
MSCP controller, so it was as viable for any system.
DEC certainly added support in the PDP-11 systems for the device, but of 
course they also added it to VMS.

As far as DSSI goes, it's a bit more complicated, but basically, there 
was one DSSI controller that worked just fine on PDP-11s. I don't 
remember the name of it right now, but there was one Qbus controller 
that spoke MSCP. So, worked just as well as any other MSCP controller.

However, with DSSI you also had controllers that talked SCA, over which 
then MSCP was used. But SCA was a different protocol with some added 
complexity which DEC never added drivers for in the PDP-11. Reasons 
might have been several, but I would say the main one is that unless you 
created new boot roms, and did some major work on the OSes at that 
point, you would not have been able to boot from those controllers 
anyway, so what would be the value? And I suspect it would have been 
pretty much impossible to write a boot strap rom that would have booted 
over SCA in just 64 bytes, which is the size available for the M9312 
boot roms.

Again, memory space is the thing that comes back to bite you.

>> The biggest reason for migration from PDP-11 to VAX was because of the 
>> larger virtual memory addressing space.
> 
> Which could have been developed into the PDP-11 while keeping most of
> the good things in the architecture.  I still think it would be fun to
> use something like SIMH to build an "improved" PDP-11 just to see where
> it could have gone but, alas, I am too far past my prime to actually
> do it.

That is really what the VAX was. You would never be able to run actual 
PDP-11 code on anything that had a larger address space. You need a 
compatibility mode for this, just as on the x86 and god knows what else.
With the VAX, the compatibility mode was limited to user space code, but 
doing a compatibility mode that worked all the way would have been 
possible. But I don't think it would have been a good idea, since that 
would have crippled the VAX.

As soon as you do some change to address space that is more directly 
visible, it cease to be able to run a PDP-11 binary to begin with, so 
you can't do it better than that. We've talked about this before, and 
you seem to constantly fail to understand this.

You can't "expand" the PDP-11 to 32 bits and still have it be a PDP-11. 
You can at best make something spiritually the same. But that is already 
what the VAX was.

>> People really did not (in general) enjoy trying to squeeze ever larger 
>> software systems into the tiny addressing space. It was a lot of 
>> effort that could be spent elsewhere.
> 
> Thus the reason the processor should have seen more development and not
> a complete and totally incompatible replacement.
> 
> But, at this point that is all water under the bridge.

I just wished you had the technical understanding to see why what you 
seem to imagine is not possible.

   Johnny