Behaviour of 'deposit' on low addresses

[Malcolm Ray]

Experimenting with programming from the front panel, I've observed
strange behaviour when depositing into low addresses. Specifically,
addresses 0 to 6. The virtual panel works as expected, but when using
the physical panel, in some cases a bit gets set which wasn't
requested.

To reproduce this, try the following (with the CPU stopped):

Set address switches to 4
Set test word switches to 2
Push deposit switch up
The memory buffer and accumulator lights display 6, not 2
Confirm this by pushing examine down
Try pushing deposit up repeatedly: sometimes you get 6, sometimes 2

At first I thought I had one or more faulty switches, but I can only
reproduce this problem for the lowest 7 addresses. Addresses above
those behave as expected (well, I haven't tried them all!). For
example, try address 14 (octal). I can't get this to misbehave.

Please tell me that I'm missing something obvious!

[Angelo Papenhoff/aap]

That definitely sounds like a hardware issue. There is a pidp1_test program in the repo, which should display the state of the switches and keys. maybe there's some interference between the switch rows? or more likely between a light row and a switch row due to how the multiplexing works. Anyway, let's hear what pidp1_test says. maybe you see something there.

[Malcolm Ray]

Interesting results! I had run pidp1_test at the appropriate point when building the kit, and all the switches worked as expected. But running it now, I see screwy results. For example, with the rightmost address switch up and all other small switches down, the output shows multiple bits set: 000001 000001 000001 000001. But it's not stable: the ones sometimes flicker to zeroes. With the second rightmost address switch up, I get: 000002 000002 000002 000002, and again the twos flicker to zeroes. If I set both of those switches up, the output is stable at 000003 000000 000000 000000. But then if I also set the rightmost test word switch up, the output changes to 000003 000003 000000 000000 (i.e., changing one switch has flipped two bits).

--
You received this message because you are subscribed to the Google Groups "[PiDP-1]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-1+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-1/f539966e-c42e-4593-9220-bbc1c8470506n%40googlegroups.com.

[Bradford Miller]

I noticed something similar to this building my PiDP-10. The issue for me was that there was minimal clearance between the circuit board and back panel, causing the (sharp) clipped leads  on the circuit board to puncture the ribbon cable connecting the two sections of the the front panel yielding intermittent interference. Inserting an insulating layer of cardboard between the ribbon cable and the circuit board cleared the issue. Perhaps you have a similar issue with a pinch somewhere?

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/bf328c62ef93f2d842f8329221469b1a12f237d3.camel%40apathetic.org.uk.

[Matthias Barthel]

i can reproduce the issue on my rack-version.

tw 1, ta 2 -> deposit-up -> pc 2, ma 2, mb 3, ac 3

tw 1, ta 4 -> deposit-up ->pc 4, ma 4, mb 7, ac 7

with the testprogram all switches off, it displays all zeros, when i test the deposit and examine and its seems to be fine, 
when i set testaddress to 4  we have this 000004 000000 000024 000000 it must be 000004 000000 000020 000000

you can reproduce this with ta 0 to 7 from ta 10 upwards all works fine. 

matthias

[Matthias Barthel]

i tested this with my console version, here is all ok .

but i have build the pcb from the kicad-files from the pidp1 debug site.

i will inspect the pcb from my rack version this evening.

Matthias

[Malcolm Ray]

Thanks for the suggestion. I've examined the PCB and cables with a magnifier, and I can't see any evidence of damage (or shorts, or obvious bad solder joints).

The PiDP-1 rack version doesn't have a back panel, so there's less chance of pinching anyway. There are a couple of places shorts can happen (between the Pi and the PCB, and between the amp and the frame), but I have those safely insulated.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/758800B6-BCF3-4389-8EB6-88BEDB891419%40gmail.com.

[Matthias Barthel]

Malcolm, i take a closer look at my rack version and give a Feedback here.

Matthias

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/84ffa869d1f5ce858e912d76cd37ea9927fb1b01.camel%40apathetic.org.uk.

[Malcolm Ray]

So we both have some "ghosting" of some switches to others, though the details differ a little.

I disconnected the I/O panel and re-ran the test program. The results were much better, and at first I thought the problem was solved, but the rightmost address switch still ghosts slightly.

Try disconnecting the ribbon cable to the I/O panel in your rack version and see what difference it makes.

I've visually inspected the main PCB (no obvious problems), and reseated the ICs, but it made no difference.

I may try touching up the solder joints for the diodes.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/77fbec6b-9f61-40ff-91a3-d7e29d925afdn%40googlegroups.com.

[Angelo Papenhoff/aap]

hm, damn. i'm not sure i have an IO panel around to test. anyway: something you could try right now is the following: panel_pidp1.c has a function readRow() with a sleep in it before we read the switches, maybe it has to be increased a bit so we don't get interference from the last LED row of the IO panel? this makes the multiplexing cycle a bit longer, but that's probably ok. try increasing the usleep(10) to something higher and see if that makes a difference.

[Malcolm Ray]

I think that may have done it! I increased the usleep from 10 to 20, and now I can't reproduce the problem (with the I/O panel connected).

I think I'll modify panel_pidp1.c to get that usleep value from a command line flag or environment variable, and then try different values.

Matthias, perhaps you could try the same change?

[Matthias Barthel]

I'll try this in the evening when the kids are sleeping 🙃👍

Matthias 

[Matthias Barthel]

i change to ulseep(20) & (15) in the panel_pidp1.c - the error is gone - but the LED's are flickering , i change back to (10) the flickering is always there.

[Malcolm Ray]

I had the same thing after my last mail, and I can't explain it. Here's how it went:

I made the usleep change (15 seems to be the lowest I can go and get a reliable test run). When the test program ran ok without switch ghosting, I updated pdp1control.sh to set the usleep period the same, and did 'pdp1control start'. The LEDs flickered like crazy (but otherwise it seemed to be running ok). I rebooted: still flickering. I power cycled: still flickering. I thought something was permanently broken. But, clutching at straws, I then moved /opt/pidp1 aside and did a reinstall from scratch. Now the flickering was gone (but the ghosting was back). I re-applied the usleep fix, and now I have a flicker-free and ghosting-free machine.

I really can't explain this, other than to suggest it's Halloween and the machine is haunted. Seriously though, I'm expecting the flickering to come back at any time. We now have three reports of this happening, including with unmodified software.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/eb35fa64-dee0-415a-b2aa-5043e4470121n%40googlegroups.com.

[Glenn Babecki]

Malcolm,

See my "explanation" regarding the LED flickering in this related thread started by Tony Jewell as well as the switch ghosting.

https://groups.google.com/d/msgid/pidp-1/a39e11b0-08c5-455d-8f8b-3d5833c73313n%40googlegroups.com?utm_medium=email&utm_source=footer\

Full disclosure:  my response doesn't provide a serious explanation but piggybacks on your Halloween haunted machine thought.

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/fd4aba4479a015f8071431d359ce2dec886899af.camel%40apathetic.org.uk.

[Malcolm Ray]

Ok, found the source of the flickering (at least in my case: I can't say this applies in all cases). It's not spooky.

I hadn't run install.sh after rebuilding panel_pidp1 (I thought it wasn't necessary, because pdp1control.sh runs it from the source directory). But the install script sets a capability on the binary, like so:

sudo setcap cap_sys_nice+ep /opt/pidp1/src/blincolnlights/panel_pidp1/panel_pidp1

Without this capability, you get the flickering.

Incidentally, install.sh also does this:

sudo chmod +s /opt/pidp1/src/blincolnlights/panel_pidp1

I suspect that's meant to be:

sudo chmod +s /opt/pidp1/src/blincolnlights/panel_pidp1/panel_pidp1

[Matthias Barthel]

sheeples - that works fine for me! Thanks.

[R Clark]

I tried to repeat the above and it worked every time I deposited the 2 into address 4. Did this repeatedly and same 2 was shown. Even with examine.   I am running a RPI-5 if that makes any difference.  Anyway, I think I am good.  Good to know though if I run into problem down the road.

[Bill E]

That's great to know, and explains some funnies I've been ignoring. I have several development branches, so I don't do a full install, I just run from the respective dirs. Not sure why the prog doesn't just do a setpriority() in the code with root perms.

Bill

[Angelo Papenhoff/aap]

That's a good observation. the LED multiplexing is probably the most complicated part of the whole project (and i'm still not quite happy with it) and we need very tight timing unfortunately. I pushed a change to increase the interval to 20μs now. so i hope with a fresh installation from the repo it will work nicely for everyone.

[Matthias Barthel]

Angelo, my first try with my pdp1 replica was also a led matrix, but now i drive all leds with gpios from expanders without any trouble.

The pidp1 matrix can also be controlled by max7219 ics, they manage the matrix and the pidp1 send only the number of the led how lights up - all problems are gone 🙃 but this needs a redesign of the pcb board. 

Matthias 

To view this discussion visit https://groups.google.com/d/msgid/pidp-1/6f6b8cee-5525-4486-9112-352ce258b96cn%40googlegroups.com.