Updates, philosopy, etc.

[Bill E]

I've merged most of aap's emulator changes into my branch, not sure how much longer I'm going to do so. Why? A rationale, but hopefully not one that will start a flamewar follows.

We have a significant philosophy difference. In my discussions with him, his goal is what he called (I think) 'software archeology', basically duplicating as exactly as he can the internal behavior of the PDP-1, down to implementing all the subclock states, naming vars the same names as the hardware flip-flops, etc. While I find this very impressive, and I really like the duplication at the full execution cycle of the 5us+ timing, does it really matter that the code looks like the hardware? It's not something anyone using it would see and it certainly adds complexity and obscurity. Take a look at pdp1.c if you want to know what I'm talking about.

My view is having an accurate duplication at the level you see when you write code for it and have it execute with proper timing. I want to write code, implement new things, not just run the old stuff. We have a spectrum from aap's end, me in the middle to simh at the other end, which doesn't care about duplicating timing, just functionality.

A good example is the current discussion of the drum. I have an implementation that passes the DEC diagnostics, has quite close to the original timing, even uses a version of the high-speed-channels, and is documented. This apparently isn't acceptable because it doesn't exactly duplicate the hardware, or something. In fact, doing his level of duplication is in some ways fruitless, there is just too much missing documentation about all the PDP-1 variants to be sure.

I doubt he'll ever adopt the very useful dynamic IOT loading for the same reasons.

However, again, I applaud his efforts and if it makes him happy, that's good.

So, my branch is probably going to diverge even more. If I'm the only one that ever uses it, fine with me, I've written thousands of lines of code that work and are useful to me, that are commented and documented. (22,000 lines of code and documentation to date. Yes, that many.) I implemented a new assembler and debugger to make coding easier for me. They are both (imho) light-years ahead of the native versions and the macro1 cross-assembler. Are they authentic? Of course not. But software is never static. If PDP-1's were still around, people would still be writing new code for them and integrating modern features.

I will continue to update my branch with my changes and probably some targeted merging. Not planning on disappearing for months either. (ok, that was a snipe, sorry, but knowing this wasn't another abandoned project could have lead to closer tracking of changes, but maybe not)

So, if you want to do new things like this one, give mine a try.

Bill

[Oscar Vermeulen]

Bill,

I've worked with your version of the software over the past week, getting to know it up close, and it is a huge step forward! Amazing, it delivers all the peripherals I had hoped for in a farther-out future in one go...

To explain a little bit, I have this uninteresting health problem, some days/weeks/months I am just Foggy in the Brain - which explains why I was offline recently. 

But actually this week , I've locked myself up with Angelo to take some good steps forward. We had Mike Hill over today, which was great fun too. But the main part was to integrate your work on the drum, the Type 33 (that was a hotly desired feature as well). And also adding some ideas that either I or Angelo brewed up over the past few months.

Inevitably, code paths diverge. Angelo has his own style of writing code that traces the low level schematics - then gets into the issue of which schematics. 

Most of the PDP-1s originally made are either slightly or hugely different once you go into the peripherals (or even earlier, really). 

So it gets increasingly difficult to make a universal PDP-1 replica once you go into the path of adding peripherals. And individuals do things in their own way - Angelo only works from schematic sheets he gets, you take more my approach to peripherals where they need to work on the logic level.

So, I like the following proposal, what do you think:

For people new to the PiDP-1:

• The install instructions will be to start with the base PiDP-1, saved from now on in /opt/pidp1-base. 
• Then, the install instructions will advise newcomers to get familiar with this base PDP-1, then add machine variants such as /opt/pidp1-045, /opt/pidp1-048.
• And there is a simple instruction 'pdp1control serial-number 045' to switch seamlessly between the forks.

This way, 

• the base version is the known-good starting point for people who just built their kit. That is important: start simple, not everyone goes into democoding. The PiDP-1 can also be a 1960s 'games and demo console'
• But right away, the instructions on the web page will tell them of the various variants they can add with a single git clone command, and their features. I can add a subpage clearly describing each variant.

This feels Historically Correct to me: if every real PDP-1 had its own feature set (even, instruction set...), that will also be true to PiDP-1s. By using 'pdp1control serial-number X' , the user just transfers from one version to another.

The idea I have in mind:

• /opt/pidp1 is a symlink to the current variant being used. For instance, it is a link to /opt/pidp1-base or /opt/pidp-1-045
• 'pdp1control serial-number X' just stops the simulator, changes the symlink, and starts the new one.

It gives us complete freedom over our 'own' machines, and shape them as we want. 

And gives users trivial ease of switching between PDP-1 variants. Instead of having one PDP-1, you can have them all, what is not to like? :-)

