From the May 1976 issue of Research/Development

Computers- Past, Present and Future

R/D interviews the architect on minicomputers who, as vice president, engineering, for Digital Equipment Corporation, has profoundly influenced data processing in r and d

To see Gordon Bell, you-don’t go to one of Digital Equipment Corporation’s more recent, modern new buildings. You drive down the main street of Maynard, Massachusetts, to the old textile mill that’s been DEC’s headquarters for some time. Fortunately, you don’t have to wend your way through the unmatching floors, and wings; Bell’s corner office is reached by one short hallway and a left turn through an engineering office. He greeted us at the door, led us into a room with a desk L’d into one corner, couch and chairs in another—all dominated by a large conference table and blackboard. Setting up the tape recorders, we broke the ice by asking:

What made you decide to be an engineer? And how did that lead‘to the computer field?

My interest in electrical engineering started while I was working for my father, who had a contracting and appliance repair business. I started out essentially being around mechanisms and tinkering. By the time I was 15, I retired as an electrician. I decided I wanted to be an engineer. I then went to MIT as a co-op student; principally. to get some understanding of what engineering was all about. It was a 5-year program with a Master’s degree.

I went to work for a couple of companies as a co-op student. It was very disturbing to find that I really didn’t like engirieering as it was practiced. They were fairly good sized companies, with a sea of engineers and massive assaults on problems. But somehow the really good solutions weren’t coming out. So I was relatively confused at this point about what I wanted to do.

Despite the co-op experience, you went right on through to the masters degree?

Oh, yes. Fundamentally, I liked the material. It was the environment that I wasn’t particularly keen on. Computers came along about the time I graduated in ’57. Transistor machines were just coming into place; one had been built at that point. Computers, at least as far as I was concerned, were really the ultimate in mechanisms, I still believe that.

I went to Australia, as a Fulbright scholar, really to try to decide what I wanted to do. It was a way of postponing making a decision. I had had a fairly intensive academic career, and I was kind of tired of working at that point. I went to a school that was patterned after MIT, the University of New South Wales. It was a young school, about 8 years old. I taught a graduate course and built a compiler for an English machine that Turing actually helped design. That gave me a user opinion about how to build machines and what they ought to look like.

I still correspond with the people there. In fact, the person whom I worked for—Ron Smart ran the comp center there—is now in charge of our international sales.

Then I came back, started down the PhD route at MIT and proceeded about halfway through that program. I was doing speech research, quite an interesting research problem. People have been on that problem for probably 50 years at this point. I’ve watched half a dozen people come up to that problem and say, “I can look at those sounds and interpret them. Now if I can simply build a machine that can understand speech.” They go off and work on that problem. In fact, some of them do make contributions.

I had that same feeling when I came back from Australia and was one of the first people to work on that problem with a computer. We built a lot of programs and hardware to do analysis.that would ultimately work on computer recognition. It took me a year and a half to realize that it was a 20-year problem, and I’m fundamentally not a 20-year-kind-of-problem person.

I like to work on all kinds of problems, but not for more than a couple years on one problem, although some have dragged on for 3 or 4 years. I like to solve problems, to see solutions. Design of a computer is something that can be solved in a relatively short term, but one has a feeling that the computer will have a long life and so it’s a particularly interesting problem. You can see a computer built. You can see people copy ideas from it.

How did you get into computer design from doing computer research on speech?

We were using a computer that was designed at Lincoln Lab. It was the first transistorized machine, the TX-0 and the Lincoln people who designed it had spun off to form DEC in 1957. I had started to design a magnetic tape control unit for the computer using modules bought from DEC, and got to know the few DEC people at that point. About halfway through I decided that digital systems design was what I wanted to do. DEC didn’t have large engineering staffs. It only took a few people to build that computer, to design it and get it ready to produce. It felt more like the style of engineering that at least I had imagined I wanted to do. So I joined DEC in 1960 and worked on various pieces of the PDP-1.

The PDP-1 was designed at that point; it was the fastest machine around and was the first transistorized machine on the market, as I recall. It was out before the 7090, which came out very shortly thereafter. We were selling the PDP-1 in real-time laboratory kinds of situations, so I worked on high-speed input/output channels and some scopes. The PDP-1 didn’t have multiply/divide, so I worked on it, and on the interrupt and direct memory access channels, all to enhance real-time performance.

In 1961 ITT came to us to buy PDP-1s for message switching, and I became the project engineer of the ITT machines. They were PDP-Is with a very large interrupt mechanism and a lot of telegraph I/O. I designed the logic, and we sold 20 or 30 of the systems . . . dual processors.

Most of your work at that point was hardware design?

Yes. We weren’t doing much with software yet. In 1960 the ALGOL group had met. We had a contract for a language based on ALGOL that was quite good. The language was excellent, but we got into a contractual thing where the piece of software didn’t get into production. Thus if it hadn’t been for the people involved, computing on mini’s might have been different. The person who designed it just didn’t want to part with his work. We were in an untenable situation and couldn’t make that software available, but it was good, and might have become a standard. It had assembly language built in, with a very nice control and block structure. It had a lot of features that probably shouldn’t have been abandoned. We had to withdraw to a more conventional approach, which is the one that’s been followed—mainly standard assembly language programming, plus FORTRAN and all other languages. We were about the first manufacturer to have FORTRAN, in 1963 on the PDP-4.

But that gets ahead of the progression. We wanted much lower cost machines because we found a tremendous elasticity in market versus price. Let me just give you the time line. First is the PDP-1, in 1960. It lasts a while, and then the PDP-4 in 1962 and then the 7, 9 and 15. These were all 18-bit machines, all family upward-compatible machines. But prices dropped, from $120,000 for the PDP-1 to $60,000 for the 4 and $30,000 for the 7. We really were trying to get much lower costs here.

I’ve always been intrigued with machines that are interesting to build; the most fascinating are these mini’s, for “minimal.” That is, you try to build the smallest machines you can to do a job, as opposed to building the largest machine that you can. In a design sense, the big machines are the easy machines to build because there are no trade-offs. [At this point, Bell drew a plot of performance versus cost on the blackboard.] There is a point here for the optimum machines, matching performance to needs at reasonable cost—the area of the mini’s. These are harder to build because it’s hard to find that point. You’ve got to have a lot of feel about what the thing is going to be used for. It’s not so much the cost that you end up with; it’s whether you put the right things in to have that performance. A designer is often accused of moving too far up the curve to a point of diminishing returns.

Don’t technological advances help?

Yes. Let’s get back to that time progression. Actually, when working on the PDP-4, I designed a 12-bit machine that turned out to be the predecessor of the PDP-5. Here’s the 5 in 1963; the PDP-8 came out a little bit after the 7, in 1965, and then the 8E, which is built with medium-scale integrated circuits. Prices tumbled from $27,000 for the PDP-5 to $18,000 for the PDP-8 and so on to about $2000 for the current 8A. But the significant thing about the 8 was that it was built using a wirewrap machine. Actually, we brought in the automatic wirewrap technology for a different reason, because we couldn’t make big machines. Meanwhile, I had gone on to make another machine called the PDP-6, the first commercial time-sharing computer, which went on to become the PDP-10 and then KI-10; there is now a KL-10 that is the basis of 20 series of large time-sharing machines.

Again, how do you provide lower cost computing? One approach says you just give everybody a small computer. The other approach says you make one big computer and you simply slice that among users. It’s the old decision between dedicated or time-shared.

What’s your view of time-sharing and networking?

They’re the same. Really, networking is simply a way of taking a given computer that may have a bunch of users sitting around it and being able to let this user community interface with another user community. Or it’s letting somebody who doesn’t have a computer at all interface into that computer. A network is for computer-to-computer as well as for terminals-to-computer communications.

Then there is this argument of, “Why have these big machines at all? Why don’t you give everybody their own little computer?” And indeed that’s happening to us to a certain extent. Some say, “What could be more lovely? I’ve got a floppy disk; I’ve got my own computer, my own terminal. Why would I ever want to have any interfacing with any outside world?

It turns out there’s a lot of data out there that you’d like to get access to. Moreover, there are a lot of times when the programs you run on these machines really are better run on a larger machine. What is worse, we all become our own systems programmers and program librarians. So essentially the networks are a way of coupling the machines. As we put more on line on single systems, there’s more of a need to have those systems talk to one another.

What do you see as the effect of microcomputers?

There are two main effects. One is simply the replacement of the current style of hardwired logic design with programming. That’s just more a way of “How do you implement logic?” A computer has traditionally been a wonderful way of implementing logic. There it’s simply a good logic replacement. I think that’s probably the biggest effect. It changes the style, the way the designs are done. The designs are actually going to be more reliable because we could never do a very good job teaching logic design. There are probably more hazards around in logic than we care to admit, because it’s a very difficult thing to do, to do well. I’m just very happy that we’ve gone to computers—although there are still opportunities for poor program designs, too!

Another effect is the tremendous increase in functionality, like the automatic ranging and complex signal processing within an instrument. The building of logic to put floating-point numbers in a hand-held voltmeter, to switch its polarity, to compute true rms and form statistical distributions all are happening.

Are you saying that when you tie an instrument to a computer you can spend a lot of the computer’s ability controlling the instrument, whereas if you put a microprocessor In the instrument, you then can use the computer and its memory system more efficiently?

No, I think that’s a third effect. I’m just driving at what the evolution will be. These smart instruments will be a better match to the intelligence of the user. But, once you start, once you do better preprocessing of information, you get a lot more information more easily. Then you’ve a massive data reduction problem. You’ve all these smart instruments sitting around providing much more data. Now, you still want to know what’s going on. To get some statistical significance, you want to couple the input and output.

What happens is every time you make a gadget fundamentally more intelligent by having more memory, more capability, then that drives you more in this network direction. Beeause you get more data out, you get into this problem of, “How does a person really deal with all of that stuff?” I think that is what networks have to do—get us out of some of the morass that data processing has gotten us into.

Do you see a problem in trying to get some standardization in this total area of smart instrument development versus computer development?

That’s a classic problem, an unsolvable design problem. Everybody will have their own idea of how to do it. There isn’t a “right” answer; for different applications it will make sense to do it one way instead of another. I think probably we’ll go through this first phase where instruments will really do as much data reduction and preprocessing as they can and then data will be forwarded in some sense.

Right now, you can ask yourself, “How many instruments do I have? Should I upgrade them? Do I want to buy all new instruments?” Each thing you probably have to argue independently. In any case, however, users are going to get into some massive programming problems. And I don’t see any way to avoid it. There isn’t anything, for maybe 10 years, that’s going to help that. Maybe that’s being pessimistic.

The way it’s going to be solved involves essentially massive amounts of memory, massive amounts of programming. Basically, you match intelligence with intelligence, and intelligence in our world equates to memory.

What’s the relative importance of processor speed, transfer rates, versus the amount of memory?

Processor speed isn’t much of a problem. The thing that you really always need more of is memory. There are lots of techniques you can use with more memory to get the equivalent of processor speed ... by doing table look-ups and by unwinding loops to make a straight-line program. I remember doing some early work on speech synthesis. We had no multiply or divide on the machine, and yet I made a very fast multiply with log table look-up.

Memory is a sort of universal solvent, but it can also be harmful. Memory is generally the mechanism used to match human intelligence. Providing more memory provides more capabilities, as in a language. For example, take something as simple as the initial BASIC, which had no string instructions. Well, there was a big change, a quantum jump really, after BASIC had that first level of additions to it and started understanding alphanumeric text. We need to label graphs, to process text in some form; we’ve data base information to look up. I find that nearly all the programs I write or need are basically string manipulation, COBOL-like programs. Few numbers—by and large it’s the storage and manipulation of text. I think in the laboratory the exciting thing is to really automate more of what the researcher really does, keeping notebooks and data bases, writing reports and dealing with text. One of the best times I’ve had was just before I left Carnegie, writing a book with Allen Newell and John Grason. It turned out to be a fairly good-sized book, but we worked on it less than a year. We had the whole text in the machine; we sat there and worked with that text, made corrections the day before it was produced; it was a real joy to put together—in contrast to one produced by the standard publishing route.

More memory is bad, when it provides the user with an opaque structure that he has to match and learn. For example, many operating systems evolve to have capabilities well beyond any person’s ability to understand and use them.

You mentioned Carnegie before, Carnegie Tech. You left DEC in 1966 and went back to teaching and university research. What motivated that?

A large number of engineers have the problem of, “What do you want to spend your life doing?” Do you want to solve problems, or do you like to manage others solving problems?” I felt at that time I was going too far in the management direction. I was beginning to feel I couldn’t solve any problems myself anymore. I wanted to get out of the management stuff, and I felt we had a basically good set of machines. I’d worked on the PDP-6 for 3 years, and I was really tired of managing projects. The PDP-10 was all set to be built. I didn’t have any real qualms about leaving because there were really good teams in place. I looked at it as the chance for more time to get a better understanding of what computing was all about.

When you went to Carnegie, did you have an understanding that you were going to come back after you “recharged your batteries?”

We had no explicit statement. I took an official leave, and I had a very strong consulting relationship. I was involved in all the machines and design reviews, and critiqued (and helped with) many projects. Communication was by phone, and I came to Maynard for a few days every couple of months. I also spent a summer here with the PDP-11 when it was going into production, when there were some critical decisions.

When did you come back full-time?

In 1972. I was involved in a system called the PDP-16, which was a style of design that I had been interested in for some time. When you conceptualize a machine, or digital system, it is at an intermediate level (register transfers), but that’s not taught. It isn’t done explicitly, but when it is and when it’s understood why, you inherently get much better designs. Earlier, we had built a set of modules at DEC that I had conceptualized. We sold some register transfer modules.

I’ve watched a number of people do logic design. There’s some concept of state, and they start putting hardware down to represent the state. Then they move pulses, move the state around over this drawing. Consequently, you end up with logic that doesn’t work. The other way is coming down from a programming standpoint to do logic design. The thing that motivated me was that the first microprocessor chip sets were coming on the market at that particular time (72) and I had just done an extensive survey on LSI technology. I was trying to predict where things were going, to set the tone of various research projects and also various machines. We had those register transfer modules and I said, “The modules are either too soon or too late. What’s really going to happen is that people are going to go to microprocessors. The logic designers don’t know about programming, but if you give them computers they know that that’s been done before, hence they can be used.”

