Is there a way to check switch position from the command line?

[David Libby]

Hello,

I am trying to see of my SingleStep switch is working. Is there any way to check the position of a switch from the command line >? I was able check continuity to the Diode , but can I just check for continuity col7 - (Pin24) and row3( Pin7)?

Dave

[J. E. Myers]

Hi Dave,

Paul Bernard put together an LED test and Switch Scanning program that works really well.  Great way to test your kit after assembly.

wget http://downspout.ca/pidp-test.zip

Note - Make sure simh is not running when you run his GPIO program.

J. E. Myers

[David Libby]

Paul,

Thanks a bunch that utility really gave me piece of mind that everything is working fine.

Dave.

Heads up for anyone compiling this I had to make some changes to include the gpio header and object file...

you can manually compile with the command line or alter the Makefile to point at the files...

gcc -pthread main.c /opt/pidp8/src/gpio.o -o pidp-test

pi@raspberrypi ~/pitest $ gcc -pthread main.c /opt/pidp8/src/gpio.o -o pidp-test

pi@raspberrypi ~/pitest $ ls -lrt

total 24

-rw-r--r-- 1 pi pi  3367 Jul 30 09:18 main.c

-rw-r--r-- 1 pi pi   346 Aug 11 10:03 Makefile

-rwxr-xr-x 1 pi pi 14294 Aug 11 10:06 pidp-test

or change the make file to include the fully qualified path for the following..

vi Makefile

or 

nano Makefile

add the path in front of gpio.h and gpio.0

DEPS = /opt/pidp8/src/gpio.h

OBJ =  main.o /opt/pidp8/src/gpio.o 

Then just launch the build

pi@raspberrypi ~/pitest $ make

gcc -c -o main.o main.c -std=c99 -U__STRICT_ANSI__  -Wno-unused-result -D_GNU_SOURCE -DUSE_READER_THREAD -DHAVE_DLOPEN=so -I . -I PDP8

gcc -o pidp-test main.o /opt/pidp8/src/gpio.o -std=c99 -U__STRICT_ANSI__  -Wno-unused-result -D_GNU_SOURCE -DUSE_READER_THREAD - DHAVE_DLOPEN=so -I . -I PDP8 -lm -lrt -lpthread -ldl 

pi@raspberrypi ~/pitest $ ls -lrt

total 28

-rw-r--r-- 1 pi pi  3367 Jul 30 09:18 main.c

-rw-r--r-- 1 pi pi   346 Aug 11 10:03 Makefile

-rw-r--r-- 1 pi pi  3292 Aug 11 10:07 main.o

-rwxr-xr-x 1 pi pi 14322 Aug 11 10:07 pidp-test

You then need to shutdown simh and run pidp-test as admin

pi@raspberrypi ~/pitest $ sudo ./pidp-test 

RPi 2 detected

turning on LED row 0

turning on LED row 1

...

turning on LED row 7

turning on LED col 0

turning on LED col 1

turning on LED col 2

...

turning on LED col 11

Reading the switches.  Toggle any pattern desired.  CTRL-C to quit.

0400 0000 0000 

0600 0000 0000 

0700 0000 0000 

[Paul R. Bernard]

David Libby <jel...@gmail.com> writes:

> Paul,
>
> Thanks a bunch that utility really gave me piece of mind that everything is working fine.
>

You're welcome.

> Heads up for anyone compiling this I had to make some changes to include the gpio header and object
> file...

The original test program was crappy and highly rushed. I've just made
it slightly less crappy and also added two tests (All On and All Off)
that seemed rather conspicuous to me in their absence. And wonder of
wonders it's now documented as to how to get the darn thing to work in a
README. At some point there'll be a webpage providing a link to it so
you won't have to ask or stumble across in on this list.

If Oscar's code is in the recommended /opt/pidp8 dir then no manual
makefile fiddling or file copying is needed. Just run 'make'. You will
have to fiddle the first line of the makefile otherwise.

