Rod Coleman's personal history of founding, building & running SAGE

Paul Koning paulkoning at comcast.net
Mon Jan 4 12:18:59 CST 2021



> On Jan 4, 2021, at 11:00 AM, emanuel stiebler via cctalk <cctalk at classiccmp.org> wrote:
> 
> On 2021-01-02 22:34, Fred Cisin via cctalk wrote:
>> On Sat, 2 Jan 2021, Liam via cctalk wrote:
>>>  I'm not really familiar with SAGE machines. They were not as
>>>  well-known in the UK, I think, being upmarket from the Apple ][ and
>>>  IBM PC, both of which were eye-wateringly expensive by UK standards of
>>>  the time.
>> 
>> Possibly, they weren't aimed at the same target audience.
>> 
>> Perhaps they were intended more to compete with machines such as PDP-11,
>> rather than Apple][ and IBM PC.
> 
> I was working 1981 with pdp11s and VAX780. Then I heard/read about the
> 68000, had to have one of those. Simple programming model, flat address
> space and really good performance. Signed up at a startup in Germany in
> 1982, had a lot of fun with all of them(68000, '10, '20, '30, '40). We
> basically only sold to research/labs.

I was at DEC at the time, and I remember discussions around the office saying "this is a VAX on a chip".  The instruction set made it feel that way.

Not long after that, Apollo Computer was founded to build workstations using the 68000.  They found out the hard way it is NOT a VAX on a chip.  The key design error is that the 68000 had page access aborts, not page faults -- they weren't restartable so you could not create virtual memory using its page access flags.  That mistake was fixed in the 68010.  I vaguely remember that Apollo worked around the issue by using a pair of 68000 chips running one cycle apart, so when the abort hit on the lead one you could stop the trailing one and fake a restartable page fault.

Some years later I wrote the fast packet handling code of the DECbridge 900 (?) -- FDDI to 6 Ethernet ports.  That used a 68040 at 25 MHz, and with careful design it could process a packet every 8 microseconds (12 microseconds if the destination address wasn't in the address cache CAM).  One trick was a memory system that did some operations on the rising edge and some on the falling edge, i.e., effectively a "2.5 cycle" access.  The other (mine) was to use the fact that the 68040 had a "RISC subset" of instructions and addressing modes that would run in one or two cycles, while the other instructions took MUCH longer.  By sticking to handwritten assembly language in the RISC subset I could make it go very fast.  It also required awareness of oddities like the fact that branch-taken is faster than branch-not-taken, the opposite of pretty much every other computer.

	paul




More information about the cctech mailing list