With the successful restoration of Unix V1, I was thinking of other
operating systems that could be restored in a similar way. The most
historically significant would probably be CTSS. The SIMH IBM 7094
simulator has everything necessary to run CTSS implemented already,
although the CTSS-specific stuff is untested (since as far as I know,
nobody has booted CTSS in it yet) and may need some patching.
There are several tapes of listings (for almost all of the system), and
a few tapes of binaries (one with supervisor binaries, and one with
"standalone" utilities, but nothing with user-mode programs) available.
The listings need to be converted back into source that can be assembled
or compiled. Part of this can be done automatically (I have written some
dumb scripts to do this), but there will likely be quite a bit of manual
editing involved. There is nothing to be OCRed, since everything is on
magtapes.
Most of the source is either assembly or MAD (an Algol-58 dialect), with
a few files in AED (another Algol dialect, for which no compiler appears
to have survived). Restoring the assembler stuff should be easy (there
exists a cross-assembler which would work), but restoring the MAD stuff
will be a little bit harder. There is no cross-compiler for it (there is
a compiler that runs under IBSYS, but it is probably just for an IBSYS
target, and I'm not sure if anyone has even figured out how to run it).
The AED stuff will have to be rewritten in MAD (which shouldn't be
especially hard, since AED and MAD are somewhat similar). Only a few
non-essential programs are written in AED.
I think that all (or at least most of) the stuff required for booting is
written in assembler, so the best way to get it working would be get a
minimal system booting (I suspect all that is necessary is the
supervisor, so the binaries on the tape might be of use), and run the
CTSS MAD compiler under it to compile all the MAD stuff (which includes
many of the "core" commands).
I'm not sure what the best way to get stuff into a filesystem is. The
standalone utilities run under FMS, and there is no bootable FMS tape.
There is a version of FMS that runs under IBSYS, but for some reason, it
returns an error when attempting to load the utilities off the tape.
It is probably possible to patch it to fix that bug, though. It would
also work to write utilities that run on the host system, much like what
was done for Unix V1 (although I think that fixing the bug in FMS would
probably be easier).
Maybe I should start a Sourceforge project.
Another, much simpler, system which might be possible to restore is
MUMPS-15, for which a PDF of a paper listing is available on bitsavers.
Restoring it would probably just be a matter of OCRing, correcting, and
assembling it (and maybe writing a bootstrap).
Hi,
while creating a web-page about the open questions of how to create C
code which compiles through the optimizer run to the same ASM code as the
original object was made from, I found the fix for one of my two "top"
questions.
The (right now) remaining question is here:
http://pofo.de/P8000/problems.php
The other (solved) problem was:
I had the following ASM code:
ldk r2,#0
ldb rl2,_u+1060
ld r3,r2
neg r3
add r3,#256
ldb rh3,rl3
clrb rl3
ld _u+48,r3
so i created the following C code out of it:
u.u_count = (-u.u_segmts[NUSEGS-1].sg_limit+0x100)<<8;
but this compiled to this ASM code:
ldk r2,#0
ldb rl2,_u+1060
neg r2
add r2,#256
ldb rh2,rl2
clrb rl2
ld _u+48,r2
As you can see the copy of r2 to r3 and the further processing with r3 is
missing here. I also thought "who the fuck would write such an C-code,
the code must look different". but I did not found the solution what
could have been written in the C code until I've talked today with a
colleague of mine at work about ASM and my problems. He isn't familar
with Z80(00)-ASM but he used to program ASM years ago with his C64. We
took the ASM code and simulated it with values:
_u+1060 contains 15 and is loaded to rl2 15 (0x000F / 00000000 00001111)
this gets negated (2 complement formed) -15 (0xFFF1 / 11111111 11110001)
to that, 256 gets added 241 (0x00F1 / 00000000 11110001)
this is 8 bit rightshiftet 61696 (0xF100 / 11110001 00000000)
the result gets loaded into _u+48
He then got the idea that all this could be aritmetical written
as ((256 - 15)*256) because -15+256 is == 256-15 and rightshifts are done
aritmetically by multiplying the value with 256. It could have also been
done by having 256² - 256*x. This was great. With that information I wrote
in C:
u.u_count = (256-u.u_segmts[NUSEGS-1].sg_limit)<<8;
And this generated the same ASM code as in the original code
problem solved :)
--
Oliver Lehmann
http://www.pofo.de/http://wishlist.ans-netz.de/
Hi everybody,
I don't know if it's usual or not to write an introduction but I'll just
do so by keeping more an eye on the computer system I own.
If you don't care just skip this mail ;)
As my From header states my name is Oliver, I live in germany and right
now I'm 27 years old. That should be enough to my person - now let me
tell you a bit more about the computer system I own ;)
EAW P8000
This system was built between 1987 and the breakdown of the former GDR -
the eastern part of germany - 1990. The system itself is split up into
two "towers" connected together. The first tower called "P8000 Computer"
contains a 8Bit system (Z80) and a 16Bit system (Z8001).The 2nd case -
the "P8000 Winchester" - contains a Winchester Disc Controller which runs
with a Z80 CPU and is connected to the 16Bit part of the "P8000
Computer". Up to three MFM drives (all with the same geometry while the
geometry itself can be configured) can be connected to the WDC.
The 8Bit part is built on a single board, has 64KB SRAM, 2 SIOs to
connect up to 4 terminals to it, one PIO to connect a EPROM programmer,
and one PIO to establish a connection to the 16Bit part. It has 2 5.25"
floppy drives with an external connector to connect two further 5.25" or
8" floppy drives. The systemmonitor is loaded from two 2732 EPROMs.
The system originally supported three operating systems while two
survived the time being. I own UDOS which is a Z80-RIO clone and OS/M
which is a CP/M clone. There also was an OS called IS/M which was an ISIS
clone.
The more interesting (at least for me) part is the 16Bit part. The 16Bit
part is built on a single board too (6layer) while the DRAM are single
board which can be hooked up onto the mainboard.
The system runs a Z8001 with 3 MMUs and Z80-peripherial ICs (PIO, SIO...)
It also has 2 SIOs for 4 terminal connections, and one PIO to connect the
WDC. The system also has two furhter PIO chips to establish a connection
to the 8Bit system. The system runs with up to 4MB of DRAM but it might
run with more RAM with self-made RAM modules. There exists also a RTC for
the system and an extension to connect an 80286CPU + 1MBRAM to the 16BIT
port to run a x86 OS on it while stearing it from the OS running on the
16Bit system.
The Operating-System running on the 16Bit part is WEGA - a ZiLOG ZEUS
clone.
To boot WEGA at first the 8Bit system has to be booted up with UDOS (the
Z80-RIO clone) to load a communication software which handles the
communication over the 8Bit-PIO. After this is done the system switches
over to the 16Bit system and the system monitor there gets loaded. The
WEGA-Kernel (most parts are still original ZEUS objects) itself has the
corresponding part for the 8<->16Bit communication interface in it.
This was done to get access to the floppy drives, the EPROM programmer
and the 4 8Bit-terminal connections which are all connected to the Z80
on the 8Bit-system.
To access for example a floppy, the WEGA-kernel has to send the request
using the PIO connection to the 8Bit system which handles it and sends
the results back to the WEGA-kernel on the 16 Bit system. Same goes with
the WDC which is connected through another PIO directly to the 16Bit
system - command codes are sent to the Z80 on the WDC which handles the
codes and sends the results back to the 16Bit system. Not that fast but
it works good.
Pictures and so one are all collected on my homepage
http://pofo.de/P8000/ while most (if not to say all) of original
documents are written in german...
So - what do I do with the system? I use it for learn more about hardware
processes itself, assembler and to get a deeper UNIX knowledge which is
easier to start with there then with todays UNIX systems.
Las project was to get TCP/IP working and I successed by usingg K5JB to
get FTP and ping to work via SLIP. Because the speed was damn slow (and
not just because of the baud rate), I came to the conclusion that a
better performance could be achieved by implementing TCP/IP in the
kernelspace instead of having it run in the userspace.
So my goal is now to get the kernel sources right now to make the
neccessary changes to get TCP/IP running in the kernel. As you might
think now this is not so easy as it sounds. The sources for some objects
of the kernel survied over the time, but many are missing. I'm now
sitting here since a month disassembling the original kernel object and
writing the disassembled code back in C. I've started this by having lets
say nearly-to-zero ASM knowldege and I'm making good progress. Not much
is left, but from time to time the C files are not compiling to
exactly the same object which is in the kernel. Some times other
temporary registers are used for operations, or I can't get to the same C
code doesn't matter of what I'm trying and so on. I'm trying to get 100%
the same object to be 100% sure I have the same code the object was built
with. The compiler on that system should be the same but of course I
can't guarantee that for sure.
I'll put a web page together with my open C<->ASM questions because I
think I can format things better there so asking and reading would be
easier (probably because it is a lot of text)
My progess can be seen here: http://pofo.de/P8000/kernel.php
And the sources I got so far are here:
http://cvs.laladev.org/index.html/WEGA/src/uts/
I hope you can help me a bit with answering the things I can't find an
answer myself ;)
--
Oliver Lehmann
http://www.pofo.de/http://wishlist.ans-netz.de/
Working with the 1st Edition UNIX code has been a blast. I just thought I'd
quickly summarise the features of the 1st Edition. It's quite amazing the
system that had been written by the end of 1971:
- a multitasking system with up to 16 processes
- multiple users
- a hierachical filesystem, with empty directories used as mountpoints
- read/write file protection for user/other (no group), plus the
execute and set-userid bits
- i-nodes, and filenames separated from i-nodes, allowing hard links
- device files
Just as interesting is the fact that, out of the 33 system calls in 1st
Edition UNIX, only one has disappeared completely from modern UNIXes;
four have merged into signal(), and a few have morphed into other syscalls:
V1_RELE 0 /* release the CPU, i.e. pre-empt this process */
V1_EXIT 1 exit()
V1_FORK 2 fork()
V1_READ 3 read()
V1_WRITE 4 write()
V1_OPEN 5 open()
V1_CLOSE 6 close()
V1_WAIT 7 wait()
V1_CREAT 8 open(path, O_CREAT | O_TRUNC | O_WRONLY, mode);
V1_LINK 9 link()
V1_UNLINK 10 unlink()
V1_EXEC 11 exec()
V1_CHDIR 12 chdir()
V1_TIME 13 gettimeofday()
V1_MKDIR 14 mkdir()
V1_CHMOD 15 chmod()
V1_CHOWN 16 chown()
V1_BREAK 17 brk()
V1_STAT 18 stat()
V1_SEEK 19 lseek()
V1_TELL 20 lseek(fd, 0, SEEK_CUR);
V1_MOUNT 21 mount()
V1_UMOUNT 22 umount()
V1_SETUID 23 setuid()
V1_GETUID 24 getuid()
V1_STIME 25 settimeofday()
V1_QUIT 26 signal(SIGQUIT,...)
V1_INTR 27 signal(SIGINT,...)
V1_FSTAT 28 fstat()
V1_CEMT 29 signal(SIGEMT,...)
V1_SMDATE 30 utimes()
V1_STTY 31 fcntl(), tcsetattr()
V1_GTTY 32 fcntl(), tcgetattr()
V1_ILGINS 33 signal(SIGILL,...)
The fact that we are still using these system calls today speaks volumes
for the original design.
Cheers,
Warren
Seen in a .sig:
Unix is the answer, but only if you phrase the question very carefully.
--
Milo Velimirović
University of Wisconsin - La Crosse
La Crosse, Wisconsin 54601 USA 43 48 48 N 91 13 53 W
> Date: Thu, 22 May 2008 18:10:33 +0200
> From: "Jose R. Valverde" <jrvalverde(a)acm.org>
> Subject: Re: [TUHS] V8 - V10
>
> Solaris has been open sourced and is heavily System V based. Novell
> argues now SCO was not entitled to, and so the Sun-SCO agreement that made it
> possible is probably void.
>
> [...]
> There remains the issue of the flow of SystemV licenses money to Novell
> after and if it is open sourced... I don't know how much that is, nor how much
> it might be 4-10 years from now when the SCO appeals are heard. So my evaluation
> is probably faulty.
I concur with your opinion.
If Novell could not get paid from The SCO Group of the percentage (about
90%) they are entitled to of the SVRX License Payment SUN made to The SCO
Group, and of the SVRX License Payment Microsoft made to The SCO Group
(because, you know, The SCO Group has filled for bankruptcy), then they are
probably going to action on the basis of said Licenses being void, or at
least in being void the part of such Licenses that allows to Sub-license
the material changing the terms of the License, or changing the License
altogether. According to this hypothesis on the future, in case The SCO
Group cannot find the money to pay Novell, Novell will probably try to
renegotiate such Licenses directly with SUN and Microsoft. Microsoft
will probably just return the material instead of paying for it (as they
don't need it), but SUN is in a totally different position.
SUN has now OpenSolaris, which was made possible by that License they got
from The SCO Group. So SUN will renegotiate and pay Novell to legalize
the SVRX License they got from The SCO Group which allowed them to
"open-source" Solaris.
Only after Novell gets that payment(s), either from The SCO Group or
SUN, will they consider "open-sourcing" the historical SVRX and
classical UNIX code. Otherwise, they could hardly monetize on it, as
they currently have the opportunity to do.
Regards,
--
Pepe
pepe(a)naleco.com
> From: Aharon Robbins <arnold(a)skeeve.com>
>
> Is the SCO "stuff" settled enough that DMR can release V8 - V10 to TUHS?
It seems clear, now, that the copyright on that is Novell's, and that
The SCO Group *never* had the copyright for that transferred to them by
Novell, and that therefore the "open-sourcing" of that material done by
Caldera is void because Caldera was lacking just title to do such
re-licensing.
Therefore, you can legally release it to TUHS, provided you have a license or
permission from Novell to do so.
You could always release it anyway, and hope for the best, but then you
are on your own and betting for your luck. Anything could happen, but it
is unknown.
--
Pepe
pepe(a)naleco.com