If you've already run the previous version on your PiDP then there's
ABSOLUTELY NO REASON to run this new version. As has been previously
said it's more about gaining confidence in your build rather then trying
to pass some grueling hardware test.

I myself have only just mustered the courage to solder the switchbar to
my PCB. I'm sure glad I wrote it. :-)

The newer version is in the same URL at:

wget http://downspout.ca/pidp-test.zip

- paul

[Jamie Cox]

Thank you very much, Paul, for this test code. I am having problems with the switches, and this is helping. For whatever reason, what I'm seeing is that if only 1 or a few switches are on, everything is fine, but if more than some number of switches are on, I start to see extra stray transitions in the first row (leftmost in the pidp-test printout).

[Rick Murphy]

Check the orientation of the diodes above the switch bank. I have a suspicion that there's one or more that are reversed.

    -Rick

On Thu, Aug 13, 2015 at 1:20 PM, Jamie Cox <jamie...@gmail.com> wrote:

Thank you very much, Paul, for this test code. I am having problems with the switches, and this is helping. For whatever reason, what I'm seeing is that if only 1 or a few switches are on, everything is fine, but if more than some number of switches are on, I start to see extra stray transitions in the first row (leftmost in the pidp-test printout).

--
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 post to this group, send email to pid...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/9359533a-ced0-419c-ba7c-ca3b616af823%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Rick Murphy, CISSP-ISSAP, K1MU/4, Annandale VA USA

[Paul R. Bernard]

I accidentally sent this only to Jamie (sorry) and not the list:

You've provided an argument as to why I should have not been so lazy and
just decoded the darn output to physical switches. :-)

I'll do it manually here (and perhaps add it to the test program later).

The switch output looks like this:

A B C
--------------
2000 0000 0000


The first twelve bits (labelled A) is the Switch Register. The bits
left to right correspond to the SR switches also left to right. So
above the SR2 switch is toggled down, ie 1. Every other SR switch is
up, ie 0.

The leftmost 6 bits (labelled B) is the DF switches followed by the IF
switches. The rest of the bits are unused in the B section.

The leftmost 8 bits (labelled C) are the remaining 8 switches starting
at "START" and ending at "SING INST". Again Left to right.

Rick thinks you may have one or more diodes reversed. I'll defer to
him, I always get confused in this switch matrix diode situation so
don't trust me, I might be wrong. However I *suspect* that you can
pinpoint the diodes that might be wrong by toggling a switch and finding
bits flipping but NOT the one bit that corresponds to the switch you
just flipped.

But then, just looking at the black bar on the body of the diode (always
to the right side when installed) will be easier than playing Steve
Gibson's "Lights Out". :-)

- paul

[Jamie Cox]

My diodes appear to be okay. Here is what I am seeing. The problem affects only the switch register, SR1 thru SR12. These are all in the "Row1" group. As long as one or more of the SR switches are off, everything is fine. However, as soon as all 12 of them are on, things get weird. Here is an example output from the new version of pidp-test:

0777 0000 0000
1777 0000 0000   <-- Here I am turning on switches one by one... okay so far.
3777 0000 0000
7777 0000 0000  <-- Here I turn on the 12th switch.
6137 0000 0000  <-- From here down, I didn't touch anything, and it kept producing similar noise
7777 0000 0000
7761 0000 0000
7777 0000 0000
7765 0000 0000
7777 0000 0000
6127 0000 0000
7777 0000 0000
7527 0000 0000
7777 0000 0000
1577 0000 0000
7503 0000 0000
...

I have tried a lot of other SR patterns and everything looks good except 7777.   Admittedly, I haven't tried all 4095 other combinations. :)

I'm suspecting a sort of accumulation-of-load-and-tolerances problem, where I have enough drive for 11 switches, but not 12. My three "1K Ohm" resistors range from 964 to 982 Ohms. The Row 1 resistor is 982 Ohms. Which is certainly within 5%.

Any ideas?

-Jamie

