> From: William Degnan
> my focus has been on just getting an 11/40 hardware working
Rightly and properly so...
> I suppose I should be happy with RT-11 given my circumstances.
Unix really is a significant improvement, we really need to make sure you can
run it. Don't worry about the OS image issue, I can crank them out like
sausages, and we already have all the bits we need (V6 RL driver, bootstrap,
etc).
> It's not possible with the 3 over the back cables to put the 7238 on a
> riser card to probe signals as easily.
Really? DEC specified BC08R-01 cables, which _should_ be long enough to allow
it to be put on an extender. Does your machine have the -01's, or have they
been replaced with little shorty ones?
If the latter, if you can't find any -01's, it should be possible to locate
some generic 40-pin cables, which should work (old IDE cables should work,
but not the new ones, which have a key that will prevent the connectors from
going in, in this application).
Also, it should not to be too hard to whip up some: the connectors and the
flat cable are pretty easy to find - although not the ground-plane backed
kind - do anyone know of a source for that? Anyway, the regular kind of flat
cable ought to work well enough for debugging.
Noel
Hi,
I am looking to swap or buy the following HP-Integral IPC (portable HP-UX box) interface boards:
- HP-IL interface
- 1 MB memory board
Does anybody have a manual for the HP-IL interface board?
Could offer HP 9000 interface or memory boards.
Martin
Hi,
Can someone identify this circuit board? It's some sort of magnetic core
memory. I've had this for ages and I've always wondered what it is and
where it comes from.
http://lookpic.com/O/i2/366/iAFq4mLF.jpeg
Best regards
> From: Allison
> for laughs I wandered over to:
> To see if the copy of V6 on RL02 is still there.... yep it is.
There are actually plenty of builds out there that run on RL11s, e.g.:
http://www.tuhs.org/Archive/PDP-11/Distributions/other/Tim_Shoppa_v6/
includes "A V6 RL02 bootable on a 11/23. Kernel is built for a 11/23, 2
RL02's, and 2 RX02's"; and my V6, running under Ersatz-11, is also an
RL-based system.
The real issue with mixing and matching kernels and disks is that since the
RL was not a standard device (as far as 'mkconf' went), the RL's can have
different major device numbers on different systems.
This does not stop the system from _booting_, since internally there will be
consistency, but consistency between the OS and file system is another
matter: e.g. trying to mount another drive (or any other use of /dev/rl? or
/dev/rrl?) may not work, since the device inodes for /dev/rl? might have the
wrong major device numbers in them.
> and it runs on a 11/23 just fine
Must be a slightly modified V6 - totally stock V6 will panic when it can't
find a clock (unless there's a BDV11), or NXM when it tries to touch the
switch register.
And for machines with no BDV11, I had to turn the clock off while booting;
the first time I tried to boot on a simulated 11/23, my totaly stock vanilla
V6 apparently took a timer interrupt during the boot process and went wayyyy
South, totally smashing the file system in the process. Not sure how the one
above dealt with this...
Noel
> From: Phil Blundell
> I suspect it would probably not be all that hard to write some
> sort of preprocessor to convert such code
Really? Check out:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/pipe.c
(Needless to say, none of the 'int *' things are actually pointers to
integers!)
In particular, what will lines like this:
sleep(ip+2, PPIPE);
do, depending on what 'ip' is declared as?
Noel
> Jim Stephens
> The listings I've read of early unix have ... mixed c + assembly
Not V6 (the subject of the current discussion); the C compiler of that era
couldn't inline assembler.
_ALL_ of the assembler in V6 is in one of _two_ files:
l.s - per system, hardware configuration dependent
m40.s - Startup, and machine language support for all low-level OS
or functions such as stack switching, etc; the latter option
m45.s supported both the -11/45 and -11/70
Noel
> From: William Degnan
> was there ever UNIX made for the PDP 11/40 and RL02, or was it only run
> on RK05? Wouldn't all of the C and wake calls, etc issues have been
> solved then?
You're mixing up two _TOTALLY_ different things.
Unix V6 will happily run on _ANY_ block device, all you need to do is write a
driver for it. The rest of Unix V6 doesn't know ^%$^%$ about the device, all
it know is that there's this thing that can store, and read back, blocks 0-N.
The _only_ interface between the rest of Unix, and the driver, is through a
file called c.c which just contains entries for functions to read and write
blocks, etc.
(You can even run Unix - painfully - on a DECTape drive.)
Adding support for RL drives to Unix V6 involves i) writing an RL driver, and
ii) editing that file c.c to add _one line in a table_ to hook the driver
into the rest of the OS. (And there's a edit to something called l.s which
holds interrupt vectors, to all the RL vector.) THAT'S IT.
Editing c.c and l.s was No Big Deal. To customize Unix to one's particular
hardware configuration, you _had_ to change those two files, and every V6
site in the known universe tweaked those files. _WITHOUT EXCEPTION_.
Unix V6 doesn't give a *&^*&^* what disk drives its using. As long as there's
a driver for the controller.
The stuff about wake() calls is a totally different subject, it's all about
how the code in V6 Unix cuts a lot of 'C' corners (e.g. using an 'int *' as a
pointer to a struct - something that would horrify modern compilers) because
it's in very early C.
Noel
> From: Paul Koning
> Yes, GCC should do that correctly. ... Dealing with the output might be
> a nuisance ... You may need some post-processing to cast the output
> into the syntax that V6 "as" expects.
Actually, dealing with the _input_ is going to be a PITA (so my suggestion
was, in retrospect, not really a plausible one). The problem is that V6 is
written in an early dialect of C, one which I am sure would cause GCC would
toss its cookies, if fed to it.
Some things, like "a =+ b;" would be easy to fix; likewise "int a 1;" instead
of "int a = 1;". But the Unix kernel is shot through with places where are
int is used as a structure pointer, etc, without benefit of a cast (casts
weren't invented until later). And a lot of stuff like that.
Noel
> From: William Degnan
> if possible can you help me to link in m40.o instead of m45.o?
Sure; tomorrow, though, not tonight.
Just to check, you have 128KB of memory, and 2 RL02 drives, right? That will
make it all really easy, if so.
Like I said, I'll make you a mini-disk that will be quick to load with GUI11,
with only the only files on it the few you need to be able to boot: the Unix
system, /etc/init, /bin/sh, etc. Once it has booted, you can 'mount' your
existing RL pack, and copy the Unix system over to that one, then you should
be able to boot off that one.
Noel
PS: I was thinking of fixing 'mkconf' (it currently doesn't properly handle
the /dev/tty device, etc), but whoever wrote it was really lazy! 'nswap' and
'swplo' aren't even parameterized, let alone being things you can override
with inputs. So the dude who did the RL disk just changed the numbers for the
RL - so his mkconf now doesn't work properly for RK drives! Might as well just
edit c.c and l.s directly - that's what I always did! ;-)
Anyway, I might fix it at some point, but... not for tomorrow.