So why say these register transfer modules were too soon or too late? They were too late with respect to LSI and microprocessors, but on the other hand they are now coming into use for conventional logic design. Fairchild has announced macromodules. There are chip sets; the four-bit slice microprocessors are register transfer level design, and there is a highly stylized design when you’re building bigger systems than a processor. That style of design is now really coming into use. You’re dealing with registers, you’re putting them in place, and you’ve rigid protocols for communicating among those parts. The LSI thing was reatly bothering me, and I didn’t think DEC was moving fast enough in it, so I came back really to help things move faster with respect to semiconductor technology.

Was that where the LSI-11 came from?

Well, the LSI-11 was really an opportunity with Western Digital. The summer I came back, we wrote a document about when the LSI-I1! could be built. We started out making an LSI PDP-8, and we had almost a prototype of the PDP-8 on a chip in 1974. Marketing said don’t make a PDP-8; let’s make a PDP-11. We said we couldn’t make a PDP-11 for three years. But we stopped the PDP-8 project and the 11 was made almost precisely on what the prediction was. We were within months of the ship date that we predicted.

What do you see in the future for computer architecture? What direction Is most probable?

The most visible thing is software. Independent of what the hardware is, with software you can surround any architecture and get certain capabilities. It’s not clear right now whether extra hardware counts much or whether this language or that language will get big gains in capabilities or productivity. There really aren’t very good language experiments; you find factors of 20 or 30 in terms of individual programmer productivity. The user’s ability to conceptualize problems seems to dominate.

Some things you intuitively feel. You can say one language is easier to learn than another. You can get in and do something very quickly with a BASIC system. You can do some things very quickly with the calculator systems. I think users are reluctant to make some of the initial investments that are required in learning to use a particular language. We’ve had examples of that right here—we recently did some calculations for our budget, and I put so many constraints on the problem that APL was the only language to use. By and large we wanted just a tremendous amount of processing.‘ We wanted to look at the business by size and by type, and we wanted to look at it historically, and we wanted to budget using several algorithms. The calculations were trivial to do. It was just that you could never imagine doing any of them with just a calculator or a conventional language.

Over the years, how many hours do you work a day?

I work about 10 or 12, but I also work weekends.

What do you do to relax?

By writing a program, or by reading something in another field, like the application of computers to music. Because the computer is such an all-encompassing device, one can move into a totally different aspect and be quite rejuvenated. I’m putting together a set of lectures on minicomputers and that, in a sense, is relaxing—until the time gets too near and it becomes a competitor for other things.

Do you see the computer business becoming a two- or three-company business?

Right now it’s hard to imagine that because the computer totally invades everything we do. The whole idea of a stored-program machine is as fundamental as the whole: business of mechanical energy transformation. That’s why it’s hard to imagine concentrated control.

The only thing that’s going to prevent growth and further applications is if the government gets involved in a controlling: fashion, the way Congress and the Justice Department tend to do. They can probably wreck the industry, but the success in computing so far has had to do with their laissez faire attitude toward industry. Research and development funding by NSF, DOD, AEC and NIH has had a tremendous impact on the industry’s evolution, and I believe we need this to continue.

Share

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

The Company

Editor’s note: This is the first company I have covered from my home state of Michigan.

According to Moby Games, MichTron started life as Computer Shack in 1980. They sold software for TRS-80 Model I and Model III. They sold both their own software and the work of other companies. Computer Shack gained popularity and was forced to changed their name to MichTron by Radio Shack.

However, I was unable to verify this elsewhere. According to OpenCorporates, Computer Shack was founded in October 1982 and was dissolved in May 1985. On the other hand, records show that MichTron was founded in October 1983 and was dissolved in May 1992. Both have addresses in Pontiac, Michigan, but they were 4 miles apart. They both had the same listed agent: Gordon Monnier.

Who was Gordon Monnier? The August 1989 issue of Computer Shopper Magazine had a list of ST Control Panelists at the Spring COMDEX. One of the names on the list was “Gordon Monnier—publisher, COMDEX showman, and president of MichTron, Inc.”

Bill Yerger wrote an article for Current Notes entitled “A History of the Atari ST - Part I: The Early Years, 1984 - 1987”. He wrote this about MichTron, which solves part of the mystery:

“The biggest names in software for the ST in this early period were Michtron, a company which had begun with programs on the Sanyo, and whose owner, Gordon Monnier, had taken a liking to the ST and thought it had a good chance of evolving into a nice niche market…”

The October 1989 issue of Puget Sound Atari News referred to MichTron as “The number one software company for the ST at least in terms of titles”. The September 1990 issue of Current Notes noted that MichTron was “one of the more voluminous product developers and distributors for the ST’s in the U.S.” The company distributed software from GFA SystemTeknic of Germany, HiSoft, Arnor, and others.

In 1990, MichTron showed signs that the end was near. The September 1990 issue of Current Notes states, “Rumors have it that Michtron is on the block; Gordon Monnier apparently confirms but declines to comment further.” STart Magazine for the following month stated, “Gordon Monnier said that MichTron is easing out of the ST marketplace. MichTron is still selling software, but Monnier said he is willing to entertain offers to buy the company.”

Here’s something fun. I found this “About Us” pamphlet from MichTron:

We chose the griffin for our logo because the mythical beast is a traditional symbol of quality.

In ancient days, griffins were said to be half-lion, half-eagle protectors of kings’ gold. The association with gold soon made the griffin a symbol of high quality products.

Since our first software program was a Dungeons and Dragons (TM) game for the Radio Shack Model I, we thought the griffin would be an excellent logo for us.

In the years since, many have recognized our griffin as the mark of quality software at a reasonable price.

We like to look at MichTron as a group of dedicated computer programmers and their support staff.

At the present time MichTron has 15 working on the Atari ST. Only two, Tim Purves and John Weaver, work full time at programming. All the rest are either students or people with full-time jobs who program as recreation.

Many of our programmers make enough money from their commissions to pay their way through college. The more of their programs we sell, the more money they make. The commission system gives programmers the incentive to write more and better programs. If you like this idea, tell your friends about it and tell them to buy a copy of your program from MichTron.

If you have written a program for the Atari ST we would be very interested in seeing it. We are always looking for good software to market.

We feel that MichTron can offer the best packaging, best marketing, and the best reputation of any company selling software for the Atari ST.

We try to sell state-of-the-art programs that give outstanding value for the dollar. If you have any suggestions, critisms or comments, they are always welcome. We read every letter sent to us and forward them to the program authors for inclusion in revisions.

MichTron has been in the software business for 5 years. We started writing software for the 8-bit Z80 Radio Shack computers. Then we moved to the 8/16 Motorola 6809 used in the Tandy Color Computer. In 1984 we said good-by to Tandy and gave our support to the 16-bit machines, mainly the Sanyo 555 because of its outstanding graphics. In just one year we became the number one producer of software for the Sanyo. Now we have moved to the greatest personal computer, the 68000 Atari ST.

The Application

One of the first mentions of ProText was in the July/August 1989 issue of Current Notes:

“Billed as the most powerful word processor for the ST, Protext is emigrating from England to the US. With all of the normal functions, dictionary and spell checker, WYSIWIG, two documents in memory with the ability to copy text between the two, plus mail merge, it appears to be a professional wordprocessor. If bug free, it may be a friend and a contender. Michtron plans to ship it in July.”

It was also mentioned in the August 1989 issue of Computer Shopper Magazine:

MichTron is also announcing its first major word processor product for the ST, called ProText. A complete list of features has yet to be compiled, but among its more prominent features will be support for multiple command macros and a built-in command-line interpreter for use in file control. Projected list price for ProText is $199.95.

The October 1991 issue of Amiga World Magazine carried a short review of ProText written by Bill Frazier:

When it comes to the heavy-duty mechanics of traditional word-processing programs, Protext ($199.95, Amor/MichTron) excels. In addition to the standard text manipulations, it automatically generates tables of contents from text headings and indexes from marked words or phrases. It plows through multiline footnotes and endnotes, handles headers and footers in neat fashion, and supports mail-merge and a variety of other advanced wordprocessing features. Best of all, Protext is easy to learn and simple to use. In short, the program is versatile enough to meet the demands of advanced users and beginners alike.

Where it falls down, however, is in the area of Amiga-specific features and feel. It suffers from port-over hangover, lacks true WYSIWYG screen display, and does not incorporate graphics with text.

Let’s look at the pros and cons of Protext a little more closely and see how it fits into the repertoire of existing Amiga word processors.

What You Get

The entire package comes on three noncopy-protected disks — program, dictionary, and printer drivers — each of which vou can easily install on vour hard drive with the provided script. The three-volume manual comprises a tutorial, a guide to the printer drivers, and a User Guide and Reference. Once installed, Pretext’s system configuration lets you select and save your own default start-up preferences. The program requires a minimum of 1 MB of RAM and Workbench 1.2 or later. Although ignoring the Work-bench printer drivers in favor of Protext’s own drivers may seem redundant at first, the developers actually provide a great service by including every option available for each of the 150 popular printers that Protext currently supports (with more of them under development).

The manuals supplied with Protext are among the most complete and easy to use of any I’ve worked with. They are arranged logically, include an extensive table of contents and index, and are simple to read and understand. The occasional use of “whilst” and similar words reflects the program’s origin, but the User Guide as a whole is an excellent document. All manuals were created using Protext, and they provide further proof of (he quality output possible when using this program.

Following Intuition guidelines, Protext provides the usual Amiga menu line and includes a large number of pull-down menu items. Nearly all menu selections are accessible to experienced users by way of keyboard shortcuts.

Protext provides a file-menu selection called Catalogue Files, which, when selected, displays a full screen showing the contents of the current directory. From this screen it is possible to open, view, erase, rename, and copy files. You can change the directory being shown at any time. It is also possible to display a graphic director)’ tree from this screen. Using this feature, you can manipulate files may in almost any manner you wish.

If you need to produce a simple box around text or to draw lines (with or without arrows), within a document, Protext provides the tools. Pressing the proper function key allows the cursor keys to double as line-drawing keys. This option makes it easy to box items and set them off from the text or to produce simple organizational charts. Printed lines are clean and smooth, without jagged edges.

Using Pretext’s Programming mode, you can write source code for assemblers and compilers or set up auto-indenting routines. Auto indent modifies the action of the Return key so that instead of going back to column I in the normal way, the cursor will return to the column that contains the first nonblank character in the line above.

Not Picture Perfect

Pretext does have a problem or two. Primary among these would be the lack of true WYSIWYG text layout on the monitor. While the program takes advantage of nearly every resident lout available on whatever primer you happen to be using, it limits the text shown on the screen to just one size — making it difficult to visualize what the final product will actually look like.

Protext does offer one unusual feature, although its implementation kills short of being useful. It can look up anagrams (words in which the letters are transposed to form an entirely new word), albeit slowly.

Another drawback Amiga owners may find hard to do without is Pretext’s inability to incorporate graphics or clip art with text. Today, most of the top Amiga word processors provide this feature, and this alone could influence some Amiga users to shun the program.

Although Protect provides excellent spell-checking, it does not include a built-in thesaurus. Many word-processing programs now have such a feature, and I find myself using a thesaurus more and more each time I write. While you could use a stand-alone thesaurus program with Protext, this is not a very convenient solution.

Protext does not have the “look and feel” of”a native Amiga program. Because it is available on a number of other systems — including MS-DOS machines and the Atari ST — you can transport documents created on one system for use on any other platform supported by Protext (either directly or by use of a conversion program). Such portability will be of value to many, but it is also reflected in the program design.

The value of any word processor lies in its ability to easily produce attractive, quality documents. Protext docs this, using the fonts and options available on any printer you happen to be using. If you can put up with the lack of certain features that most Amiga users have come to expect, Protext is an excellent word processor.

H. Earl Hill wrote a review for the March 1990 issue of Current Notes:

Some reviews are easy to write, others difficult, and the rest fall somewhere in between. I consider this a difficult review to write in that my task as I see it requires me to give a picture of a word processor that for some, will be just what they need, and for others will be something they wouldn’t touch a keyboard with.

Protext ™ does not use GEM, unlike the majority of its competitors. It is entirely keyboard intensive and lacks all those mouse-driven features that so many of us have grown to love so well. It does have some similar features to word processors (WPs) with which we are familiar, such as a WYSIWYG screen display. And also, a lot of WP’s, to use all the power possible, do use a lot of keyboard and function key commands. But still, if you are one of those people who have fully adopted GEM and mouse actions, you will not like Protext. If this shoe fits you, you may want to use the remainder of this review as a speed-reading exercise.

What is Protext? Protext is an import from Amor Ltd. from England, distributed in the USA by MichTron. It is a fully integrated WP for the Atari ST/Mega, but there is also a parallel product for the IBM PC and Amiga. It combines, in one package, features found in a word processor, text editor, and a command line interpreter. It also includes a spell checker, mail merge and file conversion. The emphasis is very much on wordprocessing.

The best description of Protext that comes to mind is power. Within the keyboard environment, there is essentially nothing it can’t do. These features will be described as we proceed. Protext is disk intensive, generally using disk space as document storage, for spell checking, for help files, etc. It can be used with RAM disks and/or hard disks to accelerate these operations. Although the optimum use is with typed-in commands, Protext does have an internally accessible menu for IBM-type cursor selection of functions (see below).

…

The manual consists of 386, extremely well-done, spiral-bound pages. Typos are minimal, although there are some mistakes in the mail merge section. It has five main chapters plus a Glossary and an Appendix with eight sections. The Although the Table of Contents is very detailed, the index is unacceptably sparse, considering the size of the manual. Each chapter covers one aspect of using Protext. The manual is organized so that the user can begin with the basics, use Protext at that level, and progress, as experience is gained, to the more complex functions. The manual contains very complete sections of command summaries and configuration options.

…

Protext has two main operational modes, the Edit mode and the Command mode, and one minor mode called a Program mode.

Command Mode. This handles Atari desktop operations such as copying, moving, deleting, saving and loading files; directory operations; formatting disks; printing; and running programs from within Protext. Command and Edit modes toggle. Most command mode operations can be carried out through the menus. These will lead inexperienced users through many of the command mode operations.

…

