Reversed rotary encoder action

[Robert S]

Hope this message goes through - I've posted this same message twice before and it appears as if the message is getting deleted from the "Show us your kits" thread where another user posted about this issue, so trying a new thread.

Anyway, in my case I have one encoder that lights the LEDs in the correct order and the other LED lights the LEDs in reverse.  Based on my read of the other threads discussing this issue, it appears as if the currently known fixes apply to *both* encoders.  Is it even possible to apply such a fix to just one of the encoders?  When assembling my kit I noted that my two rotary encoders were very obviously different parts so I suspect that is the root cause of my "one encoder only is wrong" issue.  Thanks.

Robert

[Nick M]

That message seemed to work :)

I'm new to all this, so this isn't official! (not even sure posting code is allowed here? Apologies if not.) here's a quick and dirty thing I just tried in gpio.c:

        // detect end of rotation
       for (i=0;i<2;i++)
       {
               if ((code[i]==3) && (lastCode[i]==1))
               {
                       lastCode[i]=code[i];
                       switchscan = switchscan + (1<<((i*2)+8));
//                      printf("%d end of UP %d %d\n",i, switchscan, (1<<((i*2)+8)));
//                      knobValue[i]++; //bugfix 20181225
                       if (i==0) knobValue[i]++;else knobValue[i]--; // adjust based on knob #
 
               }
               else if ((code[i]==3) && (lastCode[i]==2))  
               {
                       lastCode[i]=code[i];
                       switchscan = switchscan + (2<<((i*2)+8));  
//                      printf("%d end of DOWN %d %d\n",i,switchscan, (2<<((i*2)+8)));
//                      knobValue[i]--; // bugfix 20181225
                       if (i==0) knobValue[i]--;else knobValue[i]++;
               }    
       }

and it reverses only one of my knobs. Those boldfaced lines are the new ones (as well as commenting out the line above them). Basically, "i" tells you which knob, so you can make the adjustment based on i (and if this reverses both knobs, change swap the two ++ with the two - -).

  -Nick

[Robert S]

Hi Nick - thank you for the quick response to my question!  Having never messed with the sources before, what is the proper sequence of steps once I modify gpio.c per your message?  Assume I just go through the install again and use the "build from source" option?  Or is there a more surgical way to install this change I should be considering?  Thank you.

Robert

[Nick M]

Hi Robert,

For my setup, I just went into /opt/pidp11/src/11_pidp_server/pidp11/ and then said

  make all

Again, I'm still figuring this stuff out, so your mileage may vary. In particular, I'm not worried if my PiDP-11 code base shifts away from the standard setup :)

 Cheers, -Nick

[Robert S]

Thanks again, Nick!

This may be obvious to the more experienced among us but in my case, simply using "make all" produced all sorts of compile errors.  Note that I'm compiling directly on a Pi but I still had to explicitly add the Pi as the build target, which I don't fully understand.  The command that worked for me was: "make all MAKE_TARGET_ARCH=RPI"

Robert

[Nick M]

Ah yes, my bad. At the top of the makefile I added

  MAKE_TARGET_ARCH=RPI

which specifies the target architecture (same as you did on the command line).

> still had to explicitly add the Pi as the build target, which I don't fully understand

The makefile looks to be general-purpose, for the Pi, BeagleBone or X86, so some of the directories etc. vary based on your build target.

And hey, thanks for the STL files for your 2-post rack! I love the design. It's about half printed now - appreciate your posting those files :)

 -Nick

[terri-...@glaver.org]

On Sunday, December 28, 2025 at 6:02:41 PM UTC-5 resi...@sbcglobal.net wrote:

Anyway, in my case I have one encoder that lights the LEDs in the correct order and the other LED lights the LEDs in reverse.  Based on my read of the other threads discussing this issue, it appears as if the currently known fixes apply to *both* encoders.  Is it even possible to apply such a fix to just one of the encoders?  When assembling my kit I noted that my two rotary encoders were very obviously different parts so I suspect that is the root cause of my "one encoder only is wrong" issue.  Thanks.

