New PiDP-8 back in production

[Obsolescence]

Hi,

It has taken six months - but I finally sent out the first batch of PiDP-8 kits yesterday again, and from now on that will be a monthly thing again until the new custom switches I had made will run out. Which will not be anytime soon: the minimum order quantity will be enough for another 1000 kits.

Amazingly, there are 2300 PiDP-8's out there already and interest in building a replica PDP-8 seems to continue undiminished even now, 4 years later. If you are on the waiting list, in four weeks I will send you an ordering email for the next batch.

Many thanks to Warren for updating the software last month - and for all of you who added new features recently! Thanks to all the work on the simulator, the utilities, the polished-up OS/8, and the added vector graphics, the PDP-8 feels even more interesting to me than it did four years ago, such a lot of PDP-8 software and archaeology has been added since. I will update the web site to incorporate all of that next week, and link my web site into the relevant pages of the Wiki. And I should really write a new introductory manual for the PiDP-8 like the one I did last year for the PiDP-11. The current manual is old, refers to the original software - and just needs to provide an introductory overview of all the hidden PDP-8 gems out there.

The new kit looks identical to the old one on the outside. But inside, there have been a lot of improvements (hopefully, the proof of the pudding will have to come from those who will eat the first serving in the coming days...):

• The Pi is now placed in the middle of the front panel, so no more cutting slots in the side of the case.
  
• An I2C connector footprint was added to allow I2C devices to be hacked in as PDP-8 peripherals (like I did for the PiDP-11). I got rid of the old 40-in expansion connector, as it was used exactly zero times in the last 2000 PiDP-8s...
  
• There's also a LED cover panel much like the real PDP-8 has, that speeds up soldering the kit hugely as LEDs are automatically forced into perfect alignment. Plug them all in, flip the PCB, solder them up. Esthetically, I think the PiDP-8 PCB now looks very pretty with the LED cover and the new switches. I'll make some pictures. Unfortunately, you don't really see that once it's mounted inside the case...
  
• Most importantly though, the individual switches now have separate brackets which means no more fussing about getting them soldered straight in.
  

With the above improvements, the building time has been cut almost in half, I think. And the stress level in aligning LEDs and switches is pretty much gone. So I'm very happy with the improvements!

I hope we'll see many new PDP-8 projects in the coming years. I'm especially hopeful that adding an I2C connector will provide some hardware hacks to code for. I'll do a write-up, but adding support for custom hardware to the CPU simulator (PDP8_cpu.c) is very simple. Much simpler even than the barometer hack for the PiDP-11. The I2C pins are also accessible on the old version of the PiDP-8 by the way, but you have to solder the wires straight on the GPIO solder pins which is not terribly inviting.

Kind regards,

Oscar.

[Tom Lake]

So if we order on your website now, we'll get the new kit? 

Tom L

[Oscar Vermeulen]

Tom,

On Fri, 7 Jun 2019 at 02:28, Tom Lake <tl...@twcny.rr.com> wrote:

So if we order on your website now, we'll get the new kit? 

Yes - I ran out of the old switches, and when I had to reorder I took the opportunity to get these bracketed ones instead.

Though I keep spares of the old-style switches, should anyone ever need them.

Kind regards,

Oscar

[Steve Tockey]

Does anyone happen to know how many PDP-8/i were built by DEC? It would be interesting to compare how many DEC sold to how many Oscar has sold.

Total PDP-8 production by DEC has been estimated to be over 300,000 so it's highly unlikely Oscar can outsell that. But -8/i production must be a small subset of total PDP-8 production because most of PDP-8 production were -8/e (including -8/m and -8/f variants) and -8/a.

-- steve

[Tom Lake]

Well I'm doing MY part to break 300,000. I'm ordering a third one from him!

Tom L

[Steve Tockey]

I'm doing my part, too. I've already got three: one 2015, two 2016s.

-- steve

[Obsolescence]

Steve,

On Friday, June 7, 2019 at 7:55:21 PM UTC+2, Steve Tockey wrote:

Does anyone happen to know how many PDP-8/i were built by DEC? It would be interesting to compare how many DEC sold to how many Oscar has sold.

I once read the number 3480 PiDP-8/I's. Or maybe 3840 - I forget. So yes! That definitely is a long term target! To speak in the modern lingo of my son, that would be Satisfying.

It's a sign of how much has changed. I remember driving to the post office in my little subcompact with 100 kits in the back, the fruit of three weeks filling parts bags in the evening hours. And remembering those DEC factory photos in the Small Computer Handbook. What once took several huge factories and 100 trucks to move out, can now be done by a Lone Nerd in his evening hours(*). Another expression of Moore's law.

Kind regards,

Oscar.

(*) and a huge Raspberry Pi factory, and a huge PCB factory. But that muddles the big picture with small details.

