Inverting the deposit switch in software

[Sven Moritz Hallberg]

Hi all,

I made a post to the fossil forum on tangentsoft.com some months ago, but it has been stuck "awaiting moderator approval"...

I don't normally use this gmail account - is there any way to participate in this group with a regular email address?

Anyhow, below is a copy of my post:

I recently got the PiDP-8 kit and it's awesome!

However, I did not realize during the build that the Deposit switch is mounted in the opposite orientation on the real thing. Of course I had to turn it around! A stressful (but successful) bit of desoldering ensued...

Anyway, I patched the software to invert the signal, selected with a configure flag (--invert-dep).

I chose to introduce the inversion in the function report_ss() because it forms a bottleneck between the lower-level GPIO handling and its higher-level "user" code, so both sides can remain otherwise oblivious to this. The function is only called when the switch state actually changes (after debounce) so the extra code does not run on every scan.

Patch against Fossil trunk [3fee766e68] below. Tested with pidp8i-test.

Regards, pesco

PS: With this (not requiring a hardware mod), maybe a note could be placed in the build instructions about the possibility. It would have saved me some rework. ;)

[William Cattey]

Hello Sven,

My profuse apologies for taking so long to respond usefully to your contribution.

I've looked at your patch, and it is clear that you put in the extra work to understand how to add an option through auto.def and that you did it correctly.  I also like where you placed the code to perform the inversion.

I have just checked in your patched version to a branch called "invert-deposit".

I'm now pondering what kind of additional testing might be needed to feel totally safe pulling this change into trunk.

I agree that additional documentation should be made. I'll start with adding a description of this new option to the top level README.md in the branch.

