New IO devices

[Angelo Papenhoff/aap]

Hi,

the PDP-1 is of course well known as a playground to experiment with hardware. And we would like to replicate the fun of this with the PiDP-1 as much as possible of course.

Just like plugging in new cables into a real PDP-1 there is mild source code surgery necessary. the iot_pulse function in pdp1.c is called twice with pulse=0 and pulse=1. It then decodes the device code and does the appropriate thing. And this is where you come in: please experiment with adding new devices to this function to teach the PiDP-1 new tricks. Maybe hook up some fun device via the spare i2c pins and implement some commands to talk to it. I'm thinking about controlling an LED matrix myself.

Please tell us what you did so others can try the same or get new ideas.

Good ideas can be upstreamed to become standard pidp-1 features.

Cheers,

aap

[Matthias Barthel]

how decodes the iot_pulse the i2c-addresses ? 

standard process is , write some data in the io-register an "send it" with instruction code 72 or 73 (when indirect Bit is set) to the iot device.

so now i have a pcf8574 port expander on the i2c-bus with address 0x20, what is the address in the instruction ? 

some Devicenumbers are reserved :

eg.

how can i associate i2c-address 0x20 to device 8 ?

Matthias

[Matthias Barthel]

i have added 2 i2c port expander via the i2c connector on the back and installed the i2c dev libs with "sudo apt-get install libi2c-dev"
and now i can see my devices with the command "i2cdetect -y 1"

in the pdp1.c file i must now add a new case in the iot_pulse function
like

case 010:
   //some code like
   //write io-register 0-7 to device on i2c address 0x20 pin 0-7
break;

and instruction code for this case is then 72 0012 because the case number is decimal, and

decimal 10 = binary 001 010 = octal 12 - right ?

are there i2c functions in the simulator included, or is this my part ? :)

Matthias

[Angelo Papenhoff/aap]

The emulator itself does nothing at all with i2c, actually implementing cool IOT instructions that talk to real hardware is something that you'll have to figure out yourself. Just pick an unused device code (everything is in octal) and implement the logic. I did forget to mention that you will most likely do the physical IO in handleio(), iot_pulse() is just to start these operations.

[Matthias Barthel]

Angelo, i need a little help from you :)

i have added some code in the pdp1.c file.

how can i compile only the pdp1c file, or must i compile the complete package ? ca i do this with the install script ?

matthias

[Oscar Vermeulen]

Waiting for the more competent advice of Angelo (who's away today I think):

Just do 

make -C /opt/pidp1/src/blincolnlights/pdp1

The pdp executable in /opt/pidp/bin is just a symlink to the pdp1 executable in the source directory, so the new version is live straight away.

Kind regards,

Oscar.

[Matthias Barthel]

yes, it works :)

i add some lines of code in the pdp1.h and recompile the file with "make -C /opt/pidp1/src/blincolnlights/pdp1" 

the pdp1.c sends now the data of the io-register to a small bash-script, and the bash-script splits the data to 3 pcf8574 ic's to drive some LED's.

the code i have added to pdp1.h in the iot_pulse-function:

case 010:
if(pulse) {
char command[80];
sprintf(command, "/opt/pidp1/bin/iot_device.sh 1 %d", IO);
system(command);
}
break;

the pins of the pcf's are all High when power on, so i added a init-script to the pdp1control.sh to switch off all leds at the start.

but first you must enable the i2c bus in the raspi-config, and install the i2c-dev-tools.

then you can test the pcf's with i2cdetect and i2cset (i2cset is used from the bash-script)

both scripts are placed in the /opt/pidp1/bin directory.

now you cann write some code to bring the lights up.

0010 000001 /value for the iot device

0011 220010 /lio (0010)

0012 720010 /iot 10

0013 760400 /hlt

for short playing around, this ist enough code, play around with the value in 0010 and let it run, start is at 0011.

in the picture you can see that the io is the same linke the leds, also you see the instruction in the memory buffer 720010

later i make a short video.

i have added a zipfile with the 2 files for testing whose interested.

