Plans for a new release?

[Heinz-Bernd Eggenstein]

I was wondering: If I see this correctly, the current SDcard image for PiDP-8i form here https://tangentsoft.com/pidp8i/wiki?name=Home is based on Raspbian Buster, which will stop to receive security updates in a few days (end of this month, I think?) . Yes, I know, the "S" in IoT stands for security, but still...

Are there plans for an updated release? We now have everything needed to support both "Bookworm" (as an execution and  build platform) and even Raspberry Pi 5 support in the fossil repo in experimental branches, but I guess to get out a new image by the end of this month, some testing with a release candidate would be called for.

Any plans so far?

Cheers

HB

 

[Mike Katz]

All of my sd cards were made with bookworm.  Should I be testing on a prior version of the OS.

I agree with HB, maybe it's time to bring the default SD card image up to the latest OS and include information on how to build for the Pi 4 and Pi 5.  I will need those Pi 4 and Pi 5 instructions for my tests.

Thank you.

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/b7e960e0-7569-4990-8958-6318351b850dn%40googlegroups.com.

[William Cattey]

I think I'm the de-facto autarch for the next release.

I'd definitely like to get the pinctrl gpio support in.

I'd very much like the improved Incandescent LED support.

How much time would it take to get the cycle-accurate support in?

Sounds like a 32bit image is the right thing for most users.

If we build on Bookworm will it still run on Buster?

-Bill

[Heinz-Bernd Eggenstein]

Hi!

> I'd definitely like to get the pinctrl gpio support in.

>I'd very much like the improved Incandescent LED support.

>How much time would it take to get the cycle-accurate support in?

Someone needs to merge the merge the cycle realistic code into the pi5-ils2-bookworm branch.

I have done that locally before for my own tests, its not trivial but not rocket science either. 

I have visitors to entertain this weekend, but could do that with the latest code early next week. 

If someone else wants to do that earlier, feel free to beat me to it.

>If we build on Bookworm will it still run on Buster?

Good question, needs to be tested.

Cheers

HB

[William Cattey]

I can try a merge tomorrow. 

Any chance you could send a diff -u of what you have to me?

-Bill 

You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/aFc3mJ1Gufs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/48029c25-7874-452e-9a5e-355e6716850en%40googlegroups.com.

[Bill Cattey]

I was saying that I'd take a stab at a merge today but then I realized:

1. I don't actually have a bookwork setup at the moment. I'm still on Buster.
2. I'd rather not re-discover what HB learned as he did the integration once already.

HB,

How come you don't just make a branch off of the pi5-ils2-bookworm branch with what you have?

Then various of us can pull it in and test with it, and discuss how things should evolve from there.

We should firm up our common understanding of the critera for acceptance into trunk. Here are my thoughts:

pinctrl: 

That should go into trunk as soon as we have confirmed that we've got a clean build that works on all existing platforms, and provides the unified Pi Zero to Pi Five single-image baseline.

There's been a bit of back and forth about what kinds of "for experts" additional images might be offered. The problem has always been that every new image to be offered requires someone to sign up to create it and test it with their hardware.  My PiDP-8/i has a Pi3b, currently running Buster. So I can commit to making that image. Anything else needs someone to commit to making the others.  If all we're going to offer are instructions to make other images, that's fine.  But making and testing other images is a genuine commitment.

There is also the question about whether there might be a caching optimization valuable to the Pi Zero platform, but which we'd really prefer to coax upstream into adopting rather than holding onto as our own fork.

New ILF:

It looks like HB's evolving code will meet the criteria of  "Works as well as what we currently offer on all platforms," and may additionally "provide equivalent visual experience with less resource utilization," and "provide run-time controls for further exploration and refinement." 

What would be a home-run win would be if it also, "ran well enough under a Pi Zero that we felt comfortable offering it as a default for the one unified baseline image."

Question: How hard would it be to have a real-time toggle between ILS and NLS?  I.E. Instead of having two separate modules gpio-ils.c and gpio-nls.c, we merge the two, and have ils wake up as the default everywhere except the PiZero, but bring out a SIMH set command or environment variable to toggle between the two?

Cycle Accurate:

Benchmarking will help us understand if we are in one of the following two situations:

1. Cycle Accurate makes the PiDP-8/i experience much better since single step works, and does so with so little resource consumption that it should be adopted by default.

2. The resource impact is significant enough that we need to make it an option, not the default.

We also need to think more and discuss more about how we go about trying to get Cycle Accurate into upstream PDP8 Open SIMH.

Every upstream component we decide to redistribute is additional resourcing and commitment.
Every local mod we make to an upstream component is additional resourcing and commitment.
Every additional build variation we decide to deliver is additional resourcing and commitment.

Long term, we need to make the PiDP-8/i software project less intensive to resourcing and commitment.

-Bill

'Heinz-Bernd Eggenstein' via PiDP-8 wrote on 6/8/24 4:10 AM:

You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/aFc3mJ1Gufs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/48029c25-7874-452e-9a5e-355e6716850en%40googlegroups.com.

[Heinz-Bernd Eggenstein]

Hi Bill

Sorry for the delay, but as mentioned I was afk for the weekend.

Yup, sounds all good to me!

Details:

> How come you don't just make a branch off of the pi5-ils2-bookworm branch with what you have?

Ok, will do that soonish

> There is also the question about whether there might be a caching optimization valuable to the Pi Zero platform, 

> but which we'd really prefer to coax upstream into adopting rather than holding onto as our own fork.

For the reasons you mentioned later, let's try to do without this and go with the upstream version first, and bring in the optimization only when really, really, absolutely  needed, which at the moment I doubt.

>Question: How hard would it be to have a real-time toggle between ILS and NLS?  

