A proper source code repository

[Warren Young]

I've stood up a Fossil repository of a modified version of the PiDP-8/I software here:

    https://tangentsoft.com/pidp8i/

Details about how to use it are linked from the page that link takes you to, as well as details of what "modified" means.

This repository need only serve my own purposes, but if others would like to join me there to collaborate on improvements to the software, I welcome contributors. Alternately, if Oscar Vermuelen would like to take this over, that's fine, too. I don't intend to fork the developer community, only to provide an apparently missing resource.

There are many things I'd like to see done to the software, which make having a public source code repository helpful. They're all listed in the ticket tracker:

    https://tangentsoft.com/pidp8i/rptview?rn=3

Incidentally, you will notice that the Fossil repository doesn't have any of the multiple redundant copies of the binary media images. There's no point when it's all source-controlled. Just "fossil revert" and you're back to the stock version. See also ticket [6b3bba].

[Obsolescence]

Warren,

On Monday, November 21, 2016 at 3:57:10 PM UTC+1, Warren Young wrote:

This repository need only serve my own purposes, but if others would like to join me there to collaborate on improvements to the software, I welcome contributors. Alternately, if Oscar Vermuelen would like to take this over, that's fine, too. I don't intend to fork the developer community, only to provide an apparently missing resource.

No, I think this is a very good idea! I'll post to that as well when I've got improvements to contribute. The problem is that I've had very little time the last few months so I'm glad someone takes the initative. Like Ian with his glowing lights improvement.

Let's make this the Official PiDP repository, if that is OK for you and others? Insofar as anything needs to be Official, but you what I mean - the reference one.

 

There are many things I'd like to see done to the software, which make having a public source code repository helpful. They're all listed in the ticket tracker:

    https://tangentsoft.com/pidp8i/rptview?rn=3

Oh, I want to add to the list ;)

- small hack to hook up an Arduino to the circuit board and make it serve as a LAB-8 laboratory instrument.

- improved spacewar scope emulator and new binary (on its way, the only thing I had time for the last weeks) that is proper plug and play.

