I wonder what the challenges of emulating 36-bit machines on 32 and 64 bit systems are.
Can you even do JIT? You probably don't need to, considering how slow these PDPs actually were, but it's an interesting question nevertheless.
For ALU ops and address computations, if the 36-bit machines are also using the 2s-complements convention you can just do all computations in 64 bits and ignore the top bits.
For memory accesses you could simply round up the data bus width of emulated CPU to the next power-of-2 as the "host word size". For instance if the emulated CPU accesses memory as 12-bit words, use an uint16_t array on the host CPU and treat the top 4 bits as junk.
JIT-ing probably wouldn't make much of a difference with this approach as long as your host CPU is wider, since you just ignore the top-bits.
When writing a chip emulator, it's actually not uncommon to deal with 'odd' bit widths. For instance a sound chip might have 3- or 5-bit wide counters.
Also, in a language like Zig this stuff is quite convenient since Zig allows integer types of any width (e.g. you can have u3, u5, u36 etc...). Just have to be careful about how those types are represented in memory (e.g. bit-packed or not).
I found the selection of computers emulated to be interesting. Other than fairly popular (in their time) computers like various VAXen, also machines like the SDS 940 of which only a few dozens were ever made. What the the SDS 940 lacks in numbers it makes up in historical importance though (first node on ARPANET, host of first BBS, host used for the Mother of All Demos etc.).
As cool as this is, I cant see it being the same experience as using a real Royal McBee jukebox style console with built in oscilloscope
https://upload.wikimedia.org/wikipedia/commons/e/e3/LGP-30_G...
I've had a lot of fun installing and running VAX/VMS on a simulated VAX 11/780.
Automatic versioning of files is still a very nice idea. The general format is
FileName.Ext;1
FileName.Ext;2
Etc.Someone on HN must have been browsing similar Tindie listings as I have recently :)
https://www.tindie.com/products/obso/pdp-11-replica-kit-the-...
That's not a recent thing. I've had that replica here for years. I built it during the first lockdown (it only took a day anyway)
I've got their PDP-8 too. Really great kits.
I think the designer was working on a PDP-10 too. But got sidetracked.
The PiDP-10 will be available in the near future. I've also been working with him on the PiDP-1, which will hopefully be available soon as well.
It was recent for me! but fair point :)
Glad to hear the kit is great, helps me make up my mind!
It's great indeed. Extremely well designed, great instructions. Even comes with an alignment bar to make sure all the switches end up straight.
And the frontpanel is truly a work of art. The multilayer printing on the plexiglas in particular, but also the surround.
I soldered it all in a few hours but I'm very experienced. Even if you're new to soldering it'll be fine as long as you follow the instructions and take it slow. Double-check every switch type (there's several different types!) and position before you solder it. Make sure all the LEDs fully hit the board so they point the same way, the switches are aligned etc.
It's really an amazing kit. You can feel the love that went into it.
If there's anything I'd change I'd make it 1:1 scale. And the switches don't really feel like the real thing. I've played with a real PDP-11 and the switches really have that "someone paid 100 grand for this back in the day" feel to them. That satisfying affirmative thump. Which is very hard to replicate with off the shelf components of course.
> In May 2022, the MIT License of SIMH version 4 on GitHub was unilaterally modified by a contributor to make it non-free, by adding a clause that revokes the right to use any subsequent revisions of the software containing their contributions if modifications that "influence the behaviour of the disk access activities" are made.
That seems weirdly specific. Looking at the actual LICENCE.txt file:
> Any use of this codebase that changes the code to influence the behavior of the disk access activities provided by sim_disk.c and scp.c is free to do that as long as anyone doing this is explicitly not licensed to any subsequent changes to any part of the codebase in the master branch of the git repository (https://github.com/simh/simh) made by Mark Pizzolato after the LICENSE.txt was added to the master branch of repository. Changes that qualify for this restriction at least include: changing the behavior or default of SET AUTOSIZE/NOAUTOSIZE, or any code in scp.c and sim_disk.c or any simulator components that use the sim_disk routines.
I'm guessing this Mark Pizzolato made some changes to the implementation of "disk access activities" that he deemed were important but which other people found controversial, and he wanted to make sure they stayed?
It seems Mark Pizzolato was at the time the primary maintainer and recent contributor (by a large margin) (https://groups.io/g/simh/message/1501).
Mark made a change to how the virtual disk system worked that broke an esoteric use case (using dd to image multiple disk images to an SD, without an actual file system). The user didn't want to use a workaround (specifying the transfer size in the dd command), and proceeded to use twitter to get people to harass Mark. (https://www.bentasker.co.uk/posts/blog/the-internet/toxicity...)
Mark got sick of the harrasment and decided to take his toys and go home.
Toxic user prompts toxic reaction by developer.
I'm sure glad I don't work with developers like that, because that complaint makes perfectly reasonable sense to me and I certainly wouldn't consider it "toxic". Expecting a raw disk image file to be the exact size of the virtual device is not at all an "esoteric use case".
Being a prolific contributor doesn't mean you get to force your mistakes on others and cry about it when your decisions come back to bite you. See what Big Tech is doing to us for a great example of what this "feelings-driven design" crap has given us.
Words to live by: "if everyone tells you that you're wrong... maybe you are."
It sounds like there was a config option available to disable the signature addition to the image file ( https://github.com/simh/simh/issues/1059#issuecomment-108689... ). I could see a benefits for having an embedded image signature for preservation and corruption detection issues.
I don't think complaining about the design is toxic, but recruiting uninvolved people on twitter, and harassing out of band certainly is. Also reading the bug thread it seems the person with the issue wasn't the same as the one who instigated the harassment. (https://github.com/simh/simh/issues/1059#issuecomment-108675...)
Enabling it by default could break lots of valuable data over the history of computing. That's why I prefer simh-classic.
That "esoteric usecase" was one reason people opposed that change. There are other concerns as well (you can find them if you read the discussion in the GitHub issue linked elsewhere in the comments).
For example, it made SimH alter disk images by itself, without warning, even if you only wanted to use them in a read-only manner.
There was also concern that sticking metadata right into the data itself was bad from a preservation standpoint.
Also there was the point that such things should be opt-in instead of just appearing ferom one version to another, without warning.
All of these concerns were dismissed as unimportant or flat out ignored by Mark. Then he went full overboard with his license change (which made a free project non-free)
Edit: removed incorrect reference to the GPL
It just resulted in the open and official fork - OpenSIMH[1].
I didn't know this project existed, but that controversy on the license made me curious, and I have had a look at the repository. I stumbled upon this discussion, which shows another controversial decision by the new maintainer regarding the way disk files are managed by the emulator:
He’s not “the new maintainer,” he’s “one maintainer” but he decided he knew better than everyone else. Hence why the official SIMH repository is at open-simh.
He's the overwhelming majority of contributions to the codebase for the last decade.
What he did was toxic, but in fairness, there was out-of-band harassment coordinated towards him for nearly a year.
I'm curious – is the Alpha simulation here as a proof of concept, or are its goals beyond that? I don't imagine a simulation of a complex architecture like this would live well in the same framework hosting, say, a PDP-8 simulation.