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...
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