That was definitely a kitting error by Oscar (earlier kits) or CEDS (later kits) as both

encoders should be the same, just like all LEDs should be the same size, shade of

red, and brightness.

What likely happened is that Oscar / CEDS said "send me 500 more" to the same

supplier they had been using, got a bag with the same part number as before, and

put them in the bin with the few remaining older parts.

If you're comfortable with de-soldering one of the rotary switches, send pictures of

both to CEDS and ask for a replacement that matches one of yours. Then de-solder

the different one and install the replacement.

While there is support for both old-style and new-style encoders in my fork (which

will eventually become the official version), mismatched encoders is not something

that happens often enough (I think yours is the second or third case I've heard of in

6500+ shipped kits) to support. 

[terri-...@glaver.org]

On Sunday, December 28, 2025 at 6:37:25 PM UTC-5 nicholas...@gmail.com wrote:

That message seemed to work :)

I'm new to all this, so this isn't official! (not even sure posting code is allowed here? Apologies if not.) here's a quick and dirty thing I just tried in gpio.c:

 Posting code snippets like this is definitely OK.

  

//                      printf("%d end of UP %d %d\n",i, switchscan, (1<<((i*2)+8)));
//                      knobValue[i]++; //bugfix 20181225
                       if (i==0) knobValue[i]++;else knobValue[i]--; // adjust based on knob #

You need to be careful because there are umpteen versions of the PiDP-11 code

floating around, none of which were under any sort of revision control. That's why

I asked Oscar to move to GitHub.

It is quite easy to make the build go "kaboom" or just not produce working code 

if you are starting with one of the pre-GitHub versions.

For the GitHub ones (either Oscar's or mine), in theory:

cd /opt/pidp11/src

./makeserver.sh

./makeclient.sh 

should work. Sometimes they don't notice that a source file has been changed

and don't do anything.

[Nick M]

cd /opt/pidp11/src

./makeserver.sh

./makeclient.sh 

Wow that's much simpler than what I've been doing! And yeah, I can see how over time things could diverge into many different versions.

[Bradford Miller]

On Dec 29, 2025, at 12:07 AM, terri-...@glaver.org <terri-...@glaver.org> wrote:

You need to be careful because there are umpteen versions of the PiDP-11 code

floating around, none of which were under any sort of revision control. 

Was “revision control” even a thing back in the day?! I recall running debuggers 24/7 on customer sites to trap out

certain states and do something else instead. So we had patches that never even made it back to any kind of central

repository, and given that every customer had different installations I’m not sure how we would have dealt with it anyway.

That was on top of customizing the system for each customer, where at least we DID have a copy back at HQ.

Even post that experience, the next job had a “golden disk pack” that had some release version on it, and we call copied

that as our base to work on. Merges could take a while (to generate a new golden disk pack), but we didn’t have any 

formal QA, just complaints by everyone if you merged in a change that broke something. (Eventually we had some 

regression tests we needed to run first, though they were hardly complete coverage).

I think my first encounter with an actual modern source control system was around 1996… 

though that may be partly because I got fed up and went back to a university in 85, so I’m not completely clear

on what industry was doing in the interim.

I just think of it as getting the “full retrocomputing experience”. ;-)

[Malcolm Ray]

Bell Labs' SCCS (Source Code Control System) dates back to the early 1970s. Most people outside Bell Labs probably encountered it as part of the "Programmer's Workbench" edition of Unix V6 or V7, in the late 1970s.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/7C8050DF-B3AE-4378-A386-BDD76FAB2727%40gmail.com.

[Johnny Billquist]

