• Please review our updated Terms and Rules here

Digital GiGi VK100 colour graphics terminal

Roland Huisman

Veteran Member
Joined
Mar 24, 2011
Messages
1,464
Location
The Netherlands
Hello everyone,

It seems there is a broken VK100 / GiGi terminal waiting for me to repair.
But I had never heard about a GiGi before...

The story: I was talking to a PDP11 specialist about a VT340. I was surprised by the existence
of a DEC colour graphics terminal. But it seems to be compatible with the Tektronix 4010
monochrome and 4027 colour terminals. I thought that was quite logical.
Also the Intecolor 2427 was a Tektronix compatible model. I new there were also
Wyse terminals which are Tek compatible...

Then he talked about the existence of a GiGi terminal. :confused:

With the GiGi I'm lost... The GiGi seems to have a ReGIS protocol.
Can't these GiGi terminals run in Tektronix compatible mode?
The 4027 was introduced in 1978 and the GiGi somewhere in 1981...
Both vector based graphics...

Does anyone have or know about software to use the graphics on a GiGi?
And are there any SIMH emulators for the GiGi? Or maybe programs to
translate Tek to ReGIS? It would be fun to fix such a terminal, but then I
would love see the terminal do some graphics as well...

Here is a nice Rubiks Cube on a GiGi:
https://twitter.com/sdf_pubnix/status/812759519105163264

Regards, Roland
 
Last edited:
I did use ReGIS on a VT240 terminal back in the day to show projected 3D graphics / diagrams of simulation results. It was a simple protocol, so translating TEK4014 -> ReGIS should not be difficult.
Software was written in VAX Pascal.

Jos
 
There is an emulation of the GIGI in MAME under VK100. I haven't played with it much so I'm not sure how complete it is. There are several applications that use ReGIS such as DECslide and DECgraph. I think PGPLOT can also generate ReGIS output. I don't know if the VK100 can do it but later terminals such as the VT240, VT330 and VT340 could also display sixel graphics. Also note that a standard DECterm can display both ReGIS and sixel graphics.
 
I did use ReGIS on a VT240 terminal back in the day to show projected 3D graphics / diagrams of simulation results. It was a simple protocol, so translating TEK4014 -> ReGIS should not be difficult.
Software was written in VAX Pascal.

Jos

VT125 also does REGIS. It is essentially an extra 8085 based board that hooks in on the serial coms connector and listens to certain escape sequences which it process while acting as a bridge for the rest of the communication.

Way back in the mid eighties I laid my hands on a VT125 and connected it to a Philips 8533 monitor. Was able to draw some small things using the REGIS protocol. Gnuplot apparently can handle REGIS.
 
The GIGI is more than a terminal. It's a microcomputer. Yet another example of something DEC did early on bit still didn't enable them to understand the home computer market, or the PC.
It can run as a terminal, or running the built-in MS BASIC selected through the setup.
Rather cool piece of hardware.

Mandatory bitsavers link: http://www.bitsavers.org/pdf/dec/terminal/gigi/

Oh, and as far as software goes. Anything that speaks ReGIS should be able to play with a GIGI as well.
Several programs have been mentioned in the thread already...
 
I did use ReGIS on a VT240 terminal back in the day to show projected 3D graphics / diagrams of simulation results. It was a simple protocol, so translating TEK4014 -> ReGIS should not be difficult.

To be honest, I was wondering if it is worth the effort to edit the firmware
which supports Tektronix data. But I think the source is not available...?

There is an emulation of the GIGI in MAME under VK100. I haven't played with it much so I'm not sure how complete it is. There are several applications that use ReGIS such as DECslide and DECgraph. I think PGPLOT can also generate ReGIS output.

Interesting... Do the DECslide, DECgraph and PGPLOT also run on a (small) PDP11?
Or do you need a more powerful vax for that?

The GIGI is more than a terminal. It's a microcomputer. Yet another example of something DEC did early on bit still didn't enable them to understand the home computer market, or the PC. It can run as a terminal, or running the built-in MS BASIC selected through the setup. Rather cool piece of hardware.

