> 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.
> From: William Degnan
> Tried my M7838 EIS this morning. It is bad or there is a config/jumper
> issue to investigate.
When installing the KE11-E, you have to remove a jumper on the CPU's M7233
module. See pg. 2-1 on the KE11-E/KE11-F User's Manual (EK-KE11E-OP-001),
available online. Did yours come with the three flat cable jumpers?
If it's still not working, the KE11-E/KE11-F Technical Manual
(EK-KE11E-TM-002), also available online, will undoubtly prove useful.
Noel
Hi Josh,
I saw your posting on the 23rd Jan 16 regarding Bull DPS 6.
We are based in the UK and actually run 4 working DPS6 systems in the UK.
Any system (in its entirety or parts) we may be interested in if compatible with our existing system.
Do you still have it?
Many thanks,
Julian
Julian Metcalf
Finance Director
Like Technologies Ltd
0845 519 2244 Ext 111
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Like Technologies Ltd.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in error.
> From: William Degnan
> I do not have an EIS installed. I have one however, I can try it. I am
> unsure if it's good or not, but I guess I am going to find out.
Oh yeah, without that, you're totally hosed, Unix-wise. The V6 C compiler
puts out MUL etc all over the place (e.g. for structure pointer math), so
there's absolutely no way to run vanilla V6 Unix without it.
(The GCC compiler claims to be able to compile C to machines without the
EIS; it might be an interesting hack to see if that could be used to get
V6 running on a machine without the EIS. The machine language startups
would still need work, though. And the bootstrap. :-)
> Josh Dersch
> As I mentioned above
Right, but if his bootstrap isn't working, gotta debug that first.. :-)
> you'll also need to recompile the kernel
Actually, I don't think you need to re-compile anything, just link in m40.o
instead of m45.o; I think all the C code checks for 'cputyp == 40' or
whatever, as the case may be.
Noel
> William Degnan
> It "boots" to the ! prompt at least there's that.
Yeah, but not much has to be working for that to happen! :-)
> I am unsure if one can put an M7891 into a slot that has no NPG jumper
> installed
Yes, you can - but having a slot with no NPG jumper, and either i) no board
in in it at all, or ii) a non-DMA-speaking board in it, will prevent any DMA
device _further down the bus_ from working.
> I would have to check, or whether I can put this card into a DD11-B
No. It needs a MUD slot (UNIBUS in connectors A-B, essentially; more here:
http://gunkies.org/wiki/Modified_UNIBUS_Device
although other places have info about this too). (I'm not exactly sure how
the A/B connectors on DD11-B slots 2 and 3 are wired, it's something wierd,
look at the DD11-B prints for more.)
> or a slot without the NPG installed.
The NPG jumper is IRRELEVANT to everything except DMA devices (in that slot,
and downstream).
> Typing *anything* kills the system.
Well, technically speaking, that's not entirely accurate - clearly, from the
below typing "r" doesn't crash the machine. I gather you meant 'typing
"{anything}<CR>" crashes the machine'. Hmm.
> When I type say rlunix or foobar or whatever and hit enter, the prompt
> returns to the next line and the CPU stops. The system crashes,
> unresponsive, requiring restart from the front panel.
That sounds like the bootstrap isn't running properly.
Oh, I remember an issue I had with the boostrap when first trying to bring up
Unix in Ersatz-11 - does your -11/40 have the EIS board? Is the EIS working?
If not, the bootstrap won't run - it uses the MUL instruction. (MUL is not in
the base set on an -11/40, it's an option.)
If that's not it, we'll have to debug the bootstrap... Should't be too hard,
test versions can be loaded directly into memory with GUI-11, we don't have to
write them to disk. You've got a (hopefully good) disk to have the bootstrap
ponder over...
Noel