Display update for the PiDP8

[Ian Schofield]

Dear All,

 Please find attached an update of the PiDP8 software and a new makefile. This update is to improve the front panel display so that it appears (slightly) more like the real thing. To begin, I would note that running the emulator is one thing but to create a dynamic display on all of the leds is quite a challenge and Oscar has done a great job given the limitations of the Pi parallel port. As a result, running the display requires quite a bit of processor resource and some hand tuned loops so that the logic stays within timing limits. To make this work does require a multi-core Pi ... in my case a Pi 3. There are some advantages to using a Pi 3 in that, if configured correctly to use wifi, you don't need to plug anything into the USB ports and only a hole for a power cable is needed in the case. So, to start:

1. A Pi 3 is required by a Pi 2B might be OK.

2. The OS should be Raspbian Jessie.

3. To connect remotely via the Wifi, install tightvnc and optionally Xrdp. (I use Xrdp to connect from my Windows box).

4. Check using lsmod that the BCM2835_gpiomem module is loaded. This usually installed by default. If not, get the latest update for your Pi.

5. Install setcap using sudo apt-get install libcap2-bin from a console. This utility allows the thread priorities to be changed as a user rather than as root. This is crucial to allow the display thread to run at full speed.

6. Update the files in the PiDP8 app with the files in the attached archive.

7. Rebuild the app and now you can run the binary without using sudo as gpio.c now uses the /dev/gpiomem interface to the parallel port.

8. Run the pipdp8 binary, select OS option 6 with the front panel switches and toggle single step. This will boot an OS/8 system containing ETOS. Then, R ETOS at the console, press return in response to OPTION? and watch the lights!!!!

I hope you can get this to work.

 A few words about the update. Gpio.c has been re-written to simulate a filament bulb with a led. This is achieved using a 32 step PWM system where the brightness of each individual led is estimated based upon the ratio of the number of processor cycles when it would be on versus off. This is quantised to 32 levels in the setleds routine in pdp8_cpu.c file using

floating point arithmetic (!!!!). The brightness of every one of the 96 possible leds is estimated by averaging the state of every register every 1049 processor cycles (about once every 500 uS) using a low pass filter. This table of average brightness levels is then displayed via an asynchronous thread in gpio.c where the whole display is refreshed at about 10kHz and the leds switched on for 0 to 31 cycles. This gives an overall cycle time of about 3 mS or 300 Hz. This should be well above the flicker fusion frequency but, there are a number of OS related delays such that the actual refresh rate is probably closer to 100 Hz ... I don't have an oscilloscope to hand to check this. Overall this gives the illusion of an incandescent bulb and this can be seen by watching the leds go on and off as the processor executes instructions. The 1049 above is a prime number such that if the processor is executing a loop, all states in the loop will be sampled eventually.

Hope this works for you.

Regards, Ian Schofield.

[Marty Swartz]

Wow, Ian, that sounds like a pretty intense piece of work!  Is there any chance you can post a video showing this in action?

[Neil Higgins]

Exactly what multicore processors were invented for - simulating lightbulbs. Well done!

[Ian Schofield]

Dear Neil,

  Absolutely. The app now maxes out 2 cores and leaves 2 for other stuff. The window manager (in my case Xfce)  is still very responsive.Maybe you could run another processor instance with a D8/e inteprocessor buffer and simulate a multicore PDP8!

Regards, Ian.

[Neil Higgins]

That would stay within the spirit of things :-). I didn't know whether to gag or laugh when I saw the article about the HP35 emulator running on a PDP-8 - crazy, stupid and fantastic all in one. Actually I am running Einstein@Home on my PiDP-8 hardware. It's very processor intensive, but the PDP lights still blink perfectly. However I expect that with your software, my E@H brownie points will rack up at a significantly lower rate. I also have a theory that the Pi3's performance is thermally limited. Running E@H with all processors flat out, my Pi3 is no faster than my Pi2.

[sunnyboy010101]

Ian,

A lovely bit of work. I'm running Multos at the moment instead of ETOS. It too has a rather 'amusing' display wait state.

[Obsolescence]