Yes I understood that it is a BASIC machine. But I don't see any option to connect any storage in the documentation.
So I guess you can't use it as a real computer...?

Regards, Roland
 
Interesting... Do the DECslide, DECgraph and PGPLOT also run on a (small) PDP11?
Or do you need a more powerful vax for that?
Unfortunately, I have seen very little software for the PDP-11 that talks ReGIS.
Yes I understood that it is a BASIC machine. But I don't see any option to connect any storage in the documentation.
So I guess you can't use it as a real computer...?

Regards, Roland

There are no "local" offline storage, no. You were expected to either just write software locally, and just have it running while the machine was on, and then loose it, or else have a backend machine upload software over serial, which in a way do imply storage.

So - write software on your PDP-11 or VAX, and then upload and run on your GiGi.
 
We had a pair or 3 GiGis in the computer lab in University. I never knew that they had a BASIC built it, we used them solely as terminals.

The modern xterm has direct support for ReGIS graphics, however it may not be enabled in the build on your distribution.

I've dabbled with it once, got it built and running, but didn't push it to any kind of limits.

GNUPlot will create ReGIS graphics files as well.

I can't speak to any Tektronix compatibility.

The ReGIS is also known for its use of Sixels for bitmap graphics.

The system was good for rendering graphics, but wasn't really useful for animation. A lot of that could be changed with baud rate.
 
Sixel is actually not at all related to, or connected with ReGIS.
If you are in ReGIS mode, you can't do sixel. On graphics terminals that do both you need to exit ReGIS mode before you can do any sixel graphics. And there are printers that understands sixel, but no ReGIS (LA50, LA75 and LN03 for example).
Not sure if there are any printers who understands ReGIS actually...

As for xterm, I know it started getting sixel capabilities a few years ago, but I was not aware of any ReGIS capabilities. But I should check then...
 
Unfortunately, I have seen very little software for the PDP-11 that talks ReGIS.
There was a package of demonstration programs for the VK100 under RSTS/E (they were written in Basic-Plus and not Microsoft BASIC, so they ran on the PDP-11).

There are no "local" offline storage, no. You were expected to either just write software locally, and just have it running while the machine was on, and then loose it, or else have a backend machine upload software over serial, which in a way do imply storage.
As I recall, there was support in the VK100 for upload/download from a host RSTS/E system via a BASIC support program on the RSTS/E end.

GiGos were miserable little things which seemed to exist mainly for the purpose of offloading way-overpriced Barco monitors. SPC got suckered into buying a PDP-11/24 with dual RL02s, a DZ11 and not much else (82F31469X was the system serial number - this was so painful it is still burned into my memory even today), along with a gaggle of 16 GiGos. Also supposedly included was a CAI authoring package which our sales rep claimed would run under RSTS/E on the 11/24. She didn't know that it was only available on VAX/VMS, and the powers-that-be at SPC had a conniption when they got the answer to "How much extra will that cost?"

At the time we were exclusively Data General for timesharing (see my comments about RDOS XBASIC, 64 terminals, yadda-yadda in another forum here) and I was distinctly unimpressed with the 11/24, despite it being 6 years newer than the base harware for my 'franken-clipse'. Not a great start to our modern relationship with DEC*.

I made our displeasure known to our sales rep, local management and regional management. We got a new sales rep (for free) and an 11/44 with FP, 2MB, 4 DZ11s and dual RK07's (also for free). I believe that one was 83031162F.

We used the GiGos as terminals in one of our computer labs until 1987 or so, when I made a deal with DEC to buy 102 VT102s for $102 each** (it was a finagle done at a DECUS Symposium, which combined the Symposium discount with the sale discount and the educational discount plus an addtional incentive discount to just get me out of the booth :rolleyes:). One of the bizarre design tradeoffs in the GiGo was that the size of a character cell was not the size of a color cell, so you couldn't have different colors on adjacent characters without it looking like something was very wrong. The GiGos were generally reliable except for the keyboards and a power supply or two.

* SPC was a very early DEC customer. It tended to weird people out when places like DECdirect asked for our DEC customer number and I would answer "316".

