From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,MAILING_LIST_MULTI,T_PDS_PRO_TLD autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26767 invoked from network); 10 Oct 2022 20:50:10 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 10 Oct 2022 20:50:10 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 370DE40ED7; Tue, 11 Oct 2022 06:49:47 +1000 (AEST) Received: from pathfinder.casadevall.pro (pathfinder.casadevall.pro [45.33.112.193]) by minnie.tuhs.org (Postfix) with ESMTPS id 59B4540ED5 for ; Tue, 11 Oct 2022 06:49:41 +1000 (AEST) Received: from mail-pf1-f176.google.com (mail-pf1-f176.google.com [209.85.210.176]) by pathfinder.casadevall.pro (Postfix) with ESMTPSA id 6E6741F530 for ; Mon, 10 Oct 2022 20:49:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=casadevall.pro; s=mail; t=1665434950; bh=/tOdHk1VgircmmJejvTO1uFLlsw4k1cVfsI7Ur3J49g=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=tqBtZPBWYFlWP6GqFkif3gFnbRogRsHFq4NjN+0ma0a2D2TI4OUV5RkoTmNW4b5H9 lWqnqqxXZbryDzgBvGiQnuutBDMQmrcq5IDKRtTKjInWfviQV+PQtkjNGzM5VUnbgK M5H86nS0ZIsRmT73uu2LM8qP2En+oX/u+K5lWwmSmO5D5LfMV99uDVg6g2mffb3+45 Xma+vqw+nAG/oITxPivmtrb+L3bjJn9ITGZD2KCXokmzKWAT0SSBxZNqy/oMp//ESu nUujaLxoSoSnRGm7iCLadA9ZIXbW0Mq3e9AoIWne2p5/yTwbHJVh0hgKNhHoQ/WAF2 0hVVjYzLPuypQ== Received: by mail-pf1-f176.google.com with SMTP id y8so11705226pfp.13 for ; Mon, 10 Oct 2022 13:49:10 -0700 (PDT) X-Gm-Message-State: ACrzQf1tZHuabZtybs6tKiuT39OP14KSliLEqpGYKQLoDk2WCJ4uWo/x gFLq73gZ1VxQnjKttI3mpf+hGcsogo6UYuAV5RI= X-Google-Smtp-Source: AMsMyM68lBGoBR2LelaIudREecWeYuzELcD9PuVfhMZ80vtB98rnBlKV/k4RMUXXrZsfqREueGWqAUAq4VCMOisfyto= X-Received: by 2002:a63:8:0:b0:460:e669:a0c4 with SMTP id 8-20020a630008000000b00460e669a0c4mr10256421pga.475.1665434947582; Mon, 10 Oct 2022 13:49:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Michael Casadevall Date: Mon, 10 Oct 2022 16:48:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Clem Cole Content-Type: multipart/alternative; boundary="00000000000072825e05eab44aa3" Message-ID-Hash: DM5ZNQ43Y553UOAEN6IC3JF7UT342UCI X-Message-ID-Hash: DM5ZNQ43Y553UOAEN6IC3JF7UT342UCI X-MailFrom: michael@casadevall.pro X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Attempting To Build NOSC and BBN UNIXs + ARPANET code List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000072825e05eab44aa3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Replies inline On Mon, Oct 10, 2022 at 4:31 PM Clem Cole wrote: > below... > > > On Mon, Oct 10, 2022 at 2:33 PM Michael Casadevall > wrote: > >> For example sys4.c is entirely corrupted, and part of impio.c is cut >> off. >> > Hmmm > > % sha256sum impio.c sys4.c > 1f3d10a7e6989996dae8a07992684881fa8bc05ddc5d512c86efdaf34b4437d2 impio.c > 7bd82c560d7bd74f64b03dac10550620b70d88340f02e31b56c6002f2ae6c88d sys4.c > > This is from my system - check to see if what you have are different > > >From the NOSC tarball from THUS: % sha256sum ncpk/drivers/impio.c ken/sys4.c ace2b7dae48bacf86b3bf1260a7715b66264308d67eb3232d963794481910c6a ncpk/drivers/impio.c e5e727139e10b476c4dfa534155ddc07c0b3d32f132c98939c58d24f9a5efc41 ken/sys4.= c sys4.c is just garbage characters, impio.c stops in the middle of a function. There's also some corruption (mostly single bytes stuff) in other files, i.e., I had to edit some non ASCII characters out because cc was unhappy, so if a redump is possible, it would be good. > >> >> There=E2=80=99s some indication that this, and the later BBN TCP (which = is from >> around the same time period) code were built on top of the Programmer=E2= =80=99s >> Workbench vs. stock v6; >> > Where did you see that? Possible of course, but less likely. PWB 1.0 > was not released outside of BTL. Parts leaked to some of the Universitie= s > and the MIT systems were famously PWBish, so it's possible it leaked from > MIT to BBN. AGN is the comments -- Al Nemeth who is a friend of mine and > Al told me in those days, BBN was pretty spooked about where UNIX stuff > came from at BBN. > > I think it's more likely if something is not stock V6, is using the > typesetter C compiler - which is the compiler described in K&R1 and would > later be part of V7 and PWB 2.0. That was released independently a lot o= f > places had it and if you upgraded your V6 system to it, it was hard to go > backward. > > There are SCCS references in the code from 78/79, references to the V7 CC compiler and updates. SCCS was introduced publicly with PWB, which is why I suspect it might have been used. The code also uses some C syntax the stock compiler dislikes (specifically, it was unhappy register in the function declaration). The documentation discusses updating the C supervisor, and also using the Yale shell included in the source before trying to build. I know there's an updated cc that was on some of the disk dumps of later v6 systems, which might also be where things like "libg", and such are. There's a few .a bundles that there are binaries but no sources in the archive, but I didn't make a comprehensive list on it. > > >> >> In short, I=E2=80=99m hoping someone might be able to provide some insig= ht into >> where things have gone wrong: >> * Is the netunix kernel I built hanging because of corrupted code, or >> is it waiting for non-existent hardware. >> > Could not a ton of things - where is stopping -- use simh to get an > address and then check then look UNIX symbol table and see what routine y= ou > are in and see if you can egt a hint. > I'll check this next time I get the system out. I did follow the code a fair bit, and it looks like I do at least get as far as sched() since mem = =3D is posted, and *then* it falls over. * NOTE: The DC-11 driver was not included, but I don=E2=80=99t think I need= that >> for a single console? >> > Should not need it - you can make sure /dev entry is nuked for it. chec= k > c.c and see what entry it was -- it should be commented it. The look in > /dev and rm the entry so you don's accidentially try to open > Awesome, thanks. That's what I suspected, but that's what I thought. > > >> NOTE: v6's cc needs a seperate patch to increase the symbol table size; >> that's done in the disk image. >> > Yep - done many times - also if you use a 45 or 70, make the compiler > image split I/D that helps too. Although we ran them on 40s all the > time - even before Fred's overlay code. > =E1=90=A7 > Beside the startup code (which is in mch.c and uses a preprocessor macro), is there anything specific gotchas in regards to models? I tried building CPU40 and CPU70, and configuring simh, just to eliminate that gotcha, but the only difference seems to be early initialization code ... Michael --00000000000072825e05eab44aa3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Replies inline