> I.E. Instead of having two separate modules gpio-ils.c and gpio-nls.c, we merge the two, 

> and have ils wake up as the default everywhere except the PiZero, but bring out a SIMH set 

> command or environment variable to toggle between the two?

That question has interesting facets:

a) the current code already *does* run-time switching between ILS and NLS: When you run ILS and then press CTRL-E, 

     ILS will effectively be switched off and NLS will be used instead. That even makes sense

b) the same fallback to NLS will happen when you STOP the simulation via the panel switch. If you then 

     change the LED status via setting switches, or single stepping, the lights will change with NLs (so no "glow" effect anymore)

     and this makes much less sense...would be nicer to let the lights fade in and out even in stopped CPU mode.

     But that is the way it is handled now.

c) I looked into using the "SET ENVIRONMENT A=X"  feature of the SIMH script language to communicate

    configuration values and their updates to the GPIO thread, and then discovered that you cannot safely use

    "setenv"  from within a multithreaded application at all. It can crash "getenv" calls that happen in another thread

    e.g. see https://rachelbythebay.com/w/2017/01/30/env/

    But you could control via an environment variable set before the pidp8i-sim is called, or automatically in the

    code of pidp8i-simwhen detecting a single core CPU at start-up.That would eliminate the need for an extra

    one-core image and would make everything easier.

Cheers

HB

[Bill Cattey]

Hello HB!

I figured you wouldn't get to anything till Monday.

Before you merge in stuff to the pi-ils-bookworm branch, please do an update.  I did some testing of your branch, and made some changes that, perhaps you saw go by in fossil notifications:

1. I cleaned up the pi-specific code in auto.def and Makefile.in to eliminate all reference to the vc libs.
2. I fixed the PI_BINS Makefile.in to properly install pidp8i-test and scanswitch.
3. I made the fix to scanswitch you'd mentioned back on 19 May, "There is also a similar problem in the scanswitch tool. Doesn't work until you change the code to set all of the column pin modes to INPUT."

Some or all of these changes may already be in your local copy of that branch.  Sorry for stepping on your branch.
It is my hope that my putting these fixes in makes life easier rather than harder for you.

-Bill

'Heinz-Bernd Eggenstein' via PiDP-8 wrote on 6/9/24 4:24 PM:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/d328fcb1-3b34-462b-a4e7-aecccbf69791n%40googlegroups.com.

[Bill Cattey]

Hello again, HB,

I was in the middle of composing a "Do update first" message when your reply to this thread came in,
and so I did a quick reply with that content.

Now I'll reply to the points you raised in your note (carefully not forking the thread.  :-))

Re: Cycle Accurate branch off pi5-ils2-bookworm: Yay! We're on the same page here.
When you get round to it, I'll make time to review and test.  As you've seen, I've got that branch
and I've been testing with and messing with it.

Re: Cache optimization.  Sounds like were aligned here too.

Re: Toggling betwen ILS and NLS:

Intersting!  I agree with your point b.  If we can use it when stopped and single stepping, let's go for it!

Re: Environment setting.  YIKES! Good catch on blow-outs in multi-threading.  To be honest, I've been
a bit uncomfortable with using the shell environment variables to pass in ILS parameters.

I think the cleanest way to do it would be from a SET command inside of SIMH.  Vince was able to hook into that command for setting different CPU parameters, but there was already a setup to add sub-commands of SET CPU in ways that only touched pdp8-cpu.c.  Passing in the more complex data structures you've got for ILS seems challenging to say the least.

Let's meditate on this aspect some more.

-Bill

Bill Cattey wrote on 6/9/24 5:10 PM:

[Heinz-Bernd Eggenstein]

For selecting ILS / NLS, we could use the same "trick" again that switches between panel/nopanel: we have a unified executable that can do "everything", and we create 3 different copies of that same exec in the bin folder:

pdp8 (no panel support=> no light, no switches , same as currently)

pidp8i-ils-sim (panel support, ILS), replaces current pidp8i-sim

pidp8i-nls-sim (panel support, NLS) 

The program would look at it's filename and take actions accordingly, just like it does now to decide whether to use the lights and switches, with the additional twist of also choosing the lamps mode.

People would always have both options compiled and ready to test to see what fits their needs/taste.

Not quite sure how to switch between the executables in the pidp8i start/stop script, it could be

a) automatic based on number of cores, replicating current rationale (e.g "cat /proc/cpuinfo | egrep "^processor" | wc -l" )

b) via environment setting e.g. "PIDP8I_FORCE_NLS"

c) having two separate scripts

Anyway, it would eliminate the need to have two images, would do away with one configure option and the need to explain it, and the user could directly compare both options.

Cheers

HB

[Bill Cattey]

We don't need multiple copies of the same binary.
Instead we make a symbolic link to the main instance with other names.

-Bill

'Heinz-Bernd Eggenstein' via PiDP-8 wrote on 6/10/24 5:01 PM:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/aad17214-0f4f-4206-97d2-b611890c3923n%40googlegroups.com.

[Heinz-Bernd Eggenstein]

>We don't need multiple copies of the same binary.

>Instead we make a symbolic link to the main instance with other names.

Indeed, as it is done now already. maybe we should keep the pidp8i-sim name (would default to ILS) and just add a new pidp8i-nls-sim (forces NLS) to minimize changes in the documentation.

HB

[Mike Katz]

While we are at it, for completeness sake, add the ability to run ILS on a single core CPU.

In addition to the linked executable name can we also have an option in the config file that will override the command file name?

For benchmarking that will allow me to run the ILS version on a single core CPU just for comparison purposes.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/eced0fc4-377d-40dc-a57e-9864a2ebaa06n%40googlegroups.com.