the pcf8574's had the addresses 0x20,0x21,0x22 for bits 0-7,8-15,16-17

the files are work in process and not cleaned up, i think new version are following in the next days.

the leds are driven bei a uln2803 ic, because the current of the led's is to high for the port expander.

if anyone is able to include the i2c functions in c , you are welcome :) 

the iot interface on the real machine had also to the 18 bits of the io-register, some bits of the accu to address something, and can manipulate the program flags from outside. see : https://bitsavers.org/pdf/dec/pdp1/F25_PDP1_IO.pdf

matthias

[Matthias Barthel]

if the link works, here is a short video 

i deposit something at 0010 and write it to the leds

video

[Oscar Vermeulen]

Video links works. Angelo and I spent a few evenings discussing 'creative peripherals' to add to the Type 30. Er, Personal Democoding Peripherals. #1 would be a 8*8 LED cube, #2 indeed a galvo, etc. Just fun little things the PDP-1 could drive sitting on its bookshelf. The point being, I think the electricity cost of running a Pi 24/7 is $10-$20 a year or so, so why not leave it on and brighten up the living room...

[Bill E]

I was hoping there were enough GPIO pins left to implement the authentic audio for the classic music programs written for the -1. Program flag, 3-6, were toggled by the program to generate square waves of the appropriate frequency for the 4 voices, routed out to be filtered by some simple RC filters, summed for the audio. I wanted to have the state of those reflected on the GPIO pins.

But, no luck, too many used up.

I'm wondering about doing the same as talked about here, use an I2C->gpio expander. It would mean changes to the music sw to use an IOT to update, and of course adding the IOT code. My concern is that the i2c operation won't be fast enough, although the rpi5 seems to support 1Mhz i2c, which should work. Any other suggestions?

Bill

[Oscar Vermeulen]

Bill,

That's because you don't like the audio to come through HDMI or a little USB audio dongle?

I have my doubts on i2c for audio as well. Although unfounded and untested.

Kind regards,

Oscar.

[Bill E]

I could say it's for authenticity, but it's actually that I don't know what has been implemented for the audio. You would need to be capturing the program flag transitions, then creating an audio bitstream from that. Plus, the filtering that was done originally would have to be replicated. All possible, yes, but has it been done? In many ways just simulating the original method is easier.

Bill

[Oscar Vermeulen]

Bill,

Yes, the audio is implemented. You can hear it through HDMI. Or the USB audio dongle that's included with the Rack version (choose audio destination in the Pi's GUI if you have both options!).

The notes are slightly out of tune at the moment, we'll examine why. The CHM PDP-1 also does not have the nicest tones IMHO - the MIT PDP-1 had extra circuitry as I understand it, and sounded much nicer. 

Getting the Harmony music compiler to work is a bit of work - not more so than on the real machine though.

Kind regards,

Oscar.

[Bill E]

The note timing depends upon a precise 170 or so (I forget the actual value in the code) microsecond loop. If the simulator isn't reproducing that timing, that would be the issue.

At some point a 'tuning' parameter was added to compensate for timing that wasn't quite right, but I don't know if the one in tapes has that, I'll take a look.

I'll also check out the audio implementation. Without the RC filtering, it's definitely going to sound worse. Might have to see if a software filter can be added. Each of the 4 voices had its own filter tuned for the range, bass, treble, etc.

Bill

[Bill E]

I finally got around to looking at the audio code in pdp1.c. It would be easy to add a simple digital 'leaky integrator' filter. I'll take a stab at that once my -1 is assembled, coming tomorrow. Also, the original audio was stereo. The 4 channels were mixed for 2 for the left, 2 for the right. If I can figure out how to do 2 channel in SDL, I'll try that also. Stay tuned.

Bill

[Bill E]

Ok, I implemented a tuneable low pass filter. I'm using 4 filters, one for each original 'channel', doing 2-1 mixing for each pair, then creating a stereo stream for the SDL output. I'm on a tear these days. It requires localized changes to the audio code, quite localized. It has to do its filtering using floats, but that's no big deal. Once I can run it for real on the simulator with actual audio output, I'll tune the filters and pass on the code.