Question: Do you think this is a good idea? And if so, shall we use the serial numbers on the back of our PiDPs, or just pick a historical machine we like? 45 was BBN's PDP-1D, 48 the one from - I think - Harvard or Stanford.

I prefer the PiDP serial numbers, not the historical ones. Or we could just give them names, you keep using -modz, Angelo's version becomes -aap?

And last question, now I am relatively Brain Fog Free - shall we do a Google Meets call with you, Angelo, me? I think that would be great. There's much to discuss! Let me know, I can do most any time and this week, Angelo as well.

Kind regards,

Oscar.

[Matthias Barthel]

Oscar,

The pdp1control with serialnumber to start the various Mods sounds good. 

E.g. with my mod we can connect real devices with my backplane. I'am working on a real papertape puncher and reader for my pidp1. I build these devices from a old non working device.

I also build a wireless module for atari-joysticks and for the spacewar-controllers. 

Next project is a real 4K core memory for my esp32-pdp1 - thats my present for me next christmas 🙃 

Best 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/e1dd0ea3-814f-4ebf-b0be-681e68819fabn%40googlegroups.com.

[MICHAEL GARDI]

First of all I'd like to say that I'm loving the energy going into the PiDP-1. 

I'm not an infrastructure guy, but Oscar's proposal to support the various flavors of PDP-1 and peripherals sounds good to me. I think it's important that the PDP-1 be as fully represented and faithfully reproduced as possible (regardless of the underlying mechanisms).

One thing that I feel pretty strongly about though is that the base PiDP-1 should adhere as closely as possible to the Computer History Museum's PDP-1. One of my goal's right now is to have code that I have written run on the CHM's PDP-1. I would be devastated if I ever got the chance and the code failed to run because I had inadvertently taken advantage of some feature that the actual machine did not support. A little selfish of me I know, but you could do worse than to have your base implementation reproduce the functionality of the last known working PDP-1. I think this also honors the hard work that the CHM team put into getting the PDP-1 up and running.

My two cents,

Mike

[Bill E]

Just a quick response, haven't had the time to read thru Oscar's proposal, it's election day here in town and I'm a town official, have to be at the polls most of the day. But from a quick scan, seems good. One thing I added was a config file that is read on startup, there's no reason it can't control all the additions I've made to the pidp1 core itself, it already can control much. The ones of concern for compatibility are the 1D extensions. I also don't know how common the origin-switching dpy instruction was, but it overlaps with one of the symbol generator instructions, so that is already configurable. As for the added peripherals, they are IOTs, so code that doesn't use them is of course not dependent on them.

I know the CHM system has a lightpen and type 33 symbol generator, I think my IOTs for those are compatible, but without real hardware testing, hard to tell. The drum and DCS system (if limited to the base functionality) should work on a real -1 that has them, but that is zero unfortunately. I'll respond in more detail later.

One mistake I did make is that I reformatted the code I've been working on when I thought it wasn't going to be updated anymore, that is a real pain when it comes to merging. Oh well, my problem to suffer thru. I am slowly removing the obnoxious dos line endings that got into my copies because gvim on my Ubuntu wasn't bothering to pay attention to my vimrc file, that will help.

Bill

[Oscar Vermeulen]

On Tuesday, March 10, 2026 at 9:19:13 PM UTC+1 michae...@gmail.com wrote:

One thing that I feel pretty strongly about though is that the base PiDP-1 should adhere as closely as possible to the Computer History Museum's PDP-1. One of my goal's right now is to have code that I have written run on the CHM's PDP-1. I would be devastated if I ever got the chance and the code failed to run because I had inadvertently taken advantage of some feature that the actual machine did not support.

