[Simh] OS development

[Timothe Litt]

On 10-Jun-15 17:04, Kevin Handy wrote:
> Reading through the copyright discussion, I started wondering why
> noone  has started a development project for the ols OS's like tops-10
> and tops-20 as well as others where the original sources are available.
> It seems like there are a lot of patches being passed around, and new
> code to work in the internet environment, but it's not coordinated.
> It seems like a user project to create a new version that works on the
> simulators and actual hardware would be beneficial to many. Collecting
> all the patches and updates together.
> Would there be legal problems in doing this, 8-bitness of
> giy/subversion,  too much missing code, or other problems?
> Just curious.
>
I have thought about this for TOPS-10/20 in particular, but it requires
a good deal of time to set up.  I have quite a few things ahead of it on
my list.

There are a few bugs where the OS is broken on real hardware.  These
fixes should be distributed.

Most anything that works on actual hardware, but not the simulator is a
simulator bug.  (Or missing feature.)  There are a few cases where an OS
patch helps the simulator, such as CPU idle detection.  But those are
intentionally few and far between.

There are some cases where extending the OS to understand new things is
useful.  E.g. TCP/IP for TOPS-10, or the card punch I devised for the KS
that never existed in hardware, but allows GALAXY to punch cards as it
would on a KA/KI/KL.

For TOPS-10, I still haven't recovered the earliest preserved sources -
which is what one would want to start a repository with.  The media is
with CHM, but at last check, hasn't been read in.  Once it is, I have to
do some sorting before it's published.  My concept has been to start a
github repository for each OS with branches for each released
version.    I have signed-out https://github.com/DEC36 for this
purpose.  I have some unpublished MCOs for TOPS-10 that will help. 
Similarly for TOPS-20, though that takes even more effort in the SimH
context due to the fate of KS support and the way the system fileystems
were laid out. 

There are quite a few Y2K divots to tackle.  One tricky issue is DAP, as
that's cross-OS. (And now there's VMSSOFTWARE (the company) to
consider.)  In general, some thought needs to be given to what
categories of change are acceptable, and where.  The main thrust of the
simulator effort has been preserving history.  So there may be different
branches for "last DEC release + bug fixes", "last DEC release +
completing unfinished or internal use but never released work" (e.g. my
unfinished KS10 ethernet driver), and "new features/extensions". 

I don't foresee any major issues with putting sources in git.  They're
7-bit ASCII (and there is no 8th bit to cause confusion.)  I don't think
any development sources have line numbers (which used bit 35); if some
turn up, nothing would be lost by removing them.  They're <CR><LF> line
endings, with <FF> and 8-col hardware <TAB>s.  There may be <NUL>s,
especially at EOF.  So long as they're not edited in non-native
environments into 8-bit (or unicode) format, they should be fine. 
Getting sources into and out of the simulator will be easier when I
finish rewriting the POSIX version of backup...

Tape and disk images (e.g. for bootable/install tapes and pre-configured
systems) would be better hosted elsewhere, e.g. trailing-edge or
bitsavers.  That would be the way to distribute binaries.

Legally - so far as I know, the rights to TOPS10/20 belong to HP.  Which
part of HP gets them in the upcoming split is unknown.  Logically it
would be HP Enterprise, but logic requires knowledge and knowledge of
36-bits is in short supply at HP.  The DEC archives at CHM include the
36-bit engineering environments; I promised to sort through them and
determine what can be released.  [Things like personal e-mails in the
system backups can't be.]  (Also, HP has sold off a lot of DEC's IP. 
It's possible that HP sold some or all of the 36-bit technology.)

The simulator community uses TOPS-10/20 under the terms of the hobbyist
license that Dick Greeley & I arranged while DEC was still in
existence.  A user-driven project could not expand the terms of that
license, nor do I think it wise to draw HP's attention to it.  However,
distributing patches/improvements for use under the existing license
would seem OK to me.  I would want to be careful about any user
copyright/license text in such additions to be sure that they don't
appear to conflict with the DEC license.  (I'm not a lawyer and do not
represent HP.)

As an interim solution, I have created
https://github.com/dec36.patches.  If people care to provide their
patches (clone the repo and submit pull requests), it can serve as a
distribution point until I get to a more complete solution.  I probably
won't do much review.

At this point, I think FILCOM (/O) or SOUP/SOUPR against unmodified DEC
sources are the best formats.  That way I don't have to deal with
setting up the full repo structure.

As for other OSs - I'm not taking those on...


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4942 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20150610/e18762d1/attachment.bin>