[TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Will Senn]

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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Clem cole]

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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Clem cole]

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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Will Senn]

> 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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Clem cole]

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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Will Senn]

> 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 :).

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Clem Cole]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[ron]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Clem Cole]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[ron]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Paul Winalski]

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.

[TUHS] Useful Unix tools + Usenix tapes

[Warren Toomey]

On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>    *** 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.

In the Unix Archive, there is this location:
https://www.tuhs.org/Archive/Tools/

It's separate from the distributions. Pro: it keeps the original files
separate from 3rd party things; con: it's a bit harder to find things
when you need them.

If anybody has other tools or useful utilities to add in here, let me know!

There are some Usenix tapes in the archive here:
https://www.tuhs.org/Archive/Applications/
Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
other tape images out there that I could add, let me know as well.

Happy New Year, everyone.
Cheers, Warren

Re: [TUHS] Useful Unix tools + Usenix tapes

[Clem cole]

Warren

I understand and thank you. That is surely a possible place to put things.  I was thinking something a little different.   The directory you have are more general tools that really apply across releases and specific targets.   

I was thinking when you have tools like the set I mentioned previously that are system specific and you probable want to supply target binaries that you try to keep them in a directory next the system that they  relate.     Thus in your Research directory - create a v6 specific contributed tool directory.  



Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Dec 31, 2018, at 6:36 PM, Warren Toomey <wkt@tuhs.org> wrote:
> 
>> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>>   *** 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.
> 
> In the Unix Archive, there is this location:
> https://www.tuhs.org/Archive/Tools/
> 
> It's separate from the distributions. Pro: it keeps the original files
> separate from 3rd party things; con: it's a bit harder to find things
> when you need them.
> 
> If anybody has other tools or useful utilities to add in here, let me know!
> 
> There are some Usenix tapes in the archive here:
> https://www.tuhs.org/Archive/Applications/
> Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
> other tape images out there that I could add, let me know as well.
> 
> Happy New Year, everyone.
> Cheers, Warren

Re: [TUHS] Useful Unix tools + Usenix tapes

[Clem cole]

Warren There are a number of usenix tapes missing in your archives.   The first three were called 1 2 and 3 from the mid 70s but where included in the Harvard tape*** from about 76 or 77 which I sort of consider the first usenix tape.  Note that This is an stp format distribution.     Which IIRC the v6 tp could read or at least read it enough to pull the stp binary off the tape which would then allow you read the whole thing.      You will need the v6 ar because the directories inside the tape were archived as files called cont.a   And I think I remember that some of those were compressed with pack/unpack tools which were in the wild in those days — probably also on the Harvard tape.    As I mentioned the other day the 1BSD tape you have seems to be a conversion from stp to tar.   

FYI:  one of the issues with tp and stp is that the directory for the tape is at the beginning of the tape itself and is fixed in size [this is have DECtape worked].  Because it was fixed in size folks archived directories together so the tp directory needed only the folder and a single file it.   FWIW One of the big enhancements tar provided over tp was the threading the directory throughout the archive which eliminated tat issue, but of course if there is a tape error recovery is more difficult.  IIRC Harvard had added a second directory to the end of tp in the stp format to help reliability.  Ie if you had errors in the tp directory at the front of the tape, you had a chance to recover by using the second copy of it.   


*** the Harvard tape takes it name from the meeting at Harvard of the Unix News readers.  This would become USENIX as an org shortly there after.   The earlier tapes (1 2 and 3) were what files had been collected at earlier meetings. 

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Dec 31, 2018, at 6:36 PM, Warren Toomey <wkt@tuhs.org> wrote:
> 
>> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>>   *** 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.
> 
> In the Unix Archive, there is this location:
> https://www.tuhs.org/Archive/Tools/
> 
> It's separate from the distributions. Pro: it keeps the original files
> separate from 3rd party things; con: it's a bit harder to find things
> when you need them.
> 
> If anybody has other tools or useful utilities to add in here, let me know!
> 
> There are some Usenix tapes in the archive here:
> https://www.tuhs.org/Archive/Applications/
> Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
> other tape images out there that I could add, let me know as well.
> 
> Happy New Year, everyone.
> Cheers, Warren

Re: [TUHS] Useful Unix tools + Usenix tapes

[Clem cole]

Sounds great.  Thanks.  

Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 

