On 01/14/2017 09:29 PM, Jon Elson wrote:
On 01/14/2017 05:40 PM, Rick Bensene wrote:
>
>> From: "Rick Bensene" <rickb at bensene.com>
>>> - A Tektronix 4132 Unix workstation using a National 32016 CPU and a
>>> 4.2bsd port called UTek
>>>
> Jon wrote:
>
>> Gee, how does it perform? I built a clone of a Logical
>> Microcomputer Co. 32016 Multibus system and got it working.
>> But, it was glacially slow! I did have some memory that was likely
>> a little slower than the stock memory, but it wasn't insanely slow.
>> But, firing up certain things >like editors was just maddening.
>> And, I'm not talking about Emacs, just vi. I eventually got a
>> MicroVAX-II to replace it, and, yes, that DID have a cache to speed
>> >up the memory, but it was quite a difference.
> Well...considering the era, it wasn't too bad. By today's standards,
> yeah, it's pretty darned slow.
> Vi starts up pretty quick, even with a couple of terminals running on
> it. It runs rogue pretty nicely, quick enough for multiple people
> to play it at once.
>
> The machine has 7MB of RAM, which really helps. Without additional
> RAM, there's only 1MB on the main board, and running it with just 1MB
> makes it incredibly slow. There isn't any external cache.
That can be
because of swapping for most everything to disk. uVAX that
is...
Ahh, that may be part of the difference. I can't
remember how much
memory I had on it. I would not be surprised if it was as tiny as 128
KB, or maybe 256 KB. I'll check my schematics to see how many address
lines were implemented.
My uVAXII used to run a Notes file and 5 regular users including me with
DECwindows (it was a GPX).
Speed compared to the latest single user 3ghz box does not compare but
unlike many PC its oS
does not eat its feet when stressed.
MicroVAX tricks for speed were things like two disk controllers one
purely for swapping with say a RD31 (they were fast
for their size) and the OS and users on separate disks using the second
controller.
The only pokey machine was the uVAX2000 as it was maxed at 12meg of ram
ad the only disk controller was
not fast nor pretty i that it was very dependent of the OS to handle the
scatter gather in memory as the disk only
had something like a 16K memory window for DMA. Not the CPUs fault,
just minimization of hardware has costs.
It's fun
to fire it up and just relive the days when I was on cloud
nine to have my own personal Unix workstation that I built myself
from parts.
If mine hadn't performed so poorly, I might have continued to use it,
and upgraded parts.
I got versions of Genix and Xenix with it. These were likely early
ports for the 32016, and may have had poor implementations for the MMU
for instance.
The 32016 was not clocked very fast nor did it have any pipelines to
speak of. I needed all the help it could
get and lots of ram plus fast ram (no wait states) helped some. If
ther ewas a MMU it ran a bit better as the
OS didn't have to swap to the then rather slow disks with small read
write caches.
If the 32016 had a second generation, some tweaks and faster process it
might have had hope but like 68K
and Z8000 it was good idea but late. The 8088 and 8086 had that space
and were generally even then
capable of going faster.
Generally any machine that did virtualization or swapping was at the
mercy of the disks of the day
as some drives and their controllers were slow.
Allison
Jon