[Simh] TOPS-20 Source with KMC11 Driver Code?

[Mark Pizzolato - Info Comm]

Hi Tim,

On Monday, May 27, 2013 at 9:28 AM. Timothe Litt wrote:
> Hopefully, when the KDP is working Rob will merge (and if necessary
> debug) my changes & commit them to fix both problems.  Ideally adding
> the page optimization, but beggars can't be choosers.  If he doesn't
> I'll try to get to that later (if I have commit access to simh on github).

You don't need commit access to the core repository on Github to get your changes submitted and accepted.  The github paradigm is: 
  1) you create a personal account on github.  
  2) you 'clone' the github simh/simh repository to your personal github space.  
  3) you clone either of these to your working environment and do your work and check-in locally as desired/needed.
  4) you configure your local repo to have your personal github repo as the primary push repo and the siimh/simh one as another remote repository.
Steps 2 and 3 can be in any order.
When you are ready to submit your changes, you:
  1) you pull from the simh/simh and merge to the latest codebase
  2) you push your local working repo to your personal github repo
  3) Using the github web UI you create a pull request for the github simh/simh repo.  This pull request will create an issue which will track the details of what will happen.
I'll review the changes and either accept them as is and simply complete the merge or I'll respond with some comments and/or suggestions and you can make revisions until we're both happy and the merge will be completed.  Once the merge completes, each of your commits (with your name) will be part of the repository/history.

If you don't want to climb the learning curve of using git, I'll be glad to take changes which I'd prefer be the complete files of any files you've changed along with a description (as verbose as you may want) of the point of the changes and I'll review and commit these using the description as the commit message.  I'll credit you in the commit comments, but the commit will have my name on it.  If you go down this path, you can send all of the files as separate attachments or preferably bundle them in a zip file and send it via email (there is no problem is you include extra files which you didn't actually change since git will only notice the changed content anyway).

Without regard to climbing the git learning curve, If you create a github account and let me know you've done it, I'll add you as a contributor to the project and assign issues to you where appropriate.  If you create a github account now, and create an issue at https://github.com/simh/simh/issues describing the problems with  Map_WriteW, I'll assign that issue to you and when you ultimately submit fixes, the pull request you create can be the fix to the issue...

> I suppose I should see about building a current version, as I seem to be
> in the middle of debugging several things  by Braille... (Or is this
> simply a memory test for me :-)

Without jumping into git, you can always pickup the latest code at https://github.com/simh/simh/archive/master.zip

I look forward to anything you've got to offer.

Thanks.

- Mark

> This communication may not represent my employer's views,
> if any, on the matters discussed.
> 
> On 27-May-13 11:48, Mark Pizzolato - Info Comm wrote:
> > On Monday, May 27, 2013 at 6:19 AM, Timothe Litt wrote:
> >> This thread is getting far too messy.
> >>
> >> The increment problem found by Rob is NOT subtle.  It's just plain broken.
> > I agree 100%.
> >
> > The code, as written, would write twice as much simulated memory as
> intended which usually would crash things nicely (and did when Rob tried
> with the DMC).
> >
> > I found that the ONLY current use (prior to Rob's DMC) of this routine was
> in the CD11 simulator and that use either might never actually get executed
> (if the CDCSR_V_PACK bit not been set), OR if it was actually executed it
> would have been with the constant byte count of 2 which should have
> written 1 16/18 bit word, but actually wrote 2 due to the bug.  This may have
> never been exercised, OR writing the second word may have merely written
> the high bytes 18 bits of a word which was never referenced by the
> program...
> >
> >> The mishandling of the high bits is what I meant when I wrote 'subtle'.
> > Understood.
> >
>