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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 3fa55898 for ; Mon, 31 Dec 2018 15:06:27 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id CA52AAF369; Tue, 1 Jan 2019 01:06:25 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id AD2E6AF365; Tue, 1 Jan 2019 01:06:09 +1000 (AEST) Authentication-Results: minnie.tuhs.org; dkim=pass (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="Q8vDe+KP"; dkim-atps=neutral Received: by minnie.tuhs.org (Postfix, from userid 112) id A035EAF364; Tue, 1 Jan 2019 01:06:07 +1000 (AEST) Received: from mail-ot1-f42.google.com (mail-ot1-f42.google.com [209.85.210.42]) by minnie.tuhs.org (Postfix) with ESMTPS id A5740AF38A for ; Tue, 1 Jan 2019 01:06:03 +1000 (AEST) Received: by mail-ot1-f42.google.com with SMTP id 32so23542067ota.12 for ; Mon, 31 Dec 2018 07:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=hR0QHralncapTfCnTAFyXw+rb47Z37ZwTDqX0UjC95k=; b=Q8vDe+KPZ2KxkzER9EtWZ2voDJ5DgUocscScPkP4PNV87HGaKFjSgT9WL+C0qrFI38 pUmB0eFjoyKcuPFEuwlYFA95aGuLrbFKJpBLcgNqMcaRTYz/FZgNpAepsutbSaRGSgc8 mF/23vc7soeypaRijaJbXZzzX/gHAXxFk4VJVeBbrIeUJWX3+Z2K5EMNhBXYck2fUULy astoDHKM2L4ulKBB73/O1tmCD2iQ7vfUp21vLoFyfo3urbFi9kD1pPDmyKAobdzR0fbB oBbHyG5NEqowY+rFIR0kXo8/4jV2vTGhppROsbmSVJo16Bn9Y9mW3w/4QsUc1OCWO9io tQmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=hR0QHralncapTfCnTAFyXw+rb47Z37ZwTDqX0UjC95k=; b=S7xL9jtSrJM5tsU1d6jtACqlteSTA5CrMbLIBWabSCjQKB1VHuxarhY2au6JAJsiMI Od9bIxDC5tqhaA5cLooUQKqT54cTBegpTDoDKDj7IAgaqcSJ3i5u6L10fiswijuYItY+ U2a+4BZ/Yb8g9iJUneNP8GlHq/wL/Om42wTvii4nHcIJNBKnadeH2ztHiwfWfefaYMLj McT2JMPoGqIO4ASi1eXHFodtEn+cjp59ToIRPnW/cpswZ89Q/AGaNR85zR+NOh7DLox0 5eQpkeAlMda79rXF2IzFrOs5ecw4za0OTcP8dVeOTL2q/yp+jolwTbmEhhg1nCiJouH6 ssPQ== X-Gm-Message-State: AJcUukdEC0bBJ/f/60xTDfjGoZJVaZXqLGasPOhhfyzmTYngy/lhtDle 2aZfs32Wah1NyBw+SJBST00zFoHy X-Google-Smtp-Source: ALg8bN7R7OnQ6eBAvBiz7ZKsoKzr0iFuJS4aNGXq3FGyyDj/DlZMwSEZLqcEBKDSd7p/vSUahDzKSQ== X-Received: by 2002:a9d:19eb:: with SMTP id k98mr24522124otk.205.1546268762306; Mon, 31 Dec 2018 07:06:02 -0800 (PST) Received: from terra.local ([107.242.112.45]) by smtp.gmail.com with ESMTPSA id l1sm28525308oib.10.2018.12.31.07.06.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 31 Dec 2018 07:06:01 -0800 (PST) To: Noel Chiappa , tuhs@tuhs.org References: <20181231065125.2A34818C073@mercury.lcs.mit.edu> From: Will Senn Message-ID: Date: Mon, 31 Dec 2018 09:06:00 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 MIME-Version: 1.0 In-Reply-To: <20181231065125.2A34818C073@mercury.lcs.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 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" On 12/31/18 12:51 AM, Noel Chiappa wrote: > > From: Will Senn > > > We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a > > PDP 11/45 (preferably another SIMH) > > Heh! When I saw the subject line, I thought you wanted to upgrade a > _physical_ -11/40 to an -11/45. ('Step 1. Sell the -11/40. Step 2. Buy > an -11/45.' :-) Ha! I have been struggling for a way to convey some questions I have in a way that would lessen the amount of assumptions baked into the answers (Sometimes when I ask questions, what I get back sounds to my ears a lot like, just load the frigglewump into the carbathingamajig and boot normally). Then I thought, how would I have asked the question if it the situation had come up in my real lab. I'm sure the scenario was not period accurate, but apparently it was close enough to spark some very helpful answers. Thanks for not dismissing the thread as frivolity. > > for our Unix v6 installation. > > Why on earth would an organization have such a thing? :-) Well, interestingly enough. I find using v6 to be quite fun and one step closer to some primal tech place :). I'm sure y'all have seen Mills's winning Best in Show IOCCC entry: https://www.ioccc.org/2018/mills/hint.html and the actual 'code': https://www.ioccc.org/2018/mills/prog.c Somehow, this sorta thing just jazzes me. > > > Our CEO was traveling and met a techie in first class (seriously, > > first class?) who told him that we needed one. > > Heh. If said techie knows about the two, he's probably pretty senior (i.e. > eligible for Social Security :-), and thus elegible for first class... :-) > > > It has fairly low utilization - a developer logs in and writes code > > every few days > > Who the *&%^&*(%& is still writing code under V6?! Well... writing code might be a stretch, but certainly playing around in code is fair. The developer'd be me :) > > And how do you all get the bits in and out? (I run mine under Ersatz-11, > which has this nice device which allows it to read files off the host file > system; transfering stuff back and forth is a snap, I do all my editing with > Epsilon on my Windoze box, 'cause I'm too lazy to bring up the V6 Emacs I > have.) > > > 1. Are there any v6 specific concerns about upgrading? > > Not that I know of. Fantastic, I'm prolly gonna try it. > > > 2. Why should we consider taking the leap to the 11/45? Everything > > seems to work fine now. > > You're asking _us_? Oh yeah! > > Some larger applications will only run on an split-I-D machine, is about the > only reason I can think of. > > Oh, also, the floating point instructions on the /45 are the only kind > understood by V6; the C compiler doesn't emit the ones the /40 provides. Any > floating point code run on the /40, the instructions are simulated by a > trap handler (by way of the OS, which has to handle it and reflect it to > the user process). I.e. very slow. Interesting, I had no idea. In the simulator, speed is rarely an issue with the types of programs I've been messing around with so far, so I hadn't noticed it. > > 3. If we jump in and do the upgrade, how can we immediately recognize > > what has changed in the environment? I.e what are some things that we > > can now do that we couldn't do before? > > See above. > > > 4. If we just insert our current diskpacks into the new system, will it > > just boot and work? Or what do we need to before/after booting to > > prepare/respond to the new system? > > Any V6 disk pack can be read/mounted on any V6 machine. Any binaries (the OS, > or user commands) for the -11/40 will run on the -/45. (Which is why the V6 > dist includes binaries for /40 versions of the OS only.) > > To make use of the /45, you need a different copy of the OS binary, built from > a slightly different set of modules. (Replace m40.s with m45.s; and you will > need to re-asssemble l.s, prepending it with data.s.) Both variants can live > on the same pack, under different filenames; select the right one at boot > time. Nice. Definitely a worthy project then. If the instructions in Setting up are as good for the 45 as they are for the 40, I should be able to bring one up relatively painlessly. This is one of those assumptions I was talking about - I knew that I could just add CPU=11/45 in my SIMH ini file and be running an 11/45, and separately, I knew that I could build 11/45 code in Unix v6. But, I didn't get  how this fit together. What it sounds like is that Unix was transitioning from non-I/D land to I/D land and maintaining a measure of backward compatibility not unlike Mac OS from PPC to Intel, or 32bit to 64bit? > > 5. Is 256K enough memory or what configuration do y'all recommend? > > 256KB is all you can have. Neither SIMH nor Ersatz-11 support the Able > ENABLE: > > http://gunkies.org/wiki/Able_ENABLE > > which is what you need to have more than 256KB on a UNIBUS -11. Fascinating. Definitely will keep this in mind and hurry the transition towards the 11/70. > > > > From: Clem Cole > > > You'll probably want to configure a kernel for the 45 class machine. > > Look at the differences in the *.s files in the kernel. > > More importantly, look at the 'run' file in /usr/sys, which has commented > out lines to build the OS image for /45-/70 class machines. Found it already! > > > But either way you should configure the system to use the largest drive > > v6 has. > > This is actually of limited utility, since a V6 file system is restricted to > 65K blocks _max_. So a disk with 350K blocks (like an RP06), you'll have to > split it into like 5 partitions to use it all. Yeah, Cole already mentioned this in a separate thread. I'll file it in the keep in mind drawer. > > > > From: Will Senn > > > Do you know of some commonly used at the time v6 programs that needed > > that much space? > > Heh. Spun up my v6, and did "file * | grep separate" in /bin and /usr/bin, > and then recalled that V6 was distributed in a form suitable for a /40. So, > null set. > > Did the same thing on /bin from the MIT V6+ system, and got: > > a68: separate I&D executable not stripped > a86: separate I&D executable not stripped > bteco: separate I&D executable not stripped > c86: separate I&D executable not stripped > e: separate I&D executable not stripped > emacs: separate I&D executable not stripped > lisp: separate I&D executable not stripped > mail: separate I&D executable not stripped > ndd: separate I&D executable not stripped > s: separate I&D executable not stripped > send: separate I&D executable not stripped > teco: separate I&D executable not stripped > > No idea what the difference is between 'teco' and 'bteco', what 's/send' do, > etc. This is really helpful. Is there a bootable tape of the MIT system extant? > > > Is there any material difference between doing it at install time vs > > having run on 11/40 for a while and moving the disk over to the 11/45 > > later? > > No; like I said, you can have two different OS binaries on the disk, and > select which one you boot. > > > On a related note, how difficult is it to copy the system from rk to > > hp? I know I can rebuild, but I'm sure there's a quicker/easier method... > > Build a system with both, and then copy the files? I'd use 'tar' (I have a V6 > tar, but it uses a modified OS with the smdate() call added back in) to do the > moving (which would retain the last-write dates); 'tp' or 'stp' would also > work. > > The hack _I_ used on simulated systems was to expand the file that held the > 'disk pack', mount it as a different kind of pack (RL or RP), and then go in > and hand-patch the disk size in the root block with 'db', then 'icheck -s' to > re-build the free list. Note: this won't give you more inodes, so you may run > out, but the usual inode allocation is pretty generous. Oh my, what's that you say about frigglewumping the carbathingamajig? :) > > Noel > > PS: Speaking of the last write dates, I have versions of mv/mvall, cp/cpall, > ln, chmod etc which retain them (using smdate()). If there's an actual > community of people using V6, I should upload all the stuff I have. Although > it might be good to establish some central location for exchange of V6 code. > However, I don't and won't (don't even ask) use GitHub or any similar modern > thing. This would be great. Right now, stuff is pretty much pell-mell and difficult to find, much less use. -- GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF