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.6 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MIME_QP_LONG_LINE, 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 83ef76e3 for ; Sat, 31 Aug 2019 03:47:21 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id D3C0F9C0E8; Sat, 31 Aug 2019 13:47:19 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 029689C0B2; Sat, 31 Aug 2019 13:47:06 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=fail reason="signature verification failed" (1024-bit key; unprotected) header.d=ccc.com header.i=@ccc.com header.b="QEs9blCq"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id 1230E9C0B2; Sat, 31 Aug 2019 13:47:04 +1000 (AEST) Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by minnie.tuhs.org (Postfix) with ESMTPS id 7EFC09C0A7 for ; Sat, 31 Aug 2019 13:47:03 +1000 (AEST) Received: by mail-qt1-f196.google.com with SMTP id g4so9903121qtq.7 for ; Fri, 30 Aug 2019 20:47:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccc.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R51hIOjXkpAVsjFc8TWjPh0+K97fjz9Tyd5jQn/m4ws=; b=QEs9blCqkz5dj1vNWqlVyGPge0xPy8msRPoolcz5F3s3LS3oiDv3X5qznJLZS3fXxW UTyV2cVyxFBgotu6+KaRMihHGERaNGy/ltMvpSGQp4MG+t0WUcpxU5Befw+B4zOGeFaJ l6ytHWFjJkOeopXpj9SoR4CqmtxKLhdq50+v4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=R51hIOjXkpAVsjFc8TWjPh0+K97fjz9Tyd5jQn/m4ws=; b=AROlDbihf5m3wo423Yv1WSzRQEnwSXYgWGsckq8pn7+O7gGLVfAbrH8VluH+Ek9x79 KaVMJ74BUFwbXb973WK+Lvq5c2iAWSdlDMbe3z2qGfObTitRniE5XzMxRfPK/ao4hLeJ 7+vd4pYXDCj2Ns+h/5Q9od77vqKDc9XyivlbtkKykMe2wEVs9KslnorgmlrW/idFWk9d 3mhF2nHJRyZ/5uDOzK7yN+0rljycIDIeD/at4uwOSjvxhOVtqph+5+mYBOEunBsFSRFE TLCwZhOxNx2xjSfxctJgl9/C7KY0g/pkNkS7g0Uxt6o0M5zxjB++OEf4PN2xGxRYi3hY vMkg== X-Gm-Message-State: APjAAAWr1S7wxaVrVk23RBlZF5teTYKcQkyik4hU+mz1rpKND68EJGVR TOiy+XMpB9/P+1Z74naH0PqQ9Q== X-Google-Smtp-Source: APXvYqz7AiJpn1JfZRO/ewFK65srtR70UwEqVqvt/v3aiWy1mQ1Tr/aTFXlwEiby6ttyfFHsDBxDKw== X-Received: by 2002:aed:30e2:: with SMTP id 89mr3354815qtf.237.1567223222290; Fri, 30 Aug 2019 20:47:02 -0700 (PDT) Received: from [192.168.10.108] (pool-173-48-42-254.bstnma.fios.verizon.net. [173.48.42.254]) by smtp.gmail.com with ESMTPSA id 22sm3876650qkc.90.2019.08.30.20.47.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 30 Aug 2019 20:47:01 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Clem cole X-Mailer: iPhone Mail (16G77) In-Reply-To: Date: Fri, 30 Aug 2019 23:47:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8797F327-14CE-42C2-9B8B-8A58AEA1CC82@ccc.com> References: <1567196510.21824.for-standards-violators@oclsc.org> <20190830215202.GA974@mcvoy.com> <20190831011359.E9F491570CE9@mail.bitblocks.com> <88242A0D-D08E-47EB-84DC-A7205780A417@ccc.com> To: Gregg Levine 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: , Cc: The Eunuchs Hysterical Society Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" Fwiw. the 68k design team used a 11/70 running an ISC based Unix and with Ra= nd Editor running in Perkin Elmer Fox terminals with special microcode in th= e 6800 in the terminals roms. Basically Les, Nick and Tom were all Unix fol= ks. =20 Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.= =20 > On Aug 30, 2019, at 11:14 PM, Gregg Levine wrote:= >=20 > 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. >=20 > It was fun. > ----- > Gregg C Levine gregg.drwho8@gmail.com > "This signature fought the Time Wars, time and again." >=20 >> On Fri, Aug 30, 2019 at 10:58 PM Clem cole wrote: >>=20 >> 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 o= nce told me, that it turns out he had tried to fix it but there were a serie= s of errors and some short cuts they used to fit it in the store. They gave= up trying to fix it as the part was purely skunkworks and they could not re= spin it at the time. After it succeeded and were a real project, the differ= ence between the original and the 10 was Nick redid the microcode but they h= ad made a larger microstore - otherwise basically the same Si. >>=20 >> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not qui= te. >>=20 >>> On Aug 30, 2019, at 10:46 PM, Clem cole wrote: >>>=20 >>> 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 a= nd designed the BI before he left dec. He was a bus and memory specialist >>>=20 >>>=20 >>> *** west coast VS east coast training - calling it a TB vs a TLB. >>>=20 >>> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not qu= ite. >>>=20 >>>>> On Aug 30, 2019, at 9:13 PM, Bakul Shah wrote: >>>>>=20 >>>>> On Fri, 30 Aug 2019 20:58:13 -0400 Clem Cole wrote: >>>>>=20 >>>>> Actually not in lock step. They were independent. One was called the= >>>>> executor and the other the fixer. When a fault was detected the execu= tor >>>>> was sent wait stated while the fixer handled the fault and refilled th= e >>>>> 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 allo= w the >>>>> executor to actually take the fault and do something else while the fi= xer >>>>> replaced the TLB entry >>>>=20 >>>> 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? >>>>=20 >>>> 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.