🚀 go-pugleaf

>From NZeck.WBST.PARC-MAXC Thu Mar  4 11:07:10 1982


---------------------------

Mail-from: Arpanet host BRL rcvd at 25-FEB-82 1040-PST
Date: 25 Feb 1982 0927-PST
From: BISBEY at USC-ISIB
Subject: Re: Wicat Graphics
To:  Works at MIT-AI 
cc:   Bisbey at USC-ISIB
Via:  Mit-Ai; 25 Feb 82 12:50-EDT
Via:  Brl-Bmd; 25 Feb 82 13:04-EDT

I too have visited Wicat's Utah offices.  The graphics option for the
150-WS is 400x300.  Also, the 150-WS is already multibus.   We found
the unit to be EXTREMELY SLOW.  Wicat admitted that there were two
wait states per memory access which (they said) slowed the 68000 to
63% of 8 MHZ (that's an effective speed of only 5 MHZ).  Rumor has it
that someone put a scope on the WICAT and found the 68000 to be
running at an effective speed of only 3 MHZ.  WICAT was working on
a memory board that used 64K chips and a small page table for the
first 2 meg. of address space.
-------

While I have no bias toward a particular system, I am interested in if anyone has
any info on the performance of other 68000 systems (Fortune Systems, Forward
Systems etc...)

	 Is it Wicat's software (I assume it was their opsys that was running not a
version of unix) that is slow or is it really the hardware?

	It looks like from the 68k specs that for no wait state memory access, the
memory access time has to be around one to one an a half clock cycles (125-185
ns) including driving any busses, decoding etc.  While this is doable, it puts a
$premium on memory.  Also if the design includes a memory management unit
of some flavor (which would be desirable for os/user protection/dynamic
binding), this will add to the required memory performance.

	Also note that while the processor is slowed down for a memory access, it
still implements the execution phase of the instruction at 8 Mhz.

------------------------------------------------------------