Type 340 scaling & point size about simh HOT 47 OPEN

From DECUS 7-13, [PDP-7] 340 DISPLAY PROGRAMMING MANUAL.

from simh.

From H-340 TYPE 340 PRECISION INCREMENTAL CRT DISPLAY.

from simh.

@philbudne pointed out that the point size is larger than the point spacing. I can believe that. Compare the simulated MacHack display with a film frame. Also, note how the top text seems to sit too far to the right.

from simh.

@qu1j0t3, do you have any input?

from simh.

TABLE 3 doesn't seem to be entirely consistent. Especially the distance for 127 points seems off. At point spacing .0091" the computed distances ought to be:

from simh.

The display is documented to be 9 and 3/8 inches. Divided by 1024, that comes to .0091" per point, which is as per the comment to TABLE 3.

This is also roughly consistent with TABLE 3, where difference in distances are between .007 and .010, except for the 127 row.

from simh.

340 DISPLAY PROGRAMMING, page 2.

At scale setting 11₂, each point can be clearly distinguished. At scale setting 00₂, lines and symbols appear to be continuous.

Note that scale and intensity settings are interrelated. For example, if characters are drawn (with the character generator) at the lowest scale setting, and too high an intensity is used, they will be badly blurred. On the other hand, if many characters are to be displayed simultaneously or if the light pen is to be used, it is best to use as high an intensity level as possible.

from simh.

I don't remember anything unusual about scale. I used scale 3 to draw a grid over the bottom 3/4 of the screen, primarily for light pen detects but also to indicate position (this being a CAD program). I don't remember any issues, my code contains nothing odd. Light pen was never all that accurate, at the time I did this (1978) Mouse House was selling mice to the public so I interfaced one of them to behave like the light pen but without the limitations, that of course worked much better. Had the displayed picture been wrong I would have adjusted the software, which I didn't, so I assume the display of scaled vectors was good.

Thinking about the hardware, given the technology available, it would not have been possible to scale at anything other than powers of two, it would require an adder. There must have been analog issues in the beam deflection, scaling did not change timing, spot had to move further in the same time, perhaps that's what Feed Forward Load Resistor is all about in table 3-2? Maybe somebody had defective hardware? But that wouldn't be a cumulative change, the digital portion could not be off.

Table 3 is very suspicious to me. It covers line length with a vector of length 1, a little odd since a vector of length 1 has only 1 point (340 does not display the first point of any vector).

The 340 disagnostics I used, and converted to a TOPS-10 user mode program, appears to fully test scale mode. I don't rememer it's display ever being off.

I really should configure the 340 on my simulator and try this stuff.

from simh.

Thank you, that's very good information.

Yes, table 3 is a bit weird. Consider the remark "This applies to increment mode if the previous point is intensified". If you take that to mean there already is a .03" point (number 0 if you will), and all additional points add .0091" times scaling, then it mostly makes sense. Except the bottom line!

from simh.

Hello @rmaldersoniii,

Do you have any experience with the Type 340 at the museum, or elsewhere?

from simh.

More MacHack footage:
https://www.csail.mit.edu/node/6632

from simh.

Mathlab: https://www.csail.mit.edu/node/6621

Portions of the 340 character set it visible. Unfortunately nothing lower case.

Also brief MacHack appearances.

from simh.

According to William Ninke, about 200 inches of line drawing or 1,000 characters could be displayed flicker free at 30 frames per second

http://www.cadhistory.net/04%20The%20Second%20Half%20of%20the%201960s.pdf

200 inches should be 21845 points.

from simh.

from simh.

Is this the hardware that was used to run Space Travel on the PDP-7?

from simh.

Regarding point size, I unceremoniously hacked point() in type340.c to add eight more points around the specified coordinates. I think this results in a considerably more vivid display, and maybe closer to the screenshots we have.

I tried to reduce the intensity of the added points, but it seems the dynamic range of intensities offerend by display.c isn't large enough. Even the dimmest intensity is quite bright.

I envision a GLSL implementation where maybe there's a floating point buffer for each phosphor, modeling the energy of display areas. Then a separate pass would render this to the screen.

from simh.

Screenshot from https://www.masswerk.at/spacewar/:

from simh.

from simh.

Stan Kugell writes about 340D, the Datapoint terminal emulator:

Also the slow refresh rate of the 340 had to be considered. Using full width and height, full of text, the refresh rate was painfully slow. Better than using TECO on a TTY, but not optimal either. There are some things it would be difficult to simulate - color for example. The display’s phosphor had a bluish tiny when painted with the electron beam, and a long yellow-green decay. When full of text, the sweep of the beam painting letters from top to bottom, the color and intensity gradient behind the beam, was very noticeable.

I tested this right now, making a screen full of 66x35 characters. The current version of the 340 simulation doesn't suffer noticeably.

from simh.

from simh.

Yes, maybe the CPU is too fast. Another possibility is that the ratio between the 340 update rate and the CPU speed is off.

I think SIMH has some kind of CPU throttling, but I have never tried it. @rcornwell, does your KA10 simulator support this?

from simh.

Another thing I noticed is that the display looks mostly white when static. According to Kugell, and also the JavaScript screenshot, maybe it should look more blue.

