Modcomp

Modcomp Memories

Of the great experiences Felix had in his career, including working on an artificial neural network at Wayne State University, involvement in the design and introduction of two computer architectures of two computer systems, design and implementation of a power-line communication system, no experience matches that of his involvement with the initial founding of Modular Computer Systems. Even though Felix was not a founder and missed the initial meetings at the “Down Under”, as employee number 40 he was privileged to see and maybe even contribute to its movement from a dream to a major contributor to the mini-computer industry. This chapter will cover some of the stories.

Founders

President: Ken Harple
Finance:
Engineering: Ray Matson
Software Development: Sy Schwartz, Joe Godfrey, Neil Miller
Manufacturing

Early Staff

Engineering

Hardware

Modcomp Processor: Ray Matson

Micro Code:

Memory:

Software By Product

Operating Systems: Max II Max III, Sy Schwartz, Byron Thomas

Software Loader: Paul Parker

Text Editor: Roger Lee

Macro Assembler:

Diagnostics: Neil Miller, Doug

Fortran Compiler: Syntax-Felix Bearden, Code Generator-Joe Godfrey

Runtime Library: Bob Horton

Math Library: Kamal Bitar

Manufacturing

Sales and Marketing

Events

Know Your People

As people left, a celebration was held at a local bar. At Joe Godfrey’s party several of us were discussing the importance of upper-management knowing their people. Someone, Joe I think, mentioned that Ken Harple was one of the best at knowing his people. Bill, labeled an “arithmetic major” by Jim Johnson, argued that upper management didn’t have time to know mere employees. Ken, “Our best asset is our people”, came to our table, shook hands with each of us, and when he got to Bill, and greeted him by name, also asked how his brother, mentioning him by name, and his brother’s wife, mentioning her by name, were doing.

A New Product

The first company wide meeting was to review the presentation of a marketing firm who was contracted help introduce the company and its product to the market place. Some of their ideas were accepted. The logo recommended and adopted was to suggest interconnected components using interconnected m”s around a center. The Company colors were to be Magenta, Chocolate, and Sandstone representing the initials of Modular Computer Systems. The first computer, the Modcomp III used those colors. The first building, after we moved out of the grocery store was sandstone with chocolate trim. The windows in the executive offices were magenta.

One idea, not accepted, was to use a rounded top so that three cabinets side by side would form the Modcomp M. It would also discourage placing items on the top which interfered with cooling.

Modcomp III

had 15 general-purpose registers,

was initially offered with a 16-kilobyte (16,384 bytes), 18-mil magnetic core memory with an 800 ns cycle time, expandable to 128 kilobytes (131,072 bytes).

Modcomp II

introduced in 1972,

maintained compatibility with the Modcomp III, while using some LSI circuits.

The core architecture of the 16-bit machines included blocks of uncommitted opcodes and provisions for physical modularity that hint at the reasoning behind the company name.

Modcomp IV

introduced in 1974,

was an upward compatible 32-bit machine with a paged  memory unit,

The minimum memory configuration was 32 kilobytes (32,768 bytes), expandable to 512 kilobytes (524,288 bytes), with access times of 500 to 800 nanoseconds (varying because of memory interleaving),

The machine had 240 general purpose registers, addressable as 16 banks of 15 registers. The MMU contained 1024 address mapping registers, arranged as 4 page tables of 256 pages each (some of these page tables could be further subdivided if address spaces smaller than 128 kilobytes (131,072 bytes) were needed). Fields of the program status were used to select the current active register bank and page table. The machine had a two-stage pipelined CPU, and a floating point unit,

Modcomp Classic

Compatible with the Modcomp IV,

supported 32 bit addressing.

Bootstrapping Software

Only recently had software systems progressed to a point where an operating system was needed. Complete programs were loaded with a bootstrap loader from some media like paper tape or punched cards. With more advanced storage systems like magnetic tape and disk storage, program loading became easier and primitive  operating systems with built-in functions were developed. CPM and early versions of DOS are examples of those. However, Modcomp's chosen market was measurement and control with event driven functions needed for control applications so the resulting operating system.  Developing system software for a new architecture from scratch with the final objective being an event driven operating system actually made planning easier. The first piece was to design the program object code and  the assembler language to take symbolic code and convert to object code. These pieces were coded and checked out on an IBM computer. Once this works, a primitive system can be implemented that can be run on the prototype of the new machine along with diagnostics to make sure the instructions operated as specified. Inaccuracies in this paragraph are due to the fact that Felix was not involved in this activity.

Felix was busy with Joe Godfrey designing the Fortran System and understanding the pseudo-code of an existing compiler. Also we discovered that the author of the book “Compiler Construction” was giving a two week course using his book as the text. Modcomp was good enough to send Felix there for the course. Felix got a draft of the book and about as intense class as he had ever had. He found out later that this was a practice session for a semester length class the professor was giving next semester at Cornell University.

The Fortran consisted of four parts. The compiler, the macro-assembler, the runtime/i/o library, and the math library. Except for the macro-assembler, the system was laid out in a traditional design. Because a requirement of the system that it would run from paper tape, the compiler was designed to generate code with a single pass over the source. To ease debugging of the generated code and enable additional machine instructions be included when implemented in future machines (like the Modcomp IV) it was decided to have the code generator generate macro source code to be assembled by the macro-assembler. This enabled the compiler to remain unchanged as the newly added features of hardware could be incorporated by making changes in the macro files.

“Compiler Construction” contained  a section on code optimization which served as the model for the one implemented in the compiler. Because of the one-pass design, optimization could only occur where the execution path was linear, that is sequences that didn’t include branches (conditional or unconditional). The compiler also used all 15 registers for computation, some for intermediate results and others to temporarily hold variables that were used more than once in expressions. Note that for computations involving arrays, computation of the pointer to the memory location is an expression and is subject to optimization.

Once the team had released the software, customers found problems that were not found with internal testing. The staff instituted an SPR(Software Problem Report) system to manage the tracking and correction of the problems. One person, Phillip Mathews, was the champion  submitter of these reports which were often associated with the Fortran system. The staff ended up hiring him to fix a number of the problems in the libraries that he discovered. Because of his skill reading the generated code, he was very helpful in tracking down compiler problems. One day, he came to Felix to report on a problem someone reported. The report suggested that the expected result, that was held in a register was never stored in memory. Phil was laughing because he found the storage instruction 14 pages of listings beyond where the SPR submitter expected it to be.