Induce CHAOS

[larsbrinkhoff]

@eswenson1 wrote:

What do you want to do about the Chaosnet support (KLH10 support Chaosnet over UDP)? This would allow multiple ITS systems to be connected using the Chaosnet.

I want it supported, of course!

I think we should add @bictorv's CHAOS patches to the KLH10 at http://github.com/PDP-10/klh10.

CC @Rhialto

[larsbrinkhoff]

(Parenthetical: (There's also the option to "modernize" ITS networking programs to use TCP/IP instead of CHAOSnet.) Oops, did I really say that?)

[bictorv]

(But that wouldn't be very incompatible, would it? :-) There is also the option to develop Chaos for Linux/etc?) I'm certainly for adding the CH11 stuff here, but I don't have the time until much much later (like summer).

[larsbrinkhoff]

Sure, I had in mind to do it myself.

[eswenson1]

As far as I know Bjorn has pretty good instructions for doing this on his web site. We should be able to follow those.

[ams]

There is the option of hooking doing Chaosnet to TCP/IP. How well that ever worked, I do not know. Brad Parkers MIT CADR simulator includes a user-space chaosnet hack that might be worth looking into.

[eswenson1]

Doesn't Björn Victor have a Chaosnet over UDP implementation for KLH10? I believe it allows two or more ITS systems on the internet to use Chaosnet to talk to one another.

[ams]

@bictorv can probobly elaborate on that. :-)

[larsbrinkhoff]

He does, and he has suggested creating a network of ITS machines.

[bictorv]

The Chaos variants should be better documented. My Chaos-over-UDP introduces a new protocol which essentially just wraps a Chaos packet in a UDP header, and sends it using configured mappings between Chaos and IP addresses. We had a network with, I think, four ITS hosts at one point (mine, Craig Lennox, and possibly Paul Svensson?). Brads Chaos-over-unix-sockets is for communicating between the CADR emulator and unix "servers" such as FILE, TIME etc, but only point-to-point I think. There is also Chaos-over-Ethernet which is a standard, used e.g. by more modern Lisp machines (original Chaosnet was 2 Mb/s). I once set up a bridge program between the three, so ITS could communicate with both the CADR emulator and a real Symbolics machine. Great fun!

For ITS, I would propose my Chaos-over-UDP using CH11. CH11 could of course be extended to use the other variants above, but with more work. See http://its.victor.se/wiki/ch11 for more info about CH11.

UP is running CH11, so if you have a machine you want to join, let me know!

[larsbrinkhoff]

That bridge program sounds interesting.

[larsbrinkhoff]

See PDP-10/klh10#16.

[larsbrinkhoff]

Dave Conroy has written tools using raw sockets to send and receive Chaosnet packets encapsulated in IP packets with protocol type 16. I believe that's a fourth variant?

[bictorv]

Ah, yes! Have you found the code? Or the spec?

[larsbrinkhoff]

No, but he has stated he intends to release the code at some points.

[bictorv]

The encapsulation spec is probably simple, and would make it easy to incorporate in the CH11 device (although you would need root to run it).

[larsbrinkhoff]

@jaoswald wrote about Chaosnet-over-Ethernet as used with Symbolics Lisp machines:
http://jaoswald.blogspot.se/p/chaosnet-information.html

[bictorv]

Yes, that's what my bridge program (between chaos-over-udp and the Symbolics 3600) used. It's perfectly straight-forward.

[larsbrinkhoff]

Making progress on using Chaosnet:

• [x] Update KLH10
• [x] Add ATSIGN CHAOS
• [x] Update SYSTEM; CONFIG >
• [x] Add DB to MLDEV
• [ ] Add other hosts to MLDEV
• [ ] Update ATSIGN DEVICE
• [ ] Update FTPS
• [ ] More?

[larsbrinkhoff]

Maybe even TOPS-20 could be updated with Chaosnet support:
https://github.com/PDP-10/FOONEX/search?q=chaos

[b4]

There is a TOPS-20 CHAOSNET implementation buried in SRI-NIC's SRC: dump (wow, do I really have its contents memorised?!)

I believe it was under SRC:

[b4]

Yep - https://github.com/PDP-10/sri-nic/blob/master/files/src/mit/monitor/chaos.mac

[larsbrinkhoff]

Made by @MMcM and @jtw43, among others.

So there's a CHAOS.MAC from Symbolics' Foonly, and CHAOS.MAC, OLDCHAOS.MAC, and NEW-CHAOS.MAC from SRI-NIC. They all seem to share lots of code.

In addition, the Foonly has CHABUG.MAC, CHAOS0.MAC, and CHATTY.MAC.

[b4]

Should consult SAILDART to see if WAITS had it too ;)

Sent from my iPhone

On Feb 19, 2017, at 23:57, Lars Brinkhoff notifications@github.com wrote:

Made by @MMcM and @jtw43, among others.

So there's a CHAOS.MAC from Symbolics' Foonly, and CHAOS.MAC, OLDCHAOS.MAC, and NEW-CHAOS.MAC from SRI-NIC. They all seem to share lots of code.

In addition, the Foonly has CHABUG.MAC, CHAOS0.MAC, and CHATTY.MAC.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[larsbrinkhoff]

I see in an old host table that there were Chaosnet for

• Macintosh
• PDP-11: Unix, MINITS, MOS
• MSDOS
• SunOS
• VAX: Unix, VMS
• Multics

Bascially, everything at MIT.

[ams]

Do not forget Lisp Machines (MIT, LMI, Symbolics, and TI).

[larsbrinkhoff]

I didn't forget, it's just too obvious to mention. :-)