Yes, that would be our nightmare scenario as well. I asked Bob Rosenbloom if he'd consider running Michael Gardi's Lunar Lander on the Real Machine. That's a masterpiece and would be a nice test. There's only one way to be sure...

 

A little selfish of me I know, but you could do worse than to have your base implementation reproduce the functionality of the last known working PDP-1. I think this also honors the hard work that the CHM team put into getting the PDP-1 up and running.

This is indeed the definition we have of the base machine (the standard software release): be the CHM machine. Although with more memory (that will not hurt).

I think it is a very good thing if others can add their features to the PDP-1 as 'other serial numbers'. One thing would be to know if it is OK to copy good ideas from one 'serial number' to another, to improve all the machines with common parts. Like, the genius new assembler from Bill. That should replace macro1_1 ASAP.

...writing PDP-1 cross assemblers seems popular. Bill did one, Angelo did one, Mike Hill came over today and showed his one. I need to do a write-up of his visit: there is sooooooo much more to his Blinky demo than you think. Its source code (4500 lines) reads like a PDP-1 advanced programming book. I'll get it out ASAP.

Kind regards,

Oscar.

[Oscar Vermeulen]

Oh wait! You ARE Michael Gardi! Well, those were my unfiltered thoughts :-)

[Oscar Vermeulen]

Matthias,

I very much agree that an ESP32 mod is high on the priority list. If a Pi Zero is more appropriate for PDP-1 emulation, then an esp32 is more appropriate than a Pi Zero...

Kind regards,

Oscar.

[Bill E]

Ok, Oscar, sounds like an excellent idea, especially if I make sure all the new features are individually controllable via my new config file. Note that a few are transparent, like the improved audio. I'm also going to add some warning switches to AM1 such as 'warn if 1D instructions are used'. That way, people can write code for a 1C without risk. So, how do we make this happen? I'm happy to work with you and Angelo, it would be nice if others would join in. I do a lot of testing, but  I've written so much code I'm sure there are bugs. In fact, I fixed an obscure in AM1 just a day ago.

BTW, I have successfully disassembled spacewar, snowflake, and a few others, converted them to am1 syntax, recompiled them with am1 and they work as the original, so it should be in pretty good shape. Assuming I don't break something with my merging.

One thing we need to manage is compatibility with peripherals like the type 30, the gui, etc. especially as people start implementing things like the marvelous new type 30. I think that so far that's not a problem, I use the standard ones myself, with only the lightpen and screen scaling mods.

About serial numbers, not sure what should be done. We're not really modifying hardware like was so common, the same sw can run on any of the pidp-1s. And, if features are switchable at a fine grain, then one serial number isn't going to cover them. Maybe assign a unique bit to each feature, then the 'serial number' for someone is the number represented by the bits they have enabled. That's sufficiently obscure that it fits the lack of documentation we have for the originals. :) And since IOTs were added all the time, being hardware, not software, we could have a serial number IOT that would return the number representing the enabled features while staying true-ish to the original concept of an IOT.

Angelo, the new standard break system seems to work fine. I haven't tried sbs16 yet.

Bill

[Oscar Vermeulen]

Great! Then I will implement a mechanism where

'pdp1control version pidp1-name'

will switch seamlessly between version directories. At present, we have -base (the original one) and -mods (your upgrade).

I'll contact you by email to see if you have time for a Google Meets!

Kind regards,

Oscar.

(currently learning the am1 cross assembler - amazing what this makes possible, just looking at programSelector.am1 now)

[Angelo Papenhoff/aap]

It looks like we're in the process of resolving the tension between our different approaches, but i still wanted to comment a bit, just to make my perspective on that clear to everyone:

first of all, the code is unreadable because that's what happens when you attempt to simulate hardware in code. nobody in their right mind would write an emulator the way i do if not for the purpose of simulating internal behavior to some degree of accuracy. but that is just what i find extremely fun and satisfying. as i explained to you in our private mails i am at heart a historical linguist (i even got a BA out of it) and my interest in computing history is just another way this fascination surfaces. so whether i trace the way reconstructed proto-indo-european words end up in the ancient greek dialects (my BA thesis 10 years ago) or whether i compare different instruction set architectures, or versions of schematics for the PDP-1 or some other computer, that's all the same to me really. and going the long way and actually digging as deep as i can to understand how the machine works is precisely the reason i'm doing all this.