On Thursday, August 13, 2015 at 3:59:17 PM UTC-4, Paul R. Bernard wrote:

I accidentally sent this only to Jamie (sorry) and not the list:

[Paul R. Bernard]

Jamie Cox <jamie...@gmail.com> writes:

> My diodes appear to be okay. Here is what I am seeing. The problem affects only the switch register, SR1
> thru SR12. These are all in the "Row1" group. As long as one or more of the SR switches are off,
> everything is fine. However, as soon as all 12 of them are on, things get weird. Here is an example
> output from the new version of pidp-test:
>

Does it actually matter in which direction on the SR switches you
approach the 07777? ie. From your example it looks like you started
from the right most switch and moved to the left. Starting at the left
and moving right gives the same result? It already sounds like the
answer is yes, but I'm just confirming.

For a test (and because I don't think I actually tried it during my own
test) I turned all switches on one at a time from both the left and
right and from the middle working out. Mine worked as expected.

> I'm suspecting a sort of accumulation-of-load-and-tolerances problem, where I have enough drive for 11
> switches, but not 12. My three "1K Ohm" resistors range from 964 to 982 Ohms. The Row 1 resistor is 982
> Ohms. Which is certainly within 5%.

There's an enormous amount that I *don't* know about electronics. But
we're talking about a difference in current here of about 100 microamps
between the minimum and maximum values for your measured resistors. I
suppose that could be a possible trigger point (after all a fail has to be
triggered at some point) but I wouldn't leap to this conclusion first.
Maybe second... :-)

> Any ideas?

They're boring, and please don't ask me to explain how some of them
could cause the observed result (I don't know) but:

1) Solder bridge between the diodes. Along the chain of diodes the legs
are close, a bridge might connect two of them together. Bridges elsewhere.

2) Cold or missed solder connection on switch, diode, RPi connector, ...

3) Put the switches one toggle away from going nuts. Grab the body of
each switch while not touching the (flippy bit, paddle, toggle, GUI
whatever it's called). Wiggle firmly, but carefully. Try again after
putting it into "nuts" mode.

4) Repeat 3) above but instead try wiggling the paddle without flipping
it.

5) Power down and remove your RPi. With your Ohmmeter check for
conductivity (red on left, black on right) across each SR diode. Make
sure there is NO conductivity with red on right and black on left.

I'm out of ideas.

- paul

[Oscar Vermeulen]

Jamie,

It may be a false lead but I saw this behaviour when using 1.5k ohm resistors rather than 1.0k's. The pulldown that the resistor effectively is would be too weak for serving 12 'on' switches at the same time. 

That you have this symptomwith 1.0k resistors is a mystery though. 

So it happens if you toggle a 12th switch, and it does not matter which of the SR switches you toggle on last?

As a debugging idea: temporarily use a 800-or-so ohm resistor for row 1 (the resistor above the SR switches). 

If that solves the problem, I still don't know the cause (maybe an out-of-tolerance diode, never saw one but it's possible I guess). But using an 800k is still OK, it protects the Pi sufficiently. If it solves the symptoms you can leave it at that. 

Regards,

Oscar

--

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 post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/f7aaaf7a-fc33-4762-b8e3-cd4d87d6b9d1%40googlegroups.com.

[Jamie Cox]

Oscar,

Thanks for this.

Thanks also to Paul for some good ideas. I'm first to admit my soldering could cause problems, but I'm having trouble imagining how bad solder joints, especially on any particular switch or diode could cause this symptom. I had one LED that needed resoldering, and one switch. I'm going to try some of those things, as well as Oscar's resistor idea.

In case it matters, I am using a Raspberry Pi B+.

-Jamie





On Thursday, August 13, 2015 at 7:20:36 PM UTC-4, Obsolescence wrote:

Jamie,

It may be a false lead but I saw this behaviour when using 1.5k ohm resistors rather than 1.0k's. The pulldown that the resistor effectively is would be too weak for serving 12 'on' switches at the same time. 

