Type 340 scaling & point size

[larsbrinkhoff]

Something seems off with the Type 340 scaling. When the scale register is set to 01, the simulator uses scale factor 2. However some ITS software seem to disagree with this:

1. TCTYP expects the display to be 80 characters wide. Characters are spaced 7 units apart. 1024/7 is 146, or assuming scale factor 2, 1024/14 is 73.

2. PEEK mode "D" displays a disk directory and the user can point the light pen to enter a directory. The clicked location in the simulator window doesn't correspond to the right directory.

3. In MacHack VI, "WHITE TO MOVE" goes off the right edge. And the board lines are slightly wrong.

Documentation available here:
http://bitsavers.org/pdf/dec/graphics/

[larsbrinkhoff]

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

[larsbrinkhoff]

From H-340 TYPE 340 PRECISION INCREMENTAL CRT DISPLAY.

[larsbrinkhoff]

@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.

[larsbrinkhoff]

@qu1j0t3, do you have any input?

[larsbrinkhoff]

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:

Number of points	Documented	Computed
1	.04	.04
2	.05	.04 + 1×.0091 ≈ .049
4	.06	.04 + 3×.0091 ≈ .067
8	.09	.10
16	.17	.18
32	.31	.32
64	.60	.61
127	1.32	1.19

[larsbrinkhoff]

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.

[larsbrinkhoff]

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.

[psubjj3]

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.

[larsbrinkhoff]

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!

[larsbrinkhoff]

Hello @rmaldersoniii,

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

[larsbrinkhoff]

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

[larsbrinkhoff]

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

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

Also brief MacHack appearances.

[larsbrinkhoff]

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.

[philbudne]

Thanks for posting that link! I'd never read anything about GRAPHIC 1, and further confirms my suspicion that the reason the PDP-7 Kernighan & Ritchie used to create UNIX was a cast-off is that it was a prototype for GRAPHIC 2. I added simulation of (just) enough of the G2 hardware to make it possible to simulate the glass TTY support in PDP-7 UNIX so that you can telnet into SIMH and get a "second seat"

The (expensive) high-speed drum that UNIX(-7) depends on was (prior to the discovery of the UNIX sources as a PDP-9 era device. The same drumb was also used as a swapping device on (larger) PDP-10 systems.

The high speed DMA I/O of the drum made it possible to do timesharing despite the small memory and lack of memory management. UNIX sqandered half of the drum storage as a backup image (and caused initial confusion in identifying the hardware because the UNIX system was only using half of the available space)!

[larsbrinkhoff]

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

[larsbrinkhoff]

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.

[larsbrinkhoff]

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

[philbudne]

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

Yes, the UNIX PDP-7 had a GRAPHIC 2 display

[larsbrinkhoff]

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.

[philbudne]

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

Then something is wrong with the simulation!

Maybe the CPU is running too fast?

The PDP-6 interface is basicly programmed I/O (two 18-bit instructions passed in each DATAO)

FIrst thought maybe ka10_dpy.c needs to do an actual sleep to bring the instruction rate down (when writing to the display)?

Or does SimH have a general mechanism for bringing the instruction rate down to actual hardware speed??

phil

[larsbrinkhoff]

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?

[larsbrinkhoff]

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.

[rcornwell]

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

[larsbrinkhoff]

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.

[larsbrinkhoff]

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

[philbudne]

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

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

If characters are 5 points wide and 7 points high with one point spacing above and below:

1024/6 = 170.666 characters per line, 1024/8 = 128.0 lines

Other possible line spacings: 2 points between lines 1024/9 = 113.777 3 points between lines 1024/10 = 102.4 4 points between lines 1024/11 = 93.09

I suppose that allows the possibility that lower case could have offset the 5x7 raster below the base line, and I imagine it would have been trivial to add a positioning voltage offset if a bit was lit!

OR it may have just been that the display flicker got bad if you tried to put too many characters on the screen.

Regarding flicker: Another way the simulation is not accurate is that it doesn't account for positioning times between points. I'm not sure if that's anywhere as significant as the number of interrupts/instructions needed to be executed to keep the display painted.

[larsbrinkhoff]

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.

[larsbrinkhoff]

This would explain anomalies in MacHack and PEEK.

[larsbrinkhoff]

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)

[larsbrinkhoff]

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.

[philbudne]

Interesting, but seems anectotal-ish.... ISTR some manuals specified times for command execution movement and settle time. The display hardware isn't thinking in "points": I doubt increasing the scale factor slows down drawing (tho I wonder if it dims it).

One strategy (other than slowing down the CPU, which will ONLY simulate an upper bound on the refresh rate) would be to have the 340 simulator indicate how much real time would be taken to execute a command, and have ka10_dpy.c not process the next command (or request a data interrupt for two more commands) until that time has elapsed.

I don't know offhand if the display aging device callback interval is ANYWHERE near the per-command execution time. It looks like the vt11 simulation executes one command, then calls display aging.

[psubjj3]

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).

[larsbrinkhoff]

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:

Operation	Time
Data transfer	3 µs
Random positioning	35 µs
Incremental positioning	1.5 µs
Character	1.5 µs per point, 35 µs on average
Intensification	0.5 µs

[larsbrinkhoff]

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.)

[psubjj3]

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

[psubjj3]

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.

[larsbrinkhoff]

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.

[philbudne]

It's a vector, so (I assumed) it is drawn with the electron beam on. Saying that it hits intervening "points" isn't quite right, since the line is going to be continuous, and wouldn't have ANY "jaggies" in it.....

p

[philbudne]

Drawing a continuous line would have been impractical in a device built from discrete transistors.

Or maybe I'm wrong!

[qu1j0t3]

Some of us might take that as a challenge…

[psubjj3]

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.

[larsbrinkhoff]

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.

[larsbrinkhoff]

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

[larsbrinkhoff]

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.

[larsbrinkhoff]

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

[larsbrinkhoff]

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.

[larsbrinkhoff]

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