so taking an existing implementation which doesn't attempt to model the internal workings, no matter how well it works, is not something i want to spend my time on. that doesn't mean it's not a perfectly valid thing to do, just that it's not for me. my motivation derives from precisely *not* doing that :) feynman said something like "if i can't build it, i don't understand it" and that has always been my motto as well.

to put it shortly: i'm interested in simulation (modeling the internal behaviour), emulation (modeling the external behaviour) doesn't cut it for me.

so anyway, as for the actual features of your -mods repo: the fact that you have a drum and symbol generator and what not greatly motivated me during this week with oscar to push my simulation endeavors further. getting known-to-work stuff to also work in my simulator is definitely the goal. so operation man-cave, as i call it, has been quite a productive time so far (one day left).

the dynamic IOTs are in principle a lovely idea! wiring more stuff into the machine is precisely in the spirit of the PDP-1. i don't think i'm 100% on board with the implementation but if you want maybe we can figure out a way to do it that both of us will be happy with, and make the .so modules work with both our branches.

my idea is that i want all standard DEC hardware in the core-simulator (that includes the drum and the symbol generator), but for doing things like hooking up LEDs matrices, playing with robot arms, controlling a spotify playlist, dimming the lights in the room, calling the elevator, or whatever else you may want to do with a PDP-1, i think dynamic IOTs will be very cool!

another idea i had in this direction was to expose enough of the simulator to lua to be able to implement devices in that. would have the advantage of not having to compile any code, just pass around lua files to your pidp-1-friends. on the other hand i don't think lua supports octal literals, which makes it a pretty useless language for our purposes.

anyway, we can discuss it.

aap

[Bradford Miller]

You may have interchanged the meaning of those two words.

[Angelo Papenhoff/aap]

The article is worded a bit strangely, but it seems to agree with me:
"Emulation is the process of replicating the behavior of one system on another system."

"simulation is the process of creating a virtual environment that mimics the behavior of a real system"

in a weather simulation you simulate the internal state of the "weather system" to some degree of accuracy, but you will never make it rain. you cannot replace real rain by simulated rain.

similarly, a flight simulator may be very close to how a real plane behaves but it will never get you from A to B.

on the other hand you might consider that same flight simulator to be a cockpit *emulator*: the external behavior of just the cockpit that a pilot interacts with is modeled closely enough to the real thing that it can be used to train pilots! coincidentally, constructing such a thing was the original goal of project whirlwind, the PDP-1's great-grandparent.

it's all a matter of what you consider to be internal behavior you want to replicate or study and what you consider to be the external behavior such that you can replace the real thing by an emulator. and how closely you want to match the thing that you're interested in.

simh for instance is clearly an emulator: you can replace some real PDP-8 systems with it without it making much of a difference (depending on what they do, if you need, say, an A/D converter then simh isn't gonna help you out of the box). meanwhile it is not a simulator because the internal state of the real machines is usually not modeled.

my pdp-1 is clearly an emulator too, but it simulates the internal state more closely, so it's more in the simulator camp than simh is.

of course there's also IBM's old definition where simulation is pure software and emulation is software + hardware assist. that definition is used in e.g. the VAX-11/750 manual where they speak of the hardware as the COMET and the microcode as doing "VAX emulation". i don't consider that to be a particularly useful definition. the internal vs external view makes a lot more sense to me.

so my take is: emulation replicates the external behavior closely enough (for a given purpose) that you can replace the real thing with an emulation. simulation models the internal behavior so you can study how a thing works inside.

and these two can overlap and coincide of course. i had to do very little debugging on the symbol generator today because i modeled the internal state of the real thing closely enough such that it was already mostly working when i first tested it. but the result was of course an emulator too (and Bill wrote one before that). had it been a verilog simulation with me just looking at waveforms...well that's not emulation even if it had allowed me to study the internals even more closely. (in fact, i plan to write a simple verilog simulation to get a better understanding of the type 23 drum, so i can emulate it :) )

[Bill E]

I'm completely open to modifying my stuff to better align with how the emulator/simulator works. Many of the implementation decisions were made without a full understanding of the internals of the emulator/simulator, didn't have the patience to dig into the schematics, etc., even though I am an EE. And I guess this perhaps summarizes our different approaches, my engineering view is that if it works from an external black-box view, that's what's important. I don't care (from an abstract view) what goes on inside the black box. That doesn't mean I fully approve of the simh approach, the black box should duplicate the externally visible behavior including timing. I want easy-to-use tools to make my use of said black box easier, I'm not into pain and suffering for the sake of historical accuracy, I used the bloody stuff at the time and remember enough that I don't need to remember it again. :)