That you have this symptomwith 1.0k resistors is a mystery though. 

So it happens if you toggle a 12th switch, and it does not matter which of the SR switches you toggle on last?

   That is correct, order does not seem to matter. 

To unsubscribe from this group and stop receiving emails from it, send an email to pidp-8+unsubscribe@googlegroups.com.

[Paul R. Bernard]

Oscar Vermeulen <vermeul...@gmail.com> writes:

Jamie,

Oscar has just given me one more idea to try. Power down and disconnect
your RPi from the pidp. Put all switches (SR, DF, IF, ...) into the
toggled down position (ie generating a 1 or a short between switch pins
1 and 2 (the two soldered connections)). Measure the resistance between
the cathode (black bar side) of each diode and the appropriate pin on the RPi
connector.

ie for SR switches it'll be "ROW1" which is pin 36.
for DF, IF switches it'll be "ROW2" which is pin 11.
for START, ... SING INST it'll be "ROW3" which is pin 12.

In all cases it should be around 1K ohms. If any path is different by
some unreasonable amount you'd be closer to the problem. The working
switches would give you a reasonable measure for contact resistance
expected from the switches. If they're all within spec then hmmm...

And for completeness I should point out that you shouldn't assume that
the test program is 100% trustworthy. It uses the pidp matrix scanning
code untouched, but it's not impossible that I missed something when I
set it up to run in the test code.

- paul

[Jamie Cox]

Original symptom was: Erratic switch readings when all 12 SR switches are "ON".

I tried buzzing things out as suggested by Paul, and I couldn't find any abnormal readings. So, I swapped the Row 1 resistor from 1K to 800 Ohms, as suggested by Oscar. Problem solved!

Actually I put 2 resistors in series to get the correct value. It's ugly, but it works. I'll have to find a prettier one.

Thank you all for your suggestions.

-Jamie

[Jason Balicki]

Paul,

I'd very much like to contribute to this code (specifically, I'd like to add some command line arguments to allow selecting which tests to run.

