Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?]

[Clem cole <clemc@ccc.com>]

There was most definitely a TLB or as Dave called it ‘The TB’ ***
Remember Dave Cane (Masscomp hw lead) was part of the 780, led the 750 and designed the BI before he left dec.  He was a bus and memory specialist 


*** west coast VS east coast training - calling it a TB vs a TLB.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Aug 30, 2019, at 9:13 PM, Bakul Shah <bakul@bitblocks.com> wrote:
> 
>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc@ccc.com> wrote:
>> 
>> Actually not in lock step.  They were independent.  One was called the
>> executor and the other the fixer.  When a fault was detected the executor
>> was sent wait stated while the fixer handled the fault and refilled the
>> TLB.   Once the TLB was set to instruction was allowed to complete.    Btw
>> when the 68010 was released the pals on the board were changed to allow the
>> executor to actually take the fault and do something else while the fixer
>> replaced the TLB entry
> 
> As I remember, the issue with 68000 was that instructions were
> not restartable so in case of accessing memory that didn't
> exist, you couldn't take a segfault and do anything useful.
> This is why you needed a second processor to deal with an
> external MMU. There would have been no TLB unless you actually
> added an external TLB -- but an external CAM would've been
> very expensive. May be a direct map?
> 
> What we did at Fortune was to utilize a 4 entry external map:
> text, data, extra and stack.  When a new function was invoked
> it would do a 'probe'. If the probe caused a segfault, stack
> was extended in the handler. The probe didn't have to be
> restartable. So we didn't need a second 68k. This logic may
> have been in the V7 port we started from.