> On Dec 31, 2018, at 8:58 PM, Clem cole <clemc@ccc.com> wrote:
> 
> Warren There are a number of usenix tapes missing in your archives.   The first three were called 1 2 and 3 from the mid 70s but where included in the Harvard tape*** from about 76 or 77 which I sort of consider the first usenix tape.  Note that This is an stp format distribution.     Which IIRC the v6 tp could read or at least read it enough to pull the stp binary off the tape which would then allow you read the whole thing.      You will need the v6 ar because the directories inside the tape were archived as files called cont.a   And I think I remember that some of those were compressed with pack/unpack tools which were in the wild in those days — probably also on the Harvard tape.    As I mentioned the other day the 1BSD tape you have seems to be a conversion from stp to tar.   
> 
> FYI:  one of the issues with tp and stp is that the directory for the tape is at the beginning of the tape itself and is fixed in size [this is have DECtape worked].  Because it was fixed in size folks archived directories together so the tp directory needed only the folder and a single file it.   FWIW One of the big enhancements tar provided over tp was the threading the directory throughout the archive which eliminated tat issue, but of course if there is a tape error recovery is more difficult.  IIRC Harvard had added a second directory to the end of tp in the stp format to help reliability.  Ie if you had errors in the tp directory at the front of the tape, you had a chance to recover by using the second copy of it.   
> 
> 
> *** the Harvard tape takes it name from the meeting at Harvard of the Unix News readers.  This would become USENIX as an org shortly there after.   The earlier tapes (1 2 and 3) were what files had been collected at earlier meetings. 
> 
> Sent from my PDP-7 Running UNIX V0 expect things to be almost but not quite. 
> 
>>> On Dec 31, 2018, at 6:36 PM, Warren Toomey <wkt@tuhs.org> wrote:
>>> 
>>> On Mon, Dec 31, 2018 at 09:55:31AM -0500, Clem Cole wrote:
>>>  *** 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.
>> 
>> In the Unix Archive, there is this location:
>> https://www.tuhs.org/Archive/Tools/
>> 
>> It's separate from the distributions. Pro: it keeps the original files
>> separate from 3rd party things; con: it's a bit harder to find things
>> when you need them.
>> 
>> If anybody has other tools or useful utilities to add in here, let me know!
>> 
>> There are some Usenix tapes in the archive here:
>> https://www.tuhs.org/Archive/Applications/
>> Look in Shoppa_Tapes, Spencer_Tapes and Spencer_Tapes. If there are
>> other tape images out there that I could add, let me know as well.
>> 
>> Happy New Year, everyone.
>> Cheers, Warren

Re: [TUHS] Useful Unix tools + Usenix tapes

[Nigel Williams]

Regarding these aggregates (tapes, zips, tars etc) can we consider the
option please of having them unpacked into their tree structure so a
search-engine can index the content?

Re: [TUHS] Useful Unix tools + Usenix tapes

[Warren Toomey]

On Tue, Jan 01, 2019 at 01:08:19PM +1100, Nigel Williams wrote:
> Regarding these aggregates (tapes, zips, tars etc) can we consider the
> option please of having them unpacked into their tree structure so a
> search-engine can index the content?

Argh! I'm mindful of the disk space on my system and also on the
mirrors.

How about I write a script that unpacks and builds a table of contents
list for all the tarball and Zip files in the archive. It would run
regularly and leave a text file in the Archive root.

Cheers, Warren

Re: [TUHS] Useful Unix tools + Usenix tapes

[Warren Toomey]

On Tue, Jan 01, 2019 at 12:17:29PM +1000, Warren Toomey wrote:
> How about I write a script that unpacks and builds a table of contents
> list for all the tarball and Zip files in the archive. It would run
> regularly and leave a text file in the Archive root.

Done. It seems to work, but let me know if there are small issues.
The file is generated daily and is at:
https://www.tuhs.org/Archive/tarball_tocs.txt.gz
 
Cheers, Warren

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Eric Allman]

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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Warner Losh]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Noel Chiappa]

    > 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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Noel Chiappa]

    > 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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Clem Cole]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Warner Losh]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Clem Cole]

[-- 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 --]

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Will Senn]

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

Re: [TUHS] Upgrading from 11/40 to 11/45 in Unix v6

[Noel Chiappa]

    > 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.