[Bill Cattey]

Perhaps keep pidp8-sim as defaulting to ils on mult-core, and nls on single core, and then either add options --nls --ils to force one or the other, or else have the symbolically linked pidp8-{ils,nls}-simh names do the forcing function.

-Bill

Mike Katz wrote on 6/10/24 5:27 PM:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e625e486-9d2d-4af8-aa05-738a8bca6dcc%40gmail.com.

[Mike Katz]

Bill, Steve, HB,  Et Al,

I know I asked this earlier but I don't recall seeing an answer

In SiMH for the panel, to override OSR so it will not read the panel OSR but instead use the DEP SR value?

Thanks,

             Mike

[Heinz-Bernd Eggenstein]

I'm not so familiar with the switches code, someone else should answer this.

As for ILS / NLS, what about this:

pidp8i start ==> starts the simulation. If a PiDP-8i panel is detected by the scanswitch exec, use it.  Use a default (eventually depending on the outcome of benchmarking) based on Pi model / number of cores to select NLS or ILS

pidp8i start ils  ==> as above, but force using ILS , whatever the Pi model

pidp8i start nls ==>   as above, but force using NLS , whatever the Pi model

pidp8i stop ==> stop the simulation, however it was started

That should help with benchmarking and would leave the maximum freedom to users in the production version.

Cheers

HB

[Mike Katz]

HB,

I am going to be starting the simulator manually from the ./bin directory so I can do timing at the kernel level: 


time -v (./bin/pdp8-NLS -<run script> >>${logfile} ) >>%{logfile}

or

time -v (./bin/pdp8 -<run script> >>${logfile} ) >>%{logfile}

That will allow me to run multiple tests from a single test script.

             Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/481406f5-bad2-4ad9-ab60-15cd049a3435n%40googlegroups.com.

[William Cattey]

You know, you can set the switch register with a SIMH command…

On Jun 10, 2024, at 6:33 PM, 'Heinz-Bernd Eggenstein' via PiDP-8 <pid...@googlegroups.com> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/481406f5-bad2-4ad9-ab60-15cd049a3435n%40googlegroups.com.

[Mike Katz]

Bill,

Yes I know that but in the panel version of SiMH will the OSR instruction read the value set by the DEP SR command or what is set on the front panel.

My question is how to force SiMH to use the set value rather than the actual value.

Thanks,

        Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/E1AD3E9E-8C12-4A8F-A4E7-5FA315F184A2%40gmail.com.

[Mike Katz]

Bill, Steve, HB,  Et Al,

I'm looking at the SiMH manual from the tangentsoft website and I can't find out how to display the instructions per second as calculated by simh?

Thanks,

             Mike

On 6/10/2024 4:32 PM, Bill Cattey wrote:

[Steve Tockey]

Mike,

Doesn't "show throttle" tell you?

-- steve

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/80128be0-bd3c-42ff-9dec-7ed0809d19a5%40gmail.com.

[Mike Katz]

I think show throttle just shows you whether throttling is enabled or not.  I didn't see anything in the documentation about it showing the instructions per second.
Or do you have to emulate something first?

[Heinz-Bernd Eggenstein]

Try 

show clock

Cheers

HB

[Mike Katz]

Steve,

I tested it this morning after running JMP . for about 10 seconds.  Show throttle just displays whether throttling is enabled or disabled.

                  Mike

On 6/11/2024 8:18 PM, Steve Tockey wrote:

[Mike Katz]

Thank you.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/3170474b-916a-4140-b6e5-01b071487597n%40googlegroups.com.

[Heinz-Bernd Eggenstein]

Hi all,

I finally had some time to implement what was discussed earlier:

For the branch pi5-ils-bookworm, I did :

- revert the pinctrl optimization I had done earlier: not worth the extra hassle of diverging from upstream

- deciding whether the sim should run with NLS or ILS is moved from the build phase to the runtime,

  which means that the only way to build the sim now is *with* ILS support, *but* you can decide

 whether to use ILS or/opt/pidp8i/etc/pidp8i.rc NLS when executing the sim:

 you can either use the new pidp8i-sim-nls and pidp8i-sim-ils executables to force one or the other, or you

 can use the pidp8i-sim as before, or the pidp8i start script, and then the decision between ILS and NLS

 is made based on the configuration is the file /opt/pidp8i/etc/pidp8i.rc

The file /opt/pidp8i/etc/pidp8i.rc was there before but had only one setting, now

you can configure 

  - the minimum number of cores necessary to run ILS

  - whether to force NLS mode whatever the number of cores

  -some optional tweaking settings to configure ILS according to your personal taste

NOTE: when iinstalling from fossil repo to overwrite an existing installation., 

you need to explicitly remove the old /opt/pidp8i/etc/pidp8i.rc file because 

sudo make install 

will not overwrite an existing pidp8i.rc configuration file! 

Please have a close look at my changes, if those are ok to you we can merge them back into

the pi5 branch and then we have the first two things ready to benchmark: 

- new GPIO code, Bookworm ready , Pi Zero .. PI5 unified version with manual ILS/NLS support (branch pi5)

- same as above but with new ILS code with "tweakable" optics

TODO: merge in cycle-realistic code, will hopefully follow this weekend as well, and then we are

done wrt. having a complete bases for benchmarking

Cheers

HB

[Mike Katz]

HB,  Bill, Steve, et. al,

Is there a way to count cycles now that we have cycle accurate code.

This could be actual cycles or instructions.  I'm thinking of when optimizing code, the instruction/cycle count can be looked at.

I guess instruction time (from show clocks) could be used.  But would it make sense to add an instruction count?

           Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e5310b13-0d4a-4c38-b909-d8d580bd5c0dn%40googlegroups.com.

