* [TUHS] Re: PCS kernel sources
@ 2024-01-18 11:33 Paul Ruizendaal via TUHS
0 siblings, 0 replies; 3+ messages in thread
From: Paul Ruizendaal via TUHS @ 2024-01-18 11:33 UTC (permalink / raw)
To: tuhs
> All, I got this e-mail from Holger a while back. Somehow it went into
> a folder and has lurked unseen for way too long.
>
> Does anybody know any more about PCS Unix and, if so, where should
> I place the code that Holger has donated into the Unix Archive?
I don’t know much about PCS Unix, but I did come across many references to Newcastle Connection (and Unix United) when researching early networking and the various approaches to giving early Unix a networking API. I think there is no other set of surviving sources for this. Maybe Holger disagrees, but I would say that PCS Unix is best placed in the “Early networking” section.
By the way, for those interested, here is a start to read up on Unix United: https://en.wikipedia.org/wiki/Newcastle_Connection
To some extent, it is similar to the “RIDE” software developed at Bell Labs Naperville by Priscilla Lu and to S/F Unix developed by GWR Luderer at Murray Hill. As far as I know the sources for both of those have been lost to time, afaik.
^ permalink raw reply [flat|nested] 3+ messages in thread
* [TUHS] Re: PCS kernel sources
2024-01-17 0:23 ` [TUHS] " Warren Toomey via TUHS
@ 2024-01-17 7:03 ` Veit, Holger via TUHS
0 siblings, 0 replies; 3+ messages in thread
From: Veit, Holger via TUHS @ 2024-01-17 7:03 UTC (permalink / raw)
To: tuhs
Am 17.01.2024 um 01:23 schrieb Warren Toomey via TUHS:
> On 1/17/24 10:20, Warren Toomey via TUHS wrote:
>> Does anybody know any more about PCS Unix and, if so, where should
>> I place the code that Holger has donated into the Unix Archive?
>
> I should have attached the README that Holger provided. It's below!
>
> Cheers, Warren
>
> [...]
>
The current code can be found on https://github.com/hveit01/{pcsdis,
pcsrun, pcs-munix}, however, I haven't found enough time to make more
significant progress in reverse engineering it. There is quite more
stuff in the queue, including the graphical display support with an old
X10 (no, not X TEN as in home automation, but the prececessor of the X11
Window system). But work will continue.
Regards
Holger
^ permalink raw reply [flat|nested] 3+ messages in thread
* [TUHS] Re: PCS kernel sources
2024-01-17 0:20 [TUHS] " Warren Toomey via TUHS
@ 2024-01-17 0:23 ` Warren Toomey via TUHS
2024-01-17 7:03 ` Veit, Holger via TUHS
0 siblings, 1 reply; 3+ messages in thread
From: Warren Toomey via TUHS @ 2024-01-17 0:23 UTC (permalink / raw)
To: tuhs
[-- Attachment #1: Type: text/plain, Size: 4455 bytes --]
On 1/17/24 10:20, Warren Toomey via TUHS wrote:
> Does anybody know any more about PCS Unix and, if so, where should
> I place the code that Holger has donated into the Unix Archive?
I should have attached the README that Holger provided. It's below!
Cheers, Warren
This is part 1 of the reverse engineered sources of the PCS Cadmus
MUNIX-1.2 kernel (32bit)
which can be found on the IS0371 tapes (check FTP server of
Computermuseum Stuttgart, Germany,
contact Klemens Krause).
PCS was a German systems vendor in the 80s, located in Munich, hence
"MUNIX": Munich Unix. They came up with
an AT&T base Unix for a QBUS-based (!) 68010 machine (later an 68020)
machine. The interesting feature of this
Unix derivation was the inclusion of the so called Newcastle connection
which is an early multicomputer network
(similar to the later NFS) which like later SUN workstations allowed
disk based as well es diskless hosts.
Newcastle connection uses an own raw Ethernet protocol; it implemented
basic layer 2 stuff (ARP, ICMP) but did
not use TCP/IP. It is AFAIK documented here for the first time.
The package includes the 32 bit 1.2 kernel from Jan, 1988, including all
kernel support libraries as well as some
standard libs (libc, libm, etc).
There are also the rebuilt sources of the MINITOR boot monitor.
To guarantee correctness of the rebuilt sources, I used the following
process:
- I ignore describing the unpacking and conversion of the distribution
tape - many files are CPIO archives, possibly
with some uninteresting byte-sex issues.
- The distribution contains a set of libraries (under /usr/src) that
allow regenerating a new kernel. They are
plain AR files, without the standard .a extension. These were
unpacked into the .o files of the kernel. MUNIX uses
COFF in an obscure incarnation - it uses the VAX magic, but
internally contains 68K code. This is why well-known
IDA disassembler cannot handle this without some patching, but even
after fixing the magic it has severe issues with
calculating .data and .bss addresses. This is why I wrote an own
disassembler (pcsdis) and only used IDA for code
containing 68881 FP instructions (was to lazy to put them in - they
are only used in libm.a anyway).
- With the knowledge of the include headers, it was possible to
transform the disassembly output back into C code.
Fortunately, the PCC-based C compiler produces rather regular code.
Looking up similar sources from elsehere, like Bitsavers and Tuhs, I
could identify the original parts from AT&T code
und find the modifications that PCS made to it. The whole I/O devices
library was non-AT&T code, some of it resembled
PDP11 QBUS device handlers, but most of it was hard work to compare
the driver code with DEC documentation
e.g. from Bitsavers.
- After having the regenerated source code, it was necessary to verify
its correctness. I wrote, based on the 68K Musashi
emulator code, a syscall emulator (pcsrun) that translated the most
important MUNIX syscalls (COFF loader, open, close, read, write,
fork, etc.) into corresponding OS calls, so that an original MUNIX
executable like CC itself basically worked with files
from the underlying OS (in my case Windows, or Linux, resp.). It
contains only the syscalls that the compiler/linker etc.
used, however, so it won't allow to try out network code. This way, I
could run my C code through the original compiler
from the MUNIX distribution, and compare its output with the original
binaries. This way I found numerous anachronisms
that resulted from some rather obscure type casts (which messed up
register usage), as well as unused variables an even
several bugs that appear to come from sloppy adaption of original
AT&T code to the platform. When trying to get the LD linker
to run, it turned out that this will work only after relaxing seg
fault handling on NULL pointers - some strcmp(xxx,(char*)0)
were found in the code.
- For reference, pcsdis and pcsrun are also included, however the code
is ugly - they were just work horse for the purpose of
getting stuff done.
Beyond references to unmodified AT&T copyrighted sources from elsewhere
which were included for documentation where the code
came from, all files may be freely used.
Holger Veit hveit01@web.de 26.7.2022
[-- Attachment #2: Type: text/html, Size: 5684 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-01-18 11:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-01-18 11:33 [TUHS] Re: PCS kernel sources Paul Ruizendaal via TUHS
-- strict thread matches above, loose matches on Subject: below --
2024-01-17 0:20 [TUHS] " Warren Toomey via TUHS
2024-01-17 0:23 ` [TUHS] " Warren Toomey via TUHS
2024-01-17 7:03 ` Veit, Holger via TUHS
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).