Bill

[Oscar Vermeulen]

On Monday, September 29, 2025 at 12:52:36 PM UTC+2 wjegr...@gmail.com wrote:

The note timing depends upon a precise 170 or so (I forget the actual value in the code) microsecond loop. If the simulator isn't reproducing that timing, that would be the issue.

At some point a 'tuning' parameter was added to compensate for timing that wasn't quite right, but I don't know if the one in tapes has that, I'll take a look.

In my imperfect understanding, in my fuzzy memory, the tuning circuit was added to MIT's PDP-1, which is why that one sounded better. Is that your understanding too?

 

I'll also check out the audio implementation. Without the RC filtering, it's definitely going to sound worse. Might have to see if a software filter can be added. Each of the 4 voices had its own filter tuned for the range, bass, treble, etc.

That is much appreciated!

[Oscar Vermeulen]

Exciting!

Did you get the Harmony compiler to play a song? It's fussy but I have some notes I can clean up and publish, that is on the to-do stack anyway.

Yes, the timing of the pdp-1 simulator should be exact - even then, the notes sounded off to me. Which might be that the timing is not exact, but it's Angelo's code so unlikely, or something else. I am not sure if the PDP-1 at the CHM had any special audio circuitry? From Youtube, it also does not sound perfect (as the PDP-1X at MIT did, there's a recording on Youtube), but it does sound a bit better.

Kind regards,

Oscar.

[Bill E]

Which one? I've been using the one in tapes, which doesn't seem to be the full Harmony compiler. It does play, though. Or at least the correct flag lights blink.

Another tuning factor is the bitrate SDL is being told. You're currently using 40K, that might need adjusting.

I don't remember if the 1X had the tuning circuitry or not, but the player code does have a tweak value in it if I remember correctly. That adjusts the pitch the code generates.

There was one later system at LL that did true quadraphonic and used 4 12 bit D/A converters instead of just bit-banging. It supported volume changes and I think some different instrument sounds. I don't know any more about that one, though. Could be an interesting additional I/O project, but i2c definitely wouldn't work for that. SPI should work though. Much faster.

Bill

[Oscar Vermeulen]

Yes, I tested with the one in the tapes/ directory - only playing. I did not have the guts to encode any music, that is even harder.

If you use the Web interface (that is what I tested with), make sure to enable the Audio Output. The Audio output is coming from the Pi - so you need a HDMI monitor with sound on the Pi, or the USB audio dongle in the PiDP-1 Rack version. For use of the USB audio dongle, you need to set that as the audio output destination in the Pi's GUI menu.

Apologies, this all needs documenting. And maybe a script to automate.

Let me know if this is sufficient to get you your music. Otherwise, I'll do a write-up tomorrow!

Kind regards,

Oscar.

[Bill E]

I've been doing everything on my headless rpi via VNC, so no audio. Duh, didn't think about using the web intf. I'll give that a try. But, my kit is supposedly coming today, although with DHL it's hard to tell. My least favorite delivery company. If it does, everything is suspended while I build it.

Bill

[Oscar Vermeulen]

I just found out that the Web interface is good with audio, but right now the GUI interface is not - we'll get that going.

Kind regards,

Oscar.

[Matthias Barthel]

i wrote some lines to the pdp1.c file to talk with the i2c exanders without any bash script.

first intall wiringPi on the machine with: 

git clone https://github.com/wiringpi/wiringpi
cd wiringPi
./build

then i replace the both files in the zip file (the modified pdp1.c file and the makefile)

i have added the wirignPi lib to the makefile.

then stop the pdp1-simulator with pdp1control stop

compile the file with :

make -C /opt/pidp1/src/blincolnlights/pdp1

start the simulator with pdp1control start - have fun :)

load file in io register with the lio command and write the register to device 10 with iot 10 command .

Matthias

[Oscar Vermeulen]

