I've assembled some notes from old manuals and other sources
on the formats used for on-disk file systems through the
Additional notes, comments on style, and whatnot are welcome.
(It may be sensible to send anything in the last two categories
directly to me, rather than to the whole list.)
> Unfortunately the autoconfig stuff has /unix hard coded into
> it and will only look for this file.
Thanks, guys, for the answer. I've got to admit that I'm disappointed.
If you have to decide, before the old system goes down, via a series of
moves or copies or hard links or whatever, which kernel you're going to use
the next time the system comes up, then it doesn't seem all that useful.
I guess if I build a kernel that just doesn't work at all, I can always
boot the old kernel far enough to get to single user mode where I can remove
the dud /unix, put the old one back, and then reboot. That's something.
Anyway, if that's the way it is, then that's the way it is :-) Thanks
On Fri, 18 Nov 2005, Markus E Leypold wrote:
> I wonder, wether you realize that getting pcc "ready" would mean
> writing a x86 backend for it. Or does it already have one?
>From what I heard it does, unless I misremembered...
On 2005-Nov-14 10:45:13 -0500, Brantley Coile <brantley(a)coraid.com> wrote:
>> This is fairly wasteful of RAM. Keep in mind that V6 cannot page -
>> a process is either entirely in memory or entirely on disk. If you
>> limit yourself to 640K RAM, you are probably restricting yourself
>> to about 6 resident processes. And swapping means moving 64K of
>> data to/from disk.
>true, but your numbers are a bit off. 640k / 64k = 10 not 6.
I realise that.
> the kernel will take only 2, so you should have 8.
I was assuming split I+D, with the data segment fixed at 64K. This
means that you have (64K + code) per process. If you have code plus
data in 64K then you can fit more, but I think that was getting to
be a squeeze even on V6. (And would definitely write off something
>the mit x86 stuff would be where i'd start. i haven't looked to see
>if you need to tweak the assignment operators to avoid having
>to s/=+/+=/, but it might already be done.
Given an open-source compiler, it would be fairly easy to retrofit the
=+ operators into the lexer. (Probably easier than cleaning up the
code). The alternative is to start with something later (eg 2BSD) but
code quality then becomes far more of an issue (because 2BSD tends to
push the I-space limits in lots of areas).
>it's all 16 bit stuff: port of PCC, assembler and loader.
The x86 instruction set and registers are nothing like as regular and
orthogonal as the PDP-11. In particular, there are _no_ general
purpose registers - every register has has a particular purpose and
either you need to do data-flow analysis to work out what register to
load something into, or you (basically) give up and load from memory
as needed. You could port PCC but this would be much more difficult
than (say) a M68K port. You'd probably need a fairly decent peep-hole
optimiser to get good results.
Wesley Parish mentioned bcc and OpenWatcom. I looked into the former
and it's probably the best starting point (though, with due respect to
BDE, the code it generates could be better). Assuming that Unix fits
into the C subset implemented by bcc, you'd be better off spending the
effort on improving bcc than porting PCC. At the time I looked,
OpenWatcom was either still vapourware or not self-hosting.
>an enjoyable discussion. wish i had time to work on it.
This email may contain privileged/confidential information. You may not copy or disclose this email to anyone without the written permission of the sender. If you have received this email in error please kindly delete this message and notify the sender. Opinions expressed in this email are those of the sender and not necessarily the opinions of the employer.
This email and any attached files should be scanned to detect viruses. No liability will be accepted by the employer for loss or damage (whether caused by negligence or not) as a result of email transmission.
I've thought, since there doesn't seem to be a working "V6on286", maybe I
should try porting it myself though I'm not very familiar with the Ancient
Unix sources or with the ancient C used. The oldest compiler I've got
that will compile is Turbo C++ 1.01 from 1990 and it's an ANSI C compiler.
(I do think it'll compile late K&R, but there's weirdnesses in the C used
Having an emulator like QEMU handy is a nice plus. I could prolly build
everything onto a 1.44 MB disk image and boot it in emulation. I'm
thinking I'd want to create tools for transferring files into and out of
disk images, and a bootloader to put on the first sector of the disk
(though, 512 bytes is awful small...)
i don't know that it's a squese. a version of v6 ran on an lsi-11
with very little ram.
If you're thinking of Mini-UNIX, it's a bit of a stretch to call
it `V6 running on an LSI-11.' I think the original LSI-11 had no
memory management; in any case, Mini-UNIX didn't use it, but was
a throwback to the early days of the PDP-7 and the 11/20 (neither
of which had memory management). Only one process could be in
memory at a time; to let another process run meant swapping the
first completely out of memory.
I believe there's a paper in the 1978 all-UNIX issue of the Bell
Systems Technical Journal about Mini-UNIX or its immediate
predecessor. As I recall, there were additional compromises;
e.g. the shell quietly translated
a | b
a >tempfile; b <tempfile; rm tempfile
because that was much faster than the thrashing that often
resulted from trying to let a and b run concurrently.
Mini-UNIX might be a simpler starting point to get a system
running on a 286. Just don't think of it as full V6; it's not.
here at freaknet medialab we made some images of our
RL02 disk packs with RT-11 and GAMMA-11 software
(specific for a Nuclear Camera, this pdp-11 was used
for medical exams) :)
those images are very funny, we can use them under
simh emulator! :)
So, now that we have the backups, we're wondering about
installing UNIX in this pdp11/34.
what can we install? any hint ?
please help! :)
p.s. something about our restoration and the disk image of
our rt-11 system is online at http://zaverio.net/pdp11, under
the "stuff" directory. :)
[ asbesto : IW9HGS : freaknet medialab : radiocybernet : poetry ]
[ http://freaknet.org/asbestohttp://papuasia.org/radiocybernet ]
[ http://www.emergelab.org :: NON SCRIVERMI USANDO LE ACCENTATE ]
[ *I DELETE* EMAIL > 100K, ATTACHMENTS, HTML, M$-WORD DOC, SPAM ]
Sorry for my previous aborted message. I'm using
webmail which is an alien sort of thing to me.
What I wanted to say is that you may as well let them
'telnet' to the PDP11-2.11BSD through SSH.
I mean, you may have the PDP behind a firewall with
ports blocked, and another machine (linux, *bsd,
whatever) with SSH open.
Then all that would be needed is that your friend uses
SSH tunnel to the telnet port of the PDP.
For instance, let's say you open an account for your
friend on the intermediate machine: s/he may use this
machine to forward one of his local ports (say 2300)
port 23 on the PDP11 system (say
ssh -L 2300:pdp11-2bsd.example.net:23 hop.example.net
This would forward his local port 2300 to port 23
of pdp11-2bsd.example.net, using the host
hop.example.net as an intermediate SSH step.
Then all that your friend needs to do is issue a
telnet localhost 2300
and that would connect him to the telnet port of the
PDP11 using SSH.
If s/he uses windows, most SSH clients have a port
forwarding tool that makes introducing this
So, to sumamrize:
- you open an account on an intermediate host that has
- your friend creates a tunnel from his own computer
the PDP using the intermediate host with his
- your friend telnets his/her own local computer at
All communications will be encrypted between his/her
computer and the intermediate host, and go in the
between the intermediate host and the PDP.
If the intermediate host is behind a firewall, then
that would be no problem.
Renovamos el Correo Yahoo!
Nuevos servicios, más seguridad
Hello from Gregg C Levine
Still working on my ideas regarding E11 and the usual OSes for the
PDP-11. Would anyone of you know when networking via Ethernet was
added to the capabilities of regular UNIX? It seems to be available in
the releases of BSD that I've explored.
For those that missed it, I can reiterate my plans concerning the
Linux variety of E-11, and those operating systems, but only upon
Gregg C Levine hansolofalcon(a)worldnet.att.net
"Remember the Force will be with you. Always." Obi-Wan Kenobi