Type 33 symbol generator timing question

[Bill E]

Hope someone knows, not having luck finding real documentation.

The various manuals say it can draw 220 symbols, avg 16 on bits per, "flicker-free".

Using 30 frames per sec to mean 'flicker free', that works out to 10 usec per visible dot, and this is what I'm using for the timing for my implementation.

Since it takes 2 iot calls to draw a symbol, one for the first 17 bits, one for the second 18 bits to make up a 5x7 matrix, an average of 8 on bits per that implies that each one takes 80 usec or so to complete, so I delay raising the completion pulse for 10usec * number-of-on-bits.

Does this all make sense?

It is pretty useful, you need 2 words per distinct symbol you need to render, a couple of iots, done.

Bill

PS - this is shoving bits to the p7 display about as fast as it can take them without losing bits. I don't communicate directly with it, I just effectively do a dpy in the iot.

[Kevin McGrath]

  That P7 phosphor is SLOWWWWW... like very bright at first but takes maybe a minute to fully decay?  I would think 10 FPS would be considered "flicker free" on a true P7 display.  It has crazy long persistence.

  It's also interesting to think that some characters/glyphs render faster than others, depending upon the number of set bits.

  Has any Type 33's survived and still run?  Does the -1 at CHM have a 33?  Will you be able to test anything your write for it on real hardware?  It's a shame to think this kind of computer history is now lost, I would hope a maintenance manual could still be found somewhere.

-Kevin.

[Bill E]

Good point about the phosphor. I really need some real timing info.

Yes, CHM has a Type 33 and it works (or did, I've seen pics of it doing so).

Hopefully I can get some timing info from them.

The claim of 200 chars flicker-free also depends upon what other processing you're doing. It takes one iot per character, which won't complete for a 100 usecs or so, then add in whatever you're doing in your code to feed it characters, must be significantly less than 30fps.

Bill

[Norbert Landsteiner]

I don't think that "flicker-free" translates to 30 fps, like on modern display. The long sustain will probably stabilise the image a lot, so, something like 12 fps may still have been perceived as flicker-free. (E.g., Spacewar! is more or less about 15 fps.)

The Type 33 Manual reads,

> Symboi Display Time

> Approximately 96 microseconds from start of first memory cycle to end of display cycle, plus 3 microseconds for each dot intensified.

General operations are described as follows:

> The computer determines the location of the left end of a horizontal Iine along which symbols are to be plotted and loads this location into the X counter and Y buffer as in the point plotting mode, but does not initiate the 35-microsecond setup delay or permit a display. It next determines the intensity level, whether incrementing for additional symbols is needed, and the character size format for the line; and loads this information into the intensity and format buffers. Then it selects the first half of the particular symbol word to be generated and determines if it is to be a subscript, and loads this into a shift register with a command that initiates the symbol matrix plotting sequence. The computer must now select the last half of the symbol word and wait for the Type 33 to give a completion signal when the first half of the symbol word has been displayed, then transfer the last half of the symbol word to the shift register with a command that starts the symbol matrix plotting sequence again from the place where it left off. The Type 33 will again return a completion signal to the computer when it has finished displaying the character and has incremented the X counter to the beginning location of the next symbol.

Loading X and Y is specified as 30 microseconds in total.

The internal timing sequence seems to be started by a PLT impulse (which discriminates this IOT command [sdb] from the usual dpy) at TP7, which also seems the base line for the internal timing.

A (negative) clear display pulse (CDP) is generated 1.1 microseconds after the IOT instruction and a load display pulse (LDP) is generated 2.2 microseconds after CDP 3.3 microseconds after the IOT instruction.)

After each of the two pattern words have been displayed a DDP (display done pules) is generated, indicating that the PDP-1 should send the next pattern or, in the second DDP,  that the display is complete.

For the actual display, there are two 1 microsecond delays (combined the 2.0 microseconds matrix timing delay, where bits are shifted and tested) and a 3 microsecond intensification delay for each bit. Meaning, processing a single bit should take 5 microseconds.

As the second 1 microsecond delay triggers the intensification delay, the intensification delay is NOT generated for any unset bits. (Meaning, there's no constant timing, rather this depends on the count of set bits.)

The first of these 1 microsecond delays is the shift counter delay, generating the shift-and-count pulse (SCP) and there are 35 SCPs in total.

The over-all timing sequence is kind of complicated (two nearly identical blocks of two minor blocks each, each consisting of 6 SCP-enable signals and a final SPL signal generating the last shift-count – how does this add up to 15?) and I don't really understand it.

Anyways,

1) 30 µs …… transfer X and Y coors

(we may be here at 35 µs –for the point plotting mode, there's a 35 µs initial delay specified.)

2) intensification decoding

3) char. drop / subscript bit decoding

4) PLT 1: 3.2 + 17 x 2 µs + 3 µs for each set bit

5) DPP