[Bill Cattey]

Hi Mike,

Sorry but I have not clue about counting cycles in SIMH.

Hi HB,

I'm going to test your updated stuff right now. 

Here's why the rc file doesn't get re-installed.  These lines in Makefile.in

    @# Install runtime config file if there isn't one there already.
    @test -f $(DESTDIR)$(RCFILE) || @INSTALL@ -m 644 -o @INSTUSR@ @srcdir@/etc/pidp8i.rc $(DESTDIR)$(RCFILE)

This is silly. Everything else gets unconditionally installed.  I'll test a change.

-Bill

Mike Katz wrote on 6/14/24 8:14 PM:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/c4278f33-88c6-4cfd-9247-d684eaa99b14%40gmail.com.

[Bill Cattey]

I've got a trial fix for the  problem installing pidp8i.rc. (Doing a clean build test now.)

I have a question:

I expected that when the simulator is just running idle that the front panel would look pretty much the same whether I was runing pidp8-sim-ils or pidp8-sim-nls.  However when I ran pidp8-sim-nls, to my eye it looked like everything was running more slowly.  I double checked with "show throttle" and no, there was no throttle happening.

It it possible that that the lights are being blacked out in the new decision code when pidp8-sim-nls is run?

-Bill

'Heinz-Bernd Eggenstein' via PiDP-8 wrote on 6/14/24 8:00 PM:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/e5310b13-0d4a-4c38-b909-d8d580bd5c0dn%40googlegroups.com.

[Heinz-Bernd Eggenstein]

hmmmm, I can understand the rationale for not clobbering pidp8i.rc. Even more so now that it will contain non trivial settings like your personal ILS tuning parameters. 

The install will also not clobber existing disk Images and startup scripts, which is also a good choice.

hb

[Warren Young]

On Sat, Jun 15, 2024 at 9:36 AM 'Heinz-Bernd Eggenstein' via PiDP-8 <pid...@googlegroups.com> wrote:

hmmmm, I can understand the rationale for not clobbering pidp8i.rc. Even more so now that it will contain non trivial settings like your personal ILS tuning parameters. 

Yes. It was no attack of silliness that led me to make that line conditional. One does not blindly overwrite existing user configuration files when upgrading software.

[Bill Cattey]

Ah. Makes sense. Let's roll back my change then.

Warren Young wrote on 6/15/24 12:40 PM:

[Heinz-Bernd Eggenstein]

Hi!

>I have a question:
>I expected that when the simulator is just running idle that the front panel would look pretty much the same whether I was runing pidp8-sim-ils or pidp8-sim-nls.

What did you use to get teh PDP-8i to idle? OS/8 command line prompt?

>However when I ran pidp8-sim-nls, to my eye it looked like everything was running more slowly.
>I double checked with "show throttle" and no, there was no throttle happening.

I'll have a look.

Important note: when doing tests like this, it is essential to run the
executables that get installed to /opt/pidp8i/bin/ , and NOT those
that are still in the fossil tree (bin subdir). The reason is that
"sudo make install" applies some magic to those files so they run with
higher priority and the GPIO thread is more "real-time" like.

Cheers
HB

[William Cattey]

I just ran the two different commands from my shell prompt.
I am unable to double check right now, but I believe the /opt version was in my path.

I just started simh, but didn’t even boot into OS/8.
I just typed “cont” at the SIMH prompt.

-Bill

> On Jun 15, 2024, at 2:52 PM, Heinz-Bernd Eggenstein <hbep...@googlemail.com> wrote:
>
> Hi!

[Heinz-Bernd Eggenstein]