Thank you! I will experiment next week. I think it would be fun to have some Programmed Demo Devices. In my mind, the PiDP-1 is for play and exploration, but the rest of the time it is nice if it does something pretty when it is left alone. As it lives in my bookshelf...

[Bill E]

It seems adding new IOTs is going to get out of hand pretty quickly since it requires changing the main emulator source itself. Maybe a way of integrating new IOTs from separate IOT files would be a good idea. Might need a little program to generate some glue code, then everything would be hooked up at compile time. Vaguely, each IOT goes in its own source file. The glue program creates an IOT dispatch table that pdp1.c uses. Each IOT call is vectored thru the dispatch table to the specific IOT's implementation. That way the pdp1.c code stays clean.

Thoughts? And sigh, yes, I could take this on if Oscar and Angelo are interested.

Bill

[Matthias Barthel]

this sounds very interessting and flexible. 

[Malcolm Ray]

If each IOT handler is built as a dynamic shared object (shared library), it can be loaded at run time using dlopen(3).

I'm imagining pdp1.c having a config file which maps IOT numbers to .so filenames, and at startup it dlopens them all.

This would allow a new IOT handler to be built separately from the main sim, and added by copying one file and adding it to the config file.

--
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/455c3cb0-5ac9-4f6c-96d8-f61336762cb2n%40googlegroups.com.

[Oscar Vermeulen]

That sounds like a very elegant idea!

Opens up the path to some Maker peripherals. First to come to my mind are programmable/addressable LED strips/panels for visual effects, and driving a little robot arm - or a pan/tilt mount. These are now $2 parts these days, would be cool to drive them with a PDP-1.

My other idea was a laser galvo as a 'cool' vector display. But I've cooled off a bit on that idea. Lasers, eyes. And the ILDA interfacing seems a bit of a challenge.

Kind regards,

Oscar.

[Matthias Barthel]

Like the real PDP1 (description in the Input -Output System Manual, Site 15) we need accees to

AC Bits 0-11 

MB Bits

program Flags (can be set from the external device)

IO Bits 0-17

If we have this for the 5 Iot Devices, i rhink its more then enough.

It is useful to write and read the values linux-like from textfiles in a special iot directory ?

Matthias 

--
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/82bce9a2-53a1-4995-8dfa-d9797b8689b9n%40googlegroups.com.

[Oscar Vermeulen]

Matthias,

On Monday, October 6, 2025 at 5:01:31 PM UTC+2 maklumatp...@gmail.com wrote:

Like the real PDP1 (description in the Input -Output System Manual, Site 15) we need accees to

AC Bits 0-11 

MB Bits

program Flags (can be set from the external device)

IO Bits 0-17

Maybe I miss something, but I don't think you need the AC or MB bits? Any IOT device should live with program flags and IO register? Or I miss some PDP-1 knowledge.

 

If we have this for the 5 Iot Devices, i rhink its more then enough.

It is useful to write and read the values linux-like from textfiles in a special iot directory ?

I would think the most elegant way is to bring them out as TCP ports. Like the physical connections to Typewriter and Type 30. That way, anything can hook up to them - a program on the Pi, or an esp32. Example code on how to do that is already in the src/ directory for the various normal PDP-1 peripherals.

I'll ask for Angelo's feedback. He's eager for Programmed Demo Peripherals as well - seems he is locked up finishing his Forth or assembler or whatnot. 

We both believe that the PDP-1 is in some way the most 'artistic' of the DEC range, in terms of what was done with it and how it feels to program it. PDPeripherals would make nice objects for a PiDP-1 to play with as it sits on a bookshelf waiting for his builder to come back home :-)

Kind regards,

Oscar.

[Matthias Barthel]

Oscar,

The io manual (http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/pdp1/F25_PDP1_IO.pdf) descibes whats available as iot interface.

The ac or mb bits are not needed generally, bit you can use them for addressing something (e.g. decoders...)

The PDP1 is indeed a beautiful playground to add your own hardware 👌

Matthias

--
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/67f181ed-e7b1-4423-ad64-b33253ebf456n%40googlegroups.com.