[ams]

For the record, I have a early MIT Chaosnet for Unix implementation.

[b4]

Maybe it's time to mention that someone (not me, though!) did have the monitor starting (and crashing) in an emulator so it's doable.

I can upload the PLC config file if anyone can decipher it.

Sent from my iPhone

On Feb 20, 2017, at 00:55, Lars Brinkhoff notifications@github.com wrote:

I didn't forget, it's just too obvious to mention. :-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[larsbrinkhoff]

@ams I do want to include Lispms in the Chaos network. I seem to recall the physical machines do Chaos over Ethernet, so that would be local networks only?

Brad's emulator uses unix sockets, so that's even less accessible from internet.

I think @bictorv's UDP tunnel is unique to KLH10, so it's ITS only for now. His bridge would be very useful, though.

Dave Conroy's PDP-10/X does Chaos over IP, but he may be alone in doing that.

[ams]

Physical machines used a real Chaos card, and could do Chaos just like PDP-10. (Some had a Ethernet card, and where capable of TCP/IP.) The work has to be done in one of the simulators, they are generally using sockets for the communication -- so one (@ams?) would have make it talk properly. Alas, I'm mostly working on the HDL version of the MIT CADR right now.

[ams]

But I am sure we could re-use @bictorv UDP stuff from KLH10.

[larsbrinkhoff]

Hey @eswenson1, do you have Multics set up for Chaosnet? Or TCP/IP for that matter?

[eswenson1]

@larsbrinkhoff Unfortunately, no networking software for Multics can be found. Only kermit and IMFT transfers in and out of Multics. Hoping someone can find some tapes of TCP/IP stack.

[larsbrinkhoff]

Is this a complete list of Chaosnet transport mechanisms?

• Real Chaos hardware
• Ethernet type 0804 frames
• IP protocol 16 packets (maybe used by David Conroy?)
• @bictorv's UDP encapsulation
• @lisper's Unix sockets

Supporting protocols:

• ARP: hardware type 5
• DNS: class CH

[larsbrinkhoff]

@eswenson1 How about this? http://mailman.trailing-edge.com/pipermail/simh/2016-February/015052.html

To do something useful you need a host that emulates the RFC1822 interface and talks to one of the IMPs. Not too long ago Charles Anthony did that for the DPS8 and Multics, and I believe he actually got that working.

[eswenson1]

Yes, Charles got the IMP interface working — unfortunately, there is no Multics software stack source code available for code that uses the IMP. Actually, that is not completely true — there is some — just not a complete stack. I worked on getting the higher level software that uses NCP/IMP compiled and integrated but found too much of the underpinings that talked to the IMP (ABSI interface) missing. We abandoned the approach because we know of the existence (no source located yet) for the TCP/IP implementation that was user-ring (rather than ring-0). There are tapes available (we think) but no one has dared try to read them for fear of destroying them. Olin Sibert is the keeper of said tapes and we think the TCP/IP software may be on them.

Honeywell had the TCP/IP software as a “separately priced product”. And when Bull placed the Multics sources in the public domain, it didn’t include the TCP/IP stack. — Eric

On Feb 21, 2017, at 02:58, Lars Brinkhoff notifications@github.com wrote:

@eswenson1 https://github.com/eswenson1 How about this? http://mailman.trailing-edge.com/pipermail/simh/2016-February/015052.html http://mailman.trailing-edge.com/pipermail/simh/2016-February/015052.html To do something useful you need a host that emulates the RFC1822 interface and talks to one of the IMPs. Not too long ago Charles Anthony did that for the DPS8 and Multics, and I believe he actually got that working.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/17#issuecomment-281311034, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0-Yww5sc14ZqFZD3ORgxCr2Ivgz41Jks5resNvgaJpZM4K7Wdo.