On Mon, Oct 10, 2022 at 4:3= 1 PM Clem Cole <clemc@ccc.com> w= rote:
below...


On Mon, Oct 10, 2022 at 2:33 PM Mich= ael Casadevall <michael@casadevall.pro> wrote:
=C2=A0For example sys4.c is enti= rely corrupted, and part of impio.c is cut off.
= Hmmm

=C2=A0% sha256= sum impio.c sys4.c
1f3d10a7e6989996dae8a07992684881fa8bc05ddc5d512c86efd= af34b4437d2 =C2=A0impio.c
7bd82c560d7bd74f64b03dac10550620b70d88340f02e31b56c6002f= 2ae6c88d =C2=A0sys4.c

This is fro= m my system - check to see if what you have are different

<= /div>

From the NOSC tarball fro= m THUS:

=C2=A0% sha256sum ncpk/drivers/impio.c ken/sys4= .c
ace2b7dae48bacf86b3bf1260a7715b66264308d67eb3232d963794481910c6= a =C2=A0ncpk/drivers/impio.c
e5e727139e10b476c4dfa534155ddc07c0b3d32f1= 32c98939c58d24f9a5efc41 =C2=A0ken/sys4.c
sys4.c is just garbage characters, impio= .c stops in the middle of a function.

<= /div>
There's also some corruption (mostly si= ngle bytes stuff) in other files, i.e., I had to edit some non ASCII charac= ters out because cc was unhappy, so if a redump is possible, it would be go= od.