Edit Mode. Protext is a command driven word processor. This means that editing commands are carried out by pressing certain key combinations. Experienced, dedicated Protext users should find this an advantage in terms of speed and convenience of use. There is a strong similarity to WordStar commands.

…

Program Mode. This mode allows Protext to double as a source code editor of BASIC, assembler, C, Pascal, etc. It is also useful for creating data files. With it, formatting, the ruler line, and the right margin are suppressed, although most other functions are usable. Auto indent can be selectively enabled. Printing can be modified for program listings.

The command NUMBER can be used to add line numbers to, or remove line numbers from, the beginning of every line of text. Automatic line incrementing is optional. This provides a convenient method for writing BASIC programs.

Some programs, including compilers, assemblers, and linkers, can be run from within Protext.

…

Conclusion

As noted earlier, Protext is a word processor for a select group of individuals. Those who use a similar program, such as Wordstar, at work will find it ideal for home use on their ST/Mega. Those new to the ST, but with a lot of experience with IBM type command line based WPs, will find it both very powerful and easy to adapt to. There is no question that, as a professional word processor, Protext (although pricey for the USA) has features to do everything that is needed. For these people, Protext may be the WP of choice.

There may, however, be an overwhelming number of people who have become, like myself, adapted to GEM, mouse functions, and windows to do things. We can’t or won’t use a non-GEM word processor. Further problems exist with competition from WP’s which have automatic two-column layout; easy selection of printouts in different character size and pitch; GDOS; and the capability of importing graphics; to name only a few features. I guess, in the final analysis, the market will decide.

Here is the text from MichTron’s ProText brochure:

ProText is one of the most powerful word processors available for a microcomputer. Its incredible speed and flexibility allow you to create, edit, and format files quickly and easily. Loaded with features, ProText is designed to make your computer even more useful, and word processing enjoyable. ProText includes mail merge functions and a fast spelling checker with over 35,000 words in the dictionary. User definable dictionaries may also be easily created.

More than just a word processor, ProText is also a powerful text editor for programming C, assembly language, and HiSoft BASIC. With features like automatic indenting of program lines for structured programming, automatic numbering of program lines (if desired), PLUS many of the features of word processing such as search and replace, block commands and many others. ProText is a serious programming tool. You can even use the built-in Command Line Interpreter to run your assembler or compiler, without ever leaving ProText!

ProText permits an unlimited file size (up to the size of your disk) and extensive On Line help is available at the touch of a key. You’ll also find helpful tutorials and sample files.

Two files may be loaded into memory and you can instantly switch between them. You can even move blocks of text between the files.

Screen updates are fast. Most operations, such as reformatting and block moves are almost instantaneous.

PLUS MANY MORE FEATURES!

Never has a Word Processor/Text Editor this powerful been so affordably priced! ProText is priced at only $199.95.

Scott Wasser wrote a review of ProText for Antic's AMIGA Plus:

Computer users tend to treat their word processors like a pair of old sneakers. There may be newer, more fashionable and even more functional products on the market, but once you get comfortable with a word processor — like a pair of sneakers — it becomes hard to give up. I’m pointing this out because I believe MichTron’s Pretext is worth considering, even if you’re perfectly content with the word processor you’re already using. It has a few glitches, but overall it’s an easy-to-use program packed with interesting and useful features.

In the approximately 20 hours I spent evaluating Protext, it became one of my favorite word processors. For the most part Protext is as good as I’ve seen when it comes to striking a balance between power and ease of use. The program comes on two disks and will run on any Amiga with a minimum of 512K. One disk contains two versions of the Protext program (one for 512K machines), printer drivers, a hard disk installation file, a spell checker for 512K machines, a configuration program and an addendum to the printed documentation.

…

“Marginally” Superb

Margin manipulation is one of Protext’s best features. A default (or templated) ruler shows left and right margins and tab locations at the top of the document window. However, users can literally type in new margins at any point in the document, and succeeding text will conform to the new settings. This makes it a breeze to indent or outdent blocks of copy.

A special feature allows tabs to be set outside the left margin, great for typing in numbered lines of text. Another feature allows the creation of special decimal tabs, which can make lining up columns of numbers a virtually automatic operation.

Protext also automatically sets footnotes as well as headers, foolers and page numbers. The program can also automatically handle a wide range of mail merge functions, including .selecti\e and conditional text merges and insertion of times and dates. Data files for use in mail merges can be created, edited and stored with Protext.

A keystroke transposes letters in incorrectly spelled words such as “teh” or “thme.” Other keystrokes will turn lowercase letters into capitals and vice-versa. You can “imdelete” the last deleted word or string.

Finally, Protext has a built-in calculator function that supports the Amiga numeric keypad and allows the results of calculations to be inserted directly into documents being edited. A typewriter mode prints text as soon as you press RETURN, very convenient for addressing envelopes.

Mediocre Manual

Not nearly as convenient, the 31”^page manual is relatively easy to read and fairly well-organized, but it contains some incorrect information, neglects to cover certain aspects of the program and has a very weak index. The incomplete index doesn’t even refer to basic program features such as the calculator. Fortunately, Protext’s intuitive operation makes it easy enough to learn that the manual’s shortcomings can be overcome. A four-part on-disk tutorial helps.

Whatever effort you expend to use Protext will be rewarded. I’m willing to live with the inconvenient spell checker on my 512K system, and the mediocre documentation, to take advantage of Protext’s many useful and powerful features.

Have you ever used ProText? Do you know anything about its history? Tell us about it in the comments below.

Share

The Company

SpectraVision was founded by Harry Fox and Oscar Jutzeler in 19811. Both were Swiss immigrants who had worked as watch and clock makers. The company started selling computer games as a distributor, focusing on “Atari 2600 VCS, Colecovision and Commodore VIC-20” systems. Later that year, the company released the QuickShot joystick. This was very successful and lead to a line of accessories, including several more in the QuickShot product line.

In late 1982, the company was forced to change it’s name to Spectravideo. Another company (OnCommand) already a product named “SpectraVision”. In 1983, the company released it’s own computer: the SV-318. The new system included “a Z80 processor, 16k RAM, TMS9918A graphics chip and AY-3-8910 sound chip”. The SV-318 had it’s own version of DOS: MSX-DOS. This computer was followed by the SV-328, a more powerful system with more RAM, a full keyboard and number pad, and CP/M-support.

Both of these systems were a joint effort between Spectravideo, Bondwell in Hong Kong and ASCII Corporation in Japan (Microsoft’s representative in Japan). Kazuhiko Nishi, president of ASCII Corporation, liked the design of the SV-328 and wanted it to be the basis of a new standard for home computers. He worked out a deal with Spectravideo to do just that.

Read more

A couple of software projects have taken up a lot of my free time, but I’m working on a couple of Plus Posts. They should be out in the next week or so. Fingers crossed.

I’m also excited to publish this month’s interview. I have been looking for this interview for a while. I don’t want to spoil it, but I’ll give you a clue: it involves a very computer important computer from the 1970s.

Here are your plus post options for this month:

Read more

Cringely (pen name of Mark Stephens) started writing for InfoWorld in 1987. (In fact, he was the second writer to use that pen name.) In this role, Cringely covered many of the event…

Read more

Let’s add some levity to your day.

I hope you enjoyed the comics.

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

From the November 1984 issue of Microsystems

A Conversation with Andrew D. Hall, Director of the Bell Labs System V Development

Transcript of an interview between Microsystems (Mark, Chris) and Andy Hall, Director of the Bell Labs System V Development, at the AT&T Development Group’s facility in Summit, NJ, on 22 August, 1984.

Mark: At Microsystems, we support the type of standard environment created by the IBM PC. CP/M was powerful because it established a certain degree of portability for many programs. However, if you designed a large software project, one that was custom written for one client but designed well enough to be suitable for others, it could still easily require a good deal of modification effort before you could actually deliver it to another client. At least now, on the PC, if you write something for one client, there’s a good chance you won’t have to spend more than a minimal amount of effort to modify it for another. That’s the kind of standard that we’re talking about. It’s also one of the primary reasons why we like UNIX and its philosophy, and the direction in which it’s going.

I believe strongly that, very soon, end users won’t be buying a particular vendor’s machine just because of basic functionality issues. It’s like the automobile: you don’t buy one brand because it will take you further than another brand—they’ll both get you where you want to go. You buy one over another because it’s packaged a little nicer, or because it’s the right company, or because of price/performance tradeoffs. Micros are going to get to the same place. Meanwhile, until they do, there are very definite basic functionality issues. The industry is still developing, and software vendors are concentrating on the end user market, because that’s where the big dollars currently are, but are doing so in a rather short-sighted way. Many products are being developed quickly to get out into the market, but without all of the functionality that end users want, and without the capability for programmers to add that functionality. UNIX, with its portability, software development tools, and additional power that CP/M lacks, is a step in the right direction.

Andy: The analogy of the automobile has been pointed out to me before. You really don’t care what the engine is, as long as it meets certain performance expectations. It’s a fair analogy. The thing that’s going to change the computer industry is that, like the automobile industry, if you want to be in the headlight business, you’ve got to make a headlight with a certain plug on it. UNIX has the potential for setting the standards for the plug-in market, in terms of both hardware and software. This is going to open up all kinds of opportunities—and markets—for third party vendors. Right now, third party software, for UNIX, is hindered by the lack of UNIX standardization. The standard needs to be defined to the extent that people are confident it will be maintained, so that they can have a viable interface.

Mark: In our interview with Dennis and Ken, they mentioned that they had not been directly supporting the development group since before version 7. This split between research and development is of historical interest, especially since Dennis’s paper only covers the period through 1974. We’d like to know AT&T’s intentions with respect to the operating system itself, as well as the issue of standardization.

It’s also interesting that, in the interview, Dennis and Ken said they developed UNIX because it was something they needed, and that it was just fine if it was developed however the development group and the end user community wanted. This is a real contrast to the complaints coming from the current core UNIX community that the encroachment of the commercial world into UNIX is somehow corrupting the philosophy of UNIX.

Andy: I think you probably sensed, from talking to Ken and Dennis, as well as other people, that UNIX gained in popularity through a sort of grass roots growth. AT&T made a serendipitous decision to release UNIX to Academia for a modest licensing fee, which got it into the universities. People used it and learned to like it, because they were in the same kind of environment for which Ken and Dennis developed it. So there was a natural synergy between our research efforts and the needs of the university laboratories doing research. The academics were suffering the same kind of productivity ills we had encountered; they, too, were expending large amounts of resources supporting vendor operating systems. And UNIX, despite the fact that it was unsupported, turned out to have many of the features that research people felt they needed in order to get their jobs done. It was easily modifiable, sufficiently reliable that they didn’t have to expend a lot of resources on it, and sufficiently small that their people could learn it easily and modify it to suit their needs. So, it gained a lot of popularity in Academia.

Chris: Would you say that portability was another reason for its popularity in Academia, because of all the different kinds of machines being used?

Andy: Not in the early days. We’ll come back to that, because it’s an important part of the whole evolution. What happened is that people graduated from college and got into industry; there, they began to insist on having UNIX as their programming support environment—in other words, as a tool necessary to do their job. Then it started creeping into commercial products.

When UNIX hit the commercial marketplace, developers found that some other features were necessary before it could become viable. Things like file and record locking, real-time processing, a menu interface, and Apple/Lisa style displays. When you put UNIX into a desktop workstation, there are a number of deficiencies—it doesn’t support database management really well. But, there’s a natural conflict between the commercial world saying they need the features and the academic community saying they don’t.

Mark: Do you think it’s a question of the programmers saying, “Don’t bother me with it,” or is it something else, something more emotional?

Andy: It might just be system programmers. There’s a psychology of programming that I don’t think is very well understood, which leads to that. On the other hand, I think Ken and Dennis wouldn’t exhibit that kind of emotion— I think they would say that changes have got to happen to take UNIX into the commercial marketplace.

Mark: They did say that real-time processing, for instance, went against the original intention of the time-sharing system. It could be done—it was just more work than they wanted to do. But if other people wanted to put it in, it was fine with them.

Andy: All they are really saying is, “We had some basic aims and objectives in creating UNIX, to meet our own needs. These were different from the needs of the commercial market place.” It may well be that what has so far been done to meet the commercial needs—the first crack out of the box—isn’t the best possible. It happens to meet the immediate needs, and from a business point of view, that’s OK for now. But, we’re being driven by natural forces in the market place to develop UNIX into a better commercial product, and AT&T as a whole is working quite hard to do that.

Mark: In terms of that development, what can you tell us about the intention for graphics standards, CRT handling, such as cursor addressing, and the kinds of problems that are involved with implementing independent devices into standards?

Andy: First of all, the concept of device independence, in the early days, was confined to devices that were bytestream oriented: printers, TTY-like terminals, CRTs; all of them were very simple devices for which a simple stream model of the device would work. The concept of device independence was, therefore, fairly simple and articulate.

Since that time, various factors have all combined to allow us to build sophisticated devices that support complex graphics relatively inexpensively. If you want to get device independence back again, then you must virtualize those devices in order to present a general way of describing what happens on them. Below that level, depending on the particular output device, you’ve got to make compromises. For instance, you don’t have colors but you have textures—how do you map colors to textures automatically? A lot of people are working on the problem of how to build an applications environment in which that kind of thing is fully supported.

Right now, what has happened with MS-DOS is that they push that responsibility out to the programmers. Even in UNIX, you’ll find spooling programs that will take a file which is pure text, and will map it with the control sequences necessary to drive specific printers. UNIX provides a uniform way of writing byte streams to various devices, but has also pushed out to the applications level the responsibility of taking a text document containing italics, boldface, underlining, etc., and turning that into the specific control sequences to drive the printer. Typically, UNIX says, in the stored document file, “bold or italics go here;” then, there is a separate conversion program that maps the document to a specific output device. I think the same thing is going to happen when we start learning how to deal with bit-mapped displays, color displays, and so on.

Mark: That’s interesting, because eventually, we’ll be treating all displays, as well as printers, as bit-mapped devices.

Andy: Technically, it’s a difficult problem. It isn’t as simple as the original concept of device independence, but I believe that the GKS standard, and the CORE standard, and some of the other graphics standards, are attempts to address these issues.

Mark: Is the development team here at AT&T also working on this, as part of the OS responsibility?