[b4]

Get the tapes to Al Kossow at the CHM to read 'em.

[eswenson1]

Olin is worried that they will be ruined in the process. He’s aware (and has been in discussions with) Al Kossow and the CHM. I’ll ping Olin about it again to see where he is at. — Eric

On Feb 21, 2017, at 18:06, gewt notifications@github.com wrote:

Get the tapes to Al Kossow at the CHM to read 'em.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/17#issuecomment-281545415, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0-Y6Va7zkb4Bcjaiypp8ctz6VmKCPlks5re5gNgaJpZM4K7Wdo.

[lisper]

On 2/21/17 8:31 PM, Eric Swenson wrote:

Yes, Charles got the IMP interface working — unfortunately, there is no Multics software stack source code available for code that uses the IMP. Actually, that is not completely true — there is some — just not a complete stack. I worked on getting the higher level software that uses NCP/IMP compiled and integrated but found too much of the underpinings that talked to the IMP (ABSI interface) missing. We abandoned the approach because we know of the existence (no source located yet) for the TCP/IP implementation that was user-ring (rather than ring-0). There are tapes available (we think) but no one has dared try to read them for fear of destroying them. Olin Sibert is the keeper of said tapes and we think the TCP/IP software may be on them.

Honeywell had the TCP/IP software as a “separately priced product”. And when Bull placed the Multics sources in the public domain, it didn’t include the TCP/IP stack. — Eric urg. it's late. I should not be replying. but I have some BBN tapes.
I read them. and gave the images back. I could swear they had early tcp/ip. but multics. wow. that would be pl/1. which I would recognize. They didn't I have that. everything I saw was unix+. It was all C code. 8 bit ascii.

having said too much, if someone had 9-track tapes, I could warm them. slowly. and remove the moisture and attempt a read them. I know how to do that. It depends on the vintage of the tape and who made it. Some tapes read well - others, not so well.

I have never seen multics source on 1/2" tape. I'm (humbly) going to guess that pre-dates 9-track. I showed up on the 9-track scene around

1977. Lol. Most of my MIT friends were in diapers. I'm not a 7-track guy. That's before my time.

-brad

[eswenson1]

Multics tapes are 9-track.

-- Eric

On Feb 21, 2017, at 18:56, Brad Parker notifications@github.com wrote:

On 2/21/17 8:31 PM, Eric Swenson wrote:

Yes, Charles got the IMP interface working — unfortunately, there is no Multics software stack source code available for code that uses the IMP. Actually, that is not completely true — there is some — just not a complete stack. I worked on getting the higher level software that uses NCP/IMP compiled and integrated but found too much of the underpinings that talked to the IMP (ABSI interface) missing. We abandoned the approach because we know of the existence (no source located yet) for the TCP/IP implementation that was user-ring (rather than ring-0). There are tapes available (we think) but no one has dared try to read them for fear of destroying them. Olin Sibert is the keeper of said tapes and we think the TCP/IP software may be on them.

Honeywell had the TCP/IP software as a “separately priced product”. And when Bull placed the Multics sources in the public domain, it didn’t include the TCP/IP stack. — Eric urg. it's late. I should not be replying. but I have some BBN tapes. I read them. and gave the images back. I could swear they had early tcp/ip. but multics. wow. that would be pl/1. which I would recognize. They didn't I have that. everything I saw was unix+. It was all C code. 8 bit ascii.

having said too much, if someone had 9-track tapes, I could warm them. slowly. and remove the moisture and attempt a read them. I know how to do that. It depends on the vintage of the tape and who made it. Some tapes read well - others, not so well.

I have never seen multics source on 1/2" tape. I'm (humbly) going to guess that pre-dates 9-track. I showed up on the 9-track scene around

1977. Lol. Most of my MIT friends were in diapers. I'm not a 7-track guy. That's before my time.

-brad

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[b4]

On Tue, Feb 21, 2017, at 18:56, Brad Parker wrote:

On 2/21/17 8:31 PM, Eric Swenson wrote:

Yes, Charles got the IMP interface working — unfortunately, there is no Multics software stack source code available for code that uses the IMP. Actually, that is not completely true — there is some — just not a complete stack. I worked on getting the higher level software that uses NCP/IMP compiled and integrated but found too much of the

underpinings that talked to the IMP (ABSI interface) missing. We

