VT220 does not have graphics, but does have an available down-line-loadable character set. DECDLD is the (protocol?) that is used to transfer the custom fonts to the terminal. I was wondering how fast it does this - from what I can gather, using this method you can redefine and line up the characters so that they form a picture, while still retaining the ROM character set. Am I totally off base about this? -----Original Message----- From: cctalk-bounces at classiccmp.org [mailto:cctalk-bounces at classiccmp.org] On Behalf Of Paul Koning Sent: Monday, August 08, 2005 4:51 PM To: cctalk at classiccmp.org Subject: Re: DECDLD usage -good enough for minimal graphics? Julian> Hello everyone! I was just investigating the usage of DECDLD Julian> for defining a small graphic screen on my PDP11 during a Julian> program. Julian> When using a VT220 at 19200 baud, how fast can a screen be Julian> refreshed using DECDLD graphics? I was thinking of doing a Julian> multiplayer (4 player) game using this system. If you plan the graphics properly, sure, no problem. PLATO had multiplayer games long ago using 1200 baud lines. That was with a MUCH more efficient graphics encoding, though. Did you mean VT240? Unless my brain is going, VT220 is text only. VT240 supports REGIS, which is a simple graphics protocol (somewhat verbose in its encoding as I recall). Assuming that REGIS doesn't lose more than a factor of 16 in coding efficiency vs. PLATO -- which should be true -- you should be able to get a couple of refreshes per second. There are plenty of interactive games that can live with that. paul

John> recalling... I thought the problem with that was you could John> only define 256 characters at a time, and when you tried to John> load a new set of bitpatterns, all instances old and new John> onscreen would change, making only a picture with 256 unique John> cells (no more) possible. Don't know if this is a fact, but John> that's what the spec seemed to say to me at the time. A full John> screen could be up to more like 24x80=1920 characters. A lot John> could still be done with even that. Another possible problem: John> fixed inter-character gaps. Perhaps someone here has actually John> Done this. That sounds right. Given that the VT220 is a character display terminal, it's refreshing from a character buffer via the character bitmap memory. If the bitmap memory changes, so does the display. If you don't want that, you need a terminal with a bitmap display memory -- the VT240, or the PRO for that matter... Ignoring the issue of inter-char gaps (don't know about that, easy enough to test), you should aim for a graphic design where all the elements together can be encoded in however many fixed and programmable character bitpatterns there are. That way you load things once, and the display then becomes a changing pattern of characters. Again, that was common on PLATO, which had (62) loadable characters. For example, the display for PacMan could be done that way. paul