Andy: We are very interested in getting an applications environment defined for UNIX, so that people writing applications can have a uniform interface. But it’s got to be part of the UNIX standard.

Mark: At what level? In the kernel, or at some interface level?

Andy: You’re asking for implementation detail. I do believe that the separation between the kernel and the rest of the system is not relevant; the important thing is getting the standard there. Until you have that applications environment there, it’s very difficult for people in the market place who are writing applications for UNIX to know what to do.

Chris: How far do the /usr/group standards conform to what AT&T feels is necessary?

Andy: Let’s look at what /usr/group has done. They started with Version 7 to define what I would call a core standard—a minimum set of capabilities that has to be there for application developers to write software that would move from one vendor’s UNIX system to another.

That standard doesn’t address what we just talked about—the applications environment. The reason it doesn’t is that they are taking what has already been done, and trying to standardize on that. Designing standards without having good examples to work from is not very successful. As a result, they haven’t standardized on any applications environment, or on any menu interfaces, or that sort of thing. They have picked a smaller standard, and we are working quite closely with /usr/ group to make sure that their standard is going in a direction that is consistent with AT&T, and to make sure that AT&T moves in a direction which supports the standard. We have a commitment to make our UNIX systems conform to whatever standard the /usr/ group agrees on. It’s important to the success of UNIX in the marketplace to get redefined standards, so that everybody who is developing software for UNIX can depend on their software running on different systems.

Chris: Where do you think the push for application environment standards is coming from? Mainly from you, or mainly from user groups?

Andy: There are really two user associations: there’s USENIX, which represents the academic community, and /usr/group which really represents the commercial interests and end users and is responding to commercial needs.

Here is the problem. What we are responding to is the needs of the third-party and application people who are trying to develop applications for UNIX. CP/M, MS-DOS and PC-DOS already have their standards. If you write a PC-DOS application, you can depend on it running on any machine that runs PC-DOS.

Now UNIX, because it runs on so many different vendors’ hardware, has the potential for each little instance of UNIX to be different in ways that could affect the livelihood of the applications software—you might have to make minor changes for every UNIX box you want to put your application on. That’s a high cost, and /usr/group recognizes that. So their goal is to make sure that all UNIX systems, as they appear on different vendors’ hardware, have a consistent interface to the applications. They don’t want to have to invest a lot of hours rewriting an application for every different box—there’s no leverage in that. And that, I think, is what is driving the standards, and the commercial world is what is driving the /usr/group.

Mark: There’s also the problem of Version 7, System III, and System V. IBM is going after System III right now; that’s what they are providing on the PC with PC/IX and Xenix, and even on the new AT, which is still System III, with Xenix.

Andy: I think too much is made of the differences between the versions. To the applications developer, the differences between System III and System V are relatively minor, and most of them are internal.

On the other hand, System V has major performance improvements over System III. Many of the internal algorithms to get performance out of the system are derived from larger minicomputers. It’s interesting to know that earlier this year Gates committed the UNIX marketplace to bringing Xenix up to System V. The UNIX community is being drawn toward System V, and whoever is on Xenix is being moved in that direction, too.

Mark: And that means MS-DOS, too. To a user, MS-DOS looks much like UNIX now, with hierarchical directories, and as much device-independence as possible.

Andy: I think Microsoft has realized that they’ve got to get some kind of compatibility with UNIX in the market place, to take advantage of what the standardization efforts are going to do. It increases every software house’s leverage to be part of that standard. The System III/System V issue is, I think, blown up out of proportion.

Mark: Is there anything more specific you can tell us about the differences?

Andy: An article on the Honeywell Scorpion, in UNIX World Vol. 1 No. 3 showed the differences in commands and tools diagrammatically. It looked as though System III was a subset of System V. In addition, System V has some major performance enhancements over System III.

Mark: What’s the intention of the development group in terms of networking and talking to other non-UNIX machines? UNIX has uucp, but if I’m sitting on an MS-DOS machine, I can’t talk to uucp. How do I get my files from PC-DOS or MS-DOS to UNIX and vice versa?

Andy: AT&T already has the UNIX bridge which allows you to connect an IBM PC to a 3B computer—it makes the 3B basically a remote file server for the PC.

Mark: Yes, but that’s only for in-house where there’s UNIX and a PC. How about remote communication over the telephone lines?

Andy: Uucp is totally outside the operating system. It’s an applications program which happens to communicate UNIX-host to UNIX-host. But there are plenty of programs in the market place that will do the same thing between UNIX and a non-UNIX host.

The approach we’re trying to take on networking and network architecture is to get to the open system architecture where third-party vendors can look at the architecture of UNIX and add their networking products to UNIX. So we are going to open up the operating system architecture and make it easy to add networking protocols and peripherals to the system.

But there are two kinds of networks to consider. If you are talking about small local area networks for point-to-point communication, there are plenty of UNIX networking packages available that will do the job. On the other hand, if you try to address a very big networking problem, along the lines of a corporation the size of an IBM or an AT&T, then the whole issue of network management comes into play; it’s no longer a matter of simple point-to-point communication. Then, I think, we have in UNIX the same problem that we have with every other vendor—the available products really don’t support that kind of network.

In AT&T we are addressing that problem, and are working quite hard to see what we can do within the UNIX architecture to make it feasible, though I don’t think there is anything specific that I can talk about.

Networking is another area that depends on standards, but I think it would be a mistake to try to define a standard before having something in the marketplace about which people say, “Yes, that works.” Networking has been a problem for twenty years and, to my mind, there is no good solution yet. But we certainly have to try to separate the two main issues, here. One is the question of media and transport; the other is the system architecture and how the applications see the network. One view says that the network should be independent of the transport. But that may be an overly simplistic view.

Mark: I’d like to bring up a question that is particularly important to Microsystems, and that’s the question of whether UNIX can even run on micros. Ken and Dennis told us that the machine they first had was not very different from a micro in terms of power and resources. I think the micro industry is very confused on this question. For example, when AT&T released the 6300 PC, they didn’t release it with UNIX; the rumour mill says that somebody at AT&T decided they couldn’t put UNIX on the 6300—or couldn’t do it fast enough.

Andy: To the question, “Can UNIX run on a micro?” I think the answer is unequivocally “Yes!”—and there are plenty of examples of it. But the real issue here is, “What do you mean by UNIX?” It’s a packaging issue. If you define UNIX as a software development environment with its operating system, its 400 commands, its C and Pascal compilers and the whole gamut of software that people think of as comprising UNIX—then you’re certainly not going to get that into a TRS-100 lap-top in one go, unless you add a substantial amount of disk resources. But yes, there is evidence to support the notion that you can take that software development environment and put it into a micro-based system with primary storage of 512K of RAM, a floppy disk, and a 10M or 30M hard disk. PC/IX is a good example.

But, the real issue is whether you can drive UNIX down into a lap-top portable or a workstation. And I believe the answer to that, too, is “Yes,” if what you mean by UNIX is the operating system, the core piece. It all depends upon what market you are trying to support. If you are going into the nonprofessional, commercial marketplace, then we are told over and over again that the software tools (which take up the bulk of the space) have no relevance. In that market they want spreadsheets, word processors, graphics tools, and so on. So it becomes important to standardize on what the base operating system is to be and to standardize the application interfaces, so that those products become viable.

Mark: Another important issue is, to whom does the third party software vendor apply for licensing of UNIX on machines that don’t yet have it. If ’ma software house with a client who insists on having HP machines, but the client’s turnkey system is going to require UNIX for development and operation, do I talk to AT&T about licensing? or do I go to HP and get them to work out a deal to put UNIX on their machine?

Andy: I know this is an issue in the industry, and I know that the industry is looking closely at AT&T to see how they will do it. But I don’t know the specifics, and I can’t comment on it. One issue is the ‘unbundling’ of UNIX, and AT&T is certainly working with the industry to resolve it. It comes down to getting workable standards for the partitioning of UNIX—not a very difficult problem from a technical point of view.

Chris: Is this question of partitioning part of the standards that you and /usr/group are, working on right now?

Andy: That’s one of the questions, but it’s not the major purpose of /usr/ group. /usr/group only defines the core piece that might run on a micro.

Mark: Can you tell us anything specific about what the development group is doing in terms of such things as file and record locking, and real-time processing?

Andy: File and record locking are two of the commercial requirements, and they were announced as part of the 3B2 product. That feature is being included in the licensing agreements. There are two levels under discussion, both of which are advisory, rather than mandatory. Both involve system calls in accordance with the /usr/group standard.

‘Real-time processing is a more difficult issue. Several vendors are offering real-time extensions to UNIX, but there are several holes to be filled. Setting process priorities and locking processes are capabilities that are already there. But if you mean guaranteeing a response to a task’s request within a certain time, or guaranteeing allocation of system resources, then no, we don’t have an agreed-upon way of doing real-time processing that is accepted by the industry. It’s a problem that is being addressed.

The UNIX RTR is a real-time operating system with exactly that capability, and it does in fact make those guarantees. But that’s a separate product, and not part of the UNIX standard.

Mark: The one thing I really don’t like about UNIX is the normal shell interface. It just doesn’t seem logical to say ‘ls’ to get a directory, and still less to say ‘cat’ when you want to type a file. But of course, UNIX makes it very easy to both change the commands directly, and to provide your own shell that a novice user would find easy to use.

Andy: The shell is a classic case of a tool built by professionals for professionals. But the nonprofessional will be provided with an alternative shell that will give him more mnemonic command names, menu interfaces, etc. Dennis Ritchie’s original paper specifically mentions alternative shells—it’s one of the important features of the operating system that the shell and the user interface are not a built-in capability, but can be replaced. That’s a key notion, and it’s often forgotten. There are already systems on the market in which the shell has been replaced by a new shell that provides menu interfaces and a totally different feel, and yet have an escape for the UNIX aficionados who want to use the standard shell. That is what I consider a valid evolution of UNIX.

Mark: Going back to the question of computer size, it’s my understanding that you couldn’t run UNIX in less than 128K of memory.

Andy: That question of threshold is quickly becoming irrelevant. Technology is changing so fast that I would be hesitant even to guess at what the threshold is. On your desk today is the equivalent of a 7090 that filled a room in the 1960’s. I don’t see any end to that trend, so I’m not going to say what the threshold is in terms of the capability that you can cram into a lap-top computer.

Besides, I believe that the computer industry is driven by willingness to pay. When computers cost $1 million and up, corporations required approval at a very high level of the organization. When minicomputers came out, the level of approval was $250,000. And with the workstation at $4000 or so, a very low level of authority in the organization could approve it. I belive that price ranges are really driven by the people who make the decisions. The technology is such that when you find a willingness to pay $4000, then you’re going to cram as much functionality as possible into that box. Look at what happened to pocket calculators: they started at $150 and went down to $50, $10, and now $5. I believe the same thing is going to happen with systems. When you talk of driving UNIX into 128K, it’s a question of what market you are trying to penetrate and their willingness to pay. At each price level, you’re going to find that the competition is going to be driven by technology, and how much functionality you can cram into that price range. I believe that soon you’re going to find a full-function UNIX system, a software development environment, at the $500 level. The only question is when? Two years? Five years? I don’t think it will be very long coming.

What I find exciting about UNIX is that there’s a groundswell of acceptance. People who have used it are saying, ““We’ve got to have it in our product.” That feeling isn’t restricted to one company, it’s becoming general. And that’s why I said earlier that the decision to license UNIX was serendipitous, because nobody could have predicted its success in the marketplace. The key was its portability. It was absolutely the right decision, because now every vendor sees a way to get a standard operating system without having to develop their own. And if it is really standard, the user gets access to all the software that has been developed for it, regardless of what machine he is running.

Share

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

The Company

I found two company names in relation to this device: Gemini Technology Inc and D.E.L. Professional Systems LTD. OpenCorporates didn’t have a listing for Gemini and the D.E.L. listing was very brief. (I can tell you that D.E.L. Professional Systems LTD was incorporated in February 1980.) I tried to go to the British Columbia Corporate Registry for more information, but they want $100 to search business records.

An ad in the December 1985 issue of Sextant revealed the connection. According to the ad, Gemini Technology Inc was formed to handle the manufacturing and marketing of the Gemini Emulator Board.

I also discovered the 1986 Survey of Industrials (a Canadian stock-market directory of listed companies) with a little different take. According to this publication Gemini Technology Inc was founded in 1983. It does state the Gemini held “world-wide manufacturing and marketing rights to the “Gemini” emulator board which is used to resolve incompatible instructions between the IBM-PC and the Zenith Z-100 computer.” They also owned some mineral claims to the Kamloops Mining Division of British Columbia. (Kagi Assistant noted that based on the location and date, Gemini was a “venture-capital/junior company” that was designed to hold the rights for a single product. It also noted that companies like this often paired a tech asset with mining assets to attract potential investors. Take this for what it’s worth.)

The survey also notes that the company was originally named Widescope Resources Ltd and was renamed in September 1985. Gemini “aquired D.E.L. Professional Systems Ltd., a manufacturer of custom electronics systems” in March 1986. For the year ending in December 1985, the company had a net income of $141,802 on revenue of $1,461,637.

The 1987 Survey of Industrials shows the following financials numbers.

I was finishing up this section what I did a little more research. I found a SEC filing for a company named North American Nickel that included the following paragraph:

The Company was incorporated as Rainbow Resources Ltd. September 20 1983 under certificate of incorporation no. 268952 in the Province of British Columbia Canada. The name was changed to Widescope Resources Ltd. May 1 1984, to Gemini Technology Inc. September 13 1985, to International Gemini Technology Inc. September 23 1993, and to Widescope Resources Inc., effective July 12, 2006. The name was subsequently changed to North American Nickel Inc., effective April 19, 2010.

North American Nickel’s URL now points to NexMetals Mining Corp, but I can’t nail down whether it’s another name change or a merger.

Read more

I almost ran out of month. Sorry.

I hope you enjoyed the comics.

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

I’m a little late this month. The poll will run for three days.

Here are the options for this month:

Read more

CAFTP Editor’s Note: My temporary second job will be ending soon, so I’ll be able to start posting more often. Until then, enjoy this interview about MS OS/2. Just think, if Microsoft had not fallen out with IBM, we’d be on OS/11 by now. Maybe.

From the May 1987 issue of Microsoft Systems Journal

OS/2: Turning Off the Car to Change Gears

