PDP2011 release

[Sytse van Slooten]

Hi all,

I've just put a new release of the PDP2011 on my website. Get it here: https://pdp2011.sytse.net/wordpress/download/

The major news is that it now includes support for enc28j60 - a cheaper and better available alternative for the enc424j600 as found on the out-of-production PMODNIC100. 

Next to that PDP2011 now also includes a fully working GPIB interface for the MINC setups - a contribution of list member Jan Secker. You can now interface your old lab equipment like it's 19- something, using the original MINC Basic!

And lots of other things - I've added a post about it https://pdp2011.sytse.net/wordpress/new-release/ 

It's not like the usual software updates - there's no urgency to update unless you need what the new version can do, and there are no real changes to the workings of the hardware elements in the project. But if you're starting out, I definitely recommend the new version.

Cheers,

Sytse 

[Glenn Babecki]

Sytse,

Thanks for the heads up on the new PDP2011 release.

This brings to mind some questions I've been meaning to ask for some time regarding pros and cons of going with your FPGA implementation versus the SIMH implementation.  More specifically I'm thinking about the ability to add available (or develop new) other peripheral device simulations such as a DECtape or different display (e.g., VT11, TEK 4010, etc.).  I'm sure the existing disk, terminal, and ethernet controllers are more than adequate to preoccupy one for quite a while, but just thinking about the difference in expandability when considering the FPGA vs. SIMH implementations.

Just wondering...

Thanks,

Glenn

--
You received this message because you are subscribed to the Google Groups "[PiDP-11]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pidp-11+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CF01A54D-9FD4-4550-A3E7-9EAA551D810E%40sytse.net.

[Sytse van Slooten]

Hi Glenn

I think the only answer to a question like that is 'it depends'.

For instance, if what you're going to add has a direct reflection in hardware - this is the reason I never added a tape drive, since that maps poorly to current technology (and I don't have room for a real drive). But the abstraction to disk files works very well for simh. In the other direction, any amount of blinkenlights is kinderspiel for an fpga, but awkward in software - and I don't even mean the challenges with the PiDP software.

VT11 would be a nice thing to add for the fpga. But simh already has it, so that kind of disproves the point.

A question I get somewhat often is if it would be possible to interface the PDP2011 to 'real' hardware. I think in most cases it's easier (by a lot) and more worthwhile to instead include the hardware function into PDP2011 - sort of like I'm doing with the MINC. Or else try to find peace with that it'd be nice, but too much work (like with tape drives :-)

Hope that answers your question, if not let me know 

Cheers

Sytse

To view this discussion visit https://groups.google.com/d/msgid/pidp-11/CAL1sX6n-n3yst6%2BndibNKKh7zrNn8JPwwN02Hzw5k0-F5KMFiQ%40mail.gmail.com.

[Glenn Babecki]

Hi Sytse,

Sorry for the delayed acknowledgement of your response to my questions; all kinds of crap hit at once.

I realize after sending my somewhat vague FPGA-versus-SIMH question that I let myself open for your 'it depends' response.  The issues surrounding adding a real device versus a simulated device clearly drive which platform is more suited to the peripheral device interface.  I guess that exposed the dilemma in my head regarding having the flexibility of adding a real or pseudo-real device, while also having the ability to add a simulated device.  Clearly the more sophisticated real devices from the PDP era are either hard to find, expensive, take up a lot of space...oh, and did I say they are hard to find and are expensive if you can find a working device.

I understand that it is relatively easy to create an abstraction for the simulated device for devices such as disk drives and terminals, as has been demonstrated in SIMH.  However, adding some devices to SIMH can be painful due to the lack of (clear) documentation for SIMH development and the lack of thorough comments in existing software.  I'm experiencing the trauma associated with trying to add yet another display type to SIMH, but fortunately I have some help from Lars Brinkhoff trying to adapt some of his designs.  This current experience, in part, gave rise to the questions related to the flexibility of adding devices via the FPGA hardware approach.  (BTW, I have to totally steal the expression "kinderspiel.")  Perhaps the reality of the simulated processor options is that there are not too many general peripherals that one needs to add; I'm just thinking of some experimental devices.

I suppose another consideration for the FPGA versus SIMH implementation is that there has been a lot of latent bug fixing going on with the SIMH PDP-8 and PDP-11, particularly related to the PiDP front panel interface and, to some extent, the pursuit of cycle-accurate operation.  This seems to have mired the availability of getting a stable SIMH implementation for the PiDP family of packaging.  Not that there are not always bugs, but the FPGA implementations available for Will Folke's PDP-8 and your PDP-11 seem more stable.  I don't know; more pondering is required on my part.