abandoned the approach because we know of the existence (no source located yet) for the TCP/IP implementation that was user-ring (rather than ring-0). There are tapes available (we think) but no one has dared try to read them for fear of destroying them. Olin Sibert is the keeper of said tapes and we think the TCP/IP software may be on them.

Honeywell had the TCP/IP software as a “separately priced product”. And when Bull placed the Multics sources in the public domain, it didn’t include the TCP/IP stack. — Eric

urg. it's late. I should not be replying. but I have some BBN tapes. I read them. and gave the images back.

I could swear they had early tcp/ip. but multics. wow. that would be pl/1. which I would recognize. They didn't I have that. everything I saw was unix+. It was all C code. 8 bit ascii.

having said too much, if someone had 9-track tapes, I could warm them. slowly. and remove the moisture and attempt a read them. I know how to do that. It depends on the vintage of the tape and who made it. Some tapes read well - others, not so well.

I have never seen multics source on 1/2" tape. I'm (humbly) going to guess that pre-dates 9-track. I showed up on the 9-track scene around

1977. Lol. Most of my MIT friends were in diapers. I'm not a 7-track guy. That's before my time.

      -brad

— You are receiving this because you commented. Reply to this email directly, view it on GitHub[1], or mute the thread[2].

Do you still have the images? I'm collecting ... well, everything. ;)

--

Cory Smelosky

b4@gewt.net

Links:

1. https://github.com/PDP-10/its/issues/17#issuecomment-281553725
2. https://github.com/notifications/unsubscribe-auth/AACsnAZf2XCVVn1WT79_xfn_NVf7jUt9ks5re6PYgaJpZM4K7Wdo

[lisper]

On 2/21/17 9:59 PM, Eric Swenson wrote:

Multics tapes are 9-track. Really? That doesn't match my recollection or the hard data I have seen. Can you back that up?

I've never seen a multics tape in 9-track. and trust me, I can go toe-to-toe.

-brad

[eswenson1]

Well, as far as I remember when I used Multics at the Pentagon, MIT, and CISL (Honeywell Multics development group in Cambridge, MA), the tape drives were all 9-track. However, Multics did support both 7-track and 9-track tapes. From the manual “Multics Programmers Reference Manual”, AG91-04, Appendix F:

APPENDIX F MULTICS STANDARD MAGNETIC TAPE FORMAT This appendix describes the standard physical format used on 7-track and 9-track magnetic tapes on Multics. Tapes of this form may be written and read by the tapemult I/O module (described in the Subroutines manual). Any magnetic tape not written in the standard format described here is not a Multics standard tape. STANDARD TAPE FORMAT The first recorded block on the tape following the beginning of tape (BOT) mark is the tape label record. Following the tape label record is an end of file (EOF) mark. Subsequent reels of a multireel sequence also have a tape label followed by an EOF mark. (An EOF mark is the standard sequence of bits on a tape that is recognized as an EOF by the hardware.) Following the tape label and its associated EOF are the data records. An EOF is written after every 128 data records with the objective of increasing the reliability and efficiency of reading and positioning within a logical tape. Records that are repeated because of transmission. parity. or other data alerts are not included in the count of 128 records. The first record following the EOF has a physical record count of 0 mod 128 . . A.n end of reel (EOR) sequence is written at the end of recorded data. An EOR sequence is: EOF mark EOR record EOF mark EOF mark

It goes on from there. You can find that manual here: http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AG91-04A_mpmVol2_Jan87.pdf

— Eric

On Feb 21, 2017, at 19:12, Brad Parker notifications@github.com wrote:

On 2/21/17 9:59 PM, Eric Swenson wrote:

Multics tapes are 9-track. Really? That doesn't match my recollection or the hard data I have seen. Can you back that up?

I've never seen a multics tape in 9-track. and trust me, I can go toe-to-toe.

-brad

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/17#issuecomment-281556066, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0-YwMsNG7bD6g6pibivkynsj6bFFgrks5re6eJgaJpZM4K7Wdo.

[eswenson1]

And when logged into Multics, and using the help system to describe the various resource types, I get this:

List of reserved attribute names: The following attributes are mandatory for the devices named, and must appear in all RTMFs.

For the disk_drive device

  model=400          model=451          model=181
  model=191          model=500          model=402

For the tape_drive device

  track=7          track=9
  den=200          den=556
  den=800          den=1600
  model=400        model=500
  model=600        model=610

The model tape drives that I remember on Multics systems were MTU500. However, looking in the TOLTS manual, I see that the following tape drives are supported:

MAGNETIC TAPE STORAGE: MTS500 7/9 Track Tape Handler MTU0400/MTU0500 7/9 Track Tape Handler MTU0410 7/9 Track Tape Handler MTU0600 7/9 Track Tape Handler MTU0610/630 7/9 Track Tape Handler — Eric

