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