** That wasn't actually the most advantageous deal I ever made with DEC. My record is trading a Gandalf Quad PACX IV (2 full H960 cabinets) that had 512 terminal ports and 128 host ports for a pair of DECserver 550's, one full of 8-line CXY08 modem-control line cards and the other full of CXA16 local terminal line cards. We actually ended up with DEC owing us a credit on that deal (negative cost to us), plus they promised to come haul away the Gandalf gear for free.

*** Don't get me started on the Customer Returns Center. The joke was that we'd send it to DEC at Andover. And over. And over. And over, till they eventually fixed whatever we sent back properly. One time I send a VK100 keyboard back and they shipped me a package back where they had drilled out the rivets holding the metal brackets to the PCB and de-soldered the ribbon cable from the PCB, with a note saying "Next time please remove all optional accessories before returning hardware". Some time later, the repaired keyboard showed up, complete with new brackets and ribbon cable.
 
*** Don't get me started on the Customer Returns Center. The joke was that we'd send it to DEC at Andover. And over. And over. And over, till they eventually fixed whatever we sent back properly. One time I send a VK100 keyboard back and they shipped me a package back where they had drilled out the rivets holding the metal brackets to the PCB and de-soldered the ribbon cable from the PCB, with a note saying "Next time please remove all optional accessories before returning hardware". Some time later, the repaired keyboard showed up, complete with new brackets and ribbon cable.

One evening I got a call from another ET in a nearby #1AESS. He had a frame that had been OOS due to what turned out to be a "killer grid".

-------------------------

"In the later 1AESS, the reeds were of remanent magnetic material. This "Remreed" design allowed further reduction in size and power consumption. A "grid" of 1024 2-wire crosspoints, arranged as two stages of eight 8×8 switches, was permanently packaged in a box. Despite the sealed contacts, plating with silver rather than with precious metals resulted in reed arrays being less reliable than crossbar switches. When one crosspoint failed, the grid box was quickly replaced as a unit, and either repaired at a local workbench or shipped to a repair shop. "

https://en.wikipedia.org/wiki/Reed_relay

-------------------------

He already had the grid "fabbed out" meaning no calls were trying to go through it but we were in the evening busy hour and he was getting blocked calls, a big No No per the FCC. He asked me to bring over my spare grid. When i got there he had his spare, just returned from our PICS (Plug In Control System) warehouse where things went for repair, laid out on the desk already removed from the outer box. He asked me to take a look at some paperwork and verify a path through the grid. The paperwork was a trouble he had worked on a few weeks earlier for a stuck crosspoint in that same grid. I metered the path through that crosspoint and it was still stuck. The repair center hadn't even taken the grid out of the box, much less repaired it. He asked, "Do you see what I saw?" When I agreed, he said "They're not sending this one back to me again! Bring the boxes and meet me in the shipping room." He picked up the 40 pound grid, walked out the switchroom door to the stairwell, and dropped it over the railing to the terrazzo floor three stories below!

We somehow managed to cut up the inner box, cram it and the foam rubber packing material around the no longer quite so rectangular grid and into the outer box. I'm not sure what the repair folks thought when they took the wreck out of the box, but they didn't send it back as "No Trouble Found"!
 
He already had the grid "fabbed out" meaning no calls were trying to go through it but we were in the evening busy hour and he was getting blocked calls, a big No No per the FCC. He asked me to bring over my spare grid. When i got there he had his spare, just returned from our PICS (Plug In Control System) warehouse where things went for repair, laid out on the desk already removed from the outer box. He asked me to take a look at some paperwork and verify a path through the grid. The paperwork was a trouble he had worked on a few weeks earlier for a stuck crosspoint in that same grid. I metered the path through that crosspoint and it was still stuck. The repair center hadn't even taken the grid out of the box, much less repaired it. He asked, "Do you see what I saw?" When I agreed, he said "They're not sending this one back to me again! Bring the boxes and meet me in the shipping room." He picked up the 40 pound grid, walked out the switchroom door to the stairwell, and dropped it over the railing to the terrazzo floor three stories below!
Shouldn't the stuck crosspoint be detected as a FCG/SUPF during call setup and bypassed? This also sounds like a maintenance that should have been deferred until late night or weekend off-peak hours, unless the switch had been operating without the grid while it was out being "repaired".

