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

Robert Jarratt robert.jarratt at ntlworld.com
Mon May 27 16:42:41 EDT 2013


Mark,

It is time for me to start learning about git. The bit I am struggling to
understand right now is now to clone your repository to my personal space on
github, can I do this from the web site?

Regards

Rob

> -----Original Message-----
> From: Mark Pizzolato - Info Comm [mailto:Mark at infocomm.com]
> Sent: 27 May 2013 18:34
> To: Timothe Litt; Mark Pizzolato - Info Comm
> Cc: Robert Jarratt; simh at trailing-edge.com
> Subject: RE: [Simh] TOPS-20 Source with KMC11 Driver Code?
> 
> 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.
> > >
> >





More information about the Simh mailing list