Yeah. Revision control system isn't anything new.
SCCS is the first one I know of, but there might have been something
earlier as well.
A fair number of people got into it with RCS in the early 80s. RCS is
still being developed. CVS then showed up in 1990, based on RCS but
adding a client/server model so you could develop on different machines,
in different places, and have a shared common revision control system
for them all.
And that then leads to SVN, and so on.

Johnny

On 2025-12-29 15:49, Malcolm Ray wrote:
> Bell Labs' SCCS (Source Code Control System) dates back to the early
> 1970s. Most people outside Bell Labs probably encountered it as part of
> the "Programmer's Workbench" edition of Unix V6 or V7, in the late 1970s.
>
> On Mon, 2025-12-29 at 09:24 -0500, Bradford Miller wrote:
>>
>>
>>> On Dec 29, 2025, at 12:07 AM, terri-...@glaver.org <terri-

>> <mailto:pidp-11+u...@googlegroups.com>.

>> To view this discussion visit https://groups.google.com/d/msgid/

>> pidp-11/7C8050DF-B3AE-4378-A386-BDD76FAB2727%40gmail.com <https://
>> groups.google.com/d/msgid/pidp-11/7C8050DF-B3AE-4378-A386-
>> BDD76FAB2727%40gmail.com?utm_medium=email&utm_source=footer>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "[PiDP-11]" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to pidp-11+u...@googlegroups.com

> <mailto:pidp-11+u...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/pidp-11/

> b0f06c24f69dd16ea3641c9248a66bb11fc5ce39.camel%40apathetic.org.uk
> <https://groups.google.com/d/msgid/pidp-11/
> b0f06c24f69dd16ea3641c9248a66bb11fc5ce39.camel%40apathetic.org.uk?
> utm_medium=email&utm_source=footer>.

--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol

[Glenn Babecki]

Yeah, used SCCS extensively while working on UNIX at Bell Labs Holmdel back in the late 70's.  We ended up writing a lot of shell scripts to create the kind of manifest related features that later source control systems implemented.  Good times, good times.

Somewhere I still have a source listing of some UNIX version.  I've been meaning to dig that out with all the hubbub surrounding the recently found V4 tape.  I'll have to look at what machine it was targeted, but it was likely a PDP-11-70.  It would take an OCR scan and a lot of checking, or a whole lot of typing to re-enter it, but being retired probably makes it hard to find an excuse to not proceed. 😉

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/c2336eba-cedf-416e-9642-56bb3b3cc733%40softjar.se.

[terri-...@glaver.org]

On Monday, December 29, 2025 at 9:24:56 AM UTC-5 bradford...@gmail.com wrote:

Was “revision control” even a thing back in the day?! I recall running debuggers 24/7 on customer sites to trap out

certain states and do something else instead. So we had patches that never even made it back to any kind of central

repository, and given that every customer had different installations I’m not sure how we would have dealt with it anyway.

Yes. Some were even developed and used on the PDP-11 operating systems we use on the PiDP-11. 8-}

But it didn't become mandatory until programming project staffs got large, had employee turnover,

etc. I don't know about OS/360 and its descendents. The HP 3000 definitely didn't at first,  or the

impossibility of creating a deliverable OS that met all the goals would have been obvious.

On the PDP-11, the various Unixes* had several different revision control systems. DEC's RSTS/E

had a homebrew system that at least let you find who to blame when something broke. I don't

know about the other DEC operating systems.

* Apologies to whoever holds the "Unix" trademark this week. It's poor form to pluralize trademarks.

Of course, Bell brought some of this on themself back in the day when commercial licensees were

not allowed to call their products "Unix". So we got the "hundred kingdoms" of Xenix, genix, etc.

[David Johnson at Brown]

Of all the various *-ix brands out there, I believe the most ill advised one was rolled out by Perkin-Elmer.

I can't find any reference online, but I recall their SVr3 release was pe-nix.

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/87c84ff7-ed2d-4841-ba12-a4dd181fdc0bn%40googlegroups.com.

[Malcolm Ray]

