Step Counter LED question

[Mike Katz]

I have noticed while doing my benchmarks that the Step Counter LEDs are
lit and changing.

I thought the Step Counter was only used at part of Data Break?  Are
they being lit incorrectly or is SiMH simulating Data Break when
accessing the simulated RK05?

Here is a brief video showing this:

https://drive.google.com/file/d/1JKOFKb-wkfuAbszlNN_4gLhyoP9OMoL7/view?usp=drive_link

[timr...@gmail.com]

I thought the SC was used with the MQ?  I could be totally wrong though.  It's been way too long since

I wrote any software for a pdp-8.

[Heinz-Bernd Eggenstein]

From here:

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

Page 17-18:
"
Step Counter indicator lights (footnote: operational only on PDP-8/I systems containing the KE8/I Extended Arithmetic Element option):
Indicate the contents of the step counter (SC). The step counter is loaded with the complement of the contents of bits 7-11 of the memory location during an ASR, LSR, SCL or SHL instruction; contains the exponent after an NMI instruction; and is set to contain all zeros for the DVI and MUV instructions.
"

[Mike Katz]

Heinz,

Does the PiDP-8/I enable the EAE by default?  I was using the default configuration.  Since we are working on a cycle accurate representation of the 8/I I just wanted to be sure that the Step Counter LEDs were correct.

Since I didn't see any activity on the MQ lights I will assume that the Pascal compiler isn't using the EAE.

Thank you,

             Mike

P.S.  Did you see my initial benchmark results?  Would you like to see any other benchmarks?

--
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/d6e25c1d-d812-414a-849e-c2c3c0c02acfn%40googlegroups.com.

[Heinz-Bernd Eggenstein]

The default configuration should be to have the EAE enabled, but you can toggle it on an off in simh settings with

SET CPU EAE
and

SET CPU NOEAE

respectively

So if the benchmark does not use the EAE, why do we see the SC lights lit in the video?

Thanks for the benchmarks, I think that is all we need for now and I wouldn't know what else to test.

Cheers

HB

[Mike Katz]

I don't know why the Step Counter lamps are lit during the program execution but i will look into if the Pascal compiler uses the EAE if it exists.  That's assuming I can find documentation on it.

Unfortunately I can't disassemble the compiled file becaue, I believe, that the Pascal compiler does not generate straight Machine code but some kind of intermediate code.  Like the P-System generated P-Code.

I will dig into it when I have some time.

Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/8d350289-3af5-43bb-81b1-7f510fb0a5bfn%40googlegroups.com.

[Heinz-Bernd Eggenstein]

I guess one could just disable the EAE with the command given above in SIMH and see if the benchnmark halts with an unknown instruction.

Cheers

HB

[Mike Katz]

HB,

If I run bin/pidp8i-sim all of the LEDs start blinking.  If I type set cpu noeae the lights still blink.

If I boot into OS/8 all of the light are flashing.  I wonder if something could be wrong with my PiDP-8.

            Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/3cc0f1ed-dc5a-4227-be06-06f729dbc690n%40googlegroups.com.

[Mike Katz]

I think I have found the problem.

Building the code with the following commands:

fossil open ~/museum/pidp8i.fossil pi5 | tee -a ${Logfile}
./configure --prefix=$PWD/pidp8i
tools/mmake
sudo make install

Produces code whose lights only work on the Pi A & Pi B.  I did not try the Pi Zero W but it does not work on the Pi Zero 2 W.

Is the new code supposed to detect the current Pi and set I/O accordingly?

What can I do to help fix this issue.

Thank you,

          Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/3cc0f1ed-dc5a-4227-be06-06f729dbc690n%40googlegroups.com.

[Bill Cattey]

Hi Mike,

I'm not sure I understand your problem description.  I will say that the "pi5" code line introduces code that enables access to the gpio pins on Pi4 and Pi5 hosts. It's a new implementation of the gpio support that is supposed to work for all Pi platforms, whereas the previous implementation simply did not work at all for Pi 4 and Pi 5 hardware. (Different gpio chipset or some such.)

So if you build trunk, without the new pi5 pinctrl module, lights will not work on pi 4 and pi 5 hardware.

-Bill

Mike Katz wrote on 10/16/24 10:19 PM:

[Mike Katz]

Bill,

I was testing the lights with the pi5 branch.  It only works on pia and pib.  I tried pdp8i-sin and pdp8i-test.

    Mike

[Bill Cattey]

Hi Mike,

DARN! I was hoping it was a simple misunderstanding of what was expected to work.

Ok... You have to travel the path I did when I did the pinctrl integration first time round.
It didn't work at all for me until I learned how it was supposed to work, and fixed a few bugs
(which you see checked in over time in the pi5 timeline.)

To do this you use bin/pidp8i-test
Example: Stop any running pidp8i and start up the test:
pi@pidp8:~/src/pidp8i/pi5/bin $ pidp8i stop
pi@pidp8:~/src/pidp8i/pi5/bin $ ./pidp8i-test

It then tells you what it's trying to do... Turn on all LEDs; Turn off all LEDs, Listen to front panel switches, etc.

