14 Nov
2005
14 Nov
'05
3:38 p.m.
On Mon, 14 Nov 2005 09:16, Peter Jeremy wrote:
I've also looked at this in the past. I lost
interest when my
intended target box died (and I realised I didn't have the free time).
On 2005-Nov-12 08:18:50 -0500, Brantley Coile <brantley(a)coraid.com> wrote:
Would it be possible to use some of the DOS ones? At least to bootstrap a
more true-to-Unix one?
I'm thinking of the likes of bcc, available plus source at the FreeDOS web
archive. Or OpenWatcom's DOS 16-bit.
Wesley Parish
--
Clinersterton beademung, with all of love - RIP James Blish
-----
Mau e ki, he aha te mea nui?
You ask, what is the most important thing?
Maku e ki, he tangata, he tangata, he tangata.
I reply, it is people, it is people, it is people.
i may be wrong, but i don't think you want
the segments. pdp-11
segments divided the address space into eight, well, segments. each
could be grow up or grow down and had a physical base and a limit.
intel segments don't work that way. the major difference is that the
segment selector, instead of being the upper most three bits of the
virtual address, is not even in the address space at all.
Actually the 286 MMU is very primitive compared to the PDP-11. One
crucial difference is that Unix has the implicit assumption that the
stack is in the data space - which is not true on the 286. This
difference is fairly critical to Unix and makes it impossible to
accurately reproduce the traditional Unix memory protection.
so the eight, for a pdp-11/40 say, or the sixteen
for the 11/70 don't
really apply. instead just give each data segment the whole 64k
address space and it'll not klobber anybody else. just itself.
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.
This approach also makes brk(2) a no-op. There's nothing to prevent a
process using as much heap as it wants (or crashing into the stack).
(No SIGSEGV or SIGBUS errors).
you're correct to imply that v6 takes up MUCH
less space than other
systems. it's amazing how small you can run this. the root in the
6th edition system is only 1.4MB. and that includes the normal
binaries, libraries and the source to the kernel. it'll run great on
a floopy.
You will need to have a swap partition. And if each process has a
64K data segment, you'll need a comparatively large amount of swap.
The biggest disadvantage of a floppy will be performance - latency
of about 80msec, I/O of about 40KB/sec.
Have you identified a suitable C compiler? There aren't many open
source 16-bit x86 compilers, especially ones that can run in 16-bit
mode. None of the ones I found generated particularly good code.
This may impact you ability to get the larger utilities (and maybe
the kernel) to fit into 64K I-space.