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 switch.

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 show channels.

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 switchable channels.

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 ways.

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 codes.

MG: In fact, they will still tell you today, that they miss their TMDS. They miss NLTSS, the good old days.

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 history review.

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 per line.
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.