An Interview with Gordon Letwin

by Lori Valigra

The development of Microsoft’s multitasking operating system has taken many twists and turns since Microsoft began working on it three years ago. The many stages it has gone through so far have resulted from working with the schizophrenic Intel 80286 chip, which can run in either of two incompatible modes: protected (286) mode, and unprotected (8086 or “real”) mode. The main problem has been to get an operating system which runs both protected- and realmode programs. Microsoft solved the problem with mode switching—a feature which essentially works by mimicking the act of turning off the computer and restarting it, similar to turning off a car in order to switch gears.

The new operating system began as an ambitious project to produce an operating system for Intel 80286-based computers running a mixture of office automation applications. This new operating system was to be capable of multitasking and compatible with the protected 286 mode. But as the project got too unwieldly, Microsoft split it up in early 1985, announcing a version called DOS 4. This version incorporates multitasking but does not include protected mode features. The DOS 5 project, as it was called, is intended to support the protected mode and add other features.

OS/2, as the project has finally been named, was easily the most difficult and challenging program written at Microsoft to date, with more than 350,000 lines of code. While Microsoft generally feels that the most efficient projects are those staffed by one person, the complexity and time constraints of the OS/2 project required that the company assign more than 35 programmers to it. Managing the project—dividing the programmers into teams, dividing the project among them, and coordinating the various teams’ modifications to the program’s code—became an enormous challenge. Adding to the challenge was the joint development of the product with IBM, a company whose culture and methodology are quite different from Microsoft’s.

Microsoft Systems Journal talked with the project’s chief architect, Gordon Letwin, to learn more about the planning, development, and cooperative effort that went into the development of OS/2.

MSJ: What was the goal of the OS/2 project?

Letwin: We tried to create the underpinnings for the ideal office automation operating system. In our opinion, that operating system would allow applications direct access to high-bandwidth peripherals, offer device-independent graphics drivers, provide multitasking without performance degradation (compared with a singletasking system), run programs in both the protected 286 and real 8086 modes of the 286 processor, and provide a protected environment to assure system stability. I think we’ve done a pretty good job.

MSJ: Microsoft has been developing multitasking operating systems for three years now, beginning with DOS 4. What was the purpose of that operating system, and where does it stand now that OS/2 is out?

Letwin: DOS 4 was the first product to result from Microsoft’s multitasking DOS effort. We began it even before IBM introduced the PC AT. It was an ambitious product that was originally to include a protected mode with mode switching abilities so it could run on the 8086 or the 286.

A general-purpose multitasking system needs to run in both modes: the unprotected 8086 mode so that we can run existing DOS applications, and the protected 286 mode so that we can multitask arbitrary, unrelated applications. But the architecture of the 286 caused some delays. Although we knew the project would be difficult, it was only after we’d gotten deeply into it that we realized just how difficult it would be.

As a result, DOS 4 became too complicated for our schedules. Because of the pressure of customer demand as well as that of previous commitments, we broke the project into two parts. DOS 4 runs only in real mode and provides multitasking only for specialized applications. DOS 5, which has now been released as OS/2, includes the protected mode and other features. DOS 4 was delivered in the last half of 1986 and is being sold in special application environments, primarily in Europe. It is a specialized product that can share the market with OS/2, because it runs on 8086 hardware, while OS/2 requires a 286. The move from DOS 4 to OS/2 was a gradual evolutionary process. OS/2 is by far the most complex and sophisticated operating system project we’ve worked on. To offer multitasking in a protected environment, we developed it jointly with IBM to get around the constraints of the 286.

MSJ: How does OS/2 compare with earlier multitasking operating systems like Concurrent CP/M?

Letwin: Unlike OS/2, Concurrent CP/M has a major problem. It serializes access to the file system. When multitasking you need to make the operating system features such as the file system accessible to multiple programs at a time. But Concurrent CP/M didn’t do this. It only allowed one program to call the file system at a time. So in a real life situation with lots of I/O, Concurrent CP/M was too slow.

MSJ: What are some of the features of OS/2 that you consider particularly neat?

Letwin: One is the seamless system service interface, which means that system services don’t need to be in the kernel. Some can be provided by subroutine libraries and others by system processes. Many services can be upgraded piecemeal, in the field, without changing the whole operating system. This is accomplished by a technique called “dynamic linking,” which allows external procedure calls to be linked up at execution time, rather than link time. This same mechanism is used as the standard system interface between applications, utility packages, etc.

Another exceptional feature is direct hardware access, which allows an application to write directly to the hardware. For example, it will do special graphics on a screen.

MSJ: How did you get around the limitations of the 286 chip?

Letwin: The 286 is designed to run in only one mode, either real mode or protected mode. Since we knew we needed to support programs written using protected mode, a group of us, including Bill Gates and some project engineers, brainstormed to try to figure out how to run 8086 mode applications from within protected 286 mode. One option was “real mode emulation,” where we could emulate the operation of 8086 real mode by doing a lot of special things to the protected mode segment tables. IBM _ was examining this technique independently. We thought emulation would be too slow, since the 286 would run at one-third the speed of an 8086. IBM’s research later showed this to be the case. Soon thereafter, Intel began shipping a chip with a bug in it that would stop the technique anyway, so we tried another approach: mode switching.

The 286 chip switches from real mode to protected mode very easily, but it was not designed to switch back from protected mode to real mode at all. You could only switch back to real mode by causing a full system reset. The idea of doing a full system reset while running a multitasking system was very radical. IBM was aware of the mode switching technique itself and had the capability for it in the AT BIOS for use during power-up diagnostics and for special block copies from high memory. However, this feature was never intended for use during full system operation. What we were thinking of was similar to switching gears in a car by turning the motor off. The idea was to master-clear the processor and restart it. The question was, would this interfere with DMA transfers that might be happening at the same time, lose pending interrupts, or fail in some other way? The IBM ROM code was designed to “switch gears by turning off the car” with the car standing still. We wanted to switch gears with the car traveling at highway speeds, and without causing a jolt. Working together with IBM, we set up an experiment to see if it would work, and it did. However, it took us months to convince everyone involved that the technique was feasible. The first time we presented the idea to IBM Boca, they gave us a funny look and suggested that perhaps we’d had a bit too much sun.

There is one difficulty with mode switching, however. Because the designers thought that it would be an infrequent operation, done primarily during the power-on diagnostics, they implemented it in a fashion that saved some components but produced a very slow mode switch: typically 1,000 microseconds, round trip. During this | millisecond interval the system cannot respond to interrupts. Any interrupts that arrive then are processed after the mode switch. This delay would normally be a problem only for high-speed communications at 96K bps or faster while you are simultaneously interacting with a real-mode program. You may experience data overruns while the realmode screen group is on the display. Mode switching will affect any program that requires a very high-speed interrupt service rate faster than 500 Hz. If the communications protocols on your system can handle missing characters by asking for a retransmit, and most can, then communications will be okay.

MSJ: Why is protection so important in OS/2?

Letwin: We knew we needed a multitasking system to accomplish our goals, and we knew we needed to have it protected. If you run a multiprocessor system, software can accidentally read or change other programs or data if the memory is unprotected. You can’t stop it and you can’t tell it happened. The system can crash or you could corrupt data. Even in an unprotected DOS 3 system you can have problems with running programs simultaneously. SideKick, for example, loads into memory and terminates itself. It keeps memory in use, but the system doesn’t know what is in that memory location. If you load several such programs at the same time and they conflict on how they use memory or interrupt vectors, the software will not work correctly, or the system will crash. So in an unprotected environment the system is always vulnerable to flaky software or conflicts between software products from different vendors.

Of even greater importance than this is the fact that we needed to use protected mode to allow programs to access more than 640K bytes of memory. The 640K limit in earlier versions of DOS is a result of the addressing limitations of real mode. Protected mode programs are released from this restriction, and can use many megabytes of memory. As memory costs continue to drop and memory consumption by applications rises, it has become unacceptable to be restricted to the 640K that real mode provides.

MSJ: How did you plan such an ambitious project, both conceptually and in getting the needed resources?

Letwin: The first step was to decide what we wanted the system to do. Then, when we discovered how many of those capabilities we could implement, and by when, we could revise our goals. As a result, the initial planning process was iterative. We needed to have multitasking and to execute existing DOS 3 programs. While there were still only a few engineers on the project, we thought about techniques such as mode switching and when necessary, prototyped some code. As we got a better handle on what we could do, and how long it would take, we met again with Bill Gates and revised our goals. The tone of the first phase was as ambitious as possible, and we listed all the things we thought we could do. The second phase involved determining which of those features were feasible in the required time frame. As soon as the general scope of the project was determined, the engineers met in groups of two and three to lay out further details of the architecture of the system.

After the initial meetings came the joint design work. Engineering then finalized the goals. Because of the scope of the project, this design phase took a few months.

Next was the sign-up phase, a tradition in the computer industry, where we explained the excitement, the importance, and the tight schedule of the project, then let everyone “sign up” for a long stretch of hard, focused work. You can’t force someone to excel; you’ve got to provide the opportunity and the encouragement and then let them excel.

Then the actual work began. We decided on the key systems and the key characteristics of the product. Next came the design sessions for each of the key systems. About a half dozen people were involved, typically three from Microsoft and three from IBM.

During the coding months, my job was to understand fully all of the parts of the system and to make sure that everything worked toward achieving our overall system goals. In a project this large, with this many people working on it, it’s easy for design elements to diverge. One project member might think that speed is more important than code size, and write his code that way. Another might think the opposite and write his code the other way. The result would be that neither goal is achieved. I participated in the design of each component to insure that the goals and design philosophies of the system’s architecture were consistent throughout the code. On most projects, this role can be fulfilled on a “part time” basis, leaving time for the chief designer to also get to write some code. Unfortunately, on the OS/2 project this position required a full time effort, leaving me little opportunity to write any real code.

MSJ: How did you divide up tasks on the project?

Letwin: The most efficient programming is done by one person. It’s a classic saying in the industry that “if one person can do it in one year, two people can do it in two years.” But in a project like OS/2, although one person might be able to do it in 8 man years, you can’t afford to wait 8 years, so you have to make it a multi-person project and have it take 30 man years. In order to reduce the inefficiency introduced by having multiple people on a project, it’s important to break the work up properly, and to have each piece of work be a one man project. This project had about 35 people on it.

The programmers worked on individual parts of the code, but they were organized into teams with a maximum of eight people each to facilitate coordinating their work. There was a test team, two teams of developers each headed by a senior engineer, a build team with four people, a test team with five people, and myself as the chief architect. This project was so complicated, especially since development work was simultaneously taking place at IBM in Boca Raton, Florida, that we needed a build team just to coordinate the sources, build the executable binaries, and otherwise bring organization to the physical aspects of software development. The test team, as its name implies, was responsible for the development of test cases, bug tracking, and performance measurement.

MSJ: What was the most difficult part of managing the project?

Letwin: This project’s very large staff added to the complexity of integrating changes made at the IBM locations and timing the development between the two sites. We had to be especially careful that any changes made didn’t affect other parts of the project. In the source code control system, for example, we split the source into about 200 modules, with modification tracking on each. We had a rule that you couldn’t add a change to a module until you’d proven that the change wouldn’t break anything. That way we retained a totally stable version. Without this rule, each engineer could have spent days looking for problems that were, in fact, introduced by another engineer.

MSJ: IBM and Microsoft, to put it mildly, have very different corporate cultures and philosophies. How did you mesh the two environments during the development of OS/2?

Letwin: First, whenever we arrived in Boca Raton, we rushed into the bathroom and changed into suits.

But seriously, there were some times when differences of opinions were frustrating. Normally each company builds its own products and calls all the shots. But in a joint development, compromises were necessary. IBM engineers were slowed down by a set of rules which are intended to bring stability to large IBM projects. This naturally caused some conflicts. IBM-ers undoubtedly felt that Microsoft engineers were “wild and crazy guys.”

MSJ: What parts of OS/2 would you do differently if you had the choice?

Letwin: A year ago it became clear we weren’t going to meet our schedules, and we had to go through a simplification procedure. For example, we took out named pipes, a form of inter-process communication to send information to another program (now part of the OS/2 LAN Manager). We’ll put that in another release of the product. Installable file systems were another victim. As a result, the hard disk file system still doesn’t perform as well as we’d all like. These features will be added later. Also, we now know the parts of the system which turned out to be bigger or slower than they should, or which in some other way were a bit disappointing. Naturally we’d give them additional attention. At the end of any project, there are always a few things you’d like to improve. And we will, in the next release.

MsJ: How does it feel to give up your product when it’s ready to go to market?

Letwin: At first, I felt relief when we got the product through testing and it went out the door. The last 20 percent is hard work. You just get tired of the product. The exciting stuff takes place in the earlier stages of the project. The last days are dealing with problem after problem—fixing bugs, making it smaller, making it faster, etc. You’ve worked on it so much there doesn't seem to be much change over the last few months. You’re tired and all you do is deal with problems. In my opinion, it’s the ability to keep working hard during the last part of a long project that separates the great people from the average. In any case, when you finally move on to something else, you feel a mixture of relief that it’s completed, excitement about your new project, and anxiety about how well your efforts will be received.

MSJ: What’s your philosophy of programming?

Letwin: Software is special at our level. Computer programming is 20 percent science, 60 percent engineering, and 20 percent art. The “art” element is the hardest to achieve, and it’s the hardest to explain. When engineers talk about the “elegance” of their work, people usually think that such elegance is non-functional: the engineers are just indulging themselves. This might be the case in mechanical or civil engineering since an elegant bridge carrys no more load than an inelegant one. But it isn’t so in advanced software development because mechanical engineering deals with physical objects and software engineering deals with information. Physical objects have properties independent of human perception, but information doesn’t. In other words, although a bridge is equally functional whether or not it’s elegant, information is much more useful when it’s organized in a clear, flexible and useable form—a form a programmer would call “elegant.” Bridge design is organized to meet just two goals—buildability and final function. Software is designed to meet those goals plus one more. It has to have minimal intellectual complexity and maximum flexibility so that it can be understood by the programmers who will maintain and upgrade it in the future.

GORDON LETWIN: THE CHALLENGE OF THE 286 SPEAKS HIS LANGUAGE