It would be fascinating to see your listing. Perhaps it will even fill a gap in the history, like the V4 find!

When I feel the urge to look at historic Unix source, I reach for my samizdat copy of the Lions book, one of the most frequently photocopied textbooks ever!

[Glenn Babecki]

I'll see what I can do about getting an electronic copy, at least scanned.  It may have been very specific to the work I was doing at the time.

I may have other (later?) versions on mag tape, but I fortunately I don't have access to a drive.

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/55cb6ea2b26461c997b27d89392b0086af845423.camel%40apathetic.org.uk.

[Anton L.]

I personally had a very bad luck with OCR'ing scans of (my) old program listings... (B&W scans were too coarse for them to figure out, color scans were too distracting with the yellowed paper background,  all that in addition to uneven drum printer lines -- and yet I did not want to spend a fortune to buy something only to know it just wouldn't work, all the same)...  Not that they failed completely, but the amount of post-processing looked rather discouraging.

That, until I tried ChatGPT (not advertising!).  It did a scanned color page in no time, and the result was absolutely impressive (compared to what I had seen previously).  Inspired by that,

I asked it to do the next page, and it politely replied that only a paid subscription allows more than a page per day.  Well, for $20 (the cost of one month) I had all pages OCR'd in a couple

hours, the way I liked them -- I explained it was MACRO-11, asked to use tabs, all caps, etc, and it got it all neat and in style.  Well, that was probably my best $20 ever spent -- 'cuz a possibility of retyping everything had already crossed my mind, after all the failures.

There were a few typos, though, so you have to check, naturally, but one impressive thing happened was that (I noticed a couple of places) it also added code comments on its own LOL as if it actually figured out what the code was doing.

Your mileage may vary, obviously

[Glenn Babecki]

Anton,

Great tip!  I know vanilla OCR was notoriously sketchy so I wasn't looking forward to applying that to the scan.

Dang, I recently had a $10/month subscription to Gemini Pro that I dropped because I wasn't using it on a regular basis.  I did use it for some circuit design research and was fairly impressed with it compiling a whole bunch of documents that A) I'd have to find and B) read and extract the essential info.  Great idea using an LLM for OCR.  I'll try it on a page or two before deciding to do what you did.  Hmmm, might have to resurrect that subscription. 🤔

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/cb46f60d-cb8a-4673-9cbb-e27d8d0f2f2bn%40googlegroups.com.

[Bert Driehuis]

I used rcs on a PDP/11 around 1984, and got my other employer to purchase the MKS toolkit for MS-DOS around the same time. I ported RCS to VAX/VMS myself, so that was covered too.

When I switched jobs in 1991, my boss did not blink when I requested source code control and coverage analysis software for the new project. The dollar cost of not doing source code control and testing were obvious for anyone to see. All my friends worked at places where source code control was standard, but that may say more about my selection of friends than about the industry :-)

I did not manage to kill FORTRAN and MACRO though, even after I showed the hidden costs (and fixed a couple of nasty issues in the old code in the process).

-- Bert

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/7C8050DF-B3AE-4378-A386-BDD76FAB2727%40gmail.com.

[Bert Driehuis]

The helpful additions by the LLM hurt my archivist's soul :-)    I always prefer historic documents to be as close to the original as possible.

In the past, I've had best results scanning documents to 300 dpi black and white, where the only judgement call is to set the appropriate grey level to separate background from strike. With CCITT G4 compression, the resulting PDF is likely to be of a more or less acceptable size.

The Lions book appears to have been treated with the Adobe Acrobat 9.0 Paper Capture Plug-in to great effect (this one from bitsavers: https://bitsavers.org/pdf/att/unix/6th_Edition/Lions_-_A_Commentary_on_the_Unix_Operating_System_197705.pdf).

-- Bert

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/cb46f60d-cb8a-4673-9cbb-e27d8d0f2f2bn%40googlegroups.com.