On Feb 23, 2017, at 10:00, Eric Swenson eric@swenson.org wrote:

Well, as far as I remember when I used Multics at the Pentagon, MIT, and CISL (Honeywell Multics development group in Cambridge, MA), the tape drives were all 9-track. However, Multics did support both 7-track and 9-track tapes. From the manual “Multics Programmers Reference Manual”, AG91-04, Appendix F:

APPENDIX F MULTICS STANDARD MAGNETIC TAPE FORMAT This appendix describes the standard physical format used on 7-track and 9-track magnetic tapes on Multics. Tapes of this form may be written and read by the tapemult I/O module (described in the Subroutines manual). Any magnetic tape not written in the standard format described here is not a Multics standard tape. STANDARD TAPE FORMAT The first recorded block on the tape following the beginning of tape (BOT) mark is the tape label record. Following the tape label record is an end of file (EOF) mark. Subsequent reels of a multireel sequence also have a tape label followed by an EOF mark. (An EOF mark is the standard sequence of bits on a tape that is recognized as an EOF by the hardware.) Following the tape label and its associated EOF are the data records. An EOF is written after every 128 data records with the objective of increasing the reliability and efficiency of reading and positioning within a logical tape. Records that are repeated because of transmission. parity. or other data alerts are not included in the count of 128 records. The first record following the EOF has a physical record count of 0 mod 128 . . A.n end of reel (EOR) sequence is written at the end of recorded data. An EOR sequence is: EOF mark EOR record EOF mark EOF mark

It goes on from there. You can find that manual here: http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AG91-04A_mpmVol2_Jan87.pdf http://bitsavers.trailing-edge.com/pdf/honeywell/multics/AG91-04A_mpmVol2_Jan87.pdf

— Eric

On Feb 21, 2017, at 19:12, Brad Parker <notifications@github.com mailto:notifications@github.com> wrote:

On 2/21/17 9:59 PM, Eric Swenson wrote:

Multics tapes are 9-track. Really? That doesn't match my recollection or the hard data I have seen. Can you back that up?

I've never seen a multics tape in 9-track. and trust me, I can go toe-to-toe.

-brad

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/17#issuecomment-281556066, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0-YwMsNG7bD6g6pibivkynsj6bFFgrks5re6eJgaJpZM4K7Wdo.

[lisper]

On 2/23/17 1:00 PM, Eric Swenson wrote:

Well, as far as I remember when I used Multics at the Pentagon, MIT, and CISL (Honeywell Multics development group in Cambridge, MA), the tape drives were all 9-track. However, Multics did support both 7-track and 9-track tapes. From the manual “Multics Programmers Reference Manual”, AG91-04, Appendix F: Ah, maybe that's it. When I say "multics" I just mean "multics at MIT". As far as I know, all of the MIT multics machines only had 7 track drives. I can't comment on other places, sorry. I misunderstood and thought you meant at MIT, sorry.

-brad

[larsbrinkhoff]

I now regularly make Chaosnet connections with UP and SJ. I'd say this is done.

[bictorv]

Anyway, I updated my bridge program so it deals with Chaos-over-Ethernet, Chaos-over-UDP, and (although I haven't had time to test it yet) Chaos-over-unix-sockets. This time it's almost modular, so adding other protocols such as Chaos-over-IP-type-16 would be doable, but I have no such implementation to test it with. The program does Chaosnet routing info (RUT packets) when connecting subnets.

If you want to try it, send me a message - it may need a little bit more work before being let out to the open public.

[larsbrinkhoff]

Sounds great!

I have no immediate need; I'm quite happy as long as the UDP version works ok. And I haven't worked much on ITS for some time because it seems most of the important things are done.

[eswenson1]

I would like to set up chaosnet between ES-ITS and UP, so please keep me informed and let me know when I should try it. (I never set this up with your earlier code, but kept meaning to). — Eric

On Aug 10, 2017, at 08:56, Lars Brinkhoff notifications@github.com wrote:

Sounds great!

I have no immediate need; I'm quite happy as long as the UDP version works ok. And I haven't worked much on ITS for some time because it seems most of the important things are done.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PDP-10/its/issues/17#issuecomment-321594489, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0-Y03hUTnow2DKaEdvX385GuxOkBAeks5sWygigaJpZM4K7Wdo.

[larsbrinkhoff]

Eric, I think that should be possible without the new bridge. KLH10 already includes code for tunneling Chaosnet packets in UDP. And the ITS repository is set up for using it when appropriately configured.