PiDPI-8/I revision question - version 2 - reposted

[Mike Katz]

Oscar,

I am building a second PiDP-8/I kit that I bought, unassembled, from a
gentleman in the UK,  a couple of years ago.

The circuit board in the kit is labeled Rev 2.2 2016-02-16.  You call
this the 2016-18 version.

This version did not come with the LED spacers or the LED cover bracket
and the switches have a much larger front metal piece and have mounting
holes in them.

Would it make sense for me to buy the LED spacers, LED bracket and
possibly the updated PC board for this kit before putting it together? 
If so how much should I send you?
What else would I need to upgrade to go with the newest PCB?
If I don't upgrade the PCB, Are there any cuts and jumpers that I should
do before assembling the circuit board?
What is the correct deposit switch inversion for this board?
Will I have any problems running any of the Raspberry Pi versions on
this kit (Zero through 5)?

I will be benchmarking the new build of the PiDP SIMH software on a
bunch of different Pi's so compatibility is an issue.

Thank you,

          Mike

P.S.  Is there any chance you will be at VCF Midwest this year?

[Steve Tockey]

Mike,

Seems like Oscar is unavailable. I'll give you my perspective, for what that might be worth:

"Would it make sense for me to buy the LED spacers, LED bracket and 

possibly the updated PC board for this kit before putting it together?  

If so how much should I send you?"

You probably shouldn't bother with the spacers. The issue is the distance that the circuit board is mounted from the front panel and that varies from some generations of kits to others. If that kit didn't come with spacers then it means it doesn't need them. If you put them in then it's highly likely that the front panel won't fit right as the LEDs would be too tall.  The LED bracket is useful for positioning the LEDs correctly when soldering them in. It's not necessary after the LEDs have been soldered although it does slightly reduce light bleed. So if you have the LED bracket from a different kit, just use it for solder positioning the LEDs. I got all of my PiDP-8/I kits before the LED bracket was available. I ordered the bracket later from Oscar for a nominal fee, something like USD $5 each. I wanted 3 as I have 3 PiDP-8/Is.

It's not difficult to carefully reposition any out-of-alignment LEDs after they've already been soldered in but you do need to not overheat any traces/pads. As long as your soldering skills are beyond just basic it can be done. I don't know if you can order the LED bracket through Jose instead of Oscar. I don't know if Jose only handles PiDP-10s or if he also stocks spare parts for PiDP-8/I and PiDP-11/70. It could be worth sending an email to Jose.

"What else would I need to upgrade to go with the newest PCB?

If I don't upgrade the PCB, Are there any cuts and jumpers that I should 

do before assembling the circuit board?"

You shouldn't need to worry about anything else between board versions. The behavior of all versions of board are identical. It's the distance between the board and the front panel that's the only relevant mechanical difference and that's addressed by the combination of whatever circuit board mounting hardware you use and whether or not it needs the LED spacers. Honestly, IMHO, I would just stay with the current board and no LED spacers. In the end it will behave exactly the same as if you had used any other version of the board (see my response to your benchmarking statement, below).

"What is the correct deposit switch inversion for this board?"

It's the same on all versions of the boards. Just cut the one trace and solder the jumper around the DEPosit switch as described in other emails. That part of the circuit board should not have changed across all versions. Board trace changes were all due to just re-positioning the RPi GPIO header.

"Will I have any problems running any of the Raspberry Pi versions on 

this kit (Zero through 5)?"

Any problems you would have would center around the fact that the GPIO pin mappings changed between RPi Zero to RPi 3 vs RPi 4 and 5.There may be an additional step to build the SIMH simulator software on a RPi 4 & RPi 5 unless that has been automatically incorporated into the build process script. The how-to-build-the-software instructions should make that clear.

"I will be benchmarking the new build of the PiDP SIMH software on a 
bunch of different Pi's so compatibility is an issue."

Everything that has anything to do with PiDP-8/I performance is contained entirely on whatever RPi is driving the PiDP-8/I circuit board. The circuit board is merely lighting the LEDs per the GPIO outputs and forwarding the front panel switch settings to the GPIO inputs. The board doesn't do anything else. All versions of PiDP-8/I circuit board will perform exactly as driven/determined by the RPi that's mounted on it.Technically, you could even performance benchmark without the PiDP-8/I kit as long as the benchmarks don't depend on you seeing the front panel LEDs or setting any front panel switches. A bare bones RPi should be sufficient for performance benchmarking of the PiDP-8/I software.

I hope this helps,

-- steve

[Mike Katz]

Steve,

Thank you for your answers.

As for the benchmakring, I believe there is code in SIMH (maybe only the Incandescent Light Simulation code) that actually detects the presence of the PiDP and the software may perform differently with or without the PiDP attached.

All of my development of the setup and execution scripts for the benchmarking were run on a pi without a PiDP attached.  I was going to build the second one so that I could benchmark 2 PIs at a time.

Thanks again,

               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/291a964f-11c2-4b82-90ff-ecfd224bbd87n%40googlegroups.com.

[Steve Tockey]

Mike,

Knowing what I know about RPi GPIO (which is admittedly not all that much), I don't see how the simulator code can sense whether the PiDP-8/I hardware is attached or not:

-- In output mode a GPIO pin is set to either a high (3.3v?) or a low (close to 0.0v) voltage. The RPi (and, thus, SIMH) can't tell if there's anything consuming that voltage.

-- In input mode, a GPIO pin defaults to a "floating" high value due to RPi internal pull-up resistors. It's up to any attached hardware to  pull that pin voltage down to change the value being read. If nothing pulls it down, it just stays at the floating high. In the specific case of the PiDP-8/I,  the RPi can't tell if a front panel switch is open or is simply not there. It can really only sense when a switch is there and closed. It can't tell the difference between a connected switch that is open and no switch is connected.

Is it possible that you are confusing that with the ability of the build script to sense what kind of RPi it is on and not configure for ILS when the RPi doesn't have enough horsepower to handle it? If the RPi CPU only has a single core that isn't enough horsepower for ILS so it only builds NLS. And again, this happens on the RPi itself and will happen regardless of whether that RPi is plugged into a PiDP-8/I kit or not.

best,

-- steve

[William Cattey]

I've looked at the code that "blinks the lights", and I did some cleanup to integrate the new pinctrl code to support

a cleaner and more platform independent interface to the gpio hardware.

I think the difference happens when one has built the software on a non Raspberry Pi platform (as I do on my desktop Mac for development.)

A more careful review of the code may reveal that particular set and test of gpio pins are used to detect the PiDP-8/i hardware, but I suspect it's all just, "send to and listen from gpio pins if the gpio hardware exists, because we are running on Pi hardware."

Another test would be to run a benchmark on a Pi with without the PiDP-8/i hardware attached.  But I think that involves opening up Mike's current "I've finished fiddling, close it up and never re-open it," hardware instance.  Indeed, I don't plan on opening mine up any time soon.

-Bill

[Heinz-Bernd Eggenstein]

AFAIK, there is nothing in the code that can actually detect whether a PiDP-8i panel is plugged into the Raspi’s GPIO header or not.

What the executable does tho, first thing after starting, is to check which name was used to call it. If it is just “pidp8i” , the code will set an internal flag that basically means: “assume there is no PiDP-8i board connected, so don’t bother to interact with LEDs or switches or whatever over GPIO.” This happens during the build process when the pidp8i version of the simulator is called to perform some tasks like compiling and patching code under OS/8. So when you benchmark the build process, the new ILS code or even the presence or absence of the panel should have no effect whatsoever on the runtime because all this gets disabled when calling “pidp8i”. However, the new cycle realistic code works (mostly) the same whether a panel is present or not (with the exception of treating some switches differently), so theoretically the build could take a tiny bit longer with the new code. But perhaps the I/O is masking that effect.

[Mike Katz]

Bill,

I've taken the plunge and opened my PiDP-8/I and I am building a second one.

I'm sorry I was unable to start the benchmarks this week, I had several job interviews and other projects going on.  My wife has a 3 day craft fair this weekend so I will start on Tuesday.

Thank you for your patience,

              Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/767791d5-5e56-43af-bb2c-7832604bbfadn%40googlegroups.com.

[Mike Katz]

HB,

What command name should I use when invoking simh for my benchmarks?

         Mike

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/2b7fa1c0-5c58-4ddf-a48e-caa22c5bdba4n%40googlegroups.com.

[Heinz-Bernd Eggenstein]

I think I got the names wrong: The executables in the newest branch with new ILS and cycle realistic code are:

pdp8 # run w/o PiDP-8/I extensions

pidp8i-sim-nls # run with forced NLS mode 

pidp8i-sim-ils # run with forced ILS mode

The first would be cycle-realistic , but no pidp8i panel logic. That could be benchmarked against the same executable in older versions if you want to make sure to just benchmark cycle-realistic and not the GPIO code

The other version are both useful to benchmarkj a specific LED mode

Cheers

HB

[Mike Katz]

Oscar,

Sign me up also.

And then would you consider doing a PDP-12?

On 8/29/2024 8:29 AM, 'Heinz-Bernd Eggenstein' via PiDP-8 wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/2b7fa1c0-5c58-4ddf-a48e-caa22c5bdba4n%40googlegroups.com.

[Mike Katz]

Steve,

Since Oscar seems to be unavailable do you know if I can get the mechanical drawing for the led retainer bracket.  I can then either print it on my 3d printer por better yet cut it out of plastic or wood with my laser engraver/cutter.

Thanks for everything,

           Mike

On 8/28/2024 2:26 PM, Steve Tockey wrote:

[Steve Tockey]

Mike,

Sorry I don't know the answer. Oscar is quite open to sharing things so I'm sure he would make it available if you asked. I just don't recall ever seeing it already posted somewhere.

On the other hand, it's a very simple piece of material. Just verify the outer diameter of your LEDs is 4mm then work out the spacing between each one. For best accuracy,, measure the total distance across a complete row or down a complete column (subtracting one LED diameter to get the center-to-center length) then divide that by the number of LEDs minus 1. That would give you the most accurate spacing between them. Everything is really quite regular so it should not be difficult to put together the file for a 3d printer or laser cutter.

Good luck,

-- steve