(For example: I had this same switch problem, so to test I'd have to wait through all the LED tests before I got to the switches.)

Is there any chance you can put it up on github?

Thanks!

--Jason

[Warren Young]

On Wednesday, November 30, 2016 at 10:58:10 AM UTC-7, Jason Balicki wrote:

I'd very much like to contribute to this code (specifically, I'd like to add some command line arguments to allow selecting which tests to run.

(For example: I had this same switch problem, so to test I'd have to wait through all the LED tests before I got to the switches.)

If the switch sometimes works and other times seems to do strange things, I think it's because the switches aren't debounced. Visit that link for my plan to fix this.

 

Is there any chance you can put it up on github?

I've merged it into my Fossil repository, building and installing it as pidp8i-test. It's installed in the PATH alongside all the other PiDP-8/I software with `make install`. See its new README.

GitHub is a bit easier when it comes to checking out a new project, but after setting up your initial clone, Fossil is generally as easy to use as Git and often easier. GitHub papers over a lot of missing functionality in Git, but Fossil has most of that, too. Complete instructions for checking the project out are on the front page of my repository site.

The main thing you'll be missing relative to GitHub is the ability to check your changes in on your personal fork, and have them be published publicly somewhere. Fossil will let you check your changes into your personal repository copy, but they'll just stay there on your machine since you don't have commit rights to my repository. (Yet!)

Instead, if your changes can be done in a single checkin, just post the output of `fossil diff` here when you're done working. I'll look it over, and if I like what you've done, I'll give you a login on my Fossil repo so you can check it in under your own name. Then, hopefully, you will help me on all the rest of what I've got planned. :)

If you want several checkins to accomplish your changes, it's best to check them in on a private branch, then send me the Fossil bundle file containing that branch instead. For example:

     ...hack hack hack...

    $ fossil checkin --branch my-test-changes

    ...now you're on the my-test-changes branch, so hack, hack, hack some more...

    $ fossil checkin

    ...repeat until done...

    $ fossil bundle export my-changes.bundle --branch my-test-changes

That packs all of the changes on my-test-changes branch up in a file that I can integrate into the main repository here, seeing all the individual checkins, the comments, etc. I think of it as an überpatch. :)

[Paul R. Bernard]

Jason Balicki <sak...@gmail.com> writes:

> I'd very much like to contribute to this code (specifically, I'd like to add some command line arguments
> to allow selecting which tests to run.

Cool, it has more life than I ever expected. However, do keep in mind
its "throw away" nature. IE. don't spend a lot of effort on a use-once
program. (Unless of course you have BIG plans for it. :-)

I did start to add arguments and then decided it was silly and just
#ifdef out the code as needed.

> (For example: I had this same switch problem, so to test I'd have to wait through all the LED tests
> before I got to the switches.)

I don't have a link handy but earlier in the mailing list someone
discovered a flakey problem with having too many switches on at once.
The problem affected my PiDP-8 as well and even with my silly test program
I didn't manage to find it until I specifically looked. Oscar posted a fix
which involves replacing some resistors if that is indeed the problem.

> Is there any chance you can put it up on github?

I'll put it on github if you need it there, but as Warren will say later
on in the thread, he's already put it into the official respository. It
seems a bit silly to maintain the code separately.

- paul

[Warren Young]

On Wednesday, November 30, 2016 at 3:37:36 PM UTC-7, Paul R. Bernard wrote:

as Warren will say later
on in the thread, he's already put it into the official respository.

I don't maintain the official repository, only my repository. :)

Only Oscar gets to say if it's official, and he hasn't, yet. 

I would be happier to proceed with that blessing than not, if only because then my repo will no longer be a fork. Until then, the only "official" place to get PiDP-8/I software is the 2015.12.15 zip file on the main project site.

[Paul R. Bernard]

Warren Young <tange...@gmail.com> writes:

> On Wednesday, November 30, 2016 at 3:37:36 PM UTC-7, Paul R. Bernard wrote:
>
> as Warren will say later
> on in the thread, he's already put it into the official respository.
>
> I don't maintain the official repository, only my repository. :)
>
> Only Oscar gets to say if it's official, and he hasn't, yet. 

Um... I kinda sorta already thought he did, here:

https://groups.google.com/d/msg/pidp-8/VXt914aAttg/E6ECG0KLCAAJ

I stand corrected if I've jumped the gun.

- paul

[Warren Young]

On Wednesday, November 30, 2016 at 4:17:46 PM UTC-7, Paul R. Bernard wrote:

> Only Oscar gets to say if it's official, and he hasn't, yet. 

Um... I kinda sorta already thought he did, here:

Wow, I completely missed that message.

Well yay. :)

[Oscar Vermeulen]

Warren, all,

On 30 November 2016 at 23:50, Warren Young <tange...@gmail.com> wrote:

On Wednesday, November 30, 2016 at 3:37:36 PM UTC-7, Paul R. Bernard wrote:

I don't maintain the official repository, only my repository. :)

Only Oscar gets to say if it's official, and he hasn't, yet. 

I'm pretty sure there are people way more competent than I am, actually - not false modesty.

There will always be the basic 'standard' release (at the top of the forum posts) for people who are either new or not too interested in messing about. As it works pretty well on any Pi, slow or fast.

My preference would be if there is no Blessed distribution - let it fork, but I would suggest we (you, me, anyone) now and then bring together the improvements on Warrens repository. The one thing I feel is important is that the baseline will always run smoothly on any Pi, slow or fast. Maybe with default compile options...

This may be messy and unorganised - but the code base is really small so it'll be fine. After all, what I inserted in simh fits on maybe 10 pages printed out? Probably less.

I would be happier to proceed with that blessing than not, if only because then my repo will no longer be a fork. Until then, the only "official" place to get PiDP-8/I software is the 2015.12.15 zip file on the main project site.