Ian,

Thank you for this brilliant upgrade!

As we discussed by email, apologies for me being tied down with other duties for the moment... but I really can't wait to try it out myself. Having the leds show the 'glow' effect of light bulbs was something I wanted to have for a long time - now it is there! I'll report back as soon as I can free up time to try :)

Kind regards,

Oscar.

[Douglas Crawford]

Sounds interesting!
Why step 8?  Won't the bootup work as with the stock installation?
I kind of expected an update to just be... copy over the files, rebuild, reboot.

[sunnyboy010101]

I didn't even reboot. Just  'sudo /etc/init.d/pidp restart'. Change the switches first if you want it to boot to ETOS.

[Douglas Crawford]

Oh very good! 
Boy that sounds REALLY interesting and something very educational
to study.

--
You received this message because you are subscribed to a topic in the Google Groups "PiDP-8" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pidp-8/fmjt7AD1gIA/unsubscribe.
To unsubscribe from this group and all its topics, 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/4474f66f-5ee8-48a1-bc18-ebbf3d88ea6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[bo...@mktx.com]

Thanks for the great work, Ian!  I, too, have wished to relive the warm pulsating glow of the panel lights that I viewed in my high school computer club way back in 1970.  But (please don't hate me) I'm a DOS/Windows user and pretty much totally lost when it comes to operating in a linux environment.  Can someone please package the new light control software along with the appropriate OS/SimH into a flash image that I can just load via Windows and plug into my Pi 2B?

Thanks again,

Bob

On Saturday, September 24, 2016 at 1:37:30 PM UTC-7, Ian Schofield wrote:

[AB]

For the linux ignorant such as myself I would second that request ... if you have time :-)
thank you in advance!!

Andy

[Warren Young]

On Tuesday, November 15, 2016 at 11:01:00 AM UTC-7, bobp wrote:

Can someone please package the new light control software

I've got a version of it hosted here: https://tangentsoft.com/pidp8i/

You probably want the "Zip archive" link off the page that link takes you to.

 

along with the appropriate OS/SimH into a flash image that I can just load via Windows and plug into my Pi 2B?

You don't need that. The software unpacks over the top of the stock flash image just fine. From the RPi's shell prompt:

     $ wget https://tangentsoft.com/pidp8i/zip/pidp8.zip

     $ cd /opt

     $ sudo unzip ~/pidp8.zip

That will unpack the new source code and other associated files on top of your existing installation. Then:

    $ cd pidp8

    $ make

    $ sudo systemctl restart pidp8

That will build the new code, install it in its proper place, stop the old one, and start the new one.

Note that this version of the code has a top-level Makefile and also builds the scanswitch utility for you, so don't think you need the more complex build instructions you find on the official project pages.

The above steps may also work on a fresh Raspbian Jessie image, if you've got all the necessary the software development tools installed. (Sorry, I don't remember at this point what I had to install, and what was already present.)

[Warren Young]

On Monday, November 21, 2016 at 6:58:52 AM UTC-7, Warren Young wrote:

     $ sudo unzip ~/pidp8.zip

I forgot to mention that if you do the above step on an existing PiDP-8/I installation, it will overwrite all of your disk images, so if you've saved anything important to the RK05 disk pack, or similar, it will be reverted to the stock disk image. 

[Remy van Elst]

Hi Warren,

Do you maybe have a small summary of the changes in your software package? I did check the wiki but it talks about the hardware, not the software.

Op maandag 21 november 2016 15:05:26 UTC+1 schreef Warren Young:

[Warren Young]

On Tuesday, November 22, 2016 at 2:18:19 AM UTC-7, Remy van Elst wrote:

Do you maybe have a small summary of the changes in your software package?

That's shown on the Timeline page:

    https://tangentsoft.com/pidp8i/timeline

You can filter it to show only checkins:

   https://tangentsoft.com/pidp8i/timeline?n=50&y=ci&v=0

And because Fossil is a complete DVCS, you can use that list to modify your copy to suit.

For example, let's say you didn't want Ian Schofield's display improvements, perhaps because you needed the CPU time it takes for other things. From within your new repo checkout, you can back just that one change out:

    $ fossil merge --backout 3a85f08639