Since you're an ESS old-timer, I bet you'll like these:

PXL_20210223_041759815-s.jpg PXL_20210223_041632760-s.jpg PXL_20210223_041715742-s.jpg

The book is available at the Internet Archive here, but I have copy #1 with a dedication from the editor to a fellow Bell Labs employee. Quite a find!
 
Shouldn't the stuck crosspoint be detected as a FCG/SUPF during call setup and bypassed? This also sounds like a maintenance that should have been deferred until late night or weekend off-peak hours, unless the switch had been operating without the grid while it was out being "repaired".

The "killer grid" could not have been put off as it essentially took down all 8 grids in the Junctor Switch Frame. When he unpacked his "just returned from repair" spare grid and saw his paperwork still in the box he became suspicious. His suspicions proved correct. He could have put the grid with the stuck crosspoint in the frame, essentially undoing his work on the previous trouble but seeing his paperwork still in the box set something off. He was a recycled USMC crypto tech who learned his chops in "The Nam". "Uncle Sam's Misguided Children" have a markedly different approach to a lot of things including, apparently, support forces who slack off and don't do what's expected of them. They also have an apparently well earned reputation for being rough on their gear. I saw that first hand. That grid made one heck of a noise when it hit the floor.
 
So I got the GiGi last Friday and to my surprise I got an VT241 with it as well. The VT241 was unknown and hasn't been on in this century at all. So checked the inside of the VT241 and also soldered some bad contacts in these single layer PCBs at warm components. These solder joints often give many problems in this age.

IMG_20210326_140633.jpg IMG_20210326_140754.jpg IMG_20210326_140918.jpg IMG_20210326_140921.jpg IMG_20210326_140942.jpg IMG_20210326_141020.jpg IMG_20210326_141341.jpg IMG_20210328_121125.jpg

The GiGi owner told me that is was a smoke gun in the past. Well these Rifa filter caps are known to fail over the years. So I replaced these with modern ones.

IMG_20210326_141055.jpg IMG_20210326_141047.jpg IMG_20210327_201708.jpg

Then the GiGi came to life again. It worked about two times and then the power on self test failed... I got a weird cursor with the height of the full screen. I pulled all the ROM chips with silver contacts out of the sockets. The pins turned from shiny silver into some black oxide. So I cleaned the pins and put them back in. The GiGi is online again.

IMG_20210328_150117.jpg IMG_20210328_153937.jpg

But now I would like to throw some color information to it to make a nice picture. Despite the nice software which is mentioned here I would have some software for a PDP11. Any idea's?

Or does anyone have a file which I can sent to it which generates a picture?

Regards, Roland
 
Nice to see I'm not the only one who owns one of these. I got mine from a large haul of stuff from upstate New York 2 years ago, along with some PDP-11/VAX/Alpha and Sun 4m/4u stuff.

I take it your monitor (to the OP) is one of these Barco monitors?
 
Hello everyone,

It seems there is a broken VK100 / GiGi terminal waiting for me to repair.
But I had never heard about a GiGi before...

The story: I was talking to a PDP11 specialist about a VT340. I was surprised by the existence
of a DEC colour graphics terminal. But it seems to be compatible with the Tektronix 4010
monochrome and 4027 colour terminals. I thought that was quite logical.
Also the Intecolor 2427 was a Tektronix compatible model. I new there were also
Wyse terminals which are Tek compatible...

Then he talked about the existence of a GiGi terminal. :confused:

With the GiGi I'm lost... The GiGi seems to have a ReGIS protocol.
Can't these GiGi terminals run in Tektronix compatible mode?
The 4027 was introduced in 1978 and the GiGi somewhere in 1981...
Both vector based graphics...

