SIMH 4.0 Simulator Front Panel API

[Thomas Lake]

Does the new Simulator Front End API in SIMH 4.0 mean that the PiDP-8 could be run with no changes to SIMH?

Tom L

[Dylan McNamee]

Oscar and I traded comments about this (on an earlier thread here) a while back, and the short answer is "not easily".  The front panel API was introduced into SIMH in response to a github feature request of mine, when I was working on a PDP-11 system a lot like the PiDP/8. Unfortunately, the API adds a lot of complexity to integrating with SIMH. Oscar's approach is a lot lighter-weight and simpler to work with. With a few iterations, the frontpanel API could probably be made workable, but since we have Oscar's changes (which move nicely into SIMH 4.0), there's little incentive to do so.

dylan

--

[Obsolescence]

One other variant of simh now also works with the PiDP: Jörg Hoppe made a Blinkenbone server for the PiDP.

It means that the PiDP hardware can be used with his rather cool Blinkenbone simh. That may not provide any immediate benefits, it is more a proof of concept thing.
But - with a modified gpio.c, the PiDP-8 could run his PDP-11 Blinkenbone simulation as well. If you want a PDP-8 front panel to operate a PDP-11 ;) It would still require a little trick to deal with the extra address switches of the 11.

Again, not really useful. But maybe at some point we converge Blinkenbone and pidp8 software.

This is a good opportunity to draw attention to his incredibly beautiful PDP-11 and PDP-10 simulations, also driven by the simh for Blinkenbone. They have a fully operational front panel on your screen. You either click the switches with your mouse (cool) or use a touch screen (breathtaking).
http://retrocmp.com/projects/virtual-pdp-10-ki10-panel-on-simh

On a touch screen it's so good, in fact, that I started doubting whether a physical replica of the PDP-10 was still worth it...

Regards,

Oscar.

[rus...@personaltelco.net]

Sorry to resurrect this old thread, but it seemed like a natural place to ask, as it relates to the divergence:  Can you tell me where in the simh development the pidp8 code forked?

Thanks!

[Tony]

On Saturday, December 24, 2016 at 2:14:42 AM UTC-6, rus...@personaltelco.net wrote:

Can you tell me where in the simh development the pidp8 code forked?

Are you looking for the github commit number?  Or which files were changed? 

 

[Oscar Vermeulen]

Russell,

On 24 December 2016 at 09:14, <rus...@personaltelco.net> wrote:

Sorry to resurrect this old thread, but it seemed like a natural place to ask, as it relates to the divergence:  Can you tell me where in the simh development the pidp8 code forked?

It is embarrassing to say - err, not exactly. I started on simh v3.9, someone kindly wrote a script to move it to v4.0. But the snapshot date of the 4.0 code we grabbed, I don't really know. Which shows I am not a professional developer. OTOH, if you look in my code, that will not be a surprise anyway. I'm more of a plumber than a developer...

Mark Pizzolato, who's driving much of simh development, pointed me to this need to know the exact fork date as well recently. I will have to dig into the archive for it!

OTOH, there's not much in the simh code base relating to the PDP-8 that has changed. One fix was implemented to make Teletypes drive the serial port unbuffered, which makes the front panel lights blink exactly in sync with the Teletype printing characters. Other than that, the only reason to go back (unfork, I guess) to simh's latest release is if you want to use its front panel API instead of the "direct drive" that I wrote for the PiDP front panel. That's  matter of personal preference, I don't see their API as very desirable (lots of overhead) but Warren feels there would be merit in going that way (unforking).

Warren, you agree?

Kind regards,

Oscar.

Thanks!

On Sunday, January 24, 2016 at 11:52:21 AM UTC-8, Obsolescence wrote:

One other variant of simh now also works with the PiDP: Jörg Hoppe made a Blinkenbone server for the PiDP.

It means that the PiDP hardware can be used with his rather cool Blinkenbone simh. That may not provide any immediate benefits, it is more a proof of concept thing.
But - with a modified gpio.c, the PiDP-8 could run his PDP-11 Blinkenbone simulation as well. If you want a PDP-8 front panel to operate a PDP-11 ;) It would still require a little trick to deal with the extra address switches of the 11.

Again, not really useful. But maybe at some point we converge Blinkenbone and pidp8 software.

