An Interview with Mel Gregonis
MG = Mel Gregonis
GAM = George Michael
June 7, 1996
MG: I came to the Lab in 1963, late summer, a long time ago. I actually came from the state of
Oregon. I graduated from Oregon Tech and at that time we came down in busloads because the
Lab was hiring. Shortly after, I moved into the Comp Engineering Group when Bob Wyman was
the man in charge. After that, Dave Pehrson took the reins. So anyway, that was in 1963.
Basically, at that point in time, the Comp Engineering Group built all the interfaces to
the mainframes. Control Data was the "in" thing during those days and IBM was going out
the door. I got into probably phase II of TMDS when we decided it would work and we were
ready to make it fly. We moved the operation to Building 117, I don't remember what the
building number was in those days, but maybe you remember.
We bought the first refresh memory facility from Data Disk, then run by Armin Miller,
and continued with them for the next disk. The original scheme had one disk with sixteen
channels, as I remember. So the new scheme was that we would buy a newer disk with sixteen
channels, but we would buy more disks and end up with a multiple of six disks with sixteen
channels per disk. Then, in conjunction with this, Dave Pehrson came up with the idea of
the switch, or crossbar, based on his past experience with the Phone Company. Dave decided
we could take these sixteen channels per disk and share them amongst many, many users at
the Laboratory. This was my focus primarily with Jim Leighton, who was the project engineer
and, of course, Dave Pehrson at that time was our Group Leader and provided the main idea
for the TMDS Crossbar. With that basic knowledge, Jim Leighton and I went off and spent
many, many months at the drafting table. Many, many months. And then from there we got
it to the point were we could send the units out for wire wrapping. The hardware was
starting to come together. I don't remember chronologically, but this is probably 1970 or
thereabouts, we're talking specifically about TMDS II. Forget about TMDS I, which is
history. TMDS II in the planning stages was probably the late 1960's. It didn't really
come on-line until around 1970 and at that time it was with a dual processor system;
PDP 11-45's were the controllers. That was the hot stuff. Jim Leighton and I, with a
lot of technical support from the Comp Engineering group, did all of the basic design.
There was a lot of logic design, hardware construction and debug and, of course, software
that was done by Comp., primarily, John Fletcher, Gail Marshall and others. I don't remember
others, maybe you can.
GAM: I have a list.
MG: You have a list? OK then I guess it doesn't matter if I remember all the persons who were
involved. Primarily, we worked very closely with the Comp people to come up with a scheme
where we had hardware and software that would become a system. Fletcher also contributed a
lot of the design criteria that the logic was built around. Many, many months of logic
design and then the hardware construction and debug which was another many, many months.
Originally, Data Disk provided the videodisks and some interface-type logic to tie into
our system. All being driven by the PDP 11's, of course, it was all UNIBUS technology and
all the software was done in machine language. PDP 11: ahh, the good old days! Also, at
some point in time we came together with Data Disk personnel. This involved many months of
having to escort Data Disk people into the Q-cleared area where the hardware was being
interfaced to our computers, and I can't remember the name of the gentleman that we worked
with primarily in the early days.
GAM: It could have been either Armin Miller or Chuck Masters.
MG: That's likely. Anyway, there was a long period of time with debug and fixes and more fixes
and progress continued. Finally, we got the system on-line. Initially, we came up with a
limited system; we didn't originally have all the disks on-line. I think we had two or three
disks and we started out with a forty-eight-channel system. Three disks, forty-eight channels,
and we got this all working and started distributing co-axial fibers throughout the Lab,
mainly because this whole system was intended to be a composite video with a separate line
for every user. I don't remember all the numbers, we used forty-eight channels in the initial
GAM: Didn't the initial switch have 256 channels?
MG: 256, you're right. We went through some gyrations where we expanded the
switch and we also expanded the basic video disk farm. So you're right, and we originally
started out with 256 but TMDS became a very popular commodity at the Lab and we quickly used
up what limited resources we had. They went Bingo! Then we are back to the drawing board and
at some point in time Jim Moore jumped on the bandwagon and I don't remember chronologically
when this occurred. But, as I said originally, it was Jim Leighton and then Jim Moore got
into it during one of these expansion phases. The next step was to go from 48 by 256 to
48 by 512, the next phase in the expansion. We got that working and, Lo And Behold, Bingo,
the channels were gone again. In the meantime, another interesting thing about this was that
since the Lab encompasses an area of one square mile, driving video out to the remote sites
was a challenge because some places it's like one mile of co-axial with no amplification
in between. Early on it was decided to use low-loss rigid co-ax which was about 1/2 inch in
diameter. Each one of these 1/2-inch co-ax lines was to feed a single user. You can sort of
get the picture that eventually we got into the mode where we were digging trenches and
filling the trenches with this big humongous, expensive, co-axial cable which went to all
points throughout the Laboratory. This went on and on for many years. We got to the plateau
of 512 users and we quickly ran out of space. So we went into another expansion phase where
we doubled that, to 1024 channels. I believe that at this same period of time we also decided
we needed more video buffer resource, which means that we needed more data disks. So we also
doubled the number of video disks, from three we went to six which gave us 96 channels and
going through the switch, or cross-bar, however you want to call it, we went from 96 to share
among 1024 users. There was another gyration where we expanded the switch, and I don't
remember the number, it was kind of an odd number we ended up with because of binary constraints.
GAM: Well, the goal was 2048, but we didn't get that far. We settled for around 1900, but I can't
tell you why we had to stop there. Probably something to do with funding.
MG: Yes, 2048, that was the target because the linking channels, which is another subject, took
up a block out of that segment. The link channels were basically something that we carried
through from the first designs. The basic operation of the TMDS was to be a video output
device to save paper I guess, was the original idea.
GAM: Well, not really, it was to get cheap graphics to everyone.
MG: Well, yes, graphics and text. The basic idea was the user could get graphical and text
information to a video screen interactively with a worker computer; whichever that might
have been. In the early days it was Control Data and then we migrated to CRAY and so forth.
Getting back to the Link Channels, the Link Channels were a block of channels that had a
specific function to display system status. There were several channels dedicated to that
and also users could share information with one another with this linking scheme.
GAM: Lets sum it up this way, we eventually have 96 live video channels and we're feeding into a
cross-bar that blows it up to 1024 and then up to 1900 or something like that. Largely the
Lab built the hardware that was set to do this.
MG: Yes, it was conceived, designed, built and debugged within the Comp Group. The way we did a
lot of things in the old days, it was pretty exciting. After these phases of hardware expansion,
we still ran out of channels, so we went to other schemes where we started multiplexing
channels on a single co-ax, which took some cable TV video expertise. This was also done
primarily at the Lab by our television group. They got involved with the distribution of
more channels per co-ax because in the process of digging trenches and laying this big
humongous co-axial cable we ran out of space and room to go any further. That's sort of
where we ended up in the expansion phases. We could have always used more but we ran into
a brick wall.
GAM: There was one final phase where all of the channels were in RAM.
MG: Oh, yes, you're right. I forgot about that. The final phase was to eliminate the videodisks,
which were a maintenance headache. Mainly because they were rotating mechanical media, they
were old technology, and they were a continual maintenance nightmare. Trying to keep them
running and trying to keep them all synched up was a daily chore. In fact, an interesting
point here, all six of these disks had to be synched up together. Mainly because some of the
users were using multiple channels for color, or a gray level display. With our procedure of
first-come-first-served assigning TMDS video channels, there was no guarantee that you could
get them all from the same disk. All six of these disks had to be synched together with very
old attempts at phase lock loop technology and with these motor driven disk devices it was a
continual challenge. At some point in time, probably 1980, silicon memory (RAM) became
competitive financially. We decided, "Hey, let's go out and we will replace the mechanical
videodisks with solid state memory." In this case, we went to DeAnza, which I believe was an
offshoot of Data Disk, right?
GAM: I think DeAnza may have evolved from Gerber Scientific. Anyway, I plan to interview Chuck
Masters later, and I hope he will be able to clarify these things. Chuck is especially
interesting because he was involved with each of our procurements of a TMDS system. Anyway,
I'm not quite sure how DeAnza is related to Data Disk.
MG: I'm not either, but anyway, the company's name was DeAnza also down in Silicon Valley.
We worked with them to incorporate a system design that would be a plug and play disk clone,
or disk look-a-like, although it would be all solid state. We went through another phase of
gyrations, DeAnza did most of the hard part, the logic design, the construction, the debug,
with consulting with myself and I know Jim Moore, who was Team Leader at this particular time.
Between Jim Moore and myself and working with DeAnza people, (this time it was Chuck Masters
and Homer Martin,) we went through another phase of expansion and on-site development. DeAnza
people were escorted in and out daily for many, many months of struggling to get this system
debugged and up and running.
GAM: Well, by this time, weren't we moving to PDP 11/70's as the new controllers?
MG: Yes, well, actually I think in the early days we stayed with the 11/45's but I think we used
one for production and one for development. I think the 11/70's were installed after the DeAnza
hardware was up and running. We decided we needed to replace the PDP 11/45's because they were
obsolete. They were no longer maintainable; because we could no longer get parts. We never did
have a service contract with DEC so they became obsolete and they were not upgradeable. Then
we decided we would replace them after having meetings with DEC. I think you, George Michael,
were in on it and a few others. We decided we could buy two PDP 11/70's with the necessary
interface, disk storage, memory, etc. to get us in business. That got us through for many years.
GAM: So at that point we should have had 256 real video channels, less a few that were used for
MG: Actually, we didn't George. We never did buy all the memory. I think we ended up with 240.
We never did go to 256, but that was the plan. Originally, when we bought the system from
Data Disk, we bought a partial system and the intent was to expand it as we went along.
Actually, as this point,, TMDS started to taper off as NLTSS was being shoved aside by UNIX
that was used for networking along with ETHERNET. On the CRAYs, UNICOS became the buzzword;
the "in thing" and TMDS which held the peak for a number of years, gradually tapered off
until its shutdown.
GAM: That's quite a record though, we got the thing on-line in 1968 or 69 and it lasted until
1993 or 94. That's impressive.
MG: In fact, it probably has the award for longevity, as far as a home brew hardware/software,
system at Lawrence Radiation Laboratory.
GAM: We have now essentially described its evolution as it went from the very beginning to its
final days where we have had 240 live channels that were looking into something around 2000
MG: Yes, for users probably somewhere between 2000 to 3000 actual office connections with the
last expansion with the multiplexing on single co-axial fibers. The exact numbers are a
little unclear, but it doesn't matter anymore.
GAM: One of the things that is sort of interesting. Did you have anything to do with the little
stunt boxes that people built up for their offices so you could bring in several channels
at once and mix them in funny ways before you put them up on the screen?
MG: No, I didn't, I know what you're talking about. They also had cursor boxes, and printers
(Techtronix "Dry Silver" paper), and someone tried video tapes to hold movie frames. I think
that was all done certain users with the help of the television group. Our group wasn't
involved with that. Some of the interesting things about TMDS that did create some challenges
for us, had to do with the fact that the TMDS is, as you know, nonstandard video. It was
designed to be a square raster, of 512 x 512 points. With standard television that is not
the case. I don't recall, do you recall?
GAM: Our TMDS units were 558 line systems. That permitted the display of 512 by 512 rasters.
The better commercial TVs provided just about 489 lines.
MG: OK, so standard television is not a square, it's a rectangle, a 3 by 5 aspect ratio.
I don't really know the reason we did the 512, I think binary boundaries were the real
driving force. Anyway, this created some real problems for us whereby most commercial products
are designed for standard television or standard composite video. Basically, TMDS was composite,
but it had no RF. Most commercial products were designed for television industry. So we had to
play a lot of games finding the right equipment that the horizontal sweep rate could be tweaked
so that it would play on TMDS. The de-facto standard for video output was the old Conrac 17-inch
monochrome. People tried a lot of different devices; and one of the real challenges was the
Techtronics hardcopy unit. Even though the TMDS was supposed to replace paper hardcopy, people
still wanted hardcopy. The Techtronics hardcopy unit, which was a thermal print, took a video
frame and printed it. Anyway, the Techtronics, like most other hardware, was designed for
television. There was a lot of tweaking and internal component swapping to get the hardcopy to
come into the higher scan rate of the TMDS.
GAM: Yes, those Conrac's used a 558-line system. That allowed us to have 512 x 512 rasters that we
could see on the screen. It was a chore to tune those hardcopy printers. We tried to use
videotape. People tried to make movies at night. Jerry Owens led some of that effort years ago.
MG: Also, a lot of the color composite video monitors that were put on TMDS didn't work either.
The ones that did work had to be modified. It wasn't just a matter of adjusting the internal
frequency for horizontal synch. Typically, the commercial equipment didn't have the range.
That was one of the interesting challenges we encountered.
GAM: It's interesting that no one ever suggested that we should abandon this expensive option and
go to standard stuff. Because we were learning to things with software, the fastest scan
converters in the world were run on the 7600, as the software.
MG: Yes, I guess I wasn't in on those discussions of why we picked 512 by 512, other than I know
it was sort of historical and convenient.
GAM: I'm told it was that we wanted a circle to look like a circle. So we had to have a unity step
in each dimension. I think we were victims of our own assumption. We could have done it other
MG: Plus, it turned out to be easy with the binary binder boundary of 512. So it was a done deal.
Now, where are we?
GAM: We have essentially covered the basic technical evolution from the beginning of the idea up to
where it was shut off. You're right, we were getting lots of new local terminals that did
support high quality color displays, so the TMDS fell into disuse to a large extent. Though
many of the designers still preferred the TMDS because it was intimately tied with their big
MG: In fact, they will still tell you today, that they miss their TMDS. They miss NLTSS, the good
GAM: Well, those things were tuned and designed to handle the high, robust demands of the production
system that we had.
MG: Yes, versus the environment now where we are dependent on commercial developments. Which is all
doable, but it's kind of a step backwards. That's probably typical of the things we did in the
early days. Most of the stuff we created was never copied in the commercial world. A good
example is high-speed printers. I know we are deviating a little bit from TMDS, but in the
early days our high-speed printing of 7 pages per second, that to this day hasn't been equaled.
Today, we don't have such speed. Even though the quality was lousy, you could read it, and that
was thought to be quite sufficient for supporting our designers. The designers today seem to
prefer quality to high-speed printing.
GAM: Seven pages a second from the Radiation printer! That's going to be a chapter by itself in my
MB: And it should be.
GAM: Mel, thanks for taking the time to record this very interesting story.
Some Data on the TMDS Story
Mel Gregonis kindly provided the following summary of the specifications for the TMDS as they
were originally set for interfacing to the PDP 6, including an early drawing of the system (below):
The original TMDS (Television Monitor Display System) was being developed to interface to the
PDP 6, the main switch for the old Octopus system. The attached block diagram shows the major
parts of the TMDS and illustrates how it was to be connected to the Octopus network.
Practically all the image data was developed by software on the worker computers; i.e., the
CDC 6600s, the 7600s and so on, and sent via standard data channels to the PDP 6 core memories,
and from there the TMDS central control managed the transmission to an individual remote TV
in some user's office.
Alphanumeric and graphic images are constructed by the TMDS from lists of data in the PDP 6
memory, and then sent to the TMDS central control for transmission to an individual remote TV
in some user's office. The TMDS processes a list in one frame time (1/30th sec.). A list may
contain one or more messages that contain image and control information for a given TV monitor.
The TV raster is 512 by 512 points and the scan bit rate was 10.5 million bits/sec.
In Alphanumeric mode, the TMDS accepted 7-bit ASCII characters that had the following features:
- The character display matrix was 5 by 7 points.
- There was a 64 character set., with a screen capacity of 51 rows of up to 85 characters
- An alternate character display using a 7 by 10 dot matrix, allowing a 96 character set,
with up to 64 characters per line and 42 lines per screen.
- Line feed and carriage control characters.
In Graphics mode the TMDS accepted "streams" of bits from the core memory and reproduced them
as white and/or black spots along a TV scan line.
Editor's Addendum: I will add to these earliest memories of the TMDS with special emphasis on
the software activities.
The TMDS got its start in roughly the period 1965 through 1967. The idea grew out of a visit
to Malcolm McCaully and Joe Hood, engineers in the display group of Control Data in St Paul.
They showed some stuff that they had been developing to switch between digital and video
formats under computer control. They demonstrated the capture of a video signal and its
conversion to digital form. They could also reverse this, going from digital to video if that
was the requirement.
In talking with Malcolm and Joe, it became obvious that converting our
digital-based graphics data into video would be the most economical way to provide display
capability in a user's office . We brought that idea back to the Lab and after a short
gestation period, a small project was begun. We decided to use a computer disk to store
the video images and to support the refresh requirement. So video is what got sent to the
user's office. We chose a contact, head-per-track disk, that had a plating of cobalt and
nickel. We purchased it from Armin Miller. It was called a Data Disk and Bob Larkin, one
of our engineers spent a little more than a year trying to use 20 megacycle recording on
each track. Had that been possible, we could have had an initial 64-channel video capability.
As it turned out, we had to drop back a factor of four and got just 16 channels, of which
only 12 were really for user data. The remaining 4 channels were reserved as Show Channels
to display the status of the entire Octopus system on the other terminals.
The digital graphics images were scan converted by a piece of user software, and text was run through
a video character generator and both were then recorded on the cobalt-nickel disk. Then
the read-heads would send those signals into a co-axial cable connected to a TV set. That,
in essence was the first TMDS and to say that it was a success is really an understatement,
as the interview with Mel Gregonis has reported. The intention was to provide low cost graphics
capability to the users in their offices. It proved so useful that the initial 12 channels
were immediately inadequate. So, very shortly after these first adventures got started, we
began a set of augmentations of all sorts.
TMDS was a huge success; one of three. The other
two were the development of a mass storage facility using the IBM 1360, the Photostore, and
the production of a very robust time/resource sharing capability, LTSS. I mention these here
because in the final analysis all these successes were totally dependent on software. Each
project is further discussed in its own set of interviews, describing the environment and
the structure of the software. In all cases, the user software was developed by programmers
at the Lab. In that process, we evolved a style of usage. Generally we adopted the
"housekeeping" software supplied by the manufacturer. Things like controlling motors,
vacuums, and switching disk heads and reacting to some low level error controls. The
Lab staff using this low level housekeeping software, built the software actually seen
by the users. This included "macro level" routines like create, delete, merge, and fetch
files, or take some bits and produce a string of ASCII text, or produce pictures from
display lists, or share this file with some other user(s). Each utility development was,
by itself, a jewel: A software scan converter that was faster than that done by a TV
camera, or take these files and overlay them as one (shaded or colored) picture, and
so on. There were many such programs but one point to stress here is that such things
were being used by as many as 200 users simultaneously and almost always without painful
delays. This I not to say there were no delays, but most of these were more attributable
to certain political factors.
By reserving some channels for showing system-wide broadcasting, users could always see
at a glance such things as which machine was most lightly loaded, or which machine was
being used by a colleague, or what was the status of a program already started, and so on.
Much of the development for the Show Channels was done by Bob Judd, who has since moved to
LASL: more's the pity!
Most of this innovation was built on some absolutely elegant utilities produced by Henry Moll
and Alex Cecil, and collectively known as TRIX, or TRIX-AC. TRIX was inspired by some good
ideas from SNOBOL and TRAC and other text/string processors. TRIX-AC was a brilliant collection
of macros and other functions built from TRIX that proved to be central to all text manipulators
and picture generators. One could easily implement very powerful pattern searches, and
replacement algorithms, which ran at blinding speeds. They were extremely efficient and
small and prefigured many of the original Macintosh utilities; freeing users from the numbing
routine of having to type so much that is ordinarily obvious; sort of like all the useless
repetition required by non-Macintosh stations, (If I mention a file, of course it must be
opened. If it isn't, open it; don't waste my time telling me it isn't open, just open it,
or if it doesn't exist, create it!)
Diagram of the early TMDS system
For more information on the TMDS system, see the article, TMDS -The First Television Monitor Display System, by George Michael, and the other articles on Page 4 of this site.
For information about this page, contact us at: firstname.lastname@example.org