Would you please do a build of the invert-deposit branch and confirm that your changes work. (I.E. that I've correctly taken them.)

-Bill 

[William Cattey]

I see I should have addressed my reply to Pesco. Sorry.

I've done a build with the invert deposit logic enabled on my PiDP-8.  I wondered, "What would happen if that option were chosen on a machine that did not have the hardware mod?"

Alas, I encountered what I believe is a show-stopper.

At first things seemed fine.  The Deposit switch remained inactive when I depressed it, and then when I released it, the deposit was successful. I did that a couple times to confirm all was well. Indeed all seemed well.

I then restarted OS/8 with the traditional, Load Address 7600 / Start.  I saw the monitor dot prompt and figured, "We're good."  Alas, the system was now hung.  Both my terminal windows into my Pi went unresponsive, and then timed out.  I had to power-cycle the machine to get it back.

So there's something toxic going on here that requires further investigation.

I'm quite hesitant to dig into this because I believe that every non-graceful power off is a non-zero chance of corrupting my system image.

Pesco, Oscar, we need to collaborate on this if we're gong to make a go of this for the next release.

-Bill

[Sven M. Hallberg]

William Cattey on Sun, Nov 09 2025:

> I've done a build with the invert deposit logic enabled on my PiDP-8. I
> wondered, "What would happen if that option were chosen on a machine that
> did not have the hardware mod?"

I think the answer should be "the same as in the following scenario:"

- original software (no invert-dep)
- unmodified circuit board
- switch soldered in the "authentic" orientation

I.e. the switch looks permanently engaged, unless you press it which
momentarily disengages it. Is that the behavior you were seeing?

> Alas, I encountered what I believe is a show-stopper.

I'm not sure I follow. The config option is only meant for the situation
where someone has soldered the switch in "inverted" orientation
(relative to Oscar's instructions).

So one wouldn't enable this by default. It's for tinkerers who don't
mind compiling their own software but would rather not cut a trace on
the board.

Or am I misunderstanding?

An obvious improvement would be a run-time (rather than compile-time)
switch, I guess. However, I wanted to start with something simpler to
implement that's already useful. I judged the trade-off that one needs
to rebuild the software acceptable.

> Pesco, Oscar, we need to collaborate on this if we're gong to make a go of
> this for the next release.

>> I agree that additional documentation should be made. I'll start with
>> adding a description of this new option to the top level README.md in the
>> branch.

I was thinking of a careful hint in the build instructions that this
option exists. It would have saved me a round of resoldering.

-pesco

PS: I tried the invert-deposit branch and the build worked fine. I
booted into TSS/8, logged in and started BASIC without issue. My
blinkenlights go blink.

[William Cattey]

Hello pesco,

My profuse apologies for the delay in replying. I've been swamped with non-PiDP-8 stuff through most of December. Let me clarify, and see if we can move this conversation forward.

First let me see if I can give you a more complete understanding of the testing I did, what I had hoped for as the outcome, what my actual results were, and why I think that it's a problem.

I would very much like to incorporate either your patch, or one with equivalent functionality into the PiDP-8 release. I agree with your initial principle that it would be ideal if a simple software change would enable builders of the PiDP-8 to just "solder the deposit switch in upside-down, and set the configuration option to use it.

The only platform I have available for testing is my own PiDP-8, where I cut a trace, put in a bodge-wire, and soldered in the deposit switch upside down with the regular software.

In your reply you say:

So one wouldn't enable this by default. It's for tinkerers who don't
mind compiling their own software but would rather not cut a trace on
the board.

What would you think of a new default? Change the instructions to tell people to solder in the switch upside-down and use the "invert-deposit" version of the software?

I'd hoped to offer that as a more mainstream option. But when I tried the invert-deposit option on my test host, it initially seemed benign. I.E. if someone with a regular build ran that option nothing bad would happen. Unfortunately, on one of my test runs, the whole system hung, and I had to power cycle to get my system back. I believe that, when one un-gracefully power-cycles a Pi, it's a roll of the dice as to whether the system image gets corrupted. I got my system back but have been afraid to do more testing ever since.

I don't like the option of, "If you want to tinker, and solder in the deposit switch upside, down and compile with this option enabled it will work, but if you run this option on a stock system it will hang requiring a power cycle, which may corrupt your system image requiring a start agin from scratch."

This is why I called for additional collaboration.

As you said in your reply:

I.e. the switch looks permanently engaged, unless you press it which
momentarily disengages it.

Apparently that state of "permanently engaged" can result in the whole Raspbery Pi OS being out in lala land, unable to be interrupted or shut down cleanly.

I'd like to understand how that happens, and add code to prevent such a hangup. Then if someone tries out the option, the risk of catastrophe is eliminated.

@Oscar, @Steve Tokey, or anybody who understands the gpio code better than I, what made the system hangup, and can it be prevented?

-Bill

[Steve Tockey]

Bill,

Sorry but I don't understand GPIO code itself very well. I don't think I can offer any help on this.

-- 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 visit https://groups.google.com/d/msgid/pidp-8/3c6eeee1-ea2b-4366-8661-e2ef3dd38563%40gmail.com.

[Sven M. Hallberg]

William Cattey on Sun, Jan 04 2026:

> What would you think of a new default? Change the instructions to tell
> people to solder in the switch upside-down and use the "invert-deposit"
> version of the software?

If I understand correctly, Oscar made the deliberate choice to have all
switches in the same orientation because it makes the instructions
simpler. A trade-off between authenticity and ease of building. I worked
on the assumption that "easier building" would remain the default.
Whether to change that or not is an orthogonal question in my mind.

> I'd hoped to offer that as a more mainstream option. But when I tried
> the invert-deposit option on my test host, it initially seemed benign.

> [...]
> I don't like the option of, "[...] but if you run this option on a
> stock system it will hang [...]"

Any such effects would also be seen when someone decided to solder the
switch upside-down and ran the stock software. Nothing in the
instructions implies or should imply that one could do this and expect
things to work.

My proposal is to keep everything as is (staying with the easy-to-build
way of all switches in the same orientation) but to just add a note to
the build instructions that says (in effect) "actually, this is not
quite authentic - if you would like it proper, you can solder Dep in
upside-down but must then adapt the software by building it with
--invert-dep."

Or are you saying even this will create a significant incidence of
people doing it wrong despite instructions to the contrary?
A remedy I could think of would be to put a time-out on Dep, i.e. to
internally force the signal low if it remains engaged for more than,
say, a second or something. I don't know how much complexity that would
be and to me it feels like wasted effort, but that might just be me.

> Apparently that state of "permanently engaged" can result in the whole
> Raspbery Pi OS being out in lala land, unable to be interrupted or shut
> down cleanly.

That seems strange. Even if simh hung itself up somehow when faced with
a permanently engaged Deposit switch, how could that bring the OS down?

[Steve Tockey]

Sven and all,

Thinking about this a bit more ...

Sven wrote: "If I understand correctly, Oscar made the deliberate choice to have all switches in the same orientation because it makes the instructions simpler. A trade-off between authenticity and ease of building. I worked on the assumption that "easier building" would remain the default."

That is my understanding as well. Oscar has said--more than once, I believe--that simplicity of build is usually more important than fine-grained authenticity. I would take any action moving forward around decisions on this topic with the mentality that if someone truly wants the fine-grained authenticity then they must be willing to take on some additional level of complexity in building & setting up their PiDP-8/i.

Sven wrote: "Any such effects would also be seen when someone decided to solder the switch upside-down and ran the stock software. Nothing in the instructions implies or should imply that one could do this and expect things to work."

It's true that nothing in the instructions implies anything of this sort. It's only my own many, many years of PDP-8 experience that led me to want to flip the DEP switch. And I took it upon myself to make it happen (without any software change). I would actually prefer if the instructions did mention that there is an at-your-own-risk option here and provide a pointer to where instructions to make the change existed. I've written up the hardware version (cut one trace, solder in a jumper) of it in this discussion group elsewhere, so it could be as easy as cut-and-paste.

Sven wrote: "My proposal is to keep everything as is (staying with the easy-to-build way of all switches in the same orientation) but to just add a note to the build instructions that says (in effect) "actually, this is not quite authentic - if you would like it proper, you can solder Dep in upside-down but must then adapt the software by building it with --invert-dep.""

I'm not sure that a software-only solution should be the only option offered to the builder. The hardware fix is just as effective and leaves the software untouched.

Sven wrote, "That seems strange. Even if simh hung itself up somehow when faced with a permanently engaged Deposit switch, how could that bring the OS down?"

This is where I've really been puzzled. The state of the IF, DF, and SR switches are completely up to the PiDP-8/i user, and can be left on or off long-term. There should not be any issue--at least theoretically--with leaving any front panel switch in a normally-on vs. normally-off configuration. The other thing, which I would have to check in more detail, is that isn't the number of switches on the front panel larger than the number of input data pins on the GPIO? Aren't the inputs multiplexed in the same way that the outputs to the LEDs are? If so, then whatever input pin is co-multiplexed to the same one DEP uses should cause the same crash? If not, then the cause of the crash has to be farther along in the SIMH processing than just the raw GPIO-level?

-- steve

[Bob Darlington]

I flipped my switch over, cut a trace, and ran a bodge wire.    It wasn't a big deal, just wish I caught it before soldering the switch in the first time around.

-Bob

--
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 visit https://groups.google.com/d/msgid/pidp-8/CAHF_aixCicV7ya_eH0t%3DQj5i1Mx-qjihBshnxH_1Nov4Gf56yQ%40mail.gmail.com.

[Sven M. Hallberg]

Steve Tockey on Wed, Jan 07 2026:

> I'm not sure that a software-only solution should be the only option
> offered to the builder.

Pointing to both options is of course fair. My personal preference was
for a software solution because...

> The hardware fix is just as effective and leaves the software untouched.

... this sentence works just as well with the words "hardware" and
"software" swapped. :)