[TUHS] dmr streams & networking [was: Re: If not Linux, then what?]
bakul at bitblocks.com
Sat Aug 31 13:19:04 AEST 2019
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.
More information about the TUHS