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

[Bakul Shah]

It would be interesting to see its MMU details.

> On Aug 30, 2019, at 7:46 PM, Clem cole <clemc at ccc.com> wrote:
> 
> 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 at bitblocks.com> wrote:
>> 
>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole <clemc at 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.