New branch: integrate-zimh that integrates a more modern hard fork of SIMH.

[William Cattey]

At VCF East, I reconnected with someone I met at USENIX long ago, that I lost track of.  Turns out he has been busily applying AI to make some ambitious updates to a fork of SIMH (that he calls zimh), including creating a comprehensive self-test suite, eliminating a lot of dead legacy code, and migrating to more recent coding standards.

He expressed interest in taking our Cycle Accurate changes into his fork.

This week I sat down with Claude.ai and performed an integration of zimh.

It builds and runs just fine both on my Mac (without blinking lights) and my PiDP-8i (with a Pi3B).

I'd be grateful if others who have been testing the tangentsoft trunk tried out the branch.

-Bill

[William Cattey]

Note that the zimh branch will require two new packages in order to function, and how to get them has been added to docs on the branch.

On the pi you'll need to do:

sudo apt install libpcre2-dev uuid-dev

-Bill

[Glenn Babecki]

Bill,

I haven't checked the other PiDP forums yet, but do you know if there are plans to offer zimh for other PiDP models?

I suppose that such an effort would be contingent upon the success of the PiDP-8 conversion.

Thanks,

Glenn

--
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 visit https://groups.google.com/d/msgid/pidp-8/08f1af31-9c0e-4776-b83c-95f29cef8ed4n%40googlegroups.com.

[William Cattey]

I have made outreach to Oscar and Lars, explaining how the challenge of getting the pidp8 Cycle Accurate code into upstream SIMH, and the possible value of an updated code base drove my exploration of zimh, and asking them if they were interested in a similar exploration for the PiDP-10.

-Bill

[Glenn Babecki]

Bill,

Thanks for your insights and suggestions to Oscar et. al. regarding wider adoption of zimh.  Of course without knowing all the internal issues associated with SIMH, I hope that "wider adoption" will help future PDP-related development.  From what little I've looked at SIMH, it does seem to need a rethink.

Since the PiDP-1 is not SIMH-based, I guess it's on it's own trajectory.  Much of the work done on the PiDP-1 code base after its introduction might be difficult to port to zimh, if even needed.

Anyway, I'm looking forward to hearing more about zimh applied to PiDP platforms and I'll have to get familiar with it myself.

Best Regards,

Glenn

To view this discussion visit https://groups.google.com/d/msgid/pidp-8/c7cff569-abe2-474b-b94d-ce37ef7fa11fn%40googlegroups.com.

[Bill E]

The pidp-1 implementation doesn't use simh and is in many ways much cleaner. I seem to have taken that project over and I have been using AI tools (Claude) to ferret out bugs and validate code for conformity with the DEC documentation. It has been an eye-opening experience in a positive way. I've also added a lot of new code and a type 30 display I think works much more realistically. My Type 340 implementation has been validated to match the available timing data and uses high speed channels like the real one did, plus supports the full complement of slave displays. Anyway, it is correct that there is nothing at all similar between the pidp-1 implementation and what simh would look like. Aside from the emulator core replicating essentially the hardware schematic in code, my addition of lazy-loaded dynamic IOTs doesn't seem like it would fit the simh model, although I'm no simh expert. I did have to replicate what simh already provides, the type 23 parallel drum, dcs (but vastly improved), type 30, type 33, type 340, the type 62 and 64 line printers and the BBN clock. I'd be happy to consult or help out. My work is in https://github.com/wjenh/pidp1-mods.git and my pidp-8 is also ready and eager.

Bill E

[William Cattey]

I got a reply from Lars, who said, at this time, he is staying focused on an integration with OpenSIMH.

-Bill