Read the code in src/misc/test.c and see if you can isolate what it's trying and failing at.

My Pi3 works just fine with this code, so if you aren't getting proper operation on a 3B then maybe it's an OS issue.

Good luck!

-Bill

Mike Katz wrote on 10/17/24 9:37 AM:

[Mike Katz]

Bill,


Just when I thought the fun was over when i got the benchmarks out🙂.

Thank you for your advice.  i will have to research the difference between the A & B and the remainder. 

I am running the latest version of Bookworm.  I created a boot sd card for each Pi with the Pi Imager software and then did a sudo apt update and then sudo apt upgrade to insure I had the latest of everything on each Pi board.

If you have the time could you point me towards the GPIO differences between the different boards?

Thank you,

          Mike

[Mike Katz]

Two problems solved at the same time.

My problem with the LEDs was not stopping the Pidp8i task before running the tests or benchmark script.

and apparently the Pascal runtime uses the EAE if it is there.

With the pidp8- task stopped and telling simh that there is noeae the Step Counter LEDs stay off.

Bill and HB thank you for your help.

I'm going to put my PIDP-8/I back together and back on my shelf.

Please let me know if  you would like me to do any further benchmarking.

Thank you everyone,

                  Mike

On 10/17/2024 10:09 AM, Bill Cattey wrote:

[Steve Tockey]

Hey all,

Apologies for going silent for the last few weeks, I was on travel in China and everything Google is blocked by the proverbial "Great Firewall of China".

On the Step Counter lights, I'm not entirely sure why, but that Pascal run time system does set all of the SC bits whenever it runs (except when the Pascal compiler itself is executing, IIRC). And this is in spite of the fact that the OS/8 Pascal system does NOT use EAE at all. What I can tell about the SIMH implementation of the PDP-8 is that at its heart it really is a pdp-8/e model. In the real -8/e model, the MQ register is available although the EAE multiply & divide instructions won't work unless you actually have the EAE hardware installed. I'm not sure which board the Step Counter is located on, but if it's not on one of the EAE-specific boards (e.g., it could be on the Major Registers board) then the instructions to load it and read it would work without full EAE hardware installed, but again without the ability to execute the full hardware multiply-divide instructions.

As far as SIMH is concerned, it seems perfectly happy to execute the load and read the Step Counter instructions regardless of whether EAE is enabled or not.

My guess is that either intentionally (or, more likely?) unintentionally there's an instruction in the Pascal run-time system code that ends up setting all of the SC bits. It's normal, and it's harmless. There's nothing wrong with your PiDP-8/i. Just ignore it as an odd quirk.

-- steve

[Mike Katz]

Steve,

Welcome home from your travels.

If I run set cpu noeae before running the pascal program the Step Counter leds stay off.  That is in the latest pi5 code.  I did not try that on the pi5-ils and pi54-ils/cycle branches.

    Mike

--
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/cf315135-a7dd-4da9-a07a-dbcb6e292e7fn%40googlegroups.com.

[Steve Tockey]

Mike,

OK, I haven't tried that. But I do know that even though EAE is enabled in the SIMH PDP-8 implementation, that Pascal does NOT use it. Fortran 4 and properly configured ALGOL will use EAE if it's there, but Pascal won't. When EAE is actively in use, both the SC and MQ lights flash quite a lot. In that Pascal, the SC bits are set solid and the MQ bits are always off.

In fact you may also note that when you are running the Pascal compiler itself to compile Pascal source code that it does a kind of line-count of the code it's compiling in the MQ.

-- steve

[Mike Katz]

Steve,

Are the benchmarks sufficient?  Do they fit your needs?

I'm sorry it took me so long to get it done.

Thank you for all of the help,

           Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/96e6c043-e07a-48e0-9d33-7640f2cef71an%40googlegroups.com.

[Steve Tockey]

No apologies, volunteer work always only happens on an as-available basis. Thank you very much for all of the work you put into it.

I think the results are sufficient for my needs, it demonstrates that all possible configurations run faster than real hardware (416k IPS on a -8/e/m or /f, 336k IPS on a -8/i) meaning that one will always be able to at least match the performance of a real machine. Whether one would be willing to pay the significant performance penalty for Cycle Realistic when not on a PiDP-8/I seems unlikely. My guess is that a request to merge Cycle Realistic into the basic PDP-8 version of SIMH will likely be rejected as too high a penalty for features unavailable without the PiDP-8/1 hardware. Since there are necessary differences between the standard non-PiDP version anyway I suspect Cycle Realistic will end up having to live alongside the other PiDP-unique code.

-- steve

[Mike Katz]

Steve,

Can cycle realistic be made an run time option (command line or set CPU cycle-realistci/set CPU nocycle-realistic)?

That is my preferred solution as then two branches don't have to be maintained and code won't get "siloed".  Another option would be a compile time option that could be set in the configure script.

Thank you,

                Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/d25e237f-ca78-47c4-b7cd-2584e42dac25n%40googlegroups.com.

[Steve Tockey]