Not quite sure I understand. What code would it execute then? I think
the PDP-8 simh must be either executing some code, and the lights
blink according to that, or must be stopped (either because it ran
into a HALT or because it is stopped by the switches, but then the
lights are all static, no change going on.
Cheers
HB

[William Cattey]

I will do more rigorous testing tomorrow. I'm off to perform a concert now.

I  plan to write a blinkey light program that takes its pacing from the front panel switches.

[Heinz-Bernd Eggenstein]

Nice!

And I have finally done a merge to bring the cycle-realistic code into the latest codebase.

now we have the following versions that build onto one another::

- The new GPIO code that works for all Pis, zero to Pi 5: 

  ==> branch pi5

- plus the new ILS code, and dedicated NLS and ILS versions without recompile: 

  ==> branch pi5-ils2-bookworm

- plus the cycle realistic code 

  ==> branch pi5-ils2-bworm-cyclerealistic 

Of course one could come up with additional combinations like cycle realistic plus current ILS but new GPIO, 

but let's start with this and then see if we need anything else based on results.

Cheers

HB

[Bill Cattey]

Ok. I've done more rigorous testing.
I wrote a program that rotates a bit round the AC with a delay in the switch register.

I did:
cd /opt/pidp8i/share/media  # to get where systemd runs pidp8i
then I started ../../bin/pidp8i-sym-nls and ../../bin/pidp8i-sim-ils and took the attached videos.

Here is what I see comparing the two:

For the slow rotate of the bit through the AC:
The turn-on looks pretty similar. Maybe ils is a bit smoother in a subtle way.
The turn-off has significant persistence in ils with no persistence in nls.

But the thing I want to call your attention to is the behavior of all the other lights.
I'm used to seeing a blur of lights as normal operation.
With the nls, everything turns off completely, rather a lot.
I thought everything was running more slowly, but as shown in the demo, the rotating bit happens at the same time.
It's just that all the other light BLINK instead of blur.

Is that what everyone has been seeing on the Pi Zero?  Have I misunderstood the whole point of ILS up to now?  To show persistence across on and off states?

-Bill

ROTDEL.PA:

----8<---- cut here ----8<----
/ Rotate with delay
/ Set a delay in the switch register for how long to delay

*200

START,    CLA CLL
    OSR
    CIA
    DCA DELAY
    TAD VAL
LOOP,    ISZ DELAY
    JMP LOOP
    RAL
    DCA VAL
    JMP START+1

VAL,    0001
DELAY,    0000
$
----8<---- cut here ----8<----


William Cattey wrote on 6/15/24 3:18 PM:

[Mike Katz]

Bill,

How is that different from Normal Davie's deeper thought (Deeper Thought 2) programs which basically do that already on the pi accessing the display directly without simh.  I'm just trying to save you time from re-inventing the wheel.

There is also Steve Gibsons Deep Thought which was originally intended for the SBC-6120.

Also, I got my RPi 5 back from my son so I have a full set now.  I'm just waiting for the builds to settle and I'm writing the test scripts.

I still don't know how to force the OSR command to use the SiMH value for the switch register rather than the actual switch register.  Any help here would be appreciated.

Thanks,

           Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/CAHfX%2BzTyUhBaZBhih4U2oL87Qi5-bURJOB5wtdWAhGHWMvZpsw%40mail.gmail.com.

[Heinz-Bernd Eggenstein]

Hi!

It would be super cool if someone could make a video with this little snippet of code executing on a real historic PDP-8i, with original lamps installed. Then we could tweak the parameters of ILS to come close to the real effect.

>It's just that all the other light BLINK instead of blur.
>
>Is that what everyone has been seeing on the Pi Zero?  Have I misunderstood the whole point of ILS up to now?  To show persistence across on and off states?

I would estimate that the default configuration of the  ILS code is such that it takes a "lamp" to go from full to zero brightness in perhaps 1/4th of a second. That means that anything blinking faster than that will appear basically persistent "on" with a bit of "grey scale" depending on the duty cycle of the lamp being on or off per unit time.

However, the NLS code can also result in all sorts of https://en.wikipedia.org/wiki/Stroboscopic_effect or "aliasing" when the frequency of the *simulated* lights blinking (which can be up to a few  100kHz ) has a certain unfortunate relationship to the frequency of the code polling the simulated lamp status and blinking the LEDs accordingly (on the order of 100Hz) . Just like seeing wheels turning seemingly backwards in movies when the spokes turn much faster than the frame rate of the camera can capture them. This might look cool (because more stuff is actually blinking) but is unrealistic. The ILS code is also not invulnerable to aliasing effects, but the blurring of the lights by the "glow" effect makes it far less pronounced (and there is some intentional jitter applied to the sampling of the simulated lamp status).

It's all described here: https://tangentsoft.com/pidp8i/wiki?name=Incandescent+Lamp+Simulator&p

(Note: "New ILS" in this document still refers to the "production", now "old" ILS code used , not the experimental code we are evaluating here).

But the (now) new ILS code is very similar to the previous (and then "new") version: Both codes try to simulate up to 32 brightness levels (or perhaps 33 if you are pedantic) by digitally switching the LEDs on and off faster than the human eye can perceive it. To simulate a brightness level of, say, 16, for a given lamp, the old code will generate 16 pulses of fixed length over the course of a front-panel "refresh". For a lamp that is simulated with the full brightness level of "32", instead 32 pulses will be generated during the same period, so it will appear brighter to the human eye. 

The new code works in a similar fashion, but it will generate only a single pulse per lamp per panel refresh cycle, but of varying length depending on the simulated brightness. This reduces the number of GPIO switching actions per time significantly.

But perhaps more importantly, the new code also exposes some constants that control the ILS visual effect in the configuration file /opt/pidp8i/etc/pidp8i.rc . The previous code had those constants hardwired in #define lines in the C code so you needed to recompile when changing them. I think the visual effect was also more dependent on the speed of the PI used.

So if you think the simulated lamps should take less (or more) time to rise to full brightness or less (or more) time to decay in brightness when turned off to match the historic PDP-8i or your personal taste, you now can just change the configuration settings and restart the simulation and see if that is more pleasant/realistic for you.  The constants in questions are those that appear in the equations described in the tangentsoft.com WIKI page linked above.     

[Heinz-Bernd Eggenstein]

> I still don't know how to force the OSR command to use the SiMH value for the switch register rather than the actual switch register.  Any help here would be appreciated.

That's not possible with the current code, someone would have to make code changes to the PiDP-8i code for that.

I think it would be much easier to instead change the PDP-8 code in question to read  from a fixed memory location that your script could "dep"osit to instead of using the switch register? Didn't you suggest this  (I might have misunderstood something, tho)?

HB 

justme...@gmail.com schrieb am Sonntag, 16. Juni 2024 um 20:37:30 UTC+2:

[Mike Katz]

HB,

Thank you for your response.  The problem is the several of the maindecs read the SR multiple times.  For example the instruction test 1 reads it to both to verify the OSR instruction as well as to get 7777 into the AC.  YES CLA CLL CMA would do that as well.   That works for that one case.   In some cases I could just substitute an OR with an unused location but in other cases I would have to create a subroutine that cleared the AC, ored in the needed value and then return.

This would also require  going through all of the maindecs I want to run and see how difficult it would be to replace all of the OSR related instructions.  If we discount HLT there are 32 possible combinations of Group 2 MicroInstructions that can combine with the OSR instruction.

Additionally If I cannot override the switch register for the maindecs then I cannot run the maindecs, on the PiDP SiMH code, as benchmarks without the PiDP attached.  My original thought was to run the maindecs in parallel on the Pis without the PiDP attached to save time.  If they require the SR then I will have to do it two at a time (after I assemble second PiDP-8/I).

Thank you for your help,

             Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/6ac72ac4-6145-4c99-abe5-08a6aab8c18en%40googlegroups.com.

[Heinz-Bernd Eggenstein]

Hi!

>My original thought was to run the maindecs in parallel on the Pis without the PiDP attached to save time.  If they require the SR then I will have to do it two at a time (after I assemble second PiDP-8/I).

That case is actually covered: When no PiDP-8i panel is attached, the only meaningful choice is to run the "pdp8" executable (e.g. pidp8i start will detect the missing panel and then start plain pdp8)  

And in pdp8, without the panel, OSR will automatically get the values from SIMH and the "dep" commands in a SIMH script.

Anyway, my understanding was that the plain maindecs are not ideal for benchmarking as they take just a short time to execute and would need modification anyway to run in longer loops?

So I wonder whether the idea of suing maindec codes here is perhaps creating more problems than it solves ?

Cheers

HB 

[Steve Tockey]

Does SIMH have a "break on instruction"? If so, just set a breakpoint for the OSR instruction, do a SIMH deposit into the SR if it needs to change, then SIMH Go. This will bypass SIMH's call into the OSR code that reads the front panel. otherwise, as suggested, deposit the desired SR value into an unused location (presumably on page zero, between 0000-0177). The source code for every MAINDEC is in the PDF manual that goes along with it. But this also might suggest that using MAINDECs for benchmarks may not be the best approach.

-- steve

[Bill Cattey]

Version skew...
The code I previously provided didn't delay long enough on my Pi3b.
I did an improved version locally on the Pi, but didn't back-port it to my Mac  environment.
Here is the code I ran in my videos:

/ Rotate with delay
/ Set a delay in the switch register for how long to delay

*200

START,  CLA CLL
        OSR
        CIA

        DCA DELAY2
        TAD VAL
LOOP,   ISZ DELAY1
        JMP LOOP
        ISZ DELAY2

        JMP LOOP
        RAL
        DCA VAL
        JMP START+1

VAL,    0001

DELAY1, 0000
DELAY2, 0000
$

For those interested in toggling in a binary, here is the assembly listing:

^L/ Rotate with delay                                     PAL8-V10D NO DATE   P>

             / Rotate with delay
             / Set a delay in the switch register for how long to delay

       0200  *200

00200  7300  START,  CLA CLL
00201  7404          OSR
00202  7041          CIA
00203  3216          DCA DELAY2
00204  1214          TAD VAL
00205  2215  LOOP,   ISZ DELAY1
00206  5205          JMP LOOP
00207  2216          ISZ DELAY2
00210  5205          JMP LOOP
00211  7004          RAL
00212  3214          DCA VAL
00213  5201          JMP START+1

00214  0001  VAL,    0001
00215  0000  DELAY1, 0000
00216  0000  DELAY2, 0000
             $
^L/ Rotate with delay                                     PAL8-V10D NO DATE   P>

DELAY1 0215     
DELAY2 0216     
LOOP   0205     
START  0200     
VAL    0214     
^L

ERRORS DETECTED: 0
LINKS GENERATED: 0
^L

[Steve Tockey]

Bill,

That ILS vs. NLS difference is consistent with what I see in the original PiDP-8/i code. It would be essentially "correct" compared to that.

All,

Apologies but for the next 4+ weeks I will be away (1/2 a world) on business from my PiDP-8/is so I won't be able to do any experimenting or benchmarking myself.

-- steve

--
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.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/2956dd78-0b71-6ee3-12d6-1919426061d8%40gmail.com.

[Bill Cattey]

Thanks for the heads-up.
Have a good time, Steve!

-Bill

Steve Tockey wrote on 6/16/24 9:12 PM:

[Mike Katz]

My thought about running the maindecs was to guarantee that every instruction was included in the benchmark and they generally don't take hours to run.

My understanding is to get a comparison between different PI's running the same PDP-8 code.

I could write a small PDP-8 program executed all possible different cycles and run that program 1 million times.

As was pointed out earlier in this thread, there are really only 4 or 5 different cycle combinations (not counting data break, I/O or the microinstructions).

All of these below have Page 0, Current Page, Indirect and Auto Indexed addressing modes:
AND, TAD are probably the simplest in terms of cycles
JMP needs to update the PC instead of the AC, I don't know if this changes the timing cycles or not.
ISZ affects both the AC and PC (when the test is true)
DCA affects both the AC and memory.
JMS affects both the PC and memory.

As for the combined microinstructions, I don't know how they are handled in terms of timing cycles.  Does rotate two take longer than rotate one.  Does CLA CLL CMA CML RTR IAC BSW cycle differently than CLA?  The PDP-8/E pocket reference card says that combined microinstructions all take 1.2uS.  I'm sorry but I don't understand the underlying CPU logic that lets all of this happen.

In the group two microinstructions I presume the cycles are different if the skip is taken or not.  Does CLA SMA OSR cycle differently than SMA?

Do we want to include some kind of interrupts (maybe a periodic interrupt) in our benchmark?

Thank you all for putting up with my simple mindedness.

Steve, have a good and safe trip.

Bill, how was the concert?

            Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/fd69320f-3ed1-dae9-9fb6-89ea33fb34e4%40gmail.com.

[Bill Cattey]

Hi Mike,

The concert went well.  This time round I got through our choreography without screwing any up.
(Too bad the video was made 2 concerts ago.  ;-)  )