This is a good opportunity to draw attention to his incredibly beautiful PDP-11 and PDP-10 simulations, also driven by the simh for Blinkenbone. They have a fully operational front panel on your screen. You either click the switches with your mouse (cool) or use a touch screen (breathtaking).
http://retrocmp.com/projects/virtual-pdp-10-ki10-panel-on-simh

On a touch screen it's so good, in fact, that I started doubting whether a physical replica of the PDP-10 was still worth it...

Regards,

Oscar.

--
You received this message because you are subscribed to the Google Groups "PiDP-8" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/0f0e6052-4d3d-46ee-bdc2-7485dc6643ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Warren Young]

On Saturday, December 24, 2016 at 1:14:42 AM UTC-7, russell wrote:

Can you tell me where in the simh development the pidp8 code forked?

As best as I've been able to tell, sometime before July 25, 2015, based on mailing list traffic. I have not chased it down to a particular Git commit ID yet.

If you want to do that, it would be helpful, as I could then produce a clean diff of the current software against that version of SIMH, which would then enable me to reverse the diffs, then upgrade SIMH and reapply the diffs. 

[Tony]

On Saturday, December 24, 2016 at 10:28:58 AM UTC-6, Warren Young wrote:

As best as I've been able to tell, sometime before July 25, 2015, based on mailing list traffic. I have not chased it down to a particular Git commit ID yet.

If you want to do that, it would be helpful, as I could then produce a clean diff of the current software against that version of SIMH, which would then enable me to reverse the diffs, then upgrade SIMH and reapply the diffs. 

Looking at the commit log in that time window shows :

commit 7c7b44e409f05751c960a614dbb1e2abde22da60 @markpizz markpizz committed on Aug 3, 2015

commit a747c0f86058c22b20ad12f948ff3481cf99cdd4 @markpizz markpizz committed on Jul 8, 2015

commit d69b34e4102923e462c6f462c2540e725d5d0907 @markpizz markpizz committed on Jun 30, 2015

The Jun 30th changes show up in the PiDP-8 source.   The Aug 3rd changes do not.  

The changes made on July 8th were only to the VAX code and so I can't tell about that one.

In any case,  it looks like the Jun 30, 2015 commit would have been the one Oscar used.

Tony

 

[Warren Young]

On Saturday, December 24, 2016 at 9:25:22 AM UTC-7, Obsolescence wrote:
> Russell,

>
>
>
>
>, the only reason to go back (unfork, I guess) to simh's latest release is if you want to use its front panel API

There is at least one improvement in current SIMH code that I want, which is that they fixed SET THROTTLE to work at very slow speeds, which would help with 5.script.

>, I don't see their API as very desirable (lots of overhead)

If the overhead doesn't noticeably hurt performance and buys us easier upgrades, it's worth it. It also has design value, in decoupling the PiDP-8/I code from the stock SIMH code.

One wonders what other improvements they've made in the past year and a half that we don't enjoy?

.
>
>
>
>
>
>
> --
>
> You received this message because you are subscribed to the Google Groups "PiDP-8" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+un...@googlegroups.com.

[Warren Young]

Thanks for chasing that down, Tony!

[Tony]

On Saturday, December 24, 2016 at 11:39:29 AM UTC-6, Warren Young wrote:

One wonders what other improvements they've made in the past year and a half that we don't enjoy?

Doing a diff on the PiDP-8 source vs a June 30 2015 git clone is a bit messy as most of the files differ due to ^M line endings.   

What I did was a

git clone https://github.com/simh/simh.git simh

cd simh

git reset --hard d69b34e4102923e462c6f462c2540e725d5d0907

Then I copied all of the PiDP-8 files over top of the cloned original files.

A  git status   told me which new files to manually add via a  git add

Finally,   

git diff  --ignore-all-space d69b34e4102923e462c6f462c2540e725d5d0907 > pidp8.diff

 

gets me a what looks like a pretty good patch file (attached).

I did a diff on the patch file for  "diff -get" to see what files were touched.  It looks like  :

• PDP8/pdp8_cpu.c
  
• PDP8/pdp8_cpu.c.in
  
• config.h
  
• gpio-nls.c
  
• gpio-nls.h
  
• gpio.c
  
• gpio.h
  
• scanswitch.c
  
• scp.c
  
• scp.c.in
  
• scp.h
  