=C2=A0

There=E2=80=99s some indication that this, and the later BBN TCP (= which is from around the same time period) code were built on top of the Pr= ogrammer=E2=80=99s Workbench vs. stock v6;
Where = did you see that?=C2=A0 Possible of course, but less likely.=C2=A0 =C2=A0PW= B 1.0 was not released outside of BTL.=C2=A0 Parts leaked to some of the Un= iversities and the MIT systems were famously PWBish,=C2=A0so it's possi= ble it leaked from MIT to BBN.=C2=A0 AGN is the comments -- Al Nemeth who i= s a friend of mine and Al told me in those days, BBN was pretty spooked abo= ut where UNIX stuff came from at BBN.

I think it's=C2=A0more likely if = something is not stock V6, is using the typesetter C compiler - which is th= e compiler described in K&R1 and would later be part of V7 and PWB 2.0.= =C2=A0 That was released independently a lot of places had it and if you up= graded your V6 system to it, it was hard to go backward.


There are SCCS references in the code from 78/79, references to the V7= CC compiler and updates. SCCS was introduced publicly with PWB, which is w= hy I suspect it might have been used. The code also uses some C syntax the = stock compiler dislikes (specifically, it was unhappy=C2=A0register in the = function declaration). The documentation discusses updating the C superviso= r, and also using the Yale shell included in the source before trying to bu= ild.

I know there's an updated cc that was on = some of the disk dumps of later v6 systems, which might also be where thing= s like "libg", and such are. There's a few .a bundles that th= ere are binaries but no sources in the archive, but I didn't make a com= prehensive list on it.
=C2=A0
=

In s= hort, I=E2=80=99m hoping someone might be able to provide some insight into= where things have gone wrong:
=C2=A0 * Is the netunix kernel I built ha= nging because of corrupted code, or is it waiting for non-existent hardware= .
Could not a ton of= things - where is stopping -- use simh to get an address and then check th= en look UNIX symbol table and see what routine you are in and see if you ca= n egt a hint.=C2=A0

I'll check this next time I get the system out. I did follow t= he code a fair bit, and it looks like I do at least get as far as sched() s= ince mem =3D is posted, and *then* it falls over.

* NOTE: The DC-11 driver was not included, but I don=E2=80=99t think= I need that for a single console?
Should not need it - you can make sure /dev entry is nuked= for it.=C2=A0 =C2=A0check c.c and see what entry it was -- it should be co= mmented it.=C2=A0 =C2=A0The look in /dev and rm the entry so you don's = accidentially try to open =C2=A0
=

Awesome, thanks. That's what I suspect= ed, but that's what I thought.
=C2=A0
=C2=A0
=C2=A0NOTE: v6's cc needs a seperate patch to = increase the symbol table size; that's done in the disk image.
Yep - done many times - also if= you use a 45 or 70, make the compiler image split I/D that helps too.=C2=A0=C2=A0 Although we ran them on 40s all the time - even before F= red's overlay code.
3D""=E1=90=A7

Beside the startup code (which is in mch.= c and uses a preprocessor macro), is there anything specific gotchas in reg= ards to models? I tried building CPU40 and CPU70, and configuring simh, jus= t to eliminate that gotcha, but the only difference seems to be early initi= alization code ...

Michael
--00000000000072825e05eab44aa3--