[Tom Lake]

Hmm. In my day, we quoted Dr. Beaker from Supercar: "Satisfactory...Most satisfactory." 

[Geoffrey McDermott]

Shipped on Wednesday, arrived today in the backwoods of North Carolina, USA, even with a Sunday in-between.......

Guess I'll adjust my scheduled activities (HA!!) and build a PiDP8.

On Thursday, June 6, 2019 at 6:05:44 PM UTC-4, Obsolescence wrote:

[Warren Hardy]

Mine arrived today thank you. West cost USA. Now to find some good instructions

[Tom Lake]

How are the new switches?

[Oscar Vermeulen]

Warren,

On Tue, 11 Jun 2019 at 00:26, Warren Hardy <hellfi...@gmail.com> wrote:

Mine arrived today thank you. West cost USA. Now to find some good instructions

I did a new Building Instructions page over the weekend. Of course *I* think it's good but let me know your feedback.

Still on the to-do list is a way to integrate the recent version of the simulator with Ian Schofield's and Frederic Rible's VC08/VC8E graphics. At the moment, that's a separate tarball, downloadable from the forum here. As Warren concluded, morphing that into the Official version of the source code will be tough if we want to easily update to future simh versions. At least for a Noob like me, nontrivial. I spent yesterday looking at it.

So for the moment, maybe we just live with two binaries of the simulator and solve the problem with a little script that swaps between the two on the fly. Although I think that will leave some people Unimpressed as a solution.

Kind regards,

Oscar.

[Oscar Vermeulen]

Tom,

On Tue, 11 Jun 2019 at 00:47, Tom Lake <tl...@twcny.rr.com> wrote:

How are the new switches?

They are identical to the old ones except that the metal tab is now folded down to make a bracket for the switch. So it's easier to solder all switches in a straight line, but once done you do not see any difference.

It's just that I learned a bit over the last three years, so with the new switches, the LED cover bracket, LED spacers and the repositioning of the Pi to the center of the PCB all of the fidgety construction steps have been eliminated. I can now make a PiDP-8 in two instead of four hours and not worry about fidgety alignment of the LEDs and switches.

Kind regards,

Oscar.

[John Kennedy]

Anyone get an extra white momentary switch in their kit? I was one short!

[marcwolf60]

Great news about the improvements.

Will you be releasing the Gerber files online, or will these be proprietary.
I now have my own CNC machine and would love to use it to cut a LED aligner with it :)

[Geoffrey McDermott]

They're very easy to install, but require much more solder because of the size and number of electrical contacts. They are NICE!

[Geoffrey McDermott]

On Monday, June 10, 2019 at 7:07:55 PM UTC-4, Obsolescence wrote:

I did a new Building Instructions page over the weekend. Of course *I* think it's good but let me know your feedback.

Kind regards,

Oscar.