• sim_console.c
  
• sim_defs.h
  
• sim_timer.h
  
• sim_tmxr.c
  
• test.c
  

I guess the next step is to apply that against the current HEAD of the git repository and see what happens.

Tony

edit 1 :  I probably should repeat this process using Warren's most recent code ?

edit 2 :  In trying to apply the patch file to the HEAD, it looks like cleaning up the line endings in the PiDP-8 source before doing all the patchings and diffs might be a good idea after all

edit 3 :  updated patch file attached - I sorted out the ^M stuff so that it applies cleanly to a fresh clone of the June 30 code.  Patching the current HEAD is going to be quite a bit of work though.

 

[Tony]

Well, using the attached patch file,  I was able to clone the git simh code from June 30 2015,  patch it,  move the resulting code to the pidpi8i src & src/PDP8 directories, and rebuild the PiDP-8 simulator.  Testing the result indicates that it all seems to run as expected.

The patch file was created from Warren Young's most recent code (extracted via fossil) so unless I'm very much mistaken (which happens a lot),  the attached patch file represents the current state of the PiDP-8i code relative to the June 30th 2015 git commit.

Applying the patch to the current git HEAD will be a bit of work - a simple    patch -p0 < pidp8.diff    generates a lot of reject files that will have to be waded through one by one.

Tony

[Warren Young]

Wonderful!

I won't be able to apply it for some time yet, as I'm tied up with family stuff, but I'm considering this my a Christmas gift.

Thank you!

[Tony]

On Saturday, December 24, 2016 at 8:26:48 PM UTC-6, Warren Young wrote:

Wonderful! I won't be able to apply it for some time yet, as I'm tied up with family stuff, but I'm considering this my a Christmas gift. Thank you!

I think this is kind of "step 1".  Now that there is a working patch file for the original git clone, figuring out how to apply that against the current trunk (18 months later) will be a bit of work.  And some testing. I'll fiddle away at it over the next few days.  Better than the family Christmas jigsaw puzzle quite frankly.

If/when that works, it should leave "current" simh code running the PiDP-8.  Updating your Fossil repo should be fairly easy (famous last words) at that point - just move the current simh (patched) files over and fix anything that breaks as a result.  Keeping them sync'd might be a challenge but should not be too bad if another 18 months does not elapse between merges.

Tony

 

[Russell Senior]

On Sat, Dec 24, 2016 at 9:58 AM, Tony <hill.a...@gmail.com> wrote:
> On Saturday, December 24, 2016 at 11:39:29 AM UTC-6, Warren Young wrote:
>>
>> One wonders what other improvements they've made in the past year and a
>> half that we don't enjoy?
>
>
> Doing a diff on the PiDP-8 source vs a June 30 2015 git clone is a bit messy
> as most of the files differ due to ^M line endings.
>
> What I did was a
>
> git clone https://github.com/simh/simh.git simh
> cd simh
> git reset --hard d69b34e4102923e462c6f462c2540e725d5d0907

I don't think you want the reset --hard, better I think would be to
just checkout that commit, e.g.

git checkout d69b34e4102923e462c6f462c2540e725d5d0907

(see: https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations)

and then create a branch, e.g.:

git checkout -b pidp8

apply your changes and commit to the new branch.

Fwiw, I did a search of commits, using a metric of line count in the
diff in the PDP8 subdirectory. I found that I hit the minimum in the
window between simh commits: 80321577f9a2d6b91792a7c3aa2d175765819926
and 41978eca8091ab7618516b0abb2d0044f46a5579 (roughly mid-march to
early april, 2015). I did something like this:

git clone https://github.com/simh/simh.git
cd simh
git checkout -b fork-search
rm -rf *
tar xzvf ../pidp8-20151215.tar.gz pidp8/src
mv pidp8/src/* .
rm -rf pidp8
git commit -a -m 'pidp8 fork'
FORKHASH=$(git rev-parse HEAD)
git checkout master
while true ; do echo $(git describe) $(git diff $FORKHASH PDP8 | wc
-l) ; if ! git checkout HEAD^ ; then break ; fi ; done >
/tmp/pidp8-simh-pdp8-divergence.txt

and then I inspected /tmp/pidp8-simh-pdp8-divergence.txt for the
minimum number of lines in the diff (651 lines). Admittedly a rough
metric. The limit to the PDP8 directory was mostly to avoid noise
from churn in uninteresting parts of the tree.

[Tony]

On Saturday, December 24, 2016 at 9:27:06 PM UTC-6, Russell Senior wrote:

I don't think you want the reset --hard, better I think would be to
just checkout that commit, e.g.

  git checkout d69b34e4102923e462c6f462c2540e725d5d0907

(see: https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations)

and then create a branch, e.g.:

  git checkout -b pidp8

apply your changes and commit to the new branch.

Thanks - I'm hardly a git guru.  Version control systems all start to look the same after a while - you just have to play until you sort of get what you want.

 

Fwiw, I did a search of commits, using a metric of line count in the

diff in the PDP8 subdirectory.  I found that I ...

  <snip>

.... limit to the PDP8 directory was mostly to avoid noise

from churn in uninteresting parts of the tree.

 

Per one of my previous posts,  I think I have the actual commit number figured out based on checking for changes that are either in the code or not there yet.  But I'll double check.

Meanwhile, bringing this up to date really comes down to two files with substantial edits - PDP/pdp8_cpu.c  and scp.c.  There are a few other minor tweaks but those two are going to take a hand edit using a graphical diff tool to merge.  At least for me.

Meanwhile,  I found a weakness in my patch file - Oscar used templates to abstract directory paths (I think that's what it's called) so that needs to get adapted too.

Tony

[Russell Senior]

> Per one of my previous posts, I think I have the actual commit number
> figured out based on checking for changes that are either in the code or not
> there yet. But I'll double check.

I trust your human checking more than my coarse metric. I was/am
secretly hoping that git actually knows how to estimate/discover fork
points in a better way than my first-cut wack at it, as I have this
kind of problem in other contexts too.

Russell

[Warren Young]

On Saturday, December 24, 2016 at 8:13:36 PM UTC-7, Tony wrote:

Keeping them sync'd might be a challenge but should not be too bad if another 18 months does not elapse between merges.

I think the most important thing we can do to make SIMH merges easier — at least, until we factor the PiDP-8/I specific bits out via the SIMH front-panel API — is record the upstream Git checkin ID each time we merge with the upstream software. The biggest part of this present effort was just finding the point in the upstream tree where our current software branched.

After that, it's basically a mechanical effort. It's probably even scriptable without heroic efforts.

[Warren Young]

On Saturday, December 24, 2016 at 9:14:33 PM UTC-7, Tony wrote:

Version control systems all start to look the same after a while

I think you'll find Fossil a lot easier to master than Git. Nearly every action available in Fossil is harder to do in Git, and often has odd consequences besides.

About the only thing Git makes easier is the initial clone-and-checkout process, which is only something you want to optimize for if you view your primary audience as non-participants in the development process. ...Which works out fine for all those people cloning GitHub repos.

GitHub papers over a bunch of Git proper's weaknesses, but then you're tying yourself to a proprietary service. SourceForge and Google Code didn't work out too well for the development community in the long run...

 

Oscar used templates to abstract directory paths

Actually, that's my work. It's part of the new build system. If you look at the upstream code (or check out the v20151205 tag from my repo; same thing) you will see that in Oscar's code, all of those instances were hardcoded paths, which is why everything had to be done in /opt/pidp8 before.

So, you want to be diffiing src/scp.c.in in my repo against src/scp.c in the upstream SIMH repository. Ditto for src/PDP8/pdp8_cpu.c.in.

(I think that's what it's called)

Yes, autosetup calls the foo.in files the template which it uses to generate foo.

[Russell Senior]

>> Version control systems all start to look the same after a while

> I think you'll find Fossil a lot easier to master than Git. Nearly every
> action available in Fossil is harder to do in Git, and often has odd
> consequences besides.

I don't want to start a flame war, but frankly, I'd never heard of
fossil before. Git probably has at least 100x the mindshare, and I
don't personally relish learning yet another one. And nothing about
git ties you to github, there are other hosting services and you can
host it yourself if you want/need to.

Happy holidays ;-)

--
Russell

[Tony]

On Saturday, December 24, 2016 at 11:52:54 PM UTC-6, Warren Young wrote:

Actually, that's my work. It's part of the new build system. If you look at the upstream code (or check out the v20151205 tag from my repo; same thing) you will see that in Oscar's code, all of those instances were hardcoded paths, which is why everything had to be done in /opt/pidp8 before.   

So, you want to be diffiing src/scp.c.in in my repo against src/scp.c in the upstream SIMH repository. Ditto for src/PDP8/pdp8_cpu.c.in.

Thanks - that makes sense now.  I'd figured out the need to compare the .c.in file to the .c file from the git repository.  Now I understand how that happened. 

I guess this porting exercise can be considered a good way to learn the internal of the project.

[Warren Young]

On Saturday, December 24, 2016 at 11:42:20 PM UTC-7, Russell Senior wrote:

I don't want to start a flame war, but frankly, I'd never heard of
fossil before.  Git probably has at least 100x the mindshare, and I
don't personally relish learning yet another one.

The thing about Git is, it is popular because it is popular, not because it is especially meritorious, compared to other DVCSes. It's basically an accident of history.

But, if you really want Git, you can easily get it with:

   

  git init pidp8i-git

  cd pidp8i-git

  fossil export ~/museum/pidp8i.fossil | git fast-import

  git checkout trunk

You will need to sync up to the latest version of my Fossil repo before that will work, because Git can't cope with the same tag on multiple checkins; I've gone in and removed all the extras to make Git happy.

For what it's worth, I reuse a tag in Fossil when I have to re-release a version under the same tag for some reason. Fossil doesn't care about duplicate tags because when you refer to a tag, it always means "the newest release with this tag." I guess with Git I'd have to append a different letter to each tag to get the same effect.

 

And nothing about git ties you to github

I didn't mean to imply that it did. But, GitHub does fix a lot of Git problems, and when you get into these...discussions, people always ascribe GitHub features (or some other nice front end) as Git features.

The point is, you get much of what GitHub gives you out of the box with Fossil. (Nice web UI, timeline view, ticket tracker, wiki, Markdown rendering...) 

[Tony]

Two steps forward, one step back. I goofed up the date of the git clone pull.  

The correct commit number is actually 389c08a81e5ffbfa428cbb966a94564fd83b5eb6

The change shown below is in the PiPD-8 and PiDP-8i source.

git blame scp.c -L1060,1060

389c08a8 (Mark Pizzolato 2015-09-21 12:13:36 -0700 1060)       "+set remote NOMASTER         disable remote master mode console\n"

There are subsequent commits that don't affect the PiDP-8 source up until

git blame scp.c -L1761,1761

4921d926 (Mark Pizzolato 2015-09-27 16:14:55 -0700 1761)       " +SCREENSHOT screenshotfile\n\n"

That change is not in either the PiDP-8 or PiDP-8i code.

So from what I can now tell (having learned a lot more about using git than I originally intended to),  the PiDP-8 clone was in fact pulled after Sept 21,2015. This is later than Warren had suggested from looking at the mailing list traffic but the "smoking gun" is there in the code.  Sorry for any confusion.

Tony

edit :  It's never easy.  It looks like Warren added some of the source files pruned in the original PiDP-8 build ( sim_video.c & sim_video.h for example ) and those are pulled from a commit prior to Sept 21.  

[Warren Young]

On Sunday, December 25, 2016 at 11:35:43 AM UTC-7, Tony wrote:

The change shown below is in the PiPD-8 and PiDP-8i source.

Hm, interesting. I thought I found the last post to the mailing list where the SIMH 4.0 update was posted, but apparently that was just a prelude to the final patch.

 

It looks like Warren added some of the source files pruned in the original PiDP-8 build ( sim_video.c & sim_video.h for example ) and those are pulled from a commit prior to Sept 21.  

You've got to be looking at the wrong thing. Here is the current contents of src:

   https://tangentsoft.com/pidp8i/dir?ci=trunk&name=src

No sim_video.[ch].

I went and audited the entire contents of src, and every file checked into the current trunk is in fact needed to build the software.

That is not to say that some of those files cannot be removed and still get a functioning build, but you'd have to remove one of the obj/*/*.o lines from the OBJS definition in Makefile.in to do it. I did not audit the build to that level.

[Tony]

On Monday, December 26, 2016 at 2:04:25 AM UTC-6, Warren Young wrote:

You've got to be looking at the wrong thing. 

My bad.  Issue resolved and it had nothing to do with you. Sorry.