ARIS BBS [+1 215/957-1000] (SIG 44/MESS 109-110) 1990 Reprinted from \DEC Professional/ magazine, August 1990, page 22.
From: Phil Gravel
I've done programming in ReGIS. All I do is WRITE or TYPE the appropriate commands from a FORTRAN program. Here are four strings from a program:
'<ESC>POp'
'S(E),S(C1),P[100,440]'
'V(S),[+100,+0],[+0,-10],[+0,+10],(E)'
'<ESC>\'
The first line puts the terminal in the ReGIS mode. The second line puts the graphics position at X=100, Y=440. The origin in ReGIS is the top left corner of the screen. Positive X goes to the right, and positive Y goes down.
The third line draws a vector from the current position (100,440) 100 pixels to the right at the same vertical position, then then draws another vector up (remember negative Y is up) 10 pixels and draws a vector back down 10 pixels. Finally, the fourth line exits the ReGIS mode.
To help you develop ReGIS applications, you can use the ReGIS Graphics Library (RGL) by Richard Desper of the U.S. Army Materials Technology Laboratory. This is available from the DECUS Software Library as V00365; it allows you to make high-level calls to ReGIS primitives.
The FORTRAN source code for VMS is available thusly
ftp://www.decus.org/pub/lib/v00365/vaxregis.zip
This Zip file is 990467 bytes. Be sure to transfer in binary mode.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.terminals
From: M.T.Shipley@bradford.ac.uk (MT SHIPLEY)
Subject: Re: What is GPO on a Vt100 "style" terminal?
Date: Sun, 22 Aug 1993 10:30:29 GMT
Elizabeth M. Phillips (ad302@freenet.buffalo.edu) wrote:
: I have asked this before but it seems to have fallen on deaf ears.
: SO once again I am repeating the question. : what is GPO?
Well, that got my attention !:-)
I've only discovered this newsgroup a month ago, and thus must have missed your original post.
: AVO is advanced video option (hey I know that much!) : but GPO eludes me, if someone could explain it I would : be very happy. AND if someone could give information : on utilization of it I would be also happy.
Cut from that old VT125 manual I seem to have (remember I thought it was a VT100 manual :-)...
TERMINAL OPERATION
The VT125 Graphic Terminal (Figure 1-1) is a VT100 text video text
terminal and a graphics processor in one package. The graphics
processor processes graphics commands from a computer to generate
an image in its own memory. Then it sends a video representation
of that image to the VT100 text terminal'l internal monitor screen
and to an optional external color monitor. It can also send a bit
map representation of the image to a graphics printer. blurb blurb
blurb.
So it looks as if your GPO is a Graphics Processor Option. Wow, that's ReGIS (Remote Graphics Instruction Set) graphics.
As a test, try outputting (or maybe if you can get the terminal into "local mode", typing), the following
Notes. A general form of ReGIS data is when sent to an ANSI device is:
ESC P p ...data... ESC \
That's subsiture ...data... for the variable sequences, and
envelope this with the escape character, uppercase P,
lowercase p, your data, escape, backslash
here goes...
ESC P p p[384,240] c[+100,+50] ESC \
circle maybe, at centre point [384,240] with circumference at (relative) [+100,+50].
here are some other command that I typed in, but have not finished yet...
VT125
Coordinate range [0..767, 0..479]
Odd-Y simulation for vertical pixels
Position Command
P
[] Reset pattern memory
[<position>] Move to <position>
<pixel-vector> Move as specified by pixel vector
(W(M<multiplier>)) Temporary writing controls
(B) Save current location on stack
(S) Save non-acting location on stack
(E) Pop and move to location off stack
V
[] Draw dot at current position
[<position>] Draw vector to <position>
<pixel-vector> Draw as specified by pixel vector
(W(M<multiplier>)) Temporary writing controls
(B) Save current location on stack
(S) Save non-acting location on stack
(E) Pop and draw to location off stack
C
[<position>] Circle with center at current
position, circumference at
<position>
(C)[<position>] Circle with centre at <position>,
circumference at current position
(A<degrees>)[<position>] Arc with center at current
position, starting at <position>
for <degrees>
(A<degrees>C)[<position>] Arc with center at <position>,
starting at current position
for <degrees>
(B)[<position>]...[<position>](E) Bounded (closed) curve
(S)[<position>]...[<position>](E) Unbounded (open) curve
(W(<temporary-writing-controls>)) Temporary writing controls
T
'<text>' Output the text <text>
(S<size-number>) Set character cell size to
standard size <size-number>
(H<multiplier>)
this misses report R(), screen control S(), writing control W(), macrographics, and no doubt some others.
notes. general format of coords is when numbers do *not* start with a sign, they're absolute, and with a sign, they're relative. If the coord is unchanged since last time, you can miss it out, but may need a comma as a placeholder.
[200,100] is abs x=200, y=100
[+200,-100] is rel x=currentX+200, y=currentY-100
[200] is abs x=200, y=unchanged (same as [200,+0])
[,-100] is rel, x=unchanged, y=currentY-100
If you need more details, then either find someone that has a terminal thats got ReGIS (eg VT240, VT241) that borrow the PROGRAMMING MANUAL. (note that the newer Digital graphics terminals seem not to come with a manual included, you need to purchase it). Also, some of the PC VT type emulators come with ReGIS docu.
If you fail to find more out, then post here, or mail me, and I'll (yawn) type some more documentation and examples in.
: thank you!
no prob!, (watch those !, and the use of uppercase, they make the message
sound SHARP (to me), which I'm sure you're not.)
Martin
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.os.vms
From: leichter@LRW.COM (Jerry Leichter)
Subject: re: Re: ReGIS escape sequences
Date: 8 Apr 91 14:41:40 GMT
> <ESC>P1p ==> Enters Graphis mode
> <ESC>Pp ==> I have no idea
If <ESC>P1p means enter graphics mode, then <ESC>Pp (which is
equivalent to <ESC>P0p should exit graphics mode.
Sorry, not quite - for two reasons, one of which doesn't happen to apply here.
The (rather academic) point of all this is that you can't look at an unknown sequence with an omitted numerical parameter and say much of anything about what it will do.
2. ESC P actually is "DCS"; it introduces a Device Control String. (In 8-bit mode, DCS can be encoded as a single byte with hex value 90.) The String introduced by a DCS nominally continues until the next String Terminator (ST - ESC \, or hex 9C). I say "nominally" because the ANSI 3.64 spec leaves open the question of what aborts a DCS. The particular kind of DCS is specified by the final character, "p" here for ReGIS. (There can be one or more intermediate characters, usually specifying numerical parameters, between them. The meaning of these parameters is specific to the particular type of DCS.) Another kind of DCS is Sixels, specified by final character "q".
All DCS types that DEC has defined avoid using most control characters, and will terminate - nominally in error - if they receive many "meaningless" control characters. In particular, ESC (not part of ST) will cause them to abort.
So ... all that said ... what does the mystery parameter to the ReGIS DCS do? I think the possibilities have grown over the years, but here is what they do on a VT330/VT340:
DCS p or DCS 0 p
Re-enter ReGIS at the point where it was last exited. Does
not display commands.
DCS 1 p
Enter ReGIS at command level; ReGIS begins a new command.
Does not display commands.
DCS x+2 p, x=0 or 1
Like DCS x p, but displays commands on the screen's bottom
line.
That is: When ReGIS "exits", what it really does is suspends exactly where it is. DCS 0 p continues from where it left off; DCS 1 p first cleans up and restores ReGIS to command mode. In a ReGIS string, ST xxx DCS 0 p is, in effect, a "subroutine call", executing xxx in normal ANSI mode.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.os.vms
From: GRSPANGLER@UALR.BITNET (CTRL-Z)
Subject: regis commands
Date: 8 Apr 91 13:40:00 GMT
> I am trying to program a VT241 to change the colours on the screen,
>with the aid of a .COM file kindly sent to me by David Sigler
><sigler@wheel.enet.dec.com>, but I am at a loss as to what some of the
>escape sequences do. I don't seem to have any relevant manuals, and the
>master index for the big gray wall does not have ReGIS listed !
>
> The particular sequences I am after are :
>
> <ESC>P1p > <ESC>Pp
>
>as well as the strings which ReGIS uses to set its colours.
well, according to this here vt240 manual of mine:
Sequence Meaning
esc Pp (or esc P0p) enters regis at previous command level (no
commands displayed).
esc P1p enters regis at highest command level (no
commands displayed).
example color changing command
s(m3(r)) or s(m3(h120l50s100))
either one changes the background color to red. s is a Screen command, m is output Mapping, the 3 stands for position 3, and the r in the first command stands for Red in the rgb color scheme and the other stands for red in the Hue/Lightness/Saturation scheme.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.sys.dec
From: mike@gordian.com (Michael Thomas)
Subject: Re: how many colors can I get in REGIS?
Date: 19 Nov 91 00:34:45 GMT
Having written a Regis emulator (ACK!), I think I'm qualified to say
that Regis doesn't have any real preconceived notion of the number of
bits/pixel. The Vt330 has only 2 bits/pixel whereas the Vt340 has 4 bit/pixel.
The form of the command to change the forground color slot
W(In)
where _n_ is the slot could really be anything. I think that most regis
implementation just truncate the high bits over the actual number of bits
per pixel (as opposed to say saturating...). I know for certain that the
Regis emulator for the DS3100 (running Ultrix) definately supports 16 colors
and wouldn't suprise me if it supported 256 colors (I think this pretty much
comes with the teritory being written under X). I have little doubt that
the VMS regis emulator is the same as the Ultrix emulator. All of the other
commands like setting the color of a slot, setting the plane mask etc, have
the same overall structure as the Write command.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.terminals,comp.sys.dec From: sherwin@royalt.enet.dec.com (Jim Sherwin) Subject: Re: VT240/REGIS control codes needed! Sender: usenet@nntpd.lkg.dec.com (USENET News System) Date: Thu, 30 Jul 1992 17:16:44 GMT
In article <JOE.92Jul28233246@oilean.oilean.uucp>,
joe@oilean.oilean.uucp (Joe McGuckin) writes...
>
>I'm the proud owner of a VT240 in reasonably good shape. I'd like
>to be able to use the graphics capability. Can someone send or email or
>point me to to where I can get this info?
Given that REGIS was proprietary to DEC VT's, perhaps the best
source would be DEC documentation. The following 3 manuals
might be of interest to you.
EK-VT125-GI VT125 REGIS PRIMER
EK-VT240-HR VT240 PROGRAMMER POCKET GUIDE
EK-VT240-RM VT240 PROGRAMMER REFERENCE MANUAL
I believe all of these are still orderable thru our DECdirect
catalog @ 1-800-DIGITAL (1-800-344-4825).
The VR201 was a monochrome monitor used on either of our
Rainbow, DECmate or Professional 3xx series of personal
computers. It can be connected to the VT240 system box also.
Doing so yields a 12" (I think) monochrome graphics terminal.
BTW the VT240 was either a monochrome or color graphics terminal
depending on the monitor used; VR240 = monochrome; VR241 = color.
These VR24x monitors were, I believe a Toshiba product.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.os.vms
From: Arne Vajhøj <ARNE@kopc.hhs.dk>
Subject: Re: WANTED: ReGis to Postscript converter
Date: Thu, 27 May 1993 16:46:11 +0100
> I'm searching for a program that will convert my ReGis files to > postscript. I need color postscript output. If there is anything > like this out there please let me know.
If you have CPS or DCPS installed, then you can RUN SYS$LIBRARY:TRN$REGIS_PS !
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.os.vms
From: "Richard D. Piccard" <piccard@ouvaxa.cats.ohiou.edu>
Subject: Re: What is SIXEL?
Date: Wed, 10 May 1995 16:36:11 GMT
For those who don't know about the GIGI, a little bit of history:
Also known as the VK-100, the GIGI was DEC's Apple II: it had BASIC (I think from Microsoft) in ROM, and looked about like an Apple II. There was supposedly an ability to download and upload BASIC programs, but so far as I know, VMS never supported that, except through user-written software.
In about 1982 or 1983 we got several of them when I was at Kalamazoo College. They took an external monitor, with RGB cables. As I recall, the resolution was at least VGA-equivalent, years before IBM did VGA, and they had THREE-BIT color: black, white, red, green, blue, cyan, yellow, and magenta. The funny thing was that we got them as part of a promotion, with a discount on some nice BARCO monitors. The discount was in the form of a coupon! It was a very handsome 8 x 10 certificate, but it was a coupon, nonetheless!
I had the impression that the ReGIS graphics language was invented as part of the GIGI project, although it did show up on several later terminals. Can any of the Digits on this discussion confirm or deny that?
The first versions of TPU, with the EDT-emulator, half-way supported them, but it was not a happy match. They were pretty much an orphan product at birth, but they did have the effect of making me think poorly of the first Macintosh as a graphics DISPLAY (512 x 384, ONE-BIT), since I was slow understanding the issue of a graphical USER INTERFACE :-(
It has been a while since I thought about the GIGI!
Dick Piccard
Academic Technology Manager
Computer Services
Ohio University
piccard@ouvaxa.cats.ohiou.edu
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.sys.dec
From: jeh@cmkrnl.com (Jamie Hanrahan)
Subject: Re: GIGI information requested.
Date: 23 Oct 93 13:09:56 PDT
In article <CF968v.3zM@news.iastate.edu>, tzb76@isuvax.iastate.edu writes: > I have one or two of these graphics terminals, and have > become curious as to their capacities. What sort of graphical > resolution and color range do they have?
Not much. The basic field is 240 pixels high by, I believe, 768. It supports Y-addressing in the range 0-439 (to provide "square pixels"), but each pair of y-coordinates is mapped to a single physical scan line. eg anything you to do to a pixel with y-address 0 or 1 affects the physical pixel at y-address 0.
It gets worse. The display memory is set up as a one-plane bitmap, 768 x 240. Then for each set of 12 pixels on a horizontal line, there is a set of four attributes bits. Three of them specify one of the eight standard colors (Black, blue, cyan, green, yellow, red, magenta, or white), and the fourth specifies blinking. ie within any given horizontal line, pixels 0 through 11 can be individually off (ie displaying the chosen background color) or on, but the ones that are on must all have the same color and blinking attributes; repeat for pixels 12 through 23, etc.
This allows for only 64 attribute changes per horizontal scan line. So, you can plot things with reasonable horizontal resolution, and poor vertical resolution by PC standards, but TERRIBLE horizontal resolution if you want differently-colored things to be near each other, X-coordinate-wise. This makes drawing pie charts, among other things, pretty much impossible unless the pie wedges are moved slightly apart from each other in the X-dimension. Line graphs are ok as long as all the lines are the same color (but what fun is that?). Multicolored bar charts can be made to work if you are careful to align the bars within these attribute groups. (ie keep the bars multiples of 12 pixels wide and put their left edges on an X-coordinate that's divisible by 12, then you can put differently-colored bars right next to each other.)
> And perhaps more
> importantly, how do I do something as simple as plot points
> of varring colors on the screen? They have a little internal
> basic, but Ive never been able to figure out how to make them
> do anything graphical from within that, and I asume that
> positioning the cursor, and ploting points of various colors
> at the direction of a host, is simply a mater of a few
> escape sequences of which I am ignorant.
These beasts accept a command language known as ReGIS - Remote Graphics Instruction Set. It's not bad. There are some moderately advanced features in the terminal, like arc- and circle-drawing, curve-fitting, and fill to a horizontal line (not arbitrary polygon fill). It supports downloadable fonts.
There was once a package of utilities, the "GIGI Utilities", later renamed "ReGIS Utilities", from DEC. This included a font editor, a primitive objectbased graphics editor, a slide show program, a graphing program, and a few other things. I believe this is now available from the DECUS Library.
Someone else mentioned that the VT125 programming manual came reasonably close to describing the GIGI's variant of ReGIS. This is true; however the VT125 is different in many details. It has only two bit planes in the graphics memry but there is none of this nonsense about attribute blocks. Also the VT125 can display four selectable colors from a pallette of 64, while the GIGI can display eight fixed colors from a pallette of eight. If you want GIGI manuals, look for manuals with "VK100" in the document part number -- that was the GIGI's "other" designation. Both are EXTREMELY primitive compared to a PC with even a standard VGA card, and the available software is very primitive compared to what you can get almost-free for a PC. Which isn't intended as a slam at DEC -- they're both fairly old products. But these days I wouldn't waste my time with either of them, even if I got them free.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.os.vms
From: Chris_F_Chiesa@cup.portal.com
Subject: Re: GIGI terminals
Date: 30 May 1995 14:20:19 -0700
Howard S Shubs (hshubs@bix.com / hshubs@ultranet.com) writes:
>In article <ngmmlGakfayV071yn@iol.ie>, mccrohan@iol.ie wrote:
>
>>That last statement is ot completely accurate. yes, on its own the VT125
>>was monocrome. However it came equipped with three BNC RGB connectors
>>that could be plugged into a standard BARCO or equivalent monitor to
>>display colour without any extra VT125 hardware.
>
>This is news to me.
I'll vouch for it. At a HamFest flea market three weekends ago, I saw a GiGi terminal with Barco color monitor for sale... Considered buying it, but didn't.
I -was- going to post with some information about ReGIS and Sixel, and software that uses/used it, when this thread first got started, but I haven't had time. Is there still an interest? You may wish to email me if so.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.os.vms
From: jeh@cmkrnl.com (Jamie Hanrahan, Kernel Mode Systems)
Subject: Re: GIGI terminals
Date: 1 Jun 95 21:11:23 PDT
In article <hshubs-2905951326060001@denim.ultranet.com>, hshubs@denim.ultranet.
com (Howard S Shubs) writes:
> In article <ngmmlGakfayV071yn@iol.ie>, mccrohan@iol.ie wrote:
>
>>That last statement is ot completely accurate. yes, on its own the VT125
>>was monocrome. However it came equipped with three BNC RGB connectors
>>that could be plugged into a standard BARCO or equivalent monitor to
>>display colour without any extra VT125 hardware.
>
> This is news to me.
It's true. You actually needed four cables though, since the VT125 did not emit sync on green. So you needed a monitor with a separate h/v sync input. To make things even stranger, the VT125 had no output jack labeled "sync" -- you used its monochrome video output as the sync source.
The VT125 was strange in lots of ways. The RGB output carried only the graphics video, while its built-in monochrome display mixed the graphics video with the standard VT100 character-cell video. (This is different from the GIGI -- using the GIGI in "character mode" caused writes to the graphics bitmap.) Had a very limited color palette and map, too -- you got to use a whopping four colors out of 64 available.
--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--:--
Newsgroups: comp.os.vms
From: Jerry Leichter <leichter@lrw.com>
Subject: Re: GIGI terminals
Date: Fri, 2 Jun 95 14:31:03 EDT
> ...The VT125 was strange in lots of ways. The RGB output carried only > the graphics video, while its built-in monochrome display mixed the > graphics video with the standard VT100 character-cell video. (This is > different from the GIGI -- using the GIGI in "character mode" caused > writes to the graphics bitmap.) Had a very limited color palette and > map, too -- you got to use a whopping four colors out of 64 available.
The original VT100 was much more than a terminal - it really was a base display system. There was room and power in the box to add all kinds of interesting things. At one extreme was the VT103, which put a whole Q-bus backplane and an 11/23 inside the box. There weren't any disks small enough to put in there at the time, but everything else needed for a "PC" was there. I've still got one - long story.
The VT125 was a similar design. The VT100 remains unchanged - the logic remains in the two-chip DC-something set, it has its own memory, its own D/A converters, etc. The graphics part of the VT125 is a completely independent processor. As I recall, it hooks into the incoming line in front of the VT100, and scans the data stream for the escape sequence that enters ReGIS mode. Then it takes over, grabbing characters until the ReGIS command to exit back to text mode arrives.
At the other end, the VT125 has its own screen bitmap, and its own D/A converters. An analogue mixer combines the signals from the text and graphics pieces.
This design has some handy features. For example, you can scroll the text under the graphics without affecting the graphics - very handy for debugging. People got used to this, and used it - assuming, for example, that clearing the textual data would leave the graphics image unchanged. They also made assumptions about the size and positional relationships between the text and graphics images, using textual data to anotate graphics images.
All these assumptions were invalid on every later ReGIS implementation - all later implementations used a common bitmap for text and graphics. Many ReGIS-using programs failed to work properly on VT240's as a result. GIGI's also used the common bitmap approach, but they and VT125's were used by disjoint groups of people, for the most part, so the incompatibilities weren't obvious earlier.
As to the four colors: It's hard these days of multi-megabit chips to imagine just how much memory cost in those days. I think the VT100 and VT125 use 8 Kbit chips! That's why AVO was a (moderately expensive) option on the original VT100: All it added was a bunch more memory. Two bits per pixel was the limit within the VT125's cost budget. (By the way, you of course got your 4 colors on the "graphics" plane, plus the 4 white intensities available on the "text" plane - yes, "bold" on the original VT100 wasn't implemented by using a different "thicker" character bitmap, but by turning the beam up higher. The reverse video background was a low-intensity white. I think bold plus reverse used the "normal" foreground intensity. The actual brightness levels were quite precisely specified and controlled (relative to the general screen brightness, of course - you could change that) - one of the high-cost individual components in a VT100 was the high-precision resistor pack used to implement the voltage divider that defined the screen intensities.)