What attracted 34-year-old Gordon Letwin to computers in the late 1960s has also kept him in the forefront of programming today: an insatiable drive to overcome techincal obstacles.

“I’d read about computers in the late 1960s, that they were supposed to be super complicated. Computers held an abstract mystique. And I wanted to understand how that stuff worked,” he says. That was a tough goal at a time when the cheapest computers cost $100,000 and were locked behind glass. Letwin taught himself FORTRAN from a manual, without access to a computer to try it on. While in high school he took some courses at a small private technical college to get free time on the school’s computer.

Letwin studied physics at Purdue, but found he was more interested in getting computer time than in studying physics. Whenever he could, he’d spend his day breaking through the computer’s protective environments instead of studying physics. “Saying that there’s something that I can’t understand, or can’t access because I’m not initiated into some mystery is like waving a flag in front of a bull,” he says. He finally solved this conflict by changing his major to computer science.

A large part of the enjoyment in computing for Letwin is getting immediate results. He likens computers to pinball machines. “You get positive and negative reinforcement right away.” And, being “innately lazy,” he likes the idea of computers doing work for him.

Upon getting his Bachelor’s and Master’s degrees in computer science from Purdue, Letwin went to work for Wintek, a company run by one of his professors. He ended up bidding on a contract to supply Heathkit with a BASIC interpreter, assembler, and editor.

He later moved to Michigan and went to work at Heath but found he didn’t agree with its management’s direction. “I wasn’t happy with the direction of the company, which was run by ‘suits’ who didn’t know computers well but insisted on making the technical decisions anyway.” When his concerns with Heath’s approach at that time weren’t improving, he signed on with Microsoft, then in Albuquerque, New Mexico. “I came here because of Bill Gates,” says Letwin, who met Microsoft’s chairman during sales meetings at Heath.

Letwin became the first new employee when the firm relocated to Seattle about eight years ago. He started working on a BASIC compiler, then a Pascal compiler.

When he became tired of being a “compiler compiler,” he took advantage of his operating system experience to switch to the newly formed operating systems group, starting work on the IBM PC. “We thought the 8086 chip was the first processor powerful enough for general purpose desktop use. We had a vision of an office of the future. We knew that to realize this vision, we’d need a powerful operating system, much more sophisticated then those which were available at that time. Since the only way to insure its existence was to write it ourselves, we got into the operating system business.” The widespread acceptance of MS-DOS makes that statement Microsoft’s platform for its development of the single-user office automation operating system

Share

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

From the October 1983 issue of ROM Magazine

Interviewed by Peter Ellison

Roberta Williams is known to all of her followers and fans as the one who brought graphic adventures into their homes. Back in 1980, before the graphic adventure was born, she conceived the idea that an adventure should have pictures, so she and husband Ken, created “Mystery House” and formed the company Sierra-Online. Her next creation was a science fiction mystery called “Mission Asteroid” and after that she created the first computer adventure game with color, “The Wizard and the Princess”.

This changed the industry, with everyone now expecting everything to be in color. The next adventure took a year to complete and is labeled as an epic. “Time Zone” has more than 1300 full-color computer-generated images compacted onto 12 disk sides. Heralded as the first expert-level adventure with graphics, the estimated time for completing “Time Zone” is an incredible six to twelve months.

Her next adventure, “Dark Crystal”, was a first, because it was the first to be based on a motion picture. Roberta then set herself to the challenge of producing an adventure game that used the full potential of today’s computers. With the release of “King’s Quest” she has done it. With 3-D color graphics and animation that rival the best arcade games, the new adventure brings each character to life with a large vocabulary and challenging puzzles. Although this is available only for the IBM PC with 128K, the Atari can play it with the “ATR 8000”.

While her husband runs the company as President and Chief Executive Officer, Roberta works as Product Development and Creative Director with input into all the creative areas of the company. In addition, she designs her own games. I was able to talk with her on August 13th and had quite an enjoyable interview which was as follows.

Q. When did you first become interested in the writing of adventure games for the computer?

A. It was in the winter of 1980.

Q. Did you ever expect “Mystery House” to become such a big hit?

A. I knew people would like it in those days because it was really different and new, but I didn’t really think it would start a company the way it did.

Q. After writing “Mission Asteroid” and “Wizard and the Princess” you came out with the massive program, “Time Zone”. What caused you to write such a huge game?

A. It was because in those days I played a lot of adventure games and I was always disappointed when they ended. I’ve always been a fan of the epic movie and if I really like something I want it to go on. I really liked adventure games and I wanted them to go on and on, so I thought maybe I wasn’t the only one who was like this. I also wanted to leave my mark in this world, so I wanted to write the adventure game that would seemingly go on and on. It does end, of course, but it does go on for quite a long time. Some people like it, but it’s not a best seller type because of the time required to complete it. It’s for people who want to solve the ultimate adventure, those that are expert players.

Q. How long did it take you to complete “Time Zone”?

A. It took about six months.

Q. What inspired you to write an adventure after the motion picture, “The Dark Crystal”?

A. They called us and said they would like me to do an adventure game based on the movie . I think one of the reasons was because they were kind of venturing into new ground as far as this movie goes. They wanted to do whatever they could to promote it, plus the fellow who seeked us out had played my adventure games before and they called us and that is why we did it.

Q. Did you feel limited in the fact that you were basing it on something fixed, limiting your ability to be creative with it?

A. Yes, and I didn’t really like doing it that way because I like doing my own stories.

Q. Your latest adventure “King’s Quest” features some great three dimensional animation, do you feel this will become a standard for all adventure games?

A. Its hard to say a standard because look at Infocom, no graphics at all, and they have great games. Not a standard for them but for graphic adventure games, yes. It would have to be, but not immediately, because there are only a few computers that can run it because it takes 128K and so it really isn’t cost effective. Plus it takes a long time to program something like that. It took us over a year and a half. We did some inventing and the inventing process takes quite a long time. It will be at least a year to a year and a half before you see something that looks like it from anybody else.

Q. I noticed that every adventure that you write is entirely different from the one before. Why is this?

A. Because it would be boring if they were all on the same topic.

Q. Have you ever thought of writing a sequel to any of your games?

A. Yes, because this week I’ll be starting on the sequel to King’s Quest.

Q. Where do you get most of your creative ideas for your games?

A. In the old days I would just sit down and think of a story and it would just go from there. I’d also get a lot of ideas out of books. Nowadays I seem to concentrate more on a certain type of subject, so I will get a book or books on that subject to learn about it and anything that I like I’ll take notes, etc.

Q. What game are you working on at this time?

A. I’m just finishing up “Mickey’s Space Adventure” as we now have Disney products. It doesn’t look like King’s Quest, its like the old style adventure game, but it will have some animation in it.

Q. In what direction do you see adventure games going?

A. I would like to think I have some say on how adventure games do go. I’d like to keep ahead of everyone else and if that were true I would kind of set the standard for graphic adventure games. The graphic adventure games are probably going to go more heavily into animation and sound and eventually look like a real cartoonist type of thing.

Q. What type of adventure do you most enjoy writing?

A. Fantasy or fairy tales. I would like to try and write some mystery and suspense, and would really like to write a scary adventure game. Scary, not in the sense of gory, but suspenseful, similar to the Alfred Hitchcock style. I like writing about the subjects that I have already written about. I’d also like to do a western at some time.

Q. How many of you are usually involved in one program?

A. Its myself as the writer/designer and project leader and depending on the size of the project is how many people we have. On King’s Quest we had three programmers and three graphic artists, making a total of seven working on the same program.

Q. How long is a program tested before it is shipped?

A. It all depends on the size of the program. We have a department called the “Quality Assurance” department or “QS” that whenever we have a program that is more or less done, the programmer gives it to them and they play with it until they are satisfied. Until they approve it, we can’t ship it.

Q. What does Sierra have planned for the future?

A. The Disney products will be coming out at Christmas. We have four of those including the one I did, “Mickey’s Space Adventure”. The other three are “ Goofy ‘s Word Factory”, “Donald Duck’s Playground” and an adventure game called, “Winnie the Pooh and the Hundred Acre Woods”. We also have “Grog’s Revenge”, the sequel to “B.C.’s Quest for Tires”.

Q. What do you do in you free time?

A. We live right near Fresno, California and because we live in the mountains, on Saturdays Ken and I go down to Fresno to get away from the company. We go to a lot of movies, seeing almost every movie that has ever been out. We like to eat out and we have a boat that we use a lot in the summer. In the winter we enjoy skiing in the nearby mountains.

Share

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

The Company

bitCards, Inc. was founded in September of 1983. According to the records from the Florida Department of State, the company was dissolved in October 1991 because the company didn’t file the annual report. None of the company’s paperwork was scanned in. Unfortunately, this is the common with companies from that generation.

Color Computer Magazine mentioned another company in relation to bitCards: Chartscan Data, Inc. Compute notes that “Chartscan Data is producing bitCards, text and graphic adventures designed as holiday gifts.” This company had the same address as the ad at the top of this post, but I couldn’t find any information about it.

The Game

Here is a detailed description of the game from the January 1985 issue of Transactor Magazine:

A CHRISTMAS ADVENTURE

A Very Special Program From BITCARDS INC.

Can be Custom-Programmed For Holiday Gift-Giving

BilCards Inc. proudly announces the release of a unique adventure program written especially for the upcoming holiday season. Set in and around Santa Claus’ ice-castle at the North Pole, the player will discover at the outset of the adventure that Santa has mysteriously disappeared. With Christmas only hours away, his annual gift-delivery run is in grave jeopardy! The player’s mission is clear: Explore the many rooms of the castle and its outbuildings, unravel the mystery of Santa’s disappearance, find and free him, and thus ‘save’ Christmas.

Care has been taken in the scripting and design of the program to make it appealing to a broad range of micro-users. A Christmas Adventure is more than a challenging ‘puzzle’; it is, above all, a holiday entertainment filled with fun and surprises: The unexpected appearance of an errant Pacman, for example, munching his way across the screen; and the computer’s response, “Gel out of here dummy, you’re in the wrong game!”

An extensive ‘intelligent’ HELP utility ensures that players of all skill levels will be able to proceed through the adventure, so that they don’t miss any of the fun.

A Christmas Adventure CAN ALSO BE CUSTOM-PROGRAMMED!

Anticipating that many people may wish to purchase additional copies of A Christmas Adventure as holiday gifts, BitCards is simultaneously releasing an enhanced version of the program, (ACA. C), designed specifically for this purpose. A utility provided with this version allows the buyer to customize the program, such that the recipient will discover several references to himself as he progresses through the adventure. When the player first activates Santa’s computer, for example, he or she will be called upon by name to help solve the mystery of Santa’s disappearance. And later, part of a note will be found in the reindeer’s stable, praising the player’s skills and character, and providing Santa with his or her home phone number. Through such personal references, the player will come to feel that he is an integral part of the adventure itself.

The customization routine also allows the sender to incorporate a personal holiday greeting into the culminating sequence of the adventure. Thus, the programmable version of A Christmas Adventure enables the buyer to produce a personalized software gift-and-greeting-card all-in-one. (BitCards will do the customization of the program to the customer’s specifications if he lacks the appropriate computer to do it himself.)

$14.95 - Adventure alone (ACA.N)

$16.95 - Adventure + customization routines (ACA.C)

$17.95 - Customized version prepared by vendor

($US. add $2.25 shipping/handling - all versions)

Available on disk for Commodore-64 and for Apple II family and compatibles (48k RAM required). Apple version has over 20 pages of superb hi-res graphics including animation and zoom sequences, C-64 version is mainly text.

Robert Edelstein wrote about the bitCards game for the February issue of Twilight Zone:

THE GREAT SLEIGH ROBERY (sic)

Once upon a time there was a man named Santa Claus. No, no, forget it. Introductions that simple harken back to a time long before the computer’s coming-of-age. These days it would probably read: Enter— Once Upon A Time, Select Sequence 1 or 2.

But BitCards Incorporated has taken a step to close still further the gap between computer mechanics and the joy of growing up. They’ve just introduced their new program, A Christmas Adventure, which should be a bestseller this holiday season. Designed as a text-and-graphics entertainment, the program is set in and around the North Pole ice castle of ol’ Saint Nick.

In the game’s scenario, Santa has mysteriously disappeared, and the player must explore the castle and its outbuildings to find him. Elves, tools, passwords, and reindeer may help or stand in your way as you try to save Christmas.

An extensive Help utility aids the quest and an easy-to-use customization, a set of personal messages that can be applied to the program, is available, making the adventure the perfect Christmas gift for the junior hacker closest to your heart.

It’s available for Apple II and compatibles (64K requires), and Commodore-64 versions for $24.95. For orders call toll-free (800) 821-5226, extension 432. But hurry — Christmas depends on it.

The December 1983 issue of Compute had a less detailed summary, but listed all the systems it ran on:

Want to see what the game looked like? You can play the Apple II version of the game here.

Have you ever played a bitCards’s game? Do you know anything about its history? Tell us about it in the comments below.

Share

I feel horrible about the lack of articles +. I’ve got to get a couple done before the end of the month. Fingers crossed.

Here are the options for this month:

Read more

From the November/December 1976 issue of People's Computer Company magazine

[CAFTP Editor’s note: This “interview” took place two years before Raskin was hired by Apple and three years before he started the Macintosh project.]

Dr. Dobb Tells All

An interview with Dr. Hiram Carmichael Dobb, Titular head of Dr. Dobb’s Journal of you know the rest.

by Jef Raskin

Introduction

We were invited to the elusive Dr. Dobb’s residence high on a stone bluff overlooking the pacific ocean in the small town of Polio Del Mar, California.

Polio Del Mar is said to have the highest number of computers per family of any place in the world as well as having a sewage treatment plant that ranks with any in the state. Dr. Dobb himself looks older and acts younger than he is. He says that is easier than looking younger and acting older than he is. We found such wisdom commonplace as we began our interview.

US: Dr. Dobb, so far you have managed to evade any public exposure or interviews, and we are honored that you have agreed to our request. May we ask why?

Dr. Dobb: Yes.

US: Why?

Dr. Dobb: Nobody else asked.

US: When did you start playing with computers? We hear you have been doing it for a long time.

Dr. Dobb: Where do people hear such things? But it’s true, I started out in 1900, and, buster, that’s a long time ago.

US: But the first computers weren’t built until about 1946 or so!