- further improve spacewar by emulating the original hardware for its interface (will speed things up on Pi 2's and lower)

- small script that sets up the dual USB-serial terminal (where you cross-connect two USB-serial cables obviating the need for the Serial Mod).

- update the stock OS/8 disk image with the Vista fullscreen editor and other useful software (and fix the Fortran bug)

-----

No PDP-8 is ever finished.

Kind regards,

Oscar.

[Obsolescence]

Warren,

A question on your potential to-do projects:

#1 is to replace the front panel logic with the simH front panel API. I would not do that - it adds a lot of layers of indirection, whilst at the moment the front panels is handled within the CPU logic at the lowest level. It's probably much faster and more direct this way. Although, not portable to any other hardware setup.

Stuff that I would love to add is external peripherals ($2 Arduinos with whatever sensors you'd think of) that are programmed with instructions compatible with the LAB-8 and other original peripherals. Such things are not especially hard to do and would give people a reason to do some real coding on the PDP-8. I guess that's a poll for ideas. My first one would be an AD/DA peripheral. You could use that to hook up an oscilloscope as graphics screen (spacewar, clock, the old kaleidoscope from the manuals)...

Kind regards,

Oscar.

[Ian Schofield]

Dear Warren,

 Excellent, and I agree with Oscar to keep a separate repository for all of the Pi stuff as the PDP11 software will be joining this at some stage and the changes are such that these are significant forks of the Simh master repository. I wonder if we also need a 'request for changes' section as well and these are appearing all over the group threads and this is quite difficult to manage. Any thoughts all?

Regards, Ian.

[Roger Smith]

I would second NOT using the simh API for the front panel, it's unnecessary complication for code intended to run under raspbian.
Also, if you mmap() /dev/gpiomem instead of /dev/mem then you don't need sudo access.

[Warren Young]

On Monday, November 21, 2016 at 11:21:19 AM UTC-7, Obsolescence wrote:

#1 is to replace the front panel logic with the simH front panel API.

Not, "replace," port. That is, take the upstream SimH code version contemporaneous with the prior development effort (i.e. circa December 2015), do a diff, then move those diffs into the front panel API framework, changing as little code as possible.

Do you happen to know the approximate date of the SimH code Mike Barnes made his changes against? That will help in extracting the diffs from the base SimH code.

 

I would not do that - it adds a lot of layers of indirection, whilst at the moment the front panels is handled within the CPU logic at the lowest level. It's probably much faster and more direct this way.

Undoubtedly the current method is faster. The question is, how fast does the PiDP-8/I simulator need to be in order to meet its performance goals?

An RPi 3 is about 5,000 times faster than a real PDP-8/I on a pure MIPS basis. Currently, the budget for updating the UI comes out of that budget, meaning that the modified SimH binary can do 5,000 times more work than a real PDP and still meet its performance goals.

Under the front panel API scheme, much of that budget gets shuffled out of the simulator into async I/O. That is, while the front panel app is sitting there doing sleeps and other essentially unproductive stuff, the unmodified simh will be running in the background asynchronously, servicing the CPU and internal I/O (disks, terminals, etc.) update loops.

Not that this is an important concern, since the simulator is already fast enough. The point is that IPC latency will be swamped by incandescent lamp simulation latencies and such. As long as the front panel simulator app completes each iteration within the human PoV limit (~100 Hz) it's fast enough.

The benefit we get for this is that we can upgrade to the latest SimH code at any time, without disturbing the PiDP/8 panel interfacing code.

 

Stuff that I would love to add is external peripherals ($2 Arduinos with whatever sensors you'd think of) that are programmed with instructions compatible with the LAB-8 and other original peripherals.

Isn't a LAB-8 a PDP-8/e with A/D and such hardwired into the backplane? How would an external Arduino simulate that? 

The PiDP-8/i has run the Pi out of GPIO by this point, so do you plug the Arduino into the Pi via USB, so that the Arduino appears to be another terminal to SimH? That's do-able: a stream of 10-bit samples encoded in a fairly sloppy hex ASCII encoding at 60 Hz is still only 4,800 bps. A tight binary encoding could get it down to about half that, if needed. The question, though, is how realistic would that be, with respect to a LAB-8?

Or are you suggesting more mods to SimH to make it simulate this hard-wired peripheral by talking to an Arduino over serial? If so, any future changes of this sort should be confined to external modules, so that the only mods to the core of SimH are function calls into those modules. The patch relative to the stock version of SimH should be made as small as possible.

 

You could use that to hook up an oscilloscope as graphics screen

Reworking the current VC8-E support to directly drive an X-Y oscilloscope would be neat. I have a suitable Tektronix scope here.

[Warren Young]

On Monday, November 21, 2016 at 11:30:11 AM UTC-7, Ian Schofield wrote:

 Excellent, and I agree with Oscar to keep a separate repository for all of the Pi stuff as the PDP11 software will be joining this at some stage

I'm not sure which direction you're requesting. Are you suggesting that my new repo should be prepared to host the PDP-11 code as well?

Unless the two projects will share a lot of code, I'd think separate repos would work better.

I wonder if we also need a 'request for changes' section as well and these are appearing all over the group threads and this is quite difficult to manage. Any thoughts all?

Someone just needs to farm the list for ideas, and formalize them as tickets on the new Fossil repo.

At the moment, I've managed to blow away all of the tickets, and the best backup isn't immediately at hand. (Local pilot error.) Once I've repaired that, I'd be happy to give someone repo access to begin this process. Or, point me to the useful idea posts, and I'll do it, after I recover the prior set of ticket.

[Warren Young]

On Monday, November 21, 2016 at 12:04:14 PM UTC-7, Roger Smith wrote:

I would second NOT using the simh API for the front panel, it's unnecessary complication for code intended to run under raspbian.

How constrained do you think these Pis are? We'd have called them supercomputers, once upon a time. 

 

Also, if you mmap() /dev/gpiomem instead of /dev/mem then you don't need sudo access.

Thanks.  That's worth adding to the list, and well within my abilities.

[Ian Schofield]

Dear All,

 The updated release on Warren's site (Schofield) uses /dev/gpiomem exactly as you suggest but still requires creds to run a high priority thread. However, the final app runs with userland creds rather than needing 'sudo'.

Regards, Ian.

On Monday, November 21, 2016 at 2:57:10 PM UTC, Warren Young wrote:

[Obsolescence]

Warren,

There's one other information snippet regarding the simh FP API and its alternatives:

which is that Joerg Hoppe - of BlinkenBone fame - made a version of his Blinkenbone simh variant for the PiDP-8. He also did not use the simh FP API. So you can already run the PiDP-8 hardware with his Blinkenbone server. Does not eliminate the usefulness of what you have in mind, but good to know.

On Monday, November 21, 2016 at 9:22:55 PM UTC+1, Warren Young wrote:

 

Stuff that I would love to add is external peripherals ($2 Arduinos with whatever sensors you'd think of) that are programmed with instructions compatible with the LAB-8 and other original peripherals.

Isn't a LAB-8 a PDP-8/e with A/D and such hardwired into the backplane? How would an external Arduino simulate that? 

You'd add support for its instruction set in the PDP8_cpu.c - in other words, add a few instructions and implement what these instructions do into code for the Arduino and Pi. They are fairly basic I/O tasks, so it will not be too hard. And a pretty nice exercise in messing with the PDP-8 instruction set based on the old documentation.

Or are you suggesting more mods to SimH to make it simulate this hard-wired peripheral by talking to an Arduino over serial?

Exactly.

 

If so, any future changes of this sort should be confined to external modules, so that the only mods to the core of SimH are function calls into those modules. The patch relative to the stock version of SimH should be made as small as possible.

 

You could use that to hook up an oscilloscope as graphics screen

Reworking the current VC8-E support to directly drive an X-Y oscilloscope would be neat. I have a suitable Tektronix scope here.

It would be satisfying to use that scope - a great combination: a Tek with a PiDP underneath. :)

Kind regards,

Oscar.

 

[Obsolescence]

Warren, Ian,

For the PiDP-11, the code will reside (actually, resides already) in the Blinkenbone repository of Joerg Hoppe. Because the PiDP-11 is a Blinkenbone device, just as his beautiful touch screen simulations and his real PDP front panels. They all run on the same Blinkenbone simh version.

Truth be told, with the PiDP-8 I already felt guilty riding on the genius of the simh team's work. With the PiDP-11, Joerg did most of the remaining heavy lifting. All I need to do is make that plastic case...

Kind regards,

Oscar.

[Warren Young]

On Monday, November 21, 2016 at 1:27:35 PM UTC-7, Warren Young wrote:

On Monday, November 21, 2016 at 11:30:11 AM UTC-7, Ian Schofield wrote:

I've managed to blow away all of the tickets, and the best backup isn't immediately at hand.

I've rebuilt the prior tickets, and added more to include the other items recently discussed here.

Applications for project membership are being accepted via my email. :)

(Application process: give a good reason you should have access. Okayfine? Okayfine.)