More dpy instruction issues

[Bill E]

Some posts back, I found that using i/o wait for completion on the display, dpy instead of dpy -i, followed by an ioh (0720000) never completed, just hung. The discussion at that time indicated that it shouldn't work. However, the pong sources indicated it should.

Well, it turns out that it DOES work in the simh implementation, so I now have to conclude that the pidp-1 implementation isn't correct. In simh, using wait-for-completion delays 50 usec then sets complete, which is what it seems the original hardware did.

I would normally think that aap would address this, but it seems that both Igor and aap have abandoned this project. Shades of all the predecessors. :)

Given that the fix would not affect the current dpy-i behavior, I'll put this on my bugfix list and get to it eventually. Then pong would work as the source code is written.

Oh, there was mention in the lunar lander thread about a 'reorigin' mode for the Type 30, and I've seen mention of that elsewhere, but as with a number of PDP-1 things, I can't find anywhere that it was actually implemented, and simh doesn't do so. So, that one should probably remain unimplemented.

Bill

[Bill E]

BTW, Angelo, welcome back. I was sure you had disappeared forever. :)

Bill

[MICHAEL GARDI]

Hey Bill,

Oh, there was mention in the lunar lander thread about a 'reorigin' mode for the Type 30, and I've seen mention of that elsewhere, but as with a number of PDP-1 things, I can't find anywhere that it was actually implemented, and simh doesn't do so. So, that one should probably remain unimplemented.

Actually Bill setting the origin to the lower left hand corner is used in the venerable Snowflake program. Check out Norbert Landsteiner's Snowflake Archeology article (near the bottom) where he shows that dpy 3000 is used if sense switch 2 is enabled. 

The dpy instruction (73cb07) causes one point to be displayed on the scope. (...) The three "b" bits control the brightness -- 4 is visible to photomultiplier tubes only, 7 is barely visible in a dark room, 0 is normal, and 3 is brightest. The "c" bits control the centering. 0 makes the origin in the center of the scope. 1 puts it at a the center of the bottom edge. 2 makes the origin be half way up the left edge, while 3 puts it at the lower left corner.

So, if c = 3, as in “dpy+3000”, the origin will be located at the lower left corner. What does this mean for our 8-dots display? Effectively, we’re plotting from the outside inwards, instead of inside-out, and the graph will “grow” from the corners:

This can be seen clearly if you run the online Snowflake Demo using the Options menu to enable sense switch 2 (Draw Outside-In) and compare it to Snowflake running on the PiDP-1 with sense switch 2 set on.

I have added a request to the pidp1 Github to have this feature implemented. I would certainly have used it in Lunar Lander had it been available to me.

--
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/5cde43d3-70c1-4dd0-a1ec-bc5e5d32adaan%40googlegroups.com.

[Bill E]

Cool. It would be very easy to implement, I might play with it, let Angelo take care of it officially (if he wants).

Bill

[Angelo Papenhoff/aap]

Hm, I find the IO completion logic very confusing but i think my emulator is right: dpy-i is 720007, which does not need a completion pulse, so if you're waiting for one with iot i, there's none coming and you're stuck. what you're looking for is the asynchronous dpy that does expect a completion pulse, which is dpy-i+4000.

[Bill E]

I don't remember exactly what pong was doing, but yes, a dpy i followed by an ioh would definitely hang forever (or until some other pending IOT raised completion). I need to go back and look at the pong code. It would hang on dpy using the distributed source, but not using the rim, so clearly there was some code difference. What I don't remember is if it was doing dpy i or just dpy.

Bill

[Bill E]

Uh, dpy-i followed by an ioh. Sigh, I'm losing it.

BTW, dpy, which in macro is equivalent to dpy i, just to confuse everyone, in conjunction with ioh does work.

The pong problem is that it does a dpy-i, ioh. From what's been discussed, this could never have worked.

Bill

[Kevin McGrath]

So wait, dpy automatically gets turned into dpy-i in macro, so does “dpy i” turn into “dpy-i i” then?  Would that be wait, or don’t wait?

[Bill E]

I guess I wasn't clear. Macro automatically converts dpy to dpy i, 730007. So, you will see in a lot of code 'dpy-i', which subtracts the value of i, 10000, resulting in an actual dpy instruction, 720007.

Bill