Bill

[Ian Schofield]

Hi All,

 I added this to the philosophy thread as it may be relevant to all of us. You (Bill) do make a valid point about the attack/decay parameters for real bulbs. I made quite a fuss about this in the PiDP8I project! As a (now retired) Consultant Neurophysiologist this is of more than academic interest. It all comes down to perception (as is the case for everything). Our visual system has a number of properties that complicate what we actually see (experience) such that it is difficult to predict what we see when presented with a given visual input. For example, we are quite sensitive to minor changes in luminance such that flicker is noticeable even when the luminance change is quite small .... up to a point in that the flicker frequency has an impact here. I could go on and on about this.

Anyway, for practical purposes the problem we have is with the number and length of microstates in the simulation. If these are known,  then it is quite easy to take a snapshot of each of the machine states to generate what is effectively a PWM stream provided that the update intervals match the actual length of a given microstate. This is really hard under Linux/Windows due to the task scheduling. This is where a Pi Pico has a substantial advantage in that the internal states can be precisely timed. Then, this data can be presented to the user via the Leds interface provided that this process is also synchronous. Here again, Linux fails dismally. The ESP32 is marginally better than Win/Lin but does have a lot of variable overhead to run USB and Wifi.

I am still uncertain as to the difference in perception between a Led driven with a high speed PWM signal versus an incandescent light bulb. However, there is also the option to drive each Led through a low pass filter with a time constant that more or less matches a bulb.

This is entirely achievable as there is plenty of board space but will increase the cost......and simplify the software.

I think I have typed enough contentious claptrap for now and would conclude that the only definitive solution is to use an FPGA with lots of IO pins and lots of wires as seen in the cable harnesses of the machines we attempt to simulate.

Regards, Ian.

[Norbert Landsteiner]

> so my take is: emulation replicates the external behavior closely enough (for a given purpose) that you can replace the real thing with an emulation. simulation models the internal behavior so you can study how a thing works inside. and these two can overlap and coincide of course.

I think, this is good point. While close modelling of the internal behavior is desirable and often a prerequisite for replicating the experience, the external behavior, which conveys the experience, may be another story. E.g., the experience conveyed by the original Type 30 display tends to fall apart on frame-based media, and this will be an issue when we try to replicate the experience on a frame-based display, regardless of the frame rate (but probably less so as this becomes faster and faster). So we probably have to allow for some license in order to capture what is intended, because our combined physical and psychological response will be different and we may want to compensate for this. On the other hand, much like with PWM streams or resampling of audio streams (my example would have been resampling the 1MHz 1-bit audio of the Commodore PET to modern digital audio), accuracy in microstates is probably important to beginn with. And there's a point to be made that this will make things even easier…

Notably, when it comes to web interfaces and mitigation strategies for time-based side-channel attacks in browsers, there's now another twist to this, as the exact timing of the runtime performance will not be known (esp. with modern async protocols): while we may know the exact timing and related microstates on an idealised internal timeline, the exact behavior on the real-world device, we aim to replicate this, remains unknown. Maybe, technical channels, like audio and video, may even drift apart over time, and there's no way of telling this "from the inside", as both still refer to the same ideal timeline. As this adds another insurmountable epsilon to the equation, there comes a point where we have to declare defeat in any pursuit of the true image – and go with the good enough.

Best,

Norbert

[Unibus]

Hi,

The exact response of the P7 phosphor is available and I'd started to document. Most response graphs are less than useless as they don't show the imbalance in brightness between the two phosphors. With care it should be possible to reproduce the P7 response with modem hardware. Absolutely no idea if a Raspberry Pi  will be capable. 

Regards,

Garry

--
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/638955d2-356f-415e-b9e0-8f8b8f1a5798n%40googlegroups.com.