In answer to your query about instruction execution, I grabbed the PDP-8i and PDP-8e maintenance manuals from bitsavers.org and did some research.

Basically the PDP-8 sub-divides it's CPU operation into 4 cycles TP1 through TP4.

The Operate instructions complete in a single memory cycle, and the combined micro instructions are worked through during TP1 through TP4.  By the end of the FETCH major state, all Operate instructions have been completed.

Hope this helps.

All:

I've updated to HB's pi5-ils2-bworm-cyclerealistic branch on my Pi3.  The code builds and runs for me.
I've seen the MAJOR STATE lights of FETCH, DEFER, and EXECUTE blink at times I think are appropriate.

I shall leave it to others to benchmark.

-Bill

Mike Katz wrote on 6/16/24 11:05 PM:

[Steve Tockey]

Mike,

I would propose only using the MAINDECs to confirm proper emulation of the PDP-8 instruction set. If the PiDP-8/i simulator can pass all of the relevant MAINDECs then we should be able to safely say it is a "proper" emulation of the PDP-8 instruction set. I think it ends up being way too much of a hassle to try to also use those same MAINDECs as performance benchmarks.

I would suggest performance benchmarking using one or more compiled high level language programs in, say, FORTRAN, PASCAL, ALGOL, etc. Even if it is simple at the source code level, you are virtually guaranteed to span the majority of the PDP-8 instruction set in the compiled machine code.

