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

[William Cattey]

To the question, "What sort of support should we have for deposit invert?" I will remind people that, for a long time, there was the "Serial Port Mod" See: https://obsolescence.wixsite.com/obsolescence/pidp-8-serial-modification

It turns out that a more general solution evolved, but there is precedent to document other options.

My take-away from the "Serial Port Mod" experience is that additional options are good to offer, and they evolve over time.

I would like to keep this thread focused more on the question of "How to offer the best evolution of the inverted deposit switch option."

-Bill

[William Cattey]

It seemed like I was going to have to dig in and become an expert on gpio operation.  Instead I decided to throw the problem over to claude.ai and see if it could sort it out.  It produced a credible analysis of root cause and an alternate implementation that I have tested.

Below is a verbatim paste-in is what claude.ai had to say.  I'd be grateful if others would review the analysis and see if it seems correct.

Originally, Pasco explicitly put the inversion in the report_ss instead of the debounce code, saying that it seemed best to change it as late as possible. However it seems that the change needs to be as early as possible, otherwise there is a conflict between the internal and external state of the switches.

Pasco, after reading the analysis, does this change seem correct to you?

Others: I'd be grateful for additional review.

-Bill

---- Begin paste-in from claude.ai ----

PiDP-8/I DEP Switch Inversion Bug - Root Cause Analysis
========================================================
Bill Cattey and Claude.ai, February 2026

PROBLEM SUMMARY
===============

When the --invert-dep configuration option is enabled, the system hangs during
OS/8 restart (Load Address 7600 / Start). The system becomes completely
unresponsive, requiring a power cycle to recover.

Initial testing showed the DEP switch working correctly in isolation, but the
hang occurs specifically during the OS/8 boot sequence.


ROOT CAUSE IDENTIFIED
=====================

The bug is NOT a race condition or timing issue. It's a **permanent state
mismatch** between internal and external switch state variables caused by
inverting the switch value at the wrong point in the code flow.

The State Mismatch
------------------

The original patch placed the inversion in report_ss():

    static void report_ss(int row, int col, int ss, struct switch_state* pss)
    {
        pss->stable_state = ss;        // Line 1: Store BEFORE inversion
        pss->last_change = na_ms;

        int mask = 1 << col;
    #ifdef INVERT_DEP
        if (row == 2 && mask == SS2_DEP)
            ss = !ss;                  // Line 2: INVERT here
    #endif
        if (ss) switchstatus[row] |=  mask;   // Line 3: Store AFTER inversion
        else    switchstatus[row] &= ~mask;
    }

This creates a critical problem:
1. **Line 1**: gss[].stable_state is set to the NON-inverted value
2. **Line 2**: ss is inverted
3. **Line 3**: switchstatus[] is set to the INVERTED value

Result: The two state variables DISAGREE and never get corrected.


Demonstrating the Bug
---------------------

Testing with debug output on an UNMODIFIED board (DEP in standard orientation)
with --invert-dep enabled shows the mismatch:

    BEFORE THE FIX:
    DEP: count=1000, gpio_ss=1, gss_stable=1, switchstatus=0
   
    gpio_ss=1       <- GPIO reads DEP as open (physically open)
    gss_stable=1    <- Internal state thinks it's open
    switchstatus=0  <- External state reports it as CLOSED
   
    MISMATCH! Internal and external state disagree.


Why the Mismatch Never Corrects
--------------------------------

The debounce_switch() function is called on every GPIO scan for every switch:

    static void debounce_switch(int row, int col, int ss, ms_time_t now_ms)
    {
        struct switch_state* pss = &gss[row][col];

        if (!gss_initted) {
            // First time: calls report_ss(), creates the mismatch
            report_ss(row, col, ss, pss);
        }
        else if (ss == pss->stable_state) {
            // Subsequent scans: ss=1, stable_state=1, they MATCH!
            // Just resets timer and returns, never calls report_ss() again
            pss->last_change = na_ms;
            return;
        }
        // ... other cases for actual switch changes
    }

After initialization:
1. GPIO reads DEP = 1 (physically open)
2. gss[].stable_state = 1 (stored before inversion)
3. Condition "ss == pss->stable_state" is TRUE (1 == 1)
4. Code takes the "line 372" path: just resets timer and returns
5. report_ss() is NEVER called again
6. switchstatus[] stays frozen at 0 (inverted value from initialization)

**The mismatch is permanent for the entire session.**


Why This Causes the System Hang
--------------------------------

With switchstatus[] showing DEP as permanently closed (0):

1. SIMH thinks the DEP switch is constantly pressed
2. During OS/8 boot, this can:
   - Trigger spurious deposit operations at critical moments
   - Block boot sequences waiting for DEP to be released
   - Corrupt initialization of critical data structures
3. The "hang" is actually SIMH responding to what it thinks is a held-down
   DEP switch during the sensitive boot sequence


THE SOLUTION
============

Move the inversion to debounce_switch() BEFORE any state management:

    static void debounce_switch(int row, int col, int ss, ms_time_t now_ms)
    {
        struct switch_state* pss = &gss[row][col];

    #ifdef INVERT_DEP
        // Invert the raw GPIO value BEFORE any processing
        // This ensures BOTH gss[].stable_state AND switchstatus[]
        // see the same inverted value
        if (row == 2 && (1 << col) == SS2_DEP) {
            ss = !ss;
        }
    #endif

        if (!gss_initted) {
            report_ss(row, col, ss, pss);  // Now stores inverted value in BOTH places
        }
        else if (ss == pss->stable_state) {
            pss->last_change = na_ms;
        }
        // ... rest of function
    }