BTW, something occurred to me the other day regarding the issue of the PDP2011 FPGA implementation needing SRAM.  I know there are still some viable FPGA boards available with sufficient SRAM, but I was wondering if adding some PSRAM to a SDRAM-based FPGA board might be a way of relaxing the available board constraints.  Of course I say this without looking at what's involved in adding PSRAM to an FPGA implementation, but I thought I would ask in the event there are obvious reasons for this approach being a non-started.

As usual, thanks for your thoughts.

Regards,

Glenn

[Sytse van Slooten]

Hi Glenn

On 18 Sep 2025, at 22:03, Glenn Babecki <glenn....@gmail.com> wrote:

Hi Sytse,

Sorry for the delayed acknowledgement of your response to my questions; all kinds of crap hit at once.

I realize after sending my somewhat vague FPGA-versus-SIMH question that I let myself open for your 'it depends' response.  The issues surrounding adding a real device versus a simulated device clearly drive which platform is more suited to the peripheral device interface.  I guess that exposed the dilemma in my head regarding having the flexibility of adding a real or pseudo-real device, while also having the ability to add a simulated device.  Clearly the more sophisticated real devices from the PDP era are either hard to find, expensive, take up a lot of space...oh, and did I say they are hard to find and are expensive if you can find a working device.

One of the things I really like about the fpga is that you can have one running 24/7 without worrying about the power bill, noise or heat. Same for simh, really - although that depends a lot on what you run it on of course.

I understand that it is relatively easy to create an abstraction for the simulated device for devices such as disk drives and terminals, as has been demonstrated in SIMH.  However, adding some devices to SIMH can be painful due to the lack of (clear) documentation for SIMH development and the lack of thorough comments in existing software.  I'm experiencing the trauma associated with trying to add yet another display type to SIMH, but fortunately I have some help from Lars Brinkhoff trying to adapt some of his designs.  This current experience, in part, gave rise to the questions related to the flexibility of adding devices via the FPGA hardware approach.  (BTW, I have to totally steal the expression "kinderspiel.")  Perhaps the reality of the simulated processor options is that there are not too many general peripherals that one needs to add; I'm just thinking of some experimental devices.

What I was thinking of, for me it's very easy to add a new peripheral to pdp2011 - because I've done it many times, it's mostly cut and paste and little actual creating other than what makes the peripheral. But I expect the simh maintainers would be able to say the same. I'm not sure there's a very big difference there that really depends on the technology itself - and certainly I don't think my documentation is better than simh's :-)

Adding another display type might be easier to do in my framework than in simh - provided that the display maps reasonably to current hardware (as in, the actual screen). Kind of like the vt100/105 I now have. The vt11 is still on my list of things that I eventually want to try adding...

4010 probably a bit more difficult with its storage tube. I used to work on one of those things back in the day, there was so much screen space you could use compared to regular terminals... but always a pain when the time for clearing came. All that space would require a lot of fpga resources to make work probably. 

I suppose another consideration for the FPGA versus SIMH implementation is that there has been a lot of latent bug fixing going on with the SIMH PDP-8 and PDP-11, particularly related to the PiDP front panel interface and, to some extent, the pursuit of cycle-accurate operation.  This seems to have mired the availability of getting a stable SIMH implementation for the PiDP family of packaging.  Not that there are not always bugs, but the FPGA implementations available for Will Folke's PDP-8 and your PDP-11 seem more stable.  I don't know; more pondering is required on my part.

In and of itself, the stack of dependencies is a lot smaller for me - there's the risk of getting into vendor dependencies or versioning of the hardware languages, but so far I've managed to avoid those. So yeah, I think I would agree to that.

BTW, something occurred to me the other day regarding the issue of the PDP2011 FPGA implementation needing SRAM. 

That's not entirely correct. There's a driver for both SRAM and SDRAM, and you can also use fpga-internal memories.

I know there are still some viable FPGA boards available with sufficient SRAM, but I was wondering if adding some PSRAM to a SDRAM-based FPGA board might be a way of relaxing the available board constraints.  Of course I say this without looking at what's involved in adding PSRAM to an FPGA implementation, but I thought I would ask in the event there are obvious reasons for this approach being a non-started.

Are there any new and interesting boards with incompatible memory types that I've managed to overlook? One example that I'm aware of are the SoC based boards like the one MiSTer runs on - and they've fixed that in a very simple way. Not sure why they did really, because there are plenty of boards that have SDRAM fpga-side already on the board... 

What I don't currently support is stuff like DDR and derivatives. But it's not impossible to make that work, and maybe not even that much. It's not been anywhere near the top of the things to do list though - mainly because there are plenty of reasonably priced boards that just have (the right kind of) SDRAM.

As usual, thanks for your thoughts.

Hope that answers your questions!

Cheers

Sytse

[Glenn Babecki]

Thanks for your insights and things to consider regarding my line of questioning.

Best Regards,

Glenn