Group Two microinstructions all take the same amount of time regardless of skip or not. The PC is automatically incremented in (I believe) TS2 of the FETCH major state. If the test is true and the skip is needed, the PC is incremented again in (I believe) TS4 of that same FETCH major state giving you the skip behavior. If the test is false and the skip is not needed, that second PC increment in TS4 is inhibited so the PC was only incremented by one so the next instruction is executed.

All Group One combined microinstructions are designed in such a way that the hardware does everything in parallel so it always takes 1.5 (on -8, -8/i, -8/L, -8/a) or 1.2 (on -8/e, -8/m, -8/f) microseconds. For example, each bit in the AC+Link is directly hard wired to the two bits immediately next to it (e.g., AC4 is directly wired to AC3 for RAL and AC5 for RAR) but is also wired two bits away (e.g., AC4 is directly wired to AC2 for RTR and AC6 for RTL).

ISZ affects PC and Memory, not the AC. Again, you get (I believe) the automatic PC increment in TS2 of the FETCH major state and the additional PC increment which causes the actual skip in (I believe) TS4 of the EXECUTE major state only when the incremented memory location became 0000.

Regarding interrupts, I don't think it's relevant for benchmarking. First, the vast majority of PDP-8 software runs under OS/8 which does not play well at all with interrupts. Second, the interrupt mechanism in the PDP-8 is incredibly simplistic. If interrupts are enabled and an interrupt is requested, it is held until the current instruction completes. On completion of the current instruction, the PC is written into memory location 0000 and the PC is set to 0001 (there is a bit of parallel magic with Data Field and Instruction Field with extended memory but it does not affect the timing). This is what gives you the effective JMS 0000 on interrupts.

I'm not sure how deeply you would really want to go into the PDP-8, but I could suggest you get a copy of the "pdp8/e, pdp8/m & pdp8/f small computer handbook" of 1973 from Bitsavers:

http://bitsavers.org/pdf/dec/pdp8/handbooks/Small_Computer_Handbook_1973.pdf

Alternatively, you could get the 1970 edition as it is for the PDP-8/i and -8/L:

http://bitsavers.org/pdf/dec/pdp8/handbooks/SmallComputerHandbook_1970.pdf

Chapter 2 in both editions is fairly detailed about the hardware architecture and Chapter 3 in both editions is fairly detailed about the instruction set. That would fill in a lot of the blanks in your understanding of the machine. If you really want to go nuts, dive into Chapter 9 of the 1973 edition because it goes into gory detail about signal timing on the Omnibus.

Best,

-- steve

[Mike Katz]

Steve,

Thank you for your in depth analysis of the PDP-8 internals.  I read the PDP-8/E handbook back in the 1970's when I was 12 or 13 years old.  I was way to young to understand the internals of the architecture beyond a basic understanding of the three major states.

I didn't start to investigate the timing cycles until a couple of years ago.

I will look into the programs you have already sent me and I will work the into the scripts.

Thanks again,

             Mike

[Heinz-Bernd Eggenstein]

Today I took the pi5-ils2-bworm-cyclerealistic fossil branch and let it run on a Raspberry Pi Zero W (the single core model).

When run throttled to 333k instructions per second and doing some manual, ad hoc BASIC test runs under OS/8, the CPU load as shown by "top" fluctuates between ca 80 and 90 % when run with ILS, and ca 30% when run with NLS.

The current default configuration file /opt/pidp8i/etc/pidp8i.rc has the following setting:

[...]

PIDP8I_ILS_MIN_CORES=2

[...]

Which means that if started with "pidp8i start" on a Pi Zero with only a single core,  the code will automatically switch to NLS and you can make your first measurements.

In order to test  it with ILS, stop pidp8i, edit the setting to

PIDP8I_ILS_MIN_CORES=0

and restart pidp8i. Now the sim should run with the ILS mode.

Because the simulation just barely manages to run throttled at realistic speeds with ILS on a single core Pi, it is debatable whether we should change that default setting. If users run anything else on the PI that consumes a non trivial amount of CPU cycles, SIMH will notice it cannot maintain the 333k IPS and disable throttling. But it's good to know that at least it would now make sense to offer the option of running ILS even on a single core PI, and with cycle-realistic mode simulation.

I'm looking forward to see more meaningful tests including heavy math stuff in better benchmarks.

If you then test on multi-core Raspberry Pi models, the setting

PIDP8I_ILS_MIN_CORES=2

means that ILS will be activated by default.

To then also test NLS mode,  you need to stop the simulation, uncomment the setting

#PIDP8I_FORCE_NLS=1