Dr. Dobb: Did you come here to tell me history or to interview me?

US: But you were born in 1900!

Dr. Dobb: That’s what I said: “I started out in 1900” and you interrupted.

US: Sorry.

Dr. Dobb: As I told Johnny . . .

US: You mean Von Neumann?

Dr. Dobb: You do keep interrupting. You think you have some kind of priority? Like I was saying I told Johnny: “These computer thingies won’t amount to much until you can have one in every garage, and a chicken in every pot.” That phrase became famous, as you will remember.

US: We do remember something like that. Why, to change the subject, have you settled in Polio Del Mar?

Dr. Dobb: This town has the highest number of computers per square head.

US: How did you come to be associated with the journal of which you are the titular head?

Dr. Dobb: You know, I like that title “Titular head,” it does something for my image. But, actually, they had never heard of me when they named the journal.

US: No?

Dr. Dobb: It was named after my cousin Hilary Cynthia Dobb.

US: Hilary Cynthia Dobb?

Dr. Dobb: You do seem to have a case of echolalia! She is the expert for whom the journal is named. By the way, how much should each issue of Byte cost?

US: Tell us more about Dr. Hilary Dobb.

Dr. Dobb: Answer my question, I asked it first.

US: How should we know?

Dr. Dobb: Eight bits!

With this joke Dr. Dobb cracked up and was laughing so hard that we couldn’t get anything coherent out of him. Just then a dignified woman came down the stairs. Her eyes seemed to look right through us, and she wore a brooch of pure silicon, its jet blackness gleaming against her green dress. Since she is also Dr. Dobb you will have to figure out which of them is speaking from context.

Dr. Dobb: Oh. Hiram. I bet I know what joke you just told.

Dr. Dobb: (still incoherent)

US: Dr. Dobb, we have just been told that it is *you* that Dr. Dobb’s journal is named after.

Dr. Dobb: That may be the ease. Some other things have been named after me.

US: Yes?

Dr Dobb: Did you know that the color molded into IC’s with plastic cases is known as “Dobb’s Black” and that I invented the Dobb’s code which is used by many electronic hackers?

US: (impressed) No, we didn’t.

Dr. Dobb: You are familiar with the “ten” codes used by the CB people.

US: Slightly.

Dr. Dobb: You know 10-20 means “location” and so on. Well to save engineers and computer scientists time I set up a lot of codes so that they could talk more easily and snow anybody who might be listening.

US: Could you give us, and our readers some examples?

Dr. Dobb: Surely: The code for four 2-input nand gates is “zero-zero” or the code for a J-K master-slave flip flop is “seventy one.”

US: And do you prefix these numbers with ten like the Hams and the CBers do?

Dr Dobb: No. I use “seventy four.” And those are called, properly, the Dobb code.

Dr. Dobb: (still incoherent).

Dr. Dobb: And to keep the military people happy I gave them their own code.

US: Can we guess? They use “fifty four?”

Dr. Dobb: For a magazine writer you seem awfully bright.

US: (blushing) Thank you.

Dr. Dobb: Have you been doing interviews for long?

US: About four or five years now.

Dr. Dobb: And how did you get to specialize in computer reporting?

US: It comes from an early interest in stopwatches. When I was four years old my aunt Hilda mere gave me this stopwatch, and I began to time everything...hey, who is doing the interview?

Dr. Dobb: (sweetly) You are. What happened with the stopwatch?

US: I started to become an efficiency expert around the house, and compared different ways of washing dishes. . . you got me doing it again.

Dr. Dobb: Sorry, let me ask you a question.

US: O.K.

Dr. Dobb: (still incoherent)

Dr. Dobb: Where did you go to school?

US: The Wisconsin State School of journalism. And where did you go to school?

Dr. Dobb: Wait a second. I’m doing the interviewing.

US: ?

Dr. Dobb: Ha! Ran a 7404 on you!

US: A 7404?

Dr. Dobb: Ran you through a hex inverter, turned the tables. You got to learn the codes if you want to talk to hackers.

US: Can you teach us a few more?

Dr. Dobb: Sure. What do you think we mean when we say that a couple is all 7471?

US: Tell us.

Dr Dobb: It means you can’t tell who is in control, a perpetual master-slave flip flop relationship. When you’re sure you say that you’re 7430. And that’s an input positive nand gate, and that’s pretty positive. To go into your house is to “open a 74100” you know, a bistable latch. A woman (or a man for that matter) who worries about their age is a 7490. A decade counter. And my son, James, we call a 7488 since he likes the library so much. He’s got a read-only memory.

US: It seems that almost any situation can be represented by one of your 74-codes, Dr. Dobb.

Dr. Dobb: Thank you. I hope I’ve made a contribution to human communication, liven so obscure situation as finding a snake when you come in through the fence has a 74 code.

US: Really?

Dr Dobb: Sure. It’s a 7480.

US: A 7480?

Dr. Dobb: A Gated Full Adder!

At this joke Dr. Dobb went into pleasant peals of laughter, and we found ourselves with two incoherent Dr. Dobbs. We decided to call it a day and make our way back from Polio Del Mar. We would be back another day to continue our interview with the Drs. Dobb. Or maybe not.

About the author; Jef Raskin lives in Polio Del Mar, where he is at the Polio Del Mar Doctor’s Hospital, where a team of experts are trying to get his tongue out of his cheek.

Share

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

I’m a little behind this month, but I hope to catch up soon.

(CAFTP Editor’s note: Not sure what this games to do with computer. If you have the answer, let me know in the comments.)

I hope you enjoyed the comics.

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

From the January/February 1984 issue of CP/M Review magazine

Conversation with a Pioneer

by Mike Prezbindowski

William Godbout is the founder and Chief Executive Officer of the CompuPro Corporation. CompuPro is one of the oldest computer companies in our uncertain industry, and Bill relates to us some of his background and business philosophy that has enabled them to survive, in fact flourish since 1973. CompuPro evolved from some Godbout companies that manufactured kits and S-100 components to a corporation that offers an impressive line of complete computer systems. They haven’t abandoned S100 or board products, in fact they are offering STD Bus products and are considering new bus products. A large segment of their market is industrial based and they have large OEM accounts in the United States and Europe. You may be using some CompuPro products and not know it. While not an overnight giant, they have been continually building a strong base of support and have consistently offered products known for their reliability. Mr. Godbout has been a force in the development of the microcomputer industry.

CP/M REVIEW: Bill why did you start your own company?

Godbout: I had to have a job! Something to keep me off the streets and out of jails. Actually, I have been involved with computers in one way or another since college.

CP/M REVIEW: What did you do after college?

Godbout: I was recruited by IBM while in undergraduate school at MIT. At IBM I participated in the development of such machines as the 704’s, 705’s and 709’s and worked on the team that did the “90” and the “STRETCH” machine. (The “STRETCH” was so named because it stretched the capability and technology of their company.) I was then recalled to active duty with the Army diming the Berlin crisis.

CP/M REVIEW: Since you’re from the East Coast, why did you start your company in the Bay Area?

Godbout: I had been to San Francisco several times and it looked like a nice place to spend a couple of years. Also, the opportunity arose to take over a foundering company as a crisis manager for a period of 24 months. I started as manager of systems development and left 13 months later as general manager.

CP/M REVIEW: Then you have had business training also?

Godbout: I don’t want to say I’m just an engineer, I’m not just a “technocrat.” While at IBM I had extensive management training. When you go to work for IBM, your management training starts the day before you go to work for them, when you are selected for employment and accept their offer. You get, directly and indirectly, a good orientation. IBM is a very well managed company. If I were to work for someone else, my first choice would be IBM.

CP/M REVIEW: IBM seems to be a very conservative company. Only in the past 2 years have they increased their presence with the marketing of the Personal Computer. In the small computer market CompuPro seems to be a bit more conservative than other companies. Is this because of your IBM background?

Godbout: IBM is not as conservative as you think, they have gone out on a limb many times while pursuing various market segments. The “STRETCH” machine, like many of the products they brought out, was great for its day and even today would be no slouch. Many of the things we take for granted were way out in the ozone back then; interrupts, memory management, multi-programming, dual CPU’s, all came from that project. The IBM 7030 (a 72-bit 200 nanosecond machine) for its day, was a marvel; it was a bigger leap forward for technology than a “STRETCH” to a CRAY-1 is today. It was the first of IBM’s second generation computers. They started the project in 1955. It was re-designed in ’58 and got out the door in late 1960. 1 think they built six of them. Everything was being done with dual triode tubes and IBM had to design and manufacture its own transistors in order to build this machine, there was semiconductor core memory with interleaved memory cycles because the cycle time was only 2.2 microseconds. But they brought it down to 2.0 and finally 1.8 microseconds. The same memory boxes were used later on the 7090. All of the packaging concepts for the 7000 series came out of the “STRETCH” project.

Then RCA announced they had 5 billion dollars to commit to the computer business from the monstrous sale of TV sets in the mid to late fifties. RCA had this big cash bubble and the computer business looked like the way to go. At the time RCA announced its intent to throw this amount of money into computing, IBM had I not even had a billion dollar year. That takes guts and entrepreneurial spirit. It takes real management to pull off something like that. I admire IBM and think highly of them as an employer, an entity, and as a competitor. Because at some point we are going to come head to head, I hope.

CP/M REVIEW: Do you think there is room in the marketplace for all the now existing computer companies?

Godbout: Obviously, IBM and the others are not all things for all people. There is a nice hole where IBM has been spectacularly unsuccessful. IBM’s share of the low end minicomputer market is only 4 percent compared to 80 percent on mainframes.

CP/M REVIEW: Does the background and experience of CompuPro give you any advantages in this area of the market?

Godbout: While other manufacturers such as WANG, IBM and DEC have entered by the back door into the micro fray simply by putting CP/M onto existing machines previously dedicated to word processing, we at CompuPro have historically only offered CP/M on our equipment. This gives us a definite advantage.

CP/M REVIEW: CompuPro’ s recent emphasis on the business market will require a good service network. Has the ground work been completed in this area?

Godbout: We have an agreement with XEROX called AMERICARE, for CompuPro system level products. This opens up the market for our S-100 and non-S-100 systems, and offers new potential in the business and scientific markets.

CP/M REVIEW: How is XEROX gearing up for this task?

Godbout: XEROX has been sending their people to us for technical training on repair of CompuPro machines. We have also trained their instructors. They have assigned 300 to 400 technicians to our account which means that there will be 3 to 4 trained technicians at each XEROX service center. We do not want them to go to a customer’s site and wave soldering irons around. Each location will have several different sets of spares and will only do modular replacement to minimize down time, not component replacement. With the introduction of the CompuPro 10 aimed squarely at the business market, it becomes essential that we bundle a service package with that system. This feature has been added without increasing the overall system price on both our S-100 models and Model 10.

CP/M REVIEW: Do you plan to stay with Digital Research in the near future, with the popularity of UNIX becoming so widespread?

Godbout: We have been asked numerous times why we don’t support UNIX on the 68000. We have looked at it and have not found any implementation that we liked; we do not feel that the 68000 has enough horsepower to handle a true multi-user UNIX configuration. Bell Labs currently has a CompuPro system prototype using the National 16032 CPU and is porting UNIX for us. We will be showing it at the 1984 NCC.

CP/M REVIEW: Will the addition of UNIX affect your relationship with Digital Research ?

Godbout: DRI has got their act together and has become a real force in the marketplace. Creative Strategies, a marketing research company has predicted that by 1987, 49% of the market will be using UNIX and 37% Concurrent CP/M. I think we will still have an excellent relationship with DRI.

CP/M REVIEW: How has CompuPro been doing as a company in the marketplace?

Godbout: The market share of CompuPro today is 1.3% of the total according to a survey completed by Data Solutions. This tallys closely with other market surveys. This figure puts us ahead of such companies as Alpha Micro, Fortune and Franklin. Where we really show up well is in surveys that show “brands under consideration.” There we show a 4% share. These are surveys using open ended questions and not mentioning the Model 10 which hadn’t been announced at the time, only CP/M S-100 systems. This puts CompuPro in direct comparison with DEC and other major manufacturers of computers smaller than mainframes.

We are pleasantly surprised at the statistical significance. We expect the model 68K, “10” and 16032 to cause quite a commotion. We do want to say for the record that the Japanese home market is safe at this time; we have no immediate plans to sell in Japan.

CP/M REVIEW: How are your products being marketed in the United States ?

Godbout: We have a strong dealer network with close support. A strong dealer network is essential if you are to move from “Smalltown, Iowa,” to “Backwoods, Maine.” You must be in striking range of a dealer that will provide service, sales and support--with a smile.

CP/M REVIEW: I understand CompuPro had a role in establishing the IEEE 696 standard, could you tell us about that?

Godbout: The Chairman has always been an employee of CompuPro or an affiliate. George Morrow was designing for us when it started.

I personally did not have the time to be directly involved. Mark Garetz was chairing when the standard was completed; in fact, he typeset the whole thing.

CP/M REVIEW: Did CompuPro’ s involvement in the process directly benefit the company?

Godbout: If you mean did we control the steering of the committee, NO! The committee was put together to hammer out a consensus. The result is definitely not a CompuPro standard. I got a few things I wanted as did every manufacturer that reviewed the specs. But no, I was all for making the bus active low so when you let go of the bus nothing would happen. The DMA transfers, Ithaca Audio did that, Marinchip did the 16-bit memory and peripheral swap idea. Howard Fullmer from Parasitic Engineering had a lot of good input.

A funny sidelight to that. Before the S-100 subcommittee was formed a physician named Bill Shander and an instructor from Diablo Valley College decided in 1976 to have a meeting of manufacturers and end users. IMSAI, Altair and Processor Technology, to name a few, didn’t bother to send representatives. All the attendees are still in business today. The non-attendees were either too busy or couldn’t be bothered.

CP/M REVIEW: What are the most significant markets for CompuPro?

Godbout: S-100 products continue to be a major sales item for us. Mullen Electronics has become a partially-owned affiliate of CompuPro and is handling much of our STD bus market. Mullen is mainly involved in the industrial marketplace. They came under our wing after an unsuccessful venture into the Radio Shack market.

CP/M REVIEW: Is the STD Bus product line a new venture for CompuPro?