Does anyone have or know about software to use the graphics on a GiGi?
And are there any SIMH emulators for the GiGi? Or maybe programs to
translate Tek to ReGIS? It would be fun to fix such a terminal, but then I
would love see the terminal do some graphics as well...

Here is a nice Rubiks Cube on a GiGi:

Regards, Roland
Just came across this email thread. I was the advanced development manager for GIGI and can answer a couple of questions. We did indeed understand the microcomputer market, and the emergence of PCs. We predated both. But some factors unique to DEC lead to the VK100/GIGI emerging as a terminal. The most importwnt factor was that the GIGI was DECs response to CDC PLato, which was mainframe based with graphics workstations. Another was that this was engineered in an industry group (education) not central engineering. So we were required to not go the PC route. But the advanced dev version of GIGI, called SMAKY, had a 5" floppy and was essentially a PC. Well before the Apple one. DEC had a central engineering group working on PCs. A side note....i went from the EDU group to the PC group as the product manager for the DEC Pro 350. The day i arrived there the group was disbaned and reorganized. I chose to go another path, a one year stint in PC sales. I was back inside a year later as the Public Sector marketing manager for DEC's International group.
 
Unfortunately, I have seen very little software for the PDP-11 that talks ReGIS.


There are no "local" offline storage, no. You were expected to either just write software locally, and just have it running while the machine was on, and then loose it, or else have a backend machine upload software over serial, which in a way do imply storage.

So - write software on your PDP-11 or VAX, and then upload and run on your GiGi.
The VK100 was deaigned with local storage but ultimately emerged as a terminal designed to get its storage from a time sharing system, mostly RSTS/E at that iime. But it was fun to use one with storage. It was well ahead,of the apple pc at that time. read my other responses, especially the one about GIGI coming out of an industry engineering group rather than central engineering.
 
That's cool to know, Tony. I just acquired a GIGI VK100 a couple months ago and it's in the queue for refurbishing/testing. Looks like from the previous posts I should check the power supply right off and replace any RIFA caps I see. Hopefully nothing else is in too bad of shape.

When I was in college at Rose-Hulman we got some sort of grant and got 3 GIGIs and the accompanying BARCO monitors and had a small graphics lab with a Tek storage terminal along with the GIGIs
 
My university had a whole lab full of GIGIs. They were used either as dumb terminals to the VAX or for the graphics class. The graphics class was basic. Lots of transformational math and then hidden line algorithms on the GIGI. The GIGIs had a reputation for reliability. They were solid.
 
Hello everyone,

It seems there is a broken VK100 / GiGi terminal waiting for me to repair.
But I had never heard about a GiGi before...

The story: I was talking to a PDP11 specialist about a VT340. I was surprised by the existence
of a DEC colour graphics terminal. But it seems to be compatible with the Tektronix 4010
monochrome and 4027 colour terminals. I thought that was quite logical.
Also the Intecolor 2427 was a Tektronix compatible model. I new there were also
Wyse terminals which are Tek compatible...

Then he talked about the existence of a GiGi terminal. :confused:

With the GiGi I'm lost... The GiGi seems to have a ReGIS protocol.
Can't these GiGi terminals run in Tektronix compatible mode?
The 4027 was introduced in 1978 and the GiGi somewhere in 1981...
Both vector based graphics...

Does anyone have or know about software to use the graphics on a GiGi?
And are there any SIMH emulators for the GiGi? Or maybe programs to
translate Tek to ReGIS? It would be fun to fix such a terminal, but then I
would love see the terminal do some graphics as well...

Here is a nice Rubiks Cube on a GiGi:

Regards, Roland
I used to write programs using BASIC-Plus-2 on TOPS-20 or BASIC Plus on RSTS back in the day (can't remember which) to experiment with the GIGI. The GIGI isn't an OS so there wouldn't be any way to emulate it on SIMH (unless I'm totally mistaken).

The ReGIS Handbook (linked above) on page 1-4 gives a good basic description of how to get it to execute ReGIS commands. I forgot until I looked at that document briefly that it has an "immediate mode" where you can type the graphics commands directly from its own keyboard.
 
Last edited:
Back
Top