Type 33 Symbol Generator pushed to repo

18 views
Skip to first unread message

Bill E

unread,
Jan 28, 2026, 4:13:25 PM (8 days ago) Jan 28
to [PiDP-1]
I learned some interesting bits while testing and profiling this.
I first tried using the internal dpy logic to draw dots and found it cannot handle pushing bits fast enough to match the needed timing. It does a lot of extra work in the emulator to do dot aging that I don't quite understand, the p7 display does its own aging.

I had to switch to sending commands directly to the display. That was fast enough that I could pretty closely simulate the real timing of 2 usec per dot, plus 3 if it's on. Looks good.

The speed DEC claims, "200 characters flicker-free" is a real stretch. My IOT has the same timing as the hardware did. You would think you could render 200 chars quickly. But, that doesn't include all the program logic to actually feed characters to the generator. I didn't obsess over every cycle, but I did try to write tight code. The best I could get was 90 msecs to render 200 characters, which works out to 11 frames/sec. I imagine that could be improved some, but not dramatically. Add in converting flexo characters to the 2 bit pattern words on-the-fly, and things get slower. Still, you can get a lot of readable text on the screen.


Bill

Norbert Landsteiner

unread,
Jan 28, 2026, 5:14:37 PM (8 days ago) Jan 28
to [PiDP-1]
I think, 11 fps should still pass as flicker-free. I was told repeatedly that the long sustain intensification is visible for several seconds (up to ten seconds in a dark or dimly lit room), which should improve image stability quite a bit. There is also the problem of frame-based media, which introduces its own kind of flicker. E.g., even on film, we see the image chopped into newly intensified blue and older greenish partitions (compare the videos captured of Snowflake on the Digibarn website), which isn't perceived this way in person, where the effect is more like a smooth blending of colors. I kind of doubt that the display can be accurately reproduced by modern screen technology, it will be always an approximation. So the aim is really a "good enough" representation, which will probably be more flickery  than the original. Especially, since any emulation also involves choosing a specific lighting situation to target.

(This also extends to things like the TX-0, as well. There's a film of Mouse in the Maze, which shows extensive flicker, to the extent of being totally unviable for normal consumption. Still, this is not how this display was perceived, back then.)

Best,
Norbert

Bill E

unread,
Jan 28, 2026, 7:33:41 PM (8 days ago) Jan 28
to [PiDP-1]
I do see an interesting/annoying moving intensity band. I've seen this in some other programs. I suspect it's because the writing of the bits to the display and the aging isn't synchronized with the refresh rate. Nothing I'm going to worry about right now, though.
Bill
Reply all
Reply to author
Forward
0 new messages