Then, because it's a distributed version control system, you could proceed from that point on a local branch:

    $ ...hack hack hack...

    $ fossil set autosync 0          # prevent Fossil from trying to send your changes back to me; needed first time only

    $ fossil checkin --branch remys-cool-hack

From that point, you're working on the remys-cool-hack branch, which is the same as the tip-of-trunk on my repo minus Ian's features, plus yours.

If you did want to send your changes back to me, that above working pattern also works. Just get a login to the repository from me, then make your changes on a branch so your work doesn't interfere with the main line of development. (And then later, we can easily merge your branch in if you've done work valuable to the core effort.)

I encourage you to look deeper into Fossil. It's very nearly as powerful as Git + GitHub, yet much simpler than stock Git without the third-party dependency of GitHub. Also, being a small (by 2016 standards, anyway) single-binary program, Fossil has the PDP nature, whereas Git most certainly does not. :) 

[bo...@mktx.com]

Warren,

I'm running Raspbian jessie lite and I followed your instructions below through the make command (actually, I needed to say "sudo make"), but the make operation failed part-way through with the following error messages:

gpio.c:15:20: fatal error: config.h: No such file or directory

 #include “config.h”

                    ^

compilation terminated.

Makefile:15: recipe for target ‘gpio.o’ failed

make[1]: *** [gpio.o] Error 1

make[1]: Leaving directory ‘/opt/pidp8/src’

Makefile:2: recipe for target ‘all’ failed

make: *** [all] Error 2

Any idea what's wrong?

Thanks,

Bob

[Warren Young]

On Sat, Nov 26, 2016 at 4:24 PM, <bo...@mktx.com> wrote:

I'm running Raspbian jessie lite and I followed your instructions below through the make command (actually, I needed to say "sudo make"), but the make operation failed part-way through with the following error messages:

I redid the build system since I wrote those instructions on Monday. I don't have time to write a new build doc at the moment, but briefly, it now works like most other Linux software:

1. Download the package. (Yes, download it again. There have been recent changes, including one I just made a few minutes ago which is relevant to your situation.)

2. Unpack it anywhere convenient to you, rather than the way the upstream package works, where you unpack it into the installation tree. I suggest ~/src, but it could be the Downloads directory, or anything else you find convenient. The only place I'd suggest that you *don't* unpack it is /opt/pidp8!

3. Build it:

   $ ./configure

   $ make

   $ sudo make install

That last step (sudo make install) places all the built software and associated stuff in /opt/pidp8i by default, so it won't interfere with an upstream build. So, you could have both versions installed side-by-side.

My version also calls its init script "pidp8i" now, so commands like "sudo systemctl restart pidp8i" must include the 'i'. Partly this is to avoid conflicts with the upstream version, but also because I doubt this software will ever be repurposed for a Straight 8 or 8/e kit. :)

By unpacking the software into a directory your user controls, you don't need "sudo make" now. The only reason you need "sudo make install" is that the default installation location is outside your home directory. The new configure script's --prefix option would let you change that, though, if you want everything in your home directory:

    ./configure --prefix=$HOME/pidp8i && make install

There are further changes planned for the build system. For instance, I want it to overwrite binary media (e.g. the virtual RK05 cartridge holding OS/8) only when forced, so you don't lose local changes on every upgrade.

Realize that the current zip file link is just packing up the tip of the development tree, so you're working with whatever I checked in most recently. Eventually I will tag a release version. Perhaps Sunday night, since that will be the end of this long weekend of code hacking.

[Warren Young]

On Saturday, November 26, 2016 at 7:56:07 PM UTC-7, Warren Young wrote:

I don't have time to write a new build doc at the moment

I've just written the first version of the new README.md file. It is considerably more detailed than my prior post above, and contains at least one fix to the given advice. 

Because that link always points to the trunk version of that file, it will remain up-to-date, whereas the advice in my previous post is already stale in one detail. ("make install" no longer overwrites the OS/program media with fresh copies unless you manually force it.)

