[TUHS] Attempting To Build NOSC and BBN UNIXs + ARPANET code
michael at casadevall.pro
Tue Oct 11 06:48:56 AEST 2022
On Mon, Oct 10, 2022 at 4:31 PM Clem Cole <clemc at ccc.com> wrote:
> On Mon, Oct 10, 2022 at 2:33 PM Michael Casadevall <michael at casadevall.pro>
>> For example sys4.c is entirely corrupted, and part of impio.c is cut
> % 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
sys4.c is just garbage characters, impio.c stops in the middle of a
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’s 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’s
>> 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 Universities
> 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 of
> places had it and if you upgraded your V6 system to it, it was hard to go
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’m hoping someone might be able to provide some insight 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 you
> 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 =
is posted, and *then* it falls over.
* NOTE: The DC-11 driver was not included, but I don’t think I need that
>> for a single console?
> Should not need it - you can make sure /dev entry is nuked for it. check
> 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.
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 ...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the TUHS