Godbout: We have been supplying memory boards and CPUs for the STD bus since day one. Rick Kalish, a member of the IEEE committee working on standardization, works for us. We will continue to support this market and Vector Electronics will be involved with us. We do not plan to drop out of the industrial market-we plan to get bigger.

CP/M REVIEW: You mentioned Vector Electronics involvement in this venture. What is the relationship between Vector and CompuPro?

Godbout: We have just completed an agreement with Vector Electronics to provide second sourcing of CompuPro products. Vector is a well-established company with many years of experience in the manufacture and packaging of electronic products. They have a large industrial distribution network in place and serve pegboard customers as well as the Fortune 500 companies such as Bell Labs. Any firm using electronics is probably familiar with the Vector name.

The second source market is aimed at the third-tier products where the computer is actually a subsystem and the end product may have a design cycle of 18 to 20 years. This allows CompuPro to maintain its leading edge position with regard to technology while assuring manufacturers that products they design today will be available tomorrow. As CompuPro products are phased out of production, Vector will pick them up if the market warrants. British Telecom is one example; they use our products in their stock quote system which was years in development. They just ordered 1000 boards with more to come. The same distributor in the U.K. will serve as second source for Vector at the time we switch manufacturers.

CP/M REVIEW: Is Vector capable of maintaining the level of quality you build into your products?

Godbout: Vector is a fully integrated manufacturer, from laminates through punch, plate, drilling and soldering. The Vector S-100 motherboard is a Godbout design built under license by Vector. We have the utmost confidence that the level of quality inherent in CompuPro products will be maintained by Vector.

CP/M REVIEW: How long have CompuPro and Vector enjoyed this working relationship?

Godbout: Vector has had a good working relationship with Godbout for years. There is a high level of technology transfer between the two companies. Their engineers are on a first-name basis with ours and communicate regularly. A channel for technology exchange exists and is used frequently, and is encouraged.

CP/M REVIEW: Will the Vector computer line continue to grow in the future or will it be limited to a few products?

Godbout: Vector and CompuPro will move ahead together, as CompuPro moves out of one product line Vector will pick it up as the market warrants. CompuPro is the first company to offer second sourcing in the micro business.

CP/M REVIEW: What does the future hold for Bill Godbout and CompuPro?

Godbout: Just over the horizon at the other end of the spectrum is the 32-bit machine. It poses a problem. Take, for example, the NS 16032, the CPU has a 16-bit bus and is double pipelined. Compare the Intel 8086 and 8088, one has a 16-bit bus and the other an 8-bit bus. The 8088 shows remarkably similar performance to the 8086 despite the smaller data path. This is due to its pipelined architecture. The 16032 benefits similarly and should not lose much when compared to a full 32-bit data bus.

We are currently working with Intel to clean up some things on the apx-386. It is a full 32-bit virtual machine that is upward compatible with its 8086-based predecessors except the 64K memory segment limitation has been removed.

CP/M REVIEW: CompuPro has been mainly an S-100 company. How will you develop 32-bit machines for the S-100?

Godbout: The S-100 concept works fine for 8- and 16-bit, but doesn’t hold up to the 32-bit processors. The obvious temptation is to multiplex some of the address lines to gain the needed extra data lines, but the reduction in bandwidth makes that an unacceptable technique. Probably, 32 bits is the point where we will have break with S-100 and move to a VME-like bus. There currently is no VME bus standard and we may get involved in that area.

During grad school at Cal Tech, Tony Pietsch published in the proceedings of the IEEE a proposal called the PI bus. The VME is a takeoff of this. The thing that fires my rockets is that they didn’t even acknowledge the source. It may be in their ignorance they didn’t know where it came from, but the marked similarities are too great for the PI bus not to have been the lineal progenitor of VME. It sure would not have hurt anybody to acknowledge Pietsch’s contribution which was put into the public domain.

CP/M REVIEW: Most of the more sophisticated buses seem to drag the performance of their CPU’s down with a lot of protocol. Will the PI bus also do this?

Godbout: The VME bus does restrict the computer’s overall performance, but the PI bus, on the other hand, allows maximum performance.

CP/M REVIEW: Your philosophy regarding mixing CPU’s in an S-100 system is novel and useful. Will this also be carried to your 32-bit machines?

Godbout: We will make available some sort of 8- 16- to 32-bit interface to allow slavery of these processors in future 32-bit machines, it may be through a converter from an S-100 to a future bus.

CP/M REVIEW: CompuPro has not jumped into the networking market. Are you planning to, and with what type of protocol?

Godbout: We plan to offer several types of networking options. There is currently chaos out there. We are looking seriously at Arcnet as it is a proven technique with an existing chip set. The CompuPro 10 has a SASI interface in the back and there are several SASI to “garbagenet” interfaces already are on the market. We will be making a product for the Model 10 that will be a hardware/ software package. It will have two interesting ends. The obvious is the Model 10 end and the other will go to an IBM PC, S-100 or another CompuPro 10. You can do any combination or permutation you want.

CP/M REVIEW: The choice of Datapoint’s Arcnet bucks the tide of support that the other manufacturers are giving Ethernet. Why do you think Arcnet is better?

Godbout: It turns out that Arcnet provides better bandwidth and overall system performance than Ethernet. The reason for that is there is an awful lot of system overhead associated with Ethernet. Although Arcnet has half the stated bandwidth, it runs at least as fast or faster in a comparable context. Sure, you’re shoveling data at 5 megabits instead of 10 megabits per second, but the overhead on each of the nodes is so significantly less for Arcnet that the overall throughput is of a networked system is much greater. With Ethernet, the data coming through the node slows down processing on the node while it figures out if any of the data should be received or not. I find this unacceptable. At this point, Arcnet is the front runner and we are looking at several others.

CP/M REVIEW: Does CompuPro have a long range plan to help assure its continued growth and survival?

Godbout: We are definitely a growth company, not a hit-and-run company. Ten years ago we started with Compukit and MusicKit. We do not intend to rush into the public market with a take-the-money-and run business plan. We would rather establish a long-term business. We are definitely in it for the long haul.

We are not ruling outgoing public, we just aren’t to the point where we have optimized profit and timing yet. Why grab a few 10’s of millions when in five years we might knock off a couple of billion? We are fortunate that the company is solid and stable. We have had steady planned growth. I think it is obvious, if you look at our moves, that our products didn’t just happen. Several business analysts have looked at our advertising and our products, and have noticed that over the past ten years the planned mix of products pulled together with phased growth.

CP/M REVIEW: Is there any outside venture money in CompuPro?

Godbout: We have no outside money, and therefore no pressure from venture capitalists who would require a money turnaround in five years. The Godbout Company is the venture company for CompuPro. The Godbout Company is involved in with many things--some not related to Electronics-mostly long term, such as an automated test equipment company and software companies. We do not intend to abandon the S-100; it’s becoming more like the IBM stuff-well rung out and very solid. We find that there are a lot of companies just now considering designing microprocessors into their control systems. We who are on the cutting edge of technology sometimes don’t realize how industry works out there. They have barely caught up with the Z80. Look around at the products coming out now using Z80’s and 68000’s, machine tools and automotive applications. The S-100 still offers a lot of flexibility. There is a lot of industrial interest from such areas as the Army, Navy and Air Force, and a full 50% of our business comes from OEM’s and component accounts, a continuing growth market.

CP/M REVIEW: Earlier you referred to European customers. Has CompuPro established overseas distribution?

Godbout: We have Comcen Technology in Wales, and they have offices in London as well. They are our European distributors just as Byte Industries is our United States distributor. We have also established a Distributor in Australia called Automation Stratham.

CP/M REVIEW: Is the S-100 still performing well from the product marketing point of view?

Godbout: It is still ahead of projections in terms of product growth. The S-100 is really just starting to come into its own. The new products that promise more power and speed will only add to the growth potential of an established design, now that the industry is recognizing it as a stable and rung out standard.

Share

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

You may have noticed that I’m a little behind in regular and + posts. That’s because it’s gardening time and I’m filling in for a friend while she recovers from surgery. Please be patient. I hope to get a couple of + posts done before the end of the month.

With that in mind, here are this month’s choices:

Read more

The Company

According to opencorporates, C Source, Inc was incorporated on October 17th, 1983. Gene W. Brown was the president of the company, based on an article in the February 19, 1985 issue of PC Magazine. Tom Hogan worked as both a senior programmer and Marketing Vice President. When I was researching this post, I found a couple of letters to the editor that Hogan wrote about C Source products. Hogan wrote on his LinkedIn, “I also helped code some of the Basic_C Library and some other products. C Source was a garage startup.”

The company was dissolved on May 19, 1996.

The Product

I won’t lie, this ad was a pain in the butt to research. My search turned up thousands of unrelated results. I was able to sift through and find a couple of things.

What was BASIC_C? I found a good summary in an ad from PC Brand:

If you’re getting the message that switching from BASIC to C would be prudent, you’re about to discover that it’s back to basics of a different sort. BASIC is fat with hidden functions that stripped down C just doesn’t have.

Gone are all those handy string manipulators like LEFTS. MIDS. STRINGS, etc (although our library offerings add them back). In C, when you reach for even simple invocations like INPUT or PRINT AS, X% - well, sorry to disappoint, but underlying such expressions in BASIC are bulging macros which C cannot have if it is to keep its slim profile.

But now comes BASIC-C and all your old favorites are back. Someone has written the full set of C functions to mimic BASIC’s vocabulary, from ABS to WRITE. Over 80 routines to open and close files, “field” file buffers, convert their contents from and to strings (the CV? and MK? series), peek and poke, print using, clear screen, “instr”, on error goto...they’re all there. Some have reworked names and syntax to suit C, but all are written as one-to-one functional equivalents to the familiar features of BASIC. And they are documented one to a page in alphabetical sequence like the Microsoft manual for added familiarity.

So with BASIC-C, when you’re thinking INPUT, go ahead. Use it. Or LPRINT or LOCATE or INKEY. But without BASIC-C, you will find that every line of code plunges you back in the C texts to figure out how to write it. Someday you’ll want to, but for now, BASIC-C will start you programming quickly at the statement level so that you can concentrate on C’s larger concepts.

There’s a bonus: an unusually well written manual with a first rate chapter comparing how BASIC and C go about their tasks Without question, BASIC-C will ease your transition to C.

Happily, I was able to find a review of BASIC_C in the October 1984 issue of PC Tech Journal. Ernest Tello wrote an article for this issue entitled “BASIC To C” where he examined two tools developers were using to convert their BASIC code to C. Here is the BASIC_C section:

C Source Inc. has developed a product intended specifically for programmers with a working knowledge of BASIC who want to develop programming ability with the C language. It is a library for use with several C compilers on the IBM PC (currently Lattice, DeSmet, and Computer Innovations are supported) that implements many of the familiar BASIC statements and structures in the C environment. The purpose of this library is to ease the process of learning C for BASIC programmers, and to aid in the conversion of BASIC programs to C. It will not, however, enable a BASIC programmer to produce C programs without any knowledge of the C language. The BASIC_C Library manual is written with the C novice in mind and is one of the better introductions to C available, particularly for those familiar with the details of BASIC.

Version 1.0 of BASIC_C has about 75 functions in the library. Table 1 lists the corresponding BASIC and BASIC_C functions. No math functions are included. The reason for this, according to a brochure issued by C Source, is that math functions belong in a standard library, ‘”and only the Lattice/Microsoft C compiler does not have them.” Version 2.12 of the Lattice compiler, which includes math functions, is now available.

For writing programs that do not require trig, log, exponential, or random functions, however, the BASIC_C Library is a welcome addition to the C environment for both the experienced C programmer and the novice. A loan payment calculation program serves as an example of a BASIC program (listing 1) translated to C (listing 2) using the BASIC_C Library. The example illustrates the conversion of a GOSUB into externally defined functions. It does not use any arrays, pointers, or the COLOR function.

Generally speaking, documentation for BASIC_C helps a BASIC programmer who has studied C syntax translate programs into C. Debugging these programs, however, is another matter. A programmer accustomed to BASIC will find that a new set of debugging skills is needed in the C environment. Also, C programs that are written in the Style of the examples, virtual line-by-line translations from BASIC, are valuable as exercises in making the change from BASIC, but generally are not examples of good programming practices in C. For this reason, the gain in efficiency and speed over compiled BASIC may not be as great as anticipated. The good performance of C is due in part to its concise syntax. Using C to mimic BASIC does not take advantage of the full powers of C.

Although BASIC_C does an admirable job of getting a BASIC programmer started in making the transition to C, the product would be greatly improved if the documentation gave the user a better picture of what the final destination is. One way of doing this would be to provide more advanced examples that illustrate how the library can be used to write professional C programs, explaining the steps taken beyond the BASIC format of the simpler examples.

One relatively minor bug with the COLOR function could be a problem. Unlike the other functions in BASIC_C, COLOR does not behave the way its BASIC counterpart does. In IBM BASIC the COLOR statement can be used to set the color attributes of foreground, background, and border, clear the screen with CLS, and exit to DOS; the color attributes will remain in effect for the DOS environment. With the BASIC_C COLOR function, on the other hand, a print statement has to be issued for the color attributes to appear, and it is not possible to set the border color and keep it after exiting to DOS. These are not very serious problems, but they should either be fixed or be properly documented.

For experienced C programmers, the BASIC—C Library has some handy functions that are rarely found for the IBM PC. Among them are BLOAD(), BSAVEO, SET_TIME(), GET_TIME(), SWAPO, POINT(), and BEEP. Many of these functions, for example, are not included in the Greenleaf Functions, by Greenleaf Software, Inc., which claims to be the most inclusive C library.

Did you ever use C Source BASIC_C? Do you know anything about its history? Tell us about it in the comments below.

Share

Leave a comment

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.

Computers and Automation Magazine was the first computer magazine. Here is a little blurb from Archive.org:

Published by Edmund C. Berkeley since 1950. Computers and Automation was the first computer magazine. It was originally called Roster of Organizations in the Field of Automatic Computing Machinery, and later The Computing Machinery Field.

This publication initiated the first Computer Art Contest since 1963. A regular bibliography on computer art was compiled by Mezei, Leslie since 1966. Stopped publishing in 1972.

Enjoy the comics.

What computer ads would you like to see in the future? Please comment below. If you enjoyed it, please share it with your friends and relatives. Thank you.