in the same file, and restart.

IMPORTANT: I'm not sure I have already mentioned this here on the list: to make meaningful benchmarks, it is essential that you

complete any new build from the fossil branch in question with

sudo make install

and then start the sim with pidp8i start

or , if you want to start it with a custom script and explicit control over NLS/ILS, use

/opt/pidp8i/bin/pidp8i-sim-nls path-to-your-custom-script

or

/opt/pidp8i/bin/pidp8i-sim-ils path-to-your-custom-script

respectively.

Do NOT use the executable files created in the bin folder of the fossil working tree to run your benchmarks! The reason is that "sudo make install" will apply some extra magic to the files it installs into /opt/pidp8i/bin so they get extra high priority when running multi-threaded on your Pi and have to compete for the CPU with other processes. 

Cheers

HB

[Mike Katz]

HB,

Was that ILS test on the Pi Zero W done with the new optimized ILS?

Thank you for the information on running from /opt/pidp8i/bin

         Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/3a8ded63-15b6-4d81-9bed-9eaf6b257ad9n%40googlegroups.com.

[Mike Katz]

Steve, HB & Bill,

In order to build all of these different flavors of simh should I clone the repository as recommend into museum and make a link in src or should I use some other setup?

Thanks,

             Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/3a8ded63-15b6-4d81-9bed-9eaf6b257ad9n%40googlegroups.com.

[Heinz-Bernd Eggenstein]

> Was that ILS test on the Pi Zero W done with the new optimized ILS?

Yes, and currently that is the only option if you want to use the new GPIO code that will also run on the Raspberry Pi 4 and 5 and will compile on Bookworm, and the cycle-realistic version . 

You could use the original "cycle-realistic" branch will will use the old style ILS, but it also uses the legacy GPIO code ==> it won't run on Pi5s.

Cheers

HB

[Heinz-Bernd Eggenstein]

>In order to build all of these different flavors of simh should I clone the repository as recommend into museum and make a link in src or should I use some other setup?

As I understand https://tangentsoft.com/pidp8i/doc/trunk/CONTRIBUTING.md  , the examples given there use one "museum" folder and separate directories for any number of different branches that you want to work on in parallel,

e.g. I have

~/museum

and

~/src/pidp8i/trunk

~/src/pidp8i/pi5

~/src/pidp8i/pi5-ils2-bookworm

~/src/pidp8i/pi5-ils2-bworm-cyclerealistic

...

I got this by following the recipe under "Separate Clone and Open" under the link mentioned above.

There is no need to make links, the files from different branches can coexist at the same time side by side, just in different folder trees. That should be most convenient for benchmarking different versions.

To checkout e.g. the pi5-ils2-bworm-cyclerealistic branch , I did the following:

cd ~/src/pidp8i/

rmdir pi5-ils2-bworm-cyclerealistic # just to make sure I delete anything that might be left over from earlier experiments

mkdir pi5-ils2-bworm-cyclerealistic

cd pi5-ils2-bworm-cyclerealistic

fossil open ~/museum pi5-ils2-bworm-cyclerealistic

and after that you build the stuff with

./configure

tools/mmake

sudo make install

and you do that for all the branches of interest.

To switch between different versions for testing (remember to first stop any running pidp8i), you can then  go to a specific branch  , say  pi5-ils2-bookworm, like this:

cd ~/src/pidp8i/pi5-ils2-bookworm

and if you already built that before , you just repeat the install step:

sudo make install

and then you can start the application from the pi5-ils2-bookworm branch , etc.

So by going to different branch folders and executing  "sudo make install", you can switch between the versions.

Cheers

HB

[Mike Katz]

HB,

Thank you for the quick response.

Can I run the pi5 stuff on the PI's prior to the PI 4?

Should I test trunk, pi5, pi5-ils-bookworm and pi5-ils-bworm-cyclerealistic on all Pi's?

Please forgive me for sounding stupid.  I'm trying to understand what I need to benchmark to create a valid comparison.

Thank you,

           Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/70d25030-0768-4828-86ed-d26cf4e1b35fn%40googlegroups.com.

[Bill Cattey]

The pi5 branch should work on all Pi hardware platforms, even those prior to the Pi 4.

-Bill

Mike Katz wrote on 6/18/24 7:48 PM:

You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/aFc3mJ1Gufs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pidp-8+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/c9145aa3-ce4a-4c5f-8942-e46b076aa5b3%40gmail.com.

[Heinz-Bernd Eggenstein]

I had to make a small fix to the both the pi5-ils2-bookworm and pi5-ils2-bworm-cyclerealistic branches (the tweaking of the ILS parameters via settings in pidp8i.rc didn't work as intended). This will not affect benchmarking results tho, so no need to pepeat measurements you made with the old code.

Cheers

HB

[Heinz-Bernd Eggenstein]

Whenever you think you are done .... 

I submitted another change to the pi5-ils2-bworm-cyclerealistic, but I think it's worth the effort to rebuild.

The new features:

- ILS now still works when the simulated CPU is stopped with the front-panel STOP switch for single-stepping. 

- ILS now works correctly even when throttling to VERY low speeds , like using "SET THROTTLE 1/1000" to get a single instruction per second rate.

- all other throttling modes are supported for ILS as well now.

 

Benchmark results will not be affected by this.

What still needs to be done is to bring the documentation in the fossil repo up to date with the new features, e.g.

- the throttling documentation

-the changed limitations for single core Raspis

-documenting the cycle realistic aspects

-the changed limitations for ILS to work

- the configuration options in pidp8i.rc

-list of supported Raspi Models and Raspi OS versions

and many other things I might have forgotten here. 

So still some work to do before there can be a new release.

Cheers

HB