Why This Works
--------------

Now the inversion happens at the RAW GPIO read level, before any state
management:

1. GPIO reads DEP = 1 (physically open)
2. **Inversion happens immediately**: ss = !1 = 0
3. debounce_switch() processes ss=0
4. report_ss() is called with ss=0
5. Sets gss[].stable_state = 0
6. Sets switchstatus[] = 0
7. **BOTH state variables agree: DEP is closed (inverted from physically open)**

This consistency is maintained for:
- Initial GPIO scan during initialization
- All subsequent scans during normal operation
- Actual switch state changes (debouncing logic sees consistent values)


VERIFICATION
============

Testing with debug output after the fix shows consistency:

    AFTER THE FIX:
    DEP: count=1000, gpio_ss=1, gss_stable=0, switchstatus=0
    DEP(after):  inverted_ss=0
   
    gpio_ss=1       <- GPIO reads DEP as open (physically open)
    inverted_ss=0   <- Inversion happens immediately
    gss_stable=0    <- Internal state: inverted to closed
    switchstatus=0  <- External state: inverted to closed
   
    ALL THREE AGREE! State is consistent.


Functional Testing
------------------

With the fix in place:

1. ✅ OS/8 boots successfully to monitor dot prompt
2. ✅ No hang during initial boot
3. ✅ No hang during restart (boot rk0 from sim> prompt)
4. ✅ System remains responsive to Ctrl-E
5. ✅ Can cleanly quit simulator
6. ✅ State consistency maintained throughout all operations


THE CODE CHANGES
=================

File: src/pidp8i/gpio-common.c.in

Change 1: Remove from report_ss()
----------------------------------

REMOVE the entire #ifdef INVERT_DEP block, leaving:

    static void report_ss(int row, int col, int ss,
            struct switch_state* pss)
    {
        pss->stable_state = ss;
        pss->last_change = na_ms;

        int mask = 1 << col;
        if (ss) switchstatus[row] |=  mask;
        else    switchstatus[row] &= ~mask;

        #ifdef DEBUG
            printf("%cSS[%d][%02d] = %d  ", gss_initted ? 'N' : 'I', row, col, ss);
        #endif
    }


Change 2: Add to debounce_switch()
-----------------------------------

ADD the inversion block at the beginning, right after the pss declaration:

    static void debounce_switch(int row, int col, int ss, ms_time_t now_ms)
    {
        struct switch_state* pss = &gss[row][col];

    #ifdef INVERT_DEP
        // If the DEP(osit) switch is mounted in reverse orientation, i.e.
        // active "up" as on a real PDP-8/I, invert the raw GPIO value here
        // BEFORE any debouncing or state management. This ensures both
        // gss[].stable_state and switchstatus[] see the same inverted value.
        if (row == 2 && (1 << col) == SS2_DEP) {
            ss = !ss;
        }
    #endif

        if (!gss_initted) {
            // First time thru, so set this switch's module-global and
            // exported state to its defaults now that we know the switch's
            // initial state.
            report_ss(row, col, ss, pss);
        }
        // ... rest of function unchanged


SUMMARY
=======

The fix is minimal: move 6 lines of code from one function to another.

The impact is significant: it eliminates a permanent state mismatch that
caused the system to think DEP was constantly pressed, leading to hangs
during OS/8 boot.

The key insight: State transformations must happen at the raw input level,
BEFORE any state management, to ensure consistency across all code paths.


ATTRIBUTION
===========

Original --invert-dep patch by: Pesco
Root cause analysis and fix: Co-authored by Bill Cattey and Claude.ai
Testing: Bill Cattey


TESTING NOTES
=============

The testing was performed on an UNMODIFIED PiDP-8 board (DEP switch in
standard orientation, active-down) with --invert-dep enabled. This "reverse
polarity" test proves:

1. The state consistency bug exists with the original patch placement
2. The fix resolves the state consistency issue
3. The inversion logic works correctly (just backwards on unmodified hardware)

For users with modified boards (DEP installed upside-down, active-up), the
fix should work correctly with --invert-dep enabled, providing the authentic
PDP-8/I switch orientation.

Note on Misconfiguration Behavior
----------------------------------

When --invert-dep is enabled on unmodified hardware (reverse polarity test),
the debouncing logic operates on an inverted signal. This can cause switch
bounce artifacts. For example, during a front panel test sequence:

    Load Address 200; Examine; Load Address 200; Set SR to 7000; Deposit

The deposit didn't occur until the DEP switch was released (physically opened,
seen as closed after inversion). During release, the switch bounced and
deposited the value to location 201 instead of 200.

This is expected behavior when debouncing an inverted signal - the debounce
logic sees transitions at opposite edges from the physical switch operation.
While this demonstrates why --invert-dep should only be used with modified
hardware, it's a benign outcome (slight timing glitch) rather than a
catastrophic failure (system hang).

The key point: The original bug caused PERMANENT state mismatch leading to
system hangs. The fix eliminates this mismatch. Any bounce artifacts from
misconfiguration are transient and non-destructive.


RECOMMENDATION
==============

This fix should be merged to the invert-deposit branch and tested by Pesco
on actual modified hardware before merging to trunk.

The fix resolves a definite bug in state management that prevented the
--invert-dep feature from working correctly.