[bo...@mktx.com]

So I'm working my way through the new readme file referred to below.  I loaded a fresh copy of Raspbian Lite onto an erased SD card.  I started Raspbian on the PiDP and loaded pidp8i.zip into /usr/src and unpacked it, which created a pidp8 directory at the root level.  I went to that directory and typed "./configure && make && sudo make install", and then the machine responded with the following:

No installed jimsh or tclsh, building local bootstrap jimsh0

No working C compiler found. Tried cc and gcc.

And the build operation stopped.  Am I trying to run the ./configure command from the wrong directory folder?

Thanks for your help.

Bob

[Warren Young]

On Sunday, November 27, 2016 at 9:02:59 PM UTC-7, bobp wrote:

No working C compiler found. Tried cc and gcc.

It means just what it says: you haven't got a C compiler installed.

I guess that means it's only included with the "full" Jessie, not Lite. To fix it:

    $ sudo apt install build-essential

[bo...@mktx.com]

I did the "sudo apt install build-essential" command and the computer responded with "build-essential is already the newest version."  You want me to be in the same directory that holds the configure file before I issue the .configure command, right?

[Warren Young]

On Monday, November 28, 2016 at 7:15:18 PM UTC-7, bobp wrote:

I did the "sudo apt install build-essential" command and the computer responded with "build-essential is already the newest version."

Then I'm stumped. Let's gather more data: try "./configure --debug", and also send a copy of the resulting config.log file, if you can.

 

Also try this with the latest zip file. Changes were made to it as late as Monday morning, here in the US. I don't have any reason to believe any of them were responsible for the problem you're having, but we might as well be on the same page.

You want me to be in the same directory that holds the configure file before I issue the .configure command, right?