It's far more likely that it could be better done as a compile time-option. it is possible to do as a run time option but it would lead to serious code bloat. The basic difference is in one big code file, pdp8_cpu.c. It's merely a matter of the same basic code having been totally reorganized. Instead of "slicing" the code in one dimension (by opcode) everything has been re-arranged in an orthogonal dimension (by fetch-defer-execute major state). So you would need two differently-organized versions of the same code living side-by-side.

The "software engineering" solution could be to slice and dice the pdp8_cpu.c code into a set of small functions that implement the by-opcode with by-major-state fragments individually. it's then just a matter of having two different top-level functions that call these little fragments as needed. If the functions are in-liine then it saves the run-time cost of a C function call but the memory footprint of the executable file would increase by some (currently unknown) amount.

We still need to keep in mind that:

A) there are several basic differences between the generic PDP-8 implementation of SIMH and the PiDP-8/I version, and

B) there are still more differences between the Cycle Realistic version of the PiDP-8/I and the non-Cycle Realistic version

Is there enough interest among the PdDP-8/I owners to warrant a Cycle Realistic version?

-- steve

[Mike Katz]

Steve,

The current size of the cycle accurate binary (pidp8i-sim) is 2478964 bytes and the trunk version is 2424716.  That makes the ils-cycle realistic version 54,248 bytes longer.  I don't think this is a significant enough code size increase to merit any worry about code size.

The minimum memory on a Pi is 512MB.  That should be more than enough to load Linux (maybe not with the gui [x-windows is a pig]) and the pidp8i-sim with cycle realistic and ils.

If you prefer the build could create different binaries (PDP-8/E without PiDP-8/I, PiDP-8/i with ILS, PiDP-8/I with cycle realistic and PiDP-8/I with ILS and cycle realistic.

The System Architect in me, prefers to see all options available in a single binary (considering the target is the Raspberry Pi running Linux with 512MB or more memory).  That simplifies the build, the packaging even if it does make the code more complicated.

You are correct, re-architecting the code to use a jump table to handle each instruction separately is the best option, that would take a major re-write of the PDP-8 portion of SiMH.

However, doing that would add the following improvements:

1.  Instructions with identical cycles can use the same functions saving memory.
2.  Doing it this way would make it considerably easier to implement cycle accuracy for each of the different models in the "Family of 8".
3.  Re-architecting the code in this kind of table driven structured manner would make the code easier to read and maintain going forward.
4.  A single executable makes for easier maintenance, building and distribution.
5.  A single executable also makes for less newbie confusion (what's the difference between pidp8i-sim, pidp8i-nls and pidp8i-ils when they are all the same size).

Please see my response to your list in green below.

Thank you for your time and help.

Now if only the PiDP-11/70 image and build was as well done as you and Bill and HB have done for the PiDP-8/I...

               Mike

On 10/19/2024 9:51 PM, Steve Tockey wrote:

It's far more likely that it could be better done as a compile time-option. it is possible to do as a run time option but it would lead to serious code bloat. The basic difference is in one big code file, pdp8_cpu.c. It's merely a matter of the same basic code having been totally reorganized. Instead of "slicing" the code in one dimension (by opcode) everything has been re-arranged in an orthogonal dimension (by fetch-defer-execute major state). So you would need two differently-organized versions of the same code living side-by-side.

The "software engineering" solution could be to slice and dice the pdp8_cpu.c code into a set of small functions that implement the by-opcode with by-major-state fragments individually. it's then just a matter of having two different top-level functions that call these little fragments as needed. If the functions are in-liine then it saves the run-time cost of a C function call but the memory footprint of the executable file would increase by some (currently unknown) amount.

We still need to keep in mind that:

A) there are several basic differences between the generic PDP-8 implementation of SIMH and the PiDP-8/I version, and

B) there are still more differences between the Cycle Realistic version of the PiDP-8/I and the non-Cycle Realistic version

Why do we need a difference.  Enable or disable the PiDP-8/I, ILS and Cycle Realistic with commands.  Unless this would cause memory issues on smaller micros (like the pico)

Is there enough interest among the PdDP-8/I owners to warrant a Cycle Realistic version?

If just for educational reasons I think that cycle accuracy should be available.  I think you are right that most people won't care at all.  But those few purists have the advantage of making it an available option for all.  And since we already have the code working, isn't this a fait accompli?🙂

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/707895eb-5660-4a1e-8746-ee85f378ca30n%40googlegroups.com.

[Heinz-Bernd Eggenstein]

I think an importnat point is that the "cycle realistic" code version is doing other things as well in addition to merely make the lights blink a tiny bit differently: it finally gives meaning to the single step switch. Also some of the LEDs blinking wasn't really correct at all in the old version, e.g. the Fetch-Execute-Defer  lights were partly faked in their intensity etc.

The PiDP-8/I,  is all about the switches and lights, and any improvement in fidelity and supported features is well worth it, IMHO. If you just want to run a simulated PDP-8 as fast as possible as a SIMH proces without a realistic simulation of switches and lights, you can always use the SIMH product that you can even install from Many Lunux repository manamenet systems.

Cheers

HB