So far, the only input I have concerning the instructions is that the Raspberry PI has no need for an insulator to keep the USB/Ethernet connectors from shorting the components on the PCB, as the clearance is about 3mm(about 1/8" in US). I did see some insulation with self-stick included in my kit, but it actually got in the way more than it helped.

My kit is finished(3+ hours spread across 6 hours), and the hard parts remain.......woodworking is not my forte', and deciding where to mount the external connections isn`t exactly determined, because the cables I ordered haven't arrived yet. I'm using 'keystone' inserts/connectors designed to mount as a faceplate mounted on a wall. I figure that it will serve as a good place to mount the bulkhead connectors while acting as a bezel covering up my woodworking abilities.

[Oscar Vermeulen]

Geoffrey,

On Tue, 11 Jun 2019 at 11:12, Geoffrey McDermott <crusade...@gmail.com> wrote:

So far, the only input I have concerning the instructions is that the Raspberry PI has no need for an insulator to keep the USB/Ethernet connectors from shorting the components on the PCB, as the clearance is about 3mm(about 1/8" in US). I did see some insulation with self-stick included in my kit, but it actually got in the way more than it helped.

Indeed - you should be right. From now on, I am using not 'extra tall Raspberry Pi 2 headers' but a custom job of extra-extra-tall ones. Basically, the vendor sticks a third plastic spacer on a long-pinned header. The mention of the insulation is purely conservatism on my part, I'll remove it.

Kind regards,

Oscar.

 

[Oscar Vermeulen]

John,

On Tue, 11 Jun 2019 at 06:16, John Kennedy <johntk...@gmail.com> wrote:

Anyone get an extra white momentary switch in their kit? I was one short!

I'll send it on Thursday! Good that I read this post though, I thought mistakenly it was a PiDP-11 switch you needed :)

Kind regards,

Oscar.

[Oscar Vermeulen]

Marc,

On Tue, 11 Jun 2019 at 09:45, marcwolf60 <marc...@marcwolf.org> wrote:

Great news about the improvements.

Will you be releasing the Gerber files online, or will these be proprietary.

They are in the attachment. Let me know if you want the Kicad project files too.

Note - the LED panel cover contains an SMD footprint. It's useless and can be ignored, it only serves to ensure JLCPCB puts on their newest black coating...

Kind regards,

Oscar.

[Robert Evans]

Oscar,

  I wonder if you can post the kicad design and schematic for the new PiDP-8.  I am starting a build with circuit board Rev 3b 2019-05-13.  Although I have searched for kicad design and schematic files that match this board revision, all the ones I found seem to be for the 2015 version.

Best regards,

Robert Evans

[Warren Young]

On Tuesday, October 27, 2020 at 2:34:21 PM UTC-6 evans.r...@gmail.com wrote:

  I wonder if you can post the kicad design and schematic for the new PiDP-8.  I am starting a build with circuit board Rev 3b 2019-05-13.  Although I have searched for kicad design and schematic files that match this board revision, all the ones I found seem to be for the 2015 version.

Oscar, you're welcome to check that into the "hardware" directory of the PiDP-8/I repository atop the current version.

[Warren Young]

Oscar sent the files to me privately, and I've checked them in on trunk. I left out all files that looked like they were generated (logs, caches, Gerbers, etc.) so please let me know if there's anything you can't recreate from the subset I checked in.

[Robert Evans]

I opened trunk/hardware/pidp8i/PDP8.pro  with  kicad and I could see the schematic and highlight nets in the x-ray view of the circuit board.  This was everything I needed to find and fix the non-connection that caused none of the row7 LEDs to light on my board.  I think that is enough, assuming others can use kicad.

Thank you Warren and Oscar !

[Heinz-Bernd Eggenstein]

I'm reviving this rather old thread because I'm looking for collaborators to finally make use of the I2C header that was added to PiDP-8 in the latest release. The potential of this was discussed in this thread but I think nothing concrete has yet developed from it.

So the idea to breathe life into this  is the following:

Let's add a generic "I2C bridge* device to SIMH/PDP-8 that will allow users to offload the processing of selected IOT instructions to (typically) microcontroller(s) connected over I²C. With this mechanism, you could quickly develop or prototype new devices for PiDP-8 without having to mess with SIMH source code, the logic can instead be done in (say) MicroPython or CircuitPython or Arduino-stuff on the microcontrollers like the 5$, dual-core Raspberry Pi Pico.

Let's say you want to interface with an Analog-to-Digital Converter, mimicking the IOT 653X and 654X IOT instruction API used by several DEC products.

As far as SIMH is concerned, all you need to do then in the boot script would be:

; enable the bridge device , as it will be disabled by default

SET I2CB ENABLED

; enable two "units" of the device, one for the  ADC  (device 53) and one for a multiplexer (device 54 )

SET I2CB0 ENABLED

SET I2CB1 ENABLED

; configure a PDP-8 device number to I2C device mapping, here both devices are implemented with a single microcontroller at address 0x11 on the I2C bus

SET I2CB0 DEVNO=53

SET I2CB1 DEVNO=54

SET I2CB0 I2CADDR=11

SET I2CB1 I2CADDR=11

And that's it. Now you can use IOT commands in your PDP-8 code like ADSF, ADCV and ADRB to "talk" to an ADC on a microcontroller over the I2C bus, so of course you need to implement some logic there, but with languages like MicroPython this is relatively easy compared to , say, changing the code in SIMH to implement specific devices.

I'm at a point where all this seems to work in principle, the new "I2CB" device is implemented in an experimental development branch in the PiDP-8 software repository (branch i2c-bridge-device).

https://tangentsoft.com/pidp8i/timeline?r=i2c-bridge-device

There are some limitations tho, e.g. I'm not quite sure how devices with interrupts would fit into this scheme, if at all. Also the current code could certainly mbe made more robust against  all sorts of I2C related exceptions. Also I2C is not exactly super-fast and might slow down the PiDP-8 compared to comparable real PDP-devices.

So I guess this is a good time to ask PiDP-8 lovers to come up with ideas where this little project might go and how to improve it and help test it.

Cheers

HBE

[michael.9...@gmail.com]

Is there a GPIO pin on the Pi that could be used for an interrupt?

Would polling the I2C device for a simulated interrupt work OK?

I am using I2C on a Pi Pico at more than 1 MHz, so I2C can be fast.

[Heinz-Bernd Eggenstein]

Indeed there is, GPIO19 is unassigned at least in my version of the board (2021), even tho there is no header for it (unlike the PiDP-11). But at the moment I don't even fully understand how interrupts worked on the PDP-8 itself (e.g. finding out which device fired one ...) or in the SIMH framework, I need to read more stuff. What complicates things is that there could be more than one I2C device involved, the new I2CB device is not limited to just one.

>I am using I2C on a Pi Pico at more than 1 MHz, so I2C can be fast.

Interesting! The Raspberry Pi that hosts the SIMH for most PiDP-8 kits is AFAIK using only a 100k bps baudrate by  default (with Raspbian OS images), but can be configured easily to use higher clock rates. 400kbps seems to work just fine according to reports. 1MHz is impressive, do you already have to worry about "electrical details" like the lengths and shielding of the wires at thoses speeds?

HB 

[Mike Katz]

Interrupts on the PDP-8 were very simple. 

Any interrupt, if interrupts were enabled, would do the following:
    If the Extended Memory/Time Share Option is installed the User mode, IF and DF are stored in the Interrupt Buffer
    Set the Interrupt Mask
    Store the PC at address 0000
    Start program execution at address 0001

It was up to this single interrupt handler to save any registers (AC, MQ, Link, etc.) check each device, in order of desired interrupt priority, to see it if was the interrupting device.

INTRPT,    0
           JMP HANDLR

/
/  Interrupt handler
/
HANDLR,    SPL            /  Skip on power low
           JMP CHKKBD     /  Jump to keyboard check
           JMP LOWPWR     /  Jump to low power interrupt handler
CHKKBD,    KSF            /  Skip on Keyboard Flag 
           JMP CHKTTY     /  Jump to teletype output check
           JMP KEYBRD     /  Jump to the Keyboard interrupt handler
CHKTTY,    TSF            /  Skip on TTY flag
           JMP NXTDEV     /  Jump to next device
           JMP TTYOUT     /  Jump to TTY output handler
NXTDEV,    .
           .
           .

To return from an interrupt:
    Restore AC, MQ, Link, etc.
    RMF           /  Restore Memory Fields (Only needed if the Extended Memory/Time Share Option is installed)
    ION           /  Turn interrupts on (the actual turning on of the interrupts is delayed by 1 instruction)
    JMP I 0000    /  Continue execution at the point where the program was interrupted. 
                  /  Note:  The interrupts will be turned on and the Instruction Field will be changed prior to the execution of this function but after the fetching of it.


This is how the PDP-8 handles interrupts.  SIMH when simulating the PDP-8 does the same.  This is not how SIMH handles Raspberry Pi Interrupts.

I hope this helps.

--
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 view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/5973e1e1-f741-4d2a-8426-ebd77e6dda03n%40googlegroups.com.

[michael.9...@gmail.com]

>The Raspberry Pi that hosts the SIMH for most PiDP-8 kits is AFAIK using only a 100k bps rate by  default (with Raspbian OS images), but can be configured easily to use higher clock rates. 400kbps seems to work just fine according to reports. 1MHz is impressive, do you already have to worry about "electrical details" like the lengths and shielding of the wires at those speeds?

All I2C devices will run at 100 kHz. It is easy to configure the Pi for 100 kHz and know that it will always work and not have to worry much about pull-up resistors.

Most new chips will work at 400 kHz, but you have to check to make sure. Most of the new chips say that they are guaranteed to work at 400 kHz, but don't specify an upper limit to the bus speed. We did some experimenting and found that our latest PCB design works fine at over 1 MHz.

At speeds faster than 100 kHz you need to be careful about the total capacitance of the PC traces and chips, and you need to determine what pull-up resistors to use so you get a reasonable rise time on the I2C signals. This takes some work with a calculator and an oscilloscope.

For the interrupts, you could have an external emulated peripheral pull on the GPIO line, and have SIMH poll the GPIO like to see if an interrupt has occurred. You could also have the SIMH side of the I2C bridge poll the I2C devices to see if an interrupt occurred and then simulate an interrupt in SIMH. I am not sure that having a physical interrupt would be any better than simulating an interrupt, and would require more hardware.

If the PDP-8 OS or device handler was written to use interrupts, we will need a physical or simulated device interrupt or it won't ever know that external I/O happened.

[Heinz-Bernd Eggenstein]

Thanks a lot for your explanations, sounds like I'll try 400kHz and do some benchmarking, and I need to look deeper into SIMH code how to reconcile interrupts from devices emulated in software and actual devices connected via I2C (+ an additional GPIO perhaps),

Cheers

HBE

[Mike Katz]

In the best of of all worlds the Rasberry Pi I2C interrupt would tell SIMH that an interrupt has occurred and that would in turn generate an interrupt on the emulated PDP-8 and that interrupt would respond to the appropriate Skip On Flag IOT.

To view this discussion on the web visit https://groups.google.com/d/msgid/pidp-8/a481fc60-8fd5-4609-81bf-cf43ef640e5fn%40googlegroups.com.