6) PLT 2: 3.2 + 18 x 2 µs + 3 µs for each set bit

7) DDP

Best,

Norbert

[Bradford Miller]

On Jan 25, 2026, at 5:34 PM, Kevin McGrath <ke...@mcgrath.name> wrote:

 I would hope a maintenance manual could still be found somewhere.

I presume you have this manual: https://archive.org/details/bitsavers_decgraphiclGenerator1964_4037960/mode/2up

It has a maintenance section, and schematics.

[Norbert Landsteiner]

Small correction: PLT #2 probably hasn't the initial 3.2 microseconds delay (clear display and load display delays).

Here's the actual timing chart (which doesn't include any timings):

Mind that there's a preamble of unspecified timing events for the first PLT before the first SCP enable, which are not found for the second PLT cycle.

The last DDP pulse should also provide the completion pulse on the PDP-1 side of things.

Best,

Norbert

[Norbert Landsteiner]

This is from https://www.bitsavers.org/pdf/dec/graphics/Type_33_Digital_Symbol_Generator_1964.pdf
which seems to be the same thing.

Best,

Norbert

[Kevin McGrath]

  Nope, didn't have that manual!  Very cool.  :)  Seems they are around, just all over the place.

  A PDP-1 Wiki would rock.  Or at least a link list of all of the documents found online.  Seems every time I search for a PDP-1, the search engine changes it to PDP-11 because that's what most people search for.

[Kevin McGrath]

  So, rough timing is about:

96us + (3us * 16) = 96us + 48us = 144us average per character
220 characters * 144us = 31,680us = ~31.5 FPS

  So despite the slow persistence, you were right guessing 30 FPS for flicker free!  Trying to do the same thing with the fastest code on the Type 30:

50us * 16 average dots = 800us  average per character
220 characters * 800us = 176,000us = ~5.7 FPS

  Which I'm guessing flickers.  This means the Type 33 is about 6 times faster than the Type  30?  Is my math right?

-Kevin.

[Bill E]

Wow, thanks for the responses with real info! My guesses were close, a little tweaking needed to get to closer to exact. One issue is that I can only update once per 5us cycle, and that really challenges the dpy logic I use, effectively doing a dpy from the iot code. So, I only draw a dot every 10 usec, and calculate the total time taking that into account. I might have to dig more into how dpy sends updates to the type 30 emulator, but I wanted to avoid having to make any changes in the emulator itself.

As for the speed vs doing it all directly using dpy, one line in one of the sales docs said '10 times faster than software',  so that's pretty close.

I don't know why I couldn't find the manual after trying multiple permuations of keywords. Sometimes internet searches are pretty poor.

One thing to realize, the characters aren't baked in. The 33 could be used to display anything that could be made up of a matrix of dots in 5x7 tiles.

I have to admit that I did take one shortcut. The first iot, display left part, completes immediately because it just stores the 17 bits in an internal 36 bit shift register. The second, display right part, does take the proper time,  adding its bits to the register and computing the delay for both iots. It just made implementation a lot cleaner, and since the iots are issued in pairs, the simulation is still accurate overall.

Bill

[Unibus]

Hi,

Funny you should say that as I've been collecting all these references in my document. This is currently over 500 pages, 300 footnotes and 95% whitespace. Catch is bitsavers.org can throw Forbidden when using URLs to pdfs while you can still manually navigate to the document. The site carries a warning so this is no surprise. I've just emailed about 30 minutes ago to see if there is a quick and dirty solution. Worst case I would have to copy all the PDP-1 related files and bring up a server at home. Hardest part will be thinking of a good domain name then finding the time.

Regards,

Garry Page

--
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/b3c4e5f7-c2ca-4d97-8f5b-056ef719f2efn%40googlegroups.com.

[Unibus]

Hi,

Check out CRT Phosphor Video as an introduction to the topic. Take note of the P7 phosphor which is specified for the Type 30 Display. This leads onto the Cathode Ray Tube Chapter starting at Page 475, refer Massachusetts Institute of Technology (MIT), Radiation Laboratory Series, Volume 1. RADAR Systems. More details in Volume 22. Given the surplus equipment when the Radiation Laboratory morphed into Electronics it appears to provide a direct line through MIT to DEC for the technology. 

What is really disturbing is looking in footnotes and seeing books referenced that I had to study in the dim dark past. Terman or say topics like Miller capacitance in triodes? Luckily that is not me, I was taking the photo. For RADAR systems we trained for 1st generation computer hardware maintenance but I only ever had to maintain 2nd generation with the three legged fuses. 

Regards,

Garry

--

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/6c4e060a-f894-4d46-9aad-4ff636cf8591n%40googlegroups.com.

[Bill E]

That's great. I actually still have my RL series books somewhere, might have to dig them out.

I'm tweaking the timing in my IOT to match what's documented, and I felt guilty enough for not accurately implementing draw-left-side that I'm fixing that also.

Bill