Due to family circumstances, I've been and will be very time-constrained for a while, mostly not even close to a PiDP. For example, the lamp glow emulation of Ian Schofield is a *major major* improvement - but I have not had the opportunity to set up my PiDP with a Pi 3 and run it! Which is intensely embarrassing, but my reality at the moment. Apologies to Ian for this, but he knows already :(

At any rate, please feel free to do whatever adds to the code. No officialdom :)

Now what would be intensely interesting is adding new features - like a network interface where the Pi-in-the-back takes various types of TCP/IP packets and offers them through new PDP-8 instructions in the emulator. Stuff like that probably flourishes best without officialdom where people perhaps feel reticent to publish such things.

Kind regards,

Oscar.

[Oscar Vermeulen]

Warren, Paul,

It's just great that others help update and improve the code! And with the energy Warren puts into this, his repository seems a great idea.

Improvements and critical review of the code are not hurting my feelings. The opposite. :)

Kind regards,

Oscar.

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to pid...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/7bb99fd2-1022-43ff-9c64-0fb9ff6a8c16%40googlegroups.com.

[Warren Young]

On Wednesday, November 30, 2016 at 5:19:37 PM UTC-7, Obsolescence wrote:

My preference would be if there is no Blessed distribution - let it fork, but I would suggest we (you, me, anyone) now and then bring together the improvements on Warrens repository.

Well, I'd like to see the 2015.12.15 release replaced at some point, once development on my repository settles down. There's still way too much churn for that, but eventually...

The one thing I feel is important is that the baseline will always run smoothly on any Pi, slow or fast. Maybe with default compile options...

Already in the plan are configuration options to turn the incandescent light simulator off, which would bring performance back in line with yours. Actually, mine should run a bit faster because I've added -O2 to the build options, whereas your build doesn't turn on any optimization option at all.

My tarballs are also under half the size of yours, despite having more features.

I inserted in simh fits on maybe 10 pages printed out? Probably less.

It would nevertheless be nice to get it all sequestered into a separate front panel app.

Now what would be intensely interesting is adding new features

Your login on the Fossil server gives you the ability to file tickets. Hint. :)

 

like a network interface where the Pi-in-the-back takes various types of TCP/IP packets and offers them through new PDP-8 instructions in the emulator.

I've filed my take on that. Take a look, and let me know if you had a different idea, either here or in a comment on the ticket. 

[Oscar Vermeulen]

Warren,

On 1 December 2016 at 07:57, Warren Young <tange...@gmail.com> wrote:

On Wednesday, November 30, 2016 at 5:19:37 PM UTC-7, Obsolescence wrote:

Well, I'd like to see the 2015.12.15 release replaced at some point, once development on my repository settles down. There's still way too much churn for that, but eventually...

Yes, that makes sense.

 

Already in the plan are configuration options to turn the incandescent light simulator off, which would bring performance back in line with yours.

That would be important to keep it running comfortably on a Pi Zero, keeping enough CPU cycles free for background duty as file server etc.

It would nevertheless be nice to get it all sequestered into a separate front panel app.

It's a matter of personal preference, but I prefer the current setup. It's mean and lean, avoiding communications overhead - and keeps all the logic in one file. But, personal preference... 

Keep in mind, there is already the option to run the PiDP-8 as a BlinkenBone server, which is an implementation of the other approach.

See here: http://retrocmp.com/projects/blinkenbone/blinkenbone-physical-panels/249-pidp8-as-blinkenbone-panel

Kind regards,

Oscar.

 

[Warren Young]

On Thursday, December 1, 2016 at 1:06:23 AM UTC-7, Obsolescence wrote:

It would nevertheless be nice to get it all sequestered into a separate front panel app.

It's a matter of personal preference,

Not entirely. The current design makes upgrading SimH very difficult.

Also, I'm now certain that the switches on the PiDP-8/I aren't debounced, which often causes multiple phantom presses, particularly with the momentary switches like Sing Step. This makes debugging assembly code even more difficult than it inherently is.

It is possible to debounce switches in software. The naive fix is to add some delay after the first edge is sensed, then sample the same signal again to see if it's still in the new state, taking action only if so. A traditional value for this is 50ms. Now think what happens to even the lowly 1.5µs PDP-8/I cycle time when you go inserting 50ms delays into the middle of pdp8_cpu.c.

So, now we're faced with two bad choices if we wish to keep it all in a single process:

1. Add a state machine within the existing pdp8_cpu.c state machine for use by the PiDP-8/I, so it can return to the main instruction dispatch loop while it waits out the contact bounces. Since 50ms is enough time to flip several switches (i.e. "mash the front panel") you have to maintain separate timers for each switch.

2. Spin switch reading off into a separate thread, so that the debounced contact closures can be injected into the current switch handler within pdp8_cpu.c. Then delays and/or state machines within the separate thread don't cause mental competition with figuring out what's going on in the instruction dispatch code. But having done so, you've bought yourself all the problems with multithreaded programming.

Are you sure those two options are better than spinning the switch reader/LED writer off into an entirely separate process, where its delays don't affect the simulator?

It's mean and lean, avoiding communications overhead

How much overhead do you believe there will be? You say "overhead" like any nonzero value is a showstopper.

I just ran an iperf3 test on my Pi3 here while pidp8i-sim was in the background running Hunt the Wumpus under OS/8. I achieved a 3 Gbit/sec data rate during this!

So, what do you suppose the bandwidth to the front panel app will be? :)

Furthermore, keep in mind that the current design puts all CPU delays for the switch and LED I/O right in the middle of SimH's main instruction dispatch loop, whereas this new design will put it in a different process, and therefore likely on a different CPU core while the simulator is busy. The I/O to the front panel app will only happen while the simulator is otherwise idle.

 

That is, the simulator may well run faster in this configuration than it does now, at least on multicore Pis.

and keeps all the logic in one file

Yes, along with a whole bunch of other logic that has nothing to do with reading switch states and twiddling the LED driver's GPIO pins.

there is already the option to run the PiDP-8 as a BlinkenBone server, which is an implementation of the other approach.

So you're telling me that my solution will have too much overhead, but as an alternative, you point me at a solution written in Java, which apparently runs on a separate computer from the PiDP-8/I, and it works just fine?

That settles it, then. My idea will work just fine, too. QED, by existence proof.

[Ed Spittles]

While you're forging ahead, Warren, please can you confirm that you'll continue to support the Pi Zero as a first class platform for the PiDP-8? It's good to know that the Pi 3 will work well, but the Zero should be supported too.
​

I'm hopeful that you are right: a second thread or a second process, so long as it isn't busy-waiting, should be able to handle the I/O without overloading the Pi.

Ed

[Warren Young]

On Thursday, December 1, 2016 at 4:15:07 AM UTC-7, Ed S wrote:

While you're forging ahead, Warren, please can you confirm that you'll continue to support the Pi Zero as a first class platform for the PiDP-8?

Since I don't have one, I couldn't make any such claim.

That said, I have just checked in a new branch that backs this patch out. You will need to follow the Fossil checkout instructions on the front page of the repository, except that you substitute the "fossil open" command for this one:

    $ fossil open ~/museum/pidp8i.fossil no-lamp-simulator

From that point on, simply saying "fossil update" in that directory will get you the latest changes on that branch, so you don't need to keep cloning and checking it out like this.

I will occasionally refresh that branch from the trunk, but don't expect it to contain the latest-and-greatest all the time. Also don't expect it to be as well tested as the trunk.

Eventually, this will be an option under control of the configure script, defaulting to "off." But, that will have to wait until I extract the front panel code into a separate process, or someone beats me to it. Until then, it would amount to doing a whole lot of work twice.

Incidentally, I've just tested the difference between these two on my Pi 3, and I'm only seeing about a 10% absolute difference between the two, and without the patch, it still takes about 75% of this 4-core CPU. That suggests it's going to be completely maxing out a Pi Zero. But again, I don't have one, so that's just a guess.

[Ed Spittles]

Just a couple of thoughts - see inline

On 1 December 2016 at 12:51, Warren Young <tange...@gmail.com> wrote:

On Thursday, December 1, 2016 at 4:15:07 AM UTC-7, Ed S wrote:

While you're forging ahead, Warren, please can you confirm that you'll continue to support the Pi Zero as a first class platform for the PiDP-8?

Since I don't have one, I couldn't make any such claim.

...

 

Incidentally, I've just tested the difference between these two on my Pi 3, and I'm only seeing about a 10% absolute difference between the two, and without the patch, it still takes about 75% of this 4-core CPU. That suggests it's going to be completely maxing out a Pi Zero. But again, I don't have one, so that's just a guess.

If you start the emulator and the I/O process - or the parent script of both, if there is one - with a prefix

taskset 1 ...

then that process and all children will be locked to CPU #0. That will give some idea of performance on a single-core machine - although of course the Pi 3 cores are a little faster than the Pi Zero core. See https://linux.die.net/man/1/taskset

Second thought, the I/O thread should be able to do its work even if it's usually sleeping - if for example it sleeps for 10 milliseconds between each action, that gives it 5 samples in a 50mS debouncing period. If it can be usually sleeping, then it shouldn't present much CPU load. I think such a sleep should be possible in C, python, perl or shell.

Cheers

Ed

 

[Warren Young]

On Thursday, December 1, 2016 at 9:39:18 AM UTC-7, Ed S wrote:

> On 1 December 2016 at 12:51, Warren Young wrote:
>
> without the patch, it still takes about 75% of this 4-core CPU

Sorry, that's a think-o. I meant that it was 75% idle, meaning that if you squint, it is taking up 100% of a single core.

With the lamp patch applied, that drops to 65% idle, which is what I meant by "10% absolute."

> then that process and all children will be locked to CPU #0. That will give some idea of performance on a single-core machine

That doesn't matter. Linux's top(1) reports all the cores together as 100%, so if you've got a 4-core processor and it reports 75% idle, it's using 1 core's worth of resources, whether you bind it to a single core or it round-robins madly among the cores.

Binding the process to a single core may avoid some inefficiency from core-hopping, but all that would do is raise my idle numbers a bit. It won't change the fact that even without the lamp patch, the simulator is likely to nearly peg a Pi Zero's CPU.

Small optimizations like core-binding aren't the way to fix this.

> Second thought, the I/O thread should be able to do its work even if it's usually sleeping

I don't know how the threading works inside the simulator. That's one of the many problems with multi threading: working out exactly which bit of code executes on which thread at any given point in time.

A message-passing architecture with cooperating single-threaded programs is not only easier to understand, it's less likely to run into any of the many problems with multithreading, yet it can also get you many of the benefits of multithreading.

> if for example it sleeps for 10 milliseconds between each action, that gives it 5 samples in a 50mS debouncing period

Denouncing isn't about oversampling. You just capture the first edge transition, then at the end of the debouncing period, you ask "is the signal still in this state"? If not, you saw a blip, not a true switch throw. (Contacts might be dodgy, RFI might be getting in, etc.)

> I think such a sleep should be possible in C, python, perl or shell.

See all the sleep_ns() calls in src/gpio.c.

You must be right that this runs on a separate thread from the one that decodes CPU instructions, since even the lowly PDP-8 has a cycle time of 1.5 µs, whereas most of the delays in gpio.c are a brief eternity by comparison.

[Ed Spittles]

>Small optimizations like core-binding aren't the way to fix this.

Sorry, I must have been unclear. I didn't mean to suggest a fix for anything. By binding all relevant processes to one core, you can readily simulate a situation somewhat like a Pi Zero. This was in the context of you saying that you don't have a Zero with which to test your developments.

​