Dear Unix Enthusiasts, We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a PDP 11/45 (preferably another SIMH) for our Unix v6 installation. Our CEO was traveling and met a techie in first class (seriously, first class?) who told him that we needed one. I thought I had better ask some folks who have gone before about it before we jumped on the bandwagon. By way of background, Our install is pretty small with a few rk’s and 256K of ram along with a few standard peripherals, and some stuff our oldtimers refuse to part with (papertape, card punch, etc). It has fairly low utilization - a developer logs in and writes code every few days and the oldtimers hunt the wumpus and play this weird Brit game about cows. It could be considered a casual development and test environment and an occasional gaming console. Here is what I would like to know that I think y’all might be particularly equipped to answer: 1. Are there any v6 specific concerns about upgrading? 2. Why should we consider taking the leap to the 11/45? Everything seems to work fine now. 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? 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? 5. Is 256K enough memory or what configuration do y’all recommend? 6. Is there anything else we need to know about? Regards, Will Sent from my iPhone
The primary difference between the 11/40 class and 11/45 class is separate I/D space which I sometimes refer to as the 17th address bit because it allows you a full 64k of data space as well as a 64k of instructions space.
After you are booted, a 45 class machine will run 40 class binaries unchanged. 40 class machines can not run a.outs that are seperate I/D
You’ll probably want to configure a kernel for the 45 class machine. Look at the differences in the *.s files in the kernel. IIRC there is a different file for 40 class and 45 class systems
That said if you running the simh I would recommend going all the way to an 11/70 configuration because you can set it up for 4M of main memory.
Clem
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Dec 30, 2018, at 9:25 PM, Will Senn <will.senn@gmail.com> wrote:
>
> Dear Unix Enthusiasts,
>
> We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a PDP 11/45 (preferably another SIMH) for our Unix v6 installation. Our CEO was traveling and met a techie in first class (seriously, first class?) who told him that we needed one. I thought I had better ask some folks who have gone before about it before we jumped on the bandwagon. By way of background, Our install is pretty small with a few rk’s and 256K of ram along with a few standard peripherals, and some stuff our oldtimers refuse to part with (papertape, card punch, etc). It has fairly low utilization - a developer logs in and writes code every few days and the oldtimers hunt the wumpus and play this weird Brit game about cows. It could be considered a casual development and test environment and an occasional gaming console.
>
> Here is what I would like to know that I think y’all might be particularly equipped to answer:
>
> 1. Are there any v6 specific concerns about upgrading?
>
> 2. Why should we consider taking the leap to the 11/45? Everything seems to work fine now.
>
> 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?
>
> 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?
>
> 5. Is 256K enough memory or what configuration do y’all recommend?
>
> 6. Is there anything else we need to know about?
>
> Regards,
>
> Will
>
> Sent from my iPhone
One other thought. The basic v6 has and RP driver in it. I’ve forgotten if RP06 was in there but the RP04 certainly was by then. Check the driver rp.c to see what is configured. But either way you should configure the system to use the largest drive v6 has.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Dec 30, 2018, at 9:25 PM, Will Senn <will.senn@gmail.com> wrote:
>
> Dear Unix Enthusiasts,
>
> We are seriously considering upgrading our PDP 11/40 clone (SIMH), to a PDP 11/45 (preferably another SIMH) for our Unix v6 installation. Our CEO was traveling and met a techie in first class (seriously, first class?) who told him that we needed one. I thought I had better ask some folks who have gone before about it before we jumped on the bandwagon. By way of background, Our install is pretty small with a few rk’s and 256K of ram along with a few standard peripherals, and some stuff our oldtimers refuse to part with (papertape, card punch, etc). It has fairly low utilization - a developer logs in and writes code every few days and the oldtimers hunt the wumpus and play this weird Brit game about cows. It could be considered a casual development and test environment and an occasional gaming console.
>
> Here is what I would like to know that I think y’all might be particularly equipped to answer:
>
> 1. Are there any v6 specific concerns about upgrading?
>
> 2. Why should we consider taking the leap to the 11/45? Everything seems to work fine now.
>
> 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?
>
> 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?
>
> 5. Is 256K enough memory or what configuration do y’all recommend?
>
> 6. Is there anything else we need to know about?
>
> Regards,
>
> Will
>
> Sent from my iPhone
> On Dec 30, 2018, at 8:47 PM, Clem cole <clemc@ccc.com> wrote:
>
> One other thought. The basic v6 has and RP driver in it. I’ve forgotten if RP06 was in there but the RP04 certainly was by then. Check the driver rp.c to see what is configured. But either way you should configure the system to use the largest drive v6 has.
>
It looks like hp.c is an rp04 driver. That’s an easy upgrade... pretty sure I saw an rp04 laying around somewhere :) I’ll do that one tonight.
Thanks,
Will
Right. hp.c. - RH controller.
Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite.
> On Dec 30, 2018, at 10:08 PM, Will Senn <will.senn@gmail.com> wrote:
>
>
>
>> On Dec 30, 2018, at 8:47 PM, Clem cole <clemc@ccc.com> wrote:
>>
>> One other thought. The basic v6 has and RP driver in it. I’ve forgotten if RP06 was in there but the RP04 certainly was by then. Check the driver rp.c to see what is configured. But either way you should configure the system to use the largest drive v6 has.
>>
>
> It looks like hp.c is an rp04 driver. That’s an easy upgrade... pretty sure I saw an rp04 laying around somewhere :) I’ll do that one tonight.
>
>
> Thanks,
>
> Will
> On Dec 30, 2018, at 8:43 PM, Clem cole <clemc@ccc.com> wrote: > > The primary difference between the 11/40 class and 11/45 class is separate I/D space which I sometimes refer to as the 17th address bit because it allows you a full 64k of data space as well as a 64k of instructions space. > Do you know of some commonly used at the time v6 programs that needed that much space? > After you are booted, a 45 class machine will run 40 class binaries unchanged. 40 class machines can not run a.outs that are seperate I/D. Good to know. > You’ll probably want to configure a kernel for the 45 class machine. Look at the differences in the *.s files in the kernel. IIRC there is a different file for 40 class and 45 class systems I read about this in ’Setting up Unix Sixth Edition” and I see the source comments. It looks pretty straightforward to configure the system for separate I/D. 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? 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... > That said if you running the simh I would recommend going all the way to an 11/70 configuration because you can set it up for 4M of main memory. Maybe this will be the next upgrade :).
> 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.' :-) > for our Unix v6 installation. Why on earth would an organization have such a thing? :-) > 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?! 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. > 2. Why should we consider taking the leap to the 11/45? Everything > seems to work fine now. You're asking _us_? 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. > 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. > 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. > 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. > 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. > 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. > 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. 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.
[-- Attachment #1: Type: text/plain, Size: 2684 bytes --] On Sun, Dec 30, 2018 at 10:31 PM Will Senn <will.senn@gmail.com> wrote: > > Do you know of some commonly used at the time v6 programs that needed that > much space? > Besides everything that Noel pointed to you too, look at 1BSD - the pascal system needs to be seperate I/D for sure. I believe ex is linked seperate I/D. The C compiler itself can be, the reason to do that it allow the tables to be larger, so you don't run into errors where you run out of space. My experience from the old days, was that once you had seperate I/D, we tended to link most programs that way if we could, as we slowly deprecated the 11/40 class systems. The original Tek Labs machine was an 11/60 (which is a 40 class), and was quickly replaced with an 11/70. The 60 is what I used for the original Able Enable work that Noel referenced, so it have 4M in it for a short period (we borrowed the memory for the development). But within 2 years we had a 11/44 to replace the 11/60, which was seperate I/D system. > > > > After you are booted, a 45 class machine will run 40 class binaries > unchanged. 40 class machines can not run a.outs that are seperate I/D. > > Good to know. > > I read about this in ’Setting up Unix Sixth Edition” and I see the source > comments. It looks pretty straightforward to configure the system for > separate I/D. 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? > Making a system work on both could be done, but it chews up precious address space in code that will not be executed. Remember - what seems 'natural' for the modern user of cramming everything into a single binary, or keeping lots of copies of things, was not done. You lack address space, main memory or disk space. > > 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... > Easiest method is probably grabing the v6tar binary that you described how to make in your v6 for sim6 directionions, then use and dual tar programs***. Other wise, find(1) is your friend. That said, PWD (1.0) was v6 based, so there is a version of cpio on the spencer_pwb.tar.gz tape. That should work. Clem *** Note to Warren. It might be a wise to put copies of v6tar (both seperate I/D and not) binaries and maybe cpio(v6) on the TUHS we site in the V6 directory; maybe, a 'collected_tools' directory. Noel's tools would probably make sense to add there also. I bet people that are downloading and playing might find them helpful. [-- Attachment #2: Type: text/html, Size: 4510 bytes --]
[-- Attachment #1: Type: text/plain, Size: 249 bytes --] Yep, and notwithstanding split I/D, we switched to -n (410 magic) read-only code space. Of course, the kludge nargs() function didn’t work at all in split-I/D mode unless you made a hack to the processor to change the behavior of MFPI. [-- Attachment #2: Type: text/html, Size: 2204 bytes --]
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
[-- Attachment #1: Type: text/plain, Size: 863 bytes --] On Mon, Dec 31, 2018 at 2:20 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote: > > Speaking of the last write dates, I have versions of mv/mvall, cp/cpall, > ln, chmod etc which retain them (using smdate()). Yup - thanks, I snarfed the stuff on gunkies that you had a while back. > If there's an actual community of people using V6, I should upload all > the stuff I have. Of course we all should ;-) > Although it might be good to establish some central location for exchange > of V6 code. I think that if Warren added a 'collected tools' directory next to each of distributions, that would work and I think would make the most sense. As I said, elsewhere your stuff, v6tar, cpio, stp and a smattering of offerings from the old usenix tapes, plus maybe a couple of from 1BSD such as ex might be appropriate. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 2368 bytes --]
[-- Attachment #1: Type: text/plain, Size: 967 bytes --] On Mon, Dec 31, 2018 at 8:51 AM Clem Cole <clemc@ccc.com> wrote: > > > On Mon, Dec 31, 2018 at 2:20 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> > wrote: > >> >> Speaking of the last write dates, I have versions of mv/mvall, cp/cpall, >> ln, chmod etc which retain them (using smdate()). > > Yup - thanks, I snarfed the stuff on gunkies that you had a while back. > > > >> If there's an actual community of people using V6, I should upload all >> the stuff I have. > > Of course we all should ;-) > > > > >> Although it might be good to establish some central location for >> exchange of V6 code. > > I think that if Warren added a 'collected tools' directory next to each of > distributions, that would work and I think would make the most sense. As > I said, elsewhere your stuff, v6tar, cpio, stp and a smattering of > offerings from the old usenix tapes, plus maybe a couple of from 1BSD such > as ex might be appropriate. > Are the usenix tapes online? Warner [-- Attachment #2: Type: text/html, Size: 2360 bytes --]
[-- Attachment #1: Type: text/plain, Size: 650 bytes --] On Mon, Dec 31, 2018 at 10:05 AM <ron@ronnatalie.com> wrote: > Yep, and notwithstanding split I/D, we switched to -n (410 magic) > read-only code space. > Agreed, that was pretty standard and used the sticky bit as needed. IIRC this was to help sharing, but I admit those bits in my brain had not been refreshed in years. > Of course, the kludge nargs() function didn’t work at all in split-I/D > mode unless you made a hack to the processor to change the behavior of MFPI. > Ah yes, I've forgotten that hack. Does simh or any of the other simulators support it? It would need to be an option of course. > > ᐧ [-- Attachment #2: Type: text/html, Size: 2190 bytes --]
[-- Attachment #1: Type: text/plain, Size: 344 bytes --] On Mon, Dec 31, 2018 at 10:53 AM Warner Losh <imp@bsdimp.com> wrote: > > Are the usenix tapes online? > I know some of them are (google/duck-duck-go are your friends), but I do not know of one place. When I was USENIX President, I tried to get them added to the archives. It might be worth making another go at that. Clem ᐧ [-- Attachment #2: Type: text/html, Size: 1267 bytes --]
> From: Will Senn > Thanks for not dismissing the thread as frivolity. Hey, anyone wanting to do things with V6 I take seriously! :-) > I'm sure y'all have seen Mills's winning Best in Show IOCCC entry: > https://www.ioccc.org/2018/mills/hint.html Yes, that was pretty awesome. > Fantastic, I'm prolly gonna try it. OK; if you want to know what it's doing (somehow I figured you probably didn't just want to simply follow the instructions :-) that is different from the /40 (it's quite different, and somewhat complicated), I just wrote this: http://gunkies.org/wiki/Unix_V6_kernel_memory_layout to explain it a bit. Currently, one has to read the source to 'sysfix', and also m45.s, to understand how the /45 version works; that new page is a little crude still, but it hopefully explains the big picture. > 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. I just took a look at "Setting up UNIX - Sixth Edition", and it doesn't really say much about the /45; it basically just says 'the /45 is wiered inside' and 'look at sys/run'. It is certainly true that that does cover all one needs to bring V6 up on the /45, but... The coverage of what to do if your '45' has hardware floating point is pretty complete, though. > 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 That's pretty accurate. One main advantage of the /45 is that it could have a lot more disk buffers, but I'm not sure that makes much difference for emulation. If you have some application that won't fit well in 64KB, that's big, but that's a user-land difference, not the OS. > Is there a bootable tape of the MIT system extant? Not yet, sorry. I do have a complete dump, but it i) includes all the users' personal files, and ii) is not well organized. It's on my to-do list. Noel
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --] Yeah, ISVTX only worked on 410 and 411 files. It locked the text segment in swap. It kind of got obsoleted by later versions that could load stuff direct to memory from the disk image. From: Clem Cole <clemc@ccc.com> Sent: Monday, December 31, 2018 10:54 AM To: Ronald Natalie <ron@ronnatalie.com> Cc: Will Senn <will.senn@gmail.com>; The Eunuchs Hysterical Society <tuhs@tuhs.org> Subject: Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6 On Mon, Dec 31, 2018 at 10:05 AM <ron@ronnatalie.com <mailto:ron@ronnatalie.com> > wrote: Yep, and notwithstanding split I/D, we switched to -n (410 magic) read-only code space. Agreed, that was pretty standard and used the sticky bit as needed. IIRC this was to help sharing, but I admit those bits in my brain had not been refreshed in years. Of course, the kludge nargs() function didn’t work at all in split-I/D mode unless you made a hack to the processor to change the behavior of MFPI. Ah yes, I've forgotten that hack. Does simh or any of the other simulators support it? It would need to be an option of course. <https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=0488a3b9-8b85-4fae-afd5-ff3bcec06dd4> ᐧ [-- Attachment #2: Type: text/html, Size: 5370 bytes --]
On 12/31/18, ron@ronnatalie.com <ron@ronnatalie.com> wrote:
> Yeah, ISVTX only worked on 410 and 411 files. It locked the text segment
> in swap. It kind of got obsoleted by later versions that could load stuff
> direct to memory from the disk image.
>
a.out magic number 0410 is OMAGIC (separate read-only instruction and
data segments). 0413 is ZMAGIC (demand-paged executable). What is
magic number 0411? That one I've never heard of before.
-Paul W.
> From: Paul Winalski > What is magic number 0411? That one I've never heard of before. It's a PDP-11-ism. Separate I+D. Noel
[-- Attachment #1: Type: text/plain, Size: 464 bytes --] On Mon, Dec 31, 2018, 1:38 PM Noel Chiappa <jnc@mercury.lcs.mit.edu wrote: > > From: Paul Winalski > > > What is magic number 0411? That one I've never heard of before. > > It's a PDP-11-ism. Separate I+D. > Venix/86, a v7 sys iii hybrid that ran on 8086/286 also uses it for basically the same thing... its compiler was limited to one 64k code segment and one 64k data / stack segment. The syscall interface depends on this quirk as well... Warner > [-- Attachment #2: Type: text/html, Size: 1015 bytes --]
On 2018-12-30 10:51 PM, Noel Chiappa wrote: > > From: Will Senn > > > Do you know of some commonly used at the time v6 programs that needed > > that much space? The base system probably didn't have any separated I/D space programs for reasons that have already been discussed. But users definitely did. For example, the INGRES database system at Berkeley required separated I/D space (and even then ran in multiple processes). Tom Ferrin at UCSF Computer Graphics Lab needed it as well. Speaking of Tom and the 11/45, there was a quirk in the MFPI (Move From Previous Instruction Space) instruction that broke the nargs() function, which was pretty heavily used at the time. Tom gave an amazing presentation at USENIX in San Francisco where he fixed the problem by cutting a trace on one of the circuit boards. It's described here: https://www.cgl.ucsf.edu/home/tef/pubs/mfpi.pdf. If you're using nargs() then there might be a reason to stick with the 11/40, assuming your implementation doesn't have the Ferrin Fix. eric