from simh.

Yes, CPU throttle works. Idle detection also works. Any AOJx . SOJx . in a register is considered an idle loop.

from simh.

Another piece of information. When you open the DIS: device, it computes the display size in characters based on the scale factor:

        LDB TT,[40200,,CSCALE]
        MOVNS TT
        MOVEI T,170.
        LSH T,(TT)
        TRZ T,7
        MOVEM T,DISCHS  ;CHARS THAT WILL FIT THIS SIZE
        MOVEI T,88.
        LSH T,(TT)
        MOVEM T,DISLNL  ;LINES THAT WILL FIT

It looks to me at scale factor 1 the display is 170x88 characters! 170 is way more than 1024/7.

from simh.

Would it be possible that the MIT 340 was modified to have characters 6 points apart horizontally?

from simh.

from simh.

I think you've swapped horizontal and vertical, and forgotten about spacing

No, I really mean horizontal. But I worded it badly.

The PDP-7 340 manual says "Space (40₈) moves the beginning location 7 units to the right", and "after each character is drawn, the beginning location is moved 2 units past the lower right corner to correctly space the next character". So the available documentation clearly says the character grid is 7 points horizontally, and your simulation faithfully implements this.

However, ITS says there should be 170 characters horizontally. This works out to 6 points per character.

from simh.

This would explain anomalies in MacHack and PEEK.

from simh.

PEEK computes this value from the light pen coordinates. I think this means the character cell size is 12x18. Since scale factor 2 is used, this would be 6x9 at scale 1.

(x-12)/(12*8)+6*((960-y)/18-1)

from simh.

According to William Ninke, about 200 inches of line drawing or 1,000 characters could be displayed flicker free at 30 frames per second

200 inches should be 21845 points.

21845 × 1.5 𝜇s is 0.032, so that seems to work out.

I also get 33 𝜇s per character.

from simh.

from simh.

As I understood the 340 hardware, vectors are plotted at 1.5 uS per point, no matter what. So if you have a scale of 8, you cover 8 times the distance in the same interval. Points were not dimmed though I never paid attention to see if they were stretched a bit (from beam not being fully settled). Wasn't a problem in my setup (scaled vectors used to draw a grid).

from simh.

Interesting, but seems anectotal-ish.... ISTR some manuals specified times for command execution movement and settle time.

Agreed, it's not the most reliable information. But it so happens to agree with the manuals.

The available manuals agree on this:

from simh.

So if you have a scale of 8, you cover 8 times the distance in the same interval.

Does the scaling apply to vector mode, i.e. are the points spaced further apart? The current simulation draws a solid line regardless of the scale. (The length of the vector is scaled of course.)

from simh.

Yes vector scaling places the points further apart, it does not affect the number of points plotted, only the spacing.

from simh.

Drawing a continuous line would have been impractical in a device built from discrete transistors. The two rate multipliers (BRM) would have to be lengthened from 7 bits to 10 bits. If that were done there would be a strong temptation to lengthen the vectors from 7 to 10 bits since all the hardware would have been present to plot the longer vectors.

from simh.

Reducing the character spacing seems to solve all points raised in the first comment above. I think the position of the text in this simulator screenshot matches the film frame.

from simh.

from simh.

from simh.

Some of us might take that as a challenge…

from simh.

The 340 vector drawing cycle is 1uS for moving to the next point with the beam off, than a stable 0.5uS with the beam on for drawing the point. So hopefully the beam is never moving while it's on. There are no jaggies because the spot size is bigger than the point size otherwise you'd see the entire display was made up of points.

from simh.

I think this is text on a real 340 display. (Except the comma doesn't look like the simulated one.) Compared against simulation.

I think the photo supports the narrower character spacing. This simulator screen shot has not been updated with this.

from simh.

Source: https://archive.org/details/AIfilms/104-mac.mp4

from simh.

I got this from https://archive.org/details/AIfilms/75-logo.mp4 I believe this is text on the 340 display. There's not much to go on, but at least the upper case characters match the documentation and the comma matches the screenshot above.

So here is a sample of lower case text. We have a, b, d, e, g, h, i, k, l, n, o, r, t, u, w, y. Missing: c, f, j, m, p, q, s, v, x, z.

from simh.

From AI memo 276:

                Mg X intensity from OSO-VI
                  August 1969 - May 1970

                  Solar Satellite Project
                Harvard College Observatory
            Supported by NASA through contracts
            NAS 5-9274 and grant NGR 22-007-211.

        Artificial Intelligence Laboratory, M.I.T.
   Supported in part by ARPA of DoD and monitored by ONR
       under Contract Number N000 14-70-A-0362-0003.

   Solar Satellite Project      Dr. Edmond Reeves
           Mg X experiment      Dr. George Withbroe
astronomy data programmers      Judy Smith and Pat Thomas
            cinematography      Michael Beeler

                           1972

from simh.

ITS source code. Given the date of the film, this may be PDP-6 ITS. But more importantly in this context, we see a down arrow. I can't quite see the characters after it.

from simh.

I think it's "↓₁₄" to indicate a FF character.

from simh.