Yes, though one of the features you get from the new build system is that you can build outside the source tree if you want. (There are good reasons to do so, but it's not important to go into here.)

[bo...@mktx.com]

OK.  I erased my flash again and re-loaded Raspbian Lite, and re-downloaded and unzipped PiDP8i.zip, this time into the usr/src directory.  I then went to the pidp8i directory under usr/src and issued the ./configure command.  I got exactly the same error as before:

No installed jimsh or tclsh, building local bootstrap jimsh0

No working C compiler found. Tried cc and gcc.

Then I executed the "sudo apt install build-essential" command and the computer responded with "build-essential is already the newest version."

Then, following your suggestion in your message below, I issued the "./configure - debug" command, but I don't see a config.log file.  Would the log file have been dropped in a different directory?

Thanks,

Bob

[Warren Young]

I want the text output of the debug command. Paste it here.

--
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/4c85dfd2-4131-4fcc-b7f0-6bd6abc87219%40googlegroups.com.

[bo...@mktx.com]

Hi Warren,

Per your request, below is the screen output when I issued the ./configure -debug command:

$ ./configure -debug

No installed jimsh or tclsh, building local bootstrap jimsh0

No working c compiler found. Tried cc and gcc.

$ sudo apt install build-essential

Reading package lists... Done

build-essential is already the newest version.

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

$ ls

AUTHORS.md auto.def autosetup bin boot ChangeLog.md configure etc examples labels Makefile.in media pics README.md schematics src

Bob

On Wednesday, November 30, 2016 at 2:31:21 AM UTC-8, Warren Young wrote:

I want the text output of the debug command. Paste it here.

On Nov 30, 2016, at 01:27, bo...@mktx.com wrote:

OK.  I erased my flash again and re-loaded Raspbian Lite, and re-downloaded and unzipped PiDP8i.zip, this time into the usr/src directory.  I then went to the pidp8i directory under usr/src and issued the ./configure command.  I got exactly the same error as before:

No installed jimsh or tclsh, building local bootstrap jimsh0

No working C compiler found. Tried cc and gcc.

Then I executed the "sudo apt install build-essential" command and the computer responded with "build-essential is already the newest version."

Then, following your suggestion in your message below, I issued the "./configure - debug" command, but I don't see a config.log file.  Would the log file have been dropped in a different directory?

Thanks,

Bob

On Tuesday, November 29, 2016 at 2:39:41 AM UTC-8, Warren Young wrote:

On Monday, November 28, 2016 at 7:15:18 PM UTC-7, bobp wrote:

I did the "sudo apt install build-essential" command and the computer responded with "build-essential is already the newest version."

Then I'm stumped. Let's gather more data: try "./configure --debug", and also send a copy of the resulting config.log file, if you can.

 

Also try this with the latest zip file. Changes were made to it as late as Monday morning, here in the US. I don't have any reason to believe any of them were responsible for the problem you're having, but we might as well be on the same page.

You want me to be in the same directory that holds the configure file before I issue the .configure command, right?

Yes, though one of the features you get from the new build system is that you can build outside the source tree if you want. (There are good reasons to do so, but it's not important to go into here.)

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

[Warren Young]

On Wednesday, November 30, 2016 at 7:47:06 PM UTC-7, bobp wrote:

Per your request, below is the screen output when I issued the ./configure -debug command:

There are two dashes before "debug," not one. It matters. Please try again.

[bo...@mktx.com]

Hi Warren,

I issued the command "./configure --debug" and the response was identical to what I received previously (i.e., to the command "./configure -debug").

I see no config.log file.

Bob

[Ed Thierbach]

Pardon me for jumping in ...

Bob - try entering this command:

gcc

just to see what you get.  If you get an unknown command error, try installing the gcc package and see if it helps.  If you get an error from the gcc compiler itself, then it looks like the configure script just doesn't know where it is.  You can use the 'which gcc' command to see where it might be, then look at the configure script and see why it can't find it there.

-Ed-

--

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/6734e2d8-b4e4-4a25-8e2d-01b330c34494%40googlegroups.com.

[Bob Patterson]

Thanks, Ed.  I’ll try it tonight.

 

Bob

Virus-free. www.avast.com

[Bob Patterson]

Ed (and/or Warren),

 

When I issued the “gcc” command as you suggested, the system responded with:

 

gcc: fatal error: no input files

 

When I then issue the “which gcc” command, the system responds with:

 

/usr/bin/gcc

 

All of the PiDP8i files including configure are currently unzipped on my machine in /usr/src/pidp8i.

 

The configure script in that directory says:

 

#!/bin/sh

dir=”’dirname “$0”’/autosetup”

WRAPPER=”$0”; export WRAPPER; exec “’$dir/find-tclsh’” “$dir/autosetup” “$@”

 

‘sorry, as a linux newbie those instructions don’t yet mean anything to me.  Would I need to make any changes to the Configure script to get it to run correctly?

 

Thanks again for all your help,

Bob

 

From: Ed Thierbach

Sent: Thursday, December 01, 2016 6:04 AM

To: bo...@mktx.com

Cc: PiDP-8

Subject: Re: [pidp8] Re: Display update for the PiDP8

 

Virus-free. www.avast.com

[Warren Young]

I think I've just figured out what's going wrong.

In order to unzip the software into /usr/src, you had to do it via sudo, which means root owns the resulting folder, not your normal user. Then when you try to run the configure script as your normal user, it tries a trial-run on gcc, which can't write to the folder, so it assumes gcc can't create executables and quits.

You therefore have at least three ways to fix it:

1. Run all the other steps via sudo, too:

    $ sudo ./configure

    $ sudo make

    etc.

2. Give your user ownership of that one folder under /usr/src:

    $ sudo chown -R $USER /usr/src/pidp*

3. Unpack it in your home directory or somewhere else you do have write access.

I vote for #3, if you have no preference. I never quite understood why you'd want it in /usr/src, as that is normally for source code for software that comes with the OS, such as the Linux kernel.

Personally, I use /usr/local/src, but one of the very first steps I do on a new system is "sudo chown $USER /usr/local/src" so that the directory belongs to my normal user. I prefer that since most things I install from /usr/local/src end up elsewhere in /usr/local, so it seems logical.

[bo...@mktx.com]

Many thanks to Warren and Ed for their help.  The new software is working fine on my PiDP.  I LOVE the subtle glow to the LEDs now!  Just like I remember from 1970.

Bob