Replies inline
On Mon, Oct 10, 2022 at 4:31 PM Clem Cole <clemc(a)ccc.com> wrote:
below...
On Mon, Oct 10, 2022 at 2:33 PM Michael Casadevall <michael(a)casadevall.pro>
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’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
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’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 ...
Michael