From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id a33250b5 for ; Sat, 31 Aug 2019 03:15:29 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 8FA659C0C6; Sat, 31 Aug 2019 13:15:28 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 2E0A09C092; Sat, 31 Aug 2019 13:15:11 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="oQDwCoG+"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 092049C092; Sat, 31 Aug 2019 13:15:10 +1000 (AEST) Received: from mail-qk1-f194.google.com (mail-qk1-f194.google.com [209.85.222.194]) by minnie.tuhs.org (Postfix) with ESMTPS id 7FB649C00B for ; Sat, 31 Aug 2019 13:15:09 +1000 (AEST) Received: by mail-qk1-f194.google.com with SMTP id m10so7996290qkk.1 for ; Fri, 30 Aug 2019 20:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JmYhWuric+rwwvTxU9JfIdPUED9+CeRyY5kh4Bso1cU=; b=oQDwCoG+039AjqFvl/vuqJcLWigIdFRl22GNlyQ0HXXqP8Hhq3pCQf6FnrVtBok3+7 Z1ilrYVdeNnk0b2BkWAQVlHXLdg/E+8cgU0WggnPiC9T8Jy68Gan+VhEI43gc/OKpQJ9 iKcPQKlnYW8MHh3GmsQtVLCutr5SHXVfhDGeCDJhq2Fycav0ic6Rk/qFS44wts1ZnHi9 ZV+BQSQrHL5oFZ6WVRtT/3QDHwlrBvmgfbS0m4CFwJap5HUhmzLMvRMF2/Bo1kcDTzJf 6Uym0a1sjClOMVGAdd77l/SPeK4uZEHNYl8wBfk5lv62f7fIypctZ56cWKl4NYyfXdc9 W8Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JmYhWuric+rwwvTxU9JfIdPUED9+CeRyY5kh4Bso1cU=; b=A+5Lh7+xAST0xzK4yLUb8Dr/9Eq2hy4WEsgzoMr+CopEusXPdf2LBTr46ilB902pjs LqrmyuvGxRGWHB9we0V3Jj/9juA32ixVSzdwmpBS0bh/+QG5s31MmlgCNDr5UgPFOhH/ eNzxruHmNAXaBX7wt+rqeMlBc6ePiPE7HhD+njK+2hhYgJPHoTwgpHeUDN4j8jfmZA12 O+0wN9Qz6SAem+cAdAGJN8UvebWzyRjtd3hqYCnna8sf1elWmDDNNwVoKfJTi6Ro8/Hk SklDv9lFn9mjlKws5eaaZexK2/hPF1o2mzaSBrHheIS5ZwEVpPntSb+PW6hkct4BjwUp 4Tuw== X-Gm-Message-State: APjAAAVRf853JJzkXYXRA9wTCywxcAcU8uJCy5gVhPWBIYhPSdAxT7yb wb4apBD4o14WjkX7+D6sJOPoQhOa8kYBJocDhh4v9FQg X-Google-Smtp-Source: APXvYqxh9X+/dTnwtSkdA7xCL2ClHofGNgj4A1xVE1KRTHCvcI9YrF/1RTYodCJ8IsKiRPrCYNcEIvqAi5eb1rBIPKQ= X-Received: by 2002:ae9:e914:: with SMTP id x20mr17951615qkf.57.1567221308584; Fri, 30 Aug 2019 20:15:08 -0700 (PDT) MIME-Version: 1.0 References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> In-Reply-To: From: Gregg Levine Date: Fri, 30 Aug 2019 23:14:29 -0400 Message-ID: To: The Eunuchs Hysterical Society Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [TUHS] dmr streams & networking [was: Re: If not Linux, then what?] X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Hello! That definitely groks with a decidedly thirty year old memory. I remember going to BUSCON, and getting into an interesting discussion with the folks behind the M68K just how difficult it could be to run more modern code (or operating systems). Let's just say it was peculiar. They wanted to stick with a proprietary OS, and one odd man there wanted to expand CPM-68K. And still another was looking into bringing up UNIX on it. It was fun. ----- Gregg C Levine gregg.drwho8@gmail.com "This signature fought the Time Wars, time and again." On Fri, Aug 30, 2019 at 10:58 PM Clem cole wrote: > > Btw. The issue with the 68k was Nick Tredenick=E2=80=99s original Microco= de did not save enough information during some of the faults. Les Crudele = once told me, that it turns out he had tried to fix it but there were a ser= ies of errors and some short cuts they used to fit it in the store. They g= ave up trying to fix it as the part was purely skunkworks and they could no= t respin it at the time. After it succeeded and were a real project, the d= ifference between the original and the 10 was Nick redid the microcode but = they had made a larger microstore - otherwise basically the same Si. > > Sent from my PDP-7 Running UNIX V0 expect things to be almost but not qui= te. > > > On Aug 30, 2019, at 10:46 PM, Clem cole wrote: > > > > There was most definitely a TLB or as Dave called it =E2=80=98The TB=E2= =80=99 *** > > 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 q= uite. > > > >>> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: > >>> > >>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: > >>> > >>> Actually not in lock step. They were independent. One was called th= e > >>> executor and the other the fixer. When a fault was detected the exec= utor > >>> was sent wait stated while the fixer handled the fault and refilled t= he > >>> 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 all= ow the > >>